Blockchain Privacy and a Short History of PLONK
After a breathless summer of new cryptographic techniques, now seems a good time to flesh out a short history of SNARKs, and the innovation of ‘universality’ that led to the creation of PLONK — a collaboration between AZTEC Protocol and Protocol Labs.
This series is broken into three articles:
- The Need for Privacy on a Blockchain (you are here!)
- The Circuit-Specific SNARK
- The Universal SNARK
If you are just interested in PLONK, and are familiar with Groth16 and its use in ZCash, please skip to Part 3. We include benchmarks on PLONK’s implementations, and lightly compare it to other SNARK systems.
About AZTEC
AZTEC Protocol is building privacy on blockchains — perhaps the SSL certificate for the Internet of Value is the best entry-level analogy.
SSL certificates provide end-to-end encryption of data to and from web servers.
We’re doing something similar for value transmission — but in many ways it’s a harder and more technical problem to solve. In this article we’ll explain why.
1. The Importance of Blockchain Privacy
Just as the internet replaced letters and books for data transmission, blockchains look set to replace classical payment rails, and open up a boom in programmatic access to cash and other financial instruments.
Our transaction records identify us, reveal our locations, our preferences, our assets, our paymasters, our spending. However seamlessness finance might become through Web 3.0 — what would ever induce us to expose all that information to the world?
Imagine if your internet records were not just viewable by Google and Facebook, but by everyone and forever — your friends, your family, your colleagues, in perpetuity.
So when it comes to Web 3.0, you’ll keep your day-to-day well away from these ledgers, until you have a guarantee of privacy.
Transaction Privacy
Let’s briefly consider a naïve data privacy method, to help see why transaction privacy is somewhat difficult.
The most basic guarantee of private data available on a blockchain is a simple notarisation — pass the data through a hash function to create a fingerprint, and send that hash output to the blockchain.
This hash, mined on a blockchain, lets third parties:
- Verify some piece of data existed on at a point in time, and
- Determine whether this data has changed since that timestamp
It’s pretty good for things like wills, which ultimately will be opened and verified and executed by a single person.
But it doesn’t work for financial execution — where you need ongoing execution, and ongoing privacy.
Suppose you hash ‘I hereby give Alice ownership over the $5 bill on my mantlepiece’, and send that hash to Ethereum.
This clearly fails the basic requirements of private execution:
- All or Nothing: To prove you committed to sending someone $5, you need to ‘open’ the envelope to the verifier — if the verifier is a blockchain, that’s the whole world, and transaction privacy is gone
- Double Spend: It is possible that at exactly the same time, you also hashed ‘I am holding the $5 bill on my mantlepiece in favour of Bob’. You might have shown the ‘openings’ (decryption) of each of these messages individually to Alice and Bob, neither suspecting you’d promised exactly the same $5 bill to the other
- You might just keep it: if you don’t show the ‘opening’ of the hash to either Alice or Bob, you’ve really committed to nothing at all
So this crude brand of privacy can’t be used to execute private financial transactions.
We need something that can go deeper into encrypted data — that can confirm a transaction happened, and immediately verify the financial logic.
The ZK-SNARK
An early answer to this problem has been the ZK-SNARK — that is, Zero Knowledge Succinct Non-interactive Arguments of Knowledge.
The ZK-SNARK ushers in the era of efficient programmable privacy — allowing blockchains to execute transactions by verifying that an arbitrarily complex program has been run correctly. This program will implement the rules of a financial asset — like a bank balance, or a call option, or shares in a company.
Again, to be concrete, here is such a program for a spending system:
Whenever a spender wants to pay for something, the amount received by the vendor must be equal to the spender’s money before the transaction less their money after the transaction.
Any variable in such a program can be hidden from view — and yet Ethereum, other blockchains or even just a third party validator, can verify that whoever ran that circuit did so correctly.
The next article describes the first generation of SNARKs — those with circuit-specific setups.
Part 2: The Circuit-Specific SNARK
Get in Touch
Whether you’d like to participate in the ceremony, apply to work at AZTEC Protocol, find out more about using our cryptosystems in your dapp, or just chat, please get in touch at hello@aztecprotocol.com or join our Telegram and Discord channels.
