Block Chunks Sync

This section describes how Breivs tracks and ues ZK validated information of all historical blocks. Note that here when we talk about "historical blocks", we always refer to all blocks start from a certain block the Brevis system chooses, not necessarily from the genesis block.
The previous section discusses how Brevis updates Ethereum's headers and sync committees to the on-chain light client by verifying a ZK proof that validates the (large number of) committee signatures of the specific update. This is suitable for perodic or low frequency on-demand updates to serve applications that only cares about the latest block header, but would be prohibitively expensive if we want to keep records of all historical blocks .
To achieve the full capability of verifying any historical data of the Ethereum chain on a target chain, we need a way to efficiently verify and store all Ethereum blocks on the target chain. Our solution is to only update one block (aka "anchor block") through signature verification periodically,  then prove a chain of blocks are valid up till the anchor block. For example, if block 1024 is validated through signature verification, when one can verify that block 1023 is also valid by proving that block hash of 1023 is used when computing block hash of 1024. 
Finally, we compute the Merkle root of the chain of blocks (a block chunk) and store the root on the destination chain. To verify whether a claimed Ethereum block is valid, the prover would only need to provide a Merkle path from the block of interest to the root (contract code).
Circuit
The circuit for block chunks sync has the following input:
Public Inputs (can be used by on-chain contracts):
root Merkle root of 1024 block headers
prevHash the parent’s hash of the first block 
endHash the hash of the last block
startBlockNum the block number of the first block
endBlockNum the block number of the last block
Private inputs:
A list of 128 RLP-encoded execution layer blocks
The circuit checks the following constraints:
Hash chain: each block's hash equals the ParentHash of the next block in the list.
The claimed prevHash matches the parentHash field of the first block in the list.
The claimed startBlockNum matches the blockNumber field of the first block in the list.
The claimed endHash matches the hash of the last block in the list.
The claimed endBlockNum matches the blockNumber field of the last block in the list.
​
Last modified 4mo ago