Forem: Tony Olendo

Permit2 Frontend Guide

Tony Olendo — Tue, 12 Dec 2023 02:51:46 +0000

What if I told you never have to do an “Approve” transaction again?! Ok, maybe not never, but fewer times than you currently have to do? What if you can reduce the number of times you have to trust some random DeFi smart contract or that you’ll spend less time on revoke.cash when you hear about yet another hack! Well, Permit2 is a DeFi UX primitive that’s simplifies token approvals, safely. In this guide, I’ll walk you through a Permit2 frontend dApp that makes token approvals a lot easier.

Quick Background Lesson

Uniswap Labs developed Permit2 to allow token approvals to be shared across different applications by unifying ERC20 and NFT swapping in a single swap router. That’s a bit of a mouthful, but let’s say dApp A integrates with Permit2 and a user approved Permit2 to swap USDC for them; dApp B doesn’t have to do a new approval. All that dApp B has to do is check if there’s an existing approval, and if there is one, they can simply ask the user to sign an off-chain message allowing them to spend that approval, and dappB can transfer USDC directly if they submit the off-chain permit message alongside the transfer request. It really is that easy!

The traditional token approval process requires users to trust a protocol or dapp and then approve that protocol. If that protocol is compromised, then the user's tokens may be lost. The current process goes as follows:

User sends an approve() transaction authorizing a protocol or dapp to transfer their tokens
The Dapp can now transfer tokens on behalf of the user

Now, haters will say EIP-2612 solves this problem already, and while the token approval process is similar to Permit2, there are some subtle differences. EIP-2612 adds three new functions to the ERC-20 token standard: permit(), nonces(), and DOMAIN_SEPARATOR() to combine the consumption of token approvals and other standard ERC20 functions such as transfers. You can read more about EIP 2612 here. EIP-2612 adoption has been stymied because it can only work for new or upgradeable tokens.

Permit2, however, works with existing ERC20 tokens; no upgrades are required, and new dApps or protocols can write Permit2 convenience functions or simply use the Permit2 canonical contract to permission approvals and transfer tokens directly and safely.

With Permit2 however, a user will have to approve the canonical Permit2 contract that lives at this address across multiple chains, namely mainnet Ethereum, Goerli, Polygon, Optimism, Arbitrum, and Celo. After which any integrating protocol or dapp can submit a users’s Permit2 msg and signature and have tokens transferred seamlessly.

Repo

Here's the link to the repo I use in this guide.

Technical Details

In other Permit2 guides, the writers assume that there’s an intermediate protocol that sits between Alice and the Permit2 canonical contract; for the purpose of this article, we’ll assume the underlying dapp or protocol is represented by an address and the dApp will communicate with the canonical Permit2 contract directly, this is a frontend guide after all. For some background, I’m using this frontend template that’s not Web3 enabled, we’ll install a few dependencies that work with the Permit2 SDK, out of the box. So let’s get started.

Install Next.JS

You can choose to start a new Next.JS implementation but I used this template to get me up and running a little bit faster so feel free to start one of your own or do something else.

gh repo clone sozonome/nextarter-chakra

Install the Permit2 SDK

The first step is to install Permit2 SDK, which provides a few helpful functions that allow anyone to get started as quickly as possible. The only caveat is that the Permit2 SDK only works with the Ethers 5.7.2. Fun times, I know! Because of the joys dependency graphs, we’ll restrict ourselves to using this for now but it’s not required, you can make the various contract calls independently, that would just be outside the scope of this guide.

yarn add @uniswap/permit2-sdk ethers@5.7.2

We also add ethers js 5.7.2 as a SDK dependency. We’ll need it later on to pass providers to the SDK.

Add a few state variables

Because we are building a frontend using React, we can add a few state variables that we can use to control the state of the frontend.

const [account, setAccount] = useState<string>('')
const [spender, setSpender] = useState<string>('')
const [provider, setProvider] = useState<ethers.providers.Web3Provider>()
const token = '0x4f34BF3352A701AEc924CE34d6CfC373eABb186c'

The account variable stores the currently connected address
spender is a convenience function that we use to pull an additional address
provider holds the Ethers provider that we need to use to build a signer and also interact with the Permit2 SDK
Token represents the Polygon Ecosystem Token on Goerli. This will be the main token contract that we will be interacting with.

Connect Wallet Feature

Next, we’ll add a Connect Wallet feature to the dApp that will toggle the state depending on if a wallet is connected.

<Flex
  direction="column"
  alignItems="center"
  justifyContent="center"
  minHeight="70vh"
  gap={4}
  mb={8}
  w="full"
>
     <Text mb={4}>Welcome</Text>
     {account ? (
       <>
         <Button onClick={handleApprove} mb={4}>
           Authorize Permit2
         </Button>
         <Button onClick={handlePermit}>Permit</Button>
         <Text mb={4}>Account: {account}</Text>
       </>
     ) : (
       <Button onClick={connectWallet}>Connect Wallet</Button>
     )}
 </Flex>

Once we have the frontend elements, we can add the Connect Wallet function to connect to the user’s wallet.

const connectWallet = useCallback(async () => {
   try {
     // eslint-disable-next-line @typescript-eslint/no-explicit-any
     const address = await (window as any).ethereum.request({
       method: 'eth_requestAccounts',
     })
     setProvider(
       new ethers.providers.Web3Provider(
         // eslint-disable-next-line @typescript-eslint/no-explicit-any
         (window as any).ethereum
       )
     )
     setAccount(address[0])
     setSpender(address[1])
   } catch (e) {
     // eslint-disable-next-line no-console
     console.error(e)
   }
 }, [])

This code block connects to the window.ethereum object which returns an array of addresses that the user has enabled.

NOTE: This guide assumes at least two connected Ethereum addresses, the second address is not required for Permit2 to work, it just allows us to mock a protocol address.

If you have configured everything correctly, once you connect your wallet, your frontend should look like the image below.

Approve Permit2

This isn’t a required step to use Permit2, but it helps to ensure that a user has approved the Permit2 canonical contract to spend tokens.

Let’s add a button to enable approvals

<Button onClick={handleApprove} mb={4}>
   Authorize Permit2
</Button>

And the logic for the Approval is fairly straightforward. First, we can now import from the Permit2 SDK library.

import {
 AllowanceProvider,
 PERMIT2_ADDRESS,
 MaxAllowanceTransferAmount,
 AllowanceTransfer,
} from '@uniswap/Permit2-sdk'

The handleApprove function assigns a signer, which will prompt the user to sign the approval message and then submit a transaction.

const handleApprove = useCallback(async () => {
   try {
     const signer = provider!.getSigner(account)
     const permit2ContractAbi = [
       'function approve(address spender,uint amount)',
     ]
     const permit2Contract = new Contract(token, permit2ContractAbi, signer)
     const tx = await permit2Contract.approve(
       PERMIT2_ADDRESS,
       MaxAllowanceTransferAmount
     )
     await tx.wait()
   } catch (e) {
     // eslint-disable-next-line no-console
     console.error(e)
   }
 }, [account, provider])

Permit2 Config

Now we get to the main stuff. The handlePermit function processes the main Permit2 transfer. There are a few important steps that we will go through.

const handlePermit = useCallback(async () => {
   const processPermit = async () => {
     const signer = provider!.getSigner(account)
     const allowanceProvider = new AllowanceProvider(
       provider!,
       PERMIT2_ADDRESS
     )
     // Address of the protocol contract that is being approved to spend tokens.
     const SPENDER_ADDRESS = spender
     /**
      * Get the current allowance amount, expiration, and nonce using the AllowanceProvider.
      * This is the same data that would be used to create a PermitSingle object.
      * You can check permitAmount or expiration on this data to determine whether you need to create a new permit.
      */
     const {
       // amount: permitAmount,
       // expiration,
       nonce,
     } = await allowanceProvider.getAllowanceData(
       token,
       account,
       SPENDER_ADDRESS
     )

     /**
      * Create a PermitSingle object with the maximum allowance amount, and a deadline 30 days in the future.
      */
     const permitSingle: PermitSingle = {
       details: {
         token,
         amount: MaxAllowanceTransferAmount,
         expiration: toDeadline(/* 30 days= */ 1000 * 60 * 60 * 24 * 30),
         nonce,
       },
       spender: SPENDER_ADDRESS,
       sigDeadline: toDeadline(/* 30 mins= */ 1000 * 60 * 60 * 30),
     }

     const { domain, types, values } = AllowanceTransfer.getPermitData(
       permitSingle,
       PERMIT2_ADDRESS,
       provider!.network.chainId
     )

     const signature = await signTypedData(signer, domain, types, values)

     const permitAbi = [
       'function permit(address owner, tuple(tuple(address token,uint160 amount,uint48 expiration,uint48 nonce) details, address spender,uint256 sigDeadline) permitSingle, bytes calldata signature)',
       'function transferFrom(address from, address to, uint160 amount, address token)',
     ]

     const permitContract = new Contract(PERMIT2_ADDRESS, permitAbi, signer)
     await permitContract.permit(account, permitSingle, signature)
   }
   processPermit()
 }, [account, provider, spender])

We begin by creating an AllowanceProvider object, which will contain many of the features we need for Permit2 transactions. The AllowanceProvider class is instantiated by passing a provider and the canonical PERMIT2_ADDRESS.

const {
       amount: permitAmount,
       expiration,
       nonce,
     } = await allowanceProvider.getAllowanceData(
       token,
       account,
       SPENDER_ADDRESS
     )

We read the current Permit2 status by querying the canonical address for the specific token approval amount, expiration and nonce. You can run checks at this stage and adapt behaviour according to your preferred business logic. From this point, we begin to see the real magic of Permit2. We are constructing a PermitSingle request, but this can be done as part of a batch using PermitBatch, this opens the door to multiple token approvals.

From this stage, you need to sign the transaction details

const { domain, types, values } = AllowanceTransfer.getPermitData(
       permitSingle,
       PERMIT2_ADDRESS,
       provider!.network.chainId
     )
const signature = await signTypedData(signer, domain, types, values)

getPermitData() takes the permitSingle object, the canonical address and the chain ID to construct a signature. The signTypedData() is a Uniswap library helper method designed to work around some limitations in wallet configurations, I’ve found it very useful when working with this version of ethers so I recommend using it.

> yarn add @uniswap/conedison

import { signTypedData } from '@uniswap/conedison/provider/index'

To be clear, once you have a valid permitSingle and signature, you have all you need to perform any Permit2 operation. The remainder of this guide fleshes out our use case.

Permit2 Transaction

Once you have gotten the signature, you have the ability to perform a token transfer either via your dapp smart contract or directly interact with the canonical Permit2 address that exposes some useful functions.

const permitAbi = [
       'function permit(address owner, tuple(tuple(address token,uint160 amount,uint48 expiration,uint48 nonce) details, address spender,uint256 sigDeadline) permitSingle, bytes calldata signature)',
       'function transferFrom(address from, address to, uint160 amount, address token)',
     ]

     const permitContract = new Contract(PERMIT2_ADDRESS, permitAbi, signer)
     await permitContract.permit(account, permitSingle, signature)

Fun fact: I learned the hard way that when constructing your own ABI, a Solidity struct has to be structured as a tuple. This means you have to define the struct members as parameters of a function of the tuple and name it. The permitSingle struct is a bit confusing, seeing as it’s a tuple by itself, and also has a child details struct that is also represented by a tuple. Now I know some older heads are probably laughing at me at this point but this was the first time I was building an ABI manually and it was a fun rabbit hole to go down. If you don't understand what I mean with this tuple business, no worries, just read your ABIs the way you're used to. I just pull ABIs from Etherscan.

From this stage, you can submit the transaction and that’s all it takes to approve and transact with Permit2. Backwards ERC-20 compatibility for the win!!

I’ve included a few more convenience features on the frontend that pull a user's Permit2 token approval details so the UI is a little more feature rich than described in this guide as you can see below, nothing too fancy, just stuff that should help developers get started as soon as possible.

Next steps:

I’d like to see Uniswap Labs and the ecosystem at large advocate for more Permit2 adoption; it’s great when no-brainer UX implementations like this can become more mainstream.
Adding viem support to the SDK would be great.

References:

The Complete Full-Stack Guide to Getting Started with Zero-Knowledge Proofs using Circom and ZK-Snarks - Part 2

Tony Olendo — Thu, 26 Jan 2023 01:08:13 +0000

Welcome to the second part of this series where I try to demystify zero-knowledge proofs (ZKPs) for the rest of non-math nerds . Since writing part 1, my thoughts on the subject have evolved. I’m more drawn to answering the following questions

Can anyone be a ZK developer?
Is there a simple path that we can define for anyone to get started in writing ZK circuits?

The simple answer to all the questions above is yes! Most assuredly, yes. How? Just learn Circom and you’ll be well on your way.

What is Circom? Circom is a circuit programming language and a compiler that allows programmers to design and create their own arithmetic circuits for Zero Knowledge Proofs. In other words, it makes it easier for any developer to get started writing ZKPs. Later we’ll look at some key Circom features and the most crucial piece of Circom, understanding polynomial constraints, but let’s start by understanding arithmetic circuits and why they are so important to Circom.

Arithmetic Circuits

Most programming languages today are based on a Turing Machine, which is the foundation of computer science today given their ability to compute any function. On the other hand, an arithmetic circuit is a set of gates with separate inputs for each number that must be processed. The gates are connected so as to carry out an arithmetic action and the outputs of the gate circuit are the digits of the result (addition, subtraction, multiplication, or division).

For ZK cryptographic processing, arithmetic circuits are preferred over Turing Machines for a number of reasons:

Efficiency: Circuits are generally more time and space efficient as compared to Turing machines because circuits are comprised of a fixed set of gates.
Verifiability: Circuits are better suited at proving a ZKPs’ computation is correct compared to Turing Machines.
Compactness: Circuits are better suited to representing ZKPs’ complex and large computations by using a relatively small number of gates with reduced space requirements as compared to Turing Machines.

Polynomial Constraints

A huge limitation I’ve seen most new Circom developers struggle with is how to express conditional statements as polynomial constraints. This is the most significant difference any programmer needs to understand when writing Circom circuits. But what are Polynomial constraints and how do they work?

In Part 1 of this series, we converted the expression

if (x < 5) y = 7 else: y = 9

y = 7 * (x < 5) + 9 * (x >= 5);

This is a simple expression of a conditional statement as a quadratic equation and this goes to the heart of a key feature of Circom. In order to write circuits, one needs to understand polynomial constraints. A polynomial constraint is a mathematical statement that involves polynomials and sets limits on the values that the variables in the polynomial can take. For example, the polynomial "3x^2 + 2x + 1" is made up of the variables x and x^2, the coefficients 3 and 2, and the constant term 1. A polynomial is an expression made up of variables and coefficients, arranged according to certain rules of exponents.

In a polynomial constraint, the variables in the polynomial are subject to certain conditions or limits. These conditions can be equalities (e.g., "x^2 + y^2 = 1") or inequalities (e.g., "x^2 + y^2 < 1"). Polynomial constraints are often used in optimization problems, where the goal is to find the values of the variables that maximize or minimize a given function subject to certain constraints. For example, consider the optimization problem of finding the minimum value of the polynomial "x^2 + y^2" subject to the constraint "x + y = 1."

In this case, the constraint limits the values that x and y can take, as they must add up to 1. The solution to this problem would be x=y=0.5, which is the point at which the polynomial "x^2 + y^2" is minimized.

We’ll delve deeper into constraint generation in Circom and how they function.

Key features of Circom

Circuits in general are composed of a couple of core features, inputs, wires, and an output. Circom requires developers to express their computations in the form of arithmetic circuits and a few Circom features parallel these traditional circuit setups:

Signals (inputs)
Constraints (wires)
Output

Let’s introduce a simple circuit that we can use to demonstrate some key Circom features


pragma circom 2.0.0; 

template Factor () {  
   signal input a;  
   signal input b;  
   signal output c;  

   // Constraints
   c <== a * b;  
}

The circuit above multiples a and b and outputs the value as c. Let’s delve into a few of the features of the Circom language seen here.

Pragma

pragma circom 2.0.0

The line above is the version pragma and it specifies what compiler version the circuit is compatible with. If you don’t specify a pragma version, then the latest compiler version will be used and a warning will be shown.

Template

template Factor () {

A template is used to generate circuits, think of them as objects that receive inputs, process computations and produce outputs. They are defined by instantiation and can be reused.

A quick note on Templates, they are composable, meaning they can be reused to build bigger more complex circuits. A template is instantiated using the keyword component. So for instance, if we are to reuse our example circuit above, we would instantiate this as

component multiplier = Factor ()

And we’d then pass signals using the in keyword and output the computation using the out keyword.

signal intermediary // holds a temporary value
component multiplier = Factor()
multiplier.a ⇐ 8;
multiplier.b ⇐ 32;
intermediary ⇐ multiplier.c;

Here we introduce a temporary signal that will hold the value of the computation and we assign input and output values. Template reuse is a huge part of Circom and the Circom library continues to grow. I’d recommend reading through the various libraries to understand more about Circom.

Signals

signal input a;  
signal input b;  
signal output c;

Going back to the analogy of electrical circuits, in Circom, signals can be thought of as the basic units of information that travel through a circuit. Signals power computations meaning that regular mathematical operations can be performed using signals.

Signals are private by default but they can hold input, output or intermediary values. Intermediary signals hold values inside of a circuit.

Constraints

So everything we’ve done so far has been “wax-on, wax-off” (am I dating myself using this Karate Kid reference? maybe), we can now bring all this together. In Circom, everything comes down to writing constraints. Constraints can only be quadratic equations. Simply put, they should take the form of X + Y * Z = 0. I’m deliberately not going to delve any deeper into this for now but we can demonstrate this further by looking at how this works.

Let’s take a look at the XOR gate template from CircomLib

pragma circom 2.0.0;


template XOR() { 
   signal input a;
   signal input b;
   signal output out;

   out <== a + b - 2*a*b; 
}

This XOR template evaluates to true if only one input is true, take not of how the out signal is assigned out <== a + b - 2*a*b which essentially constrains the circuit to a given quadratic computation.

In Circom, constraints can be applied using the === or the <== operator. The former is an equality operator. Using the ===operator in the form of a * 1 + b === 0 is sufficient for the compiler to generate constraints and for your circuit to work.

The <== allows you to combine signal assignment and constraint generation in one go, improving the readability of your code. A lot of Circom libraries use this convention.

Now, there is a <-- operator that can be used for signal assignment but (shameless name drop here) I work at Polygon and as such I get the chance to interface with Jordi Baylina who created Circom and his advice is to me, which I pass on to you, is to always use double equals. This ensures that you’re always writing quadratic equations and generating constraints. If you somehow manage to write a circuit without constraints, the compiler will not play nice.

So when in doubt, do what Jordi said, always use double equals unless you absolutely know why you’re using something else.

Conclusion

So we have reviewed a few features of Circom and the underlying paradigms required to write Zero-Knowledge Circuits in Circom. I think anyone can be a ZK developer using Circom and in the next part, we’ll delve into a sample circuit that highlights how to write polynomials constraints, the Rank 1 Constrain System, a Powers of Tau ceremony and eventually generate a Solidity file that you can deploy on-chain and build a full stack Dapp around. Exciting stuff!!

The Complete Full-Stack Guide to Getting Started with Zero-Knowledge Proofs using Circom and ZK-Snarks - Part 1

Tony Olendo — Tue, 27 Sep 2022 22:44:27 +0000

Introduction

Zero-knowledge Proofs (ZKP) have picked up a whole ton of interest in the last couple of years. We are super early in ZKP applications and yet we are already met with exciting use-cases that will only continue to grow in order to provide privacy-saving mechanisms for our digital lives. This guide is targeted at software developers who are ZKP curious by clarifying what ZKPs are while using the least math possible and still explaining how it works and how teams can get started with their ZKP projects. Needless to say, a lot more further reading is required to get fully up to speed with ZKPs but the goal here is to show you how you can use Circom to get started and shed some light on some known unknowns on your ZK journey.

Circom, is a circuit programming language and a compiler that allows programmers to design and create their own arithmetic circuits for ZKP. We’ll discuss common pitfalls in using Circom, the most important paradigm to have when developing in Circom and ways you can write and extend your own Circom circuits using existing Circom libraries.

This guide will gloss over very key points about ZKPs in order to get readers coding with Circom as soon as possible. The “Further Reading'' section will provide useful links.

This article is broken down into 4 sections, we will cover only section 1 and 2 in this instalment.

What are Zero-Knowledge Proofs and how do they intersect with Web3 (Theory)
Key Paradigms (Theory)
Circom and Solidity (Coding)
Full-stack React application using Next.js (Coding)

What are Zero-Knowledge Proofs and How Do They Intersect with Web3

Zero-Knowledge Proofs can simply be defined as the ability to prove you know something without revealing what you know. Think, for example, that you have to prove to a travel website, say an airline, that you are indeed a citizen of a given country without having to show them your passport and that the website will verifiably know that what you are saying is true. Sounds wild? I know but this ZKP accuracy and reliability is really high. This, and many other scenarios, are why ZKPs are all the rage right now. ZKP’s privacy-preserving properties are changing the fundamentals of how the Web works.

Components of a ZKP

ZKPs can either be interactive—where a prover convinces a specific verifier but needs to repeat this process for each individual verifier—or non-interactive—where a prover generates a proof that can be verified by anyone using the same proof.

The three fundamental characteristics that define a ZKP include:

Completeness: if the statement is true, an honest verifier will be convinced of this fact by an honest prover.
Soundness: if the statement is false, no cheating prover can convince an honest verifier that it is true, except with some small probability.
Zero-knowledge: if the statement is true, no verifier learns anything other than the fact that the statement is true. In other words, just knowing the statement (not the secret) is sufficient to imagine a scenario showing that the prover knows the secret.

Important note: ZKPs don’t necessarily equate to privacy, they equate to honest computation. The honest computation can be the foundation of a privacy tool, product or protocol. ZKP is a cryptographic standard not a privacy panacea in and of itself.

History of ZKPs

In 1985, an MIT paper by Shafi Goldwasser and Silvio Micali titled “The Knowledge Complexity of Interactive Proof-Systems” introduced the concept of ZKP which defined protocols in which interactive proofs that involve two kinds of entities: a prover and a verifier, interact over a number of rounds by sending messages.

Prior to their paper, there was a lot of focus on interactive proof systems and the concept of Soundness, where a malicious prover attempts to trick a verifier. The concept of Soundness in which a mathematical statement is defined as sound if and only if every formula that can be proved in the system is logically valid with respect to the semantics of the system. Goldwasser, Micali and Rackoff changed the fundamentals of interactive proofs by asking “what if you don’t trust the verifier?” They asked, how much extra information is the verifier going to learn during the course of this proof, beyond the mere fact that the statement is true?

By limiting this exposure of information, their proposed proving system provided the least amount of information to either party. While the approach was novel, a key limitation of this system was the requirement for interactivity. This meant that both prover and verifier had to send each other multiple messages of varying mathematical complexity in order to complete the verification process.

What has since emerged are a number of proving systems, like STARKs, SNARKs, BulletProofs etc that, broadly speaking, remove the need for interaction between prover and verifier by using a secret key. These proving systems have different benefits, drawbacks and value propositions but you can find out more about them here.

Applications in Web3

There are a number of exciting applications of ZKPs in Blockchain technology. I’ll highlight two that relate to technology that I interact with in my role at Polygon.

zkEVM: The zkEVM wars are upon us and Vitalik’s blog post defines the parameters of different zkEVM types. The endgame for zkEVM is providing a scaling solution for Ethereum. You can learn more about Polygon zkEVM here.
Polygon ID: Self-Sovereign Identity (SSI) is an exciting development of the internet that seeks to provide an identity layer to the internet. The core contention being that the internet should end with you, not your IP address. Polygon ID is a blockchain-native identity system with programmable privacy that empowers people and enables the creation of trusted interactions with web3 services.

Key Paradigms

This guide is intended to provide hands-on instructions on getting started with Circom and we will be focusing on using the Snark tool that uses zk-SNARK under the hood but we have to define what zk-SNARKS are.

zk-SNARKS

zk-SNARK stands for “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge”, let’s break this down:

“zk”: Zero-Knowledge, this was defined above
“Succinct”: the proof that is generated is short. This is ideal because it means that our proofs can be stored on a blockchain, inside of a single transaction. This is particularly useful if we are looking at different applications of ZK such as Polygon ID.
“Non-interactive”: This non-interactive component allows the verification to occur without having to send messages between the prover and the verifier. Gross oversimplification but think of this as a driving license being verified without having to hit the DMV’s API.
“Argument” : we don’t quite use mathematical proofs but we do provide a form of them for ZKPs to work
“Knowledge”: the information that the prover has

zk-SNARKs are just one protocol that has various proving systems. I’d recommend further reading on ZK proving systems such as Pinocchio, Groth16, Plonk, Plonky2. Also, the guide “Why and How zk-SNARK Works: Definitive Explanation” is seminal text in understanding zk-SNARKs.

There is a general criticism of zk-SNARKS that in the generation of it’s key, there is still a requirement of a trusted setup in order to generate a witness, we’ll delve more into that in the coding section of this guide.

Arithmetic and ZKPs

If I was to choose the most crucial piece in understanding ZKP, it would be this, how do you convert your computations into algebraic expressions? This is by far the part of Circom that gives new developers the most grief. Let me attempt to break it down for you.

The goal of ZK is to verify computations and according to Kineret Segal & Shir Peled here, the first step “... is the translation (often referred to as ‘reduction’) of the problem of verifying a computation to the problem of checking that a certain polynomial, which can be evaluated efficiently on the verifier’s side (this is the ‘succinctly’ part), is of low degree.”

Polynomials are fundamental to understanding ZKPs given that we can present a polynomial with arguments that essentially verifies the computation. There are entire domains of study dedicated to explaining ZK math, such as the absolutely awesome ZK Hack Whiteboard Series which I highly recommend. This guide is purposefully light on this subject.

In its most simplest form, the biggest change a developer needs to make is learning how to write traditional control structures as quadratic constraints. To borrow from Vitalik’s example, we can see how this changes in arithmetic circuit programming.

Traditional control structure:

if x < 5: y = 7; else: y = 9)

To Quadratic Control Structure

y = 7 * (x < 5) + 9 * (x >= 5);

The key to understanding how to shift in thinking is by noting how the value of y changes in both statements depending on the value of x. This is the main difference in arithmetic circuit programming, well, this and understanding logic gates but if it still doesn’t make sense, don’t worry. In the next section, we delve into a Circom example that illustrates this difference even better.

In the next section, we’ll get up and running with Circom and get you writing your first ZKP Dapp. I hope this theory section provides sufficient clarity about ZKPs.