- Marius Van Der Wijden suggests innovative L2 designs to boost Ethereum’s speed and efficiency without compromising security.
- He advocates for streamlined state management, where key nodes handle the full state, reducing data overhead significantly.
- By simplifying receipts and enhancing transaction access lists, Van Der Wijden envisions a more efficient transaction process on Ethereum L2.
Marius Van Der Wijden recently outlined his design ideas for a high throughput Layer 2 (L2) solution on Ethereum. He explained how these choices contrast with mainnet operations. He emphasized the need for efficiency and speed while addressing the challenges of current Ethereum scalability. The conversation focused on several technical aspects that could enhance performance without sacrificing security.
I recently wrote down some ideas on how to build a high throughput L2. Some of the design decisions I would take (and that I suspect other rollups take as well) and why they can’t be done on mainnet #Ethereum.
Check it out: https://t.co/RjjdCHZCJ6
— MariusVanDerWijden (@vdWijden) November 3, 2024
Streamlined State Management
During the syncing process, Van Der Wijden explained that a syncing client requests account ranges. The system provides proofs for the first and last accounts, ensuring data integrity. This process allows verification against the state root.
Additionally, he introduced the concept of “moving the pivot” to accommodate ongoing chain developments. After syncing, the state must “heal,” unifying different states in memory. This healing process involves verifying which states remain correct based on the latest state root.
Significantly, he noted that not all nodes would maintain a full state. Instead, the sequencer, RPC providers, and fraud provers would manage it. They could replay the chain from Genesis or use a state disk copied from another node. This approach streamlines state management, reducing overhead.
Simplified Receipts and Logs
Van Der Wijden also proposed changes to transaction receipts. Currently, receipts consume considerable storage space. They provide transaction success confirmations and gas usage data. However, he believes many of these functionalities are underutilized. Instead, auxiliary services could collect and store logs, allowing users to query them efficiently.
Moreover, he mentioned the challenge of parallelizing computation. Current methods often struggle with identifying conflicting transactions. However, by mandating access lists, transaction senders would specify which accounts their transactions touch. This requirement could enhance transaction efficiency.
Furthermore, the sequencer could rely on centralized RPC nodes. These nodes would validate transactions before forwarding them, minimizing the sequencer’s workload. Consequently, this approach might improve overall performance and scalability.
