Author: knower, crypto KOL; Translation: Golden Finance xiaozou

1. Introduction to MegaETH

The main content of this article will be some of my personal thoughts on the MegaETH whitepaper, and I may expand further from here if I can. Regardless of what this article ends up being, I hope you can learn something new from it.

MegaETH’s website is cool because it has a mechanical rabbit on it and the colors are very eye-catching. Before this, there was only a Github - having a website makes everything much simpler.

I looked through the MegaETH Github and learned that they are developing some type of execution layer, but I have to be honest, maybe I am wrong about this idea. The fact is, I don’t know enough about MegaETH to know that they are now a hot topic on EthCC.

I needed to know everything and make sure I was seeing the same technology that the cool guys were seeing.

The MegaETH white paper says that they are a live EVM-compatible blockchain that aims to bring web2-like performance to the crypto world. Their goal is to improve the Ethereum L2 experience by providing properties such as over 100,000 transactions per second, block times of less than one millisecond, and transaction fees of one cent.

Their whitepaper highlights the growing number of L2s (discussed in one of my previous posts, though that number has since climbed to over 50, with many more in “active development”) and their lack of PMF in the crypto world. Ethereum and Solana are the most popular blockchains, and users will gravitate to one of them, only opting for other L2s if there are tokens to mine.

I don’t think too much L2 is a bad thing, just like I don’t think it’s necessarily a good thing, but I do acknowledge that we need to step back and examine why our industry is creating so much of it.

Occam's razor would say that VCs enjoy the feeling of knowing that they really have a chance to build the next L2 (or L1) king and get satisfaction from investing in these projects, but I also think that perhaps many crypto developers actually want more L2. Both sides may be right, but the conclusion about which side is more correct is not important. It is better to look at the current infrastructure ecosystem objectively and make good use of everything we have.

The performance of the L2 we currently have available is high, but not enough. The MegaETH whitepaper says that even with opBNB’s (relatively) high 100 MGas/s, that would only mean 650 Uniswap transactions per second — modern or web2 infrastructure is capable of 1 million transactions per second.

We know that despite the crypto advantages that come from decentralization and enabling permissionless payments, it’s still pretty slow. If a game developer like Blizzard wanted to bring Overwatch to the chain, they couldn’t do it - we need higher CTR to provide real-time PvP and other features that web2 games naturally provide.

One of MegaETH’s solutions to the L2 dilemma is to delegate security and censorship resistance to Ethereum and EigenDA respectively, turning MegaETH into the world’s highest-performing L2 without any trade-offs.

L1 typically requires homogeneous nodes that perform the same tasks, leaving no room for specialization. In this case, specialization refers to tasks like sorting or proving. L2 bypasses this problem by allowing heterogeneous nodes to be used, separating tasks out to improve scalability or offload some of the burden. This can be seen in the growing popularity of shared sorters like Astria or Espresso and the rise of specialized zk proving services like Succinct or Axiom.

“Creating a live blockchain involves more than just using an off-the-shelf Ethereum client implementation and ramping up the sorter hardware. For example, our performance experiments show that even with a beefy server equipped with 512GB of RAM, Reth can only reach around 1000 TPS in a live sync setting on recent Ethereum blocks, which equates to around 100 MGas/s.”

MegaETH extends this division by abstracting transaction execution from full nodes, using only one "active" sorter to eliminate the consensus overhead in typical transaction execution. "Most full nodes receive state differences from this sorter via the p2p network and apply the differences directly to update their local state. Notably, they do not re-execute transactions; instead, they indirectly validate blocks using proofs provided by provers."

I haven’t read much analysis on how good MegaETH is other than “it’s fast” or “it’s cheap” comments, so I’m going to try to carefully analyze its architecture and compare it to other L2s.

MegaETH uses EigenDA to handle data availability, which is pretty standard practice these days. Rollup-as-a-Service (RaaS) platforms like Conduit allow you to choose Celestia, EigenDA, or even Ethereum (if you want) as the data availability provider for your rollup. The difference between the two is fairly technical and not entirely relevant, and it seems like the decision to choose one over the other is based more on consensus than anything else.

The sorter orders and ultimately executes transactions, but is also responsible for publishing blocks, witnesses, and state differences. In the L2 context, a witness is additional data used by a prover to verify the sorter's blocks.

A state difference is a change to the state of the blockchain, and can be basically anything that happens on the chain - the function of a blockchain is to constantly append and verify new information added to its state, and the function of these state differences is to allow full nodes to confirm transactions without having to re-execute them.

Provers consist of special hardware that computes cryptographic proofs to verify block contents. They also allow nodes to avoid duplicate execution. There are zero-knowledge proofs and fraud proofs (or are they optimistic proofs?), but the distinction between them is not important right now.

Putting all of this together is the task of the full node network, which acts as a kind of aggregator between provers, sorters, and EigenDA, making the MegaETH magic (hopefully) a reality.

MegaETH’s design is based on a fundamental misunderstanding of the EVM. While L2 often blames the EVM for its poor performance (throughput), it has been found that the revm can reach 14,000 TPS. If it’s not the EVM, then what is it?

2. Current scalability issues

The three main EVM inefficiencies that lead to performance bottlenecks are lack of parallel execution, interpreter overhead, and high state access latency.

MegaETH is able to store the state of the entire blockchain due to its abundance of RAM, the exact RAM of Ethereum is 100GB. This setup significantly speeds up state access by eliminating SSD read latency.

I don't know much about SSD read latency, but presumably some opcodes are more intensive than others, and if you throw more RAM at the problem, you can abstract it away. Does this still work at scale? I'm not sure, but for this post I'll take it as fact. I still doubt that the chain can determine throughput, transaction cost, and latency all at once, but I'm trying to be an active learner.

Another thing I should mention is that I don’t want to be overly critical. My idea is to never favor one protocol over another or even give them equal weight in the beginning - I just do this for better understanding and to help anyone reading this get the same understanding at the same time.

You may be familiar with the trend of parallel EVM, but there is a problem. Although progress has been made in porting the Block-STM algorithm to the EVM, it is said that "the actual speedup achievable in production is inherently limited by the available parallelism in the workload." This means that even if the parallel EVM is released and eventually deployed to the EVM chain on the mainnet, the technology is limited by the basic reality that most transactions may not need to be executed in parallel.

If transaction B depends on the outcome of transaction A, you can’t execute two transactions at the same time. If 50% of the transactions in a block are interdependent, as is the case, then parallel execution is not as significant an improvement as claimed. While this is a bit of an oversimplification (and maybe even a little incorrect), I think it hits the point.

The gap between revm and native execution is quite significant, especially since revm is still 1-2 OOMs slower and not worthwhile as a standalone VM environment. It was also found that there are not enough compute-intensive contracts to warrant the use of revm. "For example, we analyzed the time spent on each opcode during history synchronization and found that about 50% of the time in revm is spent on "host" and "system" opcodes."

MegaETH found more problems when it came to state synchronization. State synchronization is simply described as a process of synchronizing a full node with sorter activity, a task that can quickly consume the bandwidth of a project like MegaETH. Here’s an example to illustrate this: if the goal is to synchronize 100,000 ERC20 transfers per second, this will consume approximately 152.6 Mbps of bandwidth. This 152.6 Mbps is said to exceed MegaETH’s estimates (or performance), essentially introducing an impossible task.

This only takes into account simple token transfers, and ignores the possibility of higher consumption if the transaction is more complex. Given the diversity of on-chain activity in the real world, this is a possible scenario. MegaETH writes that Uniswap transactions modify 8 storage slots (while ERC20 transfers only modify 3 storage slots), bringing our total bandwidth consumption to 476.1 Mbps, a much more unfeasible goal.

Another problem in achieving a 100k TPS high-performance blockchain is solving the update of the chain state root, which is a task of managing the sending of storage proofs to light clients. Even with professional nodes, full nodes still need to use the network's sorter nodes to maintain the state root. Taking the problem of synchronizing 100,000 ERC20 transfers per second as an example, this will bring the cost of updating 300,000 keys per second.

Ethereum uses the MPT (Merkle Patricia Trie) data structure to calculate the state after each block. In order to update 300,000 keys per second, Ethereum needs to "convert 6 million non-cached database reads," which is much more than any consumer-grade SSD can handle today. MegaETH wrote that this estimate doesn't even include write operations (or estimates for on-chain transactions such as Uniswap transactions), making the challenge more of a Sisyphean endless effort than the uphill battle most of us might prefer.

There is another problem, we have reached the limit of block gas. The speed of the blockchain is actually limited by the block gas limit, which is a self-imposed barrier designed to increase the security and reliability of the blockchain. "The rule of thumb for setting the block gas limit is that any block within this limit must be processed safely within the block time." The white paper describes the block gas limit as a "throttling mechanism" that ensures that nodes can reliably keep up, assuming that the nodes meet the minimum hardware requirements.

Others say that the block gas limit was chosen conservatively to protect against the worst-case scenario, and is another example of modern blockchain architecture valuing security over scalability. The idea that scalability is more important than security falls apart when you consider how much money is transferred between blockchains every day, and how losing that money for a slight increase in scalability could lead to a nuclear winter.

Blockchains may not be great at attracting high-quality consumer applications, but they are incredibly good at permissionless peer-to-peer payments. No one wants to screw that up.

Then there is the fact that parallel EVM speeds are workload dependent, and their performance is bottlenecked by the “long dependency chain” that minimizes over-“speedup” of blockchain functions. The only way to solve this problem is to introduce multi-dimensional gas pricing (MegaETH refers to Solana’s native fee market), which is still difficult to implement. I’m not sure if there is a dedicated EIP for this, or how such an EIP would work on the EVM, but I guess technically it’s a solution.

Finally, users do not interact directly with sorter nodes, and most users do not run full nodes at home. Therefore, the actual user experience of a blockchain depends heavily on its underlying infrastructure, such as RPC nodes and indexers. No matter how fast a live blockchain runs, it will not matter if RPC nodes cannot efficiently handle a large number of read requests at peak times, quickly propagate transactions to sorter nodes, or if indexers cannot update application views quickly enough to keep up with the speed of the chain.”

This may be too much to say, but it is very important. We all rely on Infura, Alchemy, QuickNode, etc., which run the infrastructure that most likely supports all of our transactions. The easiest explanation for this dependence comes from experience. If you have ever tried to claim an L2 airdrop in the first 2-3 hours after it, you will understand how difficult it is for RPC to manage this congestion.

3. Conclusion

Having said all that, I just want to express that a project like MegaETH needs to overcome many obstacles to reach the heights it wants to reach. One post said that they have been able to achieve high-performance development by using a heterogeneous blockchain architecture and a super-optimized EVM execution environment. "Today, MegaETH has a high-performance live development network and is steadily moving towards becoming the fastest blockchain, limited only by hardware."

MegaETH's Github lists some major improvements, including but not limited to: EVM bytecode → native code compiler, large memory sorter node dedicated execution engine, and efficient concurrency control protocol for parallel EVM. The EVM bytecode/native code compiler is now available, named evmone, and although I am not proficient in coding and cannot know its core working mechanism, I have tried my best to figure it out.

evmone is a C++ implementation of the EVM that takes the EVMC API and converts it into an execution module for Ethereum clients. It mentions some other features that I don't understand, such as its dual interpreter approach (baseline and advanced), and the intx and ethash libraries. In summary, evmone offers the opportunity for faster transaction processing (through faster smart contract execution), greater development flexibility, and increased scalability (assuming different EVM implementations can handle more transactions per block).

There are a few other codebases, but most of them are pretty standard and not specifically related to MegaETH (reth, geth). I think I'm pretty much done with the whitepaper, so now I leave the question to anyone reading this: What's next for MegaETH? Is it actually possible to implement a working scaling code? How long will it take for this to happen?

As a blockchain user, I’m excited to see if this works. I’m spending too much money on mainnet transaction fees and it’s time for that to change, but it still feels increasingly difficult to achieve and unlikely to happen anytime soon.

While this post is mostly centered around architectural improvements and scalability, there will still need to be intra-rollup shared liquidity and cross-chain tooling to make the experience of rollup A consistent with rollup B. We’re not there yet, but maybe in 2037 everyone will sit back and reminisce about how we were obsessed with “fixing” the scalability problem.