zkp_block_headers

Screenshots

Problem Statement

On-chain randomness in ethereum is difficult because of potential manipulation via inclusion/exclusion by proposers and the transparent nature of the blockchain data and algorithms. Many projects rely on Chainlink’s VRF as an external trusted source of randomness, but it is painful to integrate and introduces external trust assumptions.We propose bringing the beacon chain’s existing RanDAO RNG values on chain. Our contract will provide integers uniformly distributed in the interval (0, 2^256-1) based onfutureRanDAO values.Recursive zk-SNARKs will provide succinct verification that the RanDAO values attested to are correct by confirming they generate the correct sequence of block headers up to some known recent block hash.Due to the long (~O(10hour)) compilation time of recursive zk-SNARKs in circom, we first present a simple proof that we know the block headers corresponding tosome(block) hash.

Solution

We build heavily off of existing circom circuits for (1) eth block RLP preprocessing in https://github.com/yi-sun/zk-attestor/blob/f4f4b2268f7cf8a0e5ac7f2b5df06a61859f18ca/circuits/rlp.circom (2) recursive zk-SNARKs in https://github.com/nalinbhardwaj/circom-pairing/blob/082e7705a8a384e7c7568944fa216d3eb8d863ed/circuits/isokratia/isokratia.circomOther than that, our project is fairly simple from a technical perspective, because we are simply proving that a chain of block headers link and hash correctly up from some initial block to some target block.We thank Goerli testnet for providing a development environment, etherscan and tenderly for block explorer services and iden3/circom/snarkJS open source tooling and documentation.