(Also posting this much later than I was hoping to, great minds @timbeiko )
For those of you that haven’t met us, we (myself and Collin Myers) are the Founders of Obol. We have been researching and working on different pieces of PoS Ethereum since 2018. Today, we are focused on scaling and protecting the consensus layer with DVT.
Obol is building a middleware implementation of Distributed Validator Technology, the primitive that enables multi-operator Ethereum validators. For the past 18 months, we have been working with the client teams and flashbots to support all validator clients and mev-boost with our middleware. We are also a member of the Flashbots Eth2 working group.
We are surfacing in this thread to both weigh in with thoughts, but more importantly to make an offer of support.
The tl;dr is; we are a team of 15, with venture capital, and the means to support and continue the development and progressive decentralization of mev-boost for the foreseeable future, and this post is us throwing our proverbial hat in the ring to take on an accountable role in the stewardship and further development of the mev-boost client.
The Next Frontier
Ethereum is entering its next chapter of growth, which comes with intense growth efforts intertwined with decentralization efforts.
Over the past ~24 months the Ethereum infrastructure industry has been preparing for a market of middleware protocols. Through experimentation and collective design decisions we have enabled middlewares to be additive to the core client options and not competitive. However, this has resulted in a separate coordination layer (or lack thereof) detached from the work of the core client teams/ACD. This is difficult given the overlap of responsibilities.
These additive middlewares enable advanced features for core network participants (validators, builders, relayers etc.) while providing advanced protection for users of the Ethereum mainnet. A mutually beneficial relationship between core software and ancillary software is what is needed to pave our next chapter of scaling.
In today’s context we have two things happening:
- We are collectively searching for a decentralization framework for widely used middleware protocols on PoS Ethereum (builder-api)
- We are attempting to decentralize the development of our first majority run middleware client (mev-boost).
It is critical as a community that we discuss the on-going design, management, coordination, and incentive models of this new layer in a broad context as well as in the context of Flashbots.
Today the middleware market can be divided up quite simply:
- Execution Middlewares
- Exists to offer you extra rewards
- On Mainnet
- Consensus Middlewares
- Exists to protect the largest network reward (consensus)
- On Testnet
- Exists to allow other middlewares to add crypto-economic security without bootstrapping that security from 0.
- In development
- I’m not sure what language it’s being written in.
Today these middlewares are operating mostly in isolation, and have only begun to operate together on testnets (please see below).
Today there is only one middleware that matters (mev-boost), however tomorrow we envision a collection of different middlewares that run in the majority of network stake in one way or another. In addition to an increase in the total number of middlewares available to network participants, we will also see a number of cross-middleware combinations being run on mainnet.
Eventually we will reach a state of standardization such that users can run multiple middlewares at the same time, in a secure manner. From our experience, in this middleware value chain, core protocols such as mev-boost and Obol will be required to build closely as the overlap in user groups is substantial (hence this post). On the Obol side we have already begun to test distributed validators that can propose blinded beacon blocks. We expect to see a new field of research develop focused on MEV and its impact on multi-operator validators.
Today is a great time to get in front of this on-going problem and establish some sort of framework before the middleware market explodes with growth.
To touch on some of the suggestions highlighted in this thread, here are my thoughts:
I would also discourage moving towards an EIP style process for feature addition, I think that can make sense when there are multiple builder-api clients and specs are more ossified, but in the near term, I think encouraging an involved group of core devs fleshing out the client collaboratively is a more fluid and flexible paradigm for the near-term. This ties directly to my following point on where a client ends and a spec begins.
As for the debate between building a client or building a spec, this is somewhere I probably lack perspective, so I will defer to the likes of @lightclient. I will say though at Obol we are currently walking a similar road, of wondering when is too soon to formalize the protocol and direct our focus primarily on a canonical spec, and when is too late. My gut feeling/bias is that you shouldn’t move to a spec until the development of a reference implementation starts to stabilize and plateau. I think this bias is based on my belief that DVT performance will continue to improve over the near term, so I have been reticent to formalize charon’s operation into a spec until we approach some of the theoretical lower-bounds of communication rounds to form distributed consensus, rather than ossifying a relatively naïve implementation.
I’m strongly aligned with the general consensus that things don’t/shouldn’t progress up the systemic importance levels until ACD has to step in to steward it and protect the base protocol. That is neither decentralized nor scalable. I believe ACD and the EL and CL teams should continue to strengthen and broaden their APIs, and that a plethora of software will flourish on top of these APIs. I believe this is consistent with the “middleware renaissance” described by the likes of Obol, Flashbots, and Eigenlayer. If Ethereum development is to be alive and thriving 20 years from now, in my eyes the development at that point will be on top of a foundation of standardized APIs, implemented by a number of client teams.
Finally to conclude with some concrete suggestions:
- We as Obol would be open to stepping into a stewardship role for the mev-boost repo, sharing accountability for reviewing PRs and standing over what gets merged to main.
- We as Obol are keen to develop and improve mev-boost, particularly with respect to enabling distributed validators to extract MEV. Our first potential feature addition would be to make it easier for distributed validators to register with relayers effectively. Currently, due to the inclusion of a timestamp in the signature scheme, it is quite difficult to make many independent validator clients sign the exact same registration hash/digest. We hope to add a standard API endpoint to the beacon-api, where validators can ask for something to sign to register with a relay. This, if adopted, will allow for multi-client distributed validators to smoothly register with MEV relays. Without it, the workarounds are rather involved and ugly and manual and different for each client team.
- We as Obol are strongly incentivised to solve/mitigate MEV in a game-theoretic stable manner. When designing DVT, before mev-boost, I was deeply concerned that MEV present in block construction was an externality that would have compromised the stable consensus of a DV. As a greedy operator, it would be worth your while declining to approve a block proposed by someone else, such that you could propose a block where you have swept the MEV to your own side address. The pivot to blinded beacon blocks, although introducing different censoring, trusted relayer compromises, allows for a DV to come to consensus on a block hash instead of a full block, which does not have the same capacity for abuse. We believe with the right builder constraints, like crLists, this model of ‘dumb proposers’ is the right path forward for Ethereum, validating in a maximally profitable manner needs to be doable by everyone.