Written by: 0XNATALIE
In the latest episode of the Bankless podcast, Monad founder Keone Hon and MegaETH co-founder Lei Yang discussed the architecture of Monad and MegaETH and how they will improve Ethereum's performance. The podcast focuses on the future of the Ethereum Virtual Machine and answers a series of key questions, including a comparison of Monad and MegaETH speed, decentralization, and censorship resistance.
But after the show, the founder of Monad was still not satisfied and continued to ask MegaETH questions about the definition of "full node" on X, and finally invited Vitalik to join the discussion.
Monad is a Layer 1 that achieves a throughput of over 10,000 transactions per second through parallel execution technology and a unique consensus mechanism.
MegaETH is a Layer 2 that leverages parallel execution technology to achieve millisecond response times, with the goal of processing over 100,000 Ethereum transactions per second.
The heart of the dispute: Should full nodes execute all transactions?
In the podcast, Lei Yang mentioned that full nodes in MegaETH refer to those nodes that maintain and update the latest blockchain status, rather than nodes that execute and verify all transactions. In response to this, Keone Hon posted on Twitter questioning MegaETH's definition of "full node", because a full node in the traditional sense refers to a node that can independently execute and verify all transactions. The full node proposed by MegaETH only receives status updates from a centralized sequencer and does not independently verify transactions. Keone is worried that such a node may not provide sufficient security when processing large transactions in the real world.
If the full node only receives status updates and does not participate in the actual execution and verification of transactions, it means that the node must fully trust the status provided by the centralized sequencer. If the sequencer is wrong, attacked, or deliberately malicious, the node may not be able to detect the problem in time. This is especially important when processing large transactions, because these transactions involve huge amounts of money and any errors may cause serious financial losses.
Keone proposed a practical application scenario: Assuming an exchange integrates MegaETH and runs such a full node, how can the exchange determine that the user's deposit transaction has been truly confirmed? How long should it wait before the funds are deposited into the user's account? Does the exchange need to wait for a fraud proof window of up to 7 days to ensure that the transaction will not be rolled back, thereby ensuring the security of the deposit?
Vitalik’s point of view: The key is to ensure transaction confirmation
Ethereum founder Vitalik Buterin also participated in the discussion. He believes that the focus is not on whether the full node executes all transactions, but whether users can get enough transaction confirmation guarantees. Vitalik believes that for L2 users, the most important thing is to confirm whether their transactions are accepted, not whether each node executes all transactions. As long as there is an appropriate mechanism to ensure this, users do not necessarily need to run a full node that executes all transactions themselves.
Vitalik mentioned that there are two transaction confirmation mechanisms:
Bonded Sequencer Preconfirmation: In this mechanism, the sequencer is bound to a certain amount of tokens (such as ETH) when processing transactions. If the sequencer acts maliciously or fails to process transactions correctly, users can get compensation or compensation. This mechanism provides the guarantee of instant confirmation, and users can get the security of transactions without waiting for the fraud proof window.
L1 Confirmation: Transactions on L2 can eventually be confirmed by L1 (such as Ethereum). If there is a problem with the transaction on L2, L1 can roll back the transaction and correct the error. Even if there are risks on L2, users can still rely on the final confirmation of L1 for security.
Vitalik also mentioned that the length of the fraud proof window can be adjusted according to user needs. For example, exchanges can choose different fraud proof windows based on the size of the transaction amount. For small transactions, a shorter window may be required; for large transactions, a longer window may be selected. In addition, with the development of zero-knowledge proof (ZK) technology, the need for fraud proof windows will be greatly reduced in the future, and may even be eliminated, thereby providing faster transaction confirmation without sacrificing security.
However, Keone believes that MegaETH will not use ZK technology in the early stage. Although ZK technology has great potential, it still has certain limitations in performance. The computational process of generating zero-knowledge proofs is very complex and time-consuming, especially when a large number of transactions need to be processed. Therefore, blockchain projects like MegaETH that focus on high performance and high throughput will not choose to use ZK technology in the early stage to avoid performance issues affecting user experience.
MegaETH responds: Multiple transaction confirmation methods
Lei Yang then responded to the discussion about MegaETH node architecture with a tweet, clarifying some misunderstandings. He pointed out that MegaETH users have three options when confirming transactions:
Nodes that only receive status updates: This type of node does not verify any transactions and only receives status updates from the sequencer. The security of this method depends on the pre-confirmation mechanism and penalty mechanism of the sequencer. It is suitable for small to medium transactions, especially in scenarios that require instant confirmation.
Nodes waiting for the fraud proof window to expire: Same as 1, but users need to wait for the fraud proof window and the MegaETH block in which the transaction is located to be finalized on Ethereum. This option provides "full Ethereum security" (i.e., the same security and irreversibility as Ethereum transactions) and is suitable for scenarios where users do not want to verify transactions locally but involve large transactions. This use case is relatively rare.
Full nodes that verify all transactions: This full node verifies every transaction and waits for the MegaETH block in which the transaction is located to be finally confirmed on Ethereum. It also provides "full Ethereum security" and is suitable for users who regularly process large transactions and want fast confirmation, such as exchanges.
Lei Yang emphasized that MegaETH supports full nodes that can verify every transaction. There may have been a misunderstanding in the previous discussion that MegaETH nodes can only receive status updates but cannot verify transactions, which is wrong. He further explained that if a node chooses to verify all transactions, it can verify transactions more efficiently than the sequencer through optimization means (such as using the witness data provided by the sequencer), without having to process all transaction information from scratch, thereby reducing hardware requirements. Users can choose between different confirmation methods according to their needs.
This debate was quite interesting. As Lao Bai, the investment research partner of ABCDE, said: "Does this debate make sense? Absolutely! The technological evolution of the entire industry is being pushed forward slowly through these discussions. Does it matter who wins or loses? Absolutely not! Because the winner ultimately depends on resources, developers/user experience, and who comes up with 1-2 popular applications first, not on the definition and responsibilities of a 'full node'."
