Agenda

• Understanding upgrades
• Capella (Past)
  • Withdrawals
• Cancun (Present)
  • Proto-danksharding (EIP-4844)
• Electra (Future)
  • Wat do??

Understanding Hard Forks' Naming Convention

• Consensus Layer adopts star names:
  Altair → Bellatrix → Capella → Electra
• Execution Layer goes with cities:
  Paris → Shanghai → Cancun → Prague

Consensus VS Execution Layer

Client Architecture

Capella Highlights

• Epoch: 194048 (April 12, 10:27pm UTC)
• Marked the third consensus layer upgrade
• Featured both full & partial withdrawals
  • Introduced: Automatic account sweeping
• Changes to beacon state's historical data
• Refinement of the fork choice rule in spec

Deneb: What's Coming?

• Epoch: TBD (Expected Q1/2024)
• Data publishing enhancements:
  • Introduction of "Blob" - a new data type
  • Retention on nodes for 18 days
  • Enhancements to scale rollups and related apps that uses short term data
• New: Beacon block root in execution layer
• Cap chain churn and manage validator growth

Gazing at Electra

Post-Deneb: The Road Ahead

Proposing Max EB Increase (EIP-7251)

• Proposal: Enhance validator effective balance to 2048eth (from current default of 32eth)
• Benefits:
  • Potential reduction in p2p bandwidth usage
  • Laying groundwork for future upgrades like ePBS and SSF
• Maintained structures: Rewards, penalties, and queues
• Note: Possible modifications to slashing penalties

Dependencies for Max EB Increase

• Execution layer with triggerable exits (EIP-7002)
• Reusing validator indices (EIP-6974)

Inclusion List Insights (EIP-???)

• Mechanism: Proposer at slot N can mandate txs inclusion at slot N+1
• Requirement: N+1 block must encapsulate txs in state transition
• Advantages:
  • Enhances censorship resistance
  • Paves the way for upgrades, notably ePBS
• Variants to explore:
  • Separate vs. reused block gas limits
• Open Question: Dynamics of the Nash equilibrium?

Delving Deeper: Inclusion List Tradeoffs

• No free lunch – a new inclusion list paradigm
• Cumulative, Non-Expiring Inclusion Strategies
• Fun and games with inclusion lists

ePBS: Challenges and Questions

• Issue: Relayers present complications
• Proposal: Enshrine relayer responsibilities within the protocol
• Questions to address:
  • Will relayers become obsolete?
  • Should builders be staked?
  • Would increasing slot duration from 12s to 16s present issues?

ePBS: Pproposed Design

• Max EB
• Execution layer triggered withdrawal
• Forced inclusion list (own gas limit)
• PTC committee with slot time of 16s
• Getting close to implementations!
  • Beacon chain spec, fork choice spec
  • Network spec, validator spec, builder spec
  • Execution API
• Running into hard problem like validator transfer attack but we'll get there soon!

General Enhancements: Fork Choice

• Late block reorg (as seen in LH & Prysm)
• Update to (block, slot) voting
• Initiatives like Goldfish and view merge
• RLMD-GHOST (Recent Latest Message Driven GHOST)
• Balancing act between:
  • Economic security
  • Committee size and P2P constraints
  • The necessity of an additional voting round

Deep Dive: RLMD-GHOST

• Exploring Single Slot Finality
• A Journey into Streamlined Fast Finality

Reimagining Validator Economics

• Current Scenario: An unbounded validator set
• Pondering: Is there an optimized reward/penalty curve if the majority of ETH is staked?
• Interactions with LST?
• Implications for upgrades such as SSF?

SSLE Advancements (EIP-7441)

• Transition block proposer election to Whisk algorithm
• Benefits: Known proposer assignments in advance. Mitigation against sequential DoS attacks (MEV)
• Implementation:
  • Register tracks and unique commitments
  • Shuffle based on both public and private randomness
  • Conclude w/ an ordered list of proposers, selected by RANDAO

EIP4844+: What's New?

• Elevate blob sidecar count from 3 to 6
• Testing phases for erasure codes and blob reconstruction
• Introducing a new, opt-in sampling network
  • Compatibility: Fully backwards integrated
  • Avenues to explore with different node types: High capacity nodes and super full nodes
• Utilizing the mainnet as a sandbox

DAS

• Data restructuring: Rows and columns
• Sampling strategy: Each node samples select points
• Prerequisite: Robust erasure coding
• Considering additional fork choice dynamics
• Advantage: Enhanced data throughput capabilities
• Reference: PeerDAS - A Simplified Approach

Addressing Technical Debts

• Potentially a divisive perspective
• Proposing a feature-free interval to:
  • Rectify technical debts
  • Elevate code quality standards
• Championing long-term platform stability
• Multitasking complexities (working on new features and cleaning up old debt is hard!)

Visualizing Technical Debts

My Roadmap

• Immediate Focus: Ensure Electra's consensus stability
  • Prioritize Max EB, Inclusion list, and Fork choice enhancements
• Long-term Vision: Features for the "D" star-named fork
  • Emphasizing ePBS and Danksharding

Thank you EthChicago 🙏

@terencechain