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