讀懂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的中心化問題。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

標題：讀懂Chainlink DECO：隱私保護的預言機

地址：https://www.torrentbusiness.com/article/22266.html

標籤：