Programmable Privacy Could Be More Compliance-Friendly

Towards the Authentic Web3 World

At Ola, we strongly agree with a16z’s statement in their article “Achieving Crypto Privacy and Regulatory Compliance” about web3:

The development and regulation of web3 — an evolution of the internet powered by crypto — must achieve two goals that are often in tension.

Goal 1: Preserve consumer privacy, despite the default transparent nature of blockchains.

Goal 2: Reduce the risk of illicit finance in the interest of national security.

This vision aligns with what Ola described in the article “Ola — Shape Your Own Web3 Journey”. Additionally, the emphasis on high-throughput is a feature that Ola is currently working hard to implement.

Whether dealing with private or non-private scenarios, programmability is an extremely important attribute. In the realm of programmable privacy, besides Ola, both Aztec and Miden are working towards the same goal. Ola’s article, “Sin7y Tech Review (35): Hybrid Rollup — The Next-Generation Infrastructure — HackMD,” describes the differences between these three solutions.

In this piece, we’ll focus more on explaining Ola’s design in terms of being compliance-friendly. As described in the a16z article, privacy must encompass two attributes simultaneously:

1. Achieve native privacy protection to safeguard user information.
2. Ensure regulatory compliance to track illicit activities.

The first point is relatively straightforward to accomplish. Regarding the second, every project has its own considerations and trade-offs. We will primarily delve into Ola’s thought process and design regarding regulatory compliance.

Approaching this from the perspective of solving real-world issues, let’s first examine the challenges various privacy projects face in terms of regulatory compliance.

As described in the chapter “Involuntary Selective De-anonymization” from the article “Privacy-Protecting Regulatory Solutions Using Zero-Knowledge Proofs: Full Paper — a16z crypto,” the pivotal question is:

“Who maintains the private key to unlock traceability?”

Why do we need a private key to unlock traceability?

The necessity for a private key to achieve traceability is related to current privacy designs. Since almost all privacy solutions currently based on zk (zero-knowledge) technology have taken cues from Zcash, we’ll directly discuss Zcash’s design, as depicted below:

Fig1. Principles of untraceability and unlock traceability

In the article “Sin7y Tech Review (33): Principles of private transactions and regulatory compliance issues — HackMD”, you can find the design principles behind private transactions. We’ll briefly explain how privacy is maintained under this design and how it addresses regulatory concerns:

a. Hiding the transaction initiator, or the sender: This is achieved through a one-time signature, as detailed in section 4.1.7.1 of the zcash-sapling protocol.

b. Hiding the transaction recipient, or the receiver: This is divided into two scenarios:
ⅰ. Hiding from third parties is achieved by encrypting the transaction information using the receiver’s public address. See section 4.19.1 of the zcash-sapling protocol. The receiver then sifts through the transactions using a private key (known as the incoming view key) to decrypt and filter out transactions sent to them, as described in section 4.19.2 of the zcash-sapling protocol. The transaction content itself doesn’t contain any information about the receiver.

ⅱ. Hiding from the same sender is accomplished using a one-time public address.

c. For the concealment of transaction information: The approach involves the use of zero-knowledge proofs and shared secret schemes. Refer to sections 4.17 and 4.19 of the zcash-sapling protocol.

d. For the implementation of non-traceable: The approach is based on the design of the commitment (from here on referred to as “CM”) tree and the nullifier (from here on referred to as “NF”) tree. This design serves the following purposes:
ⅰ. Every UTXO (Unspent Transaction Output) corresponds to one CM and one NF, but there’s no direct linkage between the two.

ⅱ. Both the CM tree and the NF tree are append-only trees.

ⅲ. The CM tree is used to prove the validity of the UTXO, while the NF tree prevents double-spending of the UTXO.

Based on the aforementioned privacy design, users can benefit from the following privacy protection attributes:

1. Every transaction detail is invisible to external parties.
2. Relationships between transactions satisfy the non-traceable characteristic.

It seems like a flawless privacy protection design for users. However, when grounded in reality, not every user operates with genuine and lawful intentions. There must be mechanisms in place to disclose parts or all of the private transaction details to achieve traceability when necessary. This assists regulatory bodies in taking action against malicious users. Otherwise, this form of privacy could become a tool for malicious actors to harm ordinary users.

Does the aforementioned privacy design allow regulatory authorities to conveniently trace transactions and enforce regulations? The answer is no. As illustrated in the provided diagram (which is referenced but not shown), the current privacy design requires a view key to unlock transaction traceability. However, this view key is held by the user, making it inaccessible to regulators directly. This ties into the issues described in the sections 13/14 titled “Voluntary Selective De-anonymization” and “Unvoluntary Selective De-anonymization” of the article “Privacy-Protecting Regulatory Solutions Using Zero-Knowledge Proofs: Full Paper — a16z crypto.”

Let’s delve deeper. Why is the view key so sensitive that users are hesitant to provide it to regulators?

1. Firstly, it’s crucial to clarify that the view key isn’t the private key used for transaction signatures; it can’t be used to directly sign transactions, and thus, it cannot be used to steal user assets.
2. Once the view key is exposed, regulators can see all the private transactions initiated by a user in plaintext. Users must trust regulators that: (1) the view key won’t be leaked; and (2) transaction details won’t be disclosed.
3. Users with vicious purposes will, of course, be unwilling to provide their view key, leaving regulators powerless.

Based on the above analysis, the ideal privacy solution should:

1. Continue to conceal the contents of each transaction, ensuring that user privacy remains intact.
2. Achieve permissionless traceability between transactions, meaning that traceability can be realized without the mandatory provision of extra information.

This is the vision that Ola is striving to achieve: programmable privacy that natively incorporates traceability!

How does Ola introduce native traceability to programmable privacy?

Addressing the regulatory challenges encountered by the above privacy solutions, Ola has boldly ventured into making an attempt and has outlined a specific design. The core technological points can be summarized as:

1. The nullifier tree is no longer introduced to achieve the untraceability of transactions. In Ola’s design, transactions are traceable, but this is done under encryption, without compromising the privacy attributes of the transactions themselves.
2. The remaining commitment tree is transitioned from the original append-only mode to an updatable one by introducing additional prove statements to prevent double-spending attacks on the same commitment. This is illustrated in Figure 2:
   

Fig2. Example of traceability

3. Incorporate an updatable view key mechanism. This means that when a view key is exposed, users can update the view key to ensure that subsequent private transactions created after the key update cannot be decrypted. As illustrated in Figure 3:
   

Fig3. The key system of Ola

zkDID/zkKYC Effectively Balance Privacy and Regulation

Zero-Knowledge Decentralized Identifiers (zkDIDs) play a crucial role in privacy platforms. They have the capability to transform a user’s legal identity (Legal ID) into a zkDID. For example, in the PSE project Anon Aadhaar, people with an Aadhaar card can generate a zkDID. To others, a zkDID is anonymous and does not reveal the user’s real identity information. This dual characteristic provides a powerful tool for privacy protection.

Regarding the implementation levels of zkDID, it can occur at various levels, depending on the platform’s design and requirements:

1. Platform-level Implementation: If a platform needs to manage and verify the identity of all users to ensure security and compliance, implementing zkDID at the platform level might be the more appropriate choice. In this way, the platform can directly integrate zkDID as part of its identity management system, allowing for user identity verification and authorization. This approach enables consistent identity protection and privacy control across the entire platform.
2. Application-level Implementation: If a platform prioritizes user control and flexibility, then implementing zkDID in an upper-layer application on the platform might be preferable. This method allows users to choose whether to use zkDID and manage their identity as needed. Users can decide when to use zkDID to balance privacy and convenience. This approach may be more suitable for users who want to have more active control over their identity. (non-native)

Given the design above, Ola’s privacy solution boasts the following advantages:

1. Traceability: Based on the CM information within a transaction, any third party can trace the flow path of the CM, as illustrated in Figure 2.
2. Privacy: The privacy of each transaction remains intact; information about the sender, receiver, and other aspects remains confidential.
3. Efficiency: By maintaining fewer trees, the overhead of the zk proof system is reduced.
4. Updatable View Key: Supports updates to the view key, ensuring transaction privacy isn’t compromised if the view key is exposed.
5. Compliance-friendly: Without the need for non-enforceable information, regulators can trace the target’s lineage, for instance, within which CM collections. While the regulators might temporarily lack knowledge about the owners of these CMs, they have two options:
   a. Wait for the CM to be consumed and transferred to a public address, which is feasible since, in Ola’s design, all private states must transition to public states before exiting the ecosystem.
   b. Obtain view key information for decryption, a traditional method used for traceability in privacy-protecting solutions, as seen in systems like Zcash, Aleo, Aztec, Miden, and others.

Beyond these technical advantages, Ola can still integrate with papers like “Achieving Crypto Privacy and Regulatory Compliance — a16z crypto” and “Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium” to incorporate blacklist mechanisms and other early-stage constraints, refining the design of the entire programmable privacy system.