Rob Behnke
December 20th, 2022
Zero-knowledge proofs (hereafter ZKPs) are becoming quite popular in the blockchain space. You can get a basic understanding from our previous article on ZKPs here. This article takes further steps to explain ZKPs and the working principle of the zk-SNARK in the area of verified computing.
Authentication is one of the most important and complicated challenges in blockchain and cryptography, similar to digital signatures. There are two ways to solving the leakage of private information:
The latter is a cryptographic protocol referred to as Zero-Knowledge. A ZKP provides an answer that does not reveal the exact information requested but proves to be able to solve the underlying problem.
The goal of ZKPs is for a verifier to be convinced that a prover possesses the knowledge of a secret parameter, a witness which satisfies a relation, without revealing the witness to the verifier or anyone else. Mathematically, a prover $P$ ****claims to know a witness $w$ ****which satisfies a property of a designated output $y$ ****of a cryptographic hash function $h$ ****such that:
$h(w) = y$
This SNARK technology can be adopted in several scenarios such as the following:
Due to these different possible applications, there are many ways to implement a ZKP. They are categorized into two types:
This article focuses on the Non-interactive ZKPs or zk-SNARKs.
Zero-Knowledge Succinct Non-interactive Arguments of Knowledge (or zk-SNARK) is a method of proving that something is true without revealing further information.
Assuming you are in possession of a dataset whose digest string is publicly known, and you want to convince people to know that you own it, you have two options:
Now that we have learned about the use cases of zk-SNARKs, let’s see how to create one.
This section will introduce the steps involved in constructing a zk-SNARK for a particular use case. Technically, you have a computer program writing in a general purpose programming language such as C++, Rust, or Go. The program collects the witness w as input, applies a hash function h to it, and checks that the output equals y.
Appling a SNARK to a program can’t be done directly unless the program is converted into an equivalent model amenable to probabilistic checking. This refers to a type of circuit satisfactory instance like the R1CS.
The program is initially broken from the logical steps into smaller bits of operations, resulting in an arithmetic circuit. This breaks the program into steps consisting of common arithmetic operations of addition, subtraction, multiplication, and division. As an example, the cubic equation:
$x^3 + x + 5 = 35$
can be converted to a program:
“
Gofunc arithmeticCircuit(x int) int {
y := x**3
return x + y + 5
}
“
This process is called Flattening. The resulting program only supports basic arithmetic operations, indicial exponentiation, and variable assignment; all of which is sufficient in representing any bounded computation. The resulting program is a series of decipherable statements that can be likened to logic gates in an electric circuit.
This transformation from the program to the arithmetic circuit is called the front end of the system. Afterwards, the Rank 1 Constraint System (R1CS) is built to check that the right direction is used in the arithmetics. The R1CS is a group of three vectors with a single vector as it’s solution such that if
The next step involves converting the R1CS to a Quadratic Arithmetic Program form having the same logic as the program, but uses polynomials instead of the dot notation above.
The final step is to then run a SNARK — the probabilistic proof system — for circuit-satisfiability again. This is referred to as the back end of the system. Example SNARKs include Groth 16, Marlin, PlonK, Ligero, Hyrax, etc.
SNARKs are designed in almost the same steps. The exempted ones are the linear-PCP based SNARKs like GGPR13, the Groth16, Pinocchio, etc. which are among the first main practical implementations of zk-SNARKs. The steps, however, include:
With zk-SNARKs, a company can hide the code logic of their smart contracts. An example of such companies is Aleo, which allows you to deploy dApps without knowing the underlying logic of the smart contract. zk-SNARKs can also be used in Compliance applications like in proving solvency or in zero-knowledge taxes.
While real numbers are used in this article to aid understanding, real world adoption involves finite field elements that are more complex than the example here. This is why zk-SNARKs are referred to as the spooky moon math.
zk-SNARK technology can help reduce the storage size required by modern blockchains by a significant margin.