> For the complete documentation index, see [llms.txt](https://corpus-core.gitbook.io/specification-colibri-stateless/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://corpus-core.gitbook.io/specification-colibri-stateless/specifications/ethereum/proofs/synccommittee-proof.md). # SyncCommittee Proof The Verifier always needs the pubkeys of the sync committee for a given period in order to verify the BLS signature of a Beacon BlockHeader. These keys can be fetched as part of the proof for example from a remote prover. While it allows colibri to verify even without any previous state if the pubkeys are part of the proof-response, instead of adding those 25kB for the pubkeys, they easily be cached. If a verifier requests a proof from a remote prover, the verifier may use the c4-property of the RPC-Request to describe its state of the known periods or checkpoint. If the verifier only reports a checkpoint, a bootstrap is added proving the current\_sync\_committee for the given checkpoint. If the requested header has a higher period than the bootstrap or the latest known period, all required lightClientUpdates will be proven. For the sync-data-section in the proof (C4-Request) there currently 2 ways to verifiy the pubkeys of the sync\_committee: ## EthZkSyncdata A Recursive ZK proof of a sync-committee update (356-byte Groth16). This proof allows to sync from a fixed trustanchir (hardcoded in the verifier). This also solves the problem of a verifier with a very old pubkeys in the cache to speed up the process. It alos adds security, because it uses 2 independend factors to verify. the cryptographic zk proof on the one hand and the checkpointz verification on the other hand. The Type is defined in [src/chains/eth/ssz/verify\_types.c](https://github.com/corpus-core/colibri-stateless/blob/v3.0.2/src/chains/eth/ssz/verify_types.c#L303). ```python class EthZkSyncdata(Container): vk_hash : Bytes32 # the hash of the vk used to generate the proof proof : ByteVector [356] # Groth16 proof of the sync-committee update header : BeaconBlockHeader pubkeys : Vector [blsPubky, 512] # the pubkeys of the sync committee checkpoint : Union [ # the proof from the checkpoint to the header EthSignatureHeaderProof, # proof by providing the signature of the sync committee EthHistoricHeaderProof, # proof for a historic block using the state_root of a current block EthHeaderChainProof, # chain of headers up to a verifiable header EthCheckpointProof] # WSP anchor via LightClientBootstrap (currentSyncCommittee branch) signatures : List [secp256k1Signature, 16] # cap 16 is the witness-key allow-list size, not an encoding limit ``` **Referenced Types** * [EthSignatureHeaderProof](/specification-colibri-stateless/specifications/ethereum/proofs/consensus-layer-header-proof.md#ethsignatureheaderproof) * [EthHistoricHeaderProof](/specification-colibri-stateless/specifications/ethereum/proofs/consensus-layer-header-proof.md#ethhistoricheaderproof) * [EthHeaderChainProof](/specification-colibri-stateless/specifications/ethereum/proofs/consensus-layer-header-proof.md#ethheaderchainproof) * [EthCheckpointProof](/specification-colibri-stateless/specifications/ethereum/proofs/consensus-layer-header-proof.md#ethcheckpointproof) ## EthLcSyncdata The main container type definition for C4Request, wrapping all request fields Union type for a single LightClient Update, which can be either Deneb or Electra format Fulu keeps the Electra LightClientUpdate layout (branch depths unchanged). LC SyncData contains all the proofs needed to bootstrap and update to the current period. There are 3 different szenarios what kind og syncdata could be provided. 1. cold start - no pubkeys are known. In this case the verifier will use either the configured checkpoint or fetch one from the checkpointz. This checkpoint will be sent to the prover (as c4-property). The prover will then fetch the bootstrap-data and pack it to the syncdata section. If the requested Block is within a newer period, lightclient updates will be provded to reach the target period.. 2. old pubkeys in the cache. If the verifier already has verified pubkeys for a sync period, but the the target period is newer, only the light client updates will be added to the proof. If the the range of the updates is larger than the weak subjectivity period,the verifier will fetch the checkpoint from the checkpointz and verify the last update against it. 3. since the verifier is always sending the last verified sync period, in most cases the prover will simply confirm that this macthes the requested period and leave the syncdata empty. The Type is defined in [src/chains/eth/ssz/verify\_types.c](https://github.com/corpus-core/colibri-stateless/blob/v3.0.2/src/chains/eth/ssz/verify_types.c#L295). ```python class EthLcSyncdata(Container): bootstrap : Union [ # optional bootstrap data for the sync committee, which is only accepted by the verifier, if it matches the checkpoint set. None, # DenepLightClientBootstrap, # 1: Deneb-fork structured LightClient Bootstrap ElectraLightClientBootstrap, # 2: Electra-fork structured LightClient Bootstrap EthCheckpointProof, # 3: slim WSP anchor (header + currentSyncCommitteeBranch + aggregate) GloasLightClientBootstrap] # 4: Gloas-fork structured LightClient Bootstrap update : List [ Union [ # optional update data for the sync committee DenepLightClientUpdate, # 0: Deneb-fork structured LightClient Update ElectraLightClientUpdate, # 1: Electra-fork structured LightClient Update GloasLightClientUpdate] ] # 2: Gloas-fork structured LightClient Update ``` **Referenced Types** * [EthCheckpointProof](/specification-colibri-stateless/specifications/ethereum/proofs/consensus-layer-header-proof.md#ethcheckpointproof)