什麼是 zkTLS：新手入門指南

zkTLS 適用於需要將網頁或經驗證 API 的數值提供給合約或交易對手的讀者，而非用來取代 HTTPS 的新型傳輸方式。相較於螢幕截圖或自行陳述，它能將「工作階段連上目標網站」及「欄位符合特定條件」轉化為可驗證的證據。持續性的公開市場資料來源通常更依賴區塊鏈預言機；下文將介紹與資料來源型架構的比較。

下列章節將說明定義、從工作階段到證明的步驟、MPC／Proxy／TEE 的差異、使用案例、與預言機的對比及風險，並提供公開機制說明文件，例如 Oasis zkTLS 說明及 EthSystems zk-TLS 模式頁面。

重點摘要

• zkTLS 可將 HTTPS 工作階段轉換為可驗證的聲明：綁定網域／憑證，並可選擇僅揭露特定條件的結果。
• 此名稱經常造成誤解：並非每種設計都在交握階段使用零知識證明；MPC、Proxy 與 TEE 是常見的三種途徑。
• 由於 TLS 以共享的對稱工作階段金鑰結束，單一用戶端可以偽造逐字記錄並展示，因此需要公證人、代理伺服器或 TEE。
• 來源可追溯性不等於內容真實性：若來源回傳錯誤欄位，證明在形式上仍可能有效。
• 驗證者應檢查網域／憑證綁定、特定條件，以及證明路徑上的證明簽章或信任根。

什麼是 zkTLS？它解決什麼問題？

zkTLS 解決了一般 TLS 的缺口：傳輸層安全性（Transport Layer Security）支撐瀏覽器的 HTTPS 連線，可加密並驗證用戶端與伺服器之間的通道；但工作階段結束後，若不交出可能遭濫用的解密資料或依賴螢幕截圖，就很難向第三方證明伺服器確實回傳了該內容。因此，合約難以使用登入後的欄位資料。

標準 TLS 交握會產生對稱工作階段金鑰：瀏覽器與伺服器都能加密及解密。若用戶僅展示密文及該金鑰，其他各方無法排除用戶先加密偽造明文，再視需要將其解密的可能性，因此單一用戶端無法成為可靠的見證者。這項限制促成了公證人、代理伺服器或 TEE 的需求。

zkTLS 所提供的是來源可追溯性與完整性證據，而不是對業務真實性的最終裁決。證明某個餘額欄位來自某網站的 TLS 工作階段，無法否定錯誤資料輸入或遭竄改的頁面；這與zkOracle 與 zkCoprocessor中的零知識資料來源敘事相近，但屬於不同的問題領域。

zkTLS 如何運作？從 HTTPS 工作階段到可驗證聲明

概括而言，zkTLS 將一般 HTTPS 工作階段轉換為可驗證的證明：用戶與來源建立工作階段；MPC 公證人、Proxy 或 TEE 路徑會留下可驗證的證據；接著產生並驗證選擇性揭露證明。

1. 開啟工作階段 — 與目標網域建立 TLS 連線；憑證與網域綁定會成為後續聲明的一部分。
2. 共同見證或委派 — 公證人參與交握／解密（MPC）、代理伺服器證明密文方向（Proxy），或由 TEE 執行請求，使單一用戶端無法輕易偽造由伺服器傳送的密文；有些設計將此視為多方協定，而非單一用戶端流程。
3. 擷取目標欄位 — 在工作階段內請求帳戶頁面或 API，並接收加密回應。
4. 建立聲明 — 針對逐字記錄承諾、伺服器身分及特定條件（例如餘額 > 門檻）產生證明（或路徑簽章）；以電路為基礎的途徑會將逐字記錄限制轉換為證明輸出。
5. 提交驗證 — 合約或交易對手檢查證明與信任根，然後接受或拒絕。

選擇性揭露是常見的第二層：可證明餘額高於特定門檻而不揭露確切金額，或僅擷取一個欄位並隱藏其餘內容。根據 Reclaim 關於 zkTLS 中「zk」的說明，隱私零知識證明通常是一項強化功能；更基本的需求是讓第三方相信回應確實來自來源。

圖 1。zkTLS 將用戶端 HTTPS 工作階段透過 MPC／Proxy／TEE 證明路徑，轉換為由驗證者或智慧合約檢查的選擇性揭露證明。

驗證者檢查清單至少應涵蓋四項：網域與憑證是否綁定至所聲稱的來源；特定條件是否符合業務規則；證明路徑的簽章或信任根是否位於允許清單中；以及來源結構變更是否會導致剖析器失效。省略任何一項，都會讓「可驗證」變成「看起來像證明」，即使其目標是為智慧合約或交易對手產生可驗證資料。

為什麼稱為 zkTLS？MPC、Proxy 與 TEE 有何不同？

「zkTLS」是常見的統稱，容易讓人以為零知識證明必須在交握階段執行，但事實並非總是如此。這個標籤常被廣泛用於混合式協定，但並非每種實作都真正符合這種描述。許多設計更接近 Web Proofs 或 TLS 證明：重點在於可驗證性，而非必須在交握階段內使用零知識證明。

這三種途徑都在回答同一個問題：如何在不交出可能遭濫用的對稱金鑰下，讓第三方相信密文來自伺服器。代理伺服器可觀察資料傳輸方向，而無須查看明文。MPC／2PC 設計（TLSNotary 類型）透過共同持有金鑰來阻止單方面偽造；Proxy 設計結合方向證明與用戶端解密證明；TEE 設計則在硬體隔離環境中執行工作階段。隱私零知識證明可用於欄位遮蔽，但 TEE 與大多數 MPC 交握並非交握層級的零知識證明。

選擇途徑取決於威脅模型與成本：是否可接受單一公證人、代理伺服器或 TEE；工作階段是否必須維持低延遲；以及來源是否僅支援特定 TLS 版本。MPC 途徑也能確保沒有任何單一節點持有完整金鑰。應將「zk」視為可驗證網路資料的標籤，而非嚴格的密碼學分類。

zkTLS 可用於哪些情境？

經典使用案例是證明鏈下帳戶符合某項門檻，而不公開完整對帳資料：例如信貸資格的餘額門檻、金融工作流程中的銀行餘額檢查而不揭露確切金額、登入入口網站中的就業或聲譽欄位，以及任務規則中對鏈下活動的確認。這些情境的共同特徵是資料位於 HTTPS 後方，且沒有可直接使用的已簽署公開 API。

身分與屬性使用案例包括身分驗證與經驗證憑證，以及年齡區間、會員等級或摘要評分：驗證者看到的是特定條件結果，而非包含私人資料的完整頁面。zkPass zkTLS 預言機等協定型產品將可在鏈上驗證的私有資料納入其架構；應區分協定如何封裝證明，以及 zkTLS 模式本身能保證什麼。

另一類是保護隱私的資料來源：應用程式需要在鏈上應用中使用網站欄位，但不希望向所有觀察者公開完整擷取內容的明文。在此情境下，zkTLS 提供具來源可追溯性的欄位證明；但仍須與去中心化金融及更廣泛 Web-to-chain 工作流程中使用的持續性價格資料來源與多來源聚合機制區分開來。

zkTLS 與傳統預言機有何不同？

傳統預言機著重於將鏈下事實（價格、事件結果）寫入區塊鏈，通常透過節點集合或多來源資料來源完成。這項差異正是預言機問題的一部分：如何將可信的鏈下或網路資料提供給合約。zkTLS 則著重於證明 HTTPS 工作階段欄位來自特定來源，並可選擇採用選擇性揭露。資料來源會最佳化可用性與抗操縱性；zkTLS 則最佳化將網路工作階段轉換為可驗證聲明的能力。

若要比較資料來源架構、信任假設與失效模式，請參閱 zkTLS 與傳統預言機。簡要原則是：持續性的公開市場資料來源仍較適合成熟的預言機網路；需要最少揭露的私人登入後欄位則較適合 zkTLS。部分系統也將資料可攜性視為獨立的設計目標；兩者可相互組合，但彼此都不能取代對方。

使用或依賴 zkTLS 處理敏感資料有哪些優勢與風險？

其優勢包括：只要用戶仍可與來源完成 HTTPS 連線，就能匯出可驗證的欄位，而不必等待專用資料來源 API；選擇性揭露可讓合約驗證某項事實，而無須公開完整私有紀錄；聲明也可由合約以程式方式進行驗證。

風險同樣具體。公證人、代理伺服器或 TEE 的誠實性與可用性構成信任根：串通、拒絕服務或停機都可能造成錯誤接受或驗證失敗。以 TEE 為基礎的設計也帶有與硬體製造商或證明根相關的安全風險。來源的誠實性不在協定範圍內：錯誤頁面仍可能產生形式上有效的證明。欄位路徑變更會導致特定條件失效；部分公證堆疊僅支援特定 TLS 版本。

依賴此機制的各方也應衡量證明成本、工作階段延遲，以及工作階段逐字記錄的保留風險。zkTLS 能提升來源可追溯性的可驗證性；它不會將任意網頁變成未經審核的真實來源。

總結

zkTLS 可將日常 HTTPS 工作階段升級為可驗證且最少揭露的聲明，使合約能驗證欄位來自哪個綁定網域的伺服器，而非依賴螢幕截圖。「zk」不保證在交握階段採用零知識證明；MPC、Proxy 與 TEE 在不同信任假設下達成完整性保證。

在部署前，應理解持有對稱金鑰的單一用戶端可以模擬虛假的工作階段展示；驗證者檢查清單必須涵蓋網域／憑證、特定條件與信任根；來源可追溯性不等於內容真實性；而傳統預言機與 zkTLS 則分別適用於持續性資料來源及私人頁面欄位證明。請依據威脅模型選擇適當途徑，並將來源與證明風險納入該模型。

常見問題

什麼是 zkTLS？

zkTLS 是一系列建立於標準 TLS／HTTPS 之上的設計，可產生供第三方驗證的聲明：特定資料來自綁定某個網域與憑證的伺服器，並可選擇僅揭露特定條件的結果。它可在不取代 HTTPS 的情況下，將私有 Web2 欄位連結至合約驗證。

zkTLS 如何將 HTTPS 工作階段轉換為可驗證聲明？

用戶端與來源建立工作階段；MPC 公證人、Proxy 或 TEE 共同見證或執行委派，使單一用戶端無法偽造伺服器密文；接著建立選擇性揭露證明；驗證者在接受或拒絕前，會檢查網域綁定、特定條件與信任根。

zkTLS 是否必須在 TLS 交握階段使用零知識證明？

不必。許多標示為 zkTLS 的系統會使用 MPC、Proxy 或 TEE 保障完整性；零知識證明通常在後續用於選擇性揭露或 Proxy 類型的解密證明。交握本身可能完全不執行 ZK 電路，「zk」只是常用標籤。

zkTLS 與傳統預言機有何不同？

傳統預言機以多來源與可用性為目標，持續向合約提供鏈下事實；zkTLS 則為工作階段層級的 HTTPS 欄位提供來源可追溯性證明（及可選的特定條件）。公開資料來源與私人登入頁面欄位是不同問題；請參閱比較主題，兩者可結合使用。

依賴 zkTLS 的主要風險是什麼？

主要風險包括遭入侵或不可用的公證人、代理伺服器或 TEE；即使證明在形式上有效，來源仍可能提供錯誤資料；頁面結構變更導致剖析器失效；以及 TLS 版本限制。略過網域綁定與信任根檢查，將提高錯誤接受的風險。