4 ms·
Weren't there some efforts in a new, safer language for the EVM? I think, Vyper or something. What happened?
by k__ 5y ago
Weren't there some efforts in a new, safer language for the EVM? I think, Vyper or something.
What happened?
- casi18 5y agoVyper has safe math built in, so you wont get accidental over/underflows. but Solidity also has that now in the newer versions. so its really a preference if you prefer the python-like text. Fe is also being developed, looks like it has been planned out a bit more than vyper. But more likely we will see developments of security and proofs in languages like cairo, to be used on zkrollups, where we will also see alternative VMs to the EVM. So there will be lots of options with different tradeoffs between composability/security/efficiency/redundancy.
- mypastself 5y agoI think Solidity won out due to to the ease of developer adoption (unlike Vyper, it is object-oriented). ETH2’s EVM replacement, EWASM, will use WebAssembly, so developers should be able to use saner programming languages than Solidity.
- k__ 5y agoAh, I didn't know about EWASM. This sounds pretty rad! Thanks!
- duncancmt 5y agoUnfortunately EWASM is pretty much dead. The current direction of ETH2 R&D is still EVM-based.
- k__ 5y agoThat sounds pretty sad. Why did they stop going in that direction?
- vvpan 5y agoI think just a matter of priorities and also EVM has accumulated so much tooling that eWASM would be a setback.
- duncancmt 5y agoI'm not a Ethereum core dev, but this is my understanding: The EVM is tailor-made to accurately account for the expense of executing programs in a distributed environment. It has a highly heterogeneous addressing scheme. Every opcode has execution cost metering that has been refined over time. Each word is 256 bits to make 256-bit cryptographic operations easier. There's significant tooling around the EVM for writing and analyzing smart contracts. Other EVM-based blockchains would need to migrate in parallel. The skillset of "blockchain application developer" has coalesced around Solidity and the EVM. Bottom line is that although WASM offers compatibility with non-blockchain tooling, the blockchain-specific needs of Ethereum are so much better served by the EVM that migrating is difficult.
- jwlake 5y agoThe EVM design choices are tightly bound with the on-chain storage of data. On ethereum you pay for reads (less) and writes (more) but everything is very expensive because it's stored in a merkle tree with computationally expensive operations. Alot of the WASM experimentation has also included changes around how storage is charged. Specifically NEAR does a deposit system where you have to HODL to store data on chain. That allows them to innovate in the runtime and cost structure and still incentivize blockchain nodes. So it's not entirely gas accounting for computation, its more pricing for storage that probably keeps eth on EVM indefinitely. Other experimental chains are must more likely to become robust and trusted and more performant and then eclipse ethereum.
- duncancmt 5y agoEthereum considered implementing storage rents, like NEAR, but instead decided to transition to a verkle trie model that permits succinct proofs of state values. State rent presents some serious problems regarding composeability. What the state-of-the-art solution for state rent on resources that are effectively common goods?
- mypastself 5y agoHuh, I guess my information is out-of-date. It is a fast-moving space. And it’s a shame they’re continuing with Solidity. I’m wondering how Cardano’s Haskell-based Plutus platform will compare in practice, now that they’re rolling out smart contracts as well. I’m guessing they’re going to have significant adoption issues.
- jwlake 5y agoNEAR is WASM based. It's interesting but not nearly as "battle tested" as EVM. ETH2 also can't break any backward compatibility, which makes it easier to just keep going down the EVM route.
- udbhavs 5y agoEOS as well