**HEY!** Have questions? Read our recently written FAQ!

Ziesha (ℤ) is a new layer-1 cryptocurrency which uses **Zero Knowledge proofs** as the back-end of its smart-contracts, focusing on a more scalable (Yet maintainable) blockchain by compressing transactions through zkRollup-like circuits. In order to keep the protocol simple, the smart-contracts are expressed as mathematical constraints instead of bytecodes of a virtual machine.

ℤ

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

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

* - 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.

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

Now, here is the mind blowing fact:

The * proof* that you provide is constant in size, no matter how big the

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. Ziesha 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 that its tip state is not available, worths 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.

The equivalent of a Smart Contract in Ziesha blockchain is a * Zero Contract*. The contracts in Ziesha blockchain are not written for a specific virtual-machine (Like EVM), but written in

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 thausands of transactions).

Follow us on GitHub! Contribute to the project either by coding or promoting it. 💸