Designing the Certificate

[bpfarmer]

I want to propose a view regarding function and design of the Certificate. I don't think that we necessarily need to make changes at the moment, but I more want to be sure that we're on the same page for future iterations.

First, I'm not sure that Certificate is the proper name for this data structure. A Certificate in TLS, for example, is used to authenticate an identity/public key, not to authenticate data sent by a website. The way that we use Certificate is to authenticate data that's sent from chains after each block or batch, not to authenticate a distributed signing key or some validator set.

That aside, there are multiple contexts in which the state transition of a chain might need to be authenticated. For example, if Chain A receives a message from Chain B, it will need to determine whether the LET_B that includes the message is valid. This might involve checking a validity proof or a consensus proof.

At the same time, chains need to submit more data to the pessimistic prover service - a complete set of new leaves added to the LET, a complete set of ImportedClaims, etc.

There are three desired properties for the data structure that we use to authenticate :

• It should be compact, so that it can be easily downloaded and used to verify that a chain update is valid.
• It should be universal, so that it can be used to authenticate chains with execution proofs, consensus proofs, and signatures.
• It should completely authenticate all of the data that we need to verify a message, generate a pessimistic proof, etc.

I think that the minimal version of the certificate would be something like:

struct Certificate {
    /// The origin network that emitted this certificate.
    pub origin_network: NetworkId,

    /// The block height that produced the local exit root
    pub block_height: u32,
    
    /// The state root produced by the current block
    pub state_root: Option<Digest>,
    
    /// The initial local exit root.
    pub prev_local_exit_root: Option<Digest>,
    /// The updated local exit root
    pub local_exit_root: Digest,

    /// A commitment to the set of imported bridge exits for which the origin network is the target.
    pub imported_exits_root: Option<Digest>,

    /// A commitment to the set of imported local exit roots
    pub imported_lers_root: Option<Digest>,    

    /// An imported global exit root, used to process deposits from Ethereum
    pub imported_global_exit_root: Option<Digest>,

    /// A validity proof verifying transaction execution
    pub validity_proof: Option<ValidityProof>,

    /// A consensus proof for the latest block
    pub consensus_proof: Option<ConsensusProof>,

    /// The signature that commits to the state transition.
    pub signature: (),
}

This should be a minimal version that can be used to verify additional data, but I don't think it makes sense to include every argument to the pessimistic proof as part of the certificate. Given this information, the pessimistic proof can also receive and verify additional data, like the preimage of commitments.