For detailed technical information, read the Zeeka Whitepaper! Also, we are actively developing the Zeeka project. Follow us on GitHub!

**Huh? Zero-Knowledge proofs?**

A Zero-Knowledge protocol is a crytographic method by which someone can prove that they know the __ answer__ of a

__without actually revealing it. A very good example of an interactive Zero-Knowledge proof is provided below:__

*problem*- Suppose Alice is blindfolded and has two balls in her hands. Bob, who is able to see the balls, claims that the balls are different in colors. Alice doesn't trust Bob. How can Bob convince Alice that the balls have different colors (The problem), without uncovering Alice's eyes (Revealing the answer)?

Here is what Alice does:

- She first hides the balls behind her back.
- She shuffles the balls with a 50% chance.
- She shows back the balls to Bob, and ask him: -
*Did I shuffle the balls?*

If the balls are really different in colors, Bob would give Alice the correct answer. If he can't distinguish their colors, he still can give Alice a random answer, and his answer can still be correct. But the chances of giving a correct answer is 50%.

Alice repeats the procedure for 20 times. If the balls have same colors, the chances of Bob giving the correct answer all the 20 times is (1/2)^20 (Around 0.000001%). The probability is so tiny that Alice can conclude that Bob is really able to distinguish between the balls, leading to the conclusion that they really have different colors.

**What are you trying to prove?**

Suppose there is a novel payment system that consists of a merkle tree in which every leaf represents an account (A public key and a balance). We define the state of the system as the merkle root of this tree.

We want to prove a big set of transactions have happened, changing the state of the system from A to B (The problem), without showing the transactions (The answer).

Now, here is the mind blowing fact:

The proof that you provide is constant in size, no matter how big the answer is. E.g the answer can be millions of transactions, but you don't need to show them for the state transition to happen. A constant sized proof is enough to convince everyone that the state transition is valid!

**Ehmmm, Ethereum already has this with zkRollups?**

You got us! But hey, there is a big difference. In zkRollups, there is a centeralized operator, constantly publishing Zero-Knowledge proofs on the main chain, and in case the operator stops doing this (i.e gets unavailable), the chain will roll back to a previous state, from which some other operator is able to build on. This is a huge amount of complexity.

Blockchains like Ethereum/Bitcoin, enforce data-availability of the chain history, and not a SNARK state. Zeeka nodes and validators are implemented in a way to only accept forks that reveal the chain state of their last block, meaning that they will check if the hash of the provided state results in the state-hash submitted on the last block. This mechanism makes sure that the compressed state of the last block is always available. A longer subchain whose tip state is not available is worth nothing and is not accepted by the network. This removes the mentioned complexities by a great deal and creates room for some creativity as well.

**Okay, how are you going to handle smart-contracts?**

The equivalent of a Smart Contract in Zeeka blockchain is a Zero Contract. The contracts in Zeeka blockchain are not written for a specific virtual-machine (Like EVM), but written in R1CS (Which is the building block of zkSNARK circuits).

In this scheme, the programmer uploads the verifying keys of his R1CS contract (Which can consist of multiple circuits) on the blockchain and people could easily invoke these circuits and move from one state into another with a single small transaction (Which could be a compressed version of thousands of transactions).