zkTLS 與傳統預言機：哪種網路資料更適合上鏈？

本比較適合正在私有頁面欄位與公開資訊流之間做選擇的產品與風險評估讀者。其運作機制已在 zkTLS 中說明；鏈下資料橋接的統稱則屬於 區塊鏈預言機。以下章節將比較資料來源、隱私、信任與延遲，並釐清螢幕截圖／PDF 與密碼學溯源之間的界線。

以下提供比較面向與「適用情境」清單，包括螢幕截圖或 PDF 的效力止於何處，以及密碼學溯源從何處開始。具協定架構的封裝方案包括 zkPass zkTLS 預言機；零知識資訊流的相關說明則可參考 zkOracle 與 zkCoprocessor。

重點摘要

• zkTLS 著重證明 HTTPS 工作階段中的欄位來自哪個已綁定網域的伺服器；傳統預言機則著重持續將公開事實寫入鏈上，並抵抗操縱。
• 沒有已簽名公開 API 的私有登入後頁面適合 zkTLS；持續更新的市場價格與多來源彙總則適合成熟的預言機網路。
• 選擇性揭露是 zkTLS 的常見優勢；傳統資訊流通常會向所有鏈上觀察者公開彙總數值。
• 螢幕截圖與 PDF 上傳可支援營運作業，但缺乏可驗證的工作階段溯源；密碼學聲明可證明溯源與完整性，但無法證明來源內容的真實性。
• 請依據「適用情境」清單做選擇，並將公證人／節點集合風險及來源錯誤納入威脅模型。

此表將選擇濃縮為便於快速檢視的面向：資料來源與存取路徑決定誰能查看資料；隱私與信任根決定錯誤接受的代價；延遲與資料類型則決定哪種路徑的工程成本較低。螢幕截圖另列一列，是因為營運作業常將影像視為「證明」，但其證據等級與密碼學溯源並不相同。

圖 1．zkTLS 與傳統預言機在來源存取、隱私、信任假設與延遲方面的並列比較。

什麼是 zkTLS？

zkTLS 是一類技術，可將 TLS／HTTPS 工作階段中的欄位轉化為第三方可驗證的聲明：將網域與憑證綁定，並可選擇僅揭露謂詞結果（例如餘額超過某個門檻），而無須交出完整明文。

zkTLS 不會取代 HTTPS，也不會自動判定來源的業務事實是否正確；它提供溯源與完整性證據。HTTPS 使用的傳輸層安全性協定，可讓用戶端與伺服器安全交換資料。團隊通常以 MPC、Proxy 路徑或 TEE 作為完整性的主要實作路徑；「zk」常是統稱。即使零知識證明是廣泛協定系列中的其中一個可選層，TLS 握手本身也未必會執行零知識電路。

實務上，用戶端會與來源伺服器建立 TLS 工作階段。由於工作階段金鑰由用戶端與伺服器共享，單一用戶端可以加密任意位元組，之後再將其「解密」，因此其他方不能將原始傳輸記錄視為誠實的伺服器輸出。這也是 zkTLS 設計會加入見證者的原因：與用戶端共同執行協定的 MPC 公證人、證明密文傳輸方向的 Proxy，或將金鑰保留在密封運算環境內的 TEE。最終產生的證明可讓驗證者使用該聲明，而無須得知完整頁面或工作階段金鑰。

什麼是傳統預言機？

傳統預言機會將鏈下事實寫入鏈上狀態，使智慧合約可存取鏈下或現實世界資料來源的外部資料。常見輸出包括價格資訊流、利率、體育賽果或公開事件結果。這類網路最適合公開資料或可公開取得的資料，而非私有使用者紀錄。其設計重點通常是多來源彙總、節點可用性與抗操縱能力，而不是證明某個 HTML 欄位是否出現在使用者已登入的工作階段中。

合約讀取的是資訊流更新，而不是瀏覽器傳輸記錄。持續更新的公開市場資料很適合此路徑；私有登入頁面欄位通常沒有已簽名的公開 API，而且資訊流網路預設不會重播每位使用者的 HTTPS 工作階段。因此，去中心化應用程式通常會使用預言機取得共享外部資料，而非取得個人工作階段證據。預言機參與方通常會運行伺服器來擷取公開端點；它們不會位於使用者用戶端的 TLS 通道內，因此無法像 zkTLS 的用戶端加見證者協定那樣，輕易使用私有銀行頁面。

資料來源與存取路徑有何不同？

核心差異如下：zkTLS 追蹤使用者已可向來源開啟的工作階段；傳統預言機則追蹤營運節點可擷取的公開來源。

在 zkTLS 路徑中，用戶端會向目標網域伺服器完成 HTTPS 連線，且可從任何 HTTPS 網站產生證明，無須預先取得 API 存取權。部分設計採用 Proxy 模型，由中介方見證或轉送用戶端與伺服器之間的交換，而非採用 MPC 式的工作階段處理。其他基於 MPC 的方法會共同執行 TLS 握手，也就是建立安全工作階段金鑰的協定步驟，使任一方都無法單獨偽造伺服器密文。公證人、Proxy 或 TEE 會留下可驗證的證據，之後再建立聲明證明。在傳統預言機路徑中，節點會擷取交易場所、指數或公開 API，將其彙總成資訊流，再由合約讀取該資訊流。當沒有方便的公開資訊流時，這使 zkTLS 可用於驗證既有系統中的 Web2 資料。否則，傳統資料驗證或其他確認程序會要求另一方直接擷取相同來源。

沒有使用者工作階段時，zkTLS 無法取代公開資訊流；沒有可擷取的公開來源時，節點無法安全使用登入後的私有欄位。伺服器支援的方法也取決於來源伺服器是否允許匯出，因此營運方可限制可分享的內容。使用 Web Proofs 的產品因此會將用戶端、伺服器與見證方視為同一條協定路徑。Oasis zkTLS 說明 與 EthSystems zk-TLS 模式頁面 等公開機制說明，皆闡述相同的工作階段至證明路徑。

隱私、私有資料與選擇性揭露有何不同？

zkTLS 的常見能力是選擇性揭露：證明已達到某個門檻而不公開確切金額，或擷取單一欄位並隱藏其餘內容。它也可針對這類資料證明聲明，而不揭露完整內容。這使 zkTLS 適用於必須證明私有或敏感資料，但不能公開完整紀錄的情境。一旦傳統預言機資訊流上鏈，彙總數值通常對所有觀察者可見，隱私目標往往會與完全可讀的資訊流衝突。

如果產品需要資格門檻，但不需公開完整對帳單，zkTLS 符合此需求。這在以選擇性揭露方式證明法律身分或財務紀錄等個人或敏感資料時尤其相關。如果產品需要讓所有人依據相同公開價格進行結算，傳統資訊流則符合需求。兩者也可組合使用：公開價格透過預言機提供，私有使用者屬性則透過 zkTLS 聲明提供。這有助於將私有網際網路資料帶上鏈，同時避免廣泛揭露；部分系統將其描述為可驗證 HTTPS 網站的私有網際網路資料上鏈，而無須公開完整紀錄的模型。

選擇性揭露通常建構於 TLS 傳輸記錄證明之上。用戶端仍會與來源伺服器通訊；見證方協助綁定回應；之後電路或遮罩協定會產生較小的證明，供其他方使用。在 MPC 設計中，工作階段金鑰可被拆分，使任何單一方都無法濫用它。在 Proxy 設計中，Proxy 證明密文，而用戶端保有解密金鑰，並在運算中證明其知曉明文。無論採用何種方式，目標都是使用私有欄位，而不必將其傳送給每一部驗證者伺服器。

信任假設、資料完整性與失效模式有何不同？

zkTLS 的信任建立在網域／憑證綁定，以及公證人、Proxy 或 TEE 路徑是否誠實且可用之上。如果來源伺服器回傳錯誤欄位，形式上有效的證明仍可能被接受，因為溯源不等於內容真實性。若零知識揭露正確實作，驗證者仍無法得知證明者的個人資訊。審查者仍應詢問哪些方持有金鑰材料、哪些方運行 MPC 或 Proxy 協定，以及哪張伺服器憑證釘選 TLS 端點。

傳統預言機的信任建立在節點集合組成、多來源規則與經濟激勵之上。其失效通常表現為來源操縱、節點共謀，或過時／有偏誤的資訊流。若驗證者或營運方必須直接檢視私有紀錄，也會產生額外的安全風險與資料外洩疑慮。檢查清單有所不同：zkTLS 強調綁定、謂詞、資料真實性、資料完整性與信任根檢查；預言機則強調新鮮度、偏差門檻與彙總來源。略過任一方的檢查，都會讓「看似可用」形成錯誤的驗證安全感。若沒有見證者，用戶端偽造仍是關鍵失效模式；若協定參與方共謀，遭破壞的見證者則是關鍵失效模式。

應如何權衡延遲、成本與資料類型？

有三項實務原則：持續更新的公開市場資料更適合傳統預言機；針對使用者特定資料或財務資料的一次性或低頻率證明更適合 zkTLS；螢幕截圖與 PDF 適合營運紀錄，不適合用於密碼學溯源。

zkTLS 會產生每個工作階段的處理與證明成本，延遲通常高於即時資訊流路徑，適用於餘額門檻、會員等級以及就業或聲譽欄位。這包括證明銀行帳戶或銀行帳戶餘額已達所需門檻，而不公開底層憑證或完整對帳單。MPC TLS 路徑可能需要大量通訊；Proxy 路徑可減少互動式運算，但仍需要在線見證伺服器；TEE 路徑則會將金鑰處理移入密封硬體。傳統預言機維護持續更新，適合價格、利率與公開事件，並針對許多用戶端應用程式每個區塊都會使用的低延遲市場資料進行設計。

螢幕截圖、PDF 或手動上傳可呈現「看似某個頁面」的內容，但第三方無法透過密碼學驗證 TLS 工作階段是否連至目標網域伺服器，或欄位是否未遭用戶端編輯。zkTLS 式聲明可確保此類私有輸入的資料真實性並保留資料溯源，但仍無法證明來源的業務事實為真。即便如此，錯誤的來源頁面、DOM 失效與公證人離線仍會影響正確性或可用性。僅將螢幕截圖作為關卡，等同信任上傳者與審查者；將證明視為「真相」，則忽略來源錯誤可能在形式上仍有效。同時使用螢幕截圖與密碼學證明的團隊，應清楚標示每道關卡接受哪一類證據。

應選擇 zkTLS 還是傳統預言機？

**適合選擇 zkTLS 的情況：**資料位於使用者可向來源伺服器開啟的登入 HTTPS 頁面或私有 API 之後；需要謂詞層級的最小化揭露；不存在現成的多來源公開資訊流；可接受按請求計算的證明延遲，以及公證人、Proxy 或 TEE 信任根。對於身分驗證或其他私有使用者紀錄的證明，若無法接受完整揭露，這通常是較佳路徑。若多方共同運算比瀏覽器便利性更重要，請選擇 MPC；若希望使用既有用戶端 Proxy 功能，請選擇 Proxy；若密封式金鑰保管是主要控制措施，請選擇 TEE。

**適合選擇傳統預言機的情況：**需要持續更新的公開市場價格或事件結果；合約必須依可由網路讀取的資訊流結算；已有成熟的多來源彙總與偏差監控；隱私不是該欄位的主要限制。這些資訊流通常是從共享外部系統驅動智慧合約決策，而非處理個人紀錄。預言機網路的設計可讓許多用戶端合約使用相同公開資訊流，而不必讓每位使用者開啟私有 TLS 工作階段。

**適合組合兩者的情況：**公開價格透過預言機提供，私有使用者屬性透過 zkTLS 提供。當應用程式在真實世界資產工作流程或敏感業務邏輯中，同時需要公開資訊流與私有聲明時，這種組合很常見。無論採取何種方式，都應將「溯源 ≠ 真實性」寫入規則：來源伺服器錯誤、節點共謀、公證人遭破壞、金鑰處理薄弱及頁面重新設計，都是一級風險，而非附註。協定選擇應明確指出，哪些參與方必須保持誠實，證明才具備意義。

總結

zkTLS 與傳統預言機回答的是不同的鏈上問題：傳統預言機主要提供共享外部資料，而 zkTLS 協助在保護隱私的前提下，讓私有網頁紀錄可供驗證。這項差異過去使公開資訊流更容易使用，相較之下私有資料的利用率較低。比較資料來源存取、隱私、信任根與延遲後可發現，私有登入頁面欄位與公開資訊流很少能彼此替代。

簡言之：當許多合約需要相同公開資訊流時，請使用傳統預言機；當用戶端必須透過選擇性揭露證明，證明來源伺服器回傳的私有 TLS 回應時，請使用 zkTLS。MPC、Proxy 與 TEE 仍是此協定路徑的主要見證形式，各自改變哪些參與方持有金鑰材料，以及用戶端必須執行多少互動式運算。螢幕截圖與 PDF 無法填補密碼學溯源的缺口；TLS 證明也無法自動保證來源內容正確。依據「適用情境」清單做選擇，並將公證人／節點及來源失效模式納入威脅模型，比爭論標籤更有效。

常見問題

zkTLS 與傳統預言機有何差異？

傳統預言機主要向智慧合約提供公開資料；產品則會在必須證明使用者持有之 HTTPS 工作階段的資料真實性時使用 zkTLS。這也會影響驗證者看到的是底層紀錄，還是僅看到與該紀錄相關的證明。zkTLS 證明 TLS 工作階段中的欄位來自綁定特定網域與憑證的伺服器。部分設計會在用戶端與公證方之間的 TLS 握手過程中使用 MPC（安全多方運算），其他設計則依賴 Proxy 或基於 TEE 的見證者；傳統預言機則透過節點集合與多來源彙總，持續將公開鏈下事實（例如價格）寫入合約。一者著重工作階段溯源；另一者著重資訊流可用性與抗操縱能力。在基於 Proxy 或見證者的設計中，來源伺服器本身通常不需要變更，而用戶端仍會依協定規則持有或分享工作階段金鑰。

何時應使用 zkTLS，而非傳統預言機？

對於需要最小化揭露且沒有已簽名公開 API 的登入後私有欄位，應使用 zkTLS。尤其是產品需要透過存取權杖或工作階段憑證，從私有來源進行可驗證的資料共享時，用戶端可直接向來源伺服器驗證身分，而不必將原始紀錄交給中介方。部分實作會在本機執行零知識證明運算，因此可證明所選屬性，而無須上傳完整紀錄。對於需要可由網路讀取的結算機制之持續公開市場價格或事件結果，則應使用傳統預言機；如此可讓私有紀錄不進入公開預言機資訊流，同時仍讓合約使用共享價格。當不同參與方需要不同的證據類別時，公開資訊流與私有屬性可在同一產品中組合使用。

螢幕截圖或 PDF 上傳可取代 zkTLS 證明嗎？

通常無法可靠取代。網頁的螢幕截圖與 PDF 在營運上可能看似具說服力，但它們缺乏可驗證的 TLS 工作階段溯源，也不具備工作階段來源或完整性的密碼學證明，因此第三方難以排除影像遭編輯或頁面錯誤的可能性。相較之下，HTTP Proxy 見證者可觀察或轉送交換內容，以螢幕截圖或 PDF 無法做到的方式保留可驗證的溯源。zkTLS 式聲明提供網域綁定與完整性檢查路徑，但如果來源回傳錯誤資料，證明在形式上仍可能有效。

通過 zkTLS 驗證是否代表來源資料為真？

否。通過通常代表該聲明在既定信任假設下符合溯源與完整性要求，且證明可能包含完整性檢查，例如回應資料上的訊息驗證碼。證明可以顯示溯源與完整性，但底層敏感資訊仍可能反映錯誤欄位或來源端的錯誤輸入；來源資料輸入錯誤、遭竄改的頁面或錯誤 API 欄位，仍可能產生形式上有效的證明。部分設計也會在工作階段期間衍生加密金鑰，使使用者可解密回應，同時驗證者仍無法查看底層紀錄。可驗證的溯源與內容真實性是不同層次。

傳統預言機可直接使用使用者登入後網頁中的欄位嗎？

通常無法將其作為個人的 HTTPS 工作階段直接使用。傳統節點通常會從 API 或其他公開端點擷取公開來源，而不會擷取使用者私有的登入後工作階段傳輸記錄或 Web Proofs。部分較新的私有對私有預言機設計，則會將經驗證的 TLS 資料傳送至盲運算伺服器，而非將其發布為標準資訊流。此模型著重為私有輸入提供資料溯源，可為符合法規而維持加密資料的私密性，並可結合多位用戶端的資料進行共同運算；例如 Nillion 的 Private-to-Private Oracles 使用盲運算保護隱私，而 Reclaim Protocol 則是不同於該方法的 Proxy 式範例。這也可藉由將敏感工作階段資料移入私有運算，而非公開原始頁面內容來提升安全性；當登入後私有頁面沒有已簽名的開放 API 時，zkTLS 式 Web Proofs 或專用資料合作關係通常比預設資訊流工作更合適。