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

zkTLS最大的好處就是降低了Web2 HTTPS資源的達成可用性的成本。

作者：
@Web3_Mario

摘要
：最近一直在尋找新的項目方向，在做產品設計的時候遇到了一個之前沒有接觸過的科技棧，所以做了一下研究，並將學習心得做一下整理，與諸君分享。

總的來講，zkTLS是一種結合零知識證明（ZKP）和TLS（傳輸層安全協定）的新型科技，在Web3賽道中主要用於在鏈上虛擬機器環境中，可以在無需信任協力廠商的情况下驗證其所提供的鏈下HTTPS數據的真實性，這裡的真實性包含三個方面，資料來源確實來源於某個HTTPS資源、返回的數據沒有經過篡改、數據的實效性可以得到保證。

通過這種密碼學實現機制，使鏈上智慧合約獲得可信訪問鏈下Web2 HTTPS資源的能力，打破數據孤島。

什麼是TLS協定

為了能够比較深刻的理解zkTLS科技的價值，有必要將TLS協定做一下簡單的綜述。 首先TLS（傳輸層安全協定）用於在網路通信中提供加密、認證和數據完整性，確保用戶端（如瀏覽器）和服務器（如網站）之間的資料安全傳輸。 對於非網絡開發方向的小夥伴可能會發現，在訪問網站時，有些功能變數名稱是以https作為首碼，有些則以http作為首碼。 而在訪問後者時，主流瀏覽器都會提示不安全。 而前者則容易遇到&ldquo； 您的連結不是私密連結&rdquo； 或者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消息，內容包括：

l支持的TLS版本（如TLS 1.3）

l支持的加密演算法（Cipher Suites，如AES-GCM、 ChaCha20）

l亂數（Client Random）（用於金鑰生成）

l金鑰共亯參數（如ECDHE公開金鑰）

l SNI（伺服器名稱訓示）（可選，用於支持多功能變數名稱HTTPS）

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

2.服務器發送ServerHello：

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

l選擇的加密演算法

l服務器亂數（Server Random）

l服務器的證書（X.509證書）

l服務器的金鑰共亯參數（如ECDHE公開金鑰）

l Finished消息（用來確認握手完成）

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

3.用戶端驗證服務器：

用戶端執行以下操作：

l驗證服務器證書：確保證書由受信任的CA（證書頒發機构）簽發，同時驗證證書是否過期或被撤銷；

l計算共亯金鑰：使用自己和服務器的ECDHE公開金鑰計算出會話金鑰（Session Key），該金鑰用於後續通信的對稱加密（如AES-GCM）。

l發送Finished消息：證明握手數據完整性，防止中間人攻擊（MITM）。

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

4.開始加密通信：

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

l採用對稱加密（如AES-GCM、ChaCha20）加密數據，提高速度和安全性。

l數據完整性保護：使用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的發展動態，並在適當的方面綜合這個科技棧，或許可以在業務創新、以及科技架構性方面，找到一些新方向。

歡迎加入深潮TechFlow官方社群

Telegram訂閱群： https://www.gushiio.com/TechFlowDaily

Twitter官方帳號： https://www.gushiio.com/TechFlowPost

Twitter英文账号：https://www.gushiio.com/DeFlow_Intern