This blog post was written by PegaSys Applied Researchers, Gautam Botrel and Thomas Piellard. In it, they cover how to use AZTEC, an efficient zero-knowledge privacy protocol, to create and trade an anonymous asset on a private network with the implementation of PegaSys’ Enterprise Ethereum client, Pantheon.
Tokens represent the most powerful and widely adopted use case for blockchain. Yet, enterprises are often blocked from harnessing the power of tokens due to the public nature of balances and transaction amounts on public chains like Bitcoin and Ethereum. By partnering with AZTEC on this tutorial, we have sought to provide an efficient, simple solution for hiding the balances and amounts involved in token transactions on Pantheon. Our eventual goal is to enable zero-knowledge transactions in private networks that can achieve the 100+ TPS (transactions per second) throughput enterprises need.
The typical requirements enterprises ask for related to privacy are:
PegaSys has taken a multi-faceted approach to privacy: we partnered with Web3 Labs to integrate Orion, a private transaction manager in Pantheon, and our R&D teams (sidechains, zero-knowledge computation) are advancing other research rapidly.
In this post, we’re going to explore how to use AZTEC, an efficient zero-knowledge privacy protocol, to create and trade an anonymous asset on a private network.
We’re going to focus on a simple scenario: create and trade a token, while keeping balances hidden.
We wrote 2 examples, with simple scenarios around confidential transactions:
1. Mint and trade confidential assets (no ERC20 counterpart)
2. Convert ERC20 tokens to confidential assets (aka ZkAsset or AZTEC notes)
You can check out the code here.
1.Start a Pantheon node
docker run -p 8545:8545 pegasyseng/pantheon:latest –miner-enabled –miner-coinbase fe3b557e8fb62b89f4916b721be55ceb828dbd73 –rpc-http-cors-origins=”all” –rpc-http-enabled –network=dev
2. git clone firstname.lastname@example.org:pegasyseng/pantheon-aztec-quickstart.git && cd pantheon-aztec-quickstart
3. yarn install
4. yarn run zkasset
5. yarn run zkasset-erc20
At its core, AZTEC relies on “notes”, and similarly to Bitcoin or ZCash, follows the UTXO model. A valid transaction specifies a list of existing notes that are “destroyed” (spent) and a list of notes that are created.
A note is “owned” by who possesses knowledge of its viewing key. An AZTEC account is an ECC keypair on secp256k1 (like in Ethereum). The creator of a note specifies a public key belonging to the future note owner. The viewing key (key allowing the decryption of a note) is the result of a shared secret between the note’s creator and the note’s recipient, using a Diffie Hellman procedure between an ephemeral public/private key generated by the note’s creator and the note recipient’s public key.
Similarly to Confidential Transactions, Monero, ZCash or Grin the note values are blinded through a commitment scheme. Unlike these protocols, AZTEC don’t use Pedersen commitments but a scheme derived from Boneh – Boyen signatures.
Here is a high level sketch of an AZTEC confidential transaction, where Alice wants to transfer 150 AZTEC notes to Bob.
In step 3, Alice (the prover) constructs the zero-knowledge proof (without revealing either Σinputs nor Σoutputs)
Σinputs = Σoutputs + kpublic
If kpublic=0, the transaction involves only confidential notes. This is the case in our example (Alice has 150 notes that she transfers to Bob).
If kpublic<0, Σoutputs > Σinputs, and kpublic ERC20 tokens are “shielded” into notes.
If kpublic>0, Σoutputs < Σinputs, and kpublic notes are “unshielded” to ERC20 tokens.
[Note: in ZCash, kpublicis called vbalance and similarly indicates ZEC moving in and out of the Transparent/Sapling Pool]
The proof system created by AZTEC consists of a sigma protocol, a common technique used in zero-knowledge systems.
In a sigma protocol, the prover convinces a verifier that she knows some secret data “s” without revealing it. The flow is in three steps and matches the shape of capital “sigma” Greek letter:
At the end, the verifier checks that some relation R between “w” ( = f(p,c) ) and “r” ( = g(c,s) ) holds. The protocol is designed such that R holds if and only if “r” is computed with the right “s” therefore it proves that the prover knows “s” without revealing it.
Such a thing is achievable because remember that “p” depends on “s” in the first place!
In practice, this sigma protocol is made non-interactive using a Fiat-Shamir heuristic. To dig deeper into the commitments and the zero-knowledge proof, please read our AZTEC protocol cheat sheet.
Our benchmarks show that with the current implementation you can create joinSplit proofs (2 notes destroyed, 2 notes created) in 25ms and verification cost is about 1Million gas. On a private network, TPS (transactions per second) will depend on the settings (block size, block interval).
Confidential transactions come in many flavours.
In AZTEC’s current implementation, amounts are hidden, and it is not possible for a party exterior to a transaction to decipher the values involved.
However, it does not enforce anonymity of participants. We consider anonymity “broken” because it is possible to analyze the transaction graph and deduct who is transacting with who in each transaction.
Three keys informations are available:
Hence, when a note is spent, it is possible to browse the previous transactions and see in which transaction the note was created, and by who it was signed. On private networks, we may mitigate this, if an issue at all.
AZTEC realized a tour de force, by making efficient confidential transactions available on Ethereum. The protocol paves the way for more complex use cases (loans, delegate calls…) — check out the specification, whitepaper and blog posts to know more.
Interested in more complex implementations? Please reach out to the author Gautam.Botrel@consensys.net.
We are actively looking for customers and system integrators across industries to use Pantheon. If you want to discuss working with us, send us an email at email@example.com.
PegaSys is hiring! Check out our list of open roles.