This report includes key analysis of research, guides and resources and project updates in zero knowledge proof technology.
(1)《Lattice-Based Zero-Knowledge Proofs and Applications: Shorter, Simpler, and More General》
In this paper, the authors propose an improved zero-knowledge proof method Lattice-Based zero-knowledge proofs. This new proof system can be plugged into constructions of various lattice-based privacy primitives in a black-box manner. As example, we instantiate a verifiable encryption scheme and a group signature scheme which are more than twice as compact as the previously best solutions.
(2)《zkKYC in DeFi: An approach for implementing the zkKYC solution concept in Decentralized Finance》
This paper presents a solution concept for where a DeFi protocol is required or finds it desirable to implement KYC policies. zkKYC in DeFi requires no personal identifiable information to be shared with DeFi protocols for the purpose of regulatory transparency. The presented approach extends the zkKYC solution concept (which leverages self-sovereign identity and zero-knowledge proofs) with the introduction of KYC Issuers and Decentralized Oracle Networks (DONs) as key solution components. KYC Issuers verify the identity of an individual, but have no knowledge about their digital asset wallets or DeFi activity. DeFi protocols interact with digital asset wallets, but have no knowledge about the identity of the individual controlling them. If and when deemed necessary, only a designated governance entity is able to reveal the identity of an individual that is under strong suspicion of being a bad actor in a DeFi protocol. The presented solution architecture demonstrates flexibility in being agnostic to blockchain platforms and SSI¹ implementations and extensibility in being forward compatible with on-chain identity and reputation systems. Similar to the original zkKYC solution concept, zkKYC in DeFi breaks the regulatory transparency vs. user privacy trade-off.
zkKYC extends the self-sovereign identity (SSI) model, leveraging verifiable credentials (VC) and decentralized identifiers (DID). The key improvement is that individuals (i.e. Holders) no longer have to provide personal identifiable information to each business (i.e. Verifier) that they create a relationship with. This is achieved using a circular ecosystem design with clear role definitions and modern technologies, including zero-knowledge proofs.
Interactions and Concepts Trustworthy Issuers issue verifiable credentials to Holders. Verifiable credentials provide a mechanism to express traditional credentials digitally, cryptographically secure, privacy respecting and machine-verifiable. The Issuer cryptographically signs verifiable credentials with the secret key associated with their decentralized identifier (DIDI ). Using the publicly available public key associated with the Issuer’s DID, anyone can easily verify the integrity and authenticity of a verifiable credential that Issuer issued. Where a Holder is an individual, they would typically generate a unique DID for each distinct relationship they have. This helps to enhance their privacy, as only they then know and control the link between all these different DIDs. In the diagram above, you can see that Holder has DIDHV for its relationship with Issuer and DIDHI for its relationship with Verifier. In zkKYC, Holders do not present to Verifiers the actual verifiable credentials that were issued to them. This could share personal identifiable information. Rather, Holders use the verifiable credentials in their digital identity wallet to generate and present the following three objects to Verifier:
- Eligibility Proofs: zero-knowledge proof that the Holder meets the (business) criteria set out by the Verifier to be able to provide access to the requested service. These proofs leverage the information in verifiable credentials and their signatures, but without disclosing the actual information itself. Examples include proof that the Holder is above a minimum age, a domestic resident, not on a sanctions list, not a politically exposed person etc.
- zkKYC token: an encrypted data object that contains decentralized identifiers (DIDs) to enable the Holder’s identity to be revealed to parties in Government role only. Specifically, it is a data object encrypted with Government’s public key. The data object contains DIDI , DIDHI , DIDV and DIDHV . DIDV and DIDHV make the token unique and specific to Verifier so they are of no value to others.
- Validity Proofs: zero-knowledge proof that the presented zkKYC token contains the correct information, without disclosing what that information is, and is encrypted using the provided Government public key.Given that Verifier cannot read the content of the zkKYC token, they need proof that the correct information is included, to prevent bad actors from inserting false information.
2) Architectural Overview
After introducing the concept of zkKYC, let’s take a look at the architecture overview of zkKYC in DeFi. The diagram below provides an architectural overview for implementing the zkKYC solution concept in DeFi. It overlays the zkKYC ecosystem model with the identified solution components that are particular to the DeFi context and their interactions.These components are described below.
SSI Wallet Holders store the verifiable credential issued by a KYC Issuer in their SSI wallet. It reflects the outcome of their KYC process and serves as a critical element of the zkKYC solution concept. Based on this verifiable credential, the SSI wallet can generate the eligibility proofs requested by the Verifier, as well as the zkKYC token and associated validity proof.
Digital Asset Wallet The private keys associated with the Holder’s digital assets are stored in their digital asset wallet. These private keys enable the Holder to control and transfer digital assets on-chain or prove they do control a particular wallet address associated with the public key. The Digital Asset Wallet may also store the private keys of any micro-credentials (as NFTs) that support the Holder’s on-chain reputation.
User Interface The user interface of the Verifier is a rather abstract component. It represents the interface for a Holder and their wallets to interact with the Verifier. Functionally, this component represents a user interface for zkKYC interactions and a user interface for DeFi protocol interactions:
- zkKYC: a website or app for a Holder’s SSI and digital asset wallets to interact with the DON for the purpose of zkKYC. Alternatively, this interface could also be implemented as APIs in developer SDKs or into the wallets directly.
- DeFi Protocol: a website or app for a Holder’s digital asset wallet to interact with the DeFi protocol smart contracts on the blockchain. It can be implemented to access a DeFi protocol specifically (e.g. https://app.uniswap.org) or as an aggregator service (e.g. https://app.1inch.io). It can also be implemented within a development platform (e.g. Remix2) or block explorer (e.g. Etherscan3) to interact directly with the smart contracts on-chain. Last, this interface could also be implemented as a smart contract developed and deployed by the Holder, which interacts on-chain with the DeFi protocol smart contracts.
Decentralized Oracle Network (DON) The key responsibility of the DON is to provide a reliable and trusted communication bridge between the Holder and the DeFi protocol for the purpose of zkKYC. It serves as a Verifier proxy for the DeFi protocol and allows for trustless KYC verification. Based on a DeFi protocol specific configuration profile and the use case at hand, the DON interacts with the Holder’s SSI wallet and issues a request for authentication or the presentation of zkKYC specific data elements including eligibility proofs, a zkKYC token encrypted with the particular public key of Government and the associated validity proof. Each node of the oracle network will receive and verify zkKYC data from the Holder, come to consensus with the other nodes on the verification outcome and elect one oracle node to submit the outcome to the oracle smart contract on-chain. The elected oracle node is also responsible to store the relevant proofs and zkKYC token on the decentralized storage (see below). Given that the oracle network represents the DeFi protocol towards the Holder for the purpose of zkKYC, its nodes must receive delegation authority by the DeFi protocol to control its DIDV. This is required to establish the underlying SSI interactions with the Holder, which the oracle network is able to do given it runs off-chain.
The DON also requests proof from the Holder that they control a particular digital asset wallet. To do this, it asks the Holder to generate a digital signature using the wallet’s private key that they control. Then, it cryptographically verifies whether that signature matches with the digital asset wallet’s public key. The oracle nodes can perform additional verifications of the digital asset wallet such as verifying it against a black list or watch list, published by trusted authorities.
Decentralized Storage Decentralized storage is used by the DON to store DeFi protocol specific configuration files as well as zkKYC verification proofs and zkKYC tokens. These Holder and DeFi protocol specific data sets must be strongly secured and guaranteed to be only accessible by authorised parties and under strict conditions. The implementation options for this component, along with possible technologies and design trade-offs, are out of scope of this paper. Options can range from a single distributed platform with advanced access rights management to DON and DeFi protocol specific platforms and technologies with standardised interfaces in order to maintain more control and sovereignty.
Oracle Smart Contracts The elected oracle node of the DON submits the outcome of the zkKYC verification to the oracle smart contracts on-chain. These smart contracts connect the DON with the DeFi protocol. The oracle smart contracts keep track via a whitelist for each DeFi protocol which of their users (i.e. DIDHV ) have successfully passed zkKYC verification. Remember that DIDHV is a unique identifier of the Holder, specific towards the DeFi protocol (i.e. Verifier). It is not re-used across Verifiers. For most blockchains, it will be linked to the digital asset wallet address of the Holder. For this reason, using different digital asset wallets across DeFi protocols will further improve user privacy. DeFi Protocol Smart Contracts The DeFi protocol smart contracts constitute the DeFi protocol as such and are responsible for processing DeFi transactions submitted by the Holder.
DeFi Protocol Governance Each DeFi protocol that implements KYC processes is assumed to have some sort of governance entity. This can be decentralized in the form of a Decentralized Autonomous Organization (DAO) or centralized via a traditional legal entity. The governance entity is responsible for interacting with Government and retrieving the necessary data (e.g. DIDHV , zkKYC token, transaction data) from the blockchain or decentralized storage.
(3)《Multi-Party Computation in the GDPR》
This paper aims for a better understanding of the role of MPC in the GDPR. Although MPC is relatively mature, little research was dedicated to its GDPR compliance. First, we try to give an understanding of MPC for legal scholars and policymakers. Then, we examine the GDPR relevant provisions regarding MPC with a technical audience in mind. Finally, we devise a test that can assess the impact of a given MPC solution with regard to the GDPR.
The test consists of several questions, which a controller can answer without the help of a technical or legal expert. Going through the questions will classify the MPC solution as (1) a means of avoiding the GDPR, (2) Data Protection by Design, or (3) having no legal benefits. Two concrete case studies should provide a blueprint on how to apply the test. We hope that this work also contributes to an interdisciplinary discussion of MPC certification and standardization.
2. Guides and Resources
This year, Ethereum will switch from PoW to PoS so that the blockchain mining market will shrink significantly. Although storage mining has emerged in recent years, including Filecoin, Chia, and Arweave, it is still unable to meet the market vacancy caused by the exit of Ethereum. On the other hand, ZKP has some early applications in blockchain mining. There is a marketplace in Mina for ZKP workers to submit their generated proofs to earn tokens. In Filecoin, miners need to generate ZKP for every data sector stored off-chain, thus gaining storage power.
We can see that traditional hash mining is surrounded by controversies about energy wasting, meaningless computation. Therefore, the blockchain area is trying to find a meaningful mining method. The properties of ZKP (proving arbitrary statement, complex proving but simple verification) provide more possibilities to the blockchain mining market.
We are focusing on some ZKP mining projects this year：
- L2 transactions: zk-Rollup projects like zkSync, StarkWare
- L1 transactions: Mina
- Off-chain data: Filecoin
（2）Battleship on RISC ZERO — Battleship with Rust and RISC Zero’s ZKVM
In RISC Zero’s Battleship, we apply the power of zero knowledge proofs (ZKPs) using the RISC Zero Zero-Knowledge Virtual Machine (ZKVM) to build a trustless game of Battleship in Rust. The players each maintain their private game state, yet every step of the game is cryptographically checked to prevent cheating. The patterns in this code may be applied to build new secure, decentralized applications in finance, governance, information security, etc.
(3) ZK Machine Learning — A tutorial and demo
In this tutorial post, together with the associated repo and demo webapp, we explore how zero knowledge proofs can help lift these barriers by performing computations off-chain and providing a proof that this computation was correctly executed, while shielding private data. The proof can then be verified on-chain for a much smaller computational cost, enabling us to implement on-chain, private machine learning.
For this demo, we focused on the implementation of a simple computer vision deep learning convolutional neural network for handwritten digit recognition (MNIST).
To check out the demo, please follow the instructions in this github repo, or play with the webapp demo at: https://zkmnist.netlify.app/
The webapp allows the user to “draw” a digit or to select an image of a digit from examples taken from the MNIST dataset. This handwritten digit can then be classified by the neural network, outputting a predicted digit as well as a zero-knowledge proof that you have an inpu image that is classified by the ML model to yield a specific digit. Finally, this proof can be verified on-chain via a smart contract.
3. Project Updates
- Countdown to Aztec Connect: The countdown to Aztec Connect’s mainnet launch has officially begun. It is planned for June 9th, 2022. Ethereum users are about to access the full spectrum of Ethereum DeFi applications with Aztec’s ironclad privacy guarantees, starting with our launch integrations: liquid stake ETH on Lido and get fixed yields on Element with full privacy protection.
- Aztec Network Raises Total Bug Bounty to $2 Million: The team released Aztec Connect’s codebase — and rewards totaling $2 million+ via the Aztec Bug Bounty. For full program details, eligibility requirements, and vulnerabilities included in the bug bounty.
- Aztec Network has crossed 200,000 transactions in production.
（2）Mezcal, A New Vision For Celo
We propose the following architecture for the future of Celo: Celo should become a Layer-2 ecosystem. Furthermore, we think it should be an EVM-compatible and Interoperable L2 that focuses on its core mission without worrying about L1 consensus. We all agree that one of the best networks to help achieve this vision is Celestia. Celestia is the first modular blockchain network, which has created what is known as the data-availability layer, providing the consensus mechanism and ordering of transactions while separating execution to Layer 2. Here, all Celo needs to do as an L2 is data-availability sampling from Celestia for the transactions relevant for Celo’s network. It doesn’t even need to download the entire Celestia block, just the transactions relevant to Celo.
This can help to solve many points highlighted in this article:
- Celo will no longer bear the burden of worry about validators and consensus issues, because it will use the Celestia network for this shared-security and data availability approach.
- Celestia as a modular blockchain provides Celo with a customizations, while still allowing Celo to focus on its mission.
- Celo can better focus on its mission as a network, including using the core contracts as-is, by using them as part of a new L2 Rollup network just for Celo. Core developers need not worry anymore about consensus, and can just focus on improving the EVM on Celo.
- Valora and other future wallets can still resort to using their federated attestation model on the L2 system.
- The attestation service system that both has no incentive system and is costing validators money can be phased out.
- When it comes to light clients — and given the Celestia architecture not requiring the download of entire blocks — the more light nodes that are being run in the network, the larger the block size can be, which provides major scalability improvements.
- Scalability improvements for Celo means transactions stay affordable.
（3）Loopring Quarterly Update (Q1/2022)
Major Milestones in Q1/2022：
- Over $4.6 billion in Trading Volume on Loopring L2
- Over 3 million NFTs minted on Loopring L2 following the official launch of open minting on Layer 2
- Over 65,000 L2 accounts and almost 30,000 Loopring Smart Wallets are now activated — with over 12,000 new wallets added in Q1 alone
More rapid social growth in Q1 (2022):
- 100,000 Lööpers now on Reddit
- Nearing 200,000 followers on Twitter
- A highly active Discord community with almost 30,000 members
¹SSI is the abbreviation of Self-Sovereign Identity.
（1）《Lattice-Based Zero-Knowledge Proofs and Applications:
Shorter, Simpler, and More General》
（2）《zkKYC in DeFi: An approach for implementing the zkKYC solution concept in Decentralized Finance》
（3）《Multi-Party Computation in the GDPR》