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 builtin functionality. Thus, the oracle was born to help smart contracts obtain external data.
Submitting offchain data onchain 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 offchain 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 offchain 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 privacypreserving manner.
DECO is Chainlink's solution in ther direction, using zeroknowledge proof to enable users to generate proof of offchain 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 nonHTTPS websites as not secure.
The basic idea of TLS is to use the Publickey 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:

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

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 ZKRollup (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 noninteractive, which anyone can verify at any time. Interactive can be converted to noninteractive using FiatShamirheuristic.
2. How DECO works
DECO extends the HTTPS/TLS protocol so that don’t require any serverside modifications or cooperation.
From a high level, DECO involves a threeway 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.

Threeparty handshake. Prover, Veriﬁer and Server establish session keys in a special format to achieve unforgeability.

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

Proof generation. Prover proves that the query is wellformed and the response satisfies the desired condition.
2.1 Threeparty handshake
Remark: The following description is based on the CBCHMAC 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 3PHS 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 threeparty handshake is $P$ and $V$ jointly act as a TLS client. They negotiate a shared session MAC key $k^{MAC}$ with $S$ in a secretshared 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 Veriﬁer is honest, the threeparty handshake protocol ensures that the data is unforgeable.
2.2 Query execution
After the handshake, since session keys are secretshared, $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 zeroknowledge 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 Twostage Parsing. $P$ parses $R$ locally and identifies the smallest substring of $R$ that can convince $V$, then send it to $V$.
Succinct noninteractive zeroknowledge (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 offchain 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 welldeveloped 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 offchain 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 proofoffandom 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 onchain data, more similar to Indexing (eg. Hyper Oracle). Empiric Network put the oracle fully onchain using zk. There is no offchain infrastructure that data has to flow through.
Fully onchain and privacypreserving 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 offchain 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 enduser or in a TrustedExecution Environment (TEE) while the Verifier can be deployed by a decentralized oracle network.
Reference
https://medium.com/ambergroup/needforspeedzeroknowledge1e29d4a82fcd
https://www.youtube.com/watch?v=eJqZQ2_VBzo&t=1345s
https://research.chain.link/deco.pdf
https://blog.chain.link/web3identityblockchainscredentialsoracles/