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).
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 headersprevHash
the parent’s hash of the first blockendHash
the hash of the last blockstartBlockNum
the block number of the first blockendBlockNum
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 theparentHash
field of the first block in the list. - The claimed
startBlockNum
matches theblockNumber
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 theblockNumber
field of the last block in the list.
Last modified 4mo ago