轉發原文標題《How can we make the use of web2 data in web3 actually private and verifiable?》

許多人認為 Web3 是新互聯網，並用“讀取、寫如、擁有”這一短語來定義它。“讀取”和“寫入”部分很清楚，但談到“擁有”數據時，今天我們幾乎什麼都不擁有。

用戶數據常常被公司竊取，並被他們利用；我們在互聯網上並不真正擁有任何東西。

然而，我們不能僅僅轉向一個只有 Web3 而什麼也不共享的世界。不，我們仍然需要共享，但只共享必要的部分。

作為一個對申請護照不熟悉的人，我被困在申請電子簽證、提交無休止的個人信息以證明我符合特定簽證條件的過程中。我總是會問自己：

• 為什麼我必須提供完整的銀行賬單，而他們只需要確認特定的收入水平？

• 為什麼我必須提供具體的酒店預訂，而不是僅需證明我在這個國家預訂了酒店？

• 為什麼在他們只需驗證我在當前國家的永久居留地時，我必須提交完整的護照信息？

這裡有兩個主要問題：服務商知道的信息遠超過他們需要的，而且你提供的數據並不是私密的。但這與加密貨幣中的安全性和隱私性有何關係呢？

1. Web3 離不開 Web2 數據

正如大多數人所知，智能合約本身並不知道 BTC、ETH、SOL 或任何其他資產的價格。這個任務由預言機（Oracles）承擔，預言機不斷地將外部世界的公開數據傳輸到智能合約中。

在以太坊生態中，這個角色幾乎被 @chainlink 的預言機網絡所壟斷，以確保我們不會依賴單一節點。所以，實際上我們確實需要 Web2 數據來支持更多的用例，而不僅僅是知道某些資產的價格。

然而，這僅適用於公開數據。如果我想安全地連接我的銀行賬戶或 Telegram 賬戶，並分享一些私密信息，而這些信息並非公開的，而是屬於我的私有數據該怎麼辦呢？

首先想到的是：我們如何將這些數據引入區塊鏈，並提供證明以確保私密數據的安全？

不幸的是，情況並非如此，因為服務器不會簽署它們發送的響應，因此你無法在智能合約中可靠地驗證類似的信息。

保障計算機網絡通信的協議被稱為 TLS（傳輸層安全協議）。即使你沒有聽說過它，你每天都在使用它。例如，當你閱讀這篇文章時，你會看到瀏覽器地址欄中的 “https://” 。

如果你嘗試使用 “http://” 連接到網站（沒有“s”），瀏覽器會警告你連接不安全。鏈接中的“s”代表 TLS，它確保了你的連接安全，保障隱私，並防止任何人竊取你傳輸的數據。

2. 連接已經安全了，難道我們不能直接在 web3 中傳輸並使用它嗎？

正如我之前提到的，我們面臨著可驗證性的問題：服務器不會簽署它們發送的響應，因此我們無法真正驗證數據。

即使數據源同意分享其數據，標準的 TLS 協議也無法向其他方證明其真實性。僅僅傳遞響應是不夠的：客戶端很容易本地篡改數據，分享這些響應會完全暴露它們，進而威脅到用戶隱私。

解決可驗證性問題的一種方法是增強版的 TLS，稱為 zkTLS。

zkTLS 的工作機制與 TLS 相似，但稍有不同，具體流程如下：

• 你通過安全的 TLS 連接訪問一個網站併發送所需的請求。

• zkTLS 生成一個 zk 證明來驗證數據，同時只揭示用戶想要證明的具體細節，保持其他內容的私密性。

• 生成的 zk 證明隨後被其他應用用來確認和驗證所提供的信息是否正確。

當我提到 zkTLS 時，我指的是利用 zkTLS 技術的項目，但關於數據可驗證性，有多種不同的解決方案，具體包括：

1. TEE（受信執行環境）
2. MPC（多方計算）
3. Proxy（代理）

有趣的是，每種方法都引入了獨特的用例。那麼，它們有何不同呢？

3. 為什麼 zkTLS 沒有單一標準？它們有何不同？

zkTLS 不是一項單一技術，因為可以從多個角度驗證私有 Web 數據而不暴露它，每個角度都有自己的權衡。核心思想是用證明來擴展 TLS，但如何生成和驗證這些證明取決於底層機制。

正如我之前提到的，三種主要方法是使用 TEE-TLS、MPC-TLS 或 Proxy-TLS。

TEE 依靠專門的硬件（例如 Intel SGX 或 AWS Nitro Enclaves）來創建一個安全的“黑匣子”，可以在其中處理數據並生成證明。硬件確保數據保密且計算防篡改。

在基於 TEE 的 zkTLS 設置中，TEE 運行協議，證明 TLS 會話的執行和內容。驗證者是 TEE 本身，因此信任取決於 TEE 的製造商及其對攻擊的抵抗力。這種方法效率高，計算和網絡開銷低。

然而，它有一個重大缺陷：你必須信任硬件製造商，TEE 中的漏洞（如旁路攻擊）可能會破壞整個系統。

Proxy-TLS 和 MPC-TLS 因其用例範圍廣泛而成為最廣泛採用的方法。建立在 @eigenlayer 上的項目如 @OpacityNetwork 和 @reclaimprotocol，利用這些模型來確保數據安全和隱私以及額外的經濟安全。

讓我們看看這些解決方案的安全性、zkTLS 協議支持哪些用例以及目前已經推出的功能。

4. MPC-TLS 和 Opacity Network 有何特別之處？

在 TLS 握手過程中（客戶端和服務器通過共享加密密鑰來達成安全通信的協議），網站的角色保持不變，但瀏覽器的處理方式有所不同。

它不生成自己的密鑰，而是使用節點網絡通過 MPC 創建多方密鑰。該密鑰為瀏覽器執行握手，確保沒有任何一個實體知道共享密鑰。

加密和解密需要所有節點和瀏覽器之間的合作，在數據到達或離開網站之前，每個節點都按順序添加或刪除自己的加密部分。 MPC-TLS 提供強大的安全性並且可以分佈式，因此沒有一個團體擁有所有權力。

Opacity Network 通過添加保障措施來最大程度地減少信任問題，增強了經典 @tlsnotary 框架。它採用多種安全措施，例如：

1. web2 賬戶 ID 的鏈上驗證
2. 提交方案
3. 揭示方案
4. 隨機 MPC 網絡採樣
5. 可驗證的嘗試日誌

帳戶 ID 在 web2 系統中是靜態的，允許委員會提供證明，十個不同的節點必須確認所有權。這會將帳戶鏈接到一個唯一的錢包，從而防止重複嘗試使用不同的錢包來查找共謀節點。

您可查看下圖，詳細瞭解 Opacity 的工作原理：

Opacity 節點在 TEE 內運行，如果 TEE 是安全的，那麼串通幾乎是不可能的。除了 TEE 之外，Opacity 還使用 Eigenlayer 來利用 AVS，要求節再質押 32 stETH，對不當行為立即進行罰沒，避免了冷卻期帶來的延遲。

可以看到，Opacity 同時使用了 MPC 和 TEE，但由於 MPC 用於 zkTLS，而 TEE 主要用於節點安全，因此仍稱為 MPC-TLS。

然而，如果 TEE 失敗，節點可能會參與 MPC 內的串通。這就是為什麼需要額外的經濟安全層來防止這種行為的原因之一。

這也是 Opacity 正在開發舉報機制的原因，在該機制中，能夠證明公證人行為不當的用戶將獲得公證人股份所受處罰的一部分。

由於其集成簡單、安全，且能保障隱私，Opacity 吸引了各種協議將其集成到消費者、DeFi 和 AI 代理領域的產品中。

來自 @earnos_io 的團隊自正在開發一個平臺，品牌可獎勵參與或完成任務的用戶。 EarnOS 使用 Opacity 的技術通過流行的應用程序證明特徵，而無需透露個人信息，讓品牌瞄準受眾，同時用戶保護隱私並獲得獎勵。

Opacity 也被集成到 @daylightenergy_ 協議，開發一個去中心化的電力公用事業網絡，用戶可通過為清潔能源解決方案做出貢獻而獲得獎勵。藉助 Opacity，用戶無需專門的硬件即可在鏈上證明能源設備的所有權。

Opacity 甚至可以與人工智能代理集成，為當前面臨重大挑戰的領域帶來更多的可驗證性和透明度。 zkTLS 最近被集成到 @elizaOS，允許可驗證的人工智能交互而不會破壞隱私。

然而，TEE-TLS 和 MPC-TLS 只是 zkTLS 的兩種變體，還有第三種稱為 Proxy-TLS，Reclaim Network 是該模型最著名的代表。那麼，它在技術方面與其他兩種變體有何不同，以及 Proxy-TLS 可以啟用哪些用例？

5. Proxy-TLS 和 Reclaim Protocol 有何特別之處？

HTTPS 代理在互聯網上很常見，可轉發加密流量而不訪問其內容。在 zkTLS 代理模型中，它的工作原理幾乎相同，只是略有增加：

• 瀏覽器通過代理向網站發送請求，代理還處理網站的響應。

• 代理查看所有加密交換並證明其真實性，注意每個交換是請求還是響應。

• 然後，瀏覽器生成一個 zk 證明，表明它可使用共享密鑰加密該數據而不洩露密鑰，並顯示結果。

• 這是有效的，因為幾乎不可能創建將數據轉換為任何有意義的內容的假密鑰，因此只需顯示您可以解密它就足夠了。

洩露密鑰會危及之前的所有消息，包括用戶名和密碼等敏感數據。Proxy-TLS 速度相當快、價格實惠，並且可以很好地處理大數據量，因此非常適合高吞吐量設置。

大多數服務器不會根據不同的 IP 地址來限制訪問，因此該方法的適用範圍相當廣泛。

Reclaim Protocol 使用 Proxy-TLS 進行高效的數據驗證，並使用代理繞過 Web2 防火牆，防止大規模代理阻塞。

它的工作原理如下：

這裡的主要問題是共謀：如果用戶和證明者共謀，他們基本上可以簽署任何東西並進行惡意行為。為了緩解這種情況，Reclaim 包含了一部分驗證者，這些驗證者被選擇來引入隨機性並阻止此類漏洞。

Reclaim 使用 Eigen 的 AVS 將驗證去中心化。EigenLayer 操作員可充當證明者，但他們需要部署自己的 AVS 來指定其服務的證明邏輯。

Reclaim 是一個支持獨特用例的平臺，例如為交通應用程序導入拼車數據、為區塊鏈經濟橋接鏈外數據、使用國民身份證數據驗證身份、通過開發人員工具創建自定義數據解決方案等等。

Reclaim 生態系統擁有 20 多個項目，但我想重點介紹其中 4 個項目，涉及貨幣市場、數字身份、消費者和招聘領域。

@3janexyz 是 Base 上第一個基於信用的貨幣市場，通過使用鏈上和鏈下財務數據評估加密用戶的信譽和未來現金流，為他們提供有擔保的信用額度。

3Jane 使用 Reclaim 的代理模型來驗證來自 VantageScore、Cred、Coinbase 和 Plaid 的信用數據，確保這些數據的隱私。

另一個使用 zkTLS 與信用評分相關的例子是 @zkme 的功能——zkCreditScore。它利用 Reclaim 協議通過 zkTLS 安全地獲取你的美國信用評分。這樣，zkMe 可以檢查用戶的信用評分，並創建獨特的靈魂綁定代幣（SBTs）來存儲這些數據。

除了信用評分之外，還有其他用途嗎？當然有。

我們可以以 @zkp2p 為例，它是一個消費品市場，利用 Reclaim 協議驗證用戶的 Ticketmaster 數據以及支付信息。

與此同時，@bondexapp，作為加密領域最受歡迎的招聘平臺之一，也使用 Reclaim 來獲取用戶的工作證明，確保數據的真實性、隱私性和可驗證性。

從 zkTLS 的應用場景來看，能夠在鏈上驗證 TLS 記錄已經解鎖了許多新的功能，讓用戶可以控制自己的數據，而不需要依賴大企業的許可。

更重要的是，zkTLS 旨在確保你的個人數據不會被用來對付你。那麼，未來將會走向何方呢？

6. zkTLS 會長期存在嗎？

儘管仍有一些工作要做，但不同的 zkTLS 協議已經開始引入新的用例，將權力重新分配給用戶。

@Tim_Roughgarden 在 a16z 加密播客中強調，zk 證明（zk proofs）早在 1985 年就提出，但直到區塊鏈應用的興起，才真正獲得了廣泛關注，這要感謝數百位開發者為減少證明大小和成本而做出的不斷努力。

如今，區塊鏈行業的貢獻正在被應用到加密之外的其他領域。

我預計 zkTLS 會經歷類似的歷程，首先在 Web3 中實現，然後擴展到其他領域。正如我之前所說，現在我們雖然可以“讀取”和“寫入”，但在數據保護方面幾乎沒有保障，甚至連自己的數據都無法“真正擁有”。

免責聲明：

1. 本文轉載自 [Pavel Paramonov]。所有版權歸原作者所有 [Pavel Paramonov]。若對本次轉載有異議，請聯繫 Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止複製、分發或抄襲翻譯文章。