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

不久前，我们分享了一篇题为“为什么多重证明很重要”的详细文章，解释了多重证明的重要性，并重点介绍了 SGX 作为多重证明的选择之一。本文的灵感来自于我们与 Vitalik 合作的 X (Twitter) 空间以及他随后发表的博客文章，其中介绍了 Taiko 在多重证明方面的总体路线图：它与最终游戏的关系、我们的愿景是什么以及我们将如何实现这一目标。

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

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

• 以太坊残局假设 ZK 证明的 L1 区块。

与以太坊的多客户端方法类似，该方法多次使网络免于崩溃，证明 L1 区块将需要多重证明方法。这对于 ZK 和非 ZK 场景来说，都意味着多客户端 + 各种证明系统。

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

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

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

在天真的情况下，他们会使用所需的客户端重新执行该块，或者他们可以从某些证明者查询执行的有效性证明。如果看到的有效证据数量多于预期，用户就会被说服。但是，如果没有“白名单”ZKP 并且我们想避免重新执行，我们实际上应该使用哪个 ZKP？在 Vitalik 的愿景中，这是通过协议外的社会（或加密经济）共识来解决的。

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

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

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

Vitalik 表示，这意味着 ZKP 生态系统正在开放直接市场化。如果受到激励，现有的 L2 实现可能会争夺 L1 证明市场。

在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（Based Booster Rollup）设计。

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

• Taiko 致力于多重证明系统。现有的测试网已经支持PSE 的 ZK-EVM、SGX 和Reth。基础设施配置为容纳多个执行客户端和证明系统，这将在上一节中讨论。建立在这个基础设施的基础上，我们在 ZKP 中的地位将围绕模块化编译。

Taiko 的多重验证器的核心是模块化和开放性。

已订阅

Taiko 的多重证明方法

太鼓实验室

0x5b79

梅德

14 小时前

170 已收集

薄荷

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

不久前，我们分享了一篇题为“为什么多重证明很重要”的详细文章，解释了多重证明的重要性，并重点介绍了 SGX 作为多重证明的选择之一。本文的灵感来自于我们与 Vitalik 合作的 X (Twitter) 空间以及他随后发表的博客文章，其中介绍了 Taiko 在多重证明方面的总体路线图：它与最终游戏的关系、我们的愿景是什么以及我们将如何实现这一目标。

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

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

• 以太坊残局假设 ZK 证明的 L1 区块。

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

与以太坊的多客户端方法类似，该方法多次使网络免于崩溃，证明 L1 区块将需要多重证明方法。这对于 ZK 和非 ZK 场景来说，都意味着多客户端 + 各种证明系统。

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

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

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

在天真的情况下，他们会使用所需的客户端重新执行该块，或者他们可以从某些证明者查询执行的有效性证明。如果看到的有效证据数量多于预期，用户就会被说服。但是，如果没有“白名单”ZKP 并且我们想避免重新执行，我们实际上应该使用哪个 ZKP？在 Vitalik 的愿景中，这是通过协议外的社会（或加密经济）共识来解决的。

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

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

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

Vitalik 表示，这意味着 ZKP 生态系统正在开放直接市场化。如果受到激励，现有的 L2 实现可能会争夺 L1 证明市场。

在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（Based 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 进行编码。

Execution Clients -> Assembly Languages -> Arithmetizations -> SNARKs    
             multi-clients           |              multi-proofs

简而言之，这个管道对于多重证明系统来说是最可行的，因为它利用了两个世界的优点。在客户端编译过程中，现代编译器给我们带来了以下好处：

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

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

• 交叉编译产生更多多样性；根据上面的示例，我们将 Geth 或 Reth 编译为 RICS-V 或 WASM 指令，这些指令已经有四组证明。

SNARKs 汇编是我们前进的重点。请注意，算术方法（例如 PLONK 和 R1CS编码）以及Halo2、 eSTARK或Supernova等后端不会将我们限制为单一 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等）之间的合作。

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

客户端、证明系统和集成后端越多越好，因此我们努力将整个社区聚集在一起。我们的团队有着与其他团队合作的悠久历史，例如 ZK-EVM 上的 PSE 和 Risc Zero。现在，通过构建更加模块化的 ZK 堆栈，我们可以有效地抽象 API，以实现更好的泛化和集成。Taiko 将作为在生产中运输证明系统并在链上进行战斗测试的网关。我们竭诚邀请各项目方加入我们，共创更好的ZK。

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

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

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

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

• Taiko 灵活的基础设施适用于模块化和整体 ZKP 堆栈。

探索我们的招聘网站上的空缺职位 。

从 Taiko 获取最新信息：

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

• 不和谐：  https: //discord.gg/taikoxyz。

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

• 推特：https:  //twitter.com/taikoxyz。

• 社区论坛：  https ://community.tai​​ko.xyz 。

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

在 GitHub 上为 Taiko 做出贡献并获得 GitPOAP！您还将成为我们自述文件的贡献者。开始使用 贡献手册。

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

不久前，我们分享了一篇题为“为什么多重证明很重要”的详细文章，解释了多重证明的重要性，并重点介绍了 SGX 作为多重证明的选择之一。本文的灵感来自于我们与 Vitalik 合作的 X (Twitter) 空间以及他随后发表的博客文章，其中介绍了 Taiko 在多重证明方面的总体路线图：它与最终游戏的关系、我们的愿景是什么以及我们将如何实现这一目标。

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

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

• 以太坊残局假设 ZK 证明的 L1 区块。

与以太坊的多客户端方法类似，该方法多次使网络免于崩溃，证明 L1 区块将需要多重证明方法。这对于 ZK 和非 ZK 场景来说，都意味着多客户端 + 各种证明系统。

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

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

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

在天真的情况下，他们会使用所需的客户端重新执行该块，或者他们可以从某些证明者查询执行的有效性证明。如果看到的有效证据数量多于预期，用户就会被说服。但是，如果没有“白名单”ZKP 并且我们想避免重新执行，我们实际上应该使用哪个 ZKP？在 Vitalik 的愿景中，这是通过协议外的社会（或加密经济）共识来解决的。

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

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

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

Vitalik 表示，这意味着 ZKP 生态系统正在开放直接市场化。如果受到激励，现有的 L2 实现可能会争夺 L1 证明市场。

在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（Based Booster Rollup）设计。

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

• Taiko 致力于多重证明系统。现有的测试网已经支持PSE 的 ZK-EVM、SGX 和Reth。基础设施配置为容纳多个执行客户端和证明系统，这将在上一节中讨论。建立在这个基础设施的基础上，我们在 ZKP 中的地位将围绕模块化编译。

Taiko 的多重验证器的核心是模块化和开放性。

已订阅

Taiko 的多重证明方法

太鼓实验室

0x5b79

梅德

14 小时前

170 已收集

薄荷

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

不久前，我们分享了一篇题为“为什么多重证明很重要”的详细文章，解释了多重证明的重要性，并重点介绍了 SGX 作为多重证明的选择之一。本文的灵感来自于我们与 Vitalik 合作的 X (Twitter) 空间以及他随后发表的博客文章，其中介绍了 Taiko 在多重证明方面的总体路线图：它与最终游戏的关系、我们的愿景是什么以及我们将如何实现这一目标。

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

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

• 以太坊残局假设 ZK 证明的 L1 区块。

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

与以太坊的多客户端方法类似，该方法多次使网络免于崩溃，证明 L1 区块将需要多重证明方法。这对于 ZK 和非 ZK 场景来说，都意味着多客户端 + 各种证明系统。

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

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

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

在天真的情况下，他们会使用所需的客户端重新执行该块，或者他们可以从某些证明者查询执行的有效性证明。如果看到的有效证据数量多于预期，用户就会被说服。但是，如果没有“白名单”ZKP 并且我们想避免重新执行，我们实际上应该使用哪个 ZKP？在 Vitalik 的愿景中，这是通过协议外的社会（或加密经济）共识来解决的。

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

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

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

Vitalik 表示，这意味着 ZKP 生态系统正在开放直接市场化。如果受到激励，现有的 L2 实现可能会争夺 L1 证明市场。

在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（Based 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 进行编码。

Execution Clients -> Assembly Languages -> Arithmetizations -> SNARKs    
             multi-clients           |              multi-proofs

简而言之，这个管道对于多重证明系统来说是最可行的，因为它利用了两个世界的优点。在客户端编译过程中，现代编译器给我们带来了以下好处：

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

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

• 交叉编译产生更多多样性；根据上面的示例，我们将 Geth 或 Reth 编译为 RICS-V 或 WASM 指令，这些指令已经有四组证明。

SNARKs 汇编是我们前进的重点。请注意，算术方法（例如 PLONK 和 R1CS编码）以及Halo2、 eSTARK或Supernova等后端不会将我们限制为单一 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等）之间的合作。

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

客户端、证明系统和集成后端越多越好，因此我们努力将整个社区聚集在一起。我们的团队有着与其他团队合作的悠久历史，例如 ZK-EVM 上的 PSE 和 Risc Zero。现在，通过构建更加模块化的 ZK 堆栈，我们可以有效地抽象 API，以实现更好的泛化和集成。Taiko 将作为在生产中运输证明系统并在链上进行战斗测试的网关。我们竭诚邀请各项目方加入我们，共创更好的ZK。

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

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

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

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

• Taiko 灵活的基础设施适用于模块化和整体 ZKP 堆栈。

探索我们的招聘网站上的空缺职位 。

从 Taiko 获取最新信息：

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

• 不和谐：  https: //discord.gg/taikoxyz。

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

• 推特：https:  //twitter.com/taikoxyz。

• 社区论坛：  https ://community.tai​​ko.xyz 。

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

在 GitHub 上为 Taiko 做出贡献并获得 GitPOAP！您还将成为我们自述文件的贡献者。开始使用 贡献手册。