verifying remote signing

[franjoespejo]

Motivation

The current landscape, wherein remote signers rely on and trust validator clients for block signing, presents challenges in ensuring the integrity of signed blocks. This proposal addresses these challenges by introducing mechanisms for an autonomous verification process.

Rationale

This enhancement provides verification capabilities of the block proposal content to remote signers before 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:

• Prevent signing tampered blocks by verifying block properties using Merkle proofs:
  Each signing request can include an array of objects with the properties index and proof, where the index is an arbitrary generalized index of any property nested under the block body, and proof is its corresponding Merkle proof against the block body root included in the request.
  The Nimbus client has already implemented the verifying remote signer under the verifying web3signer name.

Specification overview

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

1. Define verification properties in the validator client

This step communicates to the validator client via flags where to find the remote signer and which properties the remote signer can validate. These properties can include:

• Block Properties: It tells the validator client which block properties should be submitted for verification, accompanied by Merkle proofs for all the block proposal signing requests sent to the remote signer.

2. Verify signature requests for /api/v1/eth2/sign/{pubkey}

Enhancing signature requests with Merkle proofs, facilitating property verification. Based on the properties specified for each validator in the previous step, the verifying remote signer will perform the following computation before signing:

• Block Properties Validation: The remote signer verifies each block property using the provided Merkle proofs and generalized index against the signing_root field which is the block body root, ensuring each property's integrity before signing.

Sequence diagram

[jframe]

Hi @franjoespejo, can you provide some more detail the changes you are proposing? Is there a issue or spec somewhere I could look at get more context?

[franjoespejo]

yep working on that now, will add it

[dapplion]

(1)

Block Properties Validation: The remote signer verifies each block property using the provided Merkle proofs and generalized index against the state_root, ensuring each property's integrity before signing.

The validator client does not have access to the state and can't proof things against the a state_root. From Nimbus' documentation you should indicate is proofs against the block body itself https://nimbus.guide/web3signer.html#verifying-web3signer

To enable this use case, the BLOCK_V2 request type of the /api/v1/eth2/sign/{identifier} endpoint is extended with an additional array field named proofs. The array consists of objects with the properties index, proof and value, where index is an arbitrary generalized index of any property nested under the block body and proof is its corresponding Merkle proof against the block body root included in the request.

(2)

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

I am confused by this statement, what's a "relayer" in this context? this relayer signature is the signature found in SignedBeaconBlock.signature?

(3)

I think you should split this PR into two features:

• Adding merkle proofs to arbitrary block properties
• Adding relay signature over execution payload

[dapplion]

LGTM

[rolfyone]

i think its worth pointing out that signing time is very time sensitive, so if any of these latencies added amount to very much, its likely you'll miss proposals, (70% of the network will reorg you if you're not timely)
Any delay in signing will flow downstream to when nodes can start publishing.
With that caveat of 'at your own risk' Im not completely against it, but I've got concerns about using it given other timing games out of direct control.