Ethereum EIP-8450 draft adds builders and changes key authorization

An October 30 revision of Ethereum’s EIP-8450 expands its proposed consensus-key registry to builders and changes who would authorize replacement keys. The registrant’s existing BLS signing key would authorize both registration and later replacement, subject to a delay between changes.

The Core proposal, created on October 15, remains marked Draft. Merging this edit into the EIPs repository does not activate its rules on Ethereum.

A different authorization path

The previous text let a validator’s BLS key register a key only once, while a separate execution-layer request from its withdrawal address could register or replace it. The revision replaces that split with a consensus-layer operation authorized by the validator’s or builder’s BLS signing key. BLS is the signature scheme used for the existing signing credentials described in the proposal.

Under the revised specification, a validator would register a leanXMSS signing key plus the 32-byte root of a verifiable random function tree. A builder would register a leanXMSS key with a zero value for that root. The draft assigns future builder signing duties to execution-payload bids and envelopes.

Each registration would name the epoch of the previous change. Processing would require that value to match the stored record. Replacing an existing nonzero key would also require the configured delay, set to 256 epochs in the main preset and eight in the minimal preset. Both first registrations and replacements would share a limit of eight registrations per beacon block.

Registration comes before a signing switch

For client implementers, the proposed data layout adds a beacon-block operation and four parallel beacon-state lists for keys and change epochs. It leaves the existing Validator and Builder containers unchanged.

The registered keys would remain dormant during this registry stage. Existing signing duties would still use BLS; switching duties would require a later fork. The document leaves activation to the relevant fork’s meta EIP and supplies no activation date. The repository change alone does not establish deployed client support.