The Debate Over Parallel EVMs: Monad and MegaETH Explore the Definition of Full Nodes

Written by: 0XNATALIE

In the latest episode of the Bankless podcast, Monad founder Keone Hon and MegaETH co-founder Lei Yang discussed the architectures of Monad and MegaETH and how they aim to enhance Ethereum's performance. The conversation centered on the future of the Ethereum Virtual Machine, addressing key questions such as comparisons between Monad and MegaETH in terms of speed, decentralization, and censorship resistance.

However, after the episode, the Monad founder remained engaged and continued questioning MegaETH’s definition of a "full node" on X (formerly Twitter), eventually drawing Vitalik Buterin into the discussion.

Monad is a Layer 1 blockchain that achieves over 10,000 transactions per second through parallel execution technology and a unique consensus mechanism.
MegaETH is a Layer 2 solution leveraging parallel execution to achieve millisecond response times, aiming to process over 100,000 Ethereum transactions per second.

The Core Dispute: Should Full Nodes Execute All Transactions?

During the podcast, Lei Yang mentioned that in MegaETH, a full node refers to one that maintains and updates the latest blockchain state, rather than executing and validating every transaction. In response, Keone Hon took to Twitter to challenge this definition of a "full node," arguing that traditionally, a full node should independently execute and verify all transactions. In contrast, MegaETH's proposed full nodes only receive state updates from a centralized sequencer without independently verifying transactions. Keone expressed concern that such nodes may not provide sufficient security when handling high-value real-world transactions.

If full nodes merely receive state updates instead of participating in actual transaction execution and validation, they must fully trust the state provided by the centralized sequencer. If the sequencer makes an error, is attacked, or acts maliciously, these nodes might not detect issues in time. This becomes especially critical for high-value transactions, where any mistake could lead to significant financial loss.

Keone presented a practical scenario: suppose an exchange integrates MegaETH and runs such a node—how can it confirm that a user's deposit transaction has been truly finalized? How long should it wait before crediting the user's account? Would the exchange need to wait for the full seven-day fraud proof window to ensure the transaction cannot be rolled back and thus guarantee deposit safety?

Vitalik's Perspective: The Focus Is on Transaction Finality Assurance

Ethereum co-founder Vitalik Buterin joined the discussion, emphasizing that the key issue isn't whether full nodes execute all transactions, but whether users can obtain sufficient assurance about transaction finality. According to Vitalik, for L2 users, what matters most is knowing their transactions are accepted—not whether every node executes every transaction. As long as appropriate mechanisms exist to guarantee this, users don't necessarily need to run full nodes that execute all transactions themselves.

Vitalik outlined two transaction finality mechanisms:

1. Bonded Sequencer Preconfirmation: Under this mechanism, the sequencer stakes a certain amount of tokens (e.g., ETH) when processing transactions. If the sequencer misbehaves or fails to process transactions correctly, users can receive compensation. This provides immediate finality assurance, allowing users to consider transactions secure without waiting for the fraud proof period.

2. L1 Finalization: Transactions on the L2 can ultimately be confirmed on L1 (e.g., Ethereum). If there's an issue with an L2 transaction, L1 can roll it back and correct errors. Even if risks exist on the L2, users can still rely on L1's final confirmation for security.

Vitalik also noted that the length of the fraud proof window can be adjusted based on user needs. For example, exchanges could choose different fraud proof durations depending on transaction size—shorter windows for small transactions, longer ones for large transactions. Furthermore, with advancements in zero-knowledge proof (ZK) technology, the need for fraud proof windows will significantly decrease and may eventually disappear, enabling faster transaction finality without compromising security.

Nonetheless, Keone pointed out that MegaETH does not plan to use ZK technology initially. While ZK holds great promise, it currently faces performance limitations. Generating zero-knowledge proofs is computationally intensive and time-consuming, especially under high transaction volumes. Therefore, high-performance, high-throughput blockchain projects like MegaETH avoid adopting ZK at launch to prevent performance bottlenecks from degrading user experience.

MegaETH Responds: Multiple Transaction Finality Options

Later, Lei Yang responded via tweet, clarifying misconceptions about MegaETH's node architecture. He explained that MegaETH users have three options for transaction finality:

1. Nodes that only receive state updates: These nodes do not validate any transactions and simply accept state updates from the sequencer. Their security relies on the sequencer's preconfirmation and penalty mechanisms. Suitable for low-to-medium value transactions, particularly in scenarios requiring instant finality.

2. Nodes that wait for the fraud proof window to expire: Same as option 1, but users wait for both the fraud proof window and for the corresponding MegaETH block to be finalized on Ethereum. This offers "full Ethereum-level security" (i.e., equivalent to Ethereum transaction security and irreversibility), ideal for high-value transactions where users prefer not to locally verify transactions. This use case is relatively rare.

3. Full nodes that validate all transactions: These nodes verify every single transaction and wait for the corresponding MegaETH block to be finalized on Ethereum. Also provides "full Ethereum-level security," suitable for entities like exchanges that regularly handle high-value transactions and desire fast confirmation.

Lei Yang emphasized that MegaETH does support full nodes capable of validating every transaction. Previous discussions may have created a misunderstanding suggesting MegaETH nodes can only receive state updates and cannot validate transactions—this is incorrect. He further clarified that nodes choosing to validate all transactions can use optimization techniques (such as witness data provided by the sequencer) to verify transactions more efficiently than the sequencer itself, without reprocessing all data from scratch, thereby reducing hardware requirements. Users can choose among these finality methods based on their specific needs.

This debate was truly compelling. As Lao Bai, research partner at ABCDE, put it: "Does this kind of debate matter? Absolutely! The industry's technological progress advances slowly through exactly these kinds of discussions. Does it matter who wins or loses? Absolutely not! Because in the end, the winner will be determined by resources, developer/user experience, and who launches the first one or two killer applications—not by whose definition of a 'full node' and its responsibilities is correct."