Cartesi Rollups 之 链上篇

Rollup 目前是以太坊社区的一个热门话题，这是有充分理由的。很明显，当前的以太坊架构还没有准备好大规模采用，gas 费用波动很大，网络有时候也异常拥堵，整个 DApp 实际上难以使用。众所周知的可扩展性问题已被证明很难在不影响安全性和去中心化的情况下解决。然而，Rollup 正在获得越来越多的关注和支持，几乎被普遍认为是解决以太坊可扩展性困境的关键解决方案之一。Vitalik 本人为以太坊提出了一个以Rollups为中心的路线图，值得一读。

在 Cartesi，我们正在构建一个Rollups解决方案。查看我们优秀同事之前撰写的文章：Rollups 推出公告介绍了我们解决方案的不同部分，并提供了对每个部分的简要说明。寻找更多细节的读者可以深入研究 Erick de Moura 的“Cartesi Rollup — 使用主流软件堆栈构建可扩展智能合约”，在那里他们会找到我们许多设计决策背后的推理以及对Rollups行为的深入解释。

本文是 Rollup 展示系列的一部分，旨在让用户和开发人员快速了解我们在 Rollups 团队中构建的内容。本系列发布了两篇很棒的文章：状态折叠和交易管理器。他们都引入了有助于与区块链交互的开源 Rust 工具。在本文中，我们将总结我们之前写过的一些主题并对其进行扩展。然后，我们将专注于使 Cartesi Rollups 成为可能的链上智能合约。

有多种方法可以将区块链的可扩展性概念化，但通常分为两个主要部分：数据可扩展性和执行可扩展性。Rollups 主要处理后者——改进前者是一个偶然的结果。正如他经常做的那样，Vitalik Buterin 写了一篇内容丰富的帖子，其中他强调了推荐的数据和执行之间的关系。

简而言之，Rollups通过将大部分计算移到区块链之外来实现可扩展性，使用分类帐本作为数据源而不是执行环境。因此，Rollups解决方案包含链下和链上组件。

用户通过以太坊交易与Rollups进行交互。他们向它发送消息（输入），定义要处理的计算并推进Rollups机器的状态。感兴趣的各方运行一个链下组件来观察区块链的输入——理解和执行状态更新。偶尔，机器的状态会在链上进行检查。

必须负责任地检查链上状态，这是由链上部分保证的。在这里，重要的是区分两种可能的保持状态更新的方法：有效性证明和欺诈证明。

在有效性证明方案中，每个状态更新都伴随着一个在链外创建的加密证明，以证明其有效性。仅当证明成功通过链上验证时才接受更新。零知识证明经常用于此，这就是为什么这些类型的Rollups通常被称为 ZK Rollups。有效性证明带来了即时终结的巨大好处——一旦状态更新出现在链上，它们就可以被完全信任并采取行动。然而，这种选择也带来了不太理想的特性：在可能的情况下，为通用计算生成 ZK 证明非常昂贵，并且每个链上状态更新都必须支付额外的 gas 费用，以包含和验证有效性证明。

防欺诈方案以不同的范式运作。状态更新没有伴随证明，它们是被提议的，如果没有受到质疑，则在链上确认。挑战状态更新提议是通过使用欺诈证明来完成的，欺诈证明可以分为两类：非交互式欺诈证明和交互式欺诈证明。

非交互式是指挑战者可以一步证明状态更新无效。通过交互式欺诈证明，索赔者和挑战者必须通过区块链进行调解，参与类似于验证游戏的活动。状态更新最有可能是诚实的假设通常为这样的解决方案提供了Optimistic Rollups的名称。自然地，这种乐观情绪与诚实行为的经济激励相结合，并保证除非提议的虚假状态在很长一段时间内是无可争议的，否则它永远不会被接受。

在 Cartesi，我们选择创建具有交互式欺诈证明的 Optimistic Rollup。选择交互式模型是因为它对可以执行的计算大小施加了更高的上限。通过 Cartesi Rollups，我们正在解决本文开头未提及的额外可扩展性方面：社交可扩展性。

开发人员将能够使用他们习惯的主流软件堆栈、库和工具来构建他们的 DApp 的想法对我们来说非常宝贵。我们希望弥合日常开发人员和区块链开发人员之间的差距。我们希望开发人员构建不可能的 DApp，这些 DApp 需要复杂而强大的软件堆栈。

解决社会可扩展性需要一个很棒的 VM，我们构建了一个。Cartesi Machine 在确定性 RISC-V 架构上运行，能够运行通用的完全独立的 Linux 操作系统。在为开发人员提供在 VM 上快速运行 Linux 的能力时，我们还需要让他们访问能够裁定大量计算的争议解决方法——例如验证游戏。

如前几节所述，Rollups将执行环境移动到第 2 层，但仍使用第 1 层来保证其数据可用性。然而，这并不意味着将执行带到第 2 层不会对链上数据量和交易成本产生积极影响。

有多种策略可以将改进的执行环境转化为更有效的数据处理方式。由于智能合约不必知道大部分数据，因此可以以更便宜的方式将其存储在以太坊内（例如，调用数据而不是存储）。还可以通过使用压缩方法和签名聚合等技术将数据转换为计算。这就是聚合器所做的，他们在链外接收输入并将它们分批处理成一个单一的包，然后再将它们发送到区块链。其背后的想法是，通过聚合用户的签名，他们可以稀释该交易包中每个用户的成本——创造更便宜的交易。

在创建聚合方案时，需要做出许多不同的设计决策。这些选择会影响各种不同的功能，例如订单保证、审查阻力和 AEV（聚合器可提取价值）。我们对这些概念的设计和分析的详细信息将在后面的文章中介绍。

从全球共识到本地共识的转变意味着必须保证少数感兴趣的参与者的数据可用性。因此，Hungry DApps 可以选择不同的数据源来存储数据，只要他们的用户对权衡感到满意。

Rollups智能合约旨在调解链下Rollups与其他智能合约和外部拥有账户 (EOA) 之间的关系，是为模块化而构建的。每个模块都有明确的职责，并通过定义良好的接口与其他模块进行通信。在定制、配置和升级每个部分时，这为我们提供了很大的灵活性。例如，DApp 需要不同模型来进行链上输入时可以轻松地将其替换为当前的实现。

有两种不同的代理与智能合约基础设施交互：用户和验证者。两者都运行链下节点，但以不同的方式与链上Rollups交互。验证者的任务是检查链上链下机器的状态，其中包括打击可能的不诚实验证者以确保诚实声明的流行。另一方面，用户直接或通过聚合器向机器发送输入，并执行他们感兴趣的输出。

为了避免与区块链过度交互，验证者不会在链下机器上检查每个状态更新。他们在一个 epoch 结束时进行，这是遵循相同周期的批量输入。

我们可以想象三个不同状态的时代：

• 累积，当epoch打开并等待输入时。

• 密封，当该epoch的输入明确定义并且验证者准备或发送他们的声明时。密封的epoch也可能存在争议。

• 最终阶段，当达成共识并且输出可以安全执行时。

链上机器，取决于它所处的阶段，可以包含一到两个 epoch。这些是可能的阶段：

• 输入累积：有一个单一的累积时期，处于活动状态并等待将要批处理的输入。

• 等待共识：有两个epoch。一个密封的，验证者正在准备或发送他们的声明，以及一个累积的，它是活跃的并接收输入。

• 等待争议：也有两个epoch。一个密封，一个累积。密封的epoch是有争议的。收到了两个相互矛盾的声明，验证者正在参加一个验证游戏来决定哪个声明成立。由于密封epoch的输入是明确定义的，诚实的验证者将始终达到相同的要求。争议必然意味着索赔可证明是错误的。

之前提到的 Cartesi Rollups 文章中解释了阶段变化的触发器。

既然epoch、阶段和交互都是已知的，让我们回顾一下每个链上模块并解释它们的目的：

DescartesV2 管理器

DescartesV2 管理器负责模块之间的同步。它定义了不同阶段的持续时间，并将任何阶段变化通知其他模块。其中，该模块的职责是：

根据当前状态和截止日期，定义输入的目的地。

接收声明并将其转发给验证器管理器。

将争议转发到争议解决模块。

将争议结果转发给验证者管理器。

将最终输出的摘要转发到输出模块。

通知其他模块相变。

输入

对于区块链来说，输入只是一系列无意义的字节，它们形成了第 2 层可以理解的消息。链上执行资源不会浪费在试图理解输入的过程中——我们依靠 VM 的计算能力在链下解压缩、解释和处理它们。

如上所述，链上合约通常有两个并发的 epoch：一个密封但未完成的 epoch 和一个累积 epoch。输入合约为每个 epoch 保留一个收件箱，根据 Descartes V2 管理器通知在它们之间切换。对于任何人都能够从一开始就同步机器而无需信任数据提供者，输入的完整内容始终存在于 calldata 中。在存储时，需要以更简洁的方式使用，我们为活动时期的每个输入保留一个哈希。这个输入哈希总结了输入本身及其元数据——发送者的地址和接收时间。请注意，此输入实现是无权限的，权限层被委托给链下机器，例如，该机器将判断是否允许发送者执行其输入想要执行的操作。

门户

门户，顾名思义，用于将资产从以太坊区块链传送到在 Cartesi Rollups 上运行的 DApp。一旦存入，这些第 1 层资产就会在第 2 层中获得代表权，并且在那里由存款人将它们分配给任何人拥有。在被传送之后，第 2 层资产可以以一种非常便宜的方式移动，使用 Linux 逻辑可以理解的简单输入。当资产被存入时，Portal 合约向 DApp 的收件人发送一个输入，描述资产的类型、金额、接收者和存款人可能希望 DApp 读取的一些数据。这允许存款和指令作为单个第 1 层交互发送。

人们可以将 Portal 视为一个银行账户，由链下机器拥有。任何人都可以在那里存入资产，但只有 DApp——通过其输出合约——可以决定提款。从用户的角度来看，提款过程非常简单。他们发送一个请求提款的输入，该输入在链外进行处理和解释。如果一切正常，机器会创建一个输出到 Portal 合约，订购并完成提款请求。

输出

输出是以字节为单位的目标地址和有效载荷的组合。链下机器使用它来响应第 1 层智能合约并与之交互。当输出被执行时，他们会简单地向目标地址发送一条消息，并将有效负载作为参数。因此，输出可以是任何东西，从在 DeFi 协议中提供流动性到从门户中提取资金。每个输入都可以生成许多输出，一旦包含它们的时epoch完成，这些输出将可供执行。

虽然输出合约也对正在执行的输出内容漠不关心，但它在允许其执行之前强制执行一些完整性检查：输出是唯一的，只能成功执行一次。输出是异步执行的，不需要访问检查。执行顺序没有强制执行——只要输出包含在最终确定的epoch中并且之前没有执行过，合约就允许任何人执行它们。然而，输出模块确保只有链下机器建议的输出和链上最终确定的输出才能被执行。它通过要求与执行调用一起发送有效性证明来实现。

验证管理器

Validator Manager 模块的创建是为了帮助 DApp 管理他们的声明、声明权限和对不良行为的惩罚。最初，我们对该模块的建议实现包括以下特征：可支付验证器的集合是在构建时定义的，验证器为每个 epoch 发送claim，而那些失去争议的验证器将被踢出验证器集。如上所述，Descartes V2 管理器接收声明并将它们重定向到验证管理器。当收到一个声明时，验证管理器检查哪些其他声明已经到达那个时期，并返回 Descartes V2 管理器需要继续的信息。该模块可以通过以下方式之一响应收到的claim：

• 如果发件人不是验证者或声明无效，则交易将恢复。

• 如果声明是有效的，不与 epoch 中的任何其他声明不一致，并且没有产生共识，则返回“无冲突”响应。

• 如果声明有效但不同意该epoch的另一个声明，它会警告 DescartesV2 Manager 正在发生冲突以及冲突的声明和所涉及的声明者是什么。当争议得到解决时，验证管理器模块会收到通知，因此它可以根据需要处理所涉及的验证器。在我们最初建议的实现中，争议的失败者将从验证者集中删除。

• 如果声明是有效的，与那个时期的所有其他声明一致，并且是最后收到的声明，它会让 Descartes V2 知道已经达成共识。这允许Rollups DApp 完成时代并允许执行其输出。

无论名称如何暗示，验证器根本不与此模块交互。

争议解决

当两个验证者声称对同一epoch进行不同的状态更新时，就会发生争议。由于我们虚拟机的确定性以及构成一个epoch的输入事先达成一致的事实，相互矛盾的声明意味着不诚实的行为。当发生冲突时，调解两个验证者之间交互的模块是争议解决。

Cartesi rollups 是一个基础架构，旨在允许开发人员构建令人惊叹的应用程序——它的价值来自于在它之上创建的所有很酷的东西。在开发这种框架时，发布具有明确定义接口的初始版本通常很有趣，然后不断改进。以这种方式发布软件的目标是允许开发人员并行构建他们的应用程序，而不必等待基本框架的原始最终实现。

争议是可以添加的基础设施的一个例子，因为它们很少见并且不会严重影响 DApp 的行为——除了可能延迟最终确定。因此，为了加速部署并让开发者尽早与我们一起构建，我们决定毫无争议地发布第一个版本。

话虽如此，我们根本没有忽视建立争端。事实上，我们的 Descartes SDK 有一个争议模块，它利用了我们的仲裁 dlib。仲裁 dlib 为我们的 RiscV VM 实现了前面提到的验证游戏。然而，对于 Cartesi Rollups，在集成仲裁 dlib 时还有一些额外的工作要做：我们现在需要找到验证器不同意的确切输入。好消息是，当您在我们的Rollups之上实施所有这些很酷的 DApp 时，我们正在实施一个强大的争议解决模块，该模块将易于连接。

在 Cartesi，我们拥有一支非常强大的研究团队，一直在研究新的设计、解决方案和改进。赶上我们一直在做的所有很酷的研究，对工程来说通常是一个挑战。因此，我们希望为 DescartesV2 实现一系列改进：架构更新、gas 优化、示例应用程序、改进的链下组件等。敬请关注！

特别感谢Augusto Teixeira  和Gabriel Coutinho de Paula  的反馈和审核。

Cartesi正在将智能合约推向新的高度。它是一个与链无关的第二层基础架构，解决了区块链上最紧迫的可扩展性问题。最值得注意的是，Cartesi实现了独特的支持Linux的VM，rollups和侧链，以彻底改变开发人员创建区块链应用程序的方式，允许他们使用主流软件组件。