# proto-mev-boost-improvement-proposal: Sequence validator registrations in EIP-4844 blob space A proposal to move `mev-boost` validator registrations to the "blob" space introduced as a data layer in the upcoming Cancun hard fork following [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844). ## Abstract Using the blob space as a sequencing layer for validator registrations improves the trust assumptions around some classes of "MEV stealing" attacks which helps harden staking pool designs. Additionally, relays and validators would enjoy reduced load from processing registrations that they endure under the current `mev-boost` regime. ## Motivation Validators currently participate in the `mev-boost` ecosystem by making a signed message containing their block building preferences. Relays expose these preferences to builders who use them when crafting execution payloads. In turn, relays filter out builder's execution payloads if they do not respect these preferences. To ensure availability of the registration, validators who opt in to the `mev-boost` software send a registration once per epoch per connected relay even if the data has not changed. This submission discipline ensures relays usually have the latest registration but at the cost of much unnecessary bandwidth and processing load (as the relay needs to process each registration -- even if previously seen). While this submission strategy provides suitable availability, it provides no global consensus on which relays have seen which registrations at a given point in time. This lack of global sequencing encumbers the ecosystem with additional trust assumptions required in order to mitigate attacks. To illustrate one such attack, an operator in a staking pool like Lido or RocketPool could subscribe to `mev-boost` and use the pool's rewards vault as the "fee recipient" in their validator registrations. This operator could even provide the signed registration to the pool operator as evidence of honest participation. However, at some time right before the operator's proposal, they supply a new registration to the target relay that directs all rewards to a fee recipient of their choosing (instead of the pool's vault). To prevent this type of "MEV stealing" attack, staking pools have to either raise the trust requirements for operators in the pool or require some type of collateral that can be used to insure the pool. Using a global sequencing layer, like the blob space, ensures any observer of the `mev-boost` ecosystem can know when a change to the registration occurs and, consequently, attribute fault in the case of this type of "MEV stealing" attack. Moreover, this change has synergies with other protocol features like [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) to facilitate proving actions in a staking pool on-chain, bringing even more of the management of a staking pool into a less trusted domain and further reducing reliance on oracles. ## Proposal Rather than post a [signed validator registration](https://github.com/ethereum/builder-specs/blob/main/specs/bellatrix/builder.md#signedvalidatorregistrationv1) to each individual relay, a validator would simply construct a blob with their signed registration. Relays would be responsible for syncing the blobs to build a set of latest validator registrations and in turn provide the same set of services they do today. An initial implementation can directly write the current `SignedValidatorRegistrationV1` to a blob, which the relays directly read and process like they currently do. A future iteration of this feature can pull more of the validation logic on-chain, removing this responsibility from relays entirely. ### Advantages * Mitigates MEV stealing concerns via public bulletin board of DA layer * Reduced bandwidth for validator * Reduced bandwidth and processing for relay * Iterates toward an enshrined PBS world where the chain is the primary infrastructure used to implement PBS ### Disadvantages * Higher cost for validators to "register" * Somewhat higher complexity for validators and relays