Aurora: Transparent Succinct Arguments for R1CS

The five-minute read

One action, walked through

1. Write the computation as a constraint system.
2. Prove proximity of a polynomial to a Reed-Solomon code.
3. The verifier samples from public randomness and checks the transcript.
4. What is the constraint language?

The argument, unpacked

What has to be true

• Transparent does not mean trustless in the sense of no assumption. The hash and the code are the assumptions.
• Proving time is the cost this family pays.
• It is not Groth16 and not PLONK.

What happened after the paper

STARKs and later FRI systems are the production line. Aurora is a specific R1CS argument on that line.

What to check before you use the idea

• Does a new program need a new setup?
• What is the constraint language?
• What does the verifier assume about the hash?

Terms

Transparent setup

Public randomness. No secret the prover must not know.

R1CS

A way to write a computation as rank-one constraints.

The problem the paper names

A succinct proof that needs a ceremony cannot be generated for a new program by a person who missed the ceremony.

What the design proposes

• Transparent means the setup is public randomness.
• R1CS is the circuit language, not a chain.
• Succinct is a communication claim, not a claim that proving is cheap.

How the mechanism is specified

• Write the computation as a constraint system.
• Prove proximity of a polynomial to a Reed-Solomon code.
• The verifier samples from public randomness and checks the transcript.

What this page does not treat as proven

• Transparent does not mean trustless in the sense of no assumption. The hash and the code are the assumptions.
• Proving time is the cost this family pays.
• It is not Groth16 and not PLONK.

Why a venture studio still reads it

If a rollup says the setup is transparent, ask whether a new circuit needs new toxic waste. Aurora's answer is no.