Ethereum Guild 2025-02 (March 19, 2025): Decoupled execution payload vs. ePBS, based rollups & PBS block building

[philknows]

When: March 19, 2025, 14:00-15:00 UTC
Meeting Link: https://meet.google.com/qyr-jbxu-ack
Or dial: ‪(CA) +1 613-778-6074‬ PIN: ‪505 036 482‬#
More phone numbers: https://tel.meet/qyr-jbxu-ack?pin=2400478359747

Topics for Discussion:

• Decoupling the execution payload from beacon blocks and its effect with ePBS (Enshrined proposer builder separation).

  • Reading: Add EIP: Uncouple execution payload from beacon block by g11tech

• Contiuation of Based rollups + PBS block building / Deterministic ordering

  • Refer to Ethereum Guild 2025-01: Ethereum Guild 2025-01 (January 15, 2025): Layer 2s and Security Models #7332
    • https://drive.google.com/drive/folders/1564KSapditvPiuo7sQt5Gl1cQezFAFSj?usp=drive_link

Please add to this thread or edit this post to include additional material to build context before attending the guild meeting. Additional topics, questions, or discussion points are welcome!

[philknows]

Recording/Transcript: https://drive.google.com/drive/folders/1N8qsKxeaTS5vappOGpQtsq-b8jIQoo25?usp=sharing

Summary:

Ethereum Guild Meeting Summary: Decoupled Execution Payload vs. EPBS and Future Ethereum Developments

This summary outlines key discussions from the Ethereum Guild meeting held on March 19, 2025, focusing on protocol development proposals, particularly regarding decoupled execution payloads, EPBS (Execution Payload Block Structure), and broader strategic considerations for Ethereum's development roadmap. The meeting featured significant technical deliberations on simplifying Ethereum's architecture while maintaining security and performance, comparing different approaches to protocol upgrades, and addressing challenges in development coordination and prioritization.

Decoupled Execution Payload Proposal

Core Concept and Motivation

Gajinder Singh presented a detailed explanation of an EIP proposal centered on uncoupling the execution payload from the beacon block in Ethereum's architecture. This approach aims to address several challenges:

1. Accommodating increased gas limits (potentially up to 100 million) and consequently larger block sizes
2. Improving client efficiency and scalability
3. Reducing bandwidth requirements during synchronization
4. Simplifying merkleization processes

Singh explained that the execution payload was initially introduced during the Bellatrix fork, embedding transaction data into beacon blocks. As Ethereum seeks to scale with higher gas limits, especially post-Pectra, the size of execution payloads will grow substantially – potentially equivalent to 6-7 blobs on average.

Simplified Decoupling vs. EPBS

The discussion contrasted two approaches to handling execution payloads:

1. Simplified Decoupling (Proposed EIP):

   • Uncouples execution payload from beacon blocks
   • Maintains immediate data availability
   • Preserves existing fork choice rules
   • Transmits execution payload independently over gossip channels
   • Replaces execution payload with execution payload header (containing transaction root instead of transactions)

2. EPBS (Execution Payload Block Structure):

   • More complex approach that also decouples execution payload
   • Delays data availability to the next block
   • Introduces a new committee (payload timeliness committee)
   • Changes fork choice rules
   • Originally intended to solve trustless interactions between builder and proposer

Singh argued that the simplified approach offers many benefits without the added complexity of EPBS, making it potentially easier to implement and integrate.

Benefits of Decoupling

The decoupling approach provides several advantages:

1. Improved CL Client Efficiency: By removing the need for consensus layer clients to deal with transaction merkleization
2. Reduced Bandwidth During Sync: Particularly beneficial during optimistic synchronization
3. Simplified Merkleization: Making the process cheaper and less resource-intensive
4. Future Compatibility: Potential for ZK-proof verification of payloads without needing full execution payload

Delayed Execution and Implementation Options

Relationship to Decoupling

An important thread in the discussion was whether decoupling needs to be coupled with delayed execution. Nico Flaig questioned whether decoupling alone provides substantial benefits:

Nico Flaig: "Your proposal needs to be coupled with something like delayed execution EIP, right? Otherwise, you don't really get that much benefits right now."

Singh clarified that while decoupling can stand alone and provide benefits independently, particularly for CL client efficiency and scaling gas limits, combining it with delayed execution would provide "the best of both worlds".

He explained that delayed execution changes the interpretation of execution requests to refer to the parent block rather than the current block, allowing for static validation without changing the validity of the beacon block.

Ethereum Upgrade Strategy and Coordination

Fusaka and Future Upgrades

Phil Ngo suggested that the simplified decoupling proposal could serve as an alternative for the Fusaka upgrade, potentially replacing the more complex EPBS approach. This led to a broader discussion about Ethereum's upgrade strategy.

The group reflected on lessons learned from the Electra upgrade, where attempting to include too many proposals simultaneously led to complications.

Maintenance Fork Concept

A significant strategic discussion centered around the potential for implementing two yearly forks:

1. A feature-focused fork for major upgrades
2. A maintenance fork for technical improvements and debt reduction

Gajinder Singh: "We should always push these small small EIPs along with big features because small EIPs will keep getting accumulated and then you will say that okay we have to have a maintenance fork and maintenance fork no one is going to buy."

Participants noted that this two-fork approach could reduce pressure to include too many changes in a single upgrade, allowing for better focus and preventing technical debt accumulation. Peter Kalambet mentioned that the sentiment for two forks per year is "super strong" among some Ethereum developers.

Competing Narratives and Coordination Challenges

Vision and Direction Challenges

The group discussed how Ethereum faces both coordination problems and vision challenges:

Gajinder Singh: "There is both a coordination problem as you said and then there is also a vision problem because coordination is easier when you have a coherent vision."

Singh noted that Ethereum's growth has led to competing directional pulls: scaling L1, pushing the L2 ecosystem with native rollups, or enhancing EVM capabilities. External factors like Solana's growth have created pressure to focus on L1 execution performance.

The Role of Leadership

The discussion touched on the role of leadership in setting direction, with Matthew Keil suggesting the need for a "benevolent dictator" to "corral the narrative." The group acknowledged Vitalik Buterin's influence but noted that even Vitalik is "excited by so many ideas" and "pulled in different directions".

The Beam Proposal and Long-term Strategy

Beam as a New Paradigm

The conversation included a substantial discussion of the "Beam" proposal:

1. Presented as a new consensus stack for Ethereum
2. Addresses post-quantum security concerns
3. Bundles multiple important features into a cohesive system
4. Represents a clean-slate approach rather than incremental changes[1]

Cayman Nava: "It's very important that we go on a ZK we go full ZK because that's just the future of technology but it's also important that we can scale blobs in the short term because if we don't then like the whole L2 narrative is not real."

Trade-offs and Considerations

The group debated the merits of starting fresh versus continuing to build on the existing system:

• Cayman Nava highlighted that designing "a coherent system from scratch" is easier than piecemeal changes to the beacon node
• Matthew Keil noted concerns about competing narratives and focus dilution
• The quantum computing threat timeline was discussed, with estimations ranging from 2-5 years

Parallel Chain Proposal

Alternative Deployment Strategy

The discussion also covered a more radical proposal to launch parallel chains rather than using forks for upgrades:

Gajinder Singh: "In fact Mikhail actually proposed that but instead of having forks what should happen is a new blockchain should be launched and same liquidity should be shared with that blockchain."

The concept involves:

1. Launching a new version of the blockchain
2. Allowing users to shift liquidity between versions
3. Eventually deprecating the previous version after the new one matures
4. Unifying liquidity across versions

Security Concerns

This approach met with significant skepticism, particularly from Cayman Nava:

Cayman Nava: "We get our security from our combined stake and if you are splitting stake across different like the consensus engine is coming to consensus on one thing not on two things or on multiple versions of things."

The group generally preferred the existing fork mechanism, noting that splitting stake compromises security unnecessarily.

Consensus Engine Testing Requirements

The meeting also touched on whether testing a new consensus engine like Beam requires a full execution client environment:

• Gajinder Singh argued that the execution model hasn't significantly changed since the merge
• Cayman Nava countered that a testnet could sufficiently test the consensus engine without needing the full execution client environment, similar to the Holesky testnet approach

Conclusion and Next Steps

The meeting concluded with Philip Ngo suggesting that the discussion continue asynchronously to define the outlook for Fusaka, which would help prioritize features for future releases, specifically Glamsterdam.

Overall, the meeting reflected the complex technical and strategic considerations facing Ethereum development, highlighting tensions between competing approaches and the challenges of coordinating a decentralized development ecosystem while maintaining focus on the most critical priorities.