The Blockchain Privacy Trilemma: Part One
Inspired by Vitalik’s scalability trilemma, we propose a privacy trilemma to help reason about privacy in the context of blockchain.
In this blog post, I’ll explain why the privacy trilemma makes privacy (and data confidentiality) so difficult on the blockchain. I’ll then make the case for why Obscuro (now known as Ten) optimises for all three.
Our thesis is that without revolutionary technology, like homomorphic encryption (or something greater), most solutions can only solve for two out of Privacy, Programmability and Decentralisation.
Privacy here is defined as the ability to keep transactions hidden from all participants, including any sequencers or miners.
Programmability is the ability to be Turing complete and solve for all use-cases.
Decentralisation is the degree to which you can move beyond a single entity controlling a critical aspect of the solution, leaving no single point of failure. For example, centralised sequencers or aggregators
Before I can start to break down the thesis, we’ll need to go on a short journey to better understand the technology available to us today. This is what Part 1 of this series will cover. In Part 2 I’ll go deeper on the ‘Why’.
The U.S. Constitution came into effect in 1789 and with it the right to privacy in its First, Third, Fourth and Fifth amendments.
In 1948 George Orwell writes the dystopian novel, 1984 where inhabitants of Oceania have no privacy. Public and private spaces are filled with cameras and microphones.
October 31st, 2008, Satoshi Nakamoto publishes the Bitcoin White Paper and with it, in section 10, a piece on privacy:
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone.
Now, when one thinks of privacy on blockchain, an immediate reaction might be: Hasn’t blockchain always been private? No, it’s always been anonymous.
From the very beginning, Bitcoin allowed you to own and spend Bitcoin from a pair of cryptographic keys you controlled. These keys were not linked to you in any obvious way. So we could all see what was being spent and when, but not who was spending it.
So let’s think about this for a moment. When Satoshi invented blockchain technology, he couldn’t have imagined we’d go from Bitcoin, a transparent ledger of all transactions where anonymity was preserved, to a world where central exchanges and various fiat currency on-ramps form most of the entry points into the blockchain world. Nor could he have predicted the rise of Turing complete blockchains, such as Ethereum, being built on his foundation.
Now multiple companies exist that can quickly work out exactly who you are by analysing the graph of transactions on any public blockchain. Multiple companies exist that can pick apart your trades, work out the models you’re employing, and front-run you. Even actions like paying for a coffee or playing a game can be seen by everyone.
Users of public, permisionless, blockchains are no longer anonymous, and nothing they do is private.
There exist today several approaches to increasing anonymity and adding privacy. However, before we can appreciate how these approaches are used, we first need to understand the difference between the UTXO and the Account model.
UTXO, Unspent Transaction Output, was first introduced through Bitcoin. The Account (aka Balance) model is employed by Ethereum and is widespread outside of blockchain.
UTXO
With UTXO, each transaction is formed of inputs and outputs. Each of these inputs represents some subset of the existing world state, and each output represents the state to which you wish to transition. For example, if you’re the owner of one Bitcoin and want to send it to Bob, the existing state of the world is you own a Bitcoin, and the future state is, Bob owns that Bitcoin. The transaction would represent the act of retiring (‘spending’) the first state and replacing it with the second. All the ‘unspent’ transactions are what each node on the network keeps track of and reflects the world’s current state.
In the example above, the UTXO representation shows Alice as the owner of ten Bitcoin. She wants to send Bob five Bitcoin and so builds a transaction with her ten Bitcoin as an input and creates two new states as outputs. One with Bob as the new owner of five Bitcoin and another representing her now ownership of five Bitcoin, or in other words, her ‘change’ from the transaction.
If Alice then tries to send another ten Bitcoin to Bob, the only input she can use is the now ‘spent’ state representing her original ten. If she tries to spend this, the network rejects the transaction as a double spend.
You can reach a good analogy by trying to understand the thoughts of Satoshi at the time of inventing Bitcoin. Satoshi was trying to recreate the properties of physical cash but in digital form. And so, you can think of the UTXO model as paper notes. Each note keeps track of its own amount and current owner (state), and by adding up all the paper notes in your wallet, you know how much you have. These notes in your wallet are ‘unspent’. Once you’ve spent one of these notes, the state is updated to reflect the new ownership, and you can’t spend it again.
Hopefully, a mental model should be forming where with UTXO, the order of events is explicit and foundational to the protocol, allowing the network to operate without a global ordering of transactions and crucially, the validity of any given transaction depends only on that transaction itself and those it depends on.
Account model
The Account model keeps track of the balance of each account as a global state. An analogy of the Account model would be a bank account. The bank tracks how much money everyone has. Whenever you spend via a card, the bank checks your account has a sufficient amount of money, approves the transaction accordingly, and updates its records.
Looking back at the diagram, to make a token transfer on Ethereum, the network as a whole (everyone acts as the bank!) checks the global account state. It ensures the amount being transferred by you is less than the total amount allocated to you, and then everyone updates their records.
The Account model also means that Ethereum can only ever do one thing at a time. you have to check each transaction one after the other because you don’t know until the first one has executed what parts of the global state it might have changed.
UTXO lends itself well to token transfers due to the strict enforcement of the progression of states. The Account model, being higher on the abstraction ladder, gives us DeFi and anything else requiring account-like functionality.
Approaches to Privacy (and Anonymity)
Starting from Monero, the space has seen an explosion of solutions, from those tackling the problems of trying to maintain anonymity better than Bitcoin and Ethereum, to specialised privacy and recently, generalised privacy.
Ring Signatures
Made popular through Monero, ring signatures allow senders of Monero to remain hidden from observers by combining their signature with a group of ‘decoy’ outputs from a set of previous transactions. As an observer, the transaction appears as a series of outputs with signatures, all with an equal possibility of being valid. Essentially, the approach embeds in the protocol a decoy mechanism to make analysis incredibly difficult. You can read more about Ring Signatures in Monero here
Zero Knowlege Proofs
A zero-knowledge proof or zero-knowledge protocol (ZKPs) is a set of cryptographic protocols by which one party (the prover) can prove to another party (the verifier) that a given statement is true without conveying any information apart from the fact that the statement is indeed true. The essence is that, while it is trivial to prove that one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information.
Z-Cash, Manta Network and Railgun are examples of blockchain projects that use ZKPs for specialised privacy.
Trusted Execution Environments
Trusted Execution Environments, or TEEs for short, are secure areas in computer processors where code is guaranteed to be protected for confidentiality and integrity. All execution is isolated from other parts of the computer, making it impossible, even for the computer operator, to access its contents. It’s the technology that secures many of your devices.
They allow encrypted data to be processed securely, either locally or remotely, with additional guarantees over exactly what computations are being run over the data so the data owner is always in control.
Some of the most popular implementations include Intel SGX and ARM TrustZone. There have been cases where researchers have managed to force TEEs to leak data. Still, these have never knowingly been exploited outside laboratory conditions and are patched immediately by the manufacturers.
TEEs are used in the wild for DRM and for storing sensitive data, such as biometrics. The messaging service Signal uses TEEs to keep contacts secret.
TEEs have also made their way into the blockchain space, and are used by projects such as Avalanche, Chainlink, Oasis Network, Secret Network and Obscuro.
Homomorphic encryption
Homomorphic encryption makes it possible to analyse or manipulate encrypted data without revealing the data to anyone, including those doing the processing. Only actors with the relevant keys can access the unencrypted data (their own) once processing is complete.
However, there still exists the problem of how do you know the system executing the homomorphic operations executed the ones you asked it to? How do you know it didn’t subtract two numbers rather than adding them? You know they can’t SEE the raw data. But do you know they did the calculation they claimed they did?
The combination of Homomorphic encryption and ZKPs could be the holy grail for many and potentially provide the functionality TEEs provide today without hardware.
With this foundation in place, in Part 2, I’ll be clearing up some of the confusion around ZKPs, their application in rollups and why ZKPs cannot solve the trilemma.
Find out more
To learn more about Ten, dive into the whitepaper, chat with the community on Discord, and follow us on Twitter.
