How MegaETH gets to 10ms

MegaETH is a Layer 2 on Ethereum, aiming for high transaction throughput, handling big compute and millisecond response times.

Cheap fees, fast transactions.

This was always the user facing North Star.

Keeping data fees dirt cheap is easier when you can easily scale throughput without worrying about blobs. Scaling the blobs should me of the utmost important because there is simply no way we can meet user demand by scaling the blobs just twice a year on a hard fork.

However, some L2s choose to step outside of this constraint.

MegaETH choose to do this with EigenDA.

_Data throughput, in the context of data availability layers, measures the rate at which data is processed and made available on the network, typically in bytes per second._

Standard Ethereum DA remains constrained by Ethereum’s thorughput and pricing. EigenDA gives the ability for MegaETH to aim for its real-time processing goals handling massive data volumes at low latency with prices at cents per MB.

Optimizing for fast transactions

The network’s compute is another constraint. The main constraint. Specifically the limit rests in the compute needed by nodes to re-execute all transactions, keeping up with continuous block production by the chain – so not just proving, but continuoustly keeping up with that.

To reach the compute needed while being an L2 and within the EVM, the team behind Mega modified the traditional L2 architecture based on their measurements of execution bottlenecks. Like the cool kids say: measure, then build. More on that in this article by 0xSami.

Great, let’s optimize for throughput:

– Node specialization: Not all nodes do all things. Some nodes receive state diffs, some nodes receive full block and re-execute to prove blocks are valid. We call these “replica nodes” and “prover nodes” respectively.

– Two-pronged parallel execution to maximize throughput avoiding state contention. Block producers an use any concurrency control protocol, while full nodes rely on stateless parallel validation.

– JIT-based execution = faster transaction processing by compiling bytecode to native instructions. Think of Just In Time compilation as something that translates EVM bytecode into machine code and the key part here is: _before execution._

– A Custom State Trie = fewer disk reads and writes when updating block’s state. Updating traditional Merkle Patricia Trees requires exploring and reading many nodes (data structure nodes) before effectively updating the ones that require so. MegaETH modifies MPT into a new memory & I/O efficient trie allowing to scale into terabytes of state data.

– Moving state into memory = less time in input/output operations.

– Price models where pricing depends on how many state changes (key-value updates) a transaction causes instead of gas. Internally, there is still a limit on how many key-value operations can fit into one block, but MegaETH’s node architecture (specialization, JIT, custom state trie, etc.) is built to handle those updates at ms speeds.

Unblocking the gas

Block gas limits the maximum amount of gas that can be consumed within a single block. This is good for ensuring your small Raspberry Pi can keep up with its consensus duties. Each block gets processed and verified. Although L1 has a strict gas limit per block, an L2 can define its own internal “block gas limit.” The L2 just needs to be able to post their transaction data to a DA layer.

Unlocks: The fun part

The fun part begins when you can think of all of the usecases that benefit of a realtime, high throughput environment. Gaming, AI, ML, pricing, prediction and literally any model, finance, swaps and predition markets. Not everything _needs_ high speeds, but it sure doesn’t hurt. Below I’ll add some other usecases compiled by Bread:

> Running ML models directly in smart contracts > Graph algorithms that can traverse entire networks/relationships > > Maintaining larger in-contract data structures > Handling bulk operations in a single transaction > > Running full zero-knowledge proof verification > Complex cryptographic operations without offchain components > * Real-time AMMs

Open questions

Writing this begs a couple of questions. Why EigenDA? I’m aware of the overlapping founders, the elasticity, slashability and decentralization of EigenDA. I’ve even written before about EigenDA, see here. Maybe a better question is: why would Rise choose Celestia?

Assuming mass adoption in a couple of years, will EigenDA and Celestia become a go-to need for L1? Will any apps move over to MegaETH?

Will MegaETH spawn a new series of real time L2s? I get that new L2s won’t “real time” itself but it begs to ask why would anyone spin up a new traditional L2 after this.