reLight

README

reLight

Recursive ZK-proof of ETH Light Client

This library is based on gnark, and could be used to compute zero-knowledge proofs for each and every existing sync committee in the ETH Light Client protocol.

It is up to the application developers to decide how the transactions or events of their concern should be linked to the sync committee signed data. BYW, the gnark library also provides circuits to verify BLS signature for the BLS12-381 curve.

Proof Structure

There are three roles in a general recursive proof structure: G for genesis, U for unit and R for recursive. Acordingly there are three kinds of proofs:

1. Genesis proof, or Pg for short, representing the proof to the initial data, which could be the block hash of the genesis block, or the merkle root of the genesis sync committee in Ethereum Light Client Protocol.
2. Unit proof, or Pu for short, representing the proof to individual data element, which could be the block hash of any block except the genesis, or the merkle root of any sync committee except the genesis.
3. Recursive proof, or Pr for short, representing the proof of the linking from some individual data element all the way back to the genesis.

Correspondingly, there are three kinds of circuits generating each of the above proofs: Cg, Cu, Cr.

Recursive proving is achieved by Cr validating:

1. First one instance of Pg or Pr
2. Then one instance of Pu

Plus the business level linking between the first proof and the second.

For Cr to validate a proof of either Pg or Pr, the public inputs for Cg and Cr must align, diff only in values. This usually requires that we stuff extra public inputs to Cg in addition to what is requird by its own logic. In other words, Cg and Cr must have the same 'shape'. However, one issue remains, and is discussed next.

Fingerprinting Verification Keys

So how can Cr recursively verify if a proof is generated by itself, if Cr is still under composing? The answer is to alienize the verification key via fingerprint computation. That is, by hashing the vital parts of a verification key, we can compute a fingerprint to identify a circuit. Then in the Cr circuit, we can load a verification key as witness and validate if its fingerprint matches another witness value, which happens to be the fingerprint of Cr. Note the fact that the circuits of these verifications stay stable regardless of the details of Cr.

In this project, we rely on the fingerprinting feature in gnark, which uses MiMc.