tl;dr: Confidential assets are in town! But first, a moment of silence for veiled coins.
Notation
- For time complexities, we use:
- $\Fadd{n}$ for $n$ field additions in $\F$
-
$\Fmul{n}$ for $n$ field multiplications in $\F$
- $\Gadd{\Gr}{n}$ for $n$ additions in $\Gr$
- $\Gmul{\Gr}{n}$ for $n$ individual scalar multiplications in $\Gr$
- $\fmsm{\Gr}{n}$ for a size-$n$ MSM in $\Gr$ where the group element bases are known ahead of time (i.e., fixed-base)
- when the scalars are always from a set $S$, then we use $\fmsmSmall{\Gr}{n}{S}$
- $\vmsm{\Gr}{n}$ for a size-$n$ MSM in $\Gr$ where the group element bases are not known ahead of time (i.e., variable-base)
- when the scalars are always from a set $S$, then we use $\vmsmSmall{\Gr}{n}{S}$
Preliminaries
We assume familiarity with:
- Public-key encryption
- In particular, Twisted ElGamal
- ZK range proofs (e.g., Bulletproofs1, BFGW, DeKART)
- $\Sigma$-protocols
Baby-step giant step (BSGS) discrete log algorithm
Naively, computing the discrete log $a$ on $a \cdot G$, when $a\in[2^\ell)$ could be done in constant-time via a single lookup in a $2^\ell$-sized pre-computed table.
The BSGS algorithm allows for reducing the table size to $\sqrt{2^\ell} = 2^{\ell/2}$ while increasing the time to $\GaddG{2^{\ell/2}}$.
Explain the algorithm.
FAQ
Why not go for a general-purpose zkSNARK-based design?
Question: Why did Aptos go for a special-purpose design based on the Bulletproofs ZK range proof and $\Sigma$-protocols, rather than a design based on a general-purpose zkSNARK (e.g., Groth16, PLONK, or even Bulletproofs itself)?
Short answer: Our special-purpose design best addresses the tension between efficiency and security.
Long answer: General-purpose zkSNARKs are not a panacea:
- They remain slow when computing proofs
- This makes it slow to transact confidentially on your browser or phone.
- They may require complicated multi-party computation (MPC) setup ceremonies to bootstrap securely
- This makes it difficult and risky to upgrade confidential assets if there are bugs discovered, or new features are desired
- Implementing any functionality, including confidential assets, as a general-purpose “ZK circuit” is a dangerous minefield (e.g., circom)
- It is very difficult to do both correctly & efficiently2
- To make matters worse, getting it wrong means user funds would be stolen.
Still, general-purpose zkSNARK approaches, if done right, do have advantages:
- Smaller TXN sizes
- Cheaper verification costs.
So why opt for a special-purpose design like ours?
Because we can nonetheless achieve competitively-small TXN sizes and cheap verification, while also ensuring:
- Computing proofs is fast
- This makes it easy to transact on the browser, phone or even on a hardware wallet
- There is no MPC setup ceremony required
- This makes upgrades easily possible
- The implementation is much easier to get right
- We can sleep well at night knowing our users’ funds are safe
Construction
Chunk sizes
We chose 16-bit chunks to ensure that the max pending balance chunks never exceed $2^{32}$ after around $2^{16}$ incoming transfers. This, in turn, ensures fast decryption times.
Why so many incoming transfers? There could be use cases, such as payment processors, where seamlessly receiving many transfers is necessary.
Resources
Appendix
BL DL benchmarks for Ristretto255
These were run on a Macbook M3.
Chunk size | Algorithm | Lowest time | Average time | Highest time |
---|---|---|---|---|
16-bit | Bernstein-Lange3 | 1.67 ms | 2.01 ms | 2.96 ms |
32-bit | Bernstein-Lange3 | 7.38 ms | 30.86 ms | 77.00 ms |
48-bit | Bernstein-Lange3 | 0.72 s | 4.03 s | 12.78 s |
Something is off here: BL should be much faster than BSGS. e.g., on 32 bit values, BL takes $30.86$ ms on average, while BSGS similarly takes $2^{16}$ group operations $\Rightarrow$ 0.5 microseconds $\times 2^{16} \approx 32$ ms.
Related work
There is a long line of work on confidential asset-like protocols, both in Bitcoin’s UTXO model, and in Ethereum’s account model. Our work builds-and-improves upon these works:
- 2015, Confidential assets4
- 2018, Zether5
- 2020, PGC6
- 2025, Taurus Releases Open-Source Private Security Token for Banks, Powered by Aztec, see repo here
- 2025, Solana’s confidential transfers
References
For cited works, see below 👇👇
-
Bulletproofs: Short Proofs for Confidential Transactions and More, by B. Bünz and J. Bootle and D. Boneh and A. Poelstra and P. Wuille and G. Maxwell, in 2018 IEEE Symposium on Security and Privacy (SP), 2018 ↩
-
Writing efficient and secure ZK circuits is extremely difficult. I quote from a recent survey paper7 on implementing general-purpose zkSNARK-based systems: “We find that developers seem to struggle in correctly implementing arithmetic circuits that are free of vulnerabilities, especially due to most tools exposing a low-level programming interface that can easily lead to misuse without extensive domain knowledge in cryptography.” ↩
-
Computing small discrete logarithms faster, by Daniel Bernstein and Tanja Lange, 2012, [URL] ↩ ↩2 ↩3
-
Confidential transactions, by Gregory Maxwell, 2015, [URL] ↩
-
Zether: Towards Privacy in a Smart Contract World, by Bünz, Benedikt and Agrawal, Shashank and Zamani, Mahdi and Boneh, Dan, in Financial Cryptography and Data Security, 2020 ↩
-
PGC: Pretty Good Decentralized Confidential Payment System with Auditability, by Yu Chen and Xuecheng Ma and Cong Tang and Man Ho Au, in Cryptology ePrint Archive, Report 2019/319, 2019, [URL] ↩
-
SoK: What don’t we know? Understanding Security Vulnerabilities in SNARKs, by Stefanos Chaliasos and Jens Ernstberger and David Theodore and David Wong and Mohammad Jahanara and Benjamin Livshits, 2024 ↩