Read on Medium
The EVM — Scale or Fail?21 March 2022
Guest post by Michael A. Stay Ph.D, CTO of Pyrofex & the Silvermint Network
The Ethereum foundation has written quite a bit about how they’re going to make the EVM scale and they’ve started building. They’ve deployed the Beacon chain and The Merge is planned for later this year. They have a two-part plan to scale up, partly on-chain and partly off-chain. But, they do not yet have a plan for how to scale up the execution of non-payment contracts. V. Buterin has said, “The eth2 roadmap offers scalability, and the earlier phases of eth2 are approaching quickly, but base-layer scalability for applications is only coming as the last major phase of eth2, which is still years away.” As a result, we’re left wondering whether the EVM can possibly scale or whether the challenge is ultimately intractable?
The non-EVM Bits…
Ethereum intends to use shards for on-chain scaling of payments. There is a special beacon chain that coordinates sixty-four shards, which are smaller independent blockchains. Shards don’t run contracts, they just store data. So, none of this will help ERC20 tokens or DeFi.
Ethereum’s beacon chain randomly assigns validators to a shard every 6.4 minutes (an “epoch”) and randomly picks one of them to issue a block. The rest of the validators verify that the block is valid and attest to that fact with a signature.
The set of validators assigned to the shard for that block is called a committee. Since there are sixty-four shards, committee sizes have at most 1/64th the total number of validators and this has a corresponding reduction in overall security.
Randomly selected committees can have large variance in performance and bandwidth; an unlucky combination will slow down the shard until at least the next epoch. Random assignments are likely to underperform the average 50% of the time, so shards that are slow and remain slow for 20–30 minutes are likely to be routine.
In order to prevent validators from influencing the random assignment, there’s an entropy generation ceremony. But, ceremonies like this are tricky to get right. Researchers found an attack on the original design.
None of this specifically aids smart contracts running on the EVM.
Layer 2 Scaling
Ethereum also intends to use off-chain scaling via layer 2 protocols. There are four different approaches: optimistic rollups, validity proofs, state channels, and side chains.
Optimistic rollups involve collecting batches of transactions, storing that information on a shard, and then letting a contract on the main chain know that the transactions occurred. The contract then checks the signatures and updates its internal state.
This approach optimistically assumes that all transactions are valid, and validators only verify them if someone issues a challenge during a limited window of time. A challenger has to provide a proof that fraud occurred. There’s some work claiming that optimistic rollups are subject to denial-of-service attacks.
If this helps EVM transactions, it does so only when parties to the transaction are paying very close attention to the possibility of fraud. If the window during which challenges can occur is brief, then those parties have to contribute significant resources to making sure they issue timely challenges. If the period is longer, then transactions can only be processed slowly, which scales less well.
Validity proofs, in the form of zk-snarks or zk-starks, allow validators to easily check that all the transactions are valid. Such proofs are very slow to produce, which places a real burden on the client. They also can’t support generic EVM code, so this doesn’t help EVM scalability at all. But for the purpose of quickly validating payment transactions, this is workable if clients are willing to pay the performance penalty.
State channels allow parties to run code off-chain, then have all impacted parties sign off on the result and store the resulting state on a shard, then notify a contract on the main chain to update its internal state. This works fine, but the computation can’t be verified by external observers.
Side chains run independent of the main network, with special nodes that speak both protocols to coordinate two-way communication between the chains for transfers of value or message delivery. This approach, like hash time-lock contracts, usually requires several transactions per interaction. It is also only as secure as the weakest contract on either side; for instance, last year the Poly network was hacked for $610M of ETH, BNB, and USDC — though remarkably, the hacker gave it all back — and last month Wormhole, the most popular ETH/Solana bridge, was hacked and lost $320M.
There’s No Generic Solution for the EVM
Some of the Layer 2 approaches help, but there’s no generic solution for scaling contracts that will work for all applications. V. Buterin has said, “Currently, users have accounts on L1, ENS names on L1, applications live entirely on L1, etc. All of this is going to have to change. We would need to adapt to a world where users have their primary accounts, balances, assets, etc entirely inside an L2. There are a few things that follow from this:
- ENS needs to support names being registered and transferred on L2.
- Layer 2 protocols should be built into the wallet.
- We need more work on cross-L2 transfers.
- More explicitly standardize on Yul or something similar as an intermediate compiling language…
The clear conclusion is that scaling the Ethereum VM is a disaster, and now they’re left scrambling to make the thing work with duct tape and baling wire. There’s no cutoff date, either: Ethereum’s got to keep running for the foreseeable future, and the foreseeable future is exponential growth. With these designs they can squeeze a few more years out of the system, but without a complete replacement of the virtual machine, Ethereum is not viable long term.
The Alternative: Symmetry
Silvermint offers an attractive alternative. First, because the Symmetry language and VM semantics provide excellent transaction isolation, which allows contracts that are independent of each other to scale independently. Second, because we aren’t trying to be backwards compatible with the EVM semantics. The Symmetry VM is natively multithreaded within a contract and natively asynchronous between contracts. As a result, transactions can be handled in near realtime and errors can be back-propagated along the call chain in an elegant and natural way that will be familiar to any web developer.
The Symmetry VM will offer features including memory isolation, state-of-the-art type safety, support for formal verification, advanced call tracing facilities, application-layer transaction ordering, multi-threading, and advanced package management. All available with a syntax based on Go that will be familiar and easy-to-learn. There simply isn’t another VM for blockchain that’s even considering this suite of features.
This is tough stuff to get right in a brand new programming language and Symmetry won’t be perfect from day one. The goal is to build a language and VM that’s transformative, taking the world of smart contracts far beyond what the EVM can offer. We want to build a platform that developers can rely on for decades to come, because it’s rich in features, globally scalable, and reliable in implementation.
But, we can’t do it without a decentralized community of passionate developers who share that vision. In the long run, it’s going to be people like you, who understand that blockchain is changing the world and want to be a part of creating that positive change. We’re excited to start building that community and if you’re reading this, we want you to participate.
If you’re interested in our project and want to talk with us about it, join our Discord, engage with us on social media, and let us know what you think. We’re always open to feedback and we’d love to hear your thoughts.