Introducing Commit-Boost to the Lido Community

Commit-Boost: Lido Operator Platform to Safely Make Commitments

The following post is an introduction to some and an update to others in the Lido Community on an effort called Commit-Boost. Commit-Boost is keen to engage with the Lido Community for eventual consideration to the Lido Alliance, but initially the Community in feedback / research / design / testing. We believe the mission and structure of Commit-Boost directly align with the desired infrastructure and the values that the Lido Community holds and has communicated over the last few years. Thank you and we welcome your feedback.

Resources

  • Commit-Boost Repo
  • Commit-Boost documentation
  • List of presentations
  • Original post on ETH Research, read more here
  • Second post on ETH Research, read more here
  • First presentation to the community can be found here
  • Second presentation at zuBerlin can be found here
  • zuBerlin Devnet notion can be found here
  • Mev-Boost Community call here

Proposal

  • Due to the risks developing for Ethereum, core development, and its validator set, a group of teams / individuals are working on developing a public good called Commit-Boost
  • Commit-Boost is an open-source public good that is fully compatible with MEV-Boost but acts as a light-weight validator platform for all stakers (helping to support decentralization of Ethereum’s validator set) to safely make commitments / perform validator services
  • Specifically, Commit-Boost is a new Ethereum validator sidecar that is focused on standardizing the last mile of communication between validators and validator services
  • To reduce risks to validators, Commit-Boost has been designed with safety and modularity at its core. Commit-Boost has off-the-shelf monitoring and proactive tools to identify risks, limit the impact of bugs, and proactively alert teams when / if issues develop from opted-into validator services
  • While Commit-Boost’s first use cases are commitments like preconfs, Commit-Boost is maximally neutral and does not limit innovation across the proposer commitment design space. It is proposer commitment agnostic, relay agnostic, transaction flow agnostic, commitment enforcement agnostic, etc. Nothing about Commit-Boost will limit stETH’s ability to be the #1 collateral in the restaking market
  • Commit-Boost is working with client teams, consultants, researchers, validators (including home stakers and sophisticated stakers), testing with operators in Holesky, helped stand-up devnets and persistent testnets for fast iteration, have a significant portion of the preconf teams already building modules on Commit-Boost, and been engaged with teams across the community who are eager to develop other validator services such as inclusion lists. To ensure Commit-Boost fits the needs of the Lido Community, we are keen to continue to expand this iteration / testing / feedback loop with the Lido Community, apply for a grant from the LidoDAO, and eventual consideration to be part of the Alliance
  • In the design, development, sustainment, and governance around Commit-Boost, we have tried to embrace the values of the Lido Community and previously voiced by the broader community

Background and What Risks Commit-Boost Addresses

  • Similar to the call to actions outlined in ReGoose around validator services, most are starting to agree on a common denominator: in the future, beacon proposers will be presented with a broader set of options of what they may “commit" to–be it inclusions lists or preconfs or other types of commitments such as long-dated blockspace futures–compared to just an external or local payload they see today
  • A post from Barnabe captures this well; during block construction, the validator “…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”
  • While this all seems great, the challenge is that many teams building commitments are creating new sidecars driving fragmentation and risks for Ethereum and the Lido operator set
  • For Ethereum, there are going to be significant challenges and increased risks during upgrades if there are a handful of sidecars that validators are running
  • For validators, these risks potentially take us to a world where proposers will need to make decisions on which teams to “bet on” and which sidecars they will need to run to participate in what those teams are offering
  • For homestakers, this is difficult and they likely will be unable to participate in more than one of these commitments
  • For sophisticated actors, this increases the attack vector and operational complexity as more and more sidecars are required to be run
  • Another side effect of this is validators are somewhat locked into using a specific sidecar due to limited operational capacity and the switching costs of running a different sidecar (i.e., vendor lock-in). The higher the switching costs, the more embedded network effects could become if these sidecars only support certain downstream actors / proposer commitment protocols
  • This also could create a dynamic where core out-of-protocol infrastructure supporting Ethereum which should be a public good, starts being used for monetization, distribution, or other purposes

Commit-Boost Overview

Commit-Boost is a community-driven, open-source project developing an unopinionated validator platform to enable safe interactions with commitments. Some of its features include:

  • Unification: Core devs will be able to interact and work with one standard during Ethereum forks / upgrades / when and if things go wrong
  • Backward compatibility + more: Commit-Boost is not only backward compatible with MEV-Boost, but will improve the life of Lido operators who only run MEV-Boost through increased reporting, telemetry / other off-the-shelf tools validators can employ
  • Opt-in without running more sidecars: Commit-Boost will allow proposers who want to opt into other commitments to do so without having to run multiple sidecars
  • Tools and features to help reduce risks for Lido’s operator set: In the spirit of ReGOOSE, Commit-Boost is specifically designed with off-the-shelf monitoring and proactive tools to identify risks, limit the impact of bugs, and proactively alert teams of issues that may develop from validator services
  • Robust support: Commit-Boost the software is supported by a not-for-profit entity. This team will be focused on security and robustness through policies and procedures with follow-the-sun type models where there is support 24/7 if / when things go wrong. This team will also be focused on testing and adjustments needed during hard forks and have a team to interact with to help during adoption, improvements, and sustainment
  • Additional revenue: As part of the open innovation that Commit-Boost enables, potential validator services will continue to come online, to capture new revenue opportunities when making commitments
  • Not VC-backed Public Good: This team and effort will not be VC-backed. There is no monetization plan. The entity will not sell itself and will not start any monetizable side businesses. As an example, the team is actively working on a grant application to the Lido Community, among other organizations across Ethereum

Technical Roadmap

As noted in the Proposal section above, Commit-Boost is already live with an MVP product and heavily engaged with the broader community. We are continuing the development and feature set of Commit-Boost / onboarding new modules and targeting production-ready software and audits kicking off at the end of Q3. More details on the current roadmap are in the Commit-Boost repo and we are keen to get feedback from the Lido Community to prioritize and design features that would be required.

Some near-term high-level highlights from the roadmap include:

  • Optimized and functional MEV-Boost module including multiple metrics for reporting and extensions such as configurable timing for get_header / get_payload calls
  • Pre-made dashboards on Grafana for all core services
  • Improved reliability and integrations for incident response
  • R&D / spec signing mechanism to fit as many validator set-ups as possible
  • Expanding modularity and optionality (i.e., supporting different types of signatures and modules)

From the perspective of a Lido Operator

More details on what it takes to run Commit-Boost as a node operator can be found here. Please note that this has not been finalized and over the next few weeks we will be making updates (see roadmap / milestones above):

  • The Commit-Boost client is a single sidecar that acts as a platform to interact with proposer commitment protocols
  • Do not need to run multiple sidecars for new commitments
  • Not backing one team building proposer commitment protocols letting open innovation happen at the protocol layer with low barriers for switching costs between commitment protocols for the Lido Operator
  • No risk of monetization at the sidecar layer. Commit-Boost is a public good supported by a not-for-profit team focused solely on robust support, continued development, and sustainment of Commit-Boost
  • Standardized way to provide a signature / opt into a commitment
  • Helps monitor key attributes around that signature
  • Creates constraints / condition sets and pass these constraints downstream
  • Get insight into telemetry around the commitment flow and validator box that can be seen through dashboards such as a - Grafana
  • Create bespoke process management logic to ensure safety when making commitments

From the Perspective of the Proposer Commitment Protocol

More details on what it takes to build a module / metrics can be found here. Please note that this has not been finalized and over the next few weeks we will finalize moving parts that impact module creators (see roadmap / milestones above):

  • A modular platform to develop and distribute proposer commitments protocols
  • A single API to interact with validators
  • Support for hard-forks and new protocol requirements

Commit-Boost Design Principles

  • Built for validators: Platform that not only can help validators today (i.e., can improve the lives of validators even if they just run an MEV-Boost module) but allows validators to be ready for the market of tomorrow (i.e., preconfs, inclusion lists, etc)
  • Neutrality: No opinions, the platform will be proposer commitment agnostic, relay agnostic, transaction flow agnostic, etc. The goal is to build a platform that doesn’t limit the design space downstream while reducing risks of fragmentation for validators and Ethereum
  • Unified: Validators run one core sidecar with the ability to opt into many different commitments
  • Safety: Open-source code developed with input by the community with community reviews / audits
  • Reduce risks: Modularized and transparency are core to reducing risk / overhead for the proposer to manage commitments and their broader operational processes
  • Values aligned: Public good with no plans for monetization. We will continuously ask ourselves: would Vitalik run Commit-Boost and can this be designed in a way to increase the decentralization of Ethereum block construction

Architecture of Commit-Boost

More details can be found in the Commit-Boost documentation. However, below is a schematic of Commit-Boost. It is important to note that the below depiction contains just a few examples of proposer commitment modules that can run on Commit-Boost. The design space for modules is completely open / not gated by the Commit-Boost software and proposers will be responsible for opting into the commitments they wish to subscribe to (i.e., a proposer is responsible for which modules they will subscribe to).

Terminology

  • Proposer: entity, staking pool NoOp (i.e., Lido), or DVT cluster with the right to propose the next block
  • Commitment: a constraint or condition that the proposer choses and agrees to via a signature
  • Key Manager: some proposers use key managers or remote signers as part of their proposer / validator duties. Please note, that Commit-Boost is being designed in a way where it does not require validators to run key managers and working on solutions for monolithic set-ups
  • Consensus Client: for example, Lighthouse or Teku (see here for more details)
  • Commitment Modules: community-built modules allowing proposers to make commitments, including some of the logic of the proposer commitment protocol

Signer API: The signer API is one of the core components around Commit-Boost. This is used to provide signatures from the proposer to the proposer commitment protocol. This is still in the design but proxy signatures will be used in nearly all cases (there are some outlier cases). For more details on the API please see here. For an example of how to communicate with the Signer API, please see here.

Using this as a middleware instead of direct modification to the consensus client or running a sidecar per commitment will allow for each component to be sustained independently and will provide for cross-proposer commitment compatibility. This will also allow for a bit of time for the market to play out, but via a public good, standardize the last mile of communication to help address the risks (discussed in the background section above) developing. Once the market does play out, and the community can observe some dynamics (the good and the bad), we can and should push for CL changes.

Robustness, Sustainability, and Security

  • Commit-Boost is being developed as a fully open-source project with contributions from teams across the Ethereum tech stack including validators, client teams, relays, builders, consulting firms, researchers, and many others. This effort with input and support from these teams will help develop a robust product integrating many perspectives
  • Commit-Boost will go through code reviews and audits once fully developed
  • As noted below, there also will be a full-time team that helps maintain and upgrade the software with their core focus on 100% uptime and when there are bugs, robust processes to quickly address and fix
  • The software stack is also built with the validator at the core and includes off-the-shelf tools for monitoring as well as reducing and proactively addressing any risks that may arise
  • Last, this public good software will have minimal, but critical open governance around future upgrades with input across the Ethereum

Team Supporting / Governance of Commit-Boost Software

  • Entity supporting the software: Not-for-profit entity
  • Multiple-person team: Multiple devs that fully focus on transparency, sustainment / development, and research with an initial focus around Commit-Boost the software. Based on initial research we suspect this will cost $1m - $2m / year. This funding will largely be related to developer resources.
    • Transparency: Open-source repo and governance calls (see below)
    • Sustainment / Development: 24/7 follow-the-sun coverage and highly engaged with client teams around upgrades / early in getting testnet support
    • Research: Helping with and being a resource for open-source research across the Ethereum staking roadmap
  • Governance: This is still a WIP, but at a minimum will run a Commit-Boost, ACD-like calls (first one coming soon) to engage with stakeholders (would be great to have folks from the Lido Community involved) and drive consensus on upgrades / help coordinate around hard forks. A credibly neutral community member will lead these calls / this process and has experience with running governance processes over critical software within the Ethereum community

Reducing risks for Ethereum and the Lido Community

We are excited to present this effort to the Lido Community and believe the structure, design, and goals directly address key risks developing within Ethereum and for validators. We also see that it not only aligns with the Lido Community but also of the broader Ethereum community. We are excited with the opportunity to potentially be part of and directly work with the Lido Community to support a neutral platform.

We look forward to feedback and engagement from the Lido Community and their consideration of this proposal. After feedback and engagement with the Lido Community we plan to apply and be considered for a grant from the LidoDAO as well as consideration for the Alliance.

7 Likes

Great initiative!

Quick note that Lido NOs running Vouch can’t use this, as Vouch must be the relay of relays. Recommend working with Jim McD at Attestant on design when using Vouch and offering a PR to Vouch to enable such functionality - it’s just Jim maintaining Vouch, Dirk and ethdo after all.

2 Likes

We are testing commit-boost on holesky currently and we appreciate the concept + team!
We will let you know here how the testing goes🤝

3 Likes

Thank you, Thorsten, for the support and comment! Yes, we are speaking with Jim and team and also bounced the original design off him starting a few months ago. We’ll make sure to update the community when this is ready.

1 Like

We have continued to progress on this effort and are at a place to start engaging with more Lido NO’s. Teams can find more details around the request for testing in the link below.

3 Likes

Quick update here: We are very excited to share that we now support Vouch. Teams can see our documentation page for more details!

1 Like