This is the first one of my article series on Zero Knowledge. It will be a very long serie with utmost details. This is why I call it a Deep Dive. Everything from the mathematics behind Zero Knowledge to implementation of known algorithms will be included. Let us start immediately, hold your breath…

Zero Knowledge is an incredibly complicated topic. So I am not going to be brief nor going to throw every word I know in here. I am trying to not assume anything about you and your background. If something is off for you or does not make sense to you, feel free to stop and go to the article in which I am trying to cover that topic or throw a question to me. I will do my best to answer. I only assume that you have a pencil 📝 and paper or a tablet with you and you are paying attention. If you have any feedback -good or bad- please let me know. This is not only for me I would love to put a serie that clearifies ZK as much as I can ,so I would love to make improvements, correct myself or clearify anywhere necessary. Here we go.

TLDR: Zero Knowledge is basically proving that you know or have a secret, without revealing it to another party. Anything is considered as information thus anything that is learnt means you have no ZK, including that it was you, who possessed that secret to begin with. If you cannot deny the claim that you possess that information, we cannot talk about full Zero Knowledgeness.

In essence, ZK is a property. Imagine two parties: a Prover and Verifier . As their names suggest, the Prover is trying to prove $^{[1]}$ something, which can be verified$^{[2]}$, to the Verifier . If the Prover proves her secret without revealing it, we can speak of Zero Knowledgeness. On top of that, even if the Verifier is cheating, trying to extract what the secret is and deviates from the protocol, the Prover still should be able to protect her secret. This also includes the case where the Prover can deny that she possesses the secret.

What does extracting mean?

Interactive proofs.

Non-interactive proofs.

In case of a fully

We think like the following when we mention ZKness: Victor knows a bunch stuff. He can compute $^{[3]}$ stuff with what he knows. By computation we do not need a fancy performance, we can simply think that Victor can infer other stuff from what he knows. He can reach conclusions with his knowledge. Whatever he knows right now before interacting with Peggy , let us call it his Knowledge Base KB , and let us call what he can see/conclude from his KB his View V . After Victor ’s interaction with Peggy , Victor should still have his KB and V unchanged except with the addition of the fact that Peggy “may” $^{[4]}$ know something, and she “kind of” proved it; or the opposite Peggy “may” not know since Victor tried to verify but the verification failed. Why did I explicitly used “may” and “kind of” is the essence here. Let us dive into a very popular example directly.

What is this good for?

Zcash

E-voting

Computation

Credit with collateral

letting someone know if the hidden stuff is meant to be showed

when x is large enough

$^{[1]}$ We can think of proofs as the information conveyed that are related to the claim. In our case proofs are almost always bounded mathematically. Imagine a polynomial, $P(x) = (x^{12} - 1)$. If I tell you that I have a polynomial $F(x)$ that is a factor of $P$, I can prove that by simply showing you the division. So in a sense, we are dealing with cases which have proofs, which can be proved mathematically or rather can convince the verifier and computable, thus verified.
$^{[2]}$ Verification can be thought as authentication of the provided information or the claim itself. Here Victor will be trusting probability theory, a.k.a. analysis of random phenomena, to “verify” the claim for himself. So we can basically think that Victor has a verifier function $V(x)$ such that after certain amount of trials in the protocol, $V(x)$ returns either True or False.
$^{[3]}$ As we mentioned a verification function $V(x)$ for verifier, the computation simply can be considered as a function bounded by the computation power of the Verifier. For now, we will not focus on this, but it can be significant to keep in mind that we are dealing with computable elements, meaning that the computation Verifier and Prover performs will not halt. There will be a result of the computation in a reasonable time.
$^{[4]}$ As we will see in the following paragraphs, “may” refers to probabilistically speaking an enormously likely event. This is obtained by the enourmously small error margin $e$ substracted from the overall probability $1$ -> $1-e$ being very very close to $1$.
$^{[5]}$ Transcript refers to the record of the exchanged information. There are case where we refer an actor called the Extractor who has access to internal states of the actors and their performed computations. In our case it can be thought as reading minds of our actors Victor and Peggy. For now, we will think transcript as record of the interaction event in many forms, a written one such as “Peggy went in A, Victor asked for B, Peggy came out from B…”, or a video in which the whole transaction can be watched from. Note that the amount of information can differ from type to type, but of course we can limit this in real world applications.