feat(sidecar): Signature checks (user, proposer) + refactor

[merklefruit]

Signatures in Bolt

In Bolt, various parties must provide signed values to securely exchange information.
The key types of signatures required are:

User Signature

Commitment requests from users must be signed using the sender's private key, the same secp256k1 private key used for signing Ethereum transactions. The structure of these messages is as follows:

pub struct InclusionRequestMessage {
    pub slot: Slot,
    pub tx: String,
}

To request an inclusion commitment, users sign this struct. The sidecar verifies that the sender, recovered via ecrecover from the message and signature, matches the sender of the transaction requested ¹.

Proposer Signature

Proposers (entities operating the Bolt sidecar) must sign any SignedCommitment:

pub struct SignedCommitment<M, S> {
    pub message: M,
    pub signature: S,
}

Commitments signed by the proposer's private key are essential for attributing faults and enforcing slashing.

---

Discussion on Signature Types

There has been extensive debate over which signature types to use: ECDSA, Schnorr, BLS, etc. Our current requirements do not mandate a specific cryptographic signature "at runtime" (i.e., during the operation of the Bolt protocol and signing commitments).

However, the opt-in procedure must be linked to the beacon chain validator identity. Proposers need to bind a private key to their validator pubkey, allowing them to use this new private key to authenticate commitments.

For now, the specific way to perform this binding is out of scope of the sidecar and will not be important for the devnet.

Footnotes

1. Note: This constraint can be relaxed in the future; for V0.1, we will continue to enforce this check. ↩