Researcher
Related Projects
MegaETH aims to separate execution from consensus entirely to eliminate phenomena where execution results are delayed by consensus, and chose L2 design to implement this. (Note: While there are various opinions on the definition of L2 chains, I consider all chains that submit states to Ethereum in some way (rollups / validium / optimium) to be L2.)
Currently, most L2s have sequencers perform most operations. The sequencer is responsible for bundling transactions into blocks, submitting constructed blocks to the network through broadcasting, and generating proofs to submit to Ethereum to verify that transactions were executed correctly. This series of processes is often implemented serially, causing the slowest operation to act as a bottleneck for sequencer processing speed.
MegaETH chose a structure that delegates work concentrated on sequencers to separate nodes with optimized hardware, allowing sequencers to focus on block generation. MegaETH consists of four types of nodes and light clients:
Sequencer Node: Like sequencers of other Layer 2 chains, it receives transactions from users and generates blocks. The sequencer node consists of high-performance servers requiring CPUs with over 100 cores, 1-4TB of RAM, and network connections of 10Gbps or higher. The sequencer stores the entire EVM state and state trie in memory using overwhelming RAM capacity and propagates the state diffs to replica nodes.
Prover Nodes: Nodes that generate proofs for transaction verification. They utilize specialized hardware such as GPUs, FPGAs, or ASICs to generate proofs for sequencer execution results.
Full Nodes: Responsible for complete state verification and storage. They store the entire blockchain state and re-execute all transactions to ensure data integrity.
Replica Nodes: Receive state diff from sequencer nodes and update state values in local environments. They verify states like full nodes but don't re-execute entire transactions like full nodes, instead relying on proofs generated by prover nodes to verify the validity of state increments received from sequencers.
Light Clients: Receive and store the latest state from replica nodes and full nodes, providing it to users. Mainly operated by application providers.
