The two founders of popular Ethereum ecosystem projects Monad and MegaETH recently had a heated discussion about the future development of Ethereum. Monad co-founder and CEO Keone Hon and MegaETH founder and CTO Lei Yang discussed topics related to Ethereum alignment, full nodes, decentralization, anti-censorship, and the importance of self-verification. The discussion about full nodes also attracted Ethereum founder Vitalik Buterin to participate in the discussion.
Is there a new definition for “full node”?
Lei Yang seemed to redefine a “full node” in his conversation with Keone as a node that receives streaming state deltas from a single sorter without executing transactions.
Lei said that in general, MegaETH users who want to confirm a transaction have three options:
1) Run a node that does not validate any transactions, but listens to state updates from the sorter - the kind Keone mentioned. Security comes from pre-confirmation and assurances from the sorter that if it misbehaves, its stake will be slashed. This is suitable for small to medium value transactions and when real-time finality is required.
2) Same as 1, but the user waits for the challenge window of the optimistic proof to expire, and for the MegaETH block containing the transaction to be finalized on Ethereum. This is "full Ethereum security" - a transaction being reversed will trigger the same slashing as an Ethereum transaction being reversed. This is good when the user does not want local verification but expects high-value transactions. This use case is rare.
3) Run a full node that verifies every transaction and waits for the MegaETH block containing the transaction to be finalized on Ethereum. This is also "full Ethereum security". This is good when users expect to make high-value transactions regularly and want them to be completed quickly. For example, exchanges.
MegaETH users can choose any of the above three options locally, and therefore need to make a trade-off between latency, node hardware requirements, and transaction confirmation guarantees.
It seems that some people are confused that MegaETH cannot have nodes that validate every transaction (option 3 above). This is incorrect. These three types of users coexist. It is important to note that even if a node decides to validate every transaction, it can apply many tricks to validate (re-validate) more efficiently than a powerful sorter can. Therefore, its hardware requirements are still much lower than a sorter. For example, it does not need to read the state database (a major bottleneck) when validating transactions, because the sorter can provide witnesses (the state required to validate a block, plus the corresponding trie proof). This is not the case with L1.
Unfortunately, the discussion with Keone seemed to focus on what an L2 full node is (which is off topic), while ignoring the following facts: (1) trade-offs exist; (2) trade-offs should be presented to users so that they get the most relevant combination of performance and guarantees; and (3) Ethereum L2 is well suited to do this.
Keone responded, "Well said, but that seems to be completely different from yesterday when you were touting the benefits of "option 1" nodes (which you called full nodes at the time). I mean we have the recording, go listen to it! You seem to be emphasizing self-validating nodes more now, which is a direction I agree with."
Lei said, I will happily repeat the benefits/importance of having an Optimistic full node (one that does not re-execute every transaction) as many times as I want. Such nodes will be the type that most users care about, as they provide a meaningful trade-off between confirmation guarantees and operational costs. As I mentioned in this episode, the guarantees they get are cryptoeconomic. If a user gets ripped off (transactions are reversed), the sequencer gets slashed. https://x.com/VitalikButerin/status/1826497936676860184 outlined by Vitalik can also provide compensation to users and further strengthen the security model. Such nodes are suitable for users who frequently process small to medium transactions and users who need real-time performance - these types of applications are unique on MegaETH. To reiterate: most MegaETH users do not need to self-verify.
I mention other types of full nodes to (1) clarify that MegaETH supports self-validating full nodes using hardware that is much lighter than sorters, and (2) point out that the trade-offs between confirmation guarantees, time, and node hardware are a spectrum that cannot be achieved simultaneously with self-validating full nodes alone.
V God responded, I think focusing too much on L2's "full node" is missing the point? From a user's perspective, the key question is: How much assurance do you have that your transaction will be accepted?
There are two levels:
1) Binding sequencer pre-confirmation:
Either your transaction is accepted, or the sorter loses >= N ETH or other tokens
This can be further extended through the concept of Stakesure:
Either your transaction is accepted or you get compensated by the sorter for some pre-agreed amount.
2) L1 Confirmation:
Either your transaction is accepted, or L1 is reversed (even if L1 is reverted, incentives can force the sorter to be honest. Once L1 is finalized, L1 reversal becomes impossible)
L1 and L2 are fundamentally different, L1 is much harder because you have nothing else to rely on for decentralization/security. L2 users don’t need to enforce it themselves because they can rely on L2’s proof system (this will become more true as our ecosystem moves more and more towards proofs of validity) 
Keone replied to V God: However, if the exchange accepts deposits from an Optimistic L2, it will definitely want to execute it on its own instead of waiting for 7 days because of the fraud proof window, right? 
Vitalik said that individual users (including exchanges) can set their own fraud protection window according to their preferences. With Stakesure technology, you don’t even need to do this: you can immediately ensure that the deposit is successful, or get compensated (i.e. you will get the same amount no matter what). In the long run, I think we will all adopt ZK, which makes the fraud protection window no longer an issue. 
Kenoe argues that, of course, exchanges can set different fraud prevention windows (perhaps with different amounts based on deposit size). But is there a reasonable middle ground that avoids automatic execution? For example, for large deposits, 6 hours seems quite aggressive given the number of transactions that the validator node must replay, but the user experience also seems quite bad compared to other alternatives. Or use 1 hour instead of 6 hours; still doesn't work.
ZK definitely has long-term promise, but Megaeth has said it will not use ZK on day one due to throughput limitations. I have always believed that, at this point, it is very important for real-world businesses that accept payments to be able to “run a full node” i.e. execute all transactions. I think this is an important point. 
