How does FHE address the compliance programmable privacy concerns raised by a16z?

2023-11-25 16:00

Read this article in 15 Minutes

FHE hosts the user's DID in encrypted form on-chain and lets compliant applications verify the attributes through a simple contract call.

Original Title: "Programmable Privacy and Onchain Compliance using Homomorphic Encryption"

Original Author: Rand Hindi

Translated by: Luccy, BlockBeats

Editor's Note:

On September 19th, a16z's crypto team proposed seven questions in the Nakamoto Challenge, including: atomic composability and limitations of shared sequencing, DePIN verification, JOLT + Lasso problem, compliance programmable privacy, best LVR mitigation, designing MEV transaction supply chain, and using blockchain for Deepfake protection.

For the issue of compliance programmable privacy, the open-source encryption tool Zama proposed a solution, fully homomorphic encryption (FHE) or fhEVM confidential smart contract protocol. fhEVM provides developers with a new way to build compliant programmable privacy applications on the chain by its ability to perform calculations on encrypted states.

Decentralized Identifiers (DIDs) as issuers of digital identities are stored in encrypted states, achieving a win-win situation of user identity privacy and programmable compliance. By defining token transfer rules between individuals through regulatory contracts, dynamic supervision of transfer conditions is achieved. This design enforces regulatory provisions at the smart contract level without hardcoding, and users can ensure the compliance of their applications with just a few lines of Solidity code.

Zama CEO Rand Hindi demonstrated in the article how to build a compliant ERC20 token using fhEVM and abstracting identities through on-chain DIDs. He pointed out that compared to other privacy solutions, all data and calculations of fhEVM occur on the chain, ensuring composability and data availability.

A few months ago, a16z's crypto team released the Nakamoto Challenge, which is a list of the most important problems to be solved in blockchain. The fourth problem, "Compliant Programmable Privacy," caught our attention because we have been actively thinking about this issue. Today, we propose the first solution using homomorphic encryption and the fhEVM confidential smart contract protocol.

fhEVM is a regular EVM that includes some precompiles, which can be used to perform calculations on encrypted states using our TFHE-rs homomorphic encryption library. From a developer's perspective, there is no involvement in cryptography, they only need to write Solidity code using the encrypted data types we provide (euint32, ebool, etc.). One major advantage of fhEVM over other privacy solutions is that all data and computations occur on-chain. This means that you can achieve the same composability and data availability as regular plaintext contracts.

This feature is crucial for building programmable privacy, as all access control logic can be defined within the contract itself. There is no hardcoded content in the protocol, and users do not need to perform any off-chain operations to ensure compliance. Applications can directly enforce compliance with just a few lines of Solidity code.

In this article, we will demonstrate how to use on-chain DIDs to build a compliant ERC20 token. The source code for this tutorial can be found in the examples folder of the fhEVM repository.

Through on-chain, confidential DID for identity abstraction

Decentralized Identifiers (DID) are unique digital identities issued by entities such as governments, registration agencies, companies, or users themselves. This DID can be bound to the cryptographic key that proves the user owns the DID, such as an EVM wallet. However, it can also store a range of attributes, such as the user's age, nationality, social security number, etc. These attributes can in turn be used to prove that you meet certain conditions (called "proofs"), such as being over 18 years old or not being a citizen of Narnia. They are issued by entities such as governments, registration agencies, companies, or users themselves.

Most DID implementations are actually implemented on the user side, utilizing zero-knowledge proofs to generate proofs. While this is feasible in many cases, things can get complicated when multiple users are involved in transactions, complex rules need to be applied to DIDs, or when everyone needs to follow a set of common rules. This is essentially similar to the trade-off between edge applications and cloud applications.

However, having a centralized DID registry can solve these problems, as you can simply request the registry to check if everyone is compliant. This will also make regulatory tracking easier, as you only need to implement it in one place. Blockchain will be the ideal infrastructure for this, as it will allow for composability between DIDs and applications that need to comply with regulations, as well as composability between regulations. This is essentially similar to the trade-off between edge applications and cloud applications.

Question: Everyone can see everyone's identity!

Luckily, we have a solution: homomorphic encryption, more specifically fhEVM! Due to its ability to be composable in an encrypted state, we can directly host users' DIDs in an encrypted form on the chain and allow compliant applications to verify attributes through simple contract calls. With the ability to manage identities through smart contracts, we call it "identity abstraction," similar to managing funds through smart contracts with account abstraction.

This tutorial is divided into three parts:

Identity abstraction is implemented through a registration contract, which is responsible for managing identities and proofs. Here, we assume that DIDs are official government identity cards. The registry itself is managed by a central authority (such as AFNIC), which can create registration authorities (such as KYC companies like Onfido, Jumio, etc.), and then registration authorities can create user DIDs. Then, users manage and update their DIDs through their registration authorities.

Supervision is defined in a contract, which encodes the token transfer rules between individuals based on the information contained in the user's DID. It essentially enforces supervision at the contract level rather than at the user level.

Compliant Confidential Transfers are implemented in a compliant ERC20 contract that uses regulatory contracts to enforce the compliance of token transfers without making any changes to the ERC20 API itself. In this example, we use a confidential ERC20 contract where balances and amounts are hidden, but it is equally effective for a regular, plaintext ERC20 token.

Identity Registration Contract

The identity registration contract is a registry of user DIDs issued by a registration agency, which includes a set of encrypted identifiers such as nationality, age, and social security number. These identifiers are stored in the form of encrypted 32-bit values (euint32).

This contract also handles permissions, including:

Allow contract owners (such as AFNIC) to add, delete, or update registration agencies.

Allow registration agencies to add, delete, or update user DIDs they have created.

Allow users to grant smart contracts permission to access their DID-specific attributes. It is important to note that users are responsible for not granting access to malicious contracts, just as they are responsible for not allowing malicious contracts to spend their tokens.

The first step is to implement the logic for creating and managing DID:

Sorry, I am unable to translate the given content as it does not contain any meaningful text or context. It only includes HTML tags and attributes. Please provide me with a text-based content that needs to be translated.The next step is to implement the logic for identification and access control.

Simply put, an identifier is a string (such as "date of birth") and an encrypted 32-bit value. It can only be created or updated by a registration authority. Users cannot create their own identifiers because we want them to be authenticated by the registration authority.

However, because the identifiers are encrypted, users need to grant the contract permission to access specific values. We will handle this through a simple access control mechanism, similar to the simple access control mechanism that allows contracts to spend your ERC20 tokens.

Now we can complete our identity registration contract by adding necessary getters, adding some conditions and error handling.

Sorry, I am unable to translate the given content as it does not contain any meaningful text or context. It only includes HTML tags and attributes. Please provide me with a meaningful text or context to translate.