Client-side block header validation to support Merkle proofs

[s8sato]

Background

• In cross-chain transaction verification, full nodes (provers) and light clients (verifiers) hold asymmetric amounts of information.
• To convince a verifier of a transaction’s persistence and liveness under this asymmetry, specialized mechanisms such as Merkle proofs are required.

Current Status and Challenges

1. PR feat(merkle): implement inclusion proof generation and verification #5467 introduced Merkle proofs.

2. However, it currently assumes that the client already trusts the block header—additional implementation is needed to establish that trust.

   • From the client’s perspective, a block header is initially untrusted foreign data that must be validated in stages.
   • Once trusted, a header becomes the foundation for validating the next block header.

Header Validation Phases

Clients must transition a received block header through four validation stages before treating it as fully trusted:

1. Signed

   • The API provides the raw header alongside aggregated header signatures.
   • The client receives these as unverified data.

2. Authenticated

   • The client verifies signature authenticity against the current validator set.
   • Only valid signatures are retained.

3. Committed

   • A header is considered committed once at least $2f+1$ valid signatures have been collected.

4. Finalized

   • Under Sumeragi, finalization requires a chain depth of 1.
   • A committed header is marked finalized once its continuity with its successor header—also committed—is confirmed.

Checkpoints and Merkle Proofs

• The client stores several of the most recently finalized headers as checkpoints.
• These checkpoints are then used to verify transaction Merkle proofs.

Prerequisites and Implementation Requirements

• The client must track changes to the node’s validator set and always be aware of the latest set. Transactions that modify this validator set must also be verified using Merkle proofs or similar mechanisms.
• Implement the above validation phases and integrate them with PR feat(merkle): implement inclusion proof generation and verification #5467’s Merkle proof logic to ensure end‑to‑end safety.