Chenyo's org-static-blog

Posts tagged "megaeth":

04 Jul 2024

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

rkHVB0iHR.png
Figure 1: 2024 blockchain scalability comparison
  • 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.

2. What is MagaETH

  • An EVM-compatible L2 blockchain with Web2-level real-time processing and publishing, i.e., millisecond-level response times under heavy load.
  • Main idea: delegate security and censorship resistance to base layers, e.g., Ethereum to make room for L2 optimization.

2.1. Node specialization

  • sequencer: only one active sequencer at any time to eliminate the consensus overhead.
  • full node: receive state diff from the sequencer via a p2p network and apply the diffs to update local states; don’t re-execute transactions, only validates the block indirectly using proofs provided by the provers.
  • provers: validate the block asynchronously using the stateless validation scheme.
  • Endgame, Vitalik 2021: Node specialization ensures trustless and high decentralized block validation (more provers), even though block production becomes more centralized (one sequencer).

2.2. Design philosophy

  • Reth (Rust implementation of the Ethereum protocol) is bottlenecked by the MPT update in a live sync setup, even with a powerful sequencer.
  • Measure, then build: first get insights from real problems, then design techniques to address all problems simultaneously.
  • Prefer clean-slate, as addressing any bottleneck in isolation rarely results in significant end-to-end performance improvement.

3. MegaETH challenges

BJW2EG4L0.png
Figure 2: A transaction life-cycle.
  • 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.
Tags: evm parallel-evm megaeth
Other posts