By Zhuang Luo, Here is the Chinese Version .

0. Intro

Web3 has reshaped the value of data. However, the blockchains are isolated networks, and the smart contracts cannot pull in data from or push data out to any external system as built-in functionality. Thus, the oracle was born to help smart contracts obtain external data.

Submitting off-chain data on-chain is easy, the difficult part is how to produce trust through technology and mechanism design. The oracle problem revolves around the trust problem from data source to processing to feeding. An essential condition for a recognized oracle is decentralization, i.e. whether the single point of failure is allowed. A common solution for off-chain decentralization is to use multiple nodes to form a decentralized oracle network.

Now the main use case of the oracle is to provide price feeds for DeFi. According to DefiLlama, Chainlink is one of the largest oracle, with a Total Value Secured (TVS) of approximately $11B at the time of writing, accounting for 46% of the entire market.

With the development of the blockchain, the need for off-chain data is getting stronger, and simply price feeding is not enough. The vast majority of data necessary to build innovative Web3 applications (Credit Lending, Social, DID, KYC/AML, etc.) is not publicly accessible. Therefore, the next generation of oracle needs to support complex use cases involving sensitive data in a privacy-preserving manner.

DECO is Chainlink's solution in ther direction, using zero-knowledge proof to enable users to generate proof of off-chain private data, without revealing the data to the public or the oracle nodes. And there is no need for the API data provider to make any modifications. DECO is currently in the alpha stage and is testing proofs of concept with multiple partners.

1. Background

Here provides the necessary background about TLS and ZKP, the protocols on which DECO is built.

1.1 TLS

TLS (Transport Layer Security) is a powerful, widely deployed security protocol. HTTPS is a standard practice for websites, using TLS to encrypt normal HTTP requests and responses, making them safer and more secure. Websites need to install TLS certificates on their origin servers. The browsers flag all non-HTTPS websites as not secure.

The basic idea of TLS is to use the Public-key cryptography. The TLS certificate publicly shared by the website contains the public key, and the private key is installed on the origin server and "owned" by the website. The client first requests the public key from the server and encrypts the information. After the server receives the ciphertext, it decrypts it with its own private key.

Here is a problem. The public key encryption is too computationally intensive. To reduce the session time, each session client and server generate a symmetric encryption (faster) session key to encrypt information. And the server public key is only used to encrypt the session key.

Therefore, TLS protocol can be divided into two main layers:

1. Handshake. Two parties verify each other, establish the cryptographic algorithms they will use, and agree on session keys

2. Record. Both sides use the same session keys for encryption

But TLS has a serious limitation: it doesn’t allow a user to prove to third parties that a piece of data she has accessed authentically came from a particular website. Because the data transfer uses symmetric encryption, the user can sign data as well as the server.

To understand the problem, suppose Alice wants to prove to Bob that she’s over 18. Various websites can verify Alice's birth date. Alice could send a screenshot of her birth date from such a site, but ther is easily forged. And even if the screenshot could somehow be proven authentic, it would leak information— revealing her exact birth date, not just that she’s over 18.

The oracle needs to decentrally prove the provenance of private data, then feed it to smart contracts with privacy. Zero knowledge proofs may help.

1.2 ZKP

Zero Knowledge Proof (ZKP) has received wide attention in blockchain. Its main applications are ZK-Rollup (Validity Proof) and Privacy (True ZK). ZKP allows a Prover to prove to a Verifier that it has a solution (Witness) that can solve a certain computational problem (Statement) without revealing any additional information about that solution (Witness).

A typical ZK system works as follows:

• Frontend. Compiler, engineers first write out the statements to be verified with a DSL (Domain Specific Language), which is then compiled to a ZK friendly format such as arithmetic circuits.

• Backend. Proving system, takes generated parameters along with the secret witnesses as inputs to compute the proof, such as Marlin, Plonky2, Halo2, etc.

Constructing interactions on an open system like blockchain is complex. Therefore, the ZK system on blockchain applications is usually non-interactive, which anyone can verify at any time. Interactive can be converted to non-interactive using Fiat-Shamir-heuristic.

2. How DECO works

DECO extends the HTTPS/TLS protocol so that don’t require any server-side modifications or cooperation.

From a high level, DECO involves a three-way interaction between various entities—a Server (data provider), a Prover (user or app running DECO Prover), and a Verifier (Chainlink oracle running DECO Verifier).

• Provenance. The Prover queries the information from the Server, while the Verifier witnesses the interaction and receives a commitment on session data. At this point, the Verifier has proof that the data is authentic.

• Privacy. If no privacy is needed, the Prover supplies the secret key that can decrypt the data to the Verifier. If privacy is needed, Prover makes claims about it without revealing the data itself through the power of ZKP.

In detail, DECO protocol has three phases.

1. Three-party handshake. Prover, Verifier and Server establish session keys in a special format to achieve unforgeability.

2. Query execution. Prover queries the server for data using her private parameters $\theta_s$ (eg. Account Password, API key).

3. Proof generation. Prover proves that the query is well-formed and the response satisfies the desired condition.

2.1 Three-party handshake

Remark: The following description is based on the CBC-HMAC encryption algorithm. TLS 1.3 only retains the AEAD as the encryption algorithm, uses one key for both encryption and MAC. However, thanks to the key independence property of TLS 1.3, we can construct a 3P-HS protocol of similar complexity.

Prover $P$ cannot commit after accessing the MAC (Message Authentication Code, a digital signature confirming that the communication originated from the actual website) key, otherwise he can forge or tamper with the data.

The key idea of three-party handshake is $P$ and $V$ jointly act as a TLS client. They negotiate a shared session MAC key $k^{MAC}$ with $S$ in a secret-shared form. $P$ and $V$ receive $k^{MAC}_P$ and $k^{MAC}_V$ respectively, while $S$ receives $k^{MAC}=k^{MAC}_P+k^{MAC}_V$. As with the standard handshake, both $P$ and $S$ get the encryption key $k^{Enc}$.

If the Verifier is honest, the three-party handshake protocol ensures that the data is unforgeable.

2.2 Query execution

After the handshake, since session keys are secret-shared, $P$ and V need to interact and execute a 2PC protocol to construct TLS records encrypting $Q$ using private parameters $\theta_s$.

Then $P$ sends her query $Q$ to the $S$ as a standard TLS client. Note that the query is private to $P$ and should not be leaked to $V$.

After receiving a response $Rˆ$ (still ciphertexts) from $S$, $P$ sends it to $V$ as a commitment to the session data and receive $k^{MAC}_V$ from $V$. Then $P$ can verify the integrity of the response, and prove statements about it.

2.3 Proof generation

Then $P$ may prove to $V$ that the plaintext $R$ satisfies certain properties. $P$ can just reveal the encryption keys, but this sacrifices privacy. Alternatively, $P$ could prove any statement about $R$ using general zero-knowledge techniques.

Suppose the plaintext record is composed of chunks $R=(B_1,...,B_n)$, DECO introduces selective opening to generate ZKP.

• Revealing typical substring. Prove that the $i$th data chunk of $R$ is $B_i$ without revealing other data chunks.

• Concealing typical substring. Prove that $R_{-i}$ and $R$ are equivalent, except that $B_i$ is redacted.

For many applications, the verifier $V$ may need to verify that the revealed substring appears in the right context. To compensate for this, DECO utilizes a technique called Two-stage Parsing. $P$ parses $R$ locally and identifies the smallest substring of $R$ that can convince $V$, then send it to $V$.

Succinct non-interactive zero-knowledge (NIZK) proofs often have a high overhead on the prover side in computation and memory. Since the DECO Verifier is specified (Chainlink), more efficient interactive ZKP can be used, e.g., high scalability to very large statements, cheap computation, avoidance of trusted setup, and minimal use of memory.

3. Application

DECO can verify the validity of off-chain data while protecting privacy, thus unlocking many Web3 innovative application scenarios, from finance to identity to social networking.

• Social Recovery (Proof of Legal Identity). With DECO, using institutional websites that already have well-developed authentication systems (banks, social media, mobile carriers) as one of the guardians of wallet social recovery.

• Undercollateralized DeFi Lending (Proof of Funds). Teller used DECO to prove that the sum of a user’s off-chain bank accounts had a balance exceeding a dynamic threshold specified by the requested loan amount.

• Creator Economy (Proof of Interaction). Clique used DECO in a proof of concept to demonstrate a proof-of-fandom solution that users are a fan of a particular creator, earning the user various crypto/NFT rewards, reputation, or privileges.

• Decentralized Identity (Proof of Social Identity). PhotoChromic used DECO to prove the authentic relationship between a verified Web3 individual and their particular Twitter or Discord social handle without exposing the underlying PII.

• Sybil resistance for DAOs, SBT, KYC/AML, etc.

4. Other Players

Axiom built general ZK oracles on top of Uniswap v2 or v3 pools, using fully on-chain data, more similar to Indexing (eg. Hyper Oracle). Empiric Network put the oracle fully on-chain using zk. There is no off-chain infrastructure that data has to flow through.

Fully on-chain and privacy-preserving oracles are two sides of the same coin, complementing rather than competing.

5. Conclusion

Chainlink, as the absolute leader of the oracle market, through DECO, massive off-chain private data will be able to be used by smart contracts, which unlock many applications from finance to identity to social and so on.

The potential pitfalls are the proof generation speed and size of Prover, and the centralization problem of Verifier.

Now the Prover instance was deployed by Dapp while the Verifier was deployed by Chainlink Labs. In future iterations, it is planned that the Prover can be deployed locally by the end-user or in a Trusted-Execution Environment (TEE) while the Verifier can be deployed by a decentralized oracle network.

Reference

https://medium.com/amber-group/need-for-speed-zero-knowledge-1e29d4a82fcd

https://www.youtube.com/watch?v=eJqZQ2_VBzo&t=1345s

https://research.chain.link/deco.pdf

https://blog.chain.link/web3-identity-blockchains-credentials-oracles/