Thank you Rex for your feedback on writing this and broader education around Etheruem!
Based on feedback from various stakeholders across the Ethereum community, we wanted to draft a short, less technical document on Commit-Boost. We hope this provides a good mental model of where Commit-Boost fits within the Ethereum infrastructure, the risks it is helping to mitigate, and the potential to return autonomy to the 1m+ validators supporting Ethereum! If you are interested in getting involved or have feedback, feel free to send a dm!
Glossary Terms Used Below
Historical Context on Ethereum Blocks
Today, over 90% of blocks in Ethereum are built via validators running an extra piece of software called MEV-Boost. This software allows validators to tap into the proposer builder separation protocol (“PBS”). Putting aside technical details / specifics of how PBS works, this opt-in protocol essentially lets validators outsource block construction. Put another way, with the PBS protocol, instead of validators packing the block themselves, they ask another actor to pack it for them (i.e., block builders). The main driver of adoption is that when validators outsource block construction, they increase the yield generated.
https://lh7-rt.googleusercontent.com/docsz/AD_4nXefjVx1ZoMwIvcNpN3GInqyaT0SA1kz2UG9RMM2b1-E1L0JwtzOXIxvVTRnaUqWNSEn8yjR9SIe5ozc6iStmgKBIqFUKQUpegXw0dCl0FCr5wfAnHXbiGPZy7ulybYZNBq9WorvQWam1foXHl4i7PCEzCqW?key=HrXCEbTFbJFycVhkHtSP9Q
Trade-Off
While PBS has been widely adopted, it has come with some trade-offs. One trade-off that has started to surface is that the software only allows a validator to ask someone to fill their block, and really nothing else. Essentially, when a validator runs this software, even though they have the monopolistic right to pack the block, they commit to delegating this right to the external actor and, along with it, nearly all specifications around how the block is packed. Essentially, the validator loses autonomy over how the block is packed.
This raises the question, is there a way to still allow for delegation from a validator to a block packer, but still put constraints and conditions around how the block is packed? Vitalik, in *The Near and Mid-Term Future of Improving the Ethereum Network's Permissionlessness and Decentralization,* encapsulates this idea by stating: “But [what if] 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.”
What People Started to Realize
Recently, what innovators started to realize is that there could be opportunities with augmenting the current PBS protocol to not only let someone else pack the block but to also give some instructions to that block packer on how it must be packed. In this model, when validators ask someone to fill their block, the block comes with some pre-specified requirements that must be part of the block.
Awesome Idea, But…
Nearly all the teams pursuing this idea were doing it through their own version of a different software that validators would need to run. We started to realize that if we continued down this path, Ethereum validators would have to run multiple pieces of software and core development would be increasingly complicated—introducing a new dimension of fragmentation. To help mitigate these risks, we started to explore whether we could create a new single piece of software that validators can run and still specify requirements that must be in the block. This is the main idea behind Commit-Boost.
Commit-Boost
Commit-Boost is a unifying piece of software that acts as a platform to standardize ****how shapes are signed-off on (i.e., committed to by the validator) to be included in a block. With this platform, validators run one piece of software but get to opt into many shapes to be part of the block.