zkTrue-up Trusted Setup

This repository documents all contributions to the trusted setup of zkTrue-up. All zkeys and transcripts are stored in a public GCS bucket for independent verification by anyone.

zkTrue-up Circuit (Circom Files)

• Githup repository: TS-Circom
• Repository commit hash: fdecf81dd95a67a98689015a251c0c3729f04dde

R1CS File for zkTrue-up Circuit

To verify the correctness of the R1CS file, you can recompile the zkTrue-up circuit provided above using the specified Circom version below. After recompilation, the files might not be identical due to minor differences. However, you can extract a Circuit Hash value from the R1CS file, and this value should be consistent across compilations.

• Circom version: 2.1.9
• Circom repository commit hash: 2eaaa6dface934356972b34cab64b25d382e59de
• zkTrue-up R1CS files:
  • Normal circuit R1CS file
  • Evacu circuit R1CS file

Zkey Files

This ceremony is conducted using iden3/snarkjs. In snarkjs, the output generated by all participants is in the form of zkey files.

• Snarkjs version: 0.7.2
• Snarkjs repository commit hash: 9ad62898409a975078c65ed3b728baabc456a1f3

We will list all the participants of the trusted setup ceremony along with their respective zkey files. As long as any one participant discards their secret values, the prover of this circuit will be unable to produce fraudulent proofs.

For each zkey file, anyone can execute the following command to verify its association with the above-mentioned r1cs file:

snarkjs zkey verify zktrueup.r1cs powersOfTau28_hez_final.ptau <specificed.zkey>

We provide the initial zkey file. Starting from the second zkey file, anyone can run the following command to verify the connection between any the zkey file and the previous one:

snarkjs zkey init <init.zkey> powersOfTau28_hez_final.ptau <previous.zkey>
snarkjs zkey init <init.zkey> powersOfTau28_hez_final.ptau <specificed.zkey>

This command will list the hash values of all contributions involved, and two files should only differ by one hash value.

In this way, we can ensure that the contributions of all participants have been included in zktrueup_final.zkey.

Record of The Process

• The Record for Normal Circuit
• The Record for Evacu Circuit

Random Beacon

Prior to the start of the ceremony, we declared on-chain the use of the latest chainhash that is divisible by 200,000 as our random beacon.

• The ETH Transaction Hash For Storing The Declaration: 0x1ac72f51dec26094b9c752d4ae02c375df87b67d09ac1ba00d6d41d632282ece

  • Declaration (utf-8 encoded):

    In the trusted setup ceremony for the zkTrue-up circuit, we plan to apply a random beacon generated through the computation of a Verifiable Delay Function (VDF) on a specific block hash from the Ethereum mainnet. We will select the block number that, when divided by 200,000, results in a remainder of 92,194, and use the hash of this block as the input for our computations. The designated random beacon will be the outcome of 2^34 iterations of the BLAKE2b hash of this block's hash value.
    
    Given the Proof of Stake (PoS) mechanism in Ethereum, when two consecutive blocks are endorsed by the majority of validators and deemed "justified," the first block is subsequently "finalized." The maximum duration from a block being chained to it being finalized is roughly 12.8 minutes (spanning two Epochs). Hence, as long as it is confirmed that the block proposer cannot compute the 2^34 BLAKE2b hash iterations within 12.8 minutes, the security of this random beacon can be trusted.
    
    The BLAKE2b hash of evacu_0000.zkey is: 7e3ed951fee7523a628bc61c487173831fa4a89fc83f1e0532574cc7f6b18f9cfe26ad070f28e26f34a24c289d4a9359ca85a40e84df6d5e16cf99aebf1e0ba1
    
    The BLAKE2b hash of normal_0000.zkey is: 042170b92756e63f2a0b2e32eee9ed0cbff37d71de187a7bb1c961b370c284f53e8969f6b2fe07c04d5f3cc6c50adb5f444af244d13ca24753b769ec2d6359c2
    

• Beacon Info

We will use this beacon to finalize the ceremony output.

Verification Key

Anyone can execute the following command to extract the verification key from zktrueup_final.zkey:

snarkjs zkey export verificationkey zktrueup_final.zkey verification_key.json

Or transform the zkey file into a verifier contract to compare it with the verification key deployed onchain:

snarkjs zkey export solidityverifier zktrueup_final.zkey verifier.sol