Skip to content

Proposal: Use SSZ hash_tree_root instead of keccak(payload) for SequencerCommitment signatures #787

@simon-jentzsch

Description

@simon-jentzsch

Is your feature request related to a problem? Please describe.

Currently, sequencer commitments (preconfirmations) are signed over


keccak256(
domain ++ chain\_id ++ keccak256(payload)
)

This ties the signature to the raw byte serialization of the full payload.
As a result, verification always requires transmitting the entire payload. This makes proofs unnecessarily large and prevents the use of Merkle proofs for lightweight verification. For light clients and zk-based systems (e.g. Colibri stateless clients), this is a major efficiency bottleneck.


Describe the solution you'd like

Define the signature message using an SSZ container and its hash_tree_root, similar to Ethereum consensus:

class SequencerCommitment(Container):
    parent_beacon_block_root: Bytes32
    execution_payload_header: ExecutionPayloadHeader

Then the signing root becomes:

keccak256(
    domain ++ chain_id ++ hash_tree_root(SequencerCommitment)
)

This enables:

  • Merkle-friendly proofs: clients can verify only the necessary fields.
  • Smaller proofs: no need to transmit the full payload, only Merkle branches.
  • Consistency with Ethereum consensus: aligns with how signing roots are already defined.
  • Forward-compatibility: SSZ evolution is safer than raw byte hashing.

Describe alternatives you’ve considered

  • Status quo: keep keccak(payload) – works but bloats proofs and prevents efficient verification.
  • Application-layer Merkleization: replicate hashing on top of the keccak payload, but this duplicates work and doesn’t integrate cleanly with existing SSZ tooling.

Additional context

This change would drastically reduce proof sizes and make OP Stack more compatible with stateless light clients and zk-provers.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions