Security vs Trustlessness, ZK协议在机制上该如何取舍？

原文标题：《 IOSG Weekly Brief ｜Security vs Trustlessness, ZK 协议在机制上该如何取舍 》

原文来源：  IOSG Ventures

近日，zkSync 和 Polygon 都推出了各自的 zkEVM，掀起了一波行业的热潮。与此同时，社区对于 zkEVM 的安全性和去中心化也有了很多讨论。IOSG 在前不久刚结束的 ETHDenver 期间，举办了一场以安全为主题的活动（Stay SAFU, Security Day），有幸邀请到了在零知识证明领域的头部项目参与讨论，他们分享了零知识证明协议在机制设计和工程建构上的安全原则与新颖方案，以及在设计过程中的种种权衡。

以下为各位嘉宾分享的 insight 原文，参与者为：

Queenie Wu, IOSG Ventures 合伙人（主持人）；

Alex Gluchowski, zkSync 联合创始人；

Ye Zhang, Scroll 联合创始人和研究负责人；

Matt Finestone, Taiko 首席运营官；

Mikhail Komarov, Nil foundation 创始人；

Brian R, Risc 0 创始人；

Q1：零知识证明是如何增强你们正在构建的系统的安全性的？另一方面，部署零知识证明会带来哪些安全问题？

[Brian R]

我是 Risk Zero 的 CEO Brian Redford。我们是在 Risk-V Micro Architecture 构建的 Risk Zero zkVM 的开发者，可以在 ZK 系统中执行任意代码。我们还在部署一个名为 Bonsai 的 Layer 2 网络，它可以在 ZK 场景下执行任何代码，可以把它理解为是一个 ZK 加速器。在 ZK 如何增强安全性方面，我想这取决于具体的应用场景。当然，能够进行计算并生成可以在世界任何地方验证的证明方式完全改变了区块链安全的范式。你不再需要一遍又一遍地重新做相同的计算，再通过复杂的各种机制（比如经济机制）来保证整个系统的安全性。

[Mikhail Komarov]

我是 Nil 的创始人 Mikhail Komarov。我们为正在开发的 ZK 项目提供基础设施，例如 zk-EVM 编译器。这个编译器可以将高级语言编译成电路，使得高级语言中定义的每个计算都可以被证明，无需执行任何操作，只需要简单的电路即可。除此之外，我们还引入了一个「证明市场（Proof Market）」的概念，给想要生成 zkSNARK/STARK 证明的项目方，提供了一个去中心化的竞价市场。每个开发者都可以提交所需要生成的零知识证明的竞价单，然后只需要在应用程序中调用证明，以获取所需的服务（比如 zkRollup 就可以使用证明市场）。

基本上，我们是开发人员所需的基础设施。从我们自身来说，它并没有增强我们的安全性，但从整体来说，它确实增强了安全性。正如 Brian 所说的那样，它通过消除协议中应在 Trustless 的环境中运行的信任假设来增强安全性。它的关键在于进一步减少信任假设。这就是它如何增强安全性的方式。我相信零知识证明如果被项目，去年发生的一些安全事故可能可以避免。

[Matt Finestone]

我是 Matt 来自 Taiko，我们是一个以太坊兼容的 ZK Rollup。我们追求最大程度的以太坊和 EVM 兼容性。在安全方面，我们独特的地方是我们非常依赖于经过充分测试和验证的以太坊构建模块、客户端和智能合约模式。正如 Mikhail 所说，ZK 减少了信任假设或将其转移到 Protocol/证明层面。「需要信任的」不再是一些有动机的人，而是数学和围绕数学证明开发的协议和应用。对于 ZK Rollup，有很多安全考虑，不仅仅是 ZK。

我认为我们尽可能地从以太坊中重用安全的部分，以保持安全。随着时间的推移和实战测试，ZK 将是非常强大的系统。

[Ye Zhang]

大家好，我的名字是 Ye。我在 Scroll 工作。我先简单介绍一下 Scroll。Scroll 是以太坊的扩容解决方案。它与以太坊兼容度非常高，用户可以与应用程序交互，开发者可以部署智能合约，只需将代码复制粘贴并迁移到 Scroll 上即可。它比以太坊更快，更便宜，同时具有更高的吞吐量和更严格的安全性。我们会去中心化我们的证明系统（Decentralized Prover Network），防止证明系统的单点故障。这是我们迈向去中心化的第一步，因为 ZK Rollup 的在未来相当长的一段时间内会是去中心化的。即使你对数学非常信任，对密码学非常信任，但你仍然可能遇到这种单点故障，因为你要依赖于某个证明者。

去中心化的第一步是想要将证明系统去中心化，以使其更加可靠。至于 ZK 的安全性，我认为其他嘉宾已经介绍了 ZK 给你带来了非常强大的公共可验证性属性。基本上，任何人都可以进行计算和执行证明，然后任何人都可以验证这个证明并得到相同的保证。如果你有数百万个节点，每个人只需要重新执行验证算法，而不是初始计算，这样也实现了系统的可扩展性。这就是 ZK 技术的威力所在，至于它可能存在的问题，如果我们的系统完全依赖数学的运算，如果存在一些错误，比如缺失一些约束条件，那么可能会很危险。这就是为什么我们采取多种方法来提高我们的安全性。例如，我们采用社区驱动的方法进行开发。从第一天开始，我们就开源了所有开发过程，并由以太坊和我们自己的社区进行了审核，这是一个更高的标准。这就是我们最小化信任和提高安全性的方法。

[Alex Gluchowski]

我叫 Alex Gluchowski，是 Matter Labs 的 CEO，我们是 zkSync 协议背后的公司。我们正在构建 zkSync Era Network，这是一个与 ZK EVM 兼容的 ZK Rollup。我们采取了与 EVM 等效的 Rollup 略有不同的方法。我们认为应该采取务实的方法, 从兼容的东西开始，这样开发者可以轻松接入和移植现有应用程序，并从现有工具中启动。但是，最终的 ZK 环境是不同的。如果你将自己绑定到原有技术上，将很难实现 ZK 系统的最大容量。这很重要，因为我们的使命是将区块链扩展到真实世界的范围，将下一个十亿用户引入区块链，创造新的价值互联网。如果你考虑到数百万甚至数十亿用户，你真的想要降低成本，因为随着所有这些数十亿个交易的累加，成本将变得非常重要。

这如何影响我们如何增强安全性？这是一个非常有趣的问题。当你询问如何提高安全性或任何其他因素时，你想要比较替代方案，对吧？我的基准是什么？使用 ZK 的替代方案是什么？替代方案可能是在 ZK Rollup 之前可用的其他扩展技术，例如 Optimistic Rollup、侧链、Plasma 等。这些方案引入了新的信任假设。如果我们的目标是将规模扩大到 10 亿用户，而我们的使命不仅是扩大吞吐量，而是扩大价值规模，同时保持自我主权、自我保管、无需许可的性质以及完全无需信任的系统特性，那只有使用 ZK 可以实现。

Q2：我们在比较不同类型的 zkEVM 时，通常关注的是他们的可扩展性和兼容性，（Vitalik 对此进行了详细的比较:https://vitalik.ca/general/2022/08/04/zkevm.html），如果我们在此增加一个安全的维度，zkSync Era、Scroll 和 Taiko 会如何比较不同的机制设计可能带来的不同的潜在安全风险？

[Alex Gluchowski]

正如前面的发言者所提到的，你需要隐含地信任这些复杂系统的许多组件来保证安全性，例如，你信任编译器产生的代码，你认为它正在执行你放在这个编译器中的代码逻辑。为什么你会相信它是 Solidity？它没有形式化定义，所以你只是信任编译器在各个版本中的行为是正确的。我们认为这是必须要解决的问题。这就是为什么我们开始建立基于 LLVM 框架的编译器，它支持 Solidity 作为前端之一，并依赖于这个成熟的框架，有很多工具可用于代码的静态分析、安全检查等，而后端是我们的 zkVM 虚拟机。我们还可以支持其他更成熟的语言，这些语言实际上已经被用于其他安全环境，如 Rust，或者是一些更新颖的语言，这些语言是增加了安全考量的，如 Move，它能避免一些安全问题，比如双花之类的。总而言之，尽管比较复杂，我们必须从不同的层面去解决。

[Ye Zhang]

我想讲一些不同的方法及其背景。我们正在建立 EVM Bytecode 级别的兼容方案。基本上我们可以与 EVM Bytecode 进行兼容。这与 zkSync 的构建方式不同，我们也相信编译器不应该被信任。这就是为什么我们相信 Solidity 编译器，虽然它不成熟，但在区块链的背景下，Solidity 已经是相对成熟的了。之前没有人使用 Solidity 和 LLVM。我们相信那是一个更好的标准，因为已经经过了实践的检验，很多智能合约 DeFi 已经经过了 Solidity 开发者的实践考验。这就是为什么我们相信遵守这种编译器的标准，遵守 Solidity 编译器的标准，遵守 EVM 黄皮书的定义是保证系统安全性的最好方法。因为从电路方面来说，我们不需要考虑编译器方面的问题，我们不需要建立我们自己的编译器，我们只是采用现有的基础设施，证明它的执行是正确的。

我们情愿把系统构建的复杂性只放在解决 zkEVM 在 Bytecode 层面的兼容性，而不是同时构建一个编译器以及支持 LLVM 的后端，我们不希望在构建 zkEVM 之外还需要构建编译器。另一个考虑因素是，我们肯定关心开发者的体验。Layer 2 是为扩展 EVM 而建立的，目前的 EVM 已经因为大量 Solidity 代码和应用变得拥挤不堪。我们希望开发者能够无缝迁移到我们的系统，同时确保安全性。这也是为什么我们目前不打算在 EVM 当中增加更多花俏的功能。

遵循这个标准可以使 Ethereum 真正可扩展，同时保证在此基础上的系统最佳性能和及时交付。同时，我们也在以太坊官方推动各种开源实现，包括 Type 1 和 Type 2 的 zkEVM，包括隐私和扩容等。我们从第一天开始就采用开源方式构建。我们非常关注 Ethereum zkEVM 的开发和演进，我们领导了其中一半的开发，我们是团队的一部分，因此我们确切地知道整个系统需要多长时间才能真正准备好。这就是为什么我们采取这种方法来准备产品和深入社区，然后考虑如何推动 Ethereum 的终极目标。

[Matt Finestone]

这是两个很好的答案，Taiko 和 Scroll 的方案更靠近，我们也没有引入新的编译器。我喜欢 Alex 所说的，就是在区块链背景下安全的替代方案是什么？我认为我们都会同意，以太坊可能是黄金标准。我们按照黄皮书实施，重复使用以太坊而不是调整它的组件，即使是在 EVM 以外的以太坊组件、数据存储结构等方面，也是经过实践验证的。

当然，这里始终有权衡。Alex 谈到了十亿用户和超低成本以及保持价值的扩展性。我们可能会在证明成本上做出更高的牺牲，但我们坚持使用经过实战考验的 EVM 标准和以太坊标准。而对 Ye Zhang 所说的关于实用性和快速进入市场的一些考虑，我们也会做出了权衡。

在 ZK 的背景下，有一些方向不容易实现，例如一些哈希函数或一些数据存储结构。我们不去改变这些东西，因为我们不确定它们的效果会如何，比如把 Merkel Patricia Tree 改成了 Verkle Tree，即使这在以太坊的路线图上本身就存在。我们对经过试验和实战考验的组件更加自信，系统的复杂性不在于试图重新发明以太坊的 EVM 和其他组件，而是在于如果将 ZK 完全地部署兼容 EVM。这将需要更长的时间来完成，我们需要比 Scroll 更长的时间来做一些权衡以实现可用性。在安全性上，我们的实现路径会更令人放心。

[Mikhail Komarov]

以太坊经过实战考验，让我们重用所有这些系统，减少新的假设。但还有几个安全问题，少有人真正考虑过，而我们的目标是解决它们。第一个问题，你必须信任编译器。还有另一个问题，就是如果你想实现完全的 EVM 兼容性，比如 Type 1 的 EVM 兼容性，那么你就需要手动在电路中重新部署 EVM 的任何 Opcode，通过找出作为电路的某个表达式，它在某个确定域上的形式会是怎样的，这是一个手动的过程，而且非常复杂，很容易出错。我们自己就做过这样的事情，而且搞砸了电路，因此我们知道这是糟糕的。

为了不重复这些问题，也不让任何人犯这些错误，我们正在致力于通过允许人们通过使用已经经过实战测试的 EVM 实现编译电路，来消除这种安全假设，而不是通过手动重新实现所有的 OpCode。我们的目标是通过使用 LLVM 编译器来编译它，而不是手动重新实现，由此有了最小的安全假设。这是另一个需要消除的安全假设，我们将针对 zkEVM 进行解决。

[Brian R]

你可以在类似 RiscV 的系统上运行 geth 来解决 Mikhail 所说的问题。我们实际上刚刚添加了 Go 的支持。我们构建并设计了 RiscZero VM，我们选择 RiscV 指令集的部分原因是因为它有形式化定义，而且非常轻巧。RiscV 电路的安全范围有所规范，并且已经进行了大量工作来将形式化验证方法纳入证明某个实现过程符合 RiscV 规范。我们专注于保证这个简单系统中的密码学正确，然后在其上运行 EVM 确实有效。当然，这种方法会有性能损失。比如进行 ERC 20 Token 转移需要大约 1 分钟。

Q3：正如 Alex 刚刚提到的，对于系统的任何部分，升级或选择另一种解决方案都是可能的。那么，如何确保系统的可升级性，并且以非常安全的方式实现？

[Brian R]

是的，我认为在 ZK 中，可升级性是一个非常重要的话题。从我们的角度来看，在没有部署网络和背后有大量经济价值的情况下，我们花费了大量时间确保我们正在构建正确的技术堆栈抽象。我们可以切换哈希函数，切换有限域和证明系统，或者添加新的技术，例如 PLONK，到技术堆栈中。这也是我们选择 RiscV 作为主要支持的「指令集」的另一个原因，因为它本身就是一个非常清晰的抽象系统。因此，您可以随意更换任何东西。LLVM 显然具有非常类似的特征。

[Matt Finestone]

是的，升级是一个很大的话题，我们可以将其看作一个去信任化系统的问题。系统的部署实现可能会出现漏洞，用户就会面临风险，或者要信任构建该系统的人或一些参与者，他们可能会在趁虚而入等等。升级是一种在某些层面上找到安全和去信任化的平衡。当你对系统的信任度提高时，可以去除其中一些受信任的参与者。在这里，我们应该对一些受信任的参与者持有非常警惕的态度，因为我们做这些事情的目的是为了消除这些参与者。对于这些非常复杂的系统，最好在早期就可以介入。我认为，Alex 和 Matter Labs 团队已经在这方面提供了一些很好的参考案例。他们有一个很好的安全委员会和时间延迟的机制。

那么升级的正确节奏是什么？这是一个非常重要的问题，我不知道更多的用户是否会对完全去信任的系统感到安心，因为这样的系统往往非常复杂，引入了许多新的东西，或者是信任这些善意的参与者。这是一个非常关乎人性的问题，当然也有一些技术解决方案，比如多重证明可能是一个不错的选择。我认为，我们有可能从类似于 Optimism 的组件中重用一些设计。如果我们的有效性证明有问题，那么重用 Optimistic Rollups 的实现将更容易制定欺诈证明的系统，以使其适用于以太坊等效环境。你可以混合匹配欺诈证明和有效性证明，如果有任何异议，那么升级性或某种类型的治理方案可以覆盖它。

[Mikhail Komarov]

让我来说一下。我刚花了一些时间思考这个问题。我担心我没有理解问题，因为我想说哪里有升级问题？只需重建电路即可。那么，究竟是哪些升级问题呢？

[Ye Zhang]

从我们的角度来看，首先，肯定不能仅仅编译新电路，因为它会影响您的证明密钥、验证密钥和许多链上智能合约，所以肯定不能经常这样做。我们在考虑多重证明的方法，添加双重验证等机制。有多种方法可以解决这个问题，除了像 Matt 提到的，我们不考虑直接与 Optimistic 的欺诈证明相结合，因为这会让最终确认时间变得更长。我们正在探索一些其他方法，很快就会在以太坊研究中提出一些提案，关于如何增加一些额外的保证。

例如，Justin Drake 提出了使用 Intel SGX（TEE 环境）作为一些额外保证的方法，严格地增加了安全保证。此外，还可能存在一些其他的治理方式，我们认为安全委员会和时间延迟是不错的方式。我们也在思考这个问题。这是一个权衡，我相信大多数 Rollups 仍需要更长时间才能真正摆脱这种可升级性问题，因为升级系统是一件长期的事。我们正在认真关注和研究这个问题。

[Alex Gluchowski]

我可以给一些背景信息，为什么可升级性是一个重要的问题。打个比方，对于任何你电脑桌面上运行的某个程序，你只需下载新版本并安装，对吧？升级有什么问题？问题在于，在区块链的背景下，我们试图构建 Trustless 的系统，但在某些情况下，升级的需求可能会破坏这种信任。对于 Layer 1 ，没有这个问题。如果要升级以太坊，只需下载新的客户端，安装它，然后所有人协调分叉。

然后我们安排一次分叉，定个日期，在某个区块号进行分叉，那么任何不喜欢此次升级的人都可以留在旧版本的旧分支上。这种可升级性路径是完全 Trustless 的。它不会让您依赖任何诚实的大多数或任何可信的参与者。

问题出现在 Layer 2 的背景下。如果我们构建的是 Rollup，Rollup 依赖于 Layer 1 的智能合约。这个智能合约可能是不可变的，其中某些特定电路的某些固定功能和验证密钥已经内置，那么问题就在于如果存在 Bug，那么你将束手无策。那如果面临 bug，或者如果想修复它该怎么做？

我们在 zkSync 1.0 （zkSync Lite）披露了过一个漏洞，具有可升级性的时间锁定，因此团队可以提出新版本的升级提案。然后，如果用户不喜欢这个新的版本，所有用户都有几周的时间将资产从 Layer 1 退出。我们有 Trustless 的机制来实现退出。但因为被迫进入了这个时间锁定，我们无法修复它，所以我们想出了一个折衷方案，并引入了我们称之为 Security Council 的方案，这是一个独立的委员会。我们邀请了一些来自不同社区、不同项目的以太坊社区的 15 名知名成员加入。

团队不控制合约，只能提出升级方案，Security Council 来做出决定，可以决定加速升级。但这仍然不是最佳选择，因为理论上还是有一组人可以在此期间立即安装一个恶意版本。也许他们不想这样做，但也许他们会被某些参与者强迫，我们无法排除这种可能。因此，如果我们希望充分利用零知识证明，并且仅依赖数学和开源代码而不是任何验证程序的受信任方等，最终实现完全 Trustless 的机制。

我们目前在思考一个更好的方案，由团队提出时间锁定的升级提案，Security Council 可以介入建议冻结智能合约，然后在 Layer 1 上进行软分叉。因此，这需要与 Layer 1 协调，这需要 Layer 2 协议已经有一定规模足够重要，以使社区实际上进行分叉，安装新版本等。因为 Layer 1 无法为每个小协议执行此操作，它必须是像以太坊上的系统级事物那样重要的协议。

这是我们目前拥有的增强无需信任的可升级方案的最佳机制，以便保护我们免受第一层严重漏洞的影响。但这还是会引入一些类似时效性的问题，如果出现这样的问题，协议将暂停一段时间，想象一下我们已经从 Visa 和 PayPal 切换到使用这种大型 Rollups 进行区块链支付，突然之间用户资产被冻结，没有人可以进行支付，需要我们协调升级几天，这是巨大的问题。我们当前没有更好的解决方案，也没有看到更好的解决方案。如果您有想法，请联系我们，让我们进一步探讨。

Q4：有一个关键词被多次提到，那就是「无需信任-Trustless」。正如我们所知，当前系统中最重要的组成部分仍然是中心化的。从中心化到去中心化的演变，我们将面临哪些安全挑战？

[Alex Gluchowski]

我认为这（Trustless）将增强安全性。这将为我们提供多一重因素的保护。首先，ZK Rollup 必须为每个块提供有效性证明，但它可以存在问题，例如，也许我们忘记了某些约束条件。在此之上，我们还需要通过权益证明共识机制来提供签名，这是额外的一层保护。因为为了破坏系统，恶意攻击者必须首先找到漏洞，然后必须在伙同这个这些验证者中的大多数来一起作恶。

这个可能性是比较小的，因为攻击者要么已经是这个区块链上的控制方，要么必须购买大量 Token，这给了我们足够的时间，可能其他人也会发现相同的漏洞，并提交 Immunefi 或其他地方，团队可以进行修复。或者，也许我们将同时运行一些蜜罐，这是完全开放的，任何人都可以破解并从中获得奖励。所以，总体来说，这为整个系统提供了两个因素的保护。而且，我们可以在此基础上添加更多因素。

到目前为止，我不会相信一个号称完全无需信任的 ZK Rollup 是安全的。对我来说，这将是极具风险的。我不会在这样的 ZK Rollup 上放置比我可承受失去的金额更大金额的资产。

我最喜欢举的例子是波音 737 Max 事件。这个事故的原因不是因为他们试图转移公众注意力的软件问题，而是因为他们依赖于飞机上的单个传感器，这是完全不负责任的行为。航空业已经有很长的发展历史，过程中有很多技术迭代，不能依赖单个系统是业界的共识。但因为他们在生产波音 737 max 的过程中因为各种原因（比如成本、交付时间等）牺牲了安全的系统设计，最终导致了事故。因此，我们始终希望至少有两个完全独立的安全因子，来降低故障的概率。

[Ye Zhang]

我们秉持着长期主义的理念来思考 ZK Rollup 的去中心化路线图。先去中心 Sequencer 还是 Prover，甚至如何定义 ZK Rollup 的去中心化，我们都有自己的想法。我认为最终我们将同时去中心化 Sequencer 和 Prover。但是我们有一些略微不同的优先排序，我们希望先将 Prover 去中心化。安全性绝对是重要原因之一。如果先将 Sequencer 去中心化，那在 zkEVM 变得非常成熟稳健之前，如果有人真的发现了一些漏洞并提交了虚假证明，它有一定概率会被 Sequencer 接受并出块，对系统造成破坏。

因此，我们会先保留中心化的 Sequencer。因为 zkEVM 是有可能出现漏洞的，因为它是非常复杂的系统。因此，我们希望至少在早期阶段，我们控制中心化的排序，至少能保证正确有效的出块。

另一个先去中心化 Prover 的原因是，有许多硬件公司正在寻找如何使 zkEVM 更高效的方案。如果我们承诺去中心化 Prover 的这种方案，他们会参与优化系统的代码。我们都知道，ZK ASIC 可能需要一年以上才能问世，如果我们首先进行 Prover 的去中心化，他们将更有动力为我们的系统进行构建，使系统变得更加高效。Sequencer 的去中心化是我们后面计划要做的事情。

这里还要考虑一个更复杂的因素，如果将 Prover 和 Sequencer 分配到两个不同的群体，则需要非常小心地设计激励方案，例如分配到这两方的奖励的比例，如何能够做到足够合理且平衡两方的激励。

除此之外，我们还有一些其他的安全手段。例如，我们正在构建的方式是开源的，我们正在进行一些内部安全审计，而不仅仅是外部审计。我们拥有一个非常强大的安全团队。我们提供各种资金资助来鼓励更多人参与安全方案的构建，比如形式化验证等工具。我们团队还曾经在 Consensys ZKEVM 和 Aztec 的电路上找到过漏洞。我们正在尝试改善整个生态系统的安全性。

[Matt Finestone]

Taiko 可能会更早地面临这种挑战。尽管大家都有一定程度的去中心化，但实际上我们也在计划和以太坊保持一样的方式，包括 EVM、Gas 时间表和状态树等，同时也考虑到 Ethos 和其他去中心化（我们称之为）Sequencer Proposer，以及 Prover。在几个月前的第一个测试网中，约有 2000 独立个人或地址无需许可的 Propose 一个区块。尽管可能存在一些恶意区块，但这也是去中心化的承诺。我认为这不是渐进式的去中心化，或许是渐进式的效率提升，因为你必须放弃一些效率。Proposer 可能会建立相同的区块，导致有些交易冗余，同时也付出了一些向 Layer 1 支付了 ETH 的有价值的区块空间。有些人会得到退款，有的会直接跳过。

对我们来说，我们在下一个即将到来的测试网中立即实现去中心化不太现实。Permissionless provers 在测试网环境中比较难，因为有女巫攻击，人们会让 proposed block 中充满垃圾信息，而 Prover 必须花费真正的计算资源证明它们，但却没有实际收入。

因此，我们将使用 Permissioned Proposer，让任何去中心化的 Prover 提交区块，并得到相应的奖励，这个很重要。另外，如果系统出现故障，一个 Prover 提交了有效性证明，同时也出现了一个不一致的证明被提交，那么智能合约就可以知道并且暂停。它会识别到为什么有两个正确的有效性证明在不同的块上？出现这种情况立即暂停，也就引发了时间延迟。如 Alex 所说，我们当前无法对完全无需许可、无需信任的实施感到放心，我们要努力实现平衡。

[Mikhail Komarov]

我们从一开始就考虑了这个问题。一些人最初的解决方案是自上而下的方法，例如决定创建 Rollup，然后考虑去中心化的次序问题，比如先去中心化 Sequencer。然后去中心化 Prover，一环接一环。相比之下，我们采用了一种不同的方法，我们自下而上来解决问题。

我们首先建立了一个去中心化的 Prover 网络，来无需许可地汇集算力。然后我们试图在 Prover 网络的基础上添加 Sequencer，因为 Sequencer 必须和 Prover 网络紧密结合，特别是与成熟的去中心化 Prover 网络。这里涉及到需要支付额外的证明费用，通信的复杂性等问题，所以 Sequencer 必须紧密结合 Prover 网络，以确保其有效性。我们所开发的系统可以作为 ZK Rollup 的底层基建。

为了确保所有的证明生成都有一个激励机制来加速完成，并提高质量和保持安全性，我们引入了证明市场（Proof market）来管理所有证明的生成和排序。同时，我们保持了这个系统的去中心化和无需许可性。这种方法是从底层解决问题，而不是从顶层解决问题。

[Brian R]

我认为我们采取的方法，与其他网络有很大的不同。类似于 Nil 团队正在建立的证明市场（Proof market），但是我们采用了一种更无需信任的方式。我们当前没有关注 Sequencing 的问题，而是关注在证明系统上，让它能够更加强健地进行各种运算。这种方法简化了很多复杂性，有利于尽快将最多的计算量投入市场。

我们希望降低开发人员的使用门槛，让他们在以太坊或任何系统上建立任何他们想要的应用程序，并拥有这个去中心化的基础计算层，用零知识证明来保证计算的正确性。

Q 5. 观众：在 Algorand 中，出现了一种名为 State Painting 的技术。它的基本思想是从一个共识区块链中提取状态，并将其「Paint」到另一个共识区块链上。这种技术更像是一种跨链方案，同时运用到了零知识证明的方案。那在 Layer 2 中，系统共识其实依赖于 Layer 1 的共识，这样是否会降低 Layer 2 的安全性？

[Alex Gluchowski]

在 ZK Rollups 的实施中，Layer 1 和 Layer 2 的之间的资产流动是完全无需信任的，Layer 2 完全承接了 Layer 1 的安全性。关于资产在 Layer 2 之间的转移，如果你是通过以太坊 Layer 1 的原生桥接，那么它也是完全无信任的。但是，如果没有通过 Layer 1 ，其安全性取决于通过哪种跨链方式实现桥接。

在 zkSync 中，我们正在实现一种被称为 Hyperchain 的方案。具体而言，我们将建立多个由相同电路驱动的链，这些链仍然通过以太坊上进行桥接。Hyperchain 将提供免费的、完全无信任的、非常便宜的交易，可以从任何链到任何其他链。当我们谈论将数亿甚至数十亿的用户引入区块链时，这一点非常重要。

在未来，我们不可能让数以万亿的交易都运行在一个单一的系统或共识上。它们将不得不在许多不同的共识系统上运行，比如分片、独立的应用链等。但同时我们需要保证这些不同链之间的可连接和通信的低成本。

打个比方，就像我们今天使用不同系统的电子邮件，用户可以轻松地完成不同电子邮件系统之间的通信。这就是我们希望通过 Hyperchain 实现的东西。除了完美地承接 Layer 1 的安全性，高效且无需信任的跨链通信，Hyperchain 还可以通过递归证明来实现使用的超低成本。