by Felix@StratifiedCapital

This report includes key analysis of research, guides and resources and project updates in zero knowledge proof technology.

Research

(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.

1)zkKYC

Overview

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:

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:

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

（1）Zero-Knowledge-Proof Mining

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：

（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

1）Introduction

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).

2）Demo

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

（1）Aztec

（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:

（3）Loopring Quarterly Update (Q1/2022)

Major Milestones in Q1/2022：

More rapid social growth in Q1 (2022):

¹SSI is the abbreviation of Self-Sovereign Identity.

References：

（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》

（4）https://medium.com/6block/zero-knowledge-proof-mining-9bc12fbbbd55

（5）https://www.risczero.com/docs/tutorial-examples/battleship_rust_tutorial

（6）https://0xparc.org/blog/zk-mnist

（7）https://medium.com/paradigm-fund/l2-report-vol-2-a497fab0aa83

（8）https://mirror.xyz/ocelotlabs.eth/9vtP5Tc-V_zRTMZ907DmmCWxUgIS4g-nKMrsckcZW7A

（9）https://medium.loopring.io/loopring-quarterly-update-q1-2022-cd4b6e229551