ETHTaipei x TEM #16

Nic

Jun 02, 2025

本月 Meetup 由 Ryan、CC Wang 和 Kevin Chia 三位講者來分別介紹 ZK 技術如何實現在現實生活中，包含 ZK Email、(ZK) TLSNotary 及 zkPassport。

ZK Email 讓使用者能證明他收到的郵件內容，像是寄件人、標題及選定揭露的內文字句等
(ZK) TLSNotary 讓使用者能證明他所瀏覽的網頁內容
zkPassport 讓使用者可以證明他的護照資訊，例如發照國家、出生日期等

Video

Slides

ZK Email Summary by Ryan

ZK Email 是去中心化身份（DID）的關鍵基石，可同時提升 Web3 的使用者體驗與隱私保護。使用者得以「選擇性揭露」信件資訊，並將其轉換成鏈上可驗證的憑證（Proof）；整個流程僅仰賴傳統網際網路基礎設施（DKIM 與 DNS）及其對應的密碼學 ZK 函式庫。
將傳統數位簽章導入 Web3 的專案已相當多元，例如 Daimo（Passkeys）、zkPassport、Cursive（Passport／NFC）與 Apple Digital Certificates；zkEmail 則聚焦於把 Email、JWT 等常見數位身份與簽章搬上鏈。
最終用戶 僅需選擇「哪一封 Email」以及「欲證明的欄位」，即可透過 zkEmail 產生可在鏈上驗證的 ZK Proof。協議開發者 隨後可在智慧合約中定義驗證通過後的業務邏輯，讓 Email 資訊與鏈上身份／權限深度結合。單一 Proof 可同時驗證 DKIM 簽章、信件格式，以及（可選）信件內容。
為支援上述流程，zkEmail 團隊將下列密碼學與資料處理模組實作成 ZK 函式庫：RSA、SHA256、Partial SHA256、Base64 Decoding、Quoted-Printable Decoding、Substring Extraction、Regex、Bitmasking、Attachment Parsing 等。
要使用 zkEmail 的話，開發者常用工具包含：**zkEmail SDK、Registry、Archive、ZK Email Verifier、ZK JWT、ZK Regex、Email Wallet、Email Tx Builder、Account Recovery、Relayer**。
zkEmail 已在多個 production ready 專案中落地使用，包含 zkP2P（zkP2P Domain 有用到但已經停止服務）、Stealthnote、Email Wallet、Wallet Recovery 與 POLP。

(ZK) TLSNotary Summary by CC Wang

HTTP 是客戶端與伺服器間的基本通訊標準，包含請求與回應機制；HTTPS 透過 TLS/SSL 加密保護通訊，防止中間人攻擊，TLS 握手流程透過密鑰交換與 CA 憑證機制建立安全連線
OAuth 讓用戶可授權第三方服務存取部分資料，但存在隱私問題，包括：用戶難以最小化資料分享、第三方獲得過多隱私、伺服器可追蹤用戶行為
透過結合 TLS-2PC 技術，TLSNotary 能在確保用戶隱私的同時保有傳統 TLS 相容性，使得更具隱私性的 OAuth 得以實現
TLSNotary 保持原有 TLS 安全性，額外加入 MPC（多方安全計算）機制
運作架構：Prover 與 Server 建立 TLS 連線，Prover 與 Verifier 透過 TLS-2PC 協作
從 Server 角度看，Prover 和 Verifier 是同一個實體；Prover 可選擇性揭露特定資訊給 Verifier，實現最小化資料分享；Verifier 只需信任 Notary 並驗證簽名資料的真實性

zkPassport Summary by Kevin

zkPassport 是 Aztec 的一個隱私身份專案，用零知識證明（ZKP）讓使用者只部分揭露護照資訊，解決傳統身份驗證中「暴露過多資訊」及「無法驗證真偽」的問題
應用場景: 鏈上及鏈下身份驗證、Proof of Personhood（防女巫攻擊）、dApp 合規／KYC，未來將整合到 Aztec 錢包中支援隱私代幣的合規
使用流程: 使用者將護照用 NFC 匯入手機 App，驗證者透過 Web SDK 勾選要揭露的資訊，使用者在 App 中確認並產生零知識證明，最後驗證者使用 SDK 驗證證明
底層機制
- ICAO 標準晶片資料：晶片包含了 Data Groups（年齡、國籍等）與 SOD（簽章憑證）
- 信任鏈驗證：
  1. 驗證 CSCA（Country Signing Certificate Authority，譬如政府）對 DS（Document Signer，譬如簽發單位）的簽章,
  2. 驗證 DS 對護照的簽章,
  3. 比對 Data Group 的雜湊值
- ZKP 電路與系統：
  - 證明在用戶手機端產生，電路用 Noir 實作、UltraHonk 生成證明
  - base proofs（即信任鏈驗證的三步）只需產生一次，速度較慢
  - disclosure proofs（部分資訊揭露）產生快，並包含 unique identifier 用於防重放
和 Self Protocol 比較：
- zkPassport 證明全在手機產生、而 Self 因為效率問題用到了 TEE，多一層信任
- Self 雖多一步「註冊」，但可防止簽發單位認出使用者 disclosure proofs

延伸討論

在 ZK Email 中，是否能利用 Partial Hash 或段落抽取功能抽換信件內容，讓產生的 Proof 偏離原意？

by Ryan

被抽取的段落會以 Array 形式作為 public input 參與證明生成；若刻意拼接非連續段落，Proof 仍會顯示它們屬於不同段落，因此難以隱匿地扭曲內容。

在 ZK Email 中，Partial Hash 的主要用途是什麼？

by Ryan

它可先對不欲公開的內容預先計算 Hash，減少在電路內呼叫 Hash Function 的次數，從而提升生成 Proof 的效率。

ZK Email 採用哪些 Proof System？

by Ryan

ZK Email SDK 會依情境自動挑選合適的 Proof System；而 ZK Email Verifier 則允許開發者自行指定。

在 ZK Email 中，若 Email Server 或 DNS Server 遭入侵，攻擊者是否能偽造 Proof？

by Ryan

有此風險。ZK Email 對信件真實性的信任仍仰賴這些基礎設施，後續將詳述相關安全假設與緩解策略

在 ZK TLSNotary 中，TLSNotary 運行的部分會造成多少額外的時間差呢？

by CC Wang

由於目前多數 MPC 相關專案仍受限於理論帶來額外計算成本，導致開發者需要花費額外心力，設計配套措施以提升用戶體驗。基於不同的硬體環境與處理內容，測得的延遲時間就會有所差異。根據講者之前的實測，若使用 Notary / Verifier 分離的架構做 OAuth 登入，大約需要五分鐘可完成，預期只存在 Verifier 的架構可能會花費更長的時間。

在 zkPassport 中，使用者的 unique identifier 是什麼？存在於哪裡？

by Kevin Chia

每個使用者都有唯一的 unique ID，可讓 app 區分不同使用者且不會揭露使用者身份。unique ID 由「護照資料 + app hostname + scope」hash 而成，是生成的零知識證明的 public output。

在 zkPassport 中，攻擊者（如簽發機關）因為知道使用者護照資訊而可認出使用者 unique ID？能否加入隨機數防護？

by Kevin Chia

可行，但隨機數必須由「所有人都信任且非使用者本身」產生，例如由 TEE 產生、或使用者和 app 伺服器透過 MPC 生成，才能確保只有使用者本人知道且無法操控該隨機數。

如果你在看完這次演講後有更多的問題想問、有其他技術想了解，請大方地告訴我們！

我有問題想問🙋

編輯閒聊區

不同的 ZK TLS 設計

Nic

這兩篇文章都在介紹基於 ZK TLS 的兩種不同設計：zkTLS MPC 與 Proxy-TLS。zkTLS MPC 基於 TLSNotary，也就是靠 MPC 引入第三方來避免能偽造或篡改 TLS 的內容；而 Proxy-TLS 也一樣是引入第三方，只是第三方是單純作為一個 Proxy 並對流經它的 TLS 加密資訊進行認證。這兩個方法都需要仰賴對第三方的信任且各有優缺點：MPC 因其多方參與的特性所以的信任需求更低，但 MPC 計算負擔重因此資訊量大的應用或許更適合使用 Proxy-TLS。