在浏览器中生成零知识证明, 今天就可以

Lauri Peltonen
发布于 7小时前
阅读 37

本文介绍了在浏览器中使用零知识证明（ZK）技术以保护用户数据隐私的方法。通过在浏览器中生成证明，用户可以在不将敏感数据发送到服务器的情况下，证明他们满足某些条件。文章还比较了目前可用的几种在浏览器中生成ZK证明的方案，并讨论了选择合适方案时需要考虑的因素。

零知识 (ZK) 技术为数据隐私提供了新的选择。 通过 ZK，用户可以选择公开共享哪些数据，并将其余数据保留在他们的机器上。

一些 ZK 系统允许直接在用户的浏览器中生成证明。 本文解释了为什么这通常是可取的，以及今天存在哪些选择。

## 隐私不是 ZK 问题

如果用户自愿将其数据发送到中心化服务，那么再呼唤花哨的密码学来帮忙也就没有意义了。 如果你不正确地使用技术，技术就帮不上忙。

![](https://img.learnblockchain.cn/2026/01/14/1K5vTZRkDhSB5b45kr_LGKA.png)

ZK 在保护你的私有数据方面具有巨大的潜力，但它必须在数据离开你自己的计算机之前应用。 你在计算机上使用最多的应用程序是什么？

## 你的浏览器传输你的敏感数据

你可能正在使用你的浏览器，甚至是为了阅读本文。 你在网上使用的大多数服务都是网站。 这也是你的大部分私有数据被发送到的地方。

因此，加强隐私的逻辑地点是在你的浏览器内部。 目标是尽量减少数据泄漏。

## 发送证明而不是数据

大多数网站不需要用户数据：它们只需要确信你拥有这些数据，并且它符合某些标准。

一些例子：

- 金融机构想知道你的薪水是否足以获得贷款。
- 网站想知道你是否已达到某个年龄才能允许进入。
- 网络游戏想确保你还有剩余的生命值可以继续玩。

这些都可以用 ZK 来证明。 实际数据永远不需要离开你的计算机。 你只需提交它的证明。

## 在浏览器中进行证明的可能性

浏览器不仅仅用于滚动浏览网站。 它们实际上也可以执行相当多的计算。

![](https://img.learnblockchain.cn/2026/01/14/1prNF4sAgU0xKjk4T7PovBA.png)

另一方面，浏览器具有非常明确的、经过深思熟虑的限制。 它们的内存使用受到限制，它们几乎无法访问底层操作系统，并且只能利用计算机处理能力的一部分。

许多现有的 ZK 系统假设的资源比浏览器可以提供的更多。 因此，只有一小部分系统实际上与浏览器兼容。

## 浏览器的适配器

仅靠 JavaScript 通常对于生成证明来说效率太低。 因此，证明项目利用各种适配器在浏览器环境中生成证明。

这些适配器通常是将证明系统编译为 WebAssembly (WASM)。 然后，这个 WASM 可以由 JavaScript 包装器执行。

## 有哪些选择

大多数证明系统的设计都没有考虑到浏览器的限制。 一些值得注意的例外情况存在，而另一些则主要是由于其资源配置文件而与浏览器兼容。

目前可用的主要选项是：

1. [Circom](https://github.com/iden3/circom) -> [snarkjs](https://github.com/iden3/snarkjs) 库 -> Groth16 证明
2. [Noir](https://noir-lang.org/) -> [Barretenberg](https://github.com/AztecProtocol/barretenberg) (BB) 库 -> Honk 证明
3. Rust -> [Halo2 JS](https://github.com/axiom-crypto/halo2-browser) 库 -> Halo2 证明
4. Rust -> [Ligetron](https://github.com/ligeroinc/ligero-prover) 库 -> Ligetron 证明

下面将更详细地解释这些内容。

### Circom -> snarkjs -> Groth16

Circom 是一种已建立的 ZK 语言，尽管它相当底层。

```
// Circom 代码示例（需要安装 Circom 编译器才能运行）
pragma circom 2.0.0;

template Multiplier2 () {
   signal input a;
   signal input b;
   signal output c;

c <== a * b;
}

component main {public [a,b]} = Multiplier2();
```

Groth16 也是一个已建立的证明系统。 它以其小的证明大小、快速的证明者和快速的验证而闻名，但同时也以其精心设计的 trusted setup 而闻名。

### Noir -> BB -> Honk

Noir 是一种较新的 ZK 语言，它基于 Rust。 由于其类似 Rust 的语法，它通常比 Circom 更容易学习。

```rust
// Noir 代码示例
fn main(private x: Field, private y: Field) -> pub Field {
    const z = 5;
    let a = x * y;
    let b = a + z;
    b
}
```

对于大型 ZK 程序来说，Honk 风格的证明是最好的。 对于中小型程序来说，它们比 Groth16 慢且大，但旨在为更大的电路发光。

用于生成 Plonk 证明的 Barretenberg (BB) 证明引擎曾经能够生成更小且验证成本更低的 Plonk 证明，但此功能已 [deprecated](https://x.com/rel_zeta_tech/status/1998728113065210101)。

### Rust -> Halo2

理论上，编写 Rust 比其他 ZK 专用语言（如 Circom 或 Noir）容易得多。 这是这个选项的闪光点。

Halo2 有几个版本（[1](https://github.com/zcash/halo2), [2](https://github.com/privacy-ethereum/halo2)），每个版本都有不同的权衡。

### Rust -> Ligetron

Ligetron 优先考虑低内存使用和可预测的执行，这使其更适合浏览器环境。

Ligetron 程序可以用 Rust 编写。

## 比较

没有普遍的最佳选择； 选择取决于哪些约束对于你的应用程序最重要。

下表比较了以下功能：

- Prover 速度：在浏览器中生成证明的速度和效率。
- 验证性能：证明有多小，验证效率有多高。 如果你想在链上验证证明，这尤其重要。
- JS 大小：用户在证明之前必须下载的 JavaScript 工件的大小。 通常，对于库来说，这只有几 MB。
- Trusted setup：是否需要 **可信** 设置。 通用的 **可信** 设置比完整的 **可信** 设置更容易建立。

用于比较的一些参考文献：[1](https://rohanv.me/papers/GenomeVault_ZK_Guide.html), [2](https://github.com/babybear-labs/benchmark) 和 [3](https://hashcloak.github.io/semaphore-noir-final-report/benchmarks.html)。

### 免责声明

以上比较必然是简化的。 零知识证明系统针对不同的目标进行了优化，它们的相对性能在很大程度上取决于优化的目标。

在没有硬性基准数据的情况下，比较是通过与其他 ZK 专家的讨论得出的。 这些应该被理解为方向性指导，而不是绝对排名。

## 如何选择

选择正确的证明系统很难。 在做出决定之前，你需要了解项目的需求，例如：

- 你需要在链上验证证明吗？
- 你对 **可信** 设置满意吗？
- 你的 Prover 程序会变得多么复杂？
- 证明过程需要多长时间，用户愿意等待多长时间？
- 是否期望用户在移动设备或台式机上运行 Prover 过程？ 如今，移动浏览器证明在某种程度上是不切实际的。

此外，你必须非常确定你的项目实际上需要在浏览器中进行证明。 如果没有这个要求，你将有更多的选择。

## 结论

如果项目需要强大的隐私性，那么在用户的浏览器中生成 ZK 证明可能是正确的选择。 它允许敏感数据保留在用户的机器上，而不是发送到服务器。

集成 ZK 证明并非易事，需要仔细的系统设计。 但是，如果做得正确，浏览器端证明能够实现原本难以或无法实现的隐私保证。

感谢 L2beat 的 [Sergey](https://x.com/sergeyshemyakov) 审阅本文并提供宝贵的反馈。

我是一名 ZK & Solidity 自由职业者。 我主要从事开发和写作关于 [零知识主题和生态系统](https://medium.com/@laurippeltonen) 的文章。

>- 原文链接： [medium.com/@laurippelton...](https://medium.com/@laurippeltonen/generating-zk-proofs-in-browser-today-7d3fac01c34c)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

零知识 (ZK) 技术为数据隐私提供了新的选择。通过 ZK，用户可以选择公开共享哪些数据，并将其余数据保留在他们的机器上。

一些 ZK 系统允许直接在用户的浏览器中生成证明。本文解释了为什么这通常是可取的，以及今天存在哪些选择。

隐私不是 ZK 问题

如果用户自愿将其数据发送到中心化服务，那么再呼唤花哨的密码学来帮忙也就没有意义了。如果你不正确地使用技术，技术就帮不上忙。

ZK 在保护你的私有数据方面具有巨大的潜力，但它必须在数据离开你自己的计算机之前应用。你在计算机上使用最多的应用程序是什么？

你的浏览器传输你的敏感数据

你可能正在使用你的浏览器，甚至是为了阅读本文。你在网上使用的大多数服务都是网站。这也是你的大部分私有数据被发送到的地方。

因此，加强隐私的逻辑地点是在你的浏览器内部。目标是尽量减少数据泄漏。

发送证明而不是数据

大多数网站不需要用户数据：它们只需要确信你拥有这些数据，并且它符合某些标准。

一些例子：

金融机构想知道你的薪水是否足以获得贷款。
网站想知道你是否已达到某个年龄才能允许进入。
网络游戏想确保你还有剩余的生命值可以继续玩。

这些都可以用 ZK 来证明。实际数据永远不需要离开你的计算机。你只需提交它的证明。

在浏览器中进行证明的可能性

浏览器不仅仅用于滚动浏览网站。它们实际上也可以执行相当多的计算。

另一方面，浏览器具有非常明确的、经过深思熟虑的限制。它们的内存使用受到限制，它们几乎无法访问底层操作系统，并且只能利用计算机处理能力的一部分。

许多现有的 ZK 系统假设的资源比浏览器可以提供的更多。因此，只有一小部分系统实际上与浏览器兼容。

浏览器的适配器

仅靠 JavaScript 通常对于生成证明来说效率太低。因此，证明项目利用各种适配器在浏览器环境中生成证明。

这些适配器通常是将证明系统编译为 WebAssembly (WASM)。然后，这个 WASM 可以由 JavaScript 包装器执行。

有哪些选择

大多数证明系统的设计都没有考虑到浏览器的限制。一些值得注意的例外情况存在，而另一些则主要是由于其资源配置文件而与浏览器兼容。

目前可用的主要选项是：

Circom -> snarkjs 库 -> Groth16 证明
Noir -> Barretenberg (BB) 库 -> Honk 证明
Rust -> Halo2 JS 库 -> Halo2 证明
Rust -> Ligetron 库 -> Ligetron 证明

下面将更详细地解释这些内容。

Circom -> snarkjs -> Groth16

Circom 是一种已建立的 ZK 语言，尽管它相当底层。

// Circom 代码示例（需要安装 Circom 编译器才能运行）
pragma circom 2.0.0;

template Multiplier2 () {
   signal input a;
   signal input b;
   signal output c;

   c &lt;== a * b;
}

component main {public [a,b]} = Multiplier2();

Groth16 也是一个已建立的证明系统。它以其小的证明大小、快速的证明者和快速的验证而闻名，但同时也以其精心设计的 trusted setup 而闻名。

Noir -> BB -> Honk

Noir 是一种较新的 ZK 语言，它基于 Rust。由于其类似 Rust 的语法，它通常比 Circom 更容易学习。

// Noir 代码示例
fn main(private x: Field, private y: Field) -> pub Field {
    const z = 5;
    let a = x * y;
    let b = a + z;
    b
}

对于大型 ZK 程序来说，Honk 风格的证明是最好的。对于中小型程序来说，它们比 Groth16 慢且大，但旨在为更大的电路发光。

用于生成 Plonk 证明的 Barretenberg (BB) 证明引擎曾经能够生成更小且验证成本更低的 Plonk 证明，但此功能已 deprecated。

Rust -> Halo2

理论上，编写 Rust 比其他 ZK 专用语言（如 Circom 或 Noir）容易得多。这是这个选项的闪光点。

Halo2 有几个版本（1, 2），每个版本都有不同的权衡。

Rust -> Ligetron

Ligetron 优先考虑低内存使用和可预测的执行，这使其更适合浏览器环境。

Ligetron 程序可以用 Rust 编写。

比较

没有普遍的最佳选择；选择取决于哪些约束对于你的应用程序最重要。

下表比较了以下功能：

Prover 速度：在浏览器中生成证明的速度和效率。
验证性能：证明有多小，验证效率有多高。如果你想在链上验证证明，这尤其重要。
JS 大小：用户在证明之前必须下载的 JavaScript 工件的大小。通常，对于库来说，这只有几 MB。
Trusted setup：是否需要可信设置。通用的可信设置比完整的可信设置更容易建立。

用于比较的一些参考文献：1, 2 和 3。

免责声明

以上比较必然是简化的。零知识证明系统针对不同的目标进行了优化，它们的相对性能在很大程度上取决于优化的目标。

在没有硬性基准数据的情况下，比较是通过与其他 ZK 专家的讨论得出的。这些应该被理解为方向性指导，而不是绝对排名。

如何选择

选择正确的证明系统很难。在做出决定之前，你需要了解项目的需求，例如：

你需要在链上验证证明吗？
你对可信设置满意吗？
你的 Prover 程序会变得多么复杂？
证明过程需要多长时间，用户愿意等待多长时间？
是否期望用户在移动设备或台式机上运行 Prover 过程？如今，移动浏览器证明在某种程度上是不切实际的。

此外，你必须非常确定你的项目实际上需要在浏览器中进行证明。如果没有这个要求，你将有更多的选择。

结论

如果项目需要强大的隐私性，那么在用户的浏览器中生成 ZK 证明可能是正确的选择。它允许敏感数据保留在用户的机器上，而不是发送到服务器。

集成 ZK 证明并非易事，需要仔细的系统设计。但是，如果做得正确，浏览器端证明能够实现原本难以或无法实现的隐私保证。

感谢 L2beat 的 Sergey 审阅本文并提供宝贵的反馈。

我是一名 ZK & Solidity 自由职业者。我主要从事开发和写作关于零知识主题和生态系统的文章。

原文链接： medium.com/@laurippelton...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

翻译
学分: 2
分类: 密码学
标签: 零知识证明 zk 浏览器隐私保护 WebAssembly snarkjs circom Halo2 Ligetron Noir Barretenberg Honk

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。