First time trying anything quantum computing w/ my friend Shuhul from Caltech :)

Prompt

In this project for QiskitFest@UCLA, we implement a Quantum random number generator that uniformly samples 0...N in the fewest number of qubits and gates as possible. We include 4 sample circuits ranging from a naiive implementation to the most optimal design.

Preliminaries:

Quickly, this problem of sampling 0..N is trivial for the case N = 2^k, since we can use a series of Hadamard transforms to evenly split the amplitudes across all 2^k computational basis states. Each Hadamard gate doubles the number of possible outcomes, creating a uniform superposition where every basis state has equal probability 1/2^k. This only becomes interesting when N isn’t just a power of 2, for which we explore a series of circuit constructions. Naiively, we could just simulate extra states and use rejection sampling, but we wanted to design this circuit to operate purely on a quantum state.

V0: Naiive Control

R_y Rotation Gates

In this circuit, we manually set the probabilities of each qubit using cascaded R_y rotations, but this approach quickly becomes impractical. Each new qubit requires multiple controlled rotations whose angles depend on all previous qubits, causing the gate count and circuit depth to grow quadratically. These controlled rotations are also error-prone and hardware-expensive, and the precise rotation values are hard to compute or calibrate.

V1: Binary Expansion

Since for powers of 2, building a uniform sampler is straightforward using Hadamard gates, we instead view N as a sum of powers of two, N = 2^{k_1} + 2^{k_2} + \cdots + 2^{k_m}. By constructing uniform superpositions for each 2^{k_i} block and combining them with conditional rotations, we can approximate a uniform distribution over 0...N-1 while keeping the circuit shallow and efficient.

Example

Here is an example of the breakdown for N = 7:

And here is the corresponding circuit representation

We recursively sample over N = 7 states as a binary tree of conditional probabilities. At each branching point, the circuit applies a rotation that splits the amplitude proportionally to how many valid states remain in each subtree.

For instance, the first qubit has probability P(4/7) of being |0\rangle and P(3/7) of being |1\rangle. These are then recursively refined until all of the basis states are assigned equal amplitude.

Some Math

For the first qubit, we want to split the probability mass between the left and right branches according to how many valid states lie under each. P(0) = \frac{4}{7}, \quad P(1) = \frac{3}{7}. An R_y(\theta) gate on |0\rangle prepares R_y(\theta)|0\rangle = \cos\left(\frac{\theta}{2}\right)|0\rangle + \sin\left(\frac{\theta}{2}\right)|1\rangle, giving probabilities \cos^2(\frac{\theta}{2}) and \sin^2(\frac{\theta}{2}). Setting \cos^2(\frac{\theta}{2}) = \frac{4}{7} yields \boxed{\theta = 2\arccos\sqrt{\frac{4}{7}} = 2\arcsin\sqrt{\frac{3}{7}}.}

V2: Consolidating Hadamards

Since the Hadamard gate is unitary, applying it twice yields the identity operation H^\dagger H = I. Previously, we used a Hadamard gate with a control to emulate an anti-control, but since H is self-inverse, we can simplify the circuit by directly using an anti-control instead, reducing unnecessary gates.

V3: Complement Graph

This approach first builds a fully balanced superposition over 2^k states using Hadamard gates, then applies conditional R_y rotations to correct the amplitudes for N < 2^k. The Hadamard layer creates an even base distribution, while the correction step prunes invalid branches, creating an even more compact circuit.

Example

For N=9, where the first split is N_0=8 and N_1=1, the rotation angle is

\theta = 0.680 \text{ rad},

so relative to a Hadamard baseline (\pi/2), the correction is

\Delta\theta = -0.891 \text{ rad}.

V4: Log-depth Hadamard Expansion

To build a uniform quantum state over 0 \ldots N-1, we basically follow the binary expansion of N. Each power of two, 2^j, is like a “block” of evenly distributed states, and you only need j Hadamards to generate it, since each Hadamard doubles your reach. So if N=9=8+1, you use three Hadamards to cover the first eight states and then just patch in the last one. The key idea is that you don’t brute-force all N outcomes – you reuse the structure of powers of two to get there in about \log N steps, with a few small corrections at the end to make everything line up perfectly.

There might be a slightly more clever way of reducing the number of control gates, but this is the best we could do up to gates and number of qubits.

Exercise (for fun)

Let k = \lceil \log_2 N \rceil and D = 2^k - N.

Estimate when the complement approach (cost O(D)) becomes less efficient than the Hadamard tree method (cost O(\log N)).

Introduction

In the first blog post in this series, I discussed the potential vulnerabilities of the active Monero ring signature protocol and how this sort of heuristic security can lead to flooding attacks and statistical tracing. But since then, the Monero community proposed the “FCMPs+SA+L” to defend against such spam attacks. By ensuring that verification cost grows very slowly compared to spam size (using logarithmic-size proofs with recursive composition) and using full-set membership (through the initial FCMP proposal), FCMP++ promises to address the DoS-style spam vectors.

In contrast to relying on ad-hoc sampling of decoys, FCMP++ uses bulletproofs to create provable non-inclusion guarantees – every spend comes with a succinct proof that it hasn’t been spent already without requiring global scans or probabilistic mixing.

This is a substantial change from the active Monero protocol. FCMP++ abandons this heuristic model entirely. Instead of sampling decoys, every spend is proven against the entire accumulator of outputs. This proof is succinct and compositional because of the recursive structure of curve trees and bulletproof-style arguments. But now the trust assumptions change: instead of relying on statistical obfuscation, FCMP++ security is based on the algebraic properties of elliptic curves.

A Toy Example of the FCMP++ Tree

Suppose that Monero has only 8 outputs (in reality this would be in the millions). Let them be o_1, o_2, \cdots, o_8. At a high-level, the FCMP++ would look like this:

Commitments for each output

Let C_i be the commitment for o_i, which is used to hide the value of o_i but has some algebraic properties.

Construct a Merkle (Curve) tree of commitments

The commitments are paired and combined in a Merkle-tree

Where f usually is a hash-to-curve function.

Membership proofs

To prove that o_3 has been spent for example, you generate a succinct membership proof that its commitment C_3 is included under the root R, by providing the path up the tree C_3 \to N_{1,2} \to N_{2,1} \to R. This convinces the verifier that C_3 is indeed part of the global accumulator without revealing which leaf you control.

But, membership itself is not sufficient: we have to also prove that o_3 has not been spent yet. In FCMP++, the aforementioned “+L” (Linkability) component of the proposal addresses this. With the membership proof, the spender publishes a unique linking tag L derived from their secret key. Consensus nodes maintain a set of all seen tags such that any repeat indicates a double spend event. Zcash actively employs nullifiers in the same way that Monero proposes for their upgrade.

The distinguishing characteristic for FCMP++ is the underlying machinery. Membership in the curve tree is checked inside of a generalized bulletproof using inner-product arguments and the linkability tag is bound to the spend in a parallel proof.

Zcash uses Halo2 for this, which is a general-purpose proof system where gadgets can be reused inside a single circuit, making proofs modular and easier to audit.

Generalized Bulletproofs are not a universal circuit SNARK like in Halo2: you can’t just add a constraint to a global circuit. Instead, each property you want to prove (membership via a Merkle path, spend authorization with linkability, balance, or range) must be encoded as a specialized algebraic argument expressed through inner-product relations. These arguments are then delicately composed into a single aggregated proof, where Bulletproof’s logarithmic-size folding tricks excel at compressing many homogeneous instances (e.g. multiple range proofs) but don’t natively support heterogeneous ones. As a result, while “gadgets” exist in the sense of reusable argument templates, they are not modular plug-ins that can be audited independently: each must be hand-designed to fit the aggregation framework.

More on Merkle-esque Trees

Monero’s FCMP++ proposal is built on curve trees, which are a shallow Merkle tree where the leaves and internal nodes are points over an elliptic curve. Instead of hashing bitstrings, a curve tree uses commitments and alternating elliptic-curve cycles to build an accumulator. The prover then re-randomizes the commitments along the path and proves membership using a generalized Bulletproof and elliptic-curve divisors. This is very reminiscent of the incremental Merkle tree used in Zcash’s Orchard pool, where note commitments are appended to a fixed-depth tree and each spend proves membership in that tree.

Both schemes have to prevent double spends and do so through similar mechanisms. In Orchard, each note derives a nullifier, which are required to be unique via consensus rules. FCMP++ achieves the same thing with a linking tag: a ZK circuit that emits a tag derived from the spender’s secret key and includes a commitment R to the randomness used to blind it. In both cases, a deterministic value tied to the note or output is recorded on‑chain, and the consensus layer rejects any repeat of that value, thereby preserving unspentness.

Project Tachyon, Zcash’s newest upgrade moves away from this sort of tree accumulator. Zcash currently uses a Merkle tree of note commitments and nullifiers which naturally fit in with Halo2, but the Tachyon upgrade plans to insert nullifiers into a new accumulator that supports efficient set-membership/non-membership proofs in a more succinct/cleaner hash-chain-style accumulator. This removes the necessity for wallets to maintain Merkle-path witnesses and allows on-chain proofs to shrink even more since now validators only need to check that a nullifier hasn’t appeared recently. Monero’s newest upgrade adopts an algebraic variant of a Merkle-tree approach that is currently being deprecated in favor of a leaner, more succinct accumulator in Tachyon ¹.

Ecosystem Hurdles

Bulletproofs in Monero are experimental infrastructure with limited tooling in the broader ZK community, while PLONKish proof systems are well-understood and matured with complete compilers, DSLs, and even zkVMs. They are far less error-prone, easier to adopt, and therefore more auditable and secure in practice.

Developer experience isn’t just a convenience factor but has direct security implications. Particularly for Bulletproofs which require bespoke inner-product arguments for every new property, and composing these arguments requires even more delicate care. With limited high-level tooling, the risk of subtle implementation flaws is higher.

Multiple critical exploits have been discovered in Monero security audits (documented here and here), even in their more restricted implementations of Bulletproofs from a few years ago. To Monero’s credit, these vulnerabilities were identified through rigorous auditing processes. However, they demonstrate how challenging these cryptographic systems are to properly constrain—even in limited use cases. This naturally raises questions about the security implications of the generalized Bulletproofs that FCMP++ requires.

PLONKish systems have matured into an entire developer stack: there’s a full suite of DSLs, circuit libraries, recursive provers, and zkVMs that make them stable and production-grade. High-level languages like Circom, Noir, and Leo compile directly into PLONK circuits, with libraries like gnark and jellyfish providing ready-made gadgets. Recursive provers and zkVMs² like SP1 further expand the ecosystem.

PLONK secures billions of dollars in zkRollups such as Polygon zkEVM, zkSync, Scroll, and Aztec, with public gadgets subject to constant audits and scrutiny. Halo2, one of many PLONK-based protocols, benefits from this ecosystem: its modular circuits enable easy sharing of gadgets and optimizations. This breadth of reuse and review makes PLONKish systems established and less experimental in practice, while Bulletproofs, and by extension FCMP++, remain far more isolated within the broader developer ecosystem.

Final Thoughts

With FCMP++, Monero is finally confronting some of the long-standing vulnerabilities in its anonymity model. By replacing ring signatures and heuristic decoy sampling with a global curve tree accumulator and full-chain membership proofs, Monero moves closer to the stronger, cryptographic security model that systems like Zcash pioneered. This is a significant shift both structurally for Monero but broadly for the definition of privacy for the industry: statistical obfuscation isn’t enough. Explicit, algebraic guarantees are necessary.

But Monero’s approach is complex: FCMP++ requires composing heterogeneous Bulletproofs with divisor arithmetic and custom gadgets, all within a monolithic proof system.

This is untested territory. Monero is building a one-off proving system for their uses that no other production-grade ecosystem shares in ZK. This is a bold but risky project: on one hand it addresses critical weaknesses in Monero’s current design but on the other it does so by venturing into complex and less established terrain. I’m curious to see how this pans out..

On the flight over, the ocean looked like ink—flat from that height, heavy with what it refused to show. AirPods drowned out the cabin noise. My breathing was the only thing I could measure.

Months later, I was sitting in the Tokyo Metropolitan Library, finally writing. On the way, I passed a primary school. The gates were open. Children were playing baseball on the field. The air was thick enough to hold sound; it made their shouts feel close, even from the sidewalk. Their game had no clear beginning and no end, just like mine.

The library breathed a disciplined quiet; inside, my breathing felt too loud. Outside it was summer—damp Uniqlo Airisms, sunscreen, hot asphalt. Even small distances felt intentional—the distance between seats, the timing of footsteps. Bags were placed beneath chairs and not touched again. People arrived, badged in, and remained.

The room traded the effort of navigating the city for the discipline of staying. The quiet did not offer relief so much as structure. It set a pace and expected it to be kept.

here i am writing this. i’m not sure how i feel about it.

the promise

When I told my friends I was going to Tokyo for the summer, they reacted as if I had already returned. They were excited for me, sometimes more than I was. I remember nodding and accepting their enthusiasm like a gift I don’t know where to put. I understood it later. My body didn’t wait.

Most people I know come to Japan the way they visit an exhibit or museum—wide-eyed, temporary, forgiven. There is a kind of freedom in that. You can be ignorant and call it charm. You can misread everything and leave before it has consequences.

i was worried i was going to get another visit from the keisatsu

I stopped at the mouth of a Kabukicho back alley near the Godzilla statue—so narrow it felt like the city had drawn its shoulder in. Signs stacked upward in layers, bars and ramen shops tucked behind every corner. Touts ¹ in gaudy chains drifted in and out like it was nothing. The air turned: urine, trash, stale smoke. Near Toyoko, kids hovered under LED light—gyaru makeup too bright for tired faces, cigarettes passed between small hands. I realized I’d been holding my breath.

uh oh..

I wasn’t here the way people come on vacation—wide-eyed, temporary, forgiven. I lived here. Which meant going in: through doors that didn’t care if I could read the signs, down hallways where the air changed and my instincts lagged. My cousin’s hotspot iPhone 4 sat half-dead in my pocket like a failing lifeline. If I didn’t come back out, it would be a missing person report in a language I could hardly speak, and then silence.

The first night I arrived, I couldn’t find my Airbnb. I walked the block twice, misread the entrances, slipped into the wrong building. There was a FamilyMart on the corner and a narrow back alley that smelled like damp concrete. I messaged the host. Again. And again, until I found the door.

And in the small room I had rented in a city where I was functionally illiterate, I did the most Gen Z thing possible: immediately checking the Wi-Fi. It flicked and failed. I stood hunched near the entrance, where the signal was barely alive, and called my concerned mother over WhatsApp.

And that was just the beginning.

Not the internship. Not the sightseeing. Not the friendships I would later make. This was the beginning: the comforts I usually carried—language, familiarity, the ability to disappear—were gone.

i still can’t believe i brought a crushed belvita all the way from austin. it was multiple years old and unfortunately was my first meal in tokyo.

It was better than last summer’s place in San Francisco’s financial district by a lot. But it still wasn’t much.

A yellow air conditioner that never stopped working. Slippers waiting at the door. A fridge the color of cheap mint. A TV that I never used. And a closet so shallow it felt like the room was telling me, early, not to unpack.

the same girl i’d seen on a wall in austin, near the bridge sun-faded, half-ignored, part of the outside world. here she was framed and clean—indoors, made tame.

And that kept happening this summer—familiar outlines showing up in new places. It wasn’t fate. It was just something repeating, and I kept noticing it.

wow. it’s gone now.

Andy is building a humanoid company in Japan from scratch. Not “In Japan” as a vibe but as in suppliers, visas, language, parts that don’t arrive, company structure, culture, etc.

One afternoon, we were all in the meeting area discussing the number of degrees of freedom in the robot’s foot. Masato-san suggested four—start with a simple toy model and study it before enlarging it. Research-wise, it made a lot of sense. And my experience trying to train policies seemed to support it.

Andy listened and kindly said “this is engineering management 101”.

Four isn’t wrong, but it’s slow. I’ve always liked the “start simple” story because it feels clean, almost academic. Andy’s point was more practical: in hardware, “simple first” can turn into doing everything twice. Another round of parts that don’t arrive, another vendor loop, another build you still have to ship.

Genchi genbutsu (現地現物)

“Go to the real place. See the real thing.”
A principle of the Toyota Production System: understanding should come from direct contact with the actual object and the conditions in which it operates, not from abstractions or proxies.

I liked the phrase genchi genbutsu because it sounds stricter than how I usually live. Not morally—just practically. Less negotiable. It points at places where being wrong costs something and you don’t get to talk your way out of it.

One of the members who currently works on computer vision told me about his earlier years in manufacturing. He described handling molten metal in the Toyota assembly lines, managing timing and temperature. He didn’t present it as a lesson, but to me it made genchi genbutsu click: learning under conditions where errors show up immediately. Stuff like that changed what I take seriously. It shrinks the range of things you can pretend are fine.

one of the temples i visited during the summer, famous for its cat statues but there were certain views that couldn’t be forgotten like this.

I didn’t realize it right away. It showed up on the walk home, passing the same vending machines I’d started using like mile markers.

Tokyo had a way of quieting the background noise for me. When the city stopped asking me to perform, I could hear myself more clearly. I saw how quickly I reach for “nonstandardness.” Some of it is real curiosity. Some of it—if I’m being honest—is cover. A way to stay convincing to myself while calling it ambition.

What bothered me was that the desire hadn’t changed—only the reason underneath it. Sometimes I can’t tell whether I’m pulled by the work itself or by something more embarrassing: fear of being ordinary, hunger for story, imitation that looks like taste from the inside. I don’t know what mix of that I’m made of. I just know that when I’m unsure what matters, I get restless in a way that eventually forces me to move.

Genchi genbutsu isn’t only about factories. It’s a rule against living through substitutes. I’m good at staying one step removed; if something stays debatable, I can keep it comfortable. The moments I remember from this summer weren’t like that. They had a kind of bluntness to them. Whatever I told myself afterward didn’t change what happened.

In San Francisco—at least in the crypto rooms I was in—a lot of things moved on vibes. Even the jargon had water in it—liquidity pools, depth—words that made it sound safer than it was. I could feel myself tracking the same signals everyone else was tracking: which VCs were circling, who was tweeting, what the narrative sounded like on Hacker News. It felt like momentum, even before anything had really been materially tested. That’s just what it feels like when attention moves faster than reality.

Japan isn’t just a new aesthetic, but I did learn a stricter definition of real. If I’m serious about creating things that matter, I have to go the place where the thing either functions or it doesn’t. ²

liminal spaces

it just rained, walking back from the imperial gardens

This summer has felt liminal in an odd way: not between cities but between forms of belonging.

Nothing shattered. Things only thinned—stretched until the effort of holding them became audible. I talked to people I love less often, not because they mattered less, but because each call now required a small negotiation with time zones and fatigue.

friends from the roppongi hacker house next to my airbnb

Meanwhile, Tokyo supplied companionship at arm’s length. Proximity did the work that distance was undoing elsewhere—buoyancy without intimacy. I started marking time by small things: the Takeshita side streets that stayed cool, which vending machines took my card, the same Taco Rico bags collecting by the door ³, the train up to Bunkyo to the Uzumaki house—peanut chicken and bok choy, old Ethereum friends talking sequencer design and coordination like it was casual, and me mostly just grateful to be at a table with someone across from me.

I stopped narrating updates to people who wouldn’t be present for the next chapter; without an audience nearby, the urge to sound coherent receded.

In time I noticed a different divide, less about connection and more about whether the future was already scheduled. Staying in touch turned into logistics. Some threads endured on inertia—easy to resume because the next meeting was implied. Others survived only when someone chose to re-enter them, again and again, with no scheduled Google Calendar event to make it automatic ⁴. Along the way, ideas I’d carried about identity, success, and ambition slipped loose—not dramatically, but by becoming unnecessary.

I want to do things without guarding every edge. The upside isn’t polish but the kind of asymmetry that Nassim Taleb writes about, where volatility teaches instead of eroding. This summer loosened the gravity of an identity that I’ve worked within for a significant part of my life. Now what remains feels lighter, but also more deliberate.

a sketch from my notes app that i keep as my phone background. the left captures the instability of the present; the right is my reminder to zoom out.

I’d been in it so long I stopped noticing the current. In markets, a day can disappear into tiny shifts and still feel like work. With people, it was similar: staying where the temperature was familiar, where the next interaction was implied.

Tokyo didn’t fix anything. It just gave me enough quiet to hear my breathing again.

At the end of the previous blog, I mentioned that the topological properties of the Cantor space make it searchable via a constructive algorithm. Surprisingly, its not too much of a lift but still feels kinda magical. Not only are we deciding a total predicate without any a priori information other than continuity and compactness. Nothing else is known ahead of time: which bit indices will be queried, the number of bits that are required, or any details about the frontier itself. All of this information is extracted at execution time.

In a world of AI generated images, enjoy my hand-drawn rendition of a rabbit in a hat¹. I know it is shit. Sorry.

haskell wizardry

sme :: Pred -> IO [Prefix]
sme p = go IM.empty where
  go asg = case evalP p asg of
    Right True -> pure [asg]
    Right False -> pure []
    Left i -> do
      f0 <- go (IM.insert i False asg)
      f1 <- go (IM.insert i True asg)
      pure (f0 ++ f1)

This performs a determinsitic DFS of the decision tree induced by the predicate p: (\mathbb{B}^\mathbb{N} \rightarrow \mathbb{B}) \rightarrow \mathbb{B} via a partial oracle that answers onl ythe bits present int eh current prefix \sigma and raises a Need exception when p demands an unknown bit index i (this is all covered in the previous blog, nothing new here).

In this case, at node \sigma we now have three cases: 1. evalP returns True = p is already a constant 1 on [\sigma] cylinder set so we can record \sigma and return 2. evalP returns False, so [\sigma] \subseteq U^c so the entire branch can be pruned 3. It raises Need i so we branch to \sigma \cup \{i \mapsto 0 \} and \sigma \cup \{i \mapsto 1 \}.

The result of this procedure is \cal{F} = \text{SME}(p), which represents the set of minimal true prefixes (an antichain² fo finite \sigma with p \equiv 1 on [\sigma]). Topologically, the preimage U = p^{-1}(1) (which represents the set of satsifying assignments) can be expressed as the following disjoint union of cylinders

U = \bigcup_{\sigma \in \cal{F}} [\sigma]

Imagine each prefix \sigma as carving out a subcube (cylinder set) of all points that agree with \sigma. Then taking the union fills up the region where U = p^{-1} (1). By compactness, there is always a finite subcover but our algorithm refines this so that they are also disjoint.

examples

-- fib-eventually (7 cylinders)

\x -> any (\f -> f < 30 && x f) (takeWhile (< 30) fibonacci)

This checks: “Does the infinite binary sequence x have True at any Fibonacci position < 30?”

The 7 cylinders represent the minimal decision tree: - If x[1] = True = predicate is True (fib 1) - Else if x[2] = True = predicate is True (fib 2) - Else if x[3] = True = predicate is True (fib 3) … and so on for positions 5, 8, 13, 21

-- prime-eventually (8 cylinders)

\x -> any (\p -> p < 20 && x p) (takeWhile (< 20) primes)

This computes primes on-demand from primes = filter isPrime [2..] (infinite list), then checks if x is True at any prime position < 20. The 8 cylinders correspond to checking positions 2, 3, 5, 7, 11, 13, 17, 19 in sequence.

-- collatz-reaches-1 (942 cylinders!)

\x -> let collatz n = if even n then n `div` 2 else 3*n+1
        orbit n = takeWhile (/= 1) (iterate collatz n)
    in length (orbit (sum [i | i <- [0..9], x i] + 1)) < 50

Again expanding this gives us: 1. Takes first 10 bits of x, sums the indices where x[i] = True, adds 1 2. Computes the Collatz orbit of that number (3n+1 conjecture) 3. Checks if the orbit reaches 1 in < 50 steps

Certain predicates over infinite sequences can be decided by examining only finite prefixes, and algorithms like sme can discover these finite characterizations. I wonder if there is something interesting in representing this as finite automata. In the next blog, we’ll go into some implications of introducing Randomness.

I’ve recently read this old blog post by Andrej Bauer about Martin Escardó’s Infinite sets that admit fast exhaustive search. At first, it seems pretty ridiculous! How is it possible to decide a problem that is embedded in an infinite topological space? However, using some nice tricks from functional programming and higher-level computability, we can achieve this and even explore some other unexpected consequences.

Any finite set is immediately exhaustible¹, but the interesting thing is that certain infinite sequences with specific properties can also be exhaustible.

Notation

The simple types are \sigma, \tau := o | \iota | \sigma \times \tau | \rightarrow \tau. Let’s dig into this a bit more. - o the Booleans which in Haskell are Bool = True | False - \iota (natural numbers), written as Int. - Product type \sigma \times \tau is the Cartesian product, which is IntMap a : \tau \times (Maybe a) - Function type \sigma \rightarrow \tau - \iota \rightarrow o = predicates on the naturals - o \rightarrow o = boolean functions \neg, \land, \lor, etc.

Using these primitives, we can construct increasingly more complex types as:

Base case (level 0): - o = booleans - \iota = natural numbers

Level 1: - o \times o = pair of booleans (True, False) - \iota \times \iota = pair of naturals (3, 7) - o \rightarrow o = boolean functions {NOT, AND True, OR False, id, ...} - \iota \rightarrow o = predicates on naturals {isEven, isPrime, λn.n>5} - \iota \rightarrow \iota = arithmetic functions, {successor, λn.2*n, λn.n²}

type Oracle a = Int -> a        -- ι → a (where a could be o, ι, etc.)
type Pred a = Oracle a -> Bool  -- (ι → a) → o  
type Prefix = IntMap Bool        -- finite partial assignments  

• The domain is a Cantor space \mathbb{B}^\mathbb{N} (all boolean streams)
• A predicate p is a higher-type functional p: (\mathbb{B}^\mathbb{N}) \rightarrow \mathbb{B}
• a prefix asg is a finite partial map \alpha : S \rightarrow \mathbb{B} which is used to define the cylinder sets used to define the product topology on the Cantor space. ### Scott Domains For each type \sigma, there is a Scott domain D_\sigma of partial functionals of the that same type \sigma defined by lifting the type \sigma to contain the undefined type with all of the properties you would expect (e.g. ordering, etc.). In Haskell, this looks like an Oracle a type with potential Need exceptions. This lets us capture the behavior of undefined/non-terminating computation, which we use to create partial oracles.

Total functionals T_\sigma \subseteq D_\sigma

A functional is total if it maps total inputs to total outputs (so it never produces a Nothing type from non-Nothing)

evalP :: Pred a -> Prefix a -> Either Int Bool
evalP p asg = case unsafePerformIO (try (evaluate (p (oracle undefined asg)))) of
  Left (Need i) -> Left i    -- Partial: needs position i
  Right b -> Right b         -- Total on this prefix

So then we can evaluate P(f^\perp) where f^\perp is a partial oracle depending on what the domain is.

Constructive Selection Functional for Cantor Space

Now consider the following code:

escardo :: Pred -> Maybe Oracle
escardo p = fmap extend (go IM.empty) where
  extend asg i = IM.findWithDefault False i asg
  go asg = case evalP p asg of
    Right True  -> Just asg
    Right False -> Nothing
    Left i -> case go (IM.insert i False asg) of
      Just a  -> Just a
      Nothing -> go (IM.insert i True asg)

We maintain a finite assignment asg that fixes the values of a few coordinates so far. evalP determines whether this cylinder already forces the truth value of p. If evalP p asg returns Right True, then p is already true for every infinite bitstream extending asg. Then we can just stop and produce a total oracle by calling extend, which fills every unspecified bit (at this current point) with a default value (False).

But what does this mean? Think of the Cantor space as the set of all infinite binary sequences

000000000... \\ 001010110... \\ 010101010... \\ 111111111... \\

From Wikipedia, > Given a collection S of sets, consider the Cartesian product X = \Pi_{Y \in S} Y of all sets in the collection. The canonical projection corresponding to some Y \in S is the function p_Y : X \rightarrow Y that maps every element of the product to its Y component. A cylinder set is a preimage of a canonical projection or finite intersection of such preimages. Explicitly, we can write it as: \bigcap_{i = 1}^n p_{Y_i}^{-1} (A_i) = \{(x) \in X | p_{Y_1} \in A_1, \cdots, p_{Y_n} (x) \in A_n \}

So for the Cantor space, a cylinder [\alpha] consists of the set of all infinite strings that start with a finite prefix \alpha. For example, - [01] = all strings that start with “01”: 01000000... \\ 01001010... \\ 01010101... \\ 01111111... \\ - [101] = all strings starting with “101”: 10100000... \\ 10101010... \\ 10111111... \\

We can illustrate this as a tree:

The cylinder set corresponds to the subtree circled in red in the case of the Cantor space.

So then, the search process starts at the root and recursively tries to decide p on the current space (starting with the entire Cantor space). If we need bit i, then split the current cylinder into two subcylinders. If a cylinder returns Right False, we abandon the subtree and if a cylinder returns Right True, we short-circuit and accept.

The incredible thing is that predicate p in this case can be incredibly general. The simplest form to imagine are SAT-style boolean combinations, but they can be any continuous function decidable with finite information. For instance, all of the following are compatible with this framework and are decidable efficiently:

-- Arithmetic predicate
sumFirst10 :: Pred Int  
sumFirst10 oracle = sum [oracle i | i <- [0..9]] > 50

-- Pattern matching
hasPattern :: Pred Bool
hasPattern oracle = any (\i -> oracle i && oracle (i+1) && not (oracle (i+2))) [0..97]

-- Convergence predicate  
converges :: Pred Double
converges oracle = abs (oracle 100 - oracle 99) < 0.001

and these aren’t easily expressible using an SAT-style alphabet. The key constraint is continuity, not logical structure.

for the sake of mathematical rigor

Recall that formally, the predicate is defined as p: \mathbb{B}^\mathbb{N} \rightarrow \mathbb{B} a continuous map on the Cantor space, which itself is a countable product space. The basic open sets in this space are the aforementioned cylinders [\alpha], which are infinite bitstreams that extend a finite assignment \alpha : S \rightarrow \mathbb{B}. By the (Kleene-Kreisel) continuity of p, there exists some cylinder [\alpha] \ni x for each x on which p is already constant and hence a finite amount of information about the input fixes the output. Because the Cantor space is compact and totally disconnected, the preimages p^{-1} (1) and p^{-1} (0) are clopen, so each can be written as a finite union of cylinders (this is a pretty standard trick). Refining these finitely many cylinders to a common depth yields a uniform modulus² (via Heine-Cantor) N such that for each x, p(x) is determined by some finite set of at most N bits.

The evalP function implements this. Given a finite assignment alpha (the IntMap), we run p against the partial oracle that answers exactly the bits in \alpha and throws Need when an unassigned bit is requested. This is exactly the “dialogue” that Escardó describes in his paper: continuous higher-type functionals consuming only finite information..

So really, this is just an incredibly complex guided depth-first search over the binary decision tree of finite assignments that branches only when p asks for a new bit with some short-circuiting logic. Termination relies on compactness via the uniform modulus N. Left i can appear only when i is new (once a bit is assigned, accessing it later doesn’t throw a Need). Thus, no successful branch can be longer than N, so after at most N distinct queries continuity forces a Right answer. If p is everywhere false, the algorithm will explore all finitely many branches up to depth N and fail and otherwise terminate early. Thus, we constructively determine that the Cantor space is searchable³. Another nice property of this is that the order that we sample branches doesn’t affect correctness, only runtime (so there are many engineering optimizations to be done…maybe Gray codes?).

The TL;DR is that: - Continuity gives you cylinder-faithfulness - Compactness gives you a uniform finite modulus - Dialogue gives you an on-demand DFS that decides the predicate over finite information

why just the cantor space?

Good ol’ Wikipedia image. Unfortunately took me a few months to fully wrap my head around them.

The p-adic integers⁴ \mathbb{Z}_p can similarly be seen as an infinite stream of digits in the base p much like the Cantor space (as shown above).

x = a_0 + a_1p + a_2 p^2 + \cdots, a_i \in \{ 0, 1, \cdots, p - 1 \}

Really, the only difference is that now the alphabet size is now p instead of restricted to 2. The Cantor space is kind of an artificial playground because conceptually it is pretty simple to understand. However, the p-adics are widely applicable across number theory (Hensel’s lemma always surprises me) and more. We can easily compute the answer for the question “does there exist a p-adic number \geq k that satisfies C condition?” and construct a witness for it. At some point, i’ll implement a root finding constructive algorithm…maybe pure Haskell WolframAlpha??

There is also an extension of this that introduces Randomness and in turn has some interesting measure-theoretic and algorithmic properties..

Double-spending is when someone tries to use the same funds more than once. It’s a fundamental problem in finance that appears in various guises. In traditional banking, this looks like check kiting—manipulating the float time between accounts to cover overdrafts. A notorious example is Najeeb Khan’s $180M fraud, where he exploited bank timing windows to fund a lavish lifestyle at the expense of clients.

In crypto, Ethereum Classic suffered multiple 51% attacks in 2020 where attackers rewrote transaction history and double-spent over $9M. This showed that public blockchains without secure consensus can be vulnerable too.

Zcash presents a more complex challenge: its shielded transactions reveal nothing about sender, receiver, or value. To prevent double-spending while preserving privacy, Zcash enforces two cryptographic constraints: 1. Private inclusion proof: The note¹ must be in the note-commitment Merkle tree. 2. Public non-inclusion proof: The note’s nullifier must not be in the nullifier set.

Why Zcash uses a public non-inclusion check

When a new shielded note is created, only its commitment is revealed. This is appended to the global note-commitment Merkle tree, while the note’s actual value and recipient stay private. Because the tree is append-only and doesn’t track spending, a second tag—the nullifier—ensures each note is spent at most once.

A nullifier is a deterministic, unlinkable fingerprint of a note. It’s computed using a pseudorandom function (PRF) keyed by the note’s secret. Only the owner can derive the nullifier, and each note has exactly one².

“A transaction is not valid if it would have added a nullifier to the nullifier set that already exists in the set.”

The nullifier is publicly revealed and checked against the nullifier set, which is updated each block along with the Merkle tree. This allows the network to reject double-spends while learning nothing about the note itself.

Private membership proof

Zcash uses zk-SNARKs to enforce both constraints—commitment inclusion and nullifier consistency—without revealing which note is spent. Each proof is ~1–2 kB, verifiable in milliseconds, and works even for light clients³.

1. The private link created inside the zk-SNARK

Merkle inclusion:
The prover supplies the note commitment cm⁴ and a Merkle authentication path \pi as private witness data. The circuit enforces: \text{MerkleRoot}(cm, \pi) = \rho_t where \rho_t is the anchor, a public input representing the Merkle root at block height t ⁵. This confirms that cm appears somewhere in the historical note-commitment tree.

Nullifier computation:
In the same circuit, the prover recomputes the nullifier using: nf = \text{PRF}_{nk}(\rho_t, \psi, cm) where (nk, \psi) are secrets derived from the note. The output nullifier nf is made public and bound to the same anchor and commitment.

This internal linkage ensures that the SNARK proves consistency between the revealed nullifier and the private note it was derived from—without revealing anything about the note itself.

2. How the on-chain check works

Each transaction includes the anchor \rho_t and the nullifier nf in the public input of the proof. Once the SNARK verifies, every full node checks: - That the nullifier nf is not already in the nullifier set N(t). - If the check passes, the block updates: N(t+1) = N(t) \cup \{nf\}

This ensures that every nullifier appears at most once—enforcing one-time spendability.

3. Why the two links suffice

• Existence: The Merkle equation certifies that a real commitment cm already sits in the tree whose root is \rho_t.
• Uniqueness: The PRF binds a single nullifier nf to that cm, and consensus allows each nf to appear only once.

Hence, any valid transaction must: - Reference some existing note (via inclusion of cm), - And cannot reuse that note (since its nf would already be in N).

The inclusion proof and the non-inclusion check are mathematically fixed through the shared variables (cm, \rho_t, nf)—inside the SNARK and on-chain.

Limitations of Merkle Trees

Incremental Merkle trees⁶ are the classic way Zcash records shielded notes⁷. They have a fixed depth d, so the ledger can accept at most 2^d commitments before a migration is needed. Every new note becomes a fresh leaf, and the tree’s collision-resistant hashing lets a prover later show inclusion with a d-hash path. That path is constant-size and efficient, but the tree’s state grows forever⁸.

Sharding helps, but doesn’t solve the problem

A natural next step is to shard the Merkle tree. Instead of one monolith, the ledger maintains many sub-trees (e.g., 2^{32}-leaf trees). When a shard fills, a new one is opened, and a small root-of-roots tree tracks the current shard roots. A note’s inclusion path now includes: - A short intra-shard Merkle path - One additional hash to reach the root-of-roots

This design keeps proof sizes small and reduces wallet update overhead: clients only need to track changes in shards that contain their notes ⁹.

But even this is a temporary fix. The root-of-roots is itself incremental and will eventually fill. Historical paths must still be updated as long as the shard is active. State pruning remains difficult because every note ever minted must remain accessible. As a result, ledger size and wallet sync bandwidth grow linearly with protocol lifetime.

Why a set non-inclusion accumulator changes everything

A set non-inclusion accumulator offers a simpler approach to tracking spent notes.

While incremental Merkle trees work perfectly well for inclusion proofs, they cannot efficiently support non-inclusion proofs. The accumulator solves this by folding all notes into a constant-size accumulator value A_t that can handle non-inclusion proofs (and can be easily extended to support inclusion proofs as well). Every insertion is a succinct polynomial-commitment update, and old accumulator states can be discarded—because an IVC (incremental verifiable computation) chain certifies correctness across updates.

The key advantage is simplicity: while Merkle trees require separate handling for commitments and nullifiers, the accumulator provides a single cryptographic primitive that handles non-inclusion proofs. This means we can use the same system for the nullifier set, and extend it to handle note commitments if needed.

The magic lies in the accumulator’s recursive structure: each update witnesses that a vector of notes was inserted without including a particular element x. The non-membership claim is upheld step-by-step, proving that each polynomial inserted lacked x as a root—meaning x was not present. This transforms the problem into one of recursive algebra, not storage.

At the end, proving non-inclusion (“this nullifier was never inserted up to A_t”) requires only checking that a single polynomial (the one folded into the accumulator) does have x as a root.

• The accumulator’s size never grows, no matter how many notes are inserted
• There’s no depth cap or leaf index to exhaust
• Each IVC step is just a few hashes and group ops—efficient even onchain
• You don’t need to track historical state prior to the last k epochs—as long as all proofs spanning that range have been generated, the earlier accumulator data can be safely discarded

In short: shielded anonymity can grow indefinitely, with no migrations or tree maintenance. This is the foundation for Project Tachyon’s accumulator design—a simpler system that handles non-inclusion proofs efficiently.

Implementation

The accumulator starts in a trivial state A_0 = \langle(1,0,0,\ldots), G\rangle and is updated every time we insert a vector of field elements \mathbf a_i = (a_{i,1},\dots,a_{i,k}) \subset \mathbb F. After many updates we want to show, for every step in a chosen range [j,\,m), that the inserted vector never contained some element v. Instead of storing all past vectors, we fold them into a single curve-point accumulator whose size never grows.

The magic is that while we track more and more nullifiers internally—building a bigger polynomial each time—we only store a single point on-chain. This point acts as a cryptographic summary of all nullifiers we’ve seen, like a Merkle root but without the tree. This means the blockchain state stays tiny, even as we process millions of transactions.

1. Insertion: folding one vector of roots

For the current step we first build its vanishing polynomial

a_i(X)=\prod_{r\in\mathbf a_i}(X-r),

then make a Pedersen commitment P_i to the coefficient vector. One Fiat–Shamir challenge h=H(A_i,P_i) lets us hop to the next state

A_{i+1}=[h]\,A_i + P_i .

pub fn insert(roots: &[Fr], a_prev: G1Affine, r: Fr) -> Result<State> {
    let poly   = poly_from_roots(roots);           //  a_i(X)
    let p_i    = commit(&poly.coeffs, r)?;         //  P_i
    let h      = hash_points_to_fr(&a_prev, &p_i); //  H(A_i,P_i)
    let next   = a_prev * h + p_i;                 //  A_{i+1}
    Ok(State { Accumulator: next.into_affine(), Commitment: p_i })
}

Key point: no matter how many vectors we add, Accumulator stays a single point.

2. Proving that a fresh value v was not among today’s roots

The verifier will accept only if the polynomial we committed doesn’t vanish at v.

1. Evaluate once: \alpha = a_i(v). If \alpha=0 the proof must abort (v was a root).

2. Shift the commitment so the shifted polynomial does vanish at v: P'_i = P_i - [\alpha]G_0

3. Use a second challenge h' = H(S_i, P'_i) to hop the non-membership accumulator.

pub fn check_non_membership(
        roots: &[Fr], v: Fr, r: Fr, s_prev: G1Affine) -> Result<State>
{
    let poly   = poly_from_roots(roots);
    let alpha  = evaluate_poly(&poly.coeffs, v);     // α = a_i(v)
    assert!(!alpha.is_zero());                       // must be non-root

    let p_i    = commit(&poly.coeffs, r)?;           // P_i
    let p_ip   = p_i - POINTS[0] * alpha;            // P'_i
    let h_p    = hash_points_to_fr(&s_prev, &p_ip);  // h′ = H(S_i,P′_i)
    let next   = s_prev * h_p + p_ip;                // S_{i+1}
    Ok(State { Accumulator: next.into_affine(), Commitment: p_i })
}

Because a_i(v)\neq0, the shifted commitment now hides a polynomial whose only root at v is the one we artificially created—exactly the witness we need for non-membership.

3. Non-membership across a range with IVC

We can create a recursive (IVC) proof with base case is (A_j,S_j) and repeat the above step for every i \ge j to make a ranged claim.

• In the circuit we start from snapshot (A_j,S_j).
• At each iteration we witness (P_i, \alpha_i) and apply the check_non_membership hop.
• The accumulator moves from (A_i,S_i) to (A_{i+1},S_{i+1}).
• Only the current state crosses the IVC boundary; earlier data are discarded.

After m-j hops the verifier sees (A_m,S_m). If S_m opens to zero at v, then—by induction—every intermediate polynomial was proven to evaluate non-zero at v. Hence v never appeared in any root vector \mathbf a_j.

4. Why this matters for Zcash-style nullifier checks

• O(1) state: Accumulator is one point \rightarrow no Merkle depth cap.
• Forget history: once the IVC proof exists, we can delete every old vector.
• Cheap per block: each hop is a couple of hashes and group operations
• Scalable non-membership: perfect for showing a nullifier never appeared, without keeping the nullifier set on-chain.

In practice, replacing Zcash’s append-only Merkle trees with this accumulator would remove anchor leakage and tree maintenance, while still proving that a nullifier is unique.

Conclusion

A vector-commitment accumulator gives Zcash a simpler approach to tracking spent notes: constant-size state that efficiently handles non-inclusion proofs (and can be extended to support inclusion proofs). This eliminates depth caps and tree migrations, while still providing the same security properties as Merkle trees.

Real-world deployment still has open questions—metadata privacy, lightweight witness updates, etc. Check out my implementations of this accumulator below.

For the full design sketch, see Sean Bowe’s HackMD.

Appendix

The vector-commitment accumulator guarantees existence (the value really was inserted) and uniqueness (no two different vectors can open to the same commitment at the same index) for two independent reasons:

Existence in the IVC non-membership chain

For non-inclusion, each IVC step asserts p_t(z)\neq0. Because the polynomial p_t encodes exactly the vector inserted at step t, the statement “z was not in {\bf v}_t” is true iff the evaluation is non-zero. The final recursive proof therefore certifies that for every step in the range, z was not a coordinate of any inserted vector. That is an existential statement about the entire history, achieved with only O(1) verifier work.

Uniqueness of a nullifier-style opening

If we swap the vector commitment for one that derives a nullifier‐like output (e.g. include the index j and value v_j in a PRF), the uniqueness follows the same logic: the PRF output is a function of a single valid opening, and the binding of the commitment ensures no second, distinct opening can produce the same output without violating discrete-log or collision-resistance.

In short, the algebraic binding of the commitment bases anchors existence, while their linear independence enforces uniqueness—properties that survive each IVC update and give the accumulator the same double-spend resistance Merkle nullifiers provide, but with constant-size state and proofs.

This blog reviews the prerequisite mathematics for understanding the set-noninclusion accumulator in Project Tachyon — if you’re already familiar with basic abstract algebra, feel free to skip to the next post.

Some Mathematics Prerequisites

Musical Motivation

In the 18th century, composer Johann Sebastian Bach wrote music that continues to be admired for its elegance and structure. Despite lacking formal mathematical training, Bach often composed with a precision that feels inherently mathematical. One striking example is his Crab Canon from The Musical Offering:

Bach’s Crab Canon from the Musical Offering is a fascinating example of mathematical music. When played forward and backward simultaneously, it creates a perfect palindrome — a musical Möbius strip where the end connects seamlessly to the beginning. This topological structure, where a one-sided surface is created by twisting and joining a strip, mirrors how the canon’s melody can be read in both directions while maintaining musical coherence.

The connection between musical expression and hidden structure has fascinated people for a long time. One of the key ideas here is the Circle of Fifths — a diagram that lays out musical notes so that closely related keys sit next to each other in a loop. It’s a handy way to make sense of harmony, and its circular shape hints at something deeper going on beneath the sound: a kind of pattern that music follows, even when we’re not consciously aware of it.

Circle of fifths clockwise within one octave. Source: Wikipedia.

Building on this, modern visualizations let us see musical motion as something geometric. In the animation below, a major seventh progression moves across the surface of an umbilic torus — a looping, twisted shape that shows how harmony can circle around while still shifting forward. Like Bach’s Canon, it turns music into more than just a line of notes — it becomes a kind of movement through space, shaped by patterns and rules we can start to recognize, even if we can’t name them yet.

This animation shows a major seventh progression traced on an umbilic torus surface — a higher-dimensional visualization of the circle of fifths. The smooth rotation through harmonic space represents tonal motion as continuous geometry, revealing deep symmetries between pitch, interval, and curvature.

These patterns aren’t just beautiful — there’s clearly something deeper going on under the surface. To really make sense of it, we’ll need a new kind of language — one that helps us talk about how music moves, transforms, and loops back on itself. That’s where we’re headed next: group theory.

From Loops to Logic

A group is a set equipped with a rule for combining elements — an operation — that behaves predictably: there’s a way to combine any two elements (closure), the way elements are grouped doesn’t matter (associativity), there’s an identity element that does nothing (identity), and every element has an inverse that undoes it (inverses).

A simple example of a group is a finite cyclic group \mathbb{Z} / n \mathbb{Z}, the integers modulo n which consists of the set

{0, 1, 2, \ldots, n - 1}

with the action being addition modulo n. For example, in \mathbb{Z} / 12 \mathbb{Z}, 12 \cong 0 so 7 + 6 = 1 \mod 12. Check out Wikipedia for the mathematical definition of a group.

It turns out that cyclic groups are also very useful for cryptography. Suppose that you start with 0 in \mathbb{Z} / 12 \mathbb{Z} and keep adding 5. Then you get the sequence:

0, 5, 10, 3, 8, 1, \ldots

Eventually, you reach every number in the set. Now, if I asked you to tell how many times you have to add 5 to get the number 8, would you be able to tell me?

This is the Discrete Logarithm Problem. Given a generator (like 5) and a result (like 8), the challenge is to figure out how many times the generator was applied. In this example, the answer is 4, since 5 \times 4 = 20 \cong 8 \mod 12.

In cryptography, we often write cyclic groups using multiplicative notation, where repeated application of a generator g is written as:

g^0, \; g^1, \; g^2, \; \dots, \; g^{n - 1}

This gives all elements of the group if g is a generator.

The discrete logarithm problem asks: Given g and h = g^x, find x.

For small numbers, this is easy to solve by trial. But in large cyclic groups (especially those built from primes with hundreds of digits) the problem becomes extremely hard. For small numbers, this is easy to solve by trial. But in large cyclic groups (like those used in Ethereum’s BLS signatures, where the modulus is a 381-bit prime) the problem becomes practically impossible to reverse, and that’s exactly what makes it secure against classical computers.

Pedersen Vector Commitment Scheme

Finally, we have the language to talk about tools that rely on group structure to ensure both hiding and binding: the two essential properties of a cryptographic commitment. One of the simplest and most elegant examples is the Pedersen commitment.

Hiding and Binding

Before going further, it’s worth pausing to explain what we mean by hiding and binding.

• Hiding means the commitment doesn’t reveal any information about the underlying message. Even if someone sees the commitment, they can’t figure out what value was committed — because it’s masked using randomness.

• Binding means that once you’ve committed to a value, you can’t later change your mind. That is, you can’t open the same commitment to a different value. This ensures the commitment is fixed and can’t be altered after the fact.

In short: hiding protects privacy; binding ensures integrity.

The Pedersen Commitment

Let G be a cyclic group of prime order q, with generators g and h such that no one knows the discrete logarithm between them. To commit to a value m \in \mathbb{Z} / q \mathbb{Z}, choose a random blinding factor r \in \mathbb{Z} / q \mathbb{Z} and compute:

\text{Com}(m, r) = g^m h^r

This is a commitment to m that is:

• Perfectly hiding: because r is chosen at random, the output reveals nothing about m
• Computationally binding: under the discrete log assumption, it’s infeasible to find two different pairs (m, r) and (m', r') that yield the same commitment

Additionally, Pedersen commitments are homomorphic:

\text{Com}(m_1, r_1) \cdot \text{Com}(m_2, r_2) = \text{Com}(m_1 + m_2, r_1 + r_2)

This means commitments can be added without opening them, a property useful in many protocols.

Now here’s how we implement this in Rust:

pub fn commit(m: Scalar, r: Scalar, g: GroupAffine, h: GroupAffine) -> GroupAffine {
    (g * m + h * r).into_affine()
}

From Commitments to Vector Commitments

To commit to a whole vector \mathbf{m} = (m_1, m_2, \dots, m_n), we extend the idea by using n independent generators g_1, g_2, \dots, g_n \in G, and a single blinding base h. The commitment is:

\text{Com}(\mathbf{m}, r) = g_1^{m_1} \cdot g_2^{m_2} \cdots g_n^{m_n} \cdot h^r

The vector commitment version in Rust takes an array of generators:

pub fn open(v: &[Scalar], r: Scalar, j: usize) -> Result<(Scalar, Scalar, GroupAffine)> {
    if j >= v.len() {
        return Err(anyhow!("Index out of bounds"));
    }

    let blind = POINTS[0] * r;
    let witness = POINTS[1..].iter().enumerate()
        .filter(|(i, _)| *i != j)
        .map(|(i, p)| *p * v[i])
        .sum::<GroupProjective>() + blind;
    
    Ok((v[j], r, witness.into_affine()))
}

This compactly binds the entire vector \mathbf{m} into a single group element. It maintains the same properties:

• Hiding, because the random r masks the entire vector
• Binding, assuming the generators g_1, \dots, g_n are independent and the discrete log relationships between them are unknown

And here’s how to verify the commitment:

pub fn check(c: GroupAffine, v_j: Scalar, witness: GroupAffine, h_j: GroupAffine) -> bool {
    c == witness + h_j * v_j
}

Algebraic Properties

What makes Pedersen (vector) commitments especially powerful is their algebraic structure:

• Linearity: Commitments respect linear combinations:

  \text{Com}(\mathbf{m}, r) \cdot \text{Com}(\mathbf{m}', r') = \text{Com}(\mathbf{m} + \mathbf{m}', r + r')

  where vector addition is component-wise.

• Scalability: You can aggregate commitments across multiple vectors:

  \prod_{i=1}^k \text{Com}(\mathbf{m}^{(i)}, r_i) = \text{Com}\left(\sum_{i=1}^k \mathbf{m}^{(i)}, \sum_{i=1}^k r_i\right)

• Inner-product compatibility: Because exponentiation distributes over sums, Pedersen commitments can be used inside inner-product arguments (like in Bulletproofs), where both prover and verifier can manipulate commitments algebraically without knowing the underlying messages.

• Non-interactive opening proofs: Given \mathbf{m} and r, it’s trivial to open the commitment and prove correctness. Zero-knowledge variants can be layered on top if needed. We will see this in the next blog.

These algebraic properties make Pedersen commitments a favorite building block in privacy-preserving protocols, SNARK-friendly constructions, and succinct proofs of integrity over large datasets. We will see how we can build Sean Bowe’s set-noninclusion accumulator from this in the next blog post.

Monero’s Limitations

One of the most fascinating developments in cryptocurrency has been the class of privacy-focused cryptoassets. Monero currently dominates this category in terms of usage (market cap of $6.73B and 24h volume of $110.49M) but it is not without its limitations.

Monero’s ring signature system provides each transaction input with a ring of decoy outputs plus their real one. In theory, an observer shouldn’t tell which output in the ring was actually spent. But in practice, set intersection attacks and other heuristics have exposed limitations in their privacy model.

In a set intersection attack, an adversary analyzes multiple transactions whose rings share common outputs in order to distinguish real spends by intersecting these sets. For example, suppose that Alice owns an old Monero output A. She spends it in a transaction on the main Monero chain forming a ring

\text{Tx1} = \{A, B, C, D, E\}

Because of Monero’s ring signature, an observer can’t tell which of the five is the real input. Now suppose Alice also spends the same output on a Monero fork:

\text{Tx1'} = \{F, G, A, H, I\}

Each ring has 5 outputs, but A is the only one common in both, which isn’t good. In Monero, a user’s true spend should be computationally hidden among many decoys, but the re-use of the same output across multiple rings breaks this illusion. According to a recent review by Cypher Stack, this remains a practical attack vector.

Reusing decoys in Monero has some serious ripple effects. If the real spend for a single output is ever revealed—through an exchange, user mistake, or clever analysis—it doesn’t just affect that one transaction. It lets anyone rule out that output as a decoy in any other ring it appeared in. That, in turn, helps narrow down the real spends in those rings, and the process can repeat across the network. In Monero’s early days, this was especially bad—over 65% of inputs didn’t even use decoys, so they were trivially exposed. And even after mixins were added, researchers found that another ~22% of inputs could still be traced just by overlapping the right rings and eliminating possibilities.

What’s more troubling is that a powerful attacker could add their own known decoys to the ring. By flooding the network with transactions that reuse known or controlled outputs as decoys, they can “poison” the anonymity set. Once a few real spends are known, these poisoned rings make it much easier to strip away decoys and trace other transactions. It creates a chain reaction where even users who took care to protect their privacy can end up exposed if their transactions enter rings with adversaries.

This set-intersection effect accurately explains why churning—the practice of sending funds back to yourself to “clean” them—is especially dangerous in Monero, and why any privacy leak (such as using a KYC exchange or revealing a single address) can compromise not just a single transaction but the entire anonymity set. When a user spends funds that were previously used in a public or traceable context, it contaminates any ring that output appears in. Even indirect interactions with centralized services, or careless use of wallets that expose scanning patterns, can cascade into de-anonymizing dozens or hundreds of other users.

What’s especially troubling is that normal users—people just trying to move their money or use an exchange—can unknowingly weaken the privacy of the entire network. Every time someone reveals a spend, even unintentionally, it shrinks the effective anonymity set for everyone else. Over time, these small leaks accumulate, and the network becomes easier to analyze. In Monero, privacy erosion isn’t always caused by attackers—it can emerge organically from the way the system works.

Modern Monero has strengthened its defenses against intersection attacks, though primarily through patches rather than rigorous cryptographic guarantees. Techniques like enforcing minimum ring sizes and refining decoy selection help mitigate “closed set” intersection attacks, where outputs only appear with each other and can thus be linked. Although these measures have made analysis harder than in Monero’s early days—when researchers could deanonymize up to 90% of transactions for just ~$1,000—a well-resourced adversary with enough data can still perform large-scale intersection attacks.

Figure: Monero’s resistance to various analysis techniques, adapted from Goodell, B. (2024), “History and state of Monero security analysis”. As the table shows, Monero remains vulnerable.

Zcash’s Mathematical Guarantees

Unlike Monero, Zcash doesn’t rely on probabilistic arguments with decoys. Instead, it achieves ledger indistinguishability using zero-knowledge proofs. Every shielded transaction in Zcash is cryptographically indistinguishable from random noise. And now, it is being accelerated in Zcash Engineer Sean Bowe’s Project Tachyon. Succinctly, here is how Tachyon addresses the limitations of Monero:

In Project Tachyon, Bowe rethinks how wallets sync and interact with blockchain state in a secure manner. Tachyon introduces a model where wallets maintain a proof of their own synchronization (via proof-carrying data), allowing validators to prune almost all historic data. By shifting secret distribution off-chain and removing reliance on encrypted note payloads in the ledger, it enables lean, stateless wallets and small, efficient blocks.

Where Monero’s privacy degrades as the network grows—due to increasing chain bloat, repeated decoy reuse, and compounding intersection attacks—Tachyon pushes Zcash in the opposite direction: greater usage yields greater efficiency/security. In effect, Monero’s scale is a liability, while Zcash’s scale becomes a strength. Tachyon turns what is traditionally a privacy trade-off into a privacy advantage.

For the full technical breakdown, check out Sean’s blog on Project Tachyon. In the next couple of blogs, we’ll walk through a toy implementation of the accumulator from Project Tachyon from zero!