Thread by @moo9000

1/ Welcome to #DeFi Wednesday.

Scaling wars begun have. After high fees and congestion of 2021, everyone and their cow is out there to make a better EVM - #Ethereum Virtual Machine - blockchain. But how far the 7 years old EVM architecture can still take us?

👇👇👇

2/ For those, who hate reading threads on Twitter (which I know if all of you) and who enjoy long reads, my research is also available in the blog post:

capitalgram.com/posts/scaling-…

Good for getting sleeep at night.

3/ 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.

4/ The short answer is is "sunken cost." Ethereum and its EVM was the first smart contract engine for blockchains.

5/ 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 (see: various Binance Smart Chain copy-paste projects).

Some examples:

6/ EVM based #DeFi is more than $50B assets under management

tokenterminal.com/terminal/metri…

Would take millions to rewrite those smart contracts deemed secure by age.

7/ Software development frameworks and tools like @solidity_lang, @EthereumRemix, @vyperlang, @etherscan, @HardhatHQ, @trufflesuite have been years under development and can be considered mature.

8/ For the above, there are countless of university courses, online courses, blog posts and documentation written. You can start your smart contract programming career with Solidity quite easily, but the same cannot be said for more niche technologies.

Simply: One can find devs.

9/ There have been expensive lessons learn. Each hack, flash loan attack and audit has increased our knowledge how #DeFi and smart contracts should be developed.

ethereum.stackexchange.com/questions/8551…

10/ The EVM based blockchains are integrated and can be integrated easily to hundreds of cryptocurrency exchanges and cryptocurrency wallets. ERC-20, in all its brokeness, is the lingua franca of transfer of value.

11/ For example, see the growing @WalletConnect mobile wallet support registry.walletconnect.org/wallets

12/ Thus, the sunken cost of EVM development and integration is in billions of dollars. This comes on the top of assets under management on EVM based chains.

The runner up blockchain architecture must be willing to spend similar amount of investment and time to catch up.

13/ It can be done, but it will take time.

14/ Why not EVM?

If EVM is the panacea of blockchains, why are smart people figuring out alternatives?

👇👇👇

15/ EVM was the first engine of smart contract blockchains. Like with the early automobiles, we do not want to drive T-Fords with their one cylinder piston engine today. We want to drive @Tesla

16/ Researchers developers have made theoretical breakthroughs and learnt practical lessons since the EVM inception in 2014. We know we can build better virtual machines and blockchains for smart contracts than EVM: faster, cheaper, safer and more SCALABLE.

17/ The GoEthereum, the first implementation and node, was released in 2014.

18/ EVM is very much ossified and backwards compatible incompatible changes, which would make it scale better, are impossible without breaking the billions of dollars assets running on the current smart contracts.

19/ BTW For interested you can download and dive into the "original geth" from here

pkg.go.dev/github.com/eth…

20/ We are already seeing the end of the road for EVM.

Ethereum mainnet cannot sustain much more load than it did with the 2017 cryptokitties boom. Binance Smart Chain has propagation and synchronisation issues. Polygon blocks are full.

21/ These issues are because the architectural limitations with GoEthereum and EVM themselves (more on this later).

22/ 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.

23/ But we still have at least good 2-4 years left with EVM based blockchains, on my own estimations. Because sunken cost, slow migration and massive investments needed.

24/ For this period, we are going to extract the every ounce of power out of EVM and see how far we can built our beautiful #DeFi kingdom where roads have been made for T-Fords.

25/ A bear market is going to help of course, as there is less pressure on the demand side.

26/ Who are the contenders?

EVM is with us, for a while, and everyone out there is tuning it and trying to capture #DeFi total value locked (TVL) and mindshare for their chain.

👇👇👇

27/ In the category of layer one blockchains, based on @go_ethereum, we have the following contenders:

28/ Binance Smart Chain, 100M gas blocks and 3 second block time, famous for its inability to co-operate with the rest of the ecosystem and geth developers.

Comes from @binance

29/ Polygon, @0xPolygon, with its layer one geth implementation tied to their own Heimdall (Tendermind) based consensus engine.

20M blocks, 2 second block time.

30/ Avalanche Coreth and C-chain from @avalancheavax - marrying Avalanche consensus with the forked @go_ethereum implementation

31/ Rootstock from @RSKsmart

An EVM blockchain for #bitcoin maximalists

32/ Fantom, yet another @go_ethereum clone from @FantomFDN - a marketing heavy new blockchain initiative

Looks like their Github is still unmodified geth, so who knows what's brewing? 🙃

github.com/Fantom-foundat…

33/ Then we have the second category, layer two blockchains that more or less take @go_ethereum and cram it into layer two.

These use Ethereum mainnet for optimistic rollups. Some data is written on L1, but "the state" is managed on L2.

👇👇👇

34/ If you want to learn more how layer twos work, here is an excellent article by @arturcygan

ethereum.org/en/developers/…

35/ Note that none of L2s are 1:1 EVM compatible, but a developer needs to use a special compiler or bytecode processor to deploy their smart contracts on L2. The differences should be neglible, though.

36/ Arbitrum from @OffchainLabs - famous for beating the race to be the first L2 EVM

37/ Optimism from @optimismPBC - touted as go to L2 solution for @Uniswap

PBC stands for "public benefit corporation", so I assume this means no new token, no ICO, and this will be purely #Ethereum maxi play.

38/ @zksync from @the_matter_labs - where @zksync version 2.0 will be more or less EVM compatible.

Not sure if there is any geth in ZKSync.

39/ Did I forget any notable L2s? Please ping me.

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

Let's forget the baggage and try to build it better this time? No geth, even a single bit of it.

👇👇👇

41/ 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.

42/ @HelloTelos offers EVM-as-a-smart contract on its EOS forked chain. All the speed and benefits of EOS, with the familiarity of Ethereum.

docs.telos.net/evm/about-ethe…

43/ We have some failed competitors as well. As the game has been on since 2017, so let's not forget those who gave everything they got just to get rich and then forget their promises.

44/ @Tronfoundation never really delivered their copy-paste whitepaper promises of being better Ethereum. In fact after raising a billion dollar or so back in the day, the main news on Tron Network website is still Justin Sun getting a diploma from a university.

45/ Here is more why I think Tron failed:

https://twitter.com/moo9000/status/1389583048849645576

46/ @qtum network thought UTXO (#bitcoin transaction model) is way to go. They might have been right, might have been wrong, but never got any traction.

47/ Now we know who are on the EVM race. Let's do some thought experiements and napkin math where these EVMs will take us.

👇👇👇

48/ As today we discuss about the scalability and scalability only, we will woefully ignore other importants facts, which may weight even more than technical superioty: community, quality of team, runway funding, ecosystem funding, vested interests, etc.

49/ To understand the scalability problems, we first need to understand what is the EVM state and why it is so hard to "scale the state." While there are many aspects of scaling blockchains, I find state propagation and storage the most difficult one to solve.

50/ Here is my explanation of what is the EVM state in #Ethereum for those who have taken computer science classes:

51/ The EVM measures the cost of state change through SSTORE instructions, like any other EVM instruction, in gas. The storage instructions are most expensive and have been subject to constant upgrades to make the network scale.

52/ For example, Ethereum mainnet had a denial-or-service vulnerability regarding SSTORE as recently as until the Berlin hard frok.

blog.ethereum.org/2021/05/18/eth…

53/ To understand the upper limit of EVM architecture scalability we need to look the transaction processing

👇👇👇

54/ The problem is the bottle neck in propagation and accessing the state.

The upper speed limit is set e.g. by:

55/ - Speed how fast new leader can be decided - decided by consensus algorithm

56/ - How fast the leader will execute state changes (IO, CPU)

57/ - How fast the leader propagates the block to other validators (network bandwidth and latency)

58/ - How fast other validators can validate the new block, or rerun the transactions against their state (IO, CPU)

59/ The easiest way to scale Ethereum is to have an infinite fast CPU with an infinite amount of RAM, for each validator and node that wants to sync the chain.

60/ 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 blockchain node in any part of the world.

61/ The limitation of state propagation:

👇👇👇

62/ Based on the paragraph above, the ultimate scalability problem manifests itself in step 4 - “validating the block.” To validate a block or a transaction, you need to know the full state of the whole blockchain being validated against.

63/ Because any EVM transaction can touch any part of the state of the blockchain, any validating node, fisherman, or similar disputer needs to know the current full state.

64/ It takes 1) network bandwidth to download a new block 2) CPU to validate transactions 3) large IO and RAM to maintain the full state.

65/ 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 Polygon, make less sense.

66/ We are seeing some state propagation issues, as nodes on fast EVM chains cannot keep up. Binance Smart Chain is having blocks of size 100M gas units.

https://twitter.com/ProofOfBags/status/1395235478216060935

67/ Likes of BSC and Polygon can no longer run on a normal cloud server, like one using Amazon Elastic Block Storage (EBS), but needs to have directly attached NVMe storage due to high IO requirements.

en.wikipedia.org/wiki/NVM_Expre…

68/ What about layer two?

We were promised layers.

👇👇👇

69/ All EVM layer one nodes validate and process transactions - even if your node does not participate in the consensus i.e. mine or stake.

70/ Most o 10,000+ Ethereum 1.0 nodes are not mining - they maintain the peer-to-peer network (censorship resistance), propagate transactions and offer API services to Dapps and wallets.

These kinds of nodes are called full nodes in EVM lingo.

71/ 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.

72/ While this likely makes syncing a full node faster, I do not know how much state size decrease a full node can achieve. For many use cases, full nodes still need to maintain the full state and all historical events.

73/ 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.

74/ hen, you need to either do “layer 3”, or have multiple rolled-up states. Having multiple rolled-up states running on the top of layer one Ethereum mainnet is “a poor man’s sharding” solution.

75/ Furthermore, after the first layer two solutions have now been deployed, it looks like they might not end up being cheap enough, because they still need to write transaction info on layer one calldata and logs (although not on L1 state).

76/ A layer two critical post by @hosseeb

medium.com/dragonfly-rese…

77/ But how fast? What is the current theoretical and practical EVM performance.

We know there is a wall but how soon we are going to hit it? We do not need to drive to a wall our eyes blinded.

👇👇👇

78/ @ErigonEth (formerly TurgoGeth) is the fastest Ethereum implementation on this planet. Its core developer @mandrigin offers some good insights and benchmarks.

79/ The 800M gas blocks are 8x what Binance Smart Chain is having currently. The Binance Smart Chain has hit 80% utilization on a good day, with problems.

80/ 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.

81/ Further Igor clarifies that with 800M gas blocks the processing likely becomes CPU bound. Currently, @go_ethereum uses an interpreter for running EVM code.

82/ In 2016, there was an effort in the past to replace the interpreter with a more CPU efficient, more work per executed CPU instruction, just-in-time compiler.

blog.ethereum.org/2016/06/02/go-…

83/ Breaking the EVM limits.

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?

👇👇👇

84/ Brute-forcing it: Requiring everyone to run nodes on better hardware (see NVMe comment above) and kick out nodes from the network on the P2P layer if they cannot keep up.

BSC does this.

85/ Bigger blocks (see the theoretical limit above)

86/ If we keep using @go_ethereum, then optimize it. E.g. Optimize EVM implementation e.g. by replacing geth EVM interpreter with a just-in-time compiler.

87/ Decrease decentralisation by having less active and passive block producers (Polygon, Binance Smart Chain) as that should decrease state propagation issues.

88/ Smarter leader choosing and better consensus algorithms, like Nightshade from @NEARProtocol

near.org/papers/nightsh…

89/ Smarter block and transaction propagation.See Turbine propagation from @solana

docs.solana.com/cluster/turbin…

90/ What can be done by changing the EVM?

We get even more scaling tricks if we can sacrifice some backwards compatibility with existing smart contracts.

👇👇👇

91/ Computer science theory-based changes, like trading CPU time to IO and network bandwidth by replacing Merke trees with Verkle trees

See the nice summary post from @VitalikButerin

vitalik.ca/general/2021/0…

92/ Optimistic parallel transaction processing. See Sealevel from @solana

solana.com/news/sealevel-…

93/ Various state proposals to decrease the active state size by putting some of it into the freezer.

See multiple state rent proposals EIP 2026-2031 in #Ethereum Improvement Proposal track

eips.ethereum.org/core

94/ What about the from-the-scratch approaches?

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

👇👇👇

95/ 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.

96/ 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.

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

near-staking.com

98/ Thus, Aurora team should be able to focus more on optimisations and spend less time on generic blockchain infrastructure work, like hiring validators.

This applies to @MoonbeamNetwork and other EVM soutions that tap to @Polkadot parachains for the security.

99/ Aurora has more trustless bridging solution than other blockchains ATM in the form of Rainbow Bridge - near.org/bridge/

I am yet to decide is it L2 level secure (i.e. bullet proof non-custodial), or less, as I am learning more every day.

100/ The most interesting stuff will happen in sharding. Because Aurora could potentially tap sharding faster than other EVM solutions ( @NEARProtocol is one of first sharded solutions), Aurora would have huge advantage.

101/ Sharding advantage, though, needs to have demand that cannot be satisfied by the current upper scalability limitations. Whether this demand exists or not for the next few years is yet to see.

102/ I know @solana devs are not hurried with sharding, as they believe there is still plenty of road left to travel until we fall off the cliff.

103/ 👆👆👆

That's all this time folks.

Now I will celebrate for getting this research out by switching my latte to something stronger. Maybe Espresso?

Also the mandatory @AaveAave paid swag placement.

104/ Ps. Thank you for @chirrapp for their excellent Twitter thread editor.

PPS. Please subscribe to my newsletter

newsletter.capitalgram.com