ERC-8218: Builder Discovery

Abstract

This proposal defines a new interface for permissionless on-chain registration of builders authenticated by their BLS12-381 public keys, and a new composable enumeration interface allowing consensus-layer clients to discover registered builders. These interfaces are to be implemented by permissionless and permissioned registry contracts and enable the discovery of builders from consensus clients, flexibly, through one or many registries. No consensus changes are required.

Motivation

Several approaches exist for builder discovery after EIP-7732. All of these are viable in appropriate contexts:

This proposal standardises the smart contract approach as the default because it best satisfies the properties an open, ecosystem-wide discovery layer requires:

• No single point of failure: a smart contract has no centralized host.
• Open entry: supports registration without approval.
• Censorship resistance: registration is an ordinary transaction.

We foresee a single global permissionless registry to exist for any builder to register and many permissioned registries. The same interfaces allow custom registry implementations with different functionality and value.

Specification

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Definitions

Data Types

struct BuilderRecord {
    bytes pubkey;   // 48 bytes, BLS12-381 compressed G1 point
    string fqdn;
}

IBuilderRegistry

The registration function MUST verify the BLS12-381 signature using the BLS12_PAIRING_CHECK precompile (EIP-2537, address 0x0f). The signed message is:

message = abi.encode(block.chainid, address(this), pubkey, fqdn, nonce)

Signing MUST use the ciphersuite BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_ as specified by IETF BLS signature draft standard v4 — the same suite used by the Ethereum consensus layer.

Each nonce SHOULD be a value not previously used for the given pubkey. Nonce tracking is an implementation detail and is not prescribed by this interface.

On success the registration function MUST emit BuilderRegistered and MUST either add the builder to the enumerable list (first registration) or update its stored record in place (subsequent registrations).

The deregistration function MUST verify the BLS12-381 signature in the same manner as registration. The signed message is:

message = abi.encode(block.chainid, address(this), pubkey, nonce)

On success the deregistration function MUST emit BuilderDeregistered and MAY remove the builder from the enumerable list or mark as deregistered.

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

interface IBuilderRegistry {
    event BuilderRegistered(bytes pubkey, string fqdn, bytes32 nonce);
    event BuilderDeregistered(bytes pubkey, bytes32 nonce);

    function registerBuilder(
        bytes calldata pubkey,
        string calldata fqdn,
        bytes32         nonce,
        bytes  calldata signature
    ) external;

    function deregisterBuilder(
        bytes calldata pubkey,
        bytes32         nonce,
        bytes  calldata signature
    ) external;
}

IBuilderList

builderCount MUST return the number of builders in the list.

getBuilderAtIndex MUST return the builder record at position index, and MUST revert if index >= builderCount().

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

interface IBuilderList {
    function builderCount() external view returns (uint256);

    function getBuilderAtIndex(uint256 index)
        external view returns (BuilderRecord memory);
}

Rationale

Why a smart contract

A permissionless smart contract is the only option that simultaneously provides open entry, persistent availability, and cryptographic authenticity without a trusted party. Among the alternatives, peer-to-peer gossip is worth examining in more depth: while it avoids a central registry entirely, it introduces a critical economic misalignment — builders who are already participants in the network have a direct incentive to suppress or delay announcements from competitors, undermining the openness the discovery layer is meant to guarantee. However, discovery through smart contracts is not suggested as a competitor against other discovery options and those options are to be explored more later.

Permissionless and permissioned registries

The two-tier model allows a single permissionless global registry to serve as a source of truth that any builder can join, while custom registries add governance, SLA requirements, geographic filtering, or allowlists that individual operators may require. Because both tiers expose the same IBuilderList interface, consumers require exactly one code path regardless of which registry they query.

Builder handshake

The builder handshake, defined concurrently with this standard and outside its scope, enables proposers to verify that a builder operating at a given FQDN is the same entity that registered the corresponding public key on-chain. When a proposer connects to a builder's FQDN, the builder's response includes a BLS signature over the connection parameters. This allows the proposer to verify that the endpoint is controlled by the holder of the private key corresponding to the public key recorded in the registry.

Security Considerations

Signature authentication and replay protection

Each registration or deregistration MUST be accompanied by a BLS12-381 signature over the corresponding message fields (abi.encode(chainid, contractAddress, pubkey, fqdn, nonce) for registration, abi.encode(chainid, contractAddress, pubkey, nonce) for deregistration). The chain ID prevents a valid registration on one network from being replayed on another. The contract address prevents replay across different registry deployments on the same chain. The nonce — which SHOULD NOT be reused for the same public key — prevents replay of any prior registration transaction.

Off-chain stake validation

The registry records BLS public keys but does not verify that a key belongs to an active EIP-7732 builder validator or that the corresponding beacon-chain deposit meets any threshold. Consensus-layer clients MUST cross-reference registered public keys against the beacon state and apply a minimum-effective-balance filter before treating a registered entry as a legitimate builder. Treating on-chain registration alone as proof of a builder's legitimacy is unreliable.

Permissionless registry inflation

Because registration is permissionless and requires no application-layer stake, an adversary can register large numbers of dummy entries to inflate the list and increase enumeration costs. Mitigating factors:

• Gas cost: each registration is an on-chain transaction; bulk registration at mainnet prices is expensive.
• Stake filter: clients applying a minimum-balance filter automatically discard builders that are not active validators.
• Connection filtering: clients performing DNS resolution and connection attempts will discard entries pointing to unreachable or unresponsive endpoints, recording them on an ignore list so that failed entries are skipped on subsequent registry refreshes without requiring repeated connection attempts.
• Registration fee: If deemed necessary, a minimal fee could be introduced - which is reasonably small for registration but hurts at scale.

Copyright

Copyright and related rights waived via CC0.