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.

Since we adopted BLAKE2b in the final beacon phase, we have forked the content of snarkjs to make the corresponding changes.

• Snarkjs repository
• Snarkjs version: 0.7.4-TermStructure.0

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 <specified.r1cs> powersOfTau28_hez_final.ptau <specified.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 <specified.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 normal_finalized.zkey and evacu_finalized.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 selection of a specific Ethereum block number, which yields a remainder of 92,194 when divided by 200,000. The hash of this block is used as input to generate our random beacon with 2^34 BLAKE2b iterations for the zkTrue-up circuit.

• The Ethereum 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 used this beacon to finalize the ceremony output. The finalized zkey files:

• normal_finalized.zkey
• evacu_finalized.zkey

Verification Key

Anyone can execute the following command to extract the verification key from normal_finalized.zkey and evacu_finalized.zkey:

snarkjs zkey export verificationkey normal_finalized.zkey normal_verification_key.json
snarkjs zkey export verificationkey evacu_finalized.zkey evacu_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 normal_finalized.zkey normal_verifier.sol
snarkjs zkey export solidityverifier evacu_finalized.zkey evacu_verifier.sol