The Zcash page described the shape of a shielded payment — a sealed commitment, a one-time nullifier, and a zero-knowledge proof that the whole thing is honest — and then stopped at the machinery's door. This page opens that door. It names the real parts: what is actually inside a note, how the network stores commitments so a proof can point at one, what a zk-SNARK genuinely proves, and how Zcash builds those proofs without a trusted setup.
It goes one level deeper, not all the way down. The full, exact definitions are normative
cryptography, and the place for those is the Zcash Protocol Specification and the ZIPs
(Zcash Improvement Proposals) at zips.z.cash — not a copy of them here, which could only drift
out of date and introduce mistakes. So each piece below is an accurate picture plus a pointer to
the section that defines it precisely. Read the spec for the truth; read this to know what you
are looking at.
The blockchain page kept using a "fingerprint" — a value computed from a block's exact contents, where any change, however tiny, produces a completely different result. That fingerprint has a name: it is a hash.
A hash function takes any input and returns a fixed-size string of bits. Three properties make it useful here. It is deterministic — the same input always gives the same output. It is one-way — given the output you cannot run it backwards to recover the input; you could only guess inputs and check. And it is collision-resistant — it is infeasible to find two different inputs with the same output, so a hash effectively stands in for the exact thing that produced it. (Proof-of-Work, from the blockchain page, was just hashing a block over and over, guessing a throwaway number until the hash came out with enough leading zeros.)
Hold onto those three properties. The commitment, the nullifier, and the tree below are all built from hash functions, and each one leans on a different property.
Shielded value in Zcash lives in notes. The specification's overview puts the idea simply: value in a shielded pool "is carried by notes, which specify an amount and (indirectly) a shielded payment address, which is a destination to which notes can be sent." A note is the private equivalent of a coin sitting at an address.
In the current shielded protocol, Orchard, a note records a handful of things: who can spend it (a shielded address, technically split into a diversifier and a transmission key), how much it is worth (a value in zatoshi — 1 ZEC is 100 million zatoshi), and some random values whose only job is to make every note unique and to let its owner later compute the note's nullifier. None of this is posted in the clear. The note itself stays with its owner; what reaches the chain is a sealed stand-in (next section) and, separately, an encrypted copy of the note — including an optional 512-byte memo — that only its intended recipient, and anyone they share a viewing key with, can read.
The exact field list is in the specification's Notes section.
When a note is created, the network does not see the note. It sees a note commitment — a short value computed from the note's contents with a hash-based commitment scheme (Orchard uses one called Sinsemilla). The specification states the purpose directly: when a note is created "only a commitment to the note contents is disclosed publically … This allows the value and recipient to be kept private, while the commitment is used by the zk-SNARK proof when the note is spent, to check that it exists on the block chain."
A commitment does two things at once, and they map onto the hash properties above. It hides: because the hash is one-way, the published commitment leaks nothing about the amount or recipient. And it binds: because the hash is collision-resistant, the committer cannot later claim the envelope held some other note — the contents are pinned the moment the commitment is posted. That is the sealed, tamper-proof envelope from the previous page, now with a name and a mechanism.
Once a transaction is mined into the block chain, each note commitment it created is added to one structure: the note commitment tree. The specification describes it as "an incremental Merkle tree of fixed depth used to store note commitments," and draws the Bitcoin analogy: like the unspent-output set, "it is used to express the existence of value and the capability to spend it," except that this tree is append-only and so, on its own, does nothing to stop double-spends — that is the nullifier's job, below.
A Merkle tree hashes pairs of values together, then hashes those results together, and so on up to a single value at the top called the root. The root is a hash that depends on every commitment in the tree, so it is a compact summary of the entire set of envelopes. Crucially, you can prove that one specific commitment is in the tree by revealing just the handful of sibling hashes along the path from that leaf up to the root — a Merkle path — without revealing the other leaves, or even which position among the public set is yours.
This is the piece the Zcash page promised: it is how the envelopes are stored so a proof can point at one. A spender's proof references a published root — in Orchard this fixed reference point is called the anchor — and demonstrates, in zero knowledge, that the note being spent sits somewhere underneath it.
A sealed envelope you can prove membership of still leaves the original worry: what stops you spending the same note twice, if nobody can see which note you are spending?
The nullifier. It is a tag derived — by hashing — from the note together with a secret key (in Orchard, the nullifier-deriving key). Two facts make it work, and again they are just the hash properties in disguise:
So a spend reveals a nullifier that means "some note was just spent — never allow it again" while keeping silent about which envelope it drained.
We now have envelopes (commitments) in a tree (under an anchor) and a one-time tag (the nullifier). The last piece ties them into an honest payment without exposing any of the secrets — and that is the zk-SNARK. Unpack the acronym, because each word is a real promise: a zero-knowledge succinct non-interactive argument of knowledge.
For a shielded Orchard spend, what the spend establishes is, in plain terms: the note being spent has a commitment that really sits in the tree under the published anchor (a valid Merkle path); the spender holds the key that authorizes spending it; the nullifier was computed correctly from that note; and the amounts balance, so no value is conjured from nothing. The overview names several of these obligations — that "some revealed note commitment exists for this note," that "the prover knew the proof authorizing key of the note," and that "the nullifier and note commitment are computed correctly" — and it names the property the whole design buys: "when a note is spent, the spender only proves that some commitment for it had been revealed, without revealing which one." The precise statement is written out in the spec's Action Statement (Orchard); that is the section to read if you want the real thing rather than this summary.
One question remains: where do the rules of that proof — the fixed circuit each proof is checked against — come from, and could whoever set them up cheat?
This is a genuine historical wrinkle in Zcash. Its first two proving systems needed public parameters generated ahead of time: Sprout used a system called BCTV14, and Sapling used Groth16, whose proofs are checked against a parameters file produced by a one-time setup. That setup involves secret randomness, and here is the danger — anyone who kept that secret (the so-called toxic waste) could forge proofs and counterfeit shielded value undetectably. Zcash never made that risk vanish for those pools; it contained it, by generating the parameters in elaborate multi-party ceremonies (the Sapling parameters, the spec records, came out of exactly such a multi-party computation) designed so the secret stays safe as long as even one participant destroyed their piece.
Orchard, activated in the NU5 network upgrade, removes the problem at the root by switching to Halo 2. Halo 2 needs no pre-generated parameters file at all — the specification notes its parameters are "generated on the fly … and do not require parameter files." No setup means no secret randomness, which means no toxic waste and no ceremony to trust. The integrity of a shielded Orchard payment rests on the mathematics of the proof system alone, not on anyone's promise that they threw away a dangerous secret. That is what people mean by Halo 2 having no trusted setup, and it is why the current shielded pool stands on a meaningfully stronger footing than the early ones.
Everything above is an orientation, deliberately one level above the normative detail. When you need the exact definitions — the precise contents of a note, the commitment and nullifier functions, the full Orchard statement, the curves Halo 2 is built on — go to the primary sources:
zips.z.cash record each protocol change as a standalone proposal — Orchard,
unified addresses, and the rest — and are often the gentler read for one specific feature.Treat this page as the map, and those as the territory.