Zero knowledge, from zero
Prove a fact without exposing the secret behind it.
The Monero page in this notebook told one privacy story, hiding the real spender inside a crowd of decoys. Every Monero transaction signs with a ring of possible signers, so an observer staring at the chain sees many candidates and still walks off with no certainty about who spent. It works. It keeps working. The crowd is finite though, and statistics can nibble at it. Zero knowledge grows out of a stranger question. What if a payment could prove it is legitimate while saying nothing at all about the people or the amounts? A proof that a secret exists, and not one digit of the secret itself.
That idea has a name you'll meet all over this page, a zero knowledge proof: any procedure that convinces a verifier a statement is true while handing over zero information beyond that truth. The name sounds like it shouldn't work. It does. A cave story gets you there before the algebra does, so that's where we're going. Then the arithmetic of doubt, the trick that made proofs portable, the two proof families the industry ships, and the part I actually care about in 2026: identity documents, the biggest honey pots on earth, and how to empty them. Every number carries its date. Three labs run real SHA-256 and real modular arithmetic in your browser.
01The cave that keeps a secret
Picture a cave shaped like a ring. You walk in the single entrance. The corridor splits, and you take the left fork or the right fork. Both forks end at the same locked door set in the back wall, and the door opens for one spoken word. Peggy says she knows that word. Victor, a professional skeptic, wants proof, and she won't say the word or even hint at how long it is. Here's the ritual.
Victor stays outside. Peggy walks in and flips a mental coin at the fork, going left or right as she pleases, and Victor has no idea which path she took. Then he shouts one instruction, come out on the left or come out on the right, picked only after she's already deep in the corridor. That ordering matters. If he had called the side beforehand she could simply walk in on that side and stroll back out again without ever touching the door or needing the word at all.
Now trace both versions of Peggy. The honest Peggy, who knows the word, can answer any call. Asked to exit her own side, she turns around and walks back. Asked to exit the far side she says the word to the door and walks out the other fork, because that lock is hers to open whenever she needs it. She appears at the demanded exit, every single round. The bluffing Peggy, who does not know the word, has no way through the door. She wins a round only when Victor happens to name the side she already stands on, a raw fifty fifty. When he names the other side, she's trapped. The con is over.
One round convinces nobody. A liar wins half the time by luck. So repeat. Victor calls sides freshly and randomly each round, and a liar has to keep winning coin flips. Ten clean rounds leave the liar one chance in 1,024. Twenty rounds leave one in 1,048,576, past a million to one. Nobody forges luck that lopsided, and Victor still hasn't heard a syllable of the word.
Two words and the machinery of this essay is in place. Peggy is the prover, the party holding the secret. Victor is the verifier, the party demanding proof. Real zero knowledge systems compress thousands of cave rounds into a single short mathematical object, but peel any of them open and you're back in this cave, with odds that still halve per round. So first, run the cave yourself.
Lab 01. You're the prover now. The machine is the verifier, and the coin flips come from your browser's cryptographic randomness. Enter runs a trial. Shift+R resets the board. Shift+C copies what you got.
Run it both ways. Keep the word in your pocket and twenty rounds go by, with the meter sliding down to one in a million, while nothing about the word ever hits the console. Uncheck the box and bluff. Half the time the very first call exposes you, and the odds of surviving all twenty rounds sit at that same one in 1,048,576. Honesty costs you nothing. Bluff and you eat exponential pain, and the verifier's knowledge still never grows past one bit.
02One bit at a time
What did Victor actually learn after twenty clean rounds? Exactly one bit: that she knows it. That's the entire leak. A pass has two possible causes, knowledge and luck, and the transcript cannot tell them apart, which is precisely why it is safe to show around.
The lab hides this on purpose. Watch the console after a run and you still cannot reconstruct which rounds used the door, because honest appearances and lucky appearances print identically. That is the distributional fact that makes a zero knowledge transcript safe to publish: you could fabricate a convincing transcript yourself, twenty coin flips and twenty exits, and it would match a real one in distribution. Nothing extractable rides in it.
Compare that with the proof you already know. A Bitcoin transaction convinces by publishing: the signature sits on the open ledger, anyone checks it against a public key, and the whole payment is there to read, forever. Proof and revelation arrive glued together, and the Bitcoin essay is built on that glue. The cave pries the two apart. The verifier ends with conviction and no residue.
The other half of the engine is what a liar faces. Each round is a fresh, independent coin flip, so a faker's survival odds halve with every call. One in two after one round. One in 1,024 after ten. One in 1,048,576 after twenty. Drag the slider and watch a liar's world shrink.
One round, two provers, the same call. Toggle the figure. Knowing the word answers any call. Not knowing it survives only when the call happens to name the occupied fork, one chance in two, and that is where the halving starts.
Hold on to the two facts. A verifier can be convinced to a certainty you choose, one bit of doubt at a time, and the transcript stays empty of anything else. Everything later on this page is engineering built on those two facts.
03The challenger becomes a hash
The cave has an operational problem. It is interactive. Victor has to stand at the entrance, flip a coin, and shout, twenty times, for every single proof. A blockchain has no Victor at the door. It has thousands of verifiers, most of them offline when the proof is made, and a proof posted to a chain has to stay checkable years later by someone who never met the prover. Coin flips from a live challenger cannot be stored in a block.
The fix is to replace the challenger with a hash function. The shape of the trick goes back to Amos Fiat and Adi Shamir in the 1980s, and it carries their names: the Fiat Shamir transform. Peggy first publishes her commitments, the twenty fork choices in the cave's language. Then, instead of waiting for Victor, she derives the challenges herself, as bits of SHA-256 applied to everything committed so far. A hash output is unpredictable before you compute it and deterministic after, which is exactly the resume the job demands. The challenges stop being a conversation and become a function of the transcript.
Two consequences follow. First, the proof collapses into one message that anyone can check whenever they like, no live verifier, no schedule. That is the N in SNARK, non interactive, which the next section unpacks. Second, the faker inherits a harder job than before. He commits first, and only then does the hash speak. To survive twenty rounds he cannot outguess a coin anymore. He has to hunt for commitments whose hash happens to spell out his own twenty choices, and every candidate costs real computation. The odds of a lucky find are the same one in 1,048,576. The hash didn't weaken the protocol. It just moved who flips the coin.
Lab 02. Real SHA-256 decides every challenge: the first bit of the hash over a label, the seed, and the round number. The faker commits before the hash speaks, which is the whole security argument. Toy scale, real hash.
Watch the derived challenge string. It reads like coin flips because hash bits are uniform: the comparison pass runs 256 fakers against hash derived challenges and 256 against real coin flips, and the survivors track each other round for round, both halving on schedule. The grind button then attacks the transform the only way left, hunting seeds whose hash happens to match a fixed entry string, and reports the longest prefix it managed to buy. Tens of thousands of seeds in, you're typically sitting on fifteen or sixteen matching rounds, and the full twenty costs the same million to one as the cave, paid in electricity instead of luck.
04SNARK against STARK
Two families carry this machinery into production. One honest paragraph each is enough to split them, because the split is about what you pay and what you trust.
zk SNARKs can produce compact proofs that are fast to verify. Many early constructions required a trusted setup: someone generated starting parameters and had to destroy the secret material used to create them. Multiparty ceremonies reduced that risk because the parameters remain sound if at least one contributor destroyed their secret. Zcash's Sprout ceremony in 2016 had six participants. The 2018 Sapling ceremony took 88 contributions in its open phase and more than 90 in a second phase. Newer proof systems offer different tradeoffs. Halo 2, used by Zcash Orchard, needs no trusted setup, while many other SNARK systems still use one. Section 05 follows that history.
zk STARKs, the StarkWare line, need no ceremony ever, because their security sits on hash functions and error correcting codes rather than elliptic curves, which also makes them resistant to quantum attack in principle. You pay in size. STARK proofs run tens to hundreds of kilobytes, fine for a server proving a whole batch of computations, heavy for a phone proving one payment. Neither family wins outright. STARKs get the transparent setup and the post quantum hedge. SNARKs get compactness. Modern systems frequently stack a SNARK on top of a STARK to compress it.
05Where zero knowledge already runs
The first production run of this machinery was money. Zcash has carried shielded payments on a public chain since 2016. The 31 May 2022 NU5 upgrade activated Orchard and removed its need for a trusted setup. The notes, nullifiers, and pool arithmetic belong to the coin, and they have their own page: Zcash from zero.
The science has a paper trail. Zerocoin came from a Johns Hopkins group in 2013. The direct ancestor appeared a year later: the Zerocash paper, published at the 2014 IEEE Symposium on Security and Privacy. Its seven authors were affiliated with the Technion, Tel Aviv University, MIT, and Johns Hopkins. The founding science was Israeli and American together. The US based Zcash Company later shipped the coin. Two Zerocash authors, Eli Ben Sasson and Alessandro Chiesa, later joined Michael Riabzev and Uri Kolodny to found the separate Israeli company StarkWare.
06The KYC honey pot problem
Now leave money behind. Many services ask for a passport, a selfie, and proof of address when they perform KYC, short for know your customer. Storing those records creates a concentrated target.
One documented example is enough to show the risk. Lithuania's State Data Protection Inspectorate reported that a September 2022 social engineering incident gave an attacker access to a Revolut database. Data linked to about 50,150 customers could have been affected, including names, addresses, email addresses, phone numbers, masked card data, and account details. The regulator's incident notice is the source for those figures.
Selective disclosure changes what a service needs to collect. If the service only needs to know that a person is over 18, a proof can reveal that predicate instead of the birth date or passport scan. This can reduce the identity data exposed by a later breach. It does not eliminate KYC risk. A service may still retain names, account records, device data, sanctions decisions, recovery records, or full documents required by law. Issuance, revocation, coercion, and compromised user devices also remain outside the proof.
Zero knowledge identity can reduce what reaches the storage layer. A service does not need a birth date to learn that someone is over 18. It needs one predicate. A proof can disclose that result while the source document stays on the holder's device. The next lab builds a small version of that proof and marks the government signature check as simulated.
Lab 03. A real bit decomposition range proof in p = 2027. Each envelope is a Pedersen commitment, and each one carries an OR proof that it hides a 0 or a 1. The seals multiply out to the sealed gap. Real systems use groups of size near 2 to the 251st and verify the government's signature on the passport inside the proof. That signature binding is marked simulated here.
The trick inside is worth thirty seconds of staring. The gap between your age and 18 is a number. Any number up to 127 is a row of seven bits. Seal each bit in its own envelope, then prove that every envelope hides a genuine bit and that the envelopes multiply out to a seal of the whole gap. A verifier who accepts both checks now knows the gap is between 0 and 127, so you are between 18 and 145 years old, while the birth year never appears and the exact age never appears, and none of the bit values ever leave their envelopes. Set the year to someone under 18 and the gap goes negative. No row of bits exists, and the proof can't even be constructed, which is why the lab refuses rather than lying. Press Tamper after a run. Edit one published envelope after the fact and every check collapses, because the challenges were hashed from the exact values published, Fiat Shamir again. That's what makes a proof a proof.
07The zk passport
This is not only a laboratory proposal. The physical root already sits in an electronic passport. ICAO Doc 9303, Part 11 defines passive authentication: a reader verifies the issuing state's signature over the document security object, then compares signed hashes with the data groups read from the chip. ICAO also states the limit plainly. Passive authentication proves that the signed contents are authentic and unchanged, but does not by itself prevent chip copying or substitution.
The flow is the one Figure 6.1 promised. A phone reads the chip over NFC and checks the signature. A circuit then proves a predicate such as age or citizenship. The verifier can receive the result without receiving the raw birth date or passport image. Real systems differ in where signature verification occurs and which passport types they support, so each implementation needs its own threat model.
Count what leaves in the narrow age example. The service receives a predicate result, a proof, and freshness data. It may still receive account identifiers and operational metadata. The privacy gain comes from avoiding unnecessary document fields, not from making the rest of the service breach proof.
08What is real today
Two open implementations make the design concrete. Rarimo ZK Passport scans a passport camera zone and NFC chip, then supports proofs for age, citizenship, uniqueness, and other fields. Its own documentation also lists limits: some passport signatures are too expensive for full verification on current phones, light mode relies on a trusted verifier for issuer signature checks, biometric checks are absent, and multiple passports can still create multiple registrations.
Anon Aadhaar verifies the Indian government's RSA signature from the secure QR code inside a circuit, then supports selective disclosure for age, state, pincode, or gender. Its build documentation says the project remains under development and should not be used in production without contacting the team. These are working reference systems, not a claim that every KYC workflow can discard every document today.
The common shape is a signed source, local proof generation, and a narrow public result. The unresolved work sits around it: issuer trust, revocation, recovery, liveness, sanctions policy, device compromise, and legal retention duties. Cryptography can minimize disclosure. Governance decides what must still be collected.
The decoy crowd of Monero and the proofs on this page are two privacy traditions that reached production. Identity uses the same mathematics for a different goal: reveal the fact a service needs and withhold the fields it does not. That reduces disclosure. It does not remove every source of identity risk.