Community Call - Nov 26th, 10am PST - EVM Evolution #14
Comments
|
Overview of EVM Evolution from SPADE team -- Greg, Brooke, Boris. Resources:
|
|
Using LLVM as a path to more language support
Related discussion in the ETH 1.x thread on EthMagicians with @fubuloubu |
bmann
changed the title
bmann
changed the title
|
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. |
|
@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 |
|
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. |
|
Hi @liangdzou 👋
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.
Could you explain a bit more? Do you mean off of the application layer?
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.
In case you haven't seen it, I'd check out Formality, which has a number of interesting properties, including easy/automatic parallelism. |
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.
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, ...
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... |
|
Zoom link https://zoom.us/j/715268638 for 10am PST |
|
@liangdzou @expede SIMD is also there to
|
|
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. |
|
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
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQDC-ZfRGOTTijAbOEYKkPWxN4HbdF4hks5uzHPNgaJpZM4YTvGG>.
|
The security benefits are more convincing IIRC |
|
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
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQDC-QHKvUvKt8Tfy2ObImsojXLiULvgks5uzIxHgaJpZM4YTvGG>.
|
I'm happy to brush off my LaTeX for the greater good 👍
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 😛
A new bit-width flag would need its own EIP, IMHO. This is a more complex and broader in scope than jump safety.
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? |
|
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
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQDC-VEx9GAhh_aujm3J_eYtQ6nQoyCXks5uzI4agaJpZM4YTvGG>.
|
|
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
>
<#14 (comment)>,
> 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
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQDC-dK97VaBMxSY3vmmvsqn3E3hm1ecks5uzJFJgaJpZM4YTvGG>.
|
|
🤔 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. |
|
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
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQDC-b_mks9W3ykfDsO_-xsffl_KZq5zks5uzYOigaJpZM4YTvGG>.
|
|
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
>
<#14 (comment)>,
> 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
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQDC-WCCaiu-X4h4B3C8OI_So0tCh7qVks5uzY1hgaJpZM4YTvGG>.
|
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.
The text was updated successfully, but these errors were encountered: