Aztec is building a high-speed privacy network on Ethereum.
Using mathematics and cryptography code invented and built by our team of leading cryptographers and engineers, we’re targeting VISA-scale capacity through a single entry point — the “Aztec Cryptography Engine”.
Here’s how you can use the protocol today:
- Developers: Go to our docs, and integrate confidential payments into your dApp now with our Privacy SDK — Aztec is live on mainnet
- Community: We’ve had countless requests for direct user access, so we’ve built you zk.money — here you can shield, send, and unshield zkDAI and zkWETH today. You just need a MetaMask account.
Triptych of Privacy
For newcomers to Aztec — our privacy roadmap is as follows:
- ✅ Balance privacy — hiding transaction amounts
- ⌛ User privacy (coming soon) — hiding ‘spender’ and ‘receiver’ info
- ✘ Code privacy — hiding asset/code being spent/run
Of course, Ethereum is congested, and privacy is expensive.
Which brings us to the next step for Aztec — Rollup.
Aztec is pleased to confirm the team is working on ZK-ZK Rollup for PLONK proofs, to collapse the gas costs of private transactions on mainnet.
Classical ZK Rollup leverages the ‘succinctness’ property of SNARKs to scale public blockchains. It allows a large number of transactions to be ‘rolled up’ into one aggregated transaction, so Ethereum can execute 100s or 1000s of spends at once, with the gas cost of a single transaction.
So ZK-SNARKs are a core tool for scaling. And we already know you can use ZK-SNARKs for privacy. But can you achieve both?
The answer is ‘yes’.
Aztec is now actively working on ZK-ZK Rollup, or in shorthand, ZK² — so-called because it comprises SNARKs at two or more layers:
- ‘Lower Level’ ZK-SNARKs each representing a private transaction
- ‘Upper Level’ ZK-SNARK, which is the Rollup SNARK, succinctly proving the correctness of the Lower Level SNARKs
Note: The nomenclature is a little crude because one doesn’t actually require the ‘Upper Level’ Rollup to be ZK (Zero Knowledge) — once the Lower Level SNARKs (private transactions) are created, their privacy is assured. The Rollup in fact just depends on the ‘S’ property in the acronym ‘SNARK’ — meaning ‘Succinct’. We need to take expensive-to-check private transactions, and replace them with a single succinct rollup proof, whose cost is spread across all those transactions.
Aztec will soon allow you to send private payments at 100 tps on mainnet, with both balance privacy and user privacy baked in.
In the case of visible rollup, 2,000 tps is already theoretically achievable.
So why is private rollup so much harder?
What Makes ZK² Rollup So Difficult
1. Recursion: Proofs of Proofs
In standard ZK rollup, the rollup SNARK proof is reasoning about quite SNARK-friendly mathematics — the logic around public token transfers can easily be translated into ‘arithmetic circuits’.
But for ZK² Rollup, you need to verify a SNARK proof (Lower Level, Privacy SNARK) inside another SNARK circuit (Upper Level, Rollup SNARK).
This is called recursion — the act of proving SNARKs inside SNARKs.
And recursion is tough, because you either need very special mathematical conditions to exist, or else you have a computational mountain to climb.
Specifically, you need one of the following:
- To find so-called ‘pairing-friendly’ cycles of curves, which are very rare beasts, and where they exist, their security is so low you need to pick very large and computationally expensive number systems in which to describe them (e.g. the MNT4 and MNT6 curves), or
- To emulate binary arithmetic within a circuit, which in turn can be used to emulate prime field arithmetic. This requires heavy use of range proofs. And range proofs are expensive.
2. State Updates
Aside from the computational headwinds, the administration of state updates has more overhead than public ZK Rollup. ZK² Rollups require more state updates and require the dispatch of a lot more data:
- For standard (public) ZK Rollup, one can use an account-based model — this requires 2 state updates per transaction. But, to guard against statistical attacks, privacy-preserving ZK² Rollups require twice that data — 2 state variables are added to the state tree, and 2 further variables are added to the nullifier tree
- Perhaps an even bigger bottleneck is the data haulage requires— traditional rollup involves a payload of 4–8 bytes per transaction, but the privacy cloak requires 32–64 bytes of data per transaction. Data on Ethereum remains expensive
3. Provable Randomness
We also need to validate sources of randomness (the magic that turns ‘interactive proofs’ into ‘non-interactive proofs’, so you don’t have to endure a painful question-and-answers session with Ethereum every time you want to spend some cash).
This randomness means hashes. And hashes in SNARKs are a real problem:
- SNARK-friendly hash algorithms (e.g. Pedersen hashes) lack the pseudorandomness of traditional hashes: change one bit of the input to a Pedersen hash, and you know what will happen to the output. With this property missing, we can’t easily generate a number the prover is incapable of manipulating
- We could turn to less widely-accepted SNARK-friendly hashes (e.g. Poseidon, Rescue) — but burn-in and widespread adoption are so fundamental to our faith in cryptographic primitives, it is probably too early deploy these in value-carrying cryptosystems
- So we have little choice but to turn to SNARK ‘unfriendly’ hash algorithms (e.g. Blake2 or SHA256) which make heavy use of binary logic and range proofs
However, Aztec has recently made some critical R&D breakthroughs in 2020, including our latest research paper PLOOKUP, enabling practitioners to do SNARK-unfriendly things efficiently inside SNARKs.
Combined with other innovations, the door to recursion is broken down.
PLONK: A New ZK Standard
Our SNARK proofs are built using state-of-the-art mathematics known as PLONK, created by our CTO Zac Williamson, and our now-Chief Scientist Ariel Gabizon.
In the past few months we’ve seen other leading scaling and privacy projects join the PLONK ecosystem:
- Dusk Network recently announced their switch to PLONK
- Matter Labs is implementing a form of PLONK in the transparent setting
Our Universal SNARK system describes a new way to wire up circuits (R1CS being the incumbent standard). Switching standards always comes with a cost, requiring the rewriting of industry-standard code libraries. And with the introduction of TurboPLONK, accepted standards over choices of ‘custom gates’ (i.e. more exotic gates than just ‘+’ addition and ‘×’ multiplication) are at only the very earliest phase of formation.
So, seeing important projects switch to PLONK-based systems is a great endorsement of the enormous efficiency gains this proving scheme brings. We look forward to seeing many more projects building on PLONK-based systems in 2020.
Stay up-to-date with the latest Research
Our Research Library provides the latest papers, benchmarks on our TurboPLONK project, and primers to help armchair mathematicians gain some intuition about zero knowledge systems.
And for regular updates, sign up for our bulletin!