2 of 12

Agenda

Introduction
Expanding the Infinite Garden of Ethereum
Potential challenges with the current direction
Introduction to Commit-Boost
Design principles / Key Questions
Boxes and arrows
Open questions and timeline

3 of 12

Expanding the Infinite Garden of Ethereum

“…proposer creates the specs, or the template, by which the resulting block must be created, and the builders engaged by the proposer are tasked with delivering the block according to its specifications” ~ Barnabe, More Pictures About Proposers and Builders
“…to provide input into block production, even when they decide to delegate building.” ~ Julian, Uncrowdable Inclusion Lists: The Tension between Chain Neutrality, Preconfirmations and Proposer Commitments
“But we can make a philosophical shift in how we think about inclusion lists: think of the inclusion list as being the block, and think of the builder's role as being an off-to-the-side function of adding a few transactions to collect MEV.” ~ Vitalik, The near and mid-term future of improving the Ethereum network's permissionlessness and decentralization

4 of 12

Potential Examples - Countless Others

Proposer Commitments

Blockspace Futures

Preconfirms

Partial Block Auctions

PBS

Inclusion Lists

🤠

5 of 12

Massive Unlock for Ethereum, however…

On the surface this all seems great and is an incredibly exciting development–but, in the undercurrents we are potentially on a perilous path if we can’t agree on a standard of how proposers register / send / receive commitments.

Undercurrents

Fragmentation: Multiple software and standards could compromise the security integrity of the entire Ethereum network

Development Complexity: If there is no standard, it could exponentially inflate the burden on core developers tasked with executing / testing major network upgrades

Transparency: With multiple software and standards, transparency around bugs and taking quick actions may be challenging

6 of 12

TL;DR – Introducing Commit-Boost

Mission: Not-for-profit, community driven, and an open-source, public good
Product: Validator platform for proposer commitments
Neutrality: Proposer commitment agnostic, preconf agnostic, restaking agnostic, relay agnostic, transaction flow agnostic
Unified: Validators run one core side car to opt into many different commitments
Safety: Community reviews / audits, modularized, increased transparency–the focus is to reduce risk / overhead for the proposer to manage commitments

7 of 12

Design Principles

Open source / open development: Developed in the open and under open source licensing

Safety: Thoroughly tested and audited, with full backwards compatibility with previous clients

Modularity: Allow developers and protocol teams to easily test, iterate, and deploy new protocols and software for proposer commitments without needing to implement everything from scratch

Transparency: Provide open access and good documentations to allow maximal verifiability and ease of integration

Optionality: Ensure that the final design does not limit innovation or ossify certain downstream stakeholders / proposer commitments

Observability: Allow node operators to collect and quickly analyze detailed telemetry about sidecar services

8 of 12

Open Questions

Added risks: Can we design Commit-Boost in a way it reduces risks around proposer commitments
Standardization is not always good: Does Commit-Boost enforce too much standardization that innovation can’t flourish
Centralization: Can Commit-Boost help to enable at-home stakers or geographical dispersion of validators to improve decentralization
Challenges with the current design: This was just the first iteration of the design, keen to get feedback

Would Vitalik run this and can we use this to actually increase decentralization / censorship of Ethereum?

9 of 12

Commit-Boost: Current Thinking of High-Level Design

10 of 12

Commit-Boost: Current Thinking of High-Level Design

11 of 12

Timeline for CB

May 9

ETH Research Post

June 12

ZuBerlin

July 8 - 12

EthCC

End of Q3

June 6

Call 10

Q4 - onward

Increase Adoption

CB Mainnet

CB Workshop

Devnet / Workshop

*Timeline based on Justin’s proposal on call #7

1 of 12