读懂Chainlink DECO：隐私保护的预言机

作者：kokii.eth

Intro

Web3重塑了数据价值，但分布式结构的区块链是一个封闭的确定性系统，智能合约没有实现外部 API 调用的功能，从而诞生了预言机这个机制用来帮助智能合约获取外部数据。

链下数据上链本身并不困难，难的是通过技术和机制设计生产信任，预言机问题就是需要解决从数据源到处理到喂价的信任问题。

成为公众认可的预言机的一个基本条件是去中心化，即是否允许单点故障和数据验证。链下去中心化的常用解决方案是使用多个数据节点形成去中心预言机网络，每个节点都会收集数据，达成共识后输入到区块链上的智能合约。

当前预言机的主要用法是为DeFi提供Price Feed（喂价），安全及时准确地更新基础资产的价格。根据DefiLlama数据， Chainlink是市场上**的预言机解决方案之一，在撰写本文时担保的总价值约为$11B，占整个市场的46%。

随着区块链的发展，对链下数据的需求越来越强烈，单纯为DeFi喂价已经无法满足开发者的需求。现实世界和Web2中的绝大多数数据都无法公开访问，但却是构建Web3创新应用场景（信用借贷, 社交, DID, KYC/AML, etc.）所必须的。因此新一代预言机需要使智能合约能够以隐私保护的方式支持涉及敏感数据的复杂用例。

DECO是Chainlink在这个方向的解决方案，利用零知识证明技术，让用户可以向智能合约生成链下隐私数据证明，而不向公众或预言机节点本身透露数据。DECO可以接入现有API，即使需要终端用户验证（例如获取银行账户余额需要登录），也无需API数据提供商做任何修改。目前已进行到alpha阶段，正与多个合作伙伴一起测试概念验证。

1. Background

这里提供关于TLS和ZKP的必要背景，DECO建立在这些协议之上。

1.1 TLS

TLS（Transport Layer Security, 传输层安全性）是一个强大的、广泛部署的安全性协议，前身是SSL，旨在促进互联网通信的私密性和数据安全性，位于应用程序协议层和 TCP/IP 层之间，主要用例是对 web 应用程序和服务器之间的通信进行加密。

通过 HTTP 进行的通信都是以纯文本形式进行的，容易被窃听，篡改和冒充。使用 TLS 后，用户发送到网站（单击、填写表格等）的HTTP数据和网站发送给用户的 HTTP 数据都被加密，接收者必须使用密钥来解密加密的数据。HTTPS 是在 HTTP 协议基础上实施 TLS 加密，是网站的标准做法，网站需要在其源服务器上安装 TLS 证书，浏览器会将所有非 HTTPS 网站标记为不安全。

TLS的基本思路是采用公钥加密法，网站公开共享的 TLS/SSL 证书包含公钥，而私钥安装在源服务器上，并由网站所有。客户端先向服务器端索要数字证书公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

这里有一个问题，公钥加密计算量太大，为了减少会话耗用的时间，每一次会话客户端和服务器端都生成一个”会话密钥”（session key），用它来加密信息。由于”会话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”会话密钥”本身，这样就减少了加密运算的消耗时间。

因此TLS协议主要可以分为两个层：

1. 做认证密钥协商的握手协议 (handshake protocol)：明文通信，通过非对称加密相互确认彼此验证，确立将使用的加密算法，并生成一致的会话密钥用于记录协议的对称加密

2. 做对称加密传输的记录协议 (record protocol)：协议主体，对数据传输进行保密性和完整性保护

TLS的加密套件（CipherSuite）是4个算法的组合：

1. 认证 (Authentication) ：判断身份的真实性，主流的有 RSA/DSA/ECDSA

2. 密钥交换 (Key exchange) ：通信双方协商用于加密的密钥，主流的有 ECDHE

3. 加密 (Encryption) ：用于通信的对称加密，趋势是使用GCM

4. MAC (Message Authentication Code，消息认证码) ：用于验证数据完整性以及数据是否被篡改，主流有 SHA256/SHA384/SHA1等

TLS非常强大，但有一个限制：不允许用户向第三方证明他所访问的数据确实是来自某个特定的网站，因为数据传输使用的是对称加密，用户和服务器一样有能力对数据进行签名。直观的例子是，有很多网站的服务器内都存有Alice的身份信息，可以轻松验证Alice已经超过18岁，但Alice很难向Bob证明这点。Alice可以从网站上截图，但截图很容易伪造，即使截图能被证明是真实的，也会泄露信息——Alice的确切出生日期，而不仅仅是她已超过18岁这个事实。

预言机需要去中心化（不依赖单点例如网站服务器）证明链下隐私数据的出处（Provenance），并在不泄露隐私的前提下供智能合约使用。零知识证明可以帮助实现这些功能。

1.2 ZKP

零知识证明（Zero Knowledge Proof, ZKP）在区块链受到广泛关注，主要应用为ZK-Rollup（为了提高扩容效率在算法设计上做了不少妥协，不 zk 的 Validity Proof）与隐私技术 (真正的 zk)。零知识证明允许Prover向Verifier证明其拥有一个解（Witness）能够解决某个计算问题（Statement），而无需透露任何关于该解（Witness）的额外信息。

一个典型的ZK系统可以分为前端和后端。

1. 前端：编译器，将需要验证的Statement写成领域特定语言（DSL），再编译为ZK友好的格式，例如算数电路；

2. 后端：证明系统，检查电路正确性的交互式论证系统，例如Marlin, Plonky2, Halo2；

在区块链这样的开放系统上构造交互提问的流程很复杂，证明需要任何人都能随时进行验证，因此区块链应用上的ZK系统通常是非交互式的，交互式可以使用Fiat–Shamir-heuristic转换为非交互式。

2. How DECO works

DECO在HTTPS/TLS协议基础上进行了扩展，使得服务器端无需修改就能使用。

DECO的核心思想是在Prover (用户或运行DECO Prover的Dapp)，Verifier (运行DECO Verifier的Chainlink预言机)，Server (数据提供商) 之间构建一个新颖的三方握手协议。

• Provenance：当Prover从Web Server查询信息时，Verifier见证交互过程，并收到由Prover就TLS会话数据创建的一个承诺（Commitment），由此Verifier就能验证信息的真实来源；

• Privacy：如果数据无需隐私，Prover可以直接向Verifier提供可以解密数据的密钥，供开发者在Dapp中加入数据；如果需要隐私，Prover利用ZKP生成不泄露数据的证明，供开发者在Dapp中加入。

具体来说，DECO协议由三个阶段组成：

1. 三方握手，Prover，Verifier和Server建立特殊格式的会话密钥，保证数据不可伪造；

2. 查询执行，Prover使用带有她的私有参数 θs（例如账号密码，API key）的Query，向Server查询数据 ；

3. 证明生成，Prover证明响应满足所需条件。

2.1 Three-party handshake

注：以下说明基于AES-CBC-HMAC加密算法，TLS 1.3 只保留了更安全的AEAD作为加密算法，使用一个密钥用作加密和MAC，不需要MAC密钥。但由于TLS 1.3 的密钥独立性，同样也可以构建一个复杂度类似的三方握手协议。

Prover P 不能在获取MAC密钥后再作出承诺，否则他就可以伪造或篡改数据，因此三方握手的思想是将Prover P 和Verifier V 共同作为TLS客户端，与TLS server S 建立一个共享MAC密钥。MAC密钥 k 在客户端侧被切分，Prover持有 kp，Verifier持有 kv，k=kp+kv。同时， P 还持有用于对称加密算法的加密密钥 k^{Enc}。如果Verifier不作恶，三方握手协议就能确保数据是不可伪造的。

2.2 Query execution

在握手之后， 由于MAC密钥是秘密共享的，P 和 V 执行一个交互式协议（两方安全计算），并使用私有参数 θs 来构建一个加密查询的TLS消息 Query Q。然后 P 作为一个标准的TLS客户端将 Q 发送给 S，这个过程中只有 P 与 S 通信，其发送的任何查询都无法泄露给 V 。

在从 S 收到响应 R 后，P 通过向 V 发送密文 Rˆ 承诺会话，并收到 V 的 kv ，验证响应 R 的真实性。

2.3 Proof generation

接下来，P 需要证明密文 Rˆ 对应的明文 R 满足某些属性，如果不需要隐私可以直接揭示加密密钥  k^{Enc}，在需要隐私的情况下需要使用零知识证明。

假如明文由几个数据块组成 R=(B1,…,Bn)， DECO使用选择性公开（Selective Opening）来生成零知识证明：

• 只揭示特定的数据行：在不揭示其他数据块的前提下，证明 R 的第 i 个数据块是 Bi

• 隐藏包含隐私数据的数据行：证明 R_{-i} 和 R 相等，除了 Bi 被删除

然而，很多时候 Verifier 需要验证所揭示的子字符串是否出现在正确的上下文中，上面提到方法不足以提供上下文的完整性保护。为了弥补这一点，DECO利用了一种名为零知识两阶段解析（Two-stage Parsing）的技术：Prover在本地解析其会话数据，确定能说服Verifier的最小子字符串，再向Verifier发送数据。由此实现了隐私性。

简洁的非交互式（NIZK）零知识证明在计算和内存方面通常在Prover侧具有很高的开销。由于DECO进行的ZKP的Verifier是指定的（Chainlink的预言机），因此可以使用更高效的交互式零知识证明，例如更小的内存使用，避免可信设置，廉价的计算等。

目前的Alpha Test中DECO依旧是使用Dapp在充当Prover，在未来的迭代中，计划Prover可以由终端用户本地部署（例如手机），或在可信执行环境（TEE）中部署。

3. Application

DECO可以验证用户链下身份信息的有效性，同时还能保障数据隐私，从而解锁很多Web3创新应用场景，从经济到社交。

• 自托管社交恢复/法律身份证明（你是谁）：使用DECO，利用已经拥有成熟身份验证机制的机构网站（银行，社交媒体）充当社交恢复其中一个守护人。

• 信用借贷/资金证明（你有多少钱） ：Teller是一个DeFi信用借贷协议，使用DECO协议证明用户在链下银行账户中的资产余额超过了贷款所要求的动态**门槛。

• 粉丝证明/交互证明（你与谁互动过）：Clique是一个社交预言机，正在开发一种解决方案，提供对跨各种社交媒体平台（例如使用Twitter API）的链下用户影响力、忠诚度和贡献的深度分析。

• 数字身份/社交身份证明（你拥有某个线上账户）：PhotoChromic是一个数字身份解决方案，使用DECO将Web3用户与其Twitter或Discord社交账户绑定，并在过程中不暴露底层个人身份数据，使应用能够过滤出真实的用户。

• DAO的抗女巫攻击，T，KYC/AML，etc.

4. Other Players

• Axiom为Uniswap TWAP构建ZK预言机，采取完全来自链上的可验证数据源，更类似于Indexing（eg. Hyper Oracle）；和DECO更像是互补而非竞争关系：越来越多的经济活动会发生在链上，纯链上预言机是一个方向；越来越多的链下数据需要上链，链下隐私预言机也是一个方向。

• Empiric Network 利用zk计算将整个预言机放在链上，没有数据必须流过的链下基础设施，和DECO不是一个方向上。

5. Conclusion

Chainlink作为当前预言机的**龙头，通过DECO预言机，海量链下私有数据将能在隐私保护的前提下被链上智能合约调用，可以解锁从金融到身份到社交等诸多应用场景。潜在的隐患是Prover的证明生成速度，和Verifier的中心化问题。