search

spadebuilders / community

Repo for community activities across @SPADEBuilders projects
https://waffle.io/spadebuilders/community
Apache License 2.0
5 stars 0 forks source link

Community Call - Nov 26th, 10am PST - EVM Evolution #14

Closed bmann closed 5 years ago

bmann commented 5 years ago

A kick off call with as many EVM and client maintainers that want to talk about improving the EVM. Date Nov 26th, 10am PST.

Please add topics and questions for discussion below, and use reactions to indicate which ones you like.

bmann commented 5 years ago

Overview of EVM Evolution from SPADE team -- Greg, Brooke, Boris.

Resources:

bmann commented 5 years ago

Using LLVM as a path to more language support

ethereum system diagrams

Related discussion in the ETH 1.x thread on EthMagicians with @fubuloubu

liangdzou commented 5 years ago

I would like to attend the meeting very much, but it is too late for me (2am Beijing time). It would be much better if the time can change a little. Though, it is ok if it is too hard.

bmann commented 5 years ago

@liangdzou hello! Thank you for being interested. Right now I would like to keep this call at the same time and then schedule the next call to work better for Beijing time.

We will take notes.

Can you share what you are interested in, what you are working on?

Sent with GitHawk

liangdzou commented 5 years ago

I am working in Qihoo 360 blockchain developing lab.

Currently, I am interested in improving the TPS of a blockchain, including sharding, smart contracts parallelization, SIMD, etc. I am also interested in multiple language support for writing smart contracts. But I think it would be better if TPS can be improved as well when support for the new languages.

By the way, do you guys have any examples where SIMD is required? I think those classical crypto algorithms are not appropriate examples because those can be implemented as system contracts/library/instructions. The example should show that the requirement is somehow not predictable and hence cannot be implemented before the chain is developed.

expede commented 5 years ago

Hi @liangdzou 👋

because those can be implemented as system contracts/library/instructions

Strictly speaking, any Turing-complete language (including Solidity and Vyper) can implement any possible program — ie: SIMD is for performance improvement. SIMD on Ethereum is not uncontroversial, but the main motivating case is being able to implement certain cryptographic algorithms and stay within Ethereum's gas limit (and not need to push them all down into specialized EVM opcodes / "precompiles", though I personally like that approach in general). They need to be predictable, since determinism at the application layer is desired.

cannot be implemented before the chain is developed.

Could you explain a bit more? Do you mean off of the application layer?

I am also interested in multiple language support for writing smart contracts. But I think it would be better if TPS can be improved as well when support for the new languages.

Amazing! From what I've seen, the application layer is almost never the TPS bottleneck for a blockchain system. The bigger issues are networking, mining, consensus, and hard logical synchronization.

RE languages and semantics: if I were to write a programmable blockchain from scratch, I personally would probably do things a bit differently from Ethereum (depending on the constraints of the system, of course). For one, I'd give the grammar much richer semantics, so it can be more easily (and deeply) statically analyzed. Secondly, I wouldn't provide full Turing-completeness, since we don't want contracts to run forever, and it introduces the halting problem and thus sacrificing totality.

smart contracts parallelization

In case you haven't seen it, I'd check out Formality, which has a number of interesting properties, including easy/automatic parallelism.

liangdzou commented 5 years ago

cannot be implemented before the chain is developed.

Could you explain a bit more? Do you mean off of the application layer?

If there are examples to show that the requirement of SIMD or multiple threads widely exists, not only for those countable crypto algorithms, then EVM has to define related features (SIMD, SIMT, VLIW, etc) in its opcodes. Otherwise, predefine them as system contract with const address (such as sha3) may be the best way. I can imagine that money transfer in ERC20 requires one memory read and two memory write. Those two memory writes can be running in parallel, and hence SIMD can be useful. But, this example may not be able to gain too much because that two writes will not be able to implemented by low-level SIMD instructions since the addresses used are both 256bits (creating new threads/corutines is also not appropriate since the execution is so short). So, I wish to hear some more convincible examples.

I am also interested in multiple language support for writing smart contracts. But I think it would be better if TPS can be improved as well when support for the new languages.

Amazing! From what I've seen, the application layer is almost never the TPS bottleneck for a blockchain system. The bigger issues are networking, mining, consensus, and hard logical synchronization.

Yeah, this is the most of the case. But if one applies blockchain in private chain, consensus and network will not cost as much as public blockchains. In such case, TPS will be important.

In such case, the requirement for deterministic of smart contracts makes the things so complicated. One must carefully select the libraries that can be used widely in C++ and so on, deal with uninitialised variables, data race, ...

smart contracts parallelization

In case you haven't seen it, I'd check out Formality, which has a number of interesting properties, including easy/automatic parallelism.

This functional programming approach should be able to deal with data race very well. But, it will be a little hard for normal developers to use, I think...

bmann commented 5 years ago

Zoom link https://zoom.us/j/715268638 for 10am PST

gcolvin commented 5 years ago

@liangdzou @expede SIMD is also there to

bmann commented 5 years ago

Thanks everyone for the time on the call. Here's the link to the call notes -- https://hackmd.io/g0yKhTn3TYaThqFWVjF4Ow -- feel free to edit.

I've created an evmevolution label and turned our action items into Github issues.

Please feel free to use this repo for creating meta issues related to EVM evolution.

gcolvin commented 5 years ago

Some notes on the notes:

Josselin

  • next clear step to get EIP 615 Static Jumps in?

Brooke

  • PR it against Yellow / Jello

Other Core EIPs have not been done as PRs against Yellow Paper, but we can pioneer.  (Not that I know any LaTex ;)  In addition to the EVM-K work there is Yoichi's Lem formalization.  The most up-to-date repo for that is Sidney Amani's

https://github.com/seed/eth-isabelle

which includes some of EIP-615

https://github.com/seed/eth-isabelle/blob/evm15/lem/evm.lem
  • Have a concrete implementation that people can look at

The Aleth team has pulled the old 615 and 616 code out, but I have kept a snapshot of an older repo

https://github.com/gcolvin/cpp-ethereum

Most of the work is here

https://github.com/gcolvin/cpp-ethereum/tree/develop/libevm
  • EIP moved into Final
  • Closed off as official piece of the standard

Design work remaining is to take advantage of EIP-615 to improve gas model--charged based on current modulus rather than full 256-bit width.  Could be in a separate EIP?  More convincing as single package.  Otherwise the performance benefits of EIP-615 are only a promissory note, not cash.

On implementation, should decide whether to put much more work into Aleth version given GPL license and unclear provenance, or move directly to a clean new version.  Would be interesting to see if the EVM-K folks really can generate a decent interpreter from the spec

On 11/26/18 4:05 PM, Boris Mann wrote:

Thanks everyone for the time on the call. Here's the link to the call notes -- https://hackmd.io/g0yKhTn3TYaThqFWVjF4Ow -- feel free to edit.

I've created an evmevolution label https://github.com/spadebuilders/community/labels/evmevolution and turned our action items into Github issues.

Please feel free to use this repo for creating meta issues related to EVM evolution.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spadebuilders/community/issues/14#issuecomment-441834700, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDC-ZfRGOTTijAbOEYKkPWxN4HbdF4hks5uzHPNgaJpZM4YTvGG.

fubuloubu commented 5 years ago

Otherwise the performance benefits of EIP-615 are only a promissory note, not cash.

The security benefits are more convincing IIRC

gcolvin commented 5 years ago

Yes, they are.  But 615 also allows for better code generation that is of little use unless the gas prices can reflect the better code.

On 11/26/18 5:50 PM, Bryant Eisenbach wrote:

Otherwise the performance benefits of EIP-615 are only a
promissory note, not cash.

The security benefits are more convincing IIRC

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spadebuilders/community/issues/14#issuecomment-441855902, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDC-QHKvUvKt8Tfy2ObImsojXLiULvgks5uzIxHgaJpZM4YTvGG.

expede commented 5 years ago

Not that I know any LaTex

I'm happy to brush off my LaTeX for the greater good 👍

Design work remaining is to take advantage of EIP-615 to improve gas model

I'd guess that the gas model would look a lot like a dynamic jump, but can't hurt to give it a close look since we need it in the spec. The gas model probably needs a bit of an overhaul, especially with a lot of the changes coming. As it goes with this kind of thing, starting high and lowing in a later EIP is better than the other way around, but I'm getting ahead of myself now 😛

charged based on current modulus rather than full 256-bit width. Could be in a separate EIP?

A new bit-width flag would need its own EIP, IMHO. This is a more complex and broader in scope than jump safety.

or move directly to a clean new version

Doing a cleanroom implementation is probably out of scope. We should either do this in GPLed Aleth (if the existing code can be easily adapted for the current client). Otherwise I would love to see this on a Parity branch (two birds with one stone). Thoughts?

gcolvin commented 5 years ago

On 11/26/18 5:58 PM, Brooklyn Zelenka wrote:

Not that I know any LaTex

I'm happy to brush off my LaTeX for the greater good 👍

Design work remaining is to take advantage of EIP-615 to improve
gas model

I'd guess that the gas model would look a lot like a dynamic jump, but can't hurt to give it a close look since we need it in the spec. The gas model probably needs a bit of an overhaul, especially with a lot of the changes coming. As it goes with this kind of thing, starting high and lowing in a later EIP is better than the other way around, but I'm getting ahead of myself now 😛

charged based on current modulus rather than full 256-bit width.
Could be in a separate EIP?

A new bit-width flag would need its own EIP, IMHO. This is a more complex and broader in scope than jump safety.

Runtime would be expensive, tracking max modulus at validation time cheap, probably needs its own EIP.

or move directly to a clean new version

Doing a cleanroom implementation is probably out of scope. We should either do this in GPLed Aleth (if the existing code can be easily adapted for the current client). Otherwise I would love to see this on a Parity branch (two birds with one stone). Thoughts?

Advantage of clean EVM-C version is any client can plug it in. Advantage of Aleth is likely fastest route, as I know the code. Advantage of Parity version depends on other plans re. Parity, but any EVM-C version could do for Parity?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spadebuilders/community/issues/14#issuecomment-441857328, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDC-VEx9GAhh_aujm3J_eYtQ6nQoyCXks5uzI4agaJpZM4YTvGG.

gcolvin commented 5 years ago

On reinspection, Aleth version is now EVMC-wrapped, and EMV 1.5 code fairly recently removed.  So I'd say that path of least resistance is to get EIP-615 working in Aleth again and then port to Parity via EVMC.

On 11/26/18 6:11 PM, Greg Colvin wrote:

On 11/26/18 5:58 PM, Brooklyn Zelenka wrote:

Not that I know any LaTex

I'm happy to brush off my LaTeX for the greater good 👍

Design work remaining is to take advantage of EIP-615 to improve gas model

I'd guess that the gas model would look a lot like a dynamic jump, but can't hurt to give it a close look since we need it in the spec. The gas model probably needs a bit of an overhaul, especially with a lot of the changes coming. As it goes with this kind of thing, starting high and lowing in a later EIP is better than the other way around, but I'm getting ahead of myself now 😛

charged based on current modulus rather than full 256-bit width. Could be in a separate EIP?

A new bit-width flag would need its own EIP, IMHO. This is a more complex and broader in scope than jump safety.

Runtime would be expensive, tracking max modulus at validation time cheap, probably needs its own EIP.

or move directly to a clean new version

Doing a cleanroom implementation is probably out of scope. We should either do this in GPLed Aleth (if the existing code can be easily adapted for the current client). Otherwise I would love to see this on a Parity branch (two birds with one stone). Thoughts?

Advantage of clean EVM-C version is any client can plug it in. Advantage of Aleth is likely fastest route, as I know the code. Advantage of Parity version depends on other plans re. Parity, but any EVM-C version could do for Parity?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub

https://github.com/spadebuilders/community/issues/14#issuecomment-441857328,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AQDC-VEx9GAhh_aujm3J_eYtQ6nQoyCXks5uzI4agaJpZM4YTvGG.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/spadebuilders/community/issues/14#issuecomment-441859878, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDC-dK97VaBMxSY3vmmvsqn3E3hm1ecks5uzJFJgaJpZM4YTvGG.

expede commented 5 years ago

🤔 I don't know if Parity has EVMC capability (it's not listed on the EVMC README at least). They've done their own highly-tuned EVM in Rust, so I'm not sure that they'd be looking to switch it out completely.

gcolvin commented 5 years ago

OK.  Adding EIP-615 to an existing VM is non-trivial.  Learning a new language slows it down a bit more.  Getting 615 working in Aleth again is much easier, and buys us an EVMC version for free.

Last I looked at the Rust VM is wasn't much tuned at all.  Will need to look again.

On 11/27/18 11:25 AM, Brooklyn Zelenka wrote:

🤔 I don't know if Parity has EVMC capability (it's not listed on the EVMC README https://github.com/ethereum/evmc#clients at least). They've done their own highly-tuned EVM in Rust https://github.com/paritytech/parity-ethereum/tree/master/evmbin, so I'm not sure that they'd be looking to switch it out completely.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spadebuilders/community/issues/14#issuecomment-442164982, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDC-b_mks9W3ykfDsO_-xsffl_KZq5zks5uzYOigaJpZM4YTvGG.

gcolvin commented 5 years ago

The Parity EVM is not highly tuned.  It's the same naive interpreter as ever with an expensive gasometer hanging off to the side.

https://github.com/paritytech/parity-ethereum/blob/14c9cbd40e4de4b1bdb53b346707f230b3be73c4/ethcore/evm/src/interpreter/mod.rs#L479

https://github.com/paritytech/parity-ethereum/blob/14c9cbd40e4de4b1bdb53b346707f230b3be73c4/ethcore/evm/src/interpreter/gasometer.rs#L107

On 11/27/18 12:07 PM, Greg Colvin wrote:

OK.  Adding EIP-615 to an existing VM is non-trivial.  Learning a new language slows it down a bit more.  Getting 615 working in Aleth again is much easier, and buys us an EVMC version for free.

Last I looked at the Rust VM is wasn't much tuned at all.  Will need to look again.

On 11/27/18 11:25 AM, Brooklyn Zelenka wrote:

🤔 I don't know if Parity has EVMC capability (it's not listed on the EVMC README https://github.com/ethereum/evmc#clients at least). They've done their own highly-tuned EVM in Rust https://github.com/paritytech/parity-ethereum/tree/master/evmbin, so I'm not sure that they'd be looking to switch it out completely.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub

https://github.com/spadebuilders/community/issues/14#issuecomment-442164982,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AQDC-b_mks9W3ykfDsO_-xsffl_KZq5zks5uzYOigaJpZM4YTvGG.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/spadebuilders/community/issues/14#issuecomment-442178949, or mute the thread https://github.com/notifications/unsubscribe-auth/AQDC-WCCaiu-X4h4B3C8OI_So0tCh7qVks5uzY1hgaJpZM4YTvGG.