3 ms·
The EVM itself is pretty inefficient. They're planning to replace it entirely with ewasm (a deterministic subset of wasm), once they do the big 2.0 transition i
by DennisP 6y ago
The EVM itself is pretty inefficient. They're planning to replace it entirely with ewasm (a deterministic subset of wasm), once they do the big 2.0 transition in a year or two. That may be why there hasn't been a major effort on compiler optimizations for the EVM, though they do make regular updates to Solidity. (The current version is 0.6.9, fwiw.)
There are also some other smart contract languages in the works, the main one being Vyper, but it's not quite ready for production.
But if you're interested in picking some of that low-hanging fruit, you'd probably be welcome, most of the Ethereum community is pretty open to new contributors.
- davidmurdoch 6y agoAre you sure the future ETH 1 shard won't continue to execute transactions via the EVM? AFAIK, I don't think it will be replaced, it'll just live within Ethereum 2 as an "execution environment".
- DennisP 6y agoThat is a possibility. They haven't made a final decision, but it would make things easier. But most of the network would still be running ewasm (after Phase 2).
- saagarjha 6y agoI mean, my complaints weren’t with the efficiency of the EVM, really, it was more that the compiler didn’t take any advantage of the huge gas differential between the stack and storage…I am unsure how EWASM helps at all (or even why it exists, to be honest). Sadly our project was optimized for a class presentation rather than actually contributing back, but if I ever find myself back in that space I’ll be sure to send in some patches.
- DennisP 6y agoHow long ago were you looking at it? I have no idea whether they've implemented anything like that but they do make regular updates. Btw another big change the researchers are working on is statelessness, where the on-chain data is just merkle roots, the actual data is held off-chain in a distributed but reliable way, and clients submit merkle proofs with their transactions. That would drastically reduce the amount of data that full nodes have to store, and presumably allow large reductions in storage prices. (But that doesn't mean solc shouldn't work on compiler improvements like you're talking about, they're not the ones working on statelessness.)