Commitment registry

[mempirate]

The Bolt registry is a canonical registry that keeps track of registered validators (among other things). In this document we explore the why, what and how of such a registry in the context of proposer commitments. Note that this registry doesn't have to be specific to Bolt. We don't concern ourselves with collateral and slashing too much in this discussion, we just assume that the registered keypair has the power to slash the associated validator(s) collateral.

Core Functionality

• Registration: allow entities like collateral providers, validators and operators to register themselves with their respective terms & conditions
• Authorization: provide functionality for authorizations. Includes things like collateral providers authorizing validators to provide blockspace for commitments, or specifying delegations
• Tracking State: track the state of different entities in the registry
• Discovery: allow users to discover registered validators in the lookahead (and their preferences)

Requirements

• Canonical: ideally, everyone agrees on one canonical registry. This is exactly what blockchains like Ethereum achieve, which is why our ideal choice is a smart contract registry
• Neutral & Permissionless: any proposer should be able to participate, and we should support any restaking protocol (how do we interface with restaking protocols in a future proof manner? $\Rightarrow$ adapter contracts)
• Capital efficient: proposer pooling, staking pool / node operator friendly, dynamic collateral (vs. ex ante lockup), user defined penalties
• Cost efficient: for large validator sets representing a single entity, a single registration should suffice
• Secure: key isolation, authentication & authorization

Design 1: Beacon Chain Ether

TLDR: Natively restaked Eth for collateral provisioning. Explicit authorization from withdrawal credentials a.k.a. the collateral holders for their validators to participate in these protocols. Tailored for non-custodial staking pools where there is a separation between capital owners and validators.

Entities & Relations

We define 3 main entities:

• Collateral providers: limited to Ethereum collateral for now. Identified by 0x01 withdrawal credentials.
• Validators: blockspace providers for commitments. Identified by signing / validator keys. Can be distinct from collateral providers in the case of non-custodial staking pools.
• Operators: entities that make commitments, authorized by both collateral providers and validators. Identified by a commitment signing key and metadata like RPC endpoint.

Registration & Authorization

Registering will be a 2-step process:

• Collateral registrations & authorization
• Validator registrations & activation

Step 1: Collateral Registration

Note: for now we assume collateral to be staked ETH controlled by 0x01 withdrawal credentials.

The first step of registration consists of collateral providers authorizing access to their staked ETH through their withdrawal credentials. The reason for this is that collateral providers and validators might not be the same entity, as is the case with non-custodial staking pools. Since collateral providers are taking on the slashing risk, they need to explicitly authorize that their allocated blockspace (through associated validators) can be used for commitments.

Withdrawal credentials can either be an EOA or a smart contract (in the case of an EigenPod for example). Only when they are set to a smart contract that adheres to an interface and can extend slashing rights to the registry, can that collateral be used to secure the commitments. This check is done in the registration step.

registerCollateral(address owner, address collateralProvider)

• Check that collateralProvider adheres to some slashing interface (EigenPod, Symbiotic Vault)
• Check that the registry has authorization to freeze / slash (using said interface)
• Check effective balance etc.
• Save owner as the address that can later set & modify terms & conditions for this collateral (alternatively, could be read from the collateralProvider contract)

setCollateralTerms(address collateralProvider, Terms terms)

• Check that msg.sender is the owner for this collateralProvider
• Sanity checks on terms

struct Terms {
    // Max gas limit per block allowed for commitments
    uint256 gasLimit;
    // Collateral at risk
    uint256 collateral;
    // Defines the authorized operator keypair
    address operatorAddress;
    // The commitment RPC endpoint
    string endpoint;
}

Step 2: Validator Registration

Once collateral has been added, the associated validators can register themselves as well. We define a method that takes as inputs the validatorIndexes, state about those validators (effective balance, associated withdrawal credentials), proofs for verification of that state against the beacon block root (EIP-4788), and an aggregated BLS signature to authenticate the provided validators.

An example of the proof logic in EigenLayer can be found here. Since the proof verification of validator fields is already implemented in EigenLayer / Symbiotic, we could also just reuse that and only implement the BLS signature verification. We can use the view methods like validatorStatus on EigenLayer to verify this.

Note

The BLS signature verification precompile will only ship with Pectra in EIP-2537. Can we use ZK proofs in the meanwhile? Or should we just optimistically provide the signatures and have off-chain components do the verification before considering a validator as registered?

registerValidators(uint256 oracleTimestamp, uint40[] validatorIndeces, ValidatorFields[] validatorFields, Proof[] proofs, bytes[] signatures)

• oracleTimestamp is used to get the beacon block root from the EIP-4788 contract [Should this be a finalized timestamp?]
• Alternatively to double checking the proofs we rely on EigenLayer / Symbiotic to verify this

Tracking State

Registered entities' state needs to be tracked to have a consistent view of the status of different validators. State is stored as a mapping from pubkey => status. [Should status be on a per-entity (keypair) basis or per-validator?] Currently proposed states:

• REGISTERED: the keypair is registered, but not active yet
• ACTIVE: the keypair has been activated, i.e. associated collateral has been registered and the keypair has access to it
• FROZEN: the keypair has been frozen and should not be relied upon for commitments (could be because of a fault)
• EXITING: the keypair is exiting either due to manual deregistration, full slashing of underlying collateral, or unstaking of the underlying collateral
• EXITED: default for non-existing validator indexes

Discovery

The registry exposes some view methods that allow off-chain actors to get info about registered validators. They can consult the smart contract with a validatorIndex & pubkey read from the beacon chain lookahead (the EVM does not provide direct read access to the beacon chain lookahead). This method will return information like the commitment keypair, RPC endpoint, collateral at stake & other optional metadata.

Questions

• Is validatorIndex a good enough unique ID of validators or should we use their pubkeys?
  $\Rightarrow$ No, see https://eips.ethereum.org/EIPS/eip-6914
• Both Symbiotic and EigenLayer already natively have the concept of delegation. How can we re-use that? Is their concept of delegation what we need? What else can we re-use?
• BLS or ECDSA keys for signing commitments? We won't have BLS signature verification until Pectra. Also, restaking keys might prefer ECDSA? EigenPod credentials are ECDSA
• Should we have an off-chain "registry" that can be used to signal uptime etc. Can be maintained by the Bolt RPC.
• Push vs. pull? Commitments API: push or pull? #47
• Chain reactions: what happens when a single validator in the registered set commits an accidental fault? Does that knock down all validators in the set?

References

• https://github.com/LimeChain/based-preconfirmations-research/blob/main/docs/optin-mechanics.md
• https://ethresear.ch/t/credibly-neutral-preconfirmation-collateral-the-preconfirmation-registry/19634
• https://docs.lido.fi/contracts/node-operators-registry/
• https://github.com/Layr-Labs/eigenlayer-middleware
• https://github.com/Layr-Labs/eigenlayer-middleware/tree/mainnet/docs/registries
• https://github.com/spire-labs/preconfirmation-registry

[merklefruit]

After some further design and implementation efforts, here are the latest updates on the role of the Registry and how we currently see it evolving in further iterations of Bolt:

First iteration: Holesky-1

This version of the registry will demonstrate authentication and discovery functionality, along with the first restaking integrations:

• ability to register with a validator BLS public key (without signature checks, waiting for BLS precompile to be live)
• ability to opt-in as a collateral provider (aka "vault") and authorize operators
• ability for operators to opt-in with delegated collateral and start issuing commitments in Bolt
• ability to request slashing of collateral in case of faults (challenger not fully implemented at this point)
• ability for operators and users to easily query the opted-in Bolt proposers in the lookahead and their collateral status

For this, we have adopted a modular approach with two contracts: BoltValidators and BoltManager:

• BoltValidators serves as a global registry from which validators can register directly. It will implement BLS signature checks once they are live on Holesky. It can also track metadata set by validators such as their delegated operator or collateral provider address.
• BoltManager handles all the "staking control" operations. This means either depositing ETH directly, or signalling opt-in from third-party restaking protocols such as Symbiotic or Eigenlayer. This essentially means implementing the full opt-in and slashing API integrations and leaving all the deposit/withdraw and internal authorization steps to these protocols.

Here is a diagram of how opt-in through Symbiotic would look like:

Second iteration: Holesky-2

The next milestone will mainly consist of cleaning up the restaking abstraction behind a unified API and proxy it with adaptors.
This will essentially make the BoltManager simpler by exposing the bare minimum functionality and leaving the restaking protocol-specific implementation details to these adaptors. Here is a diagram of how this may look like: