0. KZG 仪式简介

a) Rollup 的数据可用性

Layer2 Rollups 大大扩展了以太坊的整体吞吐量和区块空间, 使以太坊能够容纳更多交易.

L2 Rollups 的核心是需要使用以太坊的 Layer1 区块空间进行数据分发 (L2 交易数据或状态差异), 称为 “数据可用性”. 数据可用性保证了 Optimistic Rollups 的安全性 ( 需要数据可用来进行挑战 ) 以及 Optimistic Rollups 和 ZK Rollups 的实时性 ( 需要数据可用来重构状态 ).

b) Danksharding

为满足 Rollups 的数据可用性要求, 以太坊引入了一个新的数据层 (EIP-4844 Proto-danksharding → Danksharding), 允许验证者仅临时存储 Rollup 数据.

这样的设计可以同时带宽更高和定价模型更好的情况下满足 Rollups 的需求, 对 L1 的正常交易影响较小, 并且还可以确保 L1 验证者的硬件要求不过高, 从而确保去中心化.

c) KZG

为了实现这样的机制, 快速证明和验证底层数据的一个关键组件是多项式承诺. 最符合条件的多项式承诺方案是 KZG 承诺 (KZG commitments).

KZG 在零知识证明系统中也被广泛使用. 在 Danksharding 和 ZK 系统之间, KZG 承诺的一个有趣的区别是 Danksharding 同时运行许多小型多项式承诺, 而 ZK 系统则是少量但较大的多项式.

根据 EIP-4844, KZG 是一个高效的向量承诺方案, 具有固定大小的证明数据, 并且与数据可用性采样具有前向兼容性. 这些承诺方案在完整的 “Danksharding” 提案中使用相同的基础结构.

d) KZG 仪式

KZG 方案通过在一个秘密值 ( 具体来说, 是一个椭圆曲线点 ) 处对多项式进行评估来进行承诺. 简单地说, 使用 KZG 需要一个秘密值, 而这个值应该通过一个 “仪式” (ceremony) 生成.

“仪式” 通常也称为 “可信设置” (Trusted Setup). 仪式的目的是构建一个任何人都无法完全掌握的秘密值. 只要至少有一方销毁了手中的随机数 — 在可信设置仪式中，偏执是一种美德 — 整个仪式就是有效的.

也许你会想, 既然使用 KZG 需要额外的可信设置, 为什么不使用不需要可信设置的承诺方案呢？因为使用其他方案会导致功能丧失和复杂性增加, 这些缺陷远远超过 KZG 本身的风险 ( 包括可信设置 ).

总结一下, 对于 Proto-danksharding 和 Danksharding 要运行的 KZG 方案, KZG 仪式是一个前提条件. KZG 仪式将生成 KZG 的秘密值.

1. KZG 仪式客户端实现

a) KZG 仪式总览

在 KZG 仪式中, 有三个主要角色:

• Sequencer ( 排序器 ): 充当交互的公共设施并验证贡献.
• Client ( 客户端 ): 向排序器提交贡献.
• User ( 用户 ): 为客户端生成用于贡献的随机性.

整体流程如下图所示. 请注意, 为了演示目的, 可能有很多细节被故意省略了.

b) 现有实现

KZG 仪式客户端的实现可以使用不同的编程语言和底层 BLS 库. 目前, 除了以太坊基金会提供的实现之外, 我们还有非常广泛的其他实现.

每个客户端都使用自己的特殊代码和对规范的理解来实现相同的规范, 并使用不同的底层库和技术解决方案. 那么, 为什么我们需要这么多不同的客户端实现方式呢?

c) 实现中的多样性

一个仪式需要防止泄漏随机性的单点故障, 不仅通过让更多的人参与仪式, 还要确保客户端的多样性, 以确保没有单一的软件错误导致失败.

正如我们希望确保以太坊客户端的多样性一样, 特别是执行客户端. 拥有在不同编程语言和技术堆栈上构建的多个客户端, 有以下两个主要好处:

• 更好的去中心化: 防范单个客户端的故障.
• 更多功能: 为用户提供不同特性和技术堆栈的选择.

2. 基于 Halo2 的 Hyper Oracle KZG 仪式客户端

a) 简介

Hyper Oracle 非常自豪地为 KZG 仪式的客户端多样性做出贡献. 我们完成了基于 Halo2 的 KZG 仪式客户端, 并借助以太坊基金会的 KZG 仪式资助, 提供了一种额外的验证仪式贡献的方法.

通过 Hyper Oracle 开发的 KZG 仪式客户端和新的通过零知识证明 (ZKP) 验证贡献的方法, 整个 KZG 仪式贡献过程可以实现如下:

我们的工作为 KZG Ceremony 的两个重要组成部分做出了贡献: 客户端和排序器。

• hyperoracle/kzg_ceremony_halo2: 用随机字符串为 KZG 仪式进行贡献 + 生成贡献过程的 zk 证明

• hyperoracle/kzg-ceremony-sequencer: 排序者除了以正常方式验证贡献外, 还可以验证贡献的 zk 证明.

你可以在我们的开源软件仓库中找到代码并尝试运行客户端, 为 KZG 仪式进行贡献并生成 ZKP.

b) 优点

我们的客户端有两大优势, 即多样性和可验证性.

多样性

我们实施方案的特别之处在于:

• Rust: 我们使用 Rust 编写了该客户端, 它也是公开资料中唯一的 Rust CLI 客户端.
• Halo2: 我们使用 Halo2 (Rust 语言的常用 ZK 框架 ), 这意味着我们的客户端有能力生成 zk 证明.

我们的 KZG Ceremony Client 使用最 “多样化” 的 Rust 语言, 甚至使用了连以太坊基金会都没想到的 Halo2 框架.

可验证性

通过我们所选的技术堆栈, Halo2 允许我们在生成计算证明的同时执行常见的计算. 正如我们之前描述的, 我们可以生成 “贡献证明” (Proof of Contribution), 修改后的排序器可以在不检查计算本身的情况下验证 “贡献证明”.

在几乎所有情况下, 可信设置或仪式客户端的贡献验证都发生在链下环境中. 我们的实现使任何参与方都可以更快、更可信地验证零知识证明, 从而更好地表示计算的有效性.

此外, 这也为直接在链上验证 “KZG 仪式贡献证明” 打开了可能性. 然而, 重要的是, 目前这是不可能的, 并且在未来实现这一目标之前需要进行大量优化, 以确保其可行性和经济性.

c) 未来改进

由于计算本身的计算量非常大, 而 zk 的证明生成又进一步增加了这种挑战, 因此我们在实现过程中仍然会遇到证明生成延迟和证明大小的问题.

• 证明生成时间: 我们通过拆分电路和大量优化来实现这种计算密集型的证明生成. 为了使证明生成时间满足特殊贡献的要求, 甚至在未来实现小到 128 秒的正常贡献阶段的证明生成时间, 我们仍然需要通过 GPU 加速或更多方式来提高性能.
• 证明大小: 即使在 KZG 仪式定序器中, 我们也需要进行特殊的调整, 才能让定序器成功验证最终的零知识证明. 尽管有可能在链上直接验证证明, 但由于最终生成的证明加起来体积庞大 ( 以兆字节为单位 ), 链上直接验证的成本过高.

3. 为以太坊贡献

在完成构建后, 我们通过 Hyper Oracle KZG 仪式客户端向 KZG 仪式做出了贡献, 并在生产中生成了相关的 ZKP. 证明和贡献数据已上传至我们的 repo.

我们希望用户可以体验我们的 kzg_ceremony_halo2 实现, 自行将他们的贡献添加到以太坊 KZG 仪式中, 以构建一个更加多样化和去中心化的以太坊. 我们也希望开发者能从这个客户端多样性的例子中得到启发.

以太坊基金会高度重视我们的开发和仪式贡献. “[Hyper Oracle 的]提议让我们感到惊讶, 因为我们真的没有考虑过使用通用 SNARK 来证明贡献 ( 序列器验证的本质上是一个特殊用途的 SNARK). 你们能做到这一点, 非常了不起”. 我们再次非常感谢以太坊基金会在我们开发过程中的沟通和讨论以及 grant 支持.

在 Twitter 上关注我们并加入我们的 Discord, 以了解 Hyper Oracle 的最新情况. 在我们的网站上了解更多关于 Hyper Oracle 的信息.