Parallel EVM: MegaETH

This is a personal note for MegaETH-blog as well as some terminology explained online, e.g., ethereum.org.

In summary, this blog proposes many challenges when designing a high-performance EVM chain, but does not include any design details of MegaETH itself.

1. Blockchain fundamentals

1.1. Conduit chain

• Allows one to deploy a rollup through its Rollups-as-a-service platform within in minutes.

1.2. Gas per second

• Reflects the amount of computation the blockchain can handle per second.
• Different EVM operation costs different gas, e.g., ADD costs 3 gas.
• Block gas limit: ensures that any node can reliably keep up with the rest of the network.

1.3. Target gas per block

• Dynamically regulate the amount of computation a block can include.
• Gas per second = Target Gas per block / Block time.

1.4. Current blockchain scalability

• Throughput: 100MGas/s (\(\approx\) 3700 ERC-20 transfer) cannot compares to Web2 database with >1M transactions per second.
• Capacity: Complex applications cannot be on-chain, e.g., compute large Fibonacci (e.g., \(10^8\)) number would take 55 seconds on opBNB, while in C just 30 milliseconds in a single core.
• Delay: Applications that require fast feedback loop, e.g., high-frequency trading are not feasible with long block times, e.g., 1s.

1.5. Blockchain node hardware requirements

• Lower hardware requirements for full nodes increase decentralization.
• Higher requirements increase performance and security.

1.6. L1 and L2 nodes

• L1 nodes are homogeneous; each node performs identical tasks, i.e., transaction consensus and execution without specialization.
• L2 nodes are heterogeneous; different nodes perform specific tasks, e.g., sequencer node determines the transaction order, prover nodes rely on accelerators to enhance proof generation.

1.7. Verifying a block

• Re-execute the transactions in the block.
• Applying the changes to Ethereum state trie.
• Calculate the new root hash and compare it with the root hash provided by the block.

1.8. Maximum extractable value (MEV)

• Validators maximize their profitability by favorably ordering transactions.

1.9. Proposer-builder separation (PBS)

• Block builders are responsible for creating blocks and offering them to the block proposer in each slot.
• Block proposers cannot see the contents, but simply choose the most profitable one and pay a fee to the block builder before broadcasting the block.
• PBS makes it harder for block builders to censor transactions, and to outperform individuals at MEV extraction.

1.10. Live and historical sync

• Live (online): continuously update a node with the latest data.
• Historical (offline): synchronize a node by downloading the processing data up to a certain point.
• Historical sync has much higher TPS than live sync, e.g., 10x, since historical sync can perform batch processing and does not have network latency.

1.11. Portal Network

• An in-development p2p network for serving historical data where each node stores a small piece of Ethereum’s history.
• Light nodes do not need to trust on full nodes.
• The entire history exists distributed across the network.

1.12. Verkle tree

• Stateless clients rely on a witness that arrives with the block for PoI rather on maintaining own local trie.
• Witness: the minimal set of data that prove the values of the state that are being changed by the transactions in a block.

• Merkle tree is too large to be broadcast between peers; the witness is a path connecting the data from leaved to the root, and to verify the data the hash of all sibling nodes are also required (to compute the parent hash).
• Verkle trees reduce the witness size by shortening the distance between leaves and eliminating the need to provide sibling nodes; Using a polynomial commitment scheme (see Ethereum MPT post for explanation) allows the witness to have a fixed size.

1.13. Node storage

• High disk space is the main barrier to a full node access, due to the need to store large chunks of Ethereum state data to process new transactions.
• Using cheap hard drivers to store old data cannot keep up with new blocks.
• Clients should find new ways to verify transactions without relying on looking up local databases.

1.13.1. History expiry

• Nodes discard state data older than X blocks with weak subjectivity checkpoints, i.e., a genesis block close to the present.
• Nodes can request historical data from peers with Portal Network, e.g., altruistic nodes that are willing to maintain and serve historical achieves, e.g., DAO.
• Does not fundamentally change how Ethereum node handles data.
• Controversial due to it could introduce new censorship risks if centralized organizations are providing historical data.
• EIP-4444 is under active discussion regarding community management.

1.13.2. State expiry

• Remove state from individual nodes if it has not been accessed recently.
• The inactive accounts is not deleted, but stored separately from the active state and can be resurrected.
• A leading approach requires to add timestamps to the account address.
• The responsibility of storing old data may also be moved to centralized providers.

1.13.3. Statelessness

• weak statelessness: only block producers need access to full state data.
• Weak statelessness require Verkle trees and proposer-builder separation.
• strong statelessness: no nodes need access to the full state data.
• In strong statelessness, witnesses are generated by users to declare accounts related to the transaction; not a part of Ethereum’s roadmap.

1.14. Software transactional memory (STM)

• A concurrency control mechanism to control access to shares memory in software.
• A transaction refers to a piece of code executing a series of reads and writes to the shared memory.
• Transactions are isolated; changes made by one transaction are not visible to others until the transaction commits.
• When a conflict is detected, e.g., two transactions try to modify the same memory, one transaction is rolled back.

1.15. Block-STM

• A parallel execution engine to schedule smart contract transactions based on STM.
• Transactions are grouped in blocks, every execution of the block must yield the deterministic and consistent outcome.

3. MegaETH challenges

• State synchronization requires high data compression given limited network bandwidth.
• Updating the hash root requires intensive disk I/O operation, which cannot be well speedup with optimized smart-contract compilers.
• Cannot easily raise block gas limit without properly repricing opcodes that do not benefit from optimized compilation.
• Parallelism is low for long dependency chains.
• The actual user experience highly depend on the infrastructure, e.g., RPC nodes, indexers.
• Support transaction priorities, e.g., critical transactions should be processed without queuing delays.