Thread by @auroraisnear

1/ Highlights of an informative thread by @moo9000
Explore the evolution of EVMs and solutions to their scaling. For more details, read this blog post: capitalgram.com/posts/scaling-…
Let’s go! 👇🏻👇🏻👇🏻

2/ The first question we need to ask "why EVM?" There are nice highly scalable blockchains like @NEARProtocol, @solana and even @EOS_io out here. They provide more modern architecture than EVM and can do much better throughput and disk use. 💾

3/ The short answer is "sunken cost." 💸 During the last seven years a lot of investments have been made into Ethereum and Solidity ecosystems and this is directly portable to new blockchains.

4/ It would take millions to rewrite #DeFi smart contracts deemed secure by age. Software development frameworks and tools like @solidity_lang, @EthereumRemix, @vyperlang, @etherscan, @HardhatHQ, @trufflesuite have been years under development and can be considered mature.

5/ If EVM is the panacea of blockchains, why are smart people figuring out alternatives? Why are we already seeing the end of the road for EVM?

6/ Ethereum mainnet cannot sustain much more load than it did with the 2017 cryptokitties boom. @BinanceChain has propagation and synchronisation issues. @0xPolygon blocks are full.

7/ We see that EVM can go only to so many transactions per second. We see that transactions might never going to be free, or even cheap, on-chain, based on the current EVM architecture. Unless solved, the widespread adoption might be slow.

8/ We still have at least good 2-4 years left with EVM based blockchains. Because of sunken cost, slow migration and massive investments needed we are going to extract the every ounce of power out of EVM and see how far we can built our beautiful #DeFi kingdom.

9/ Who are the contenders? In the category of L1 blockchains we have @BinanceChain, @0xPolygon, Avalanche Coreth by @avalancheavax, Rootstock by @RSKsmart, Fantom by @FantomFDN

10/ Then we have L2 blockchains that use Ethereum mainnet for optimistic rollups. Some data is written on L1, but "the state" is managed on L2. Note that none of L2s are 1:1 EVM compatible, a developer needs to use a compiler or bytecode processor to deploy smart contracts on L2

11/
- @arbitrum from @OffchainLabs - famous for beating the race to be the first L2 EVM.
- Optimism from @optimismPBC - touted as go to L2 solution for @Uniswap.
- @zksync from @the_matter_labs - where @zksync version 2.0 will be more or less EVM compatible.

12/ Then, maybe the most interesting category is "EVM implementations from the scratch".

Aurora (@auroraisnear) from @NEARProtocol is EVM running as a service on the top of NEAR sharded blockchain. It's EVM-as-a-Rust-smart contract.

13/ A way to scale Ethereum is to have an infinite fast CPU and amount of RAM for each node. But even still you would hit the speed of light, as it takes 200 milliseconds for a single bit to travel around the world, and we want to be able to sync a node in any part of the world⚡

14/ The ultimate scalability problem is validating the block. To validate a block or a transaction, you need to know the full state of the whole blockchain.

15/ Because of state propagation, there is not much sense of doing another layer on top of layer 2. There won’t be “layer three”. Also layer two on the top of already fast state propagating layer 1 chains, like @0xPolygon, make less sense.

16/ We are seeing some state propagation issues, as nodes on fast EVM chains cannot keep up. @BinanceChain is having blocks of size 100M gas units. Likes of BSC and @0xPolygon can no longer run on a normal cloud server, but need to have directly attached NVMe storage.

17/ Optimistic layer two solutions will separate validation and transaction processing, so that a node can participate in the network, but can trust transactions coming from other nodes without validating them.

18/ But layer two solutions do not get away with propagation and storage limitations. Even though layer two solutions, like @arbitrum, start with an empty state eventually their layer two state is going to be similarly “full” as well.

19/ With some insight, we can make an assumption that the EVM model practical performance limit is somewhere between 100M gas and 800M gas blocks. With the 3 seconds / block BSC is 33M gas / second.

20/ As we do not have infinite fast CPUs, infinite amount of RAM and cannot break the light speed, what can we do to make EVM faster? 💽

21/
- Run nodes on better hardware.
- Have bigger blocks.
- Optimize EVM implementation.
- Decrease decentralisation by having less active and passive block producers (@0xPolygon, @BinanceChain) as that should decrease state propagation issues.

22/ Is there a case for @auroraisnear and other "EVM embedded in another chain approaches?"

One of the main benefits of the “EVM as a smart contract” approach is that it is trivial for EVM smart contracts to interact with the native smart contracts of the blockchain.

23/ For example, NEAR native smart contracts are able to run proper on-chain order book exchanges which seems to be out of the grasp for EVM. Aurora smart contracts can tap into this potential and e.g. create smarter AMMs swap services that beat @Uniswap v3.

24/ Aurora does not need to create a new blockchain: it utilizes the existing NEAR validator network that is already working. Aurora acts as a service from the existing NEAR blockchain.

25/ Aurora has a trustless bridging solution unlike other blockchains. near.org/bridge/
The most interesting stuff will happen in sharding. Aurora could potentially tap sharding faster than other EVM solutions (@NEARProtocol is one of the first sharded solutions).