This issue is a writeup of how to build a Celestia client that will act as the underlying DA client for rollups clients to verify. Once consensus is reached, this can be formalized with a document on the specs

One thing to note is that Celestia is an SDK chain running CometBFT consensus. Thus we can reuse the tendermint client for most of the client logic.

However Celestia has some important key modifications it needs to make.

The first is that rollup block data (header + txs) are committed to in the DataHash of the CometBFT header. In the 07-tendermint client, we discard this information when compressing the header down to a consensus state. However, it is necessary that we add the DataHash to the consensus state for DA verification.

*Note theoretically, one could add this as metadata in the client store, thus outside the consensus state itself. But I find that to be a bit hacky and not in keeping with the client and proof semantics.

The second thing we will need to do is to allow different types of proofs to be handled by the Celestia light client VerifyMembership and VerifyNonMembership methods.

Of course we will want to continue supporting standard proofs against the app hash, but in order for the celestia light client to serve as DA verification for rollup clients, it will also need to support inclusion proofs against the data hash stored in the consensus state.

The proposal here would be to unmarshal the proof []byte sent to VerifyMembership into a specific type:

type CelestiaProof struct {
    ProofType enum
    Proof []byte
}

The ProofType enum will select one of a specific set of supported proof types (e.g. AppHashInclusionProof, DataHashInclusionProof, DataHashBlockDataProof)

Based on the prooftype specified, the VerifyMembership unmarshals the underlying proof accordingly and executes proof-specific verification logic.

*Note there are multiple types of proofs that can be verified against the data hash. So we should support those at separate enums.

IMPORTANT: The caller that wishes to do the verification should be the one to set the ProofType enum and wrap provided proof in a CelestiaProof. Do not allow relayers or untrusted users to set the enum themselves as this could be a potential attack vector

Discussion with @nashqueue needed to understand which proof types will need to be supported.

TLDR;

Changes to Tendermint Client needed:

1. Add data hash to ConsensusState on UpdateClient
2. Support multiple proof types and verification logic in VerifyMembership endpoint