Mega Intro to MegaETH

on the Tradeoffs between Performance and Centralization, Node Separation and Latency

MegaETH is a fast and scalable blockchain focused on performance.

They aim to become the most performant execution environment, a real-time blockchain, and make no vaporware promises in doing so.

For instance, they don’t pretend to be decentralized and explain why a centralized sequencer was necessary as a tradeoff to achieve their desired level of performance.

With their testnet expected to launch in November 2024 and mainnet in the works for Q1 2025, this article introduces MegaETH, abstracting the complexity of the tech stack and highlighting their value proposition, as well as new use cases unlocked with their performance.

---

On MegaETH

The Unique Selling Proposition (USP) of MegaETH is to create a blockchain with Web2 performance levels.

Before going into the technical implementations making this possible, it is important to reiterate on MegaETH and its USP. They aim to:

• Be a real-time Ethereum

• Have <10ms latency

• 100k Transactions Per Second (TPS)

While others boast 100k TPS what makes MegaETH unique is its highly specialized stack and low latency.

---

From Problem to Solution

MegaETH comes as a response to the limitations of most existing EVM chains (including Layer 2s):

• Transaction throughput: While L2s have significantly contributed to Ethereum’s scalability, their performance is still limited, limiting the development of more performant applications.

• Computing Power: executing EVM contracts is computationally expensive compared to programs in C and other languages.

• Long block times: Applications might require shorter block times to update than the chain offers. This limits the deployment of on-chain games, which need higher tick rates to work smoothly.

These limitations arise from the fact that L1 blockchains are inherently homogenous; that is, all nodes perform all sorts of tasks, from execution to validation. Unfortunately, this means the whole network matches the speed of the slowest nodes.

L2s partially mitigate this problem with more heterogeneous blockchain, where nodes are partially specialized through a sequencer.

MegaETH tackles these limitations with:

1. Developing a heterogeneous blockchain architecture focused on performance, allowing different nodes to have different hardware configurations to execute specific tasks

2. A hyper-optimized EVM execution environment to match the performance of the sequencer, pushing throughput, latency, and resource efficiency to hardware limits. 

MegaETH takes node separation to the extreme, with each blockchain task expected to have a different node configuration:

• Sequencers: a beefy machine responsible for transaction ordering and execution (this will have hardware requirements similar to a Solana RPC node or better).

• Stateless Provers: extremely lightweight OP challengers using stateless validation schemes to re-execute transactions.

• Full Nodes: re-executing all transactions, but more lightweight than the sequencer (as re-execution is more efficient and requires less power)

• Replica nodes: they only stream state diffs from the sequencer and rely on provers to verify the correctness of the state. The absence of re-execution means these nodes have lower hardware requirements. 

• Light Clients: rely on full nodes or replica nodes to update the state

By doing so, they separate the execution task from full nodes, as execution and sequencing should have a different node architecture than block validation.

The sequencer is responsible for executing and ordering transactions. MegaETH employs one very powerful sequencer, specifically configured and optimized for this task. It can achieve sub 10ms latency, 100k transactions per second, and parallel execution.

The rest of the MegaETH stack is optimized to match these benchmarks.

Having only one sequencer means that during normal transaction execution, there is no need for consensus, reducing redundancy and node workload. To align interests and mitigate the sequencer's centralized power, MegaETH employs optimistic fraud proofs and slashing in case of malicious behavior.

MegaETH also plans to introduce a rotating sequencer architecture to decentralize the sequencer operators. The operating sequencer changes according to a pre-defined schedule and sequencers are located in different geographic locations.

MegaETH also optimizes its prover network, decoupling its nodes, where each prover node is tasked with a subset of the sequencer's transactions. In this way, the hardware requirements are not as high as those of the sequencer nodes. The provers can validate blocks "asynchronously and out of order” by leveraging the stateless validation scheme. Currently, the prover network starts with an optimistic fraud proofs architecture with plans to move to zk proofs in the future.

Megadeth Replica Nodes are not required to re-execute transactions but can indirectly validate blocks using proofs sent by provers. For this reason, they can be operated with relatively lower hardware requirements, similar to an Ethereum full node. They receive status updates from the sequencer and use them to update states, but they are not required to check the validity of the information contained.

Others can still choose to re-execute transactions themselves using a Full Node, but they will need higher hardware requirements. They can also simply decide to rely on the information validated by full nodes and replica nodes using a light node.

MegaETH uses EigenDA for Data Availability (over 15mb per second) to achieve the necessary performance.

Through this configuration, MegaETH stack can be summed up as having a:

• Very centralized block production (execution environment)

• Very decentralized block validation

This results in enhanced network performance with minimized hardware requirements for full nodes.

Here are the hardware requirements for MegaETH compared to others:

MegaETH is also Ethereum-aligned. As they have a centralized sequencer, they need a strong decentralized settlement layer like Ethereum to derive security and decentralization. While having a single sequencer poses questions in terms of censorship and a single point of failure, MegaETH uses several mechanisms mitigating these risks, such as:

• Exit hatch: take your ETH to the L1, even if the sequencer is malicious, your ETH is safe (technical and social consensus guarantee)

• Fraud Proofs to ensure the sequencer is behaving as expected (current optimistic proofs)

• Rotational sequencer, decentralizing the operator of the sequencer to mitigate centralization and single point of failure.

While MegaETH is developing its in-house rotational sequencer, these other mitigation mechanisms are widely used across L2s.

The current blockchain architecture makes it impossible to achieve Web2 levels of performance. MegaETH decouples consensus from execution and leverages node separation to create specialized nodes dedicated to specific tasks.

A centralized sequencer ensures outstanding performance, opening up new use cases. What’s interesting to me is that these new cases are so innovative that there is no clear idea of what they might look like.

Some examples mentioned by the team include:

• Games

• dePin infra, which requires real-time computation

• Autonomous world engines

• Decentralised vpn networks

• Cross-border payments

• High-Frequency Trading leveraging the extremely low latency

While the performance improvements brought by MegaETH are game-changing for some niches that require real-time updates, a question remains on the ability to develop an ecosystem of apps that prioritize performance over decentralization.

For this reason, they have created an ecosystem called MegaMafia, focusing on ensuring a vibrant ecosystem since the testnet launch - they already have over 13 protocols developing.

Here’s an overview of the ecosystem as of the 11th of October.

In most cases with blockchain networks that are incubating projects in-house (like we have seen with Blast, Monad, Berachain), we expect total alignment between their interests for mutual benefits…. IYKYK.

I also appreciate their honest approach to communication. Contrary to what most L2 do nowadays, they don’t pretend to be decentralized and actually present the trade-offs they chose.

This is admirable and makes them very focused on a specific feature: performance.

What does MegaETH compare to? MegaETH can be considered a Solana competitor with more decentralized block validation.

In particular, some apps building on MegaETH couldn’t do so on Solana due to the need for real-time updates, including an on-chain Minecraft and a fitness application.

It will then be interesting to see whether MegaETH manages to attract a significant following to compete with Solana, which is arguably the most developed retail ecosystem.

To conclude, opening up a discussion around the 10ms latency is essential.
In the context of MegaETH, latency is defined as the preconfirmation latency or block time on the chain. The <10ms latency means there is no additional wait for block time, only the necessary time for the message to travel back and forth.

Unfortunately, we can’t break the speed of light (yet). For this reason, latency has to be understood as sequencer latency (from the transaction arriving to the chain to be executed and the state being committed). In the case of MegaETH, latency close to 1ms is only practical when projects run their own full nodes and place them close to the sequencer – but this will not be the final latency for each node.

As MegaETH full nodes are fairly cheaper to run, this is not an extremely difficult effort, especially for large applications. 

In a certain sense, sequencer rotation partially mitigates this; however, ensuring the same latency across nodes will be hard. This is similar to the Flash Boys High-Frequency Trading days when closeness to the server mattered as it defined latency.