Axiom V2 Docs Old
  • Introduction
    • What is Axiom?
    • Quickstart
  • Examples
    • Autonomous Airdrop
      • AxiomREPL Code
      • Contract
      • Web App
      • DataQuery-only Version
  • Developers
    • Axiom for Developers
    • Specifying a Query into Axiom
    • AxiomREPL
      • AxiomREPL Examples
    • Exporting a Client Side Prover
    • Handling Axiom Callbacks
    • Common Issues
      • Callback Debugging
  • SDK and REPL Reference
    • Axiom SDK Reference
      • QueryBuilderV2
      • Data Subqueries
        • Header Subquery
        • Account Subquery
        • Storage Subquery
        • Transaction Subquery
        • Receipt Subquery
        • Solidity Nested Mapping Subquery
    • AxiomREPL Reference
      • Circuit Types
      • Circuit Functions
      • Data Functions
      • Compute Functions
  • Protocol Design
    • Architecture Overview
    • Caching Block Hashes
    • Axiom Query Protocol
      • Axiom Query Format
    • ZK Circuits for Axiom Queries
    • Ethereum On-chain Data
    • Guardrails
  • Transparency and Security
    • KZG Trusted Setup
    • Contract Addresses
    • On-chain ZK Verifiers
    • Security
  • Zero Knowledge Proofs
    • Introduction to ZK
    • ZK Examples
    • Getting Started with halo2
    • halo2-repl
  • Additional Resources
    • Axiom V2 Explorer
    • Github
    • Website
    • Telegram
    • Discord
    • Axiom V1 Docs
Powered by GitBook
On this page
  • Example: PLONK
  • Summary
  • Backend
  1. Zero Knowledge Proofs

ZK Examples

For a peek at the math behind ZKPs

PreviousIntroduction to ZKNextGetting Started with halo2

Last updated 1 year ago

Example: PLONK

There are various options of what kind of front-end to use to design a ZK circuit. The system is one such way. We will describe it below, and it will be a good way of preparing us for the full used in halo2, which is what Axiom uses in production.

A PLONK circuit consists of a table/matrix with the following fixed columns and nearly arbitrary number of rows:

a
b
c
q_L
q_R
q_M
q_C
q_O

.

.

.

where the numbers in the columns qL,…,qOq_L, \dotsc, q_OqL​,…,qO​ are fixed once and for all at compile time. Meanwhile the numbers in columns a,b,ca, b, ca,b,c are called witnesses and specified by the prover each time a new proof is generated. What makes the circuit meaningful, and not a random collection of numbers, is that for each row iii, the following equation is guaranteed to hold:

qL⋅a+qR⋅b+qM⋅a⋅b+qC=qO⋅cq_L \cdot a + q_R \cdot b + q_M \cdot a \cdot b + q_C = q_O \cdot cqL​⋅a+qR​⋅b+qM​⋅a⋅b+qC​=qO​⋅c

Since the qqq columns are fixed once and for all, specifying these numbers allows you to "mold" the circuit to constrain the witnesses a,b,ca, b, ca,b,c to perform certain computations.

For example, if you want to add ai+bi=cia_i + b_i = c_iai​+bi​=ci​ in row iii, put:

a
b
c
q_L
q_R
q_M
q_C
q_O

a_i

b_i

c_i

1

1

0

0

1

To multiply ai⋅bi=cia_i \cdot b_i = c_iai​⋅bi​=ci​ in row iii, put:

a
b
c
q_L
q_R
q_M
q_C
q_O

a_i

b_i

c_i

0

0

1

0

1

To force aia_iai​ to be a known constant CCC, put:

a
b
c
q_L
q_R
q_M
q_C
q_O

a_i

*

*

1

0

0

0

Note that bi,cib_i, c_ibi​,ci​ can be any numbers and it doesn't matter.

So far, we can use the above to do single line computations. There is one more ingredient: one can also specify once and for all that certain predetermined cells in the table above are always equal. For example, for some i0i_0i0​, we must have ci0=ai0+1c_{i_0} = a_{i_0 + 1}ci0​​=ai0​+1​. This now allows us to carry results of previous computations into new computations, "chaining" to create longer computations.

Summary

To summarize, creating a ZK proof involves the following steps:

Once and for all, specify the circuit itself:

  • Specify all cells in columns qL,qR,…,qOq_L, q_R, \dotsc, q_OqL​,qR​,…,qO​.

  • Specify any equality constraints between cells.

  • The verifier receives the above information in a compressed form.

  • The prover holds onto a copy of the above information itself.

To submit a proof:

  • Do the computation itself, i.e., generate the witnesses ai,bi,cia_i, b_i, c_iai​,bi​,ci​.

Backend

While circuit design involves just filling out a table using some front end, to actually create a proof there is a backend that takes the PLONK table above and does a bunch of computations involving polynomial commitment schemes. This part is largely independent of the circuit design, but different backends lead to different performance characteristics, which become important to understand for production use cases.

−C-C−C
PLONK
PLONKish arithmetization