技術棧拓展：綜述zkTLS的原理以及潛在應用場景

作者 ：++@Web3++ ++_Mario++

摘要 ：最近一直在尋找新的項目方向，在做產品設計的時候遇到了一个之前沒有接觸過的技術棧，所以做了一下研究，並將學習心得做一下整理，與諸君分享。總的來講，zkTLS 是一種結合零知識證明（ZKP）和TLS（傳輸層安全協議）的新型技術，在Web3賽道中主要用於在鏈上虛擬機環境中，可以在無需信任第三方的情況下驗證其所提供的鏈下HTTPS 數據的真實性，這裡的真實性包含三個方面，數據源確實來源於某個HTTPS資源、返回的數據沒有經過篡改、數據的實效性可以得到保證。通過這種密碼學實現機制，使鏈上智能合約獲得可信訪問鏈下Web2 HTTPS資源的能力，打破數據孤島。

什麼是TLS協議

為了能夠比較深刻的理解zkTLS技術的價值，有必要將TLS協議做一下簡單的綜述。首先TLS（傳輸層安全協議）用於在網絡通信中提供加密、認證和數據完整性，確保客戶端（如瀏覽器）和伺服器（如網站）之間的數據安全傳輸。對於非網絡開發方向的小夥伴可能會發現，在訪問網站時，有些域名是以https作為前綴，有些則以http作為前綴。而在訪問後者時，主流瀏覽器都會提示不安全。而前者則容易遇到"您的鏈接不是私密鏈接"或者HTTPS證書錯誤的提示。而這種提示的原因就在於TLS協議的可用性。

具體來講，所謂HTTPS協議就是在HTTP協議的基礎上利用TLS協議保證了信息傳輸的隱私性和完整性，並使得伺服器端的真實性變得可驗證。我們知道，HTTP協議是一種明文傳輸的網絡協議，且該協議不能對伺服器端的真實性做驗證，這就產生了幾個安全性問題：

1. 你和伺服器端傳輸的信息可能被第三方監聽，從而造成隱私洩漏；

2. 你無法驗證伺服器端的真實性，即你的請求是否被其他惡意節點劫持，並返回惡意信息；

3. 你無法驗證返回的信息的完整性，即是否有可能由於網絡原因造成數據丟失；

而TLS協議正是為了解決這些問題而被設計的。在這裡做個解釋，有些小夥伴可能知道SSL協議，其實TLS協議就是基於SSL 3.1版本開發的，只是由於一些商業相關的問題，換了個名字，但其實是一脈相承。所以有些時候在一些語境下，兩個詞是可以互換的。

而TLS協議解決上述問題的主要思路是：

1. 加密通信：使用對稱加密（AES、ChaCha20）保護數據，防止竊聽。

2. 身份認證：通過第三方頒發給指定機構的數字證書（如 X.509 證書）來驗證伺服器的身份，防止中間人攻擊（MITM）。

3. 數據完整性：使用 HMAC（哈希消息認證碼）或 AEAD（認證加密）確保數據未被篡改。

我們簡單來講解一下基於TLS協議的HTTPS協議在數據交互過程中的技術細節，整個過程共分為兩個階段，首先是握手階段（Handshake），即客戶端與伺服器端協商安全參數並建立加密會話。其次是數據傳輸階段，即使用會話密鑰進行加密通信。具體的過程共分為四個步驟：

1. 客戶端發送 ClientHello：

客戶端（如瀏覽器）向伺服器發送 ClientHello 消息，內容包括：

• 支持的 TLS 版本（如 TLS 1.3）
• 支持的加密算法（Cipher Suites，如 AES-GCM、ChaCha20）
• 隨機數（Client Random）（用於密鑰生成）
• 密鑰共享參數（如 ECDHE 公鑰）
• SNI（伺服器名稱指示）（可選，用於支持多域名 HTTPS）

其目的是讓伺服器知道客戶端的加密能力，並準備安全參數。

2. 伺服器發送 ServerHello：

伺服器響應 ServerHello 消息，內容包括：

• 選擇的加密算法
• 伺服器隨機數（Server Random）
• 伺服器的證書（X.509 證書）
• 伺服器的密鑰共享參數（如 ECDHE 公鑰）
• Finished 消息（用來確認握手完成）

其目的是讓客戶端知道伺服器的身份，並確認安全參數。

3. 客戶端驗證伺服器：

客戶端執行以下操作：

• 驗證伺服器證書：確保證書由受信任的 CA（證書頒發機構）簽發，同時驗證證書是否過期或被撤銷；
• 計算共享密鑰：使用自己和伺服器的 ECDHE 公鑰計算出 會話密鑰（Session Key），該密鑰用於後續通信的對稱加密（如 AES-GCM）。
• 發送 Finished 消息：證明握手數據完整性，防止中間人攻擊（MITM）。

其目的是確保伺服器可信，並生成會話密鑰。

4. 開始加密通信：

客戶端和伺服器現在使用協商好的會話密鑰進行加密通信。

• 采用 對稱加密（如 AES-GCM、ChaCha20）加密數據，提高速度和安全性。
• 數據完整性保護：使用 AEAD（如 AES-GCM）防止篡改。

所以經過這四步操作後，就可以有效解決HTTP協議的問題。然而這種廣泛應用在Web2網絡中的基礎技術，卻為Web3應用開發造成了困擾，特別是在鏈上智能合約希望訪問某些鏈下數據時，由於數據可用性的問題，鏈上虛擬機不會開放為外部數據的調用能力，以確保所有數據的可回溯性，進而保證共識機制的安全性。

然而經過一系列迭代後，開發者發現DApp對於鏈外數據還是有需求的，於是一系列預言機Oracle項目便出現了，例如Chainlink和Pyth等。他們通過充當鏈上數據與鏈下數據的中繼橋，來打破這種數據孤島的現象。同時為了保證中繼數據的可用性，這些Oracle普遍通過PoS共識機制來實現，即讓中繼節點的作惡成本高於收益，使其從經濟效益上不會向鏈上提供錯誤信息。例如我們希望在智能合約中訪問BTC在Binance、Coinbase等中心化交易所的加權價格，則需要依賴這些Oracle將數據在鏈下訪問加總，並傳輸到鏈上智能合約中存儲起來，才可以使用。

zkTLS解決了什麼問題

然而人們發現，這種基於Oracle的數據獲取方案，存在兩個問題：

1. 成本過高：我們知道為了保證Oracle傳遞到鏈上的數據是真實數據，沒有經過篡改，需要由PoS共識機制保證，然而PoS共識機制的安全性是建立在質押資金量的基礎上的，這就為維護帶來了成本。而且通常情況下，PoS共識機制中存在大量的數據交互冗餘，因為當數據集合需要在網絡中大量重複傳輸、計算、匯總，才可以通過共識，這也墊高了數據使用成本。所以通常情況下，Oracle項目為了獲客，只會免費維護一些最主流的數據，例如BTC等主流資產的價格。而對於專屬需求，則需要通過為之付費。這就阻礙了應用創新，特別是一些長尾、定制化的需求。

2. 效率過低：通常情況下，PoS機制的共識需要一定的時間，這就造成了鏈上數據的滯後性，這對於一些高頻訪問的使用場景是不利的，因為鏈上獲得的數據與真實的鏈下數據存在較大的延遲。

為了解決上述問題，zkTLS技術便應運而生，它的主要思路是通過引入ZKP零知識證明算法，讓鏈上智能合約作為第三方，可以直接驗證某個節點提供的數據，確實是訪問了某個HTTPS資源後返回的數據，且未經篡改，這樣就可以避免傳統Oracle因共識算法導致的高昂的使用成本。

有小夥伴可能會問，為什麼不直接為鏈上VM環境中內置Web2 API調用的能力。答案是不可以的，因為鏈上環境中之所以需要保持一個封閉數據的原因是要保證所有數據的可追溯性，即在共識過程中，所有節點對於某一數據或某一執行結果的準確性有統一的評估邏輯，或者說是一種客觀的驗證邏輯。這保證了在完全去信任的環境下，大多數善意節點可以依賴自己冗餘的數據判斷直接結果的真偽。但是由於Web2數據，你很難構建其這種統一的評估邏輯，因為可能由於某些網絡延遲原因，不同節點訪問Web2 HTTPS資源所獲得的結果是不一樣的，這就為共識增添了困難，特別是針對一些高頻數據領域。除此之外，另一個關鍵問題在於，HTTPS協議依賴的TLS協議的安全性，依賴於客戶端生成的隨機數（Client Random）（用於密鑰生成）和密鑰共享參數，實現與伺服器端針對加密密鑰的協商，但我們知道鏈上環境是公開透明的，如果讓智能合約維護隨機數和密鑰共享參數，則關鍵數據將會被暴露，從而使數據隱私性被損害。

那麼zkTLS則採用了另一種手段，其構想在於，通過密碼學的保護，替代掉傳統Oracle基於共識機制為數據帶來可用性的高昂成本。類似於L2中的ZK-Rollup對OP-Rollup的優化。具體來講，通過引入ZKP零知識證明，並對鏈下中繼節點請求某HTTPS得到的資源、相關的CA證書驗證信息、時序證明以及基於HMAC 或 AEAD 的數據完整性證明進行計算生成Proof，並在鏈上維護必要的驗證信息以及驗證算法，使得智能合約在不暴露關鍵信息的同時，可以驗證數據的真實性、實效性、及數據源的可靠性。具體的算法細節在這裡不做討論，感興趣的小夥伴可以自行深入研究。

這種技術方案最大的好處就是降低了Web2 HTTPS資源的達成可用性的成本。這就激發了很多新需求，特別是在降低長尾資產的鏈上價格獲取、利用Web2世界中的權威網站做鏈上KYC，從而優化DID、Web3 Game的技術架構設計等方面。當然我們可以發現，zkTLS對現有Web3企業的衝擊也是存在的，特別是針對當前主流的預言機項目。所以為了應對這種衝擊，例如Chainlink、Pyth等該行業巨頭積極跟進相關方向的研究，試圖在技術迭代過程中依舊占據主導地位，同時也會催生新的商業模式，例如從原來的按時間收費向按用量收費轉換、Compute as a service等。當然這裡的難點與大多數ZK項目一樣，還是在於如何降低計算成本，使之具有商業化價值。

綜上所述，小夥伴們在做產品設計的時候，也可以關注zkTLS的發展動態，並在適當的方面整合這個技術棧，或許可以在業務創新、以及技術架構性方面，找到一些新方向。