At Ola, we strongly agree with a16z's statement in their article " " about web3: Achieving Crypto Privacy and Regulatory Compliance “The development and regulation of – an evolution of the internet powered by crypto – must achieve two goals that are often in tension. Goal 1: . Goal 2: Reduce the risk of illicit finance in the interest of national security.” web3 Preserve consumer privacy, despite the default transparent nature of blockchains This vision aligns with what Ola described in the article " ". Additionally, the emphasis on high throughput is a feature that Ola is currently working hard to implement. Ola – Shape Your Own Web3 Journey 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, " ," describes the differences between these three solutions. Sin7y Tech Review (35): Hybrid Rollup – The Next-Generation Infrastructure - HackMD In this piece, we'll focus more on explaining Ola's design in terms of being . As described in the a16z article, privacy must encompass two attributes simultaneously: compliance-friendly Achieve native privacy protection to safeguard user information. 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 " ," the pivotal question is: " " Privacy-Protecting Regulatory Solutions Using Zero-Knowledge Proofs: Full Paper - a16z crypto 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: In the article " ", 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: Sin7y Tech Review (33): Principles of private transactions and regulatory compliance issues - HackMD : This is achieved through a one-time signature, as detailed in section 4.1.7.1 of the . Hiding the transaction initiator, or the sender zcash-sapling protocol : This is divided into two scenarios: Hiding the transaction recipient, or the receiver ⅰ. Hiding from third parties is achieved by encrypting the transaction information using the receiver's public address. See section 4.19.1 of the . 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 . The transaction content itself doesn't contain any information about the receiver. zcash-sapling protocol zcash-sapling protocol ⅱ. Hiding from the same sender is accomplished using a one-time public address. : The approach involves the use of zero-knowledge proofs and shared secret schemes. Refer to sections 4.17 and 4.19 of the . For the concealment of transaction information zcash-sapling protocol : 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: For the implementation of non-traceable ⅰ. 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 above privacy design, users can benefit from the following privacy protection features: Each transaction remains invisible to external parties. The connections between transactions are untraceable. 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 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? 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. 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. 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 Continue to conceal the contents of each transaction, ensuring that user privacy remains intact. . 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: 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. 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: 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: 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 , people with an Aadhaar card can generate a zkDID. Anon Aadhaar 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: : 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. Platform-level Implementation This approach enables consistent identity protection and privacy control across the entire platform. : 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. Application-level Implementation 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: : Based on the CM information within a transaction, any third party can trace the flow path of the CM, as illustrated in Figure 2. Traceability : The privacy of each transaction remains intact; information about the sender, receiver, and other aspects remains confidential. Privacy : By maintaining fewer trees, the overhead of the zk-proof system is reduced. Efficiency : Supports updates to the view key, ensuring transaction privacy isn't compromised if the view key is exposed. Updatable View Key : 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: Compliant-friendly 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 " " and " " to incorporate blacklist mechanisms and other early-stage constraints, refining the design of the entire programmable privacy system. Achieving Crypto Privacy and Regulatory Compliance - a16z crypto Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium Also published here

Introducing Ola's Pre-Alpha Testnet: Empowering Data Ownership and ZK Smart Contract Innovation  

Hybrid Rollup — What do Aztec, Miden, & Ola Hold for the Future of Next-Generation Infrastructure?

Nominated for 2022 - HackerNoon Contributor of the Year - Optimization

Nominated for 2022 - HackerNoon Contributor of the Year - Algorithms

Programmable Privacy: How It Could Be More Compliance-Friendly to the Web3 World

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Study on Parallel Execution: Everything You Need to Know

How could Cryptos change the world?

Practice Makes Perfect…and Money, How These 3 Prediction Markets Can Prep You In The Crypto World

The Most Common Mistakes to Avoid in the Crypto World

The Oracle of Truth: Where Do Blockchain Betting Projects get Their Event's Results?

The Taxman Cometh for the Crypto World

A Study on Parallel Execution: Everything You Need to Know

How could Cryptos change the world?

Practice Makes Perfect…and Money, How These 3 Prediction Markets Can Prep You In The Crypto World

The Most Common Mistakes to Avoid in the Crypto World

The Oracle of Truth: Where Do Blockchain Betting Projects get Their Event's Results?

The Taxman Cometh for the Crypto World

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps