零知识证明专题第12期：客户端 ZK 与轻量证明——从服务器到手机的架构重构

第1章入口：从数据中心到用户口袋

1.1 一个手机上的证明是如何诞生的

凌晨两点，Lisa 的 Pixel 手机屏幕亮起。她刚刚收到一封来自 Uber 的 Offer 邮件——年薪 28 万美元，签字费 5 万。Lisa 想把这份薪资证明提交给链上信贷协议，以获得更低的贷款利率。但她并不想让任何人看到她的雇主全名、招聘邮箱，甚至邮件正文——她只想证明三个数字：年薪 ≥ 25 万，签字费 ≥ 3 万。

三年前，这个需求意味着：把邮件转发给机构审核员，签署一堆隐私协议，等待三天审核。今天，Lisa 在手机上打开一个叫 zk.email 的应用，授权 Gmail DKIM 公钥验证，选择「薪资」和「签字费」两个字段作为公开声明。浏览器中的 NoirJS 库生成了一个零知识证明——整个过程 47 秒，没有数据离开她的手机。证明被提交到链上验证合约，贷款协议在 12 秒后批准了 10 万 USDC 的额度。

这个场景不是概念验证。2026 年 7 月，它已经在以太坊主网上处理了超过 18,000 笔真实交易。

客户端 ZK——让手机、浏览器和边缘设备本地生成零知识证明——不再是密码学论文里的思想实验。它是正在发生的基础设施迁移。

1.2 服务器侧证明的隐性成本

要理解客户端 ZK 的颠覆性，需要先看清当前 ZKP 部署的主模型——服务器侧证明——的三重隐性成本。

第一，延迟。 一个典型的 Groth16 证明在高端 GPU（如 RTX 4090）上生成需要 0.3-5 秒，但在移动端请意味着：数据必须上传到证明服务器，排队等待，生成证明，再传回客户端。RTT（往返时延）加上队列等待，用户体验从「瞬时」退化到「3-15 秒」。对于需要即时反馈的场景（如支付验证、票务核销），这个延迟不可接受。

第二，隐私泄露。 服务器侧证明的核心矛盾在于：要证明的数据最初一定产生在用户端。如果你的信用卡对账单需要上传到证明生成器才能生成 ZKP，那么「零知识」只在验证阶段成立——证明生成器本身已经看到了所有明文数据。2025 年慢雾实验室的审计报告中指出，超过 40% 的 ZK 应用存在「证明生成器单点可见明文」的安全风险。在客户端本地生成证明，是避免这个风险最直接的方式。

第三，中心化风险。 集中式的证明生成节点成为了新的单点故障。2025 年 3 月，某知名 NFT 项目因证明生成器所在 AWS 区域宕机，导致 mint 暂停 6 小时。当证明生成变成了一项只能由少数 GPU 服务器完成的任务，系统的去中心化承诺就被打了折扣。

1.3 当 ZK 遇见移动端：三种需求场景

客户端 ZK 并非对所有场景都适用。当前的生产级应用集中在三类需求：

场景 A：身份验证与选择性披露。 用户需要向某个验证方证明自己满足某些属性（年龄 ≥ 18、国籍 ∈ EU 列表、信用评分 ≥ 700），但不希望泄露具体数值。这是客户端 ZK 最成熟的场景——Google Longfellow、zk.email 和 EUDI Wallet 都落在这个象限。它的密码学特征是：电路规模相对小（通常 < 2^18 个门），证明数据量在 KB 级，证明生成时间在 1-60 秒。

场景 B：数据的可验证性证明。 用户需要证明某个数据来源于真实的服务端（如 Web 页面、邮件服务器、TLS 连接），而不暴露会话内容。zkTLS 协议是这个场景的代表。它的技术难点不在电路规模，而在「可验证的 TLS 会话抓取」——需要浏览器插件或代理在 TLS 握手阶段记录会话密钥的承诺。

场景 C：链下状态跨设备共享。 用户在手机 A 上签署了一笔交易，在手机 B 上需要证明该签名有效——但不想让 B 设备看到 A 的私钥。或者更一般地：一个设备生成的状态证明，能被另一设备在不信任通道中验证。这本质上是递归证明的客户端变体——Nova 折叠方案的低内存优势在此凸显。

这三种场景覆盖了 2026 年客户端 ZK 生产中 95% 以上的真实部署。它们共同的架构哲学是：离线生成，在线验证；证明在客户端，验证在合约。

第2章轻量证明系统：密码学层面的可行性

许多开发者听到「手机生成 ZK 证明」的第一反应是：这能行吗？毕竟就连高端 GPU 跑一个 R1CS 约束系统也需要秒级时间。答案是：主要看选哪种证明系统。

2.1 为什么 Groth16 不适合手机？

Groth16 是当前链上验证最廉价的证明系统——验证只需一次配对运算和一次椭圆曲线点乘，验证 gas 费用约为 200k-300k。但它在客户端证明生成端有两大硬伤。

硬伤一：Trusted Setup 的移动端困境。 Groth16 依赖可信初始化（Trusted Setup），生成一套 CRS（Common Reference String），大小通常在 100 MB 到数 GB 之间。手机无法在每次证明时加载并缓存这么大结构——即使通过幂等校验压缩，CRS 的 on-disk 大小也远超手机应用的合理限制。更关键的是，CRS 的「有毒废物」假设（toxic waste）要求设置仪式无法被追踪——这在移动端的动态环境中几乎不可能保证。

硬伤二：大数运算的配对瓶颈。 Groth16 的证明生成包含大量域运算和配对操作，而手机 CPU（即使是 A18 / Snapdragon 8 Gen 4）的标量运算能力远逊于服务器 GPU。2024 年的基准数据显示，在 iPhone 16 Pro 上完整跑一次 Groth16 证明（电路规模 2^20 门）需要 180 秒以上。

结论：Groth16 是「验证端优化」的极致，但「证明端不友好」。它不适合作为客户端 ZK 的主力方案。

2.2 PLONKish 体系的验证器优化

PLONK 及其后继者（HyperPlonk、Orion、Clariity）从根本上改变了这个局面。PLONKish 体系的核心特征包括：

无需 Trusted Setup。PLONK 使用透明的随机数参考字符串（transparent setup），没有有毒废物依赖，CRS 大小仅与电路尺寸线性相关。
验证器计算的轻量化。PLONK 的验证只需约 7 次配对运算和若干多项式承诺打开——而 Groth16 是 1 次配对。但更重要的是，PLONK 允许「分阶段验证」：证明可被分割成多个子证明，验证器在资源受限端也能逐步检查。
多项式承诺的选择灵活性。PLONKish 框架允许选择不同的承诺方案——KZG（椭圆曲线配对，小证据但需要 Trusted Setup）、FRI（哈希基础，大证据但无配对）、Bulletproofs（对数证据大小但验证时间长）。对于客户端场景，FRI 承诺的透明性和抗量子特性，使其成为首选。

关键在于：PLONKish 的设计哲学是把计算量集中在证明端（更方便服务器侧做），验证端保持轻量——但这一哲学在客户端 ZK 中反过来使用：用 PLONKish 的「验证器可定制性」反过来优化证明端。HyperPlonk 的「零次信息和和检查」等技术进一步压缩了证明端的内存占用。

2.3 IOP + 抗运算哈希的组合优势

STARK 族方案（zk-STARK、FRI-STARK、Stwo）在移动端具有天然的结构性优势：

透明性（Transparency）：STARK 不依赖任何 Trusted Setup。这一特性使其在浏览器/手机环境中部署时无需处理「有毒废物」的工程复杂性和安全假设。
无配对运算：STARK 的验证只依赖哈希函数碰撞抗性，不需要椭圆曲线运算。在手机 SoC 的 NEON/SVE 指令集上，哈希运算（如 Rescue Prime、Poseidon、Keccak）可以享受 SIMD 加速，而大型有限域配对运算则需要多精度整数库（如 GMP）——后者在 ARM 架构上的性能远不如服务器端 E5/Xeon 处理器。
证据大小的权衡：STARK 的代价是证明体积极大——典型 STARK 证明在 50-200 KB，而 Groth16 仅约 200 B。但在移动端，网络带宽比计算周期便宜；200 KB 在 5G/Wi-Fi 6 下仅需几十毫秒传输。

关键基准：StarkWare 的 Stwo 证明器在 2026 年初集成了 WebGPU compute shader，在其约束多项式求值（constraint polynomial evaluation）阶段获得了 5x 加速，整体证明管道获得 2x 提升。这个加速发生在浏览器端——证明了 STARK 路线在客户端 ZK 中的可行性。

2.4 Nova 折叠在移动端的前景

Nova 折叠方案（Kothapalli et al., 2022）及其后继者 SuperNova 和 Protostar，提供了一个与上述方案完全不同的范式。

核心思想：不一次性证明整个计算轨迹，而是每次只证明一步（或一个折叠），将证明状态累积到「折叠状态」（accumulator）中，从而实现递归证明的线性复杂度。

这个方案对客户端 ZK 意味着什么？

内存的连续小占用：每次折叠只需要处理一个中间状态，而不是整个电路。在手机内存（通常 6-8 GB）上，Nova 可以处理百万级门的电路，而 PLONK/STARK 在类似约束规模下需要更大的工作集。
渐进式证明：用户可以在空闲时生成折叠证明，逐步构建最终证明——类似流式处理。这对于电池敏感型场景（如手机）至关重要。
但验证成本更高：Nova 的验证比 PLONK 更复杂——需要检查折叠状态的正确性，验证方仍需打开多个多项式承诺。因此，对于单次证明场景，Nova 优势不大；但涉及多次折叠或递归的场景（如跨设备状态累积），Nova 是当前唯一实用的移动端方案。

quadrantChart
    title 证明系统选型坐标系（客户端可行性）
    x-axis "证据大小 (小)" --> "证据大小 (大)"
    y-axis "客户端验证时间 (快)" --> "客户端验证时间 (慢)"
    quadrant-1 "推荐：客户端用 STARK/FRI"
    quadrant-2 "谨慎：仅限递归场景"
    quadrant-3 "不推荐：验证太重"
    quadrant-4 "不推荐：证据太大"
    "Groth16": [0.15, 0.35]
    "PLONK+KZG": [0.35, 0.45]
    "STARK/FRI": [0.85, 0.25]
    "Nova 折叠": [0.60, 0.55]
    "HyperPlonk": [0.50, 0.35]

图1：证明系统选型坐标系 — X 轴为证据大小（从左小到右大），Y 轴为客户端验证时间（从上快到下慢）。STARK/FRI 因透明性、无配对和可定制验证进入推荐区域；Nova 折叠位于中间偏右，因其递归特性在跨设备场景有独特价值；Groth16 在客户端两侧都不占优。

第3章 WASM + WebGPU：浏览器变身为证明引擎

如果说第 2 章从密码学层面回答了「哪种证明系统适合手机」，那么这一章回答「如何在浏览器中实际运行它们」。

3.1 WebAssembly 3.0 的 SIMD 指令对有限域运算的加速

WebAssembly（Wasm）自 2017 年登上浏览器主舞台以来，其核心定位始终是「接近原生的计算性能」。2025 年发布的 Wasm 3.0 规范引入了一个关键组件：定长 128-bit SIMD（Single Instruction Multiple Data）指令支持——即 Wasm SIMD 128。

为什么这对 ZK 重要？ ZK 证明生成的核心计算负载来自有限域大数运算——特别是域乘法、加法链和 NTT（数论变换）。这些运算天然适合 SIMD 并行化：

域乘法中的逐项乘积：128-bit SIMD 允许一次处理 4 个 32-bit 域元素或 2 个 64-bit 域元素。
NTT 的蝴蝶运算：每个周期需要同时读取两个域元素并执行乘-加。SIMD 指令在访存和计算两方面提供 2x-4x 加速。

实测数据：在以 Stwo 证明器为背景的基准测试中，Wasm SIMD 128 版本的有限域运算相比纯标量版本获得约 3.7x 的吞吐量提升。但在实际浏览器环境中，由于 Wasm 编译器的优化差异（SpiderMonkey vs V8 vs JavaScriptCore），SIMD 加速的跨度在 1.8x-3.7x 之间。

3.2 WebGPU 的 GPU 并行证明：从理论到实践

SIMD 加速的是标量运算的吞吐量——但如果能把证明工作负载卸载到 GPU，则可能获得数量级加速。这正是 WebGPU 的承诺。

WebGPU 的架构优势：

Compute Shader 是第一等公民，而非 WebGL 的 hack 扩展。
统一的着色语言 WGSL 可在同一代码路径上编译到 Vulkan/Metal/DirectX 12 后端。
显式的缓冲管理和工作组分派控制，允许开发者精细调优证明算法的并行特性。

典型的 WebGPU 加速 ZK 证明流水线：

约束系统构建（CPU 端）：Wasm 模块解析电路定义和公开输入，构建约束矩阵和多项式表示。这个阶段的顺序依赖性强，不适合 GPU。
FFT/NTT 预处理（CPU 端 + GPU 端）：部分前向 NTT 可在 GPU 上并行执行。zkSecurity 的基准显示，WGSL 实现的 NTT（基于 Cooley-Tukey 算法）在浏览器中相较纯 Wasm 版本获得 5x 加速。
MSM（多标量乘）并行化（GPU 端）：这是 ZK 证明中最耗时的操作——占比可达 60-80%。WebGPU 通过 compute shader 的 workgroup 协作机制，将 MSM 分解为多条不相关的椭圆曲线点乘，在 GPU 全局内存中聚合结果。实测 5x-10x 加速。
证明序列化（CPU 端）：输出 Proof 结构，传入 JSON/二进制序列化器。

flowchart LR
    A["输入数据（私密输入 + 公开输入）"] --> B["Wasm SIMD 解析约束"]
    B --> C["CPU: 约束矩阵构建\n& 多项式预处理"]
    C --> D["WebGPU Compute Shader 调度"]
    D --> E["WGSL: NTT / FFT 并行计算\n（5x 加速 vs CPU）"]
    D --> F["WGSL: MSM 并行化\n（5x-10x 加速）"]
    E --> G["GPU 全局内存\n中间约束多项式"]
    F --> G
    G --> H["Proof 组合与序列化"]
    H --> I["输出 SNARK/STARK\n（JSON / 二进制）"]
    
    style B fill:#e1f5fe
    style D fill:#fff3e0
    style E fill:#c8e6c9
    style F fill:#c8e6c9
    style H fill:#f3e5f5

图2：WebGPU 加速 ZK 证明的流水线架构 — 输入数据经过 Wasm SIMD 解析后进行约束构建，预处理的 FFT/MSM 计算通过 WebGPU compute shader 卸载到 GPU 并行执行，最后序列化输出证明。标注为绿色的步骤（NTT 和 MSM）获得了最大加速收益。

3.3 工具链成熟度：NoirJS、ezkl、mopro

工具链是客户端 ZK 从论文走向工程的关键。2025-2026 年，三个项目构成了工具链的主轴：

NoirJS — Noir 电路的浏览器端 SDK。将 Noir 编译器输出的 ACIR（Abstract Circuit Intermediate Representation）在浏览器中加载，通过 Wasm 编译的 nargo 后端执行证明。2026 年 3 月发布的 v0.36 版本支持了以下关键特性：WebGPU 后端的实验性支持、证明生成进度回调、以及 Proof 的 Base64 编码输出。barretenberg.js（Noir 的后端库）在浏览器端的初始加载大小已优化至约 8 MB（wasm+gz），相比 2024 年的 25 MB 有了大幅改善。

ezkl — 聚焦于 ZK-ML（零知识机器学习）。ezkl 的核心创新在于：将训练好的 ONNX 模型自动编译为 Halo2 电路，生成 ZK 证明。2025 年 1 月发布的 iOS 原生库（Swift 绑定）使其能在 iPhone 上运行。虽然 Halo2 的证明生成时间仍远长于 Groth16（部分场景多 373x），但对于 ML 推理这类本身就耗时较长的计算，设备端证明的隐私收益足以弥补性能代价。ezkl 当前支持的最复杂模型为约 2^22 个门的神经网络，在 iPhone 16 Pro 上推理需要约 4 分钟。

Mopro — 移动端 ZK 的「瑞士军刀」。Mopro 提供 Rust 核心库 + Swift / Kotlin / Dart 的跨平台绑定，支持 Halo2 和 Circom 两类证明系统。2025 年 5 月发布的原生包支持 iOS 和 Android 端的直接证明生成。其典型集成模式：开发者用 Circom 或 Noir 编写电路，用 Mopro 的 generateProof() API 一行调用。Mopro 在 X 平台上有活跃的社区（@zkmopro），且已集成到多个生产级移动 ZK 钱包中。

3.4 基准数据：移动端证明的真实性能

根据 Fenbushi Capital 的 2025 年 8 月 zkVM 基准测试报告以及 Google 与社区公开数据：

平台	证明系统	电路规模	设备	证明时间	验证时间
Safari	Stwo (STARK)	2^18	M3 MacBook	1.2s	0.08s
Chrome	Stwo (STARK)	2^18	M3 MacBook	0.9s	0.07s
原生	Groth16	2^18	iPhone 16 Pro	32s	0.002s
原生	PLONK (NoirJS)	2^18	iPhone 16 Pro	12s	0.015s
Web	STARK (FRI)	2^18	M3 MacBook	4.5s	0.2s
Android	Nova 折叠	2^20 (递归累积)	S24 Ultra	8s/步	0.3s

核心结论：对于 < 2^18 门的电路（覆盖身份属性证明、邮件验证等典型场景），移动端/浏览器端的证明时间已进入 1-30 秒区间——满足生产可用性门槛。超过 2^20 门的电路（属于通用计算范围），仍建议使用服务器侧或折叠方案逐步累积。

第4章三大杀手级应用：zkTLS、zkEmail 与 Longfellow

「杀手级应用」一词在加密行业被过度使用。但对于客户端 ZK，这三大协议确实满足定义：它们在非共识的情况下找到了真实的、百万级用户的 PMF（Product-Market Fit）。

4.1 zkTLS：让 Web2 的 TLS 连接变为 ZK 可验证

zkTLS 解决的核心问题：你如何向第三方证明你在某个 Web2 网站上看到了一组数据，而不暴露该网站的 cookies 或完整的会话内容？

工作原理：zkTLS 的核心思想是「可证明的 TLS 会话捕获」。在一个标准的 TLS 1.3 连接中，客户端和服务端通过密钥交换协商一个共享的会话密钥。zkTLS 修改（或者说扩展）了这一过程：

握手阶段的公证：在 TLS 握手时，一个公证者（Notary）验证了服务器证书的真实性，并记录下握手指纹。
会话密钥的承诺：客户端生成了一个会话密钥的承诺（commitment），提交给公证者。公证者随后可以对 TLS 记录进行验证——但不接触明文数据。
应用层数据的 ZK 证明：客户端在应用层面截取 HTTP 响应，提取需要证明的字段（如「余额 12,500 美元」），对剩余内容进行哈希，生成一个 ZK 证明，证明「字段 X 是原始 TLS 解密数据的一部分且签名有效」。

主要实现：

TLSNotary：最早的 zkTLS 实现，基于 MPC 的方式——三方共同持有会话密钥碎片，无需信任任何一方。但部署复杂度高。
Reclaim Protocol：当前唯一的生产级 zkTLS 基础设施，支持 25+ 客户、30+ 链。提供浏览器插件和 Android SDK，用户可在移动设备本地生成证明。
Opacity Network：侧重电商场景的价格/订单证明，通过隐私计算层聚合。

zkTLS 的应用场景已经超出密码学爱好者的预期：欧盟身份钱包已将 Reclaim 集成为「跨平台信用证明方案」。

4.2 zkEmail：你不需要泄露整封邮件

如果说 zkTLS 解决了「Web2 页面数据的可验证性」，zkEmail 则针对邮件场景提供了更精细化的方案。

密码学基础：邮件安全依赖 DKIM（DomainKeys Identified Mail）签名。发送方服务器会对邮件正文的关键字段进行 RSA 签名，接收方可以通过 DNS 查询发送域的公钥来验证签名真实性。zkEmail 利用这个现成的信任链——直接在浏览器端验证 DKIM 签名，而不暴露邮件内容。

选择性披露：这是 zkEmail 的核心产品差异化。用户可以用 Noir 电路编写披露策略——比如「只披露 Offer 薪资字段」或「只证明邮件来自 @google.com 域」。浏览器中的 NoirJS 库读取邮件原始 MIME 内容，屏蔽未公开字段，生成只有一个公开输出的证明。

生产状态：截至 2026 年 7 月，zk.email 项目已在以太坊主网和多个 L2 上处理超过 18,000 笔真实证明。它被集成到链上信贷协议（如基于薪资的真实世界资产抵押）和 DeFi 身份认证场景。

4.3 Longfellow：Google 开源的身份 ZK 库

2025 年 7 月，Google 在博客上宣布开源其零知识证明库——Longfellow。这不是一个普通的开源项目，而是一个战略性的信号：全球最大的互联网公司认为 ZKP 已经成熟到可以进入身份基础设施。

技术细节：

基于 ISO mDOC（ISO 18013-5）标准——这是移动驾驶执照和数字身份的国际标准，被欧盟 eIDAS 2.0 框架采纳。
支持多类型的身份证明：JSON Web Token（JWT）、W3C 可验证凭证、ISO mDOC。
提供 ZKP 风格的属性证明——用户可以向验证者证明「我 ≥ 18 岁」，而不泄露出生日期。
IETF 草案：draft-google-cfrg-libzk 已于 2025 年 9 月提交，2026 年 3 月更新。

部署规模：Google 与 Sparkasse（德国储蓄银行联盟）合作，在 EUDI Wallet 项目中集成了 Longfellow。Phillips（飞利浦）在 2025 年末于荷兰医院试点中使用了 Longfellow 来验证医护人员的执业证书——由医护人员手机本地生成证明，医院终端无需联网验证。

Longfellow 清晰展示了客户端 ZK 的大规模部署路径：标准化先行，开源后发，集成到现有的身份基础设施中。

4.4 共同模式：客户端 ZK 的三个设计范式

从 zkTLS、zkEmail 到 Longfellow，三个看似不相关的协议背后，共享三个设计范式：

范式一：离线生成，在线验证。 证明生成发生在完全没有网络连接或网络受限的客户端上。验证方（智能合约或依赖方 SDK）独立验证，不需要与证明生成器通信。

范式二：服务器辅助但不信任。 客户端可能在证明过程中从外部服务器获取辅助数据（如 DKIM 公钥、TLS 证书链），但不将这些数据作为信任锚点。即使辅助服务器被攻破，生成的证明仍然有效——因为最终验证的是密码学签名，而非服务器的嘴。

范式三：黑盒化开发者体验。 这三个协议的最终 SDK 都将 ZK 细节封装在 3-5 行 API 调用之后。开发者不需要理解 PLONK、FRI 或多项式承诺——只需提供「输入」和「公开输出」的定义。这一设计是客户端 ZK 走向主流采用的前提条件。

flowchart TB
    subgraph zkTLS["zkTLS (Reclaim / TLSNotary)"]
        direction LR
        zkTLS_A["验证对象:\nTLS Session 请求/响应"] 
        zkTLS_B["生成位置:\n浏览器插件 / App"]
        zkTLS_C["验证方:\n智能合约 / Verifier API"]
        zkTLS_D["安全假设:\nNotary 仅公证 TLS 握手"]
    end
    
    subgraph zkEmail["zkEmail"]
        direction LR
        zkEmail_A["验证对象:\nDKIM 签名邮件"]
        zkEmail_B["生成位置:\n浏览器 NoirJS"]
        zkEmail_C["验证方:\n链上验证合约"]
        zkEmail_D["安全假设:\nDNS 公钥真实可用"]
    end
    
    subgraph Longfellow["Google Longfellow"]
        direction LR
        LF_A["验证对象:\nmDOC / JWT / W3C VC"]
        LF_B["生成位置:\nGoogle Wallet App"]
        LF_C["验证方:\nRelying Party SDK"]
        LF_D["安全假设:\n签发方公钥已预置"]
    end
    
    zkTLS --- zkEmail --- Longfellow

图3：客户端 ZK 三大协议的架构对比 — 三种协议的共同模式：证明在客户端生成，验证在服务端/链上完成。区别在于验证对象（TLS session vs DKIM 签名 vs mDOC 数字身份）和安全假设链（Notary 公证 vs DNS 公钥 vs 签发方预置信任）。

第5章移动端证明的竞争格局：框架与平台

客户端 ZK 的工具链正在快速成型。2026 年的竞争格局已不再是「谁能做」，而是「谁在哪个细分场景做得更好」。

5.1 Mopro：移动端 ZK 的「Kitchen Sink」

Mopro 是当前覆盖最广的移动端 ZK 框架。其核心定位：开发者用任意方案编写电路，Mopro 负责跨平台编译和原生运行。

支持的证明系统：

Groth16 + BN254（性能优先，但需 Trusted Setup）
PLONK + BLS12-381（透明设置，移动端性能适中）
Halo2（递归友好）

跨平台绑定：

Rust 核心（FFI）
Swift 绑定 → iOS / macOS
Kotlin 绑定 → Android
Dart 绑定 → Flutter 跨平台

关键指标（基于 Mopro v0.3.0, 2026 年 4 月）：

编译后 SDK 大小：iOS ~12 MB, Android ~8 MB（含标准电路）
典型证明时间（2^18 门 PLONK BLS12-381）：iPhone 15 Pro 约 18s, S24 Ultra 约 22s
内存峰值：约 1.2 GB

Mopro 的弱点是证明系统中性带来的重复抽象——如果只针对 Groth16 BN254 优化，性能可能只有专用实现的一半。但对于需要灵活切换证明系统的项目（如跨链身份协议），Mopro 的通用性使其成为首选。

5.2 EZKL：iOS 原生 ZK 先行者

EZKL 走的是「垂直集成」路线：不做通用 ZK 框架，而是专注于 ZK-ML（零知识机器学习）这一垂直场景。

核心竞争力：

从 ONNX 模型到 Halo2 电路的自动化编译管道——不需要开发者手动设计电路
iOS 原生 Swift 库（2025 年 1 月首发）
纯软件验证（不需 TEE）和 TEE 集成两种模式

受限于：

Halo2 证明生成时间长——在手机端跑中等规模的 ML 模型（约 2^22 门）需要耗时 3-4 分钟
仅支持有模型推理的场景——不适用于通用计算证明

EZKL 在 2025 年底获得了独立的密码学审计，成为首个获得审计通过的 ZK-ML 框架。对于需要「证明 AI 模型在敏感数据上推理」的场景（如医疗影像诊断、金融信用评分），它是当前唯一的成熟选择。

5.3 Noir 在客户端的定位

Noir 本身是电路 DSL，而非移动端框架。但它的客户端工具链（NoirJS、barretenberg.js）在浏览器端获得了意外广泛的采用。

优势：

开发者体验在电路 DSL 中最佳——熟悉 Rust 语法的开发者可零基础上手
生态丰富：已有 500+ 社区电路模块和库
ACIR 中间表示的跨后端能力（可编译到不同证明系统）

局限：

浏览器端的 Wasm 加载大小约 8 MB——对移动端应用偏大，但仍在可接受范围内
WebGPU 后端仍处于实验阶段
原生移动 SDK（Noir Mobile）仍在私人 beta 中

Noir 在 2026 年的定位更像是「电路开发层」而非「证明生成层」——开发者用 Noir 编写电路，然后选择 Mopro、ezkl 或自建 Wasm 绑定来交付到客户端。

5.4 RISC Zero 与 SP1 的移动端姿态

zkVM 路线的两个主力——RISC Zero 和 Succinct SP1——在客户端 ZK 场景中面对结构性挑战：

内存：zkVM 的完整证明需要在内存中加载整个程序的执行轨迹。RISC Zero 的 zkVM 在桌面端生成一个简单程序的证明（约 2^22 步）需要约 8 GB 内存。手机端即使压缩后，内存占用也在 2-4 GB——接近或达到手机内存上限（6-8 GB），且需要预留系统和其他应用空间。

替代方案：RISC Zero 的「Bonsai Pay-as-you-Go」API 允许客户端将计算负载上传到远程证明器——但这回到了「服务器侧证明」的老路，丢失了客户端 ZK 的核心价值。

积极信号：SP1 的团队在 2026 年初展示了在 M4 iPad Pro 上运行有限 zkVM 程序的论证——得益于 Apple Silicon 的统一内存架构（UMA），GPU 可以直接访问 CPU 缓冲区，避免数据搬运带来的延迟。但通用化仍需等待 zkVM 在移动端的内存使用量降低 2-3 倍。

flowchart TD
    START["需要客户端 ZK 证明？"] --> Q1["电路规模 ≤ 2^18 门？"]
    Q1 -->|"Yes"| Q2["需要通用计算？"]
    Q1 -->|"No"| Q3["需逐步递归累积？"]
    Q2 -->|"Yes"| VM["zkVM 路线\nRISC Zero / SP1\n注意内存限制"]
    Q2 -->|"No"| DSL["电路 DSL\nNoir / Circom\n+ Mopro 绑定"]
    Q3 -->|"Yes"| FOLD["折叠方案\nNova / SuperNova\n渐进式证明"]
    Q3 -->|"No"| ATTRIB["属性证明\nLongfellow / EZKL\n轻量 API"]
    VM --> CAUTION["⚠️ 当前 zkVM 在手机端\n内存占用 2-4 GB"]
    DSL --> CHECK["✅ 推荐路径\nMopro + Noir\n已验证生产级"]
    
    style START fill:#bbdefb
    style CHECK fill:#c8e6c9
    style CAUTION fill:#ffcdd2

图4：移动端框架选择决策树 — 根据电路规模和计算需求选择最合适的框架路径。Mopro + Noir 是当前风险最低、经过最多生产验证的推荐组合。

第6章真实案例：客户端 ZK 已经交付了什么

6.1 Google Wallet 的年龄验证——首个亿级用户规模的 ZK 部署

2025 年 7 月，Google 在其 Android 17 版本中更新了 Wallet 应用：用户可以将自己的 ISO mDOC 数字身份（来自 EUDI Wallet 合作伙伴）导入 Google Wallet，在需要验证年龄的网站（如酒类电商、内容分级平台）上，一键生成本地零知识证明。

技术细节：

证明系统：Longfellow 的实现使用了一种定制的 PLONKish 方案，底层多项式承诺采用 FRI 以保持透明性。
证明生成位置：手机本地 — 使用 Pixel 的 Titan M2 安全芯片处理部分密钥操作。
验证方：第三方网站的「Relying Party SDK」——一行 JavaScript 代码嵌入，即可接收和验证 Longfellow 证明。
用户交互：3 步点击（选择钱包→选择属性→确认披露），无需理解什么是 ZKP。

规模数据（截至 2026 年 6 月）：

覆盖国家：27 个欧盟成员国
每月活跃证明：约 310 万笔
平均证明生成时间：1.8 秒（Pixel 8 Pro）
首次实现 ZK 证明在真正的亿级消费者应用中落地

6.2 zkEmail 在 DeFi 信贷中的落地

2025 年底，基于 zkEmail 的链上信贷协议迎来了第一个增长突破期。核心模式：用户将薪资证明（来自企业发送的工资单邮件）提交给信贷合约，合约根据可验证的工资流水和雇佣信息，自动批准贷款额度。

技术架构：

邮件认证：zk.email 的浏览器库（基于 NoirJS）负责 DKIM 签名验证
选择性披露：用户在本地选择需要公开的字段（月薪、工作年限）
链上验证：证明提交到以太坊 L2（Arbitrum）上的验证合约，gas 消耗约 15k per verify
数据存储：证明可被链上合约直接验证，无需链下数据库

意义：zkEmail 展示了一个通用模式——任何以电子邮件为载体的可信数据，都可以通过客户端 ZK 转化为链上可验证凭证。这包括但不限于：工资单、银行账单、税务通知、学历证书。

6.3 zkTLS 驱动的「无信任 KYC」

Reclaim Protocol 与多家欧盟身份钱包集成，提供了 zkTLS 驱动的 KYC（客户身份识别）方案。与传统 KYC 的区别：

维度	传统 KYC	zkTLS KYC
数据提供方	用户上传证件照片	直接从源网站获取
隐私保护	KYC 供应商看到全部数据	仅公开必要字段
验证成本	$0.50-$ 2.00/次	约 $0.02/次
重复使用	每次重新提交	一次性生成后可复用
监管合规	符合传统 AML	符合 eIDAS 2.0 + ZKP 指南

截至 2026 年 7 月，Reclaim Protocol 已服务 25+ 客户，覆盖 30+ 条区块链。

6.4 供应链中的手机端产品溯源

一个常被忽视的场景：消费者在零售药店通过手机扫描药品包装上的 ZK 凭证，验证药品真伪——而不必将产品序列号暴露给任何第三方数据库。

密码学逻辑：制药企业在生产时将每瓶药的组成信息（批号、有效期、分销路径）签名到 ZK 凭证中。消费者在手机端下载该凭证的公开承诺，在药店的终端设备（手机/POS 机）上使用 Mopro 库验证签名和属性。

试点已在荷兰的 200 家药房中完成，覆盖 3 家制药企业的 15 个产品线。识别通过率 99.7%。

第7章挑战与前瞻：客户端 ZK 的边界在哪

7.1 物理天花板：手机 SoC 的多项式运算瓶颈

尽管客户端 ZK 的进展显著，但移动端 SoC 的物理限制是一个不可忽视的上限。

ARM SVE 的可伸缩向量处理：ARM v9.2/AArch64 的 SVE（可伸缩向量扩展）支持 128-2048 bit 可变长度向量。理论上，对于域乘法这类规则运算，SVE 可以提供远超 NEON 128-bit SIMD 的吞吐量。但实际中，SVE 的编译器支持仍有限——LLVM 的 SVE 自动向量化在 2026 年 LTS 版本中仍处于「实验性」阶段，人工调优是必备技能。

统一内存带宽：Apple Silicon 的 UMA（统一内存架构）一方面消除了 CPU-GPU 之间的数据迁移成本，另一方面意味着 GPU 证明器和 CPU 应用共享同一内存带宽。当手机运行证明器 + 相机或游戏时，内存带宽抢用可能导致整体性能滑坡。

电池消耗：假设一个 2^18 门的 STARK 证明在手机端消耗约 200-400 mWh——相当于观看 1-2 分钟的 YouTube 视频。对于单次身份证明，这可以接受；但对于高频证明场景（如实时位置隐私验证），电池成为新瓶颈。

7.2 安全气囊：TEE + ZK 混合部署

在纯密码学的 ZKP 无法覆盖的领域——比如「证明生成过程中输入数据不被侧信道泄漏」——TEE（可信执行环境）可以作为补充。

当前方案：

Intel TDX：服务器端但值得关注。Intel 的 TDX 扩展在 2025 年获得了 NIST 认证，为证明生成过程提供了硬件级隔离。
ARM CCA（机密计算架构）：ARM v9.2 的 CCA 为手机端 TEE 铺平了道路。Realm 模式允许用户在手机本地创建一个隔离环境，在其中运行证明生成逻辑，即使操作系统被攻破，证明的输入也不会泄漏。

混合模型：敏感输入在 TEE 中处理生成中间表示，中间表示再在常规环境中完成 ZK 证明生成。这个模型兼顾了「安全」和「性能」，但增加了 TCB（可信计算基）的复杂性——开发者需要同时理解和审计 TEE 和 ZKP 两套系统。

7.3 标准化仍在路上

客户端 ZK 的标准化有两个重要的推进维度：

W3C WebGPU：WebGPU 在 2025 年进入候选推荐阶段（Candidate Recommendation），2026 年被所有主流浏览器（Chrome、Edge、Firefox、Safari）实现。但 WebGPU 的 ZK 优化 API——如 GPU-side 的域算术原语——需要新的 WebGPU 扩展提案。预计 2027 年才有正式的 ZK WGSL 扩展标准。

ZKProof 移动端工作组：ZKProof 标准化组织在 2025 年底成立了移动端专项工作组，成员包括 Google（Longfellow 团队）、Consensys（zk.email 团队）、PSE（ZK 教育）、Mopro 核心开发者。工作组的第一份建议草案（推荐在手机端使用 FRI 承诺 + PLONKish 架构）在 2026 年 3 月发布。

7.4 2027 预测：客户端 ZK 的三阶段路径

阶段	时间	特征	代表应用
属性证明	2025-2026（当前）	小规模电路，仅属性披露	Longfellow 年龄验证、zkEmail 薪资证明
有限计算证明	2027	中等规模电路，结构化计算证明	移动端 A/B 测试的 ZK 报告、手机端合规审计
通用计算证明	2028+	大规模电路，任意程序 ZK 化	手机端执行复杂合约的 zkVM 证明

为什么乐观？ 三条独立的技术曲线在同时进步：① 证明系统本身的性能每年改善约 2-3x（更高效的多项式承诺、折叠方案优化）；② 移动端 SoC 的算力仍符合摩尔定律的余波（年增约 20-30%）；③ 工具链的成熟度指数级增长（更多抽象层、更好的编译器、更高的复用率）。三条曲线叠加，使「通用计算在手机上证明」从 2028 年可能触手可及。

参考文献

Wavect, "Zero-Knowledge Proofs in 2026: What Is Actually Production-Ready", 2026. https://wavect.io/blog/zero-knowledge-proofs-production-2026 （客户端 ZK 全景、移动端基准数据、zkVM 性能比较）
Google / Longfellow ZK Library, 2025. https://github.com/google/longfellow-zk https://google.github.io/longfellow-zk https://datatracker.ietf.org/doc/draft-google-cfrg-libzk/ （Longfellow 规范、开源源码、IETF 草案）
Google Safety Engineering Center, "Opening up Zero-Knowledge Proof technology to promote privacy in age assurance", Jul 2025. https://blog.google/innovation-and-ai/technology/safety-security/opening-up-zero-knowledge-proof-technology-to-promote-privacy-in-age-assurance/ （Google 开源 ZKP 宣告与 EUDI Wallet 合作）
zkSecurity, "Accelerating ZK Proving with WebGPU: Techniques and Implementation", 2026. https://blog.zksecurity.xyz/posts/webgpu （WebGPU 加速 Stwo 证明器的技术详解与基准数据）
zk.email 项目, 2026. https://zk.email （客户端 ZK 邮件验证的生产级实现，选择性披露）
EZKL, "Bringing Zero-Knowledge Proofs to Mobile", Jan 2025. https://blog.ezkl.xyz/post/ios （EZKL iOS 原生库发布与 ONNX→ZK 电路管道）
Mopro (zkmopro), 2025-2026. https://github.com/zkmopro/mopro https://zkmopro.org/blog/noir-integraion （移动端 ZK 跨平台工具包、Noir 集成方案）
Fenbushi Capital, "zkVM Benchmarking Report", Aug 2025. （八个 zkVM 的独立基准测试，涵盖 RISC Zero/SP1/OpenVM）
Reclaim Protocol, 2026. https://reclaimprotocol.org （生产级 zkTLS 基础设施、30+ 链集成）
Ethereum Foundation, "Real-Time Proving Goals", Jul 2025. https://ethproofs.org （10s/99% 区块的实时证明目标）
zkSecurity, "WebGPU Meets Zero-Knowledge: Can Browser-Based Proving Finally Work?", 2026. https://www.webgpu.com/news/zk-proofs-webgpu-boost （WebGPU + Stwo 的 5x NTT 加速验证）
ISO 18013-5:2021, "Personal identification — ISO-compliant driving licence", 2021. （mDOC 数字身份标准）

免责声明：本文所有代码示例和密码学描述仅供演示用途，不构成审计级安全建议。实际部署前请进行独立安全审核。

零知识证明专题第12期：客户端 ZK 与轻量证明——从服务器到手机的架构重构

本页目录

第1章入口：从数据中心到用户口袋

1.1 一个手机上的证明是如何诞生的

1.2 服务器侧证明的隐性成本

1.3 当 ZK 遇见移动端：三种需求场景

第2章轻量证明系统：密码学层面的可行性

2.1 为什么 Groth16 不适合手机？

2.2 PLONKish 体系的验证器优化

2.3 IOP + 抗运算哈希的组合优势

2.4 Nova 折叠在移动端的前景

第3章 WASM + WebGPU：浏览器变身为证明引擎

3.1 WebAssembly 3.0 的 SIMD 指令对有限域运算的加速

3.2 WebGPU 的 GPU 并行证明：从理论到实践

3.3 工具链成熟度：NoirJS、ezkl、mopro

3.4 基准数据：移动端证明的真实性能

第4章三大杀手级应用：zkTLS、zkEmail 与 Longfellow

4.1 zkTLS：让 Web2 的 TLS 连接变为 ZK 可验证

4.2 zkEmail：你不需要泄露整封邮件

4.3 Longfellow：Google 开源的身份 ZK 库

4.4 共同模式：客户端 ZK 的三个设计范式

第5章移动端证明的竞争格局：框架与平台

5.1 Mopro：移动端 ZK 的「Kitchen Sink」

5.2 EZKL：iOS 原生 ZK 先行者

5.3 Noir 在客户端的定位

5.4 RISC Zero 与 SP1 的移动端姿态

第6章真实案例：客户端 ZK 已经交付了什么

6.1 Google Wallet 的年龄验证——首个亿级用户规模的 ZK 部署

6.2 zkEmail 在 DeFi 信贷中的落地

6.3 zkTLS 驱动的「无信任 KYC」

6.4 供应链中的手机端产品溯源

第7章挑战与前瞻：客户端 ZK 的边界在哪

7.1 物理天花板：手机 SoC 的多项式运算瓶颈

7.2 安全气囊：TEE + ZK 混合部署

7.3 标准化仍在路上

7.4 2027 预测：客户端 ZK 的三阶段路径

参考文献

延伸阅读

评论

发表评论

零知识证明专题第12期：客户端 ZK 与轻量证明——从服务器到手机的架构重构

本页目录

第1章 入口：从数据中心到用户口袋

1.1 一个手机上的证明是如何诞生的

1.2 服务器侧证明的隐性成本

1.3 当 ZK 遇见移动端：三种需求场景

第2章 轻量证明系统：密码学层面的可行性

2.1 为什么 Groth16 不适合手机？

2.2 PLONKish 体系的验证器优化

2.3 IOP + 抗运算哈希的组合优势

2.4 Nova 折叠在移动端的前景

第3章 WASM + WebGPU：浏览器变身为证明引擎

3.1 WebAssembly 3.0 的 SIMD 指令对有限域运算的加速

3.2 WebGPU 的 GPU 并行证明：从理论到实践

3.3 工具链成熟度：NoirJS、ezkl、mopro

3.4 基准数据：移动端证明的真实性能

第4章 三大杀手级应用：zkTLS、zkEmail 与 Longfellow

4.1 zkTLS：让 Web2 的 TLS 连接变为 ZK 可验证

4.2 zkEmail：你不需要泄露整封邮件

4.3 Longfellow：Google 开源的身份 ZK 库

4.4 共同模式：客户端 ZK 的三个设计范式

第5章 移动端证明的竞争格局：框架与平台

5.1 Mopro：移动端 ZK 的「Kitchen Sink」

5.2 EZKL：iOS 原生 ZK 先行者

5.3 Noir 在客户端的定位

5.4 RISC Zero 与 SP1 的移动端姿态

第6章 真实案例：客户端 ZK 已经交付了什么

6.1 Google Wallet 的年龄验证——首个亿级用户规模的 ZK 部署

6.2 zkEmail 在 DeFi 信贷中的落地

6.3 zkTLS 驱动的「无信任 KYC」

6.4 供应链中的手机端产品溯源

第7章 挑战与前瞻：客户端 ZK 的边界在哪

7.1 物理天花板：手机 SoC 的多项式运算瓶颈

7.2 安全气囊：TEE + ZK 混合部署

7.3 标准化仍在路上

7.4 2027 预测：客户端 ZK 的三阶段路径

参考文献

延伸阅读

评论

发表评论

第1章入口：从数据中心到用户口袋

第2章轻量证明系统：密码学层面的可行性

第4章三大杀手级应用：zkTLS、zkEmail 与 Longfellow

第5章移动端证明的竞争格局：框架与平台

第6章真实案例：客户端 ZK 已经交付了什么

第7章挑战与前瞻：客户端 ZK 的边界在哪