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

**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:

```python
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**

* Current spec reference: [[Rollup Node P2P – Block signatures](https://specs.optimism.io/protocol/rollup-node-p2p.html)](https://specs.optimism.io/protocol/rollup-node-p2p.html)
* Ethereum SSZ reference: [SSZ hash\_tree\_root](https://ethereum.org/en/developers/docs/data-structures-and-encoding/ssz/)
* Backwards compatibility path: introduce a **new topic/domain (e.g. v5)**, sequencers can dual-sign during migration, clients accept both formats.

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

Start by reading the Rollup Node P2P – Block signatures specification and the linked Ethereum SSZ hash_tree_root reference. Compare the current keccak(payload) signing formula with the proposed SequencerCommitment container, then document the versioned topic or domain and dual-signing compatibility path needed for migration.

Written by the indexing model from the issue text.