Skip to content
Gallery
Blockchain One Pager
Getting Started
important ppts
AMAs
More
Share
Explore

Comments from Enzo - Interactive ZK

To understand zero-knowledge better, let’s have a story before definition:
Enzo loves coke-zero so much, and he could even taste the difference between coke-zero and regular coke.
Enzo is a very private person, he does not want to reveal his knowledge (how to distinguish Coke) to Gareth
Gareth highly doubts about it, he thinks Enzo is lying because Gareth cannot prove Enzo is lying by knowing the mechanism. So Gareth prepares a test with two cups of coke.
He asks Enzo to cover his eyes and taste to tell which one is regular coke and which one is coke-zero.
To prove Gareth is not Enzo’s secret spy or they have telepathy etc. Gareth flips a coin and puts either Coke-zero or regular Coke into the cup based on the result.
Test #1, Gareth knows
Cup1: Regular coke
Cup2: Coke-zero
Enzo gets the correct answer just by blind tasting.
Gareth thinks this might be a coincidence, since the P(guessing correct answer)=1/2, btw Enzo is a lucky guy.
Here P=probability
To avoid coincidence, Gareth decides to repeat the test k times.
Test #k, Gareth knows
Cup1: Regular coke
Cup2: Coke-zero
⁠
⁠
⁠
If Gareth tests sooooo many times until
⁠
⁠
⁠
Well it is a limit, but Enzo has almost 0.0000001% probability that he cannot distinguish between Coke and Coke-zero.
If we apply this example to the blockchain
Enzo is honest = Correct state transitions
So if we have a protocal based on the zero-knowledge proof, one party (the prover) can prove to another party (the verifier) that a given statement is true, without conveying any information apart from the fact that the statement is indeed true.
Such a proof could be observed by a third party, or recorded and such a proof would be convincing to anybody.

Definaiton

In cryptography, a zero-knowledge proof or zero-knowledge protocol is a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true.
A zero-knowledge proof must satisfy three properties:
Completeness: if the statement is true, the honest verifier (that is, one following the protocol properly) will be convinced of this fact by an honest prover.
Soundness: if the statement is false, no cheating prover can convince the 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. This is formalized by showing that every verifier has some simulator that, given only the statement to be proved (and no access to the prover), can produce a transcript that "looks like" an interaction between the honest prover and the verifier in question.
The first two of these are properties of more general interactive proof systems. The third is what makes the proof zero-knowledge.
Zero-knowledge proofs are not proofs in the mathematical sense of the term because there is some small probability, the soundness error, that a cheating prover will be able to convince the verifier of a false statement. In other words, zero-knowledge proofs are probabilistic "proofs" rather than deterministic proofs. However, there are techniques to decrease the soundness error to negligibly small values.

Cons of Zk

Although zk-Rollup is secure and efficient, its applications are still limited to payments and swaps. It’s hard to build general-purpose DApps due to the following two reasons.
First, if you want to develop DApps in a zk-Rollup, you need to write all your smart contract logic using a special language (i.e.
R1CS
⁠
). Not only is the syntax of required language complicated, but doing so also demands extremely strong expertise in zero-knowledge proof.
Second, current zk-Rollup doesn’t support composability[1]. It means different zk-Rollup applications can’t interact with each other within Layer 2. Such quality significantly undermines the composability of DeFi applications.
In a nutshell, zk-Rollup is developer-unfriendly and has limited functionality for now.
That’s the biggest problem we want to tackle. We want to provide the best developer experience and support composability within Layer 2 by supporting native EVM verification directly, so that existing Ethereum applications can simply migrate over onto the zk-Rollup as is.

Build general DApps in zk-Rollup

There are two ways to build general DApps in zk-Rollup.
One is building application-specific circuit (“ASIC”) for different DApps.
The other is building a universal “EVM” circuit for smart contract execution.
⁠
“circuit”
⁠
refer to the program representation used in zero-knowledge proof. For example, if you want to prove hash(x) = y, you need to re-write the hash function using the circuit form. The circuit form only supports very limited expressions (i.e., R1CS only support addition and multiplication). So, it’s very hard to write program using the circuit language — you have to build all your program logic (including if else, loop and so on) using add and mul.
Bibliography:
⁠
https://en.wikipedia.org/wiki/Zero-knowledge_proof
⁠
⁠
⁠
https://hackmd.io/@yezhang/S1_KMMbGt
⁠
⁠
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.