一文讀懂 Chainlink DECO：隱私保護的預言機

撰文：kokii.eth，啟明創投 Intern

0. Intro

Web3重塑了數據價值，但分佈式結構的區塊鏈是一個封閉的確定性系統，智能合約沒有實現外部 API 調用的功能，從而誕生了預言機這個機制用來幫助智能合約獲取外部數據。

鏈下數據上鍊本身並不困難，難的是通過技術和機制設計生產信任，預言機問題就是需要解決從數據源到處理到喂價的信任問題。

成為公眾認可的預言機的一個基本條件是去中心化，即是否允許單點故障和數據驗證。鏈下去中心化的常用解決方案是使用多個數據節點形成去中心預言機網絡，每個節點都會收集數據，達成共識後輸入到區塊鏈上的智能合約。

Chainlink 架構

當前預言機的主要用法是為 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 網站標記為不安全。

非HTTPS網站

TLS 的基本思路是採用公鑰加密法，網站公開共享的 TLS/SSL 證書包含公鑰，而私鑰安裝在源服務器上，並由網站所有。客戶端先向服務器端索要數字證書公鑰，然後用公鑰加密信息，服務器收到密文後，用自己的私鑰解密。

這裡有一個問題，公鑰加密計算量太大，為了減少會話耗用的時間，每一次會話客戶端和服務器端都生成一個"會話密鑰"（session key），用它來加密信息。由於"會話密鑰"是對稱加密，所以運算速度非常快，而服務器公鑰只用於加密"會話密鑰"本身，這樣就減少了加密運算的消耗時間。

因此 TLS 協議主要可以分為兩個層：

1. 做認證密鑰協商的握手協議 (handshake protocol)：明文通信，通過非對稱加密相互確認彼此驗證，確立將使用的加密算法，並生成一致的會話密鑰用於記錄協議的對稱加密。

2. 做對稱加密傳輸的記錄協議 (record protocol)：協議主體，對數據傳輸進行保密性和完整性保護。

TLS 協議棧

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 系統

在區塊鏈這樣的開放系統上構造交互提問的流程很複雜，證明需要任何人都能隨時進行驗證，因此區塊鏈應用上的 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 Example

具體來說，DECO 協議由三個階段組成：

1. 三方握手，Prover，Verifier和Server建立特殊格式的會話密鑰，保證數據不可偽造；

2. 查詢執行，Prover使用帶有她的私有參數 θs（例如賬號密碼，API key）的Query，向Server查詢數據 ；

3. 證明生成，Prover證明響應滿足所需條件。

DECO Architecture

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 的抗女巫攻擊，SBT，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 的中心化問題。