Implement Certification of Cardano Block Headers

[aslesarenko]

Why

Background

Minotaur, a sub-project of Partner Chains, utilizes light clients to follow state changes on integrated blockchains through a trust-minimized state bridge.

Previously, we implemented a proof of concept for Ethereum, using its existing features to enable this design. Our goal was to replicate a similar approach for Cardano using Mithril. However, both Cardano and Mithril currently lack certain features necessary for achieving parity with the Ethereum implementation. More broadly it also prevents having light clients on Cardano with designs similar to other chains (see overview on the topic).

This issue describes the missing feature on the Mithril side.

Problem

Mithril certifies blockchain snapshots (and potentially other data types) by aggregating signatures from stakeholders, thereby enabling trust-minimized verification of that data. However, Mithril currently does not provide a way to certify Cardano block headers themselves. The Cardano header contains critical information about block creation time (e.g., the slot number) and other metadata. By certifying headers in addition to transactions and snapshots, a broader set of trust-minimized use cases becomes possible—for example, transaction inclusion proofs that link directly to a verified header and its timestamp are widely used in light clients and bridges across blockchains.

Key points:

1. No Certified Block Headers

• Although Mithril can already certify transactions (by hashing their content), there is no corresponding proof that the transaction belongs to a specific block at a specific time.
• Without header certification, a transaction’s temporal context (slot number, block height) is not trust-minimized. Users or clients must either download entire blocks or rely on external sources.

2. Missed Opportunities for Compact Proofs

• The Cardano community is exploring adding a root commitment (Merkle root) for transactions directly in the block header. If this occurs, having that header certified would allow extremely concise transaction inclusion + time proofs:
  1. Verify the header certificate.
  2. Present a Merkle path for the transaction to that header’s root.
  3. Prove which slot/time the block (and thus the transaction) was created.

3. Ad-Hoc Workarounds

• One workaround would be to create a new data type “(transaction, header)” just to prove a transaction’s time. This approach does not address the more general need for header certification which is valuable independently from transactions.

What

1. Extend Mithril’s Certification Framework to Include Block Headers

• Create a new “header certificate” type in Mithril.
• Have signers produce signatures over block headers. Aggregators would then combine these signatures into a single multi-signature that attests to the correctness and canonical status of each header.
• The resulting “header certificate” (a small object containing the header hash and multi-signature) is published and made available to light clients, sidechains, or other verifiers.

2. Expected Benefits

• Compact Inclusion Proofs:
  If Cardano incorporates a transaction Merkle root into its headers, verifying a transaction + timestamp boils down to checking:
  1. The block header certificate (small multi-signature)
  2. A Merkle path from the transaction to the header’s root
• Time-Bound Verification:
  Since the header includes a slot or timestamp, the transaction is cryptographically bound to a point in chain history.
• Seamless with Existing Mithril Architecture:
  Reuses Mithril’s stake-based threshold approach, signers, and aggregators.

Additional requirements (except what need to be certified) and use case is also described here. This proposal somewhat depends on CPS to be implemented, however even without that CPS the header certification proposed here would be indispensable for multiple trust-minimized L2 applications and will bring Cardano ecosystem (feature-wise) to be on par with other chains.