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

作者： @Web3 _Mario

摘要：最近一直在尋找新的專案方向，在做產品設計的時候遇到了一個之前沒有接觸過的技術棧，所以做了一下研究，並將學習心得做一下整理，與諸君分享。總的來講，zkTLS 是一種結合零知識證明（ZKP）和TLS（傳輸層安全協定）的新型技術，在Web3賽道中主要用於在鏈上虛擬機環境中，可以在無需信任第三方的情況下驗證其所提供的鏈下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的發展動態，並在適當的方面整合這個技術棧，或許可以在業務創新、以及技術架構性方面，找到一些新方向。