Relayer signature forwarding

[franjoespejo]

Motivation

This proposal introduces a mechanism for remote signers to authenticate the provenance of the relayer responsible for providing a blinded block to proposer. It aims to enhance the integrity of the signing process.

Rationale

This enhancement provides verification capabilities of the block proposals content to remote signers prior to signing the block, thereby facilitating a trustless operational setup between the validator client and the remote signer.

The specification aims to optionally extend the capabilities of the remote signer API while maintaining compatibility with the current API with the following (optional, flag-enabled) addition:

• Validate Execution Payload's BlindedBlock authenticity:
  In a MEV context, when the signing request is built for a BlindedBlock, in order to validate the authenticity of the Transactions root / Execution Payload of the BlindedBlock, the validator client can include the relayer's signature by adding the signature field from the SignedBuilderBid to verify that the signature was performed by a given relayer.

Specification Overview

This specification proposes a structured methodology to refine the interaction between validator clients and the remote signer.

Enable relayer signature forwarding in validator client

This process involves validator to knowing by flags where to find the remote signer and calling to remote signer /api/v1/pubkeys endpoint to check for:

• Relayer Signature: Specifically for block proposals that are BlindedBlocks, the option indicates whether a relayer's signature should be forwarded to the remote signer.

Verifying Signature Request in /api/v1/eth2/sign/{pubkey}

Enhancing signature requests with the inclusion of relayer signatures. Based on the setting specified for each validator in the previous step, the verifying remote signer will perform before signing:

• Relayer Signature Validation: If applicable, the remote signer validates that the BLS signature in the signature field was indeed generated by a specified relayer, thereby confirming the authenticity of the execution payload of the BlindedBlock in the signing request.

Sequence Diagram

[dapplion]

Thanks! I am a bit confused due to:

• The relayer does not sign a BeaconBlockHeader. Instead is signs a BuilderBid (ref).
• The validator client does not request a SignedBeaconBlockHeader, and the beacon node does not sign. Also in the case of using a relayer it will return a BlindedBeaconBlock.

This signature field from the relayer can authenticate that the execution payload originates on the relayer, not the entire beacon block.

Please amend the diagram and description for spec clarity. Also this PR includes changes from #10, please maintain the scope of this branch to "Relayer signature forwarding" only

[dapplion]

This is a breaking change, it should bump to a new version

[dapplion]

This change is additive but I am not sure if it deserves a new version. If we don't bump the version, the field has to be optional, and may not be present even if the web3signer requests it on the public_keys return

[rolfyone]

agree, optional, or new interface.