Zero-Knowledge Proofs Explained: The Cryptography Behind RAILGUN

I've covered what RAILGUN does and how to use it. Now I want to look at what sits underneath: zero-knowledge proofs. They are the cryptographic foundation that makes private transactions possible without trusting any central party.

You don't need to be a mathematician for this. I'll keep it accessible, but I still want you to come away with a real understanding of how it works.

What is a Zero-Knowledge Proof?

A zero-knowledge proof lets you prove something is true without revealing any information about why it's true.

The classic example is a locked door. You want to prove you know the password without telling anyone what the password is. A zero-knowledge proof lets you do exactly that: you demonstrate knowledge of the password while the password itself stays completely secret.

In RAILGUN, the thing you prove is that you own the tokens you're trying to spend, that you're not spending more than you have, and that your transaction follows all the rules. You prove all of that without revealing your balance, who you're sending to, or any other detail.

zk-SNARKs: The Specific Type RAILGUN Uses

RAILGUN uses zk-SNARKs, short for Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge. Each part of the name carries a promise.

Zero-Knowledge means the proof reveals nothing beyond the statement being proven.

Succinct means the proofs are small and fast to verify, no matter how complex the underlying computation is. A RAILGUN proof is only a few hundred bytes and verifies in milliseconds.

Non-Interactive means the prover generates the proof once, and anyone can verify it without any back-and-forth. That is essential on a blockchain, where you submit a transaction once and every node has to be able to check it.

Arguments of Knowledge is the technical term for proofs that show you actually know something, not just that something exists.

How RAILGUN Uses zk-SNARKs

When you make a private transaction, your wallet generates a zk-SNARK proof covering five things at once. It shows that you possess the spending key for the UTXOs you're using, and that those input UTXOs exist in the Merkle Tree of valid commitments. It shows that the input amounts equal the output amounts plus fees, so no value appears from nowhere. And it shows that all cryptographic signatures are valid and that the transaction doesn't violate any other protocol rule.

The smart contract verifies this proof on-chain. If the proof is valid, the transaction executes. If not, it's rejected. At no point does the contract see your actual balances, addresses or transaction details.

The UTXO Model: Tracking Private Balances

RAILGUN uses a UTXO model similar to Bitcoin's, rather than the account model Ethereum uses publicly.

In the account model you have a single balance that goes up and down. It's easy to understand, but it depends on knowing the account's state.

In the UTXO model your balance is a collection of "unspent outputs". Each UTXO behaves like a discrete coin. When you spend, you consume some UTXOs entirely and create new ones for the recipient and for your change.

A concrete example: you shield 100 USDC, and RAILGUN creates a UTXO worth 100 USDC, encrypted so only you can see it. Then you send 30 USDC to a friend. RAILGUN consumes your 100 USDC UTXO and creates two new ones in its place, a 30 USDC UTXO for your friend and a 70 USDC UTXO as your change.

Both new UTXOs are encrypted for their respective owners. Observers can see that a transaction happened, but not the amounts or the participants.

Why UTXOs? Because they fit zero-knowledge proofs perfectly. Each UTXO is independent, so you can prove things about individual coins without revealing your entire balance.

Merkle Trees: Efficient Commitment Tracking

RAILGUN uses Merkle Trees to keep track of every private commitment. A Merkle Tree is a data structure that lets you prove membership in a large set without revealing the whole set.

Every time someone shields tokens or receives a private transfer, a new commitment is added to the tree. The commitment is a cryptographic hash that represents the UTXO without revealing its contents.

When you spend a UTXO, you prove two things. The first is membership: your UTXO's commitment exists in the Merkle Tree. The second is ownership: you know the secret data that produces that commitment.

Because of the tree structure, this proof stays compact. Whether there are 1,000 or 1,000,000 UTXOs in the system, your proof is the same size.

Nullifiers: Preventing Double Spends

Every UTXO has an associated nullifier, a unique identifier derived from the UTXO and your spending key. When you spend a UTXO, you reveal its nullifier.

The smart contract keeps a list of every nullifier ever revealed. If someone tries to spend the same UTXO twice, its nullifier is already on the list and the transaction fails.

I find this elegant. A nullifier proves that a UTXO has been spent without revealing which commitment it belongs to. Even if you see two nullifiers, you can't link either of them to a specific commitment in the Merkle Tree.

The Trusted Setup

zk-SNARKs need a one-time "trusted setup" ceremony to generate the cryptographic parameters used for proving and verifying.

RAILGUN ran a large-scale trusted setup with many participants. The security property is that as long as at least one participant was honest and destroyed their secret contribution, the whole system is secure.

It only happens once. After the parameters are generated they're used forever, and no further trust is required.

Putting It All Together

Here is a complete private transaction from start to finish.

Step 1: Transaction Construction

Your wallet identifies the UTXOs you want to spend, calculates the outputs and prepares all the data.

Step 2: Proof Generation

Your wallet runs the zk-SNARK prover. It takes your private inputs (the spending key and UTXO details) together with the public inputs (the Merkle root, the nullifiers and the output commitments), and produces a compact proof that every rule is followed.

Step 3: Transaction Submission

The transaction goes to the blockchain carrying the nullifiers of the spent UTXOs, the commitments of the new UTXOs, the zk-SNARK proof, and encrypted data that lets recipients identify the UTXOs meant for them.

Step 4: Verification

The smart contract verifies the zk-SNARK proof. This is computationally cheap and takes milliseconds.

Step 5: State Update

If the proof checks out, the contract marks the nullifiers as spent, adds the new commitments to the Merkle Tree, and emits events so recipients can scan for their UTXOs.

The whole flow keeps the transaction private while its correctness is guaranteed by mathematical proof.

Why This Matters

Zero-knowledge proofs change what's possible on public blockchains. Without them, privacy would mean trusting some central party or moving to a separate, less secure system.

With zk-SNARKs, privacy is enforced by mathematics rather than promises. Verification happens on-chain, inside the smart contract itself, so there is no trusted intermediary who can see or censor your transactions, and the security comes directly from the underlying blockchain.

RAILGUN doesn't ask you to trust anyone. It asks you to trust math.

The Bottom Line

The cryptography behind RAILGUN looks complex, but the key ideas are straightforward. Zero-knowledge proofs let you prove correctness without revealing details. The UTXO model tracks discrete private coins. Merkle Trees prove membership efficiently. Nullifiers stop double spending.

Together they make a system where privacy is mathematically guaranteed, not just promised.

In the next article I'll look at one of RAILGUN's most interesting features, Private Proofs of Innocence, and how RAILGUN keeps bad actors out of the system while keeping legitimate users private. It's a careful balance between privacy and compliance.