David Wong

cryptologie.net

cryptography, security, and random thoughts

Hey! I'm David, cofounder of zkSecurity, research advisor at Archetype, and author of the Real-World Cryptography book. I was previously a cryptography architect of Mina at O(1) Labs, the security lead for Libra/Diem at Facebook, and a security engineer at the Cryptography Services of NCC Group. Welcome to my blog about cryptography, security, and other related topics.

← back to all posts

High-level intuitions for the Bulletproofs/IPA protocol

blog

I wrote about Bulletproofs / inner product arguments (IPA) here in the past, but let me try again. The Bulletproofs protocol allows you to produce these zero-knowledge proofs based only on some discrete logarithm assumption and without a trusted setup. This essentially means no pairing (like KZG/Groth16) but a scheme more involved than just using hash functions (like STARKs). This protocol has been used for rangeproofs by Monero, and as a polynomial commitment scheme in proof systems like Kimchi (the one at the core of the Mina protocol), so it’s quite versatile and deployed in the real world.

The easiest way to introduce the protocol, I believe, is to explain that it’s just a protocol to compute an inner product in a verifiable way:

a,b=c

If you don’t know what an inner product is, imagine the following example:

(a1a2a3a4),(b1b2b3b4)=a1b1+a2b2+a3b3+a4b4

Using Bulletproofs makes it faster to verify a proof that a,b=c than computing it yourself. But more than that, you can try to hide some of the inputs, or the output, to obtain interesting ZK protocols.

Furthermore, computing an inner product doesn’t sound that sexy by itself, but you can imagine that this is used to do actual useful things like proving that a value lies within a given range (a range proof, as I explained in my previous post), or even that a circuit was executed correctly. But this is out of scope for this explanation :)

Alright, enough intro, let’s get started. Bulletproofs and its variants always “compress” the proof by hiding everything in commitments, such that you have one single point that represent each input/output:

  • A = a,G
  • B = b,H
  • C = a,bQ

where you can see each point A,B,C as a non-hiding Pedersen commitment with independent bases G,H,Q (so the above calculations are multi-scalar multiplications). To drive the point home, let me repeat: single points instead of long vectors makes proofs shorter!

Because we like examples, let me just give you the commitment of a:

(a1a2a3a4),(G1G2G3G4)=a1G1+a2G2+a3G3+a4G4

Different protocols (like the halo one I talk about in the first post) since bootleproof (the paper that came before bulletproofs) aggregate commitments differently. In the explanation above I didn’t aggregate anything, but you can imagine that you could make things even smaller by having a single commitment P=A+B+C to the inputs/output.

At this point, a prover can just reveal both inputs a,b and the verifier can check that they are valid opening of A,B, and C (or to P if you aggregated all three commitments). But this is note very efficient (you have to perform the inner product as the verifier) and it also is not very compact (you have to send the long vectors a and b). I know it’s also not zero-knowledge, but we will just explain Bulletproofs/IPA without hiding, and for the hiding part we’ll just ignore it as we usually do in such ZKP schemes.

The prover will eventually send the two input vectors by the way, but before doing that they will reduce the problem statement a,b=c to a much smaller a,b=c where the vectors a and b both have a single entry. If the original vectors where of size 2n then Bulletproofs will perform n reductions in order to get that final statement (as each reduction halves the size of the vectors), and then will send these “reduced” input vectors (for the verifier do perform the same check as before).

For us, this means that there are two things to understand next:

  1. how does the reduction work?
  2. how is it verifiable?

To reduce stuff, we do the same basic operation we’re doing in every “folding” protocol: we pick a challenge x and we multiply it with one half, then add it to the other half. Except that here, because we’re dealing with a much harder algebraic structure to work with (these Pedersen commitments, which as I pointed in this post, are basically random linear combinations of what you’re committing to, hidden in the exponent), we’ll have to also use the inverse x1.

Here’s how we’ll fold our inputs:

  • a=x1(a1a2)+x(a3a4)
  • b=x(b1b2)+x1(b3b4)

Then you get two new vectors a,b of half the size. This means nothing much so far, so let’s look at what their inner product looks like:

a,b=(x1a1+xa3x1a2+xa4),(xb1+x1b3xb2+x1b4)=(a1b1+a2b2+a3b3+a4b4)+x2(a1b3+a2b4)+x2(a3b1+a4b2)=a,b+x2(L)+x2(R)

for some cross terms L and R that are independent of the challenge x chosen (so when we will Fiat-Shamir this protocol, the prover will need to produce L and R before sampling x).

Wow, did you notice? The new inner product depends on the old one. This means that as a verifier, you can produce the reduced inner product result in a verifiable way by computing

a,b=a,b+stuff

If what you have is a commitment C=a,bQ, then you can produce a reduced commitment C=C+stuff where stuff is essentially provided by the prover, and is not going to mess with C because of the challenge that’s shifting/randomizing that garbage (it’ll look like x2[L]+x2[R] where [L] and [R] are commitments of the protocol L and R).

So we tackled the question of how do we reduce, in a verifiable way, the result of the inner product. But what about the inputs?

Of course, you can do the same for the commitment of a and b! So essentially, you get [a]=reduce([a],x,stuff) (and similarly for b).

We can go over it in a quick example, but it’ll pretty much look the same as we did above except that we also have to reduce the generators G for the first input (and H for the second input).

The first thing we’ll do is reduce the generators:

G=x(G1G2)+x1(G3G4)

then we will look at what a Pedersen commitment of our reduced first input a looks like:

A=a,G=(x1a1+xa3)(xG1+x1G3)+(x1a2+xa4)(xG2+x1G4)=A+x2(a1G3+a2G4)+x2(a3G1+a4G2)=A+x2La+x2Ra

In other words, a,G=a,G+stuff (and similarly for the second input).

In the Bulletproofs protocol, we’re dealing with a single commitment P=A+B+C and so we’ll reduce that statement to P=P+stuff where stuff contains the aggregated L and R for all of the separate commitments.

So just a recap, this is what you’re essentially doing with this first round of the protocol:

  1. we start from P=a,G+b,H+a,bQ
  2. the prover produces the points L and R
  3. the verifier samples a challenge x
  4. they both produce P=P+x2L+x2R

at this point the prover can choose to release a and b and the verifier can check that this is a valid opening for P by comparing it with a,G+b,H+a,bQ (so the verifier needs to produce the reduced bases G and H as well).

you can imagine that in Bulletproofs, they don’t stop there, they just notice that this looks like another statement that you could reduce as well, so you do that until your reduced inputs are both of size 1.

Notice that we computed a,bQ which is important because you want to make sure that the inner product result is indeed a,b and not some arbitrary value. Checking this in the reduced form tells you with high probability that this is true as well in the original statement P.

Anyway, that’s it, hopefully that adds some colors to what Bulletproofs look like. In real-world implementation, the reductions are not checked one by one, instead an optimized check aggregates all of them.

← back to all posts blog • 2025-09-26
currently reading:
High-level intuitions for the Bulletproofs/IPA protocol
09-26 blog
📖 my book
Real-World Cryptography is available from Manning Publications.
A practical guide to applied cryptography for developers and security professionals.
🎙️ my podcast
Two And A Half Coins on Spotify.
Discussing cryptocurrencies, databases, banking, and distributed systems.
📺 my youtube
Cryptography videos on YouTube.
Video explanations of cryptographic concepts and security topics.