技術棧擴展:全面解析ZKTLS原理與潛在應用場景


作者@web3_mario探討了Zktls(零知識證明與傳輸層安全協議)在Web3行業中的應用。 Zktls技術允許在沒有第三方信任的情況下,驗證鏈下HTTPS數據的真實性,確保數據源可靠且未被篡改。這突破了傳統Oracle解決方案成本高、效率低的問題,並保護數據隱私,防止關鍵信息洩露。同時,Zktls降低了利用Web2資源的成本,推動了新需求,可能會對現有的Oracle項目產生衝擊。開發者需重視這一技術在產品設計中的潛力與影響。

作者:@web3_mario

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

tls協議

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

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

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

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

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

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

tls協議解決上述問題的主要思路是:

1.加密通信:使用對稱加密( aes,chacha20)保護數據,防止竊聽。 ,防止竊聽。

2.身份認證:x.509證書)來驗證服務器的身份

3.數據完整性:(HMAC (哈希消息認證碼)或(AEAD (認證加密)確保數據未被篡改。)

tls tls協議的https協議在數據交互過程中的技術細節,整個過程共分為兩個階段,首先是握手階段( htshake),即客戶端與服務器端協商安全參數並建立加密會話即客戶端與服務器端協商安全參數並建立加密會話即客戶端與服務器端協商安全參數並建立加密會話。其次是數據傳輸階段,即使用會話密鑰進行加密通信。具體的過程共分為四個步驟::

1.客戶端發送客戶端::

(客戶端(如瀏覽器)向服務器發送clienthello消息,內容包括::

TLS 版本(如tls 1.3) 支持的加密算法(密碼套件,如aes-gcm,chacha20) 隨機數((客戶隨機)(隨機)(用於密鑰生成) 密鑰共享參數(如(ecdhe) SNI (服務器名稱指示)(可選,用於支持多域名https)

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

2.服務器發送serverhello:

服務器響應serverhello消息,內容包括::

選擇的加密算法服務器隨機數((服務器隨機) 服務器的證書( x.509證書) 服務器的密鑰共享參數(如(ecdhe) (完成消息(用來確認握手完成)

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

3.客戶端驗證服務器::

客戶端執行以下操作:

驗證服務器證書:確保證書由受信任的ca (證書頒發機構),同時驗證證書是否過期或被撤銷;,同時驗證證書是否過期或被撤銷; 計算共享密鑰:使用自己和服務器的ecdhe(會話密鑰),該密鑰用於後續通信的對稱加密(如aes-gcm)。 發送完成消息:證明握手數據完整性,防止中間人攻擊(米(MITM)。

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

4.開始加密通信::

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

AES-GCM,chacha20),提高速度和安全性。 ,提高速度和安全性。 ,提高速度和安全性。 數據完整性保護:使用aead (如aes-aes-gcm)防止篡改。

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

然而經過一系列迭代後,開發者發現dapp對於鏈外數據還是有需求的,於是一系列預言機,oracle項目便出現了,chainlink和pyth等。他們通過充當鏈上數據與鏈下數據的中繼橋,來打破這種數據孤島的現象。同時為了保證中繼數據的可用性向鏈上提供錯誤信息。例如我們希望在智能合約中訪問btc在binance,coinbase等中心化交易所的加權價格,則需要依仗這些oracle將數據在鏈下訪問加總,並傳輸到鏈上智能合約,並傳輸到鏈上智能合約中存儲起來,才可以使用。 ,才可以使用。

zktls解決了什麼問題

然而人們發現,這種基於oracle的數據獲取方案,存在兩個問題::

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

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

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

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

那麼Zktls則採用了另一種手段,其構想在於,通過密碼學的保護,替代掉傳統oracle基於共l2 l2 Zk-rollup對op-rollup的優化。具體來講,通過引入,Zkp零知識證明,並對鏈下中繼節點請求某https 得到的資源、相關的ca 證書驗證信息、時序證明以及基於hmac或併在鏈上維護必要的驗證信息以及驗證算法,使得智能合約在不暴露關鍵信息的同時,可以驗證數據的真實性、實效性、及數據源的可靠性。具體的算法細節在這裡不做討論,感興趣的小伙伴可以自行深入研究。

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

綜上所述,小伙伴們在做產品設計的時候

資訊來源:由0x資訊編譯自互聯網。版權歸作者所有,未經許可,不得轉載!

Total
0
Shares
Related Posts