Privacy enhancing technologies explained
A blockchain, at its very core, is a way for everyone to agree on what the current state of the world is, without having to rely on a trusted authority.
Of course, by “everyone” we don’t actually mean everyone, but instead everyone who believes in the security model. Likewise, by “the world” we also don’t actually mean the world, but rather, whatever is currently written on the blockchain’s ledger. Nevertheless, well-known blockchains such as bitcoin or ethereum both have market caps in the 100s of billions of USD, which tells us that the technology excites people.
Programmable blockchains, in particular, are exciting because their “world” is very rich. On a programmable blockchain, the “world” is basically the current memory of a computer, and so, simply by being clever about how we design the programs that run on this computer, we can use it to accomplish almost anything.
Let’s digress for a bit and classify programs into three categories:
— Those that take a public input and produce a public output
— Those that take a private input and produce a public output
— Those that take a private input and produce a private output
A programmable blockchain such Ethereum supports programs of the first kind: Everyone sees what goes into a smart contract on Ethereum, and everyone sees what comes out again. This is great for some applications (like agreeing on who bought a NFT), but clearly not sufficient for others (like performing an auction).
Several solutions have surfaced which attempt to support the remaining two types of computations. Let’s take a brief look at some of them:
Zero-knowledge proofs
Zero-knowledge proofs (ZKPs) are, in a nutshell, a way for someone to convince (i.e., prove to) someone that they know or possess something, without revealing anything about that something. One situation where this shows up, is when someone wishes to prove to someone else that they control a certain amount of tokens.
ZKPs can therefore be used for private-public and private-private computation, to a limited degree. ZKPs can only compute, well, proofs. This in particular means that the computations are limited to a binary “yes” or “no” output. Moreover, ZKPs are inherently single-user oriented, so it is not possible to perform a computation that takes multiple private inputs.
Note that a program that takes a public input, but produces a private input does not make sense. If everyone can see the program and what goes into it, then everyone can obviously see the output as well.
Fully homomorphic encryption
Another private computation technique is fully homomorphic encryption, or FHE as it is called for short. At its very basic, FHE is a way of encrypting data such that it is possible to perform computations directly on the encryption.
This immediately tells us that FHE for sure supports private input private output type computations.
However, FHE, like ZKPs, are oriented towards a single user scenario. This means that, although FHE can perform any computation (which ZKPs cannot do), they cannot perform a computation that receives private inputs from multiple users.
Trusted execution environment
In contrast to the two above technologies (as well as the next one), trusted execution environments (shortened as TEEs) are a purely hardware based solution to the private computing problem we’re looking at.
A TEE is simply a piece of hardware that have been hardened in certain ways that make it hard to break into. If we believe this to be the case, then a TEE can be used to perform the private input, public/private output computations we’re interested in.
Inputs are encrypted using a key stored only on the TEE, and computations take place on the TEE after decryption. When the computation is done, the output is encrypted (or not, depending on whether the output should be public or private) and then output by the TEE. In this way.
TEEs therefore clearly support the type of single-private-input computations talked about so far. However, the situation is a bit complicated if we want to receive inputs from multiple sources. Indeed, the only way that can be possible, is to make sure the same key is stored on everyone’s TEE.
Secure multiparty computation
The last tech I will look at is secure multiparty computation, or MPC. This privacy tech supports both types of computations, just like FHE and ZKPs, but where it distinguishes itself is that it naturally supports private inputs from multiple sources. Indeed, there’s a reason it’s called secure multiparty computation.
This makes MPC especially suited for a blockchain because of its multi-user nature.
Wrapping up
The above categorization leaves out a lot of details, since it talked about neither the security models that each of the technologies use, nor about their efficiency.
Each of the four technologies above operate in a particular security model, and none of the models are exactly the same. Likewise, they each have some properties that make them desirable compared to the others. (For example, FHE requires more computation, but less communication, than MPC.)
In general, MPC does seem to come out on top, and is the only technology that easily supports computations where multiple users provide inputs. MPC, by its nature, is a decentralized technology, which is probably why it works so well in a blockchain setting. That being said, an ideal world would probably use all of the technologies in a carefully created orchestration to ensure the best guarantees in terms of both security and efficiency.
Stay updated:
Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube