Skip to content
Gallery
Blockchain One Pager
Share
Explore
Starkware

icon picker
Introduction

The old world

The old world is build on the “Trust system”, we trust the bank, and bank also trusts us.
If you lost trust, then you won’t have social credits, may send to jial even get fines.
Reputation is also important, which attracts future customers

The new world

“Don’t Trust, Verify”
No more third party(ex: accountants) for trust issues
The Integrity is guaranteed by a node to verify the integrity of all transactions in the system
The method to verify is inefficient: all nodes are asked to re-execute (replay) the computations that verify each and every transaction

Pain Points

How can public trust the output of a computation?
Bitcoin: Provide enough information for verification by re-excution
More issue: How can public trust the output of a computation, while preserving financial privacy?

Privacy

Everyone could see all transactions then privacy might be compromised. It also deters individuals, as it erodes human dignity. Damn it is about dignity!

Scalability

A standard laptop could even run it. Not simply moving to bigger computers and larger bandwidth.

Proof System

Interactive Proof

Interactive proofs are protocols that involve two kinds of entities
a prover
a verifier, who interact over a number of rounds by sending messages
And their goal is different
the prover wants to convince the verifier
the verifier is entrusted by the public to find out falsities
At the end
the verifier either accept the new state or reject it

Example by Enzo

Gareth says he can distinguish Coke and Pepsi, Enzo doubts about that.
For the claim to be accepted as true, the answers provided by the Gareth (prover) to the Enzo (verifier’s) queries must be consistent and valid.
If there is mismatch between a statement and reality, and thus expose it as false.【Gareth cannot tell any difference】
We say that a proof system solves CI if when updating the system from state A to state B, the following properties hold:

Completeness

If the prover indeed knows how to change the state from A to B in a valid way then the prover will manage to convince the verifier to accept the change.

Soundness

If the prover doesn’t know how to change the state from A to B, then the verifier will notice an inconsistency in the interaction and reject the suggested state transition.
There remains a tiny false-positive probability, i.e., a probability of the verifier accepting an invalid proof. This probability is a system security parameter which can be set to an acceptable level like 1/(2¹²⁸), similar odds to winning the powerball five times in a row.

Example: Color blindness and Apples

Look at the following diagram to understand how normal vision works and how color blind vision.
image.png
In our hypothetical scenario, the prover has normal vision and the verifier has color blindness.
The former has two apples – red and green.
The verifier thinks that both the apples are of the same color and the prover wants to disprove this without explicitly telling them what the colors are.
This is how it works:
The verifier shows the apples to the prover.
He then hides his hands behind the prover and switches the apples or keeps them as is.
Now he reveals the prover his hands again.
If the verifier has made the switch, the prover will be able to point it out instantly. This proves that the apples are of different colors.
The verifier can repeat the test multiple times to make sure that the result wasn’t a fluke. Let’s look at how this verifies the ZKP properties.
Completeness: Since the prover was honest, they were able to give the correct answer multiple times.
Soundness: The verifier conducted the test multiple times to make sure that the results were fluke-free.
Zero-Knowledge: The prover never revealed the apples’ colors.

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