The point of this document is to provide the shortest (and most intuitive) possible introduction to each of the technologies mentioned in the title. I hope I succeed in this endeavor.
The technologies in this document all — with exception of differential privacy — deal with “secure” computation on data. At a very high level, this means they can be used to perform an arbitrary computation on one or more pieces of data, while keeping this data private.
Secure multiparty computation, which is what we do here at Partisia, is the term for a fairly broad class of protocols that enable two separate entities (called parties) to compute a function, while revealing nothing except the output.
An MPC protocol typically proceeds in three phases: First the inputters secret-share their private inputs. This step can be thought of as each user sending a special type of encryption of their inputs to the nodes doing the computation. The encryption ensures, for example, that at least two out of three nodes are required to recover the input, and thus, we get a security model that relies on non-collusion. It could also be the case that all three nodes must collude to recover the input — in this case, we have a full threshold model (since all servers must collude to break privacy).
The next step involves the nodes (the servers A, B, and C) performing the computation on the encryptions (i.e., secret-shares) received in the input step.
When the nodes finish the computation, they will hold a secret-sharing of the output. Each node’s share is returned to the users, so they can recover the actual output.
As might be inferred from the figures above, MPC works particularly well if the computation nodes are well-connected. Indeed, what makes MPC expensive to run is all the data that the nodes have to send between each other.
MPC have been actively studied in academia since the early 1980s and there are a lot of good resources available to learn more about it:
Fully homomorphic encryption (FHE) solves a very old problem: Can I have my data encrypted and compute on it too? FHE is a tool that allows us to not only store data encrypted on a server, but which allows the server to compute on it as well, without having to decrypt it at any point.
A user encrypts their private data and uploads it to a server. However, unlike a traditional E2EE (End-to-End-Encrypted) scenario, the server can actually perform a computation on the user’s private data — directly on ciphertext. The result can then be decrypted by the user using their private key.
FHE, unlike MPC, relies on clever cryptographic computation, rather than clever cryptographic protocols. On the one hand, this means FHE requires less data to be sent between the server and client compared to MPC. On the other hand, FHE requires a lot of computation to be done by the server.
Practically speaking, FHE is slower than MPC (unless we have an incredibly slow network, or incredibly powerful computers).
Practical FHE is a relatively new technology that only came about in 2009. However, since then it has received quite a bit of interest, especially from “bigger” players like Microsoft or IBM.
Partisia Blockchain supports FHE solutions.
While both MPC and FHE allow us to compute anything, zero-knowledge proof (ZKP) systems allow us to compute proofs. In short, ZKP allows us to compute functions where the output is either “true” or “false”.
ZKPs are incredibly popular in the blockchain space, mainly for their role in “rollups”. The particular type of ZKPs used for rollups are ZK-SNARKs, which are succinct proofs. In a nutshell, a succinct proof is a proof whose size is some fixed (small) constant, and where verification is fast. This makes smart particularly useful for blockchains since the proof and verification are both onchain.
That said, ZK rollups don’t actually use the zero-knowledge property — they only use the soundness and succinctness properties of the proof scheme.
Soundness simply means that it is very difficult to construct a proof that appears valid, but in actuality is not.
ZKPs, like FHE, takes place between a single user and a verifier. The user has a secret and they wish to convince the verifier about some fact concerning this secret, without revealing the secret. ZKPs don’t designate a particular verifier, so anyone can usually check that a proof is correct.
The final private computation technology I will talk about here is trusted execution environments. A trusted execution environment, or TEE, is basically just a piece of hardware that is trusted to do the right thing. If we trust this particular type of hardware, then private computing is clearly doable.
TEEs, being hardware, are tightly connected to some hardware vendor. Often when TEEs are mentioned, what is really meant is something like Intel’s SGX or ARM TrustZone. SGX is the TEE used by Secret Network, for example.
The security model of TEEs is fairly different compared to the other technologies I have written about so far, in that it is a lot more opaque. Vulnerabilities have been demonstrated in different iterations of different TEE products, especially SGX.
Differential privacy is radically different from the previous technologies. (In this discussion I will exclude ZKPs since it does not allow general computations.)
While MPC, TEE and FHE all provide means of computing something on private data, they do not really care about what that something is.
For example, it is possible (albeit pointless) to compute the identity function using both MPC, TEE and FHE.
This is because MPC, TEE and FHE allow us to compute anything. In particular, they allow us to perform computations that are not really private.
At this point, we may ask: Well, why would we perform such a silly computation on private data? For some computations, it might be easy to see that it is not private (in the sense that the original input can easily be inferred from the output). However, there are many computations that are seemingly private, but which can also leak the input if we are not careful. For example, it has been shown that it is possible to extract machine learning models, simply by querying a prediction API. In another example it was shown that it is possible to extract the data that a model was trained on.
These issues all arise because there are no restrictions on the computation that is performed. Differential privacy tries to fix this.
Differential privacy is used to provide a fairly intuitive guarantee. Suppose we are given two databases A and B. The only difference between these two databases, is that a particular entry R exists in A but not in B. Differential privacy now states that, no matter which type of query we make on the database, we will not be able to guess whether we are interacting with A or B.
Naturally, this means that some queries cannot be allowed. For example, it is not possible to obtain differential privacy if one can simply ask “Is record R in the database?”. Generally, differential privacy is obtained by adding noise, or synthetic data, to the database as well as restricting the type of queries that are allowed.
What makes differential privacy different from MPC, TEE and FHE, is that differential privacy makes guarantees about the output of a computation, whereas MPC, TEE and FHE makes guarantees about the process of arriving at that output. In summary:
This also means that differential privacy is not in direct “competition” with MPC, TEE or FHE, but rather complements them.
While each technology has its specific advantages and use cases, it is our feeling that Partisia Blockchain’s MPC, backed by 35 years of research and practical implementation does seem to provide the most overall coverage of all possible scenarios with very little drawback.
Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube
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 (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.
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.
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.
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.
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.
Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube
Self-sovereign identity (SSI) is an ever increasingly important concept to enable users control over their own data and let them share it with whom they want. Today, data rests in centralized databases that belong to big enterprises with little transparency into how the data is actually being used and for what purpose.
SSI turns this around and data starts with the users, actually resting at users own device at first. Then it is up to the users to choose with whom and what data they share. Additionally, privacy-preserving features, such as selective disclosure and predicates enhance the user to share data without sharing it all or just prove simple facts about the data.
There are many great tools and infrastructures that can handle SSI, and Partisia Blockchain’s MPC technology adds a new component to the stack that enables new business models, enhances privacy for the data-driven economy, and will take your project ahead of the competition. So read on if you are a builder of the US$27 billion global digital identity market that is expected to expand at a CAGR of 17.2% from 2023 to 2030.
First things first, digital identity usually revolves around three actors: issuer, holder, and verifier.
The issuer issues verifiable credentials to the holder, and the holder can then present the credentials to a verifier who can verify the content by digital signatures and Decentralized Identifiers (DIDs) that may be on a blockchain. For most digital identity use cases, DIDs and associated DID documents are the only elements that get on the blockchain. We do not take a deep dive on this in this article.
DIDs and verifiable credentials are some of the essential components that make up digital identity, especially digital identity that works with decentralized networks. DIDs are a type of address that is generated to manage digital signatures, and verifiable credentials are credentials created and issued by any issuer based on their DIDs.
To enable real SSI, the users will have to store all data themselves at first, often in digital identity wallets, and only then will the user be in full control. The data itself can be data inputs from users such as personal Identifiable Information (PII) or digital verifiable credentials issued by a third-party, e.g. KYC provider issues KYC claim as digital verifiable credential. Credentials are often issued and exchanged by an agency that establishes secure peer wise connections.
Multiparty computation (MPC) is a groundbreaking technology that allows multiple data inputs to remain private while still being computed on and only sharing the outputs. The computing itself is carried out by specially selected MPC validator nodes who each compute on secret shares of the data and privacy is guaranteed by cryptography.
Compared to ZK proofs, such as zk-SNARKs, MPC is a game changer that allows computing on any function. This takes digital identity to the next level because it is now not only possible to share data with privacy features, but also carry out decentralized computation on private data and write business logic into private and public smart contracts to orchestrate the process and rules.
As we learned before, ZK proofs are good for simple presentations about specific data, e.g. a verifiable credential issued by an employer can be used to prove to the bank that you earn more than US$80,000 a year to qualify for a loan without revealing the exact amount you earn.
Now imagine that we need to compute statistics on multiple inputs from multiple users and compare a single person’s salary to the average, all while preserving privacy. ZK proofs cannot handle general computations on multiple inputs and comparison is limited to two users presenting against each other, so another system would have to support it. This is where Partisia Blockchain’s MPC comes to save the day! MPC on Partisia Blockchain can handle multiple inputs and preserve the privacy while carrying out efficient general computation.
Even though all smart contracts and data can be private, it is often worth considering only to push the most sensitive data and operations into private computation because it is generally more expensive than public computation. This goes for all ZK technology. For instance, if you want to calculate the average salary of employees, you might consider just the salary as private inputs plus pseudonymized identity, and then do statistical calculations in the public space.
When we look at DID/SSI solutions, the business requirements of the implementation usually go past simple verification of ID. DID/SSI proof is just the first step. The real challenge is what other data do you need after the verification. Perhaps it is to verify that this person has proper credentials for accessing a system. Or another popular use case for DID is to verify a user has enough assets to pay for something without revealing their total asset holding. Another app that is looking to build on our system is trying to create a persona on-chain, which advertisers can target, without revealing personal information about the user themselves.
In all these use cases, a simple proof system becomes too expensive and slow due to the fact that each individual parameter must require a proof. When you have 10 users, maybe this is possible. But what happens when you need to scale to 1000 or 10,000 users? And proofs are not computations. It is unable to compute the various different private data for analysis.
This is where MPC can extend the functionality of DID/SSI to create multi-functional applications. Through MPC you can both prove and compute multiple parameters in a single computation and include all the additional business requirements while keeping the data private.
During the pandemic, many attempts were made to create a Covid-19 passport so citizens could prove they were either vaccinated or tested negative while preserving privacy. Zk proofs are good for this, but limited to only presenting yes/no results to a verifier without extensive physical verification such as ID cards, which would compromise SSI principles.
In collaboration with HES-SO Valais-Wallis, Partisia Blockchain developed a solution where identification is reduced to matching an individual’s face with an image of the person’s face powered by MPC in order to increase security and privacy. The Partisia Blockchain ensures trustworthy information is broadcasted to the verifier and MPC ensures that the private information about the citizen is used only for matching and kept hidden for the verifier.
Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube