Taiko 的多重证明方法

Taiko 实现多重证明的方法

本文由 Taiko 的 ZK 工程师 CeciliaZ_ 撰写。

不久前，我们分享了一篇题为《为什么多重证明很重要》的详细文章，解释了多重证明的意义，并将 SGX 作为多重证明的选项之一。这篇文章的灵感来自于我们与 Vitalik 的 X (Twitter) space 以及他随后发表的 博客文章，其中介绍了 Taiko 关于多重证明的总体路线图：它与最终目标有何关系，我们的愿景是什么，以及我们将如何实现它。

我们认为，ZK 中的多重证明转化为用多个 SNARK 编译的多个客户端，这将为未来以太坊 L1 中的 SNARKed 客户端多样性奠定基础。为了非常简要地说明多重证明的理由，我们应该提到两点：

• 多重证明方法可以对冲客户端实现和证明系统中错误和漏洞的风险。那么，如果出现错误，即使一个证明被破坏，其他证明也不太可能允许利用完全相同的漏洞。

• 以太坊的最终目标是 ZK 证明 L1 区块。

来源：https://twitter.com/vitalikbuterin/status/1741190491578810445。

类似于以太坊的 多客户端方法，它已经多次将网络从崩溃中拯救出来，证明 L1 区块将需要一种多重证明方法。对于 ZK 和非 ZK 场景，这意味着多客户端 + 各种证明系统。

多客户端系统和 L1 最终目标

正如 Vitalik 在他的文章 ““嵌入的 ZK-EVM”可能是什么样子？” 中描述的那样，多客户端系统有两种方法：“开放”与“封闭”。

在一个封闭的多客户端系统中，协议内已知一组固定的证明，并“列入白名单”以生成证明。所有 ZK L2 都遵循他的分类的“封闭”模式，因为它们只接受他们自己实现的证明。

在一个开放的多客户端系统中，证明被放置在“区块之外”，并由客户端单独验证。单个用户可以使用他们想要的任何客户端来验证区块。

在一种简单的情况下，他们会使用所需的客户端重新执行该区块，或者他们可以从一些证明者那里查询执行的有效性证明。如果看到的有效证明数量超过预期，用户就会相信。但是，如果没有“列入白名单”的 ZKP，并且我们想要避免重新执行，那么我们实际上应该使用哪个 ZKP？在 Vitalik 的愿景中，这可以通过协议外的社会（或密码经济）共识来解决。

在共识层，我们添加一条验证规则，即仅当客户端看到区块中每个声明的有效证明时，才接受该区块。该证明必须是 ZK-SNARK，证明 transaction_and_witness_blobs 的连接是对 (Block, Witness) 对的序列化，并且使用 Witness 在 pre_state_root 之上执行该区块 (i) 有效，并且 (ii) 输出正确的 post_state_root。潜在地，客户端可以选择等待 M-of-N 类型的多个证明。

想象一下一个诚实的构建者，他有一个想要提供有效性的 1 型 区块； 几个选项 已经可以从 L2 获得，例如 Polygon、zkSync 和 Scroll。假设他们的 ZK-EVM 已经发展到 1 型，并且它们是信誉良好且经过实战考验的。然后，构建者将从这些可用的证明系统中进行选择，而验证他的区块的人将运行相应的验证软件。最好是创建多种类型的证明，并且通过多个验证。给定相同的 L1 链规范，如果任何验证者不同意，则会变成一个共识问题。

证明系统将通过说服用户信任它们来获得影响力，而不是通过说服协议治理过程。

根据 Vitalik 的说法，这将意味着生态系统 ZKP 正在为直接市场化开放。如果激励措施到位，现有的 L2 实现可能会竞争 L1 证明市场。

Taiko 多重证明的可行性

在 Taiko 协议 中，提议者必须找到一个证明者来提议一个区块，并且分配的证明者将存入一个 TKO 债券 以保证交付证明。Taiko 不规定提议者如何找到和补偿证明者，因此他们甚至可以亲自见面并用现金进行交易。因此，我们的供应链作为一个自由市场运作。提议者可以选择他们喜欢的任何证明者。

除了经济优势之外，还有一些技术特性使 Taiko 非常适合多客户端系统：

• Taiko 是一个 1 型 ZK-EVM，它有两个好处：

  • 对于执行多样性，现有的 EVM 实现（Geth、Besu、Reth，...）可以直接引入 L2。

  • 为了测试 L1 嵌入式设计，我们需要一个标准化的 ZK-EVM，用于开放的多客户端验证，因为验证者需要对照相同的转换进行检查，才能就其验证结果达成共识。在这种情况下，1 型 ZK-EVM 将是最合适的，因为它清楚地遵循以太坊规范。对于 rollup 特定的逻辑，Vitalik 还提到如何通过预编译支持 修改 ZK-EVM，并且利用这些预编译来支持 Taiko 的 BBR（基于 Booster Rollup）设计就足够了。

• Taiko 在以太坊上发布数据，不像某些探索替代数据可用性选项的 L2。只要数据发布到 L1，Taiko 就可以轻松适应 Vitalik 的实现提案，该提案提出了 ZKEVMClaimTransaction 来涵盖状态转换、证明和数据可用性。

来源：https://notes.ethereum.org/@vbuterin/enshrined\_zk\_evm。

• Taiko 适用于多个证明系统。现有的测试网已经支持 PSE 的 ZK-EVM、SGX 和 Reth。该基础设施配置为适应多个执行客户端和证明系统，这将在最后一节中讨论。在此基础设施的基础上，我们在 ZKP 中的定位将围绕模块化编译。

模块化和开放性的路线图

Taiko 的多重证明完全关于模块化和开放性。

模块化

在 ZKP 的上下文中，给定多个客户端，我们利用现代编译器来获得通用程序集，例如 Risc-V 或 WASM。然后将这些指令转换为各种证明系统的 算术化（AIR 或 PIL），并且算术化的执行跟踪最终用不同的 SNARK 进行编码。

执行客户端 -> 汇编语言 -> 算术化 -> SNARK
             多客户端             |           多重证明

简而言之，此流程是多重证明系统最可行的，因为它利用了两个世界的优势。在客户端编译过程中，现代编译器为我们提供了以下好处：

• 客户端升级与证明无关，因为无需为最新的 EIP 或硬分叉 实现电路；我们只需要保持源代码最新即可。

• 我们可以从 LLVM 等工具链中免费获得代码优化。

• 交叉编译产生更多多样性；以上述示例为例，我们有 Geth 或 Reth 编译为 RICS-V 或 WASM 指令，它们已经有四组证明。

SNARK 的编译是我们前进的重点。请注意，使用 Halo2、eSTARK 或 Supernova 等后端进行编码的 PLONK 和 R1CS 等算术化方法 不会将我们限制为单个 ZK 协议，而 * 单片 ZK-VM/EVM 提交到特定的 ZKP 以进行后端实现。随着越来越多的项目采用彼此的组件以获得更好的性能，单片技术堆栈可能会模块化。ZKP 研究领域发展如此之快，以至于灵活性比直接实施最新结果更重要。为了保持灵活性，我们与 Powdr Labs 和 Risc Zero 等项目合作，开发他们的交叉编译流程，尽可能实现模块化。对于精通技术的读者，以下是具体的好处：

• 我们可以将优化应用于编译器，以针对不同的后端，例如偏爱 高阶门 或使用更多 查找参数。

• 像 keccak 和 Poseidon 哈希函数这样的加速电路可以作为库实现。

• 我们可以逐步将 LogUp 等 ZK 功能添加到语言中，并启用相应的后端支持。

• 集成新的 后端 ZK 框架 变得更快。在一些以研究为导向的 ZK 项目中，仅在代码中开发了概念验证，这使得它们难以在生产中使用。通过让编译器完成繁重的工作，我们可以轻松地应用早期阶段的框架。

• 现有的后端电路，例如 用 Halo2 编写的 PSE ZK-EVM 组件，仍然可以通过直接调用来重用。

通过共同努力，Taiko 已经集成了 Risc Zero 的 zeth 和 ZK-VM，同时为其开发了一个额外的 SGX 后端。Taiko 的工程师还将 Powdr 集成到我们的多重证明系统中，开发 PIL 语言和库，优化编译，添加更多后端，并执行一般的低级加速。在硬件层面，我们的 ZK 加速层 (ZAL) 旨在标准化证明系统（Halo2、Arkworks、Risc Zero、Polygon 等）和加速器库（CPU、GPU、FPGA 等）之间的合作。

开放性

客户端、证明系统和集成后端越多越好，因此我们努力将整个社区聚集在一起。我们的团队与他人合作有着悠久的历史，例如与 PSE 合作开发 ZK-EVM，与 Risc Zero 合作。现在，通过构建更模块化的 ZK 堆栈，我们可以有效地致力于抽象 API，以实现更好的泛化和集成。Taiko 将充当在生产中交付证明系统并在链上对其进行实战测试的门户。我们全心全意地邀请所有项目加入我们，共创更美好的 ZK。

Taiko 堆栈

可扩展、灵活的基础设施对于我们的多重证明范例至关重要。 ZK 有效性证明的来源成分是客户端的状态跟踪和存储证明，这些证明用于构造见证和公共输入。请注意，见证是特定于证明的，而公共输入是协议方面的。拥有一个鲁棒的基础设施来处理证人生成非常重要。因此，我们使用一个轻量级主机从多客户端获取跟踪，并将跟踪反馈给多重证明者。在证明者端，该设计支持模块化和单片堆栈，同时我们从目标客户端（目前为 Geth）提取相同的公共输入。

将来，如果跟踪格式兼容，则可以将作为 Taiko 节点的 Geth 替换为另一个节点。此外，运行在证明系统上的轻客户端（目前为 Reth）也可以被编译为可接受的汇编语言的任何实现所取代。

主要收获

• 我们相信多重证明 = 多客户端 + 多 SNARK（以及像 SGX 这样的 TEE）。

• Taiko 协议非常适合多客户端系统，因为它具有开放的多重证明供应链，其中包含 1 型执行，该执行在 L1 上发布数据可用性。

• Taiko 设想了一个具有模块化和开放性的多重证明架构。我们与 Powdr Labs 合作，利用与客户端和 ZKP 的交叉编译，并与 Risc Zero 合作，在其 ZK-VM 和 TEE 上实现 Taiko 的执行。我们还将继续与 PSE 合作，以改进 ZK-EVM 项目。

• Taiko 的灵活基础设施考虑了模块化和单片 ZKP 堆栈。

加入我们 💗

在我们的 招聘版块 上探索空缺职位。

关注我们 🥁

从 Taiko 获取最新信息：

• 网站：https://taiko.xyz。

• Discord：https://discord.gg/taikoxyz。

• GitHub：https://github.com/taikoxyz。

• Twitter：https://twitter.com/taikoxyz。

• 社区论坛：https://community.taiko.xyz。

• Youtube：https://www.youtube.com/@taikoxyz。

贡献 🤓

在 GitHub 上为 Taiko 做出贡献并赢得 GitPOAP！你还将作为贡献者出现在我们的 README 中。从 贡献手册 开始。

• 原文链接： taiko.mirror.xyz/j_zUGgL...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～