一篇文章带你深入理解 Arbitrum

一. 项目概述

Arbitrum 是一套以太坊扩展解决方案,可实现高吞吐量、低成本的智能合约,同时保持无需信任的安全。Arbitrum 具有三种模式:AnyTrust Channels、AnyTrust Sidechains 和 Arbitrum Rollup。

二. 项目架构

Aggregator: 它还接收来自用户的交易并代表他们分批提交 Forwarder: 接收交易并直接将它们转发到另一个节点而不做任何事情 Sequencer: 定序器是一个特别指定的全节点,被赋予有限的权力来控制交易的顺序。

1. 批处理交易:全节点作为聚合器

全节点的一个重要角色是充当聚合器,这意味着全节点从用户那里接收一组已签名的交易,并将它们组装成一个批次,然后作为一个单元提交到链的收件箱。分批提交交易比逐个提交更有效率,因为每次提交都是到 EthBridge 的 L1 交易,而以太坊对每笔交易的基本成本为 21,000 L1 gas。提交批次允许将固定成本(和其他一些固定成本)摊销到更大的用户交易组中。也就是说,提交一批是未经许可的,因此任何用户都可以在需要时提交单个交易“批”;因此,Arbitrum 继承了与以太坊相同的审查阻力。 代表用户提交交易的聚合器将产生成本,因为它使用 L1 交易将这些交易提交到收件箱合约。Arbitrum 包括向用户收取费用的设施,以补偿聚合器的成本。

2. 压缩交易

除了批处理事务,全节点还可以压缩事务以节省 L1 调用数据空间。压缩对用户和在 Arbitrum 上运行的合约是透明的——他们只能看到正常的未压缩交易。流程是这样的:用户向全节点提交普通交易;全节点压缩交易并提交到链上;ArbOS 收到交易并解压缩以恢复原始交易;ArbOS 验证交易的签名并处理交易。 压缩可以使事务中的“标头信息”更小。全节点通常在提交事务时同时使用压缩和批处理。

3. Sequencer

定序器模式是 Arbitrum 链的可选功能,可以为每个链打开或关闭。我们希望它可以为大多数链启用。Arbitrum One 使用由 Offchain Labs 操作的定序器 定序器是一个特别指定的全节点,被赋予有限的权力来控制交易的顺序。这允许定序器立即保证用户交易的结果,而无需等待以太坊上发生任何事情。因此,无需等待 5 分钟左右即可确认区块——甚至无需等待 15 秒即可让以太坊出块。 如果没有定序器,节点可以预测客户端事务的结果,但节点不能确定,因为它无法知道或控制它提交的事务将如何在收件箱中排序,相对于事务由其他节点提交。 定序器对排序有更多控制权,因此它有权为其客户的交易分配收件箱队列中的位置,从而确保它可以立即确定客户交易的结果。排序器重新排序的能力是有限制的,但它确实比其他任何人都更有能力影响交易排序。

4. inbox

当我们添加一个排序器时,收件箱的操作发生了变化。 - 只有定序器可以将新消息直接放入收件箱。定序器用以太坊区块号和时间戳标记它正在提交的消息。(ArbOS 确保这些不减少,必要时向上调整它们以避免减少。) - 其他任何人都可以提交消息,但非排序节点提交的消息将被放入“延迟收件箱”队列,该队列由 L1 以太坊合约管理。 - 延迟收件箱队列中的消息将在那里等待,直到排序器选择将它们“释放”到主收件箱中,在那里它们将被添加到收件箱的末尾。行为良好的定序器通常会在大约十分钟后释放延迟的消息,原因如下所述。 - 或者,如果邮件在延迟收件箱队列中的时间超过最大延迟间隔(当前为 24 小时),那么任何人都可以强制将其提升到主收件箱中。(这确保了定序器只能延迟消息,但不能审查它们。)

三. 交易的生命周期

一个交易的生命周期如下图所示:

批处理提交交易如下:

四. Arbi 的仲裁解决

1. 为什么使用仲裁

Arbitrum 是以太坊的 L2 扩展解决方案,提供独特的优势组合:

  • 无需信任的安全性:植根于以太坊的安全性,任何一方都能够确保正确的第 2 层结果
  • 与以太坊的兼容性:能够运行未修改的 EVM 合约和未修改的以太坊交易
  • 可扩展性:将合约的计算和存储移出以太坊主链,允许更高的吞吐量
  • 最低成本:旨在最大限度地减少系统的 L1 气体足迹,最大限度地降低每笔交易的成本。

2. Arbi 的基本工作原理

在最基本的层面上,Arbitrum 链的工作方式如下:

人员和合约将消息放入收件箱。链一次读取一条消息,并处理每一条消息。这会更新链的状态并产生一些输出。

如果您希望 Arbitrum 链为您处理交易,您需要将该交易放入链的收件箱。然后链会看到你的交易,执行它,并产生一些输出:交易收据,以及你的交易所做的任何提款。

执行是确定性的——这意味着链的行为由其收件箱的内容唯一确定。因此,一旦您的交易被放入收件箱,您的交易结果就可以知道。任何 Arbitrum 节点都可以告诉您结果。(如果需要,您可以自己运行 Arbitrum 节点。)

3. 交互式证明

Arbitrum 是一个RollUp,这意味着链的输入——放入收件箱的消息——都作为 calldata 记录在以太坊链上。正因为如此,每个人都拥有确定链当前正确状态所需的信息——他们拥有收件箱的完整历史记录,结果由收件箱历史唯一确定,因此他们可以重建链的状态如果需要,仅基于公共信息的链。

这也允许任何人成为 Arbitrum 协议的完全参与者,运行 Arbitrum 节点或作为验证者参与。关于链条的历史或状态,没有什么是秘密。

Arbitrum 是乐观的 RollUp,对于执行的结果不满意都可以发起挑战,说谎者将没收押金,而说真话的人将收取部分押金作为对他们努力的奖励。

交互式证明的想法是 Alice 和 Bob 将参与一个由 L1 合约引用的来回协议,以任何 L1 合约所需的最少工作量来解决他们的争议。

Arbitrum 的方法是基于对争议的剖析。如果 Alice 的声明涵盖了 N 个执行步骤,她发布了两个大小为 N/2 的声明,它们结合起来产生了她的初始 N 步声明,然后 Bob 选择 Alice 的 N/2 步声明中的一个来挑战。现在争议的规模已经减少了一半。这个过程继续进行,在每个阶段将争议减半,直到他们对执行的单个步骤产生分歧。请注意,到目前为止,L1 裁判不必考虑“根据案情”执行。只有将争议缩小到一个步骤,L1 裁判才需要通过查看指令实际执行的操作以及 Alice 关于它的声明是否正确来解决争议。

交互式证明背后的关键原则是,如果 Alice 和 Bob 发生争议,Alice 和 Bob 应该尽可能多地做链下工作来解决他们的争议,而不是把这些工作放到 L1 合约上。

3.1 交互式证明的优势

  • 在乐观和悲观的情况下更有效
  • 更高的每笔交易气体限制
  • 合约大小没有限制
  • 更大的实现灵活性

3.2 仲裁架构

在左侧,我们有帮助他们连接到他们选择的链的用户和服务提供商。在右边,有 Arbitrum 系统本身,构建在以太坊之上并继承了以太坊的安全性。

以太坊之上是EthBridge,一组管理 Arbitrum 链的以太坊合约。EthBridge 对 Arbitrum 汇总协议进行裁判,以确保其上方的层正确运行。EthBridge 还维护链的收件箱和发件箱,允许人和合约向链发送交易消息,并观察和使用这些交易的输出。用户、L1 以太坊合约和 Arbitrum 节点调用 EthBridge 合约以与 Arbitrum 链进行交互。

EthBridge 上方的水平层边界标记为AVM 架构,因为 EthBridge 为其上方的层提供的是一个 Arbitrum 虚拟机,它可以执行读取输入并产生输出的计算机程序。这是 Arbitrum 中最重要的接口,因为它将第 1 层与第 2 层分开——它将提供收件箱/执行/发件箱抽象的第 1 层组件与使用该抽象的第 2 层组件分开。

下一层是ArbOS。这是一个由 Offchain Labs 编写的软件程序,在 Arbitrum 虚拟机上运行,并作为记录保存者、交通警察和执行者在 Arbitrum 链上执行智能合约。它之所以被称为 ArbOS,是因为它扮演的角色类似于笔记本电脑或手机上的操作系统(轻量级版本)——它是首先启动并管理链上所有其他代码执行的程序。重要的是,ArbOS 完全在以太坊链之外的第 2 层运行,因此它可以利用第 2 层计算的可扩展性和低成本。

ArbOS 上方的水平层边界称为EVM 兼容性,因为 ArbOS 为智能合约提供了与以太坊虚拟机兼容的执行环境。也就是说,您可以将合约的 EVM 代码发送给 ArbOS,就像您将该合约发送到以太坊一样,ArbOS 将加载合约并使其能够为交易提供服务,就像在以太坊上一样。ArbOS 负责兼容性的细节,因此智能合约程序员可以像在以太坊上一样编写他们的代码(或者通常只使用现有的以太坊合约并重新部署它们)。

在堆栈的顶部(图表的右上部分)是EVM 合约,这些合约已由开发人员部署到 Arbitrum 链,并执行提交给链的交易。

这是图表的右侧,它提供了 Arbitrum 链功能。现在让我们转向左侧,更直接地支持用户。

左下方是标准的以太坊节点,用于与以太坊链进行交互。就在上面是Arbitrum 节点。顾名思义,这些用于与 Arbitrum 交互。它们支持与以太坊节点相同的 API,因此它们可以很好地与现有的以太坊工具配合使用——您可以将与以太坊兼容的钱包或工具指向 Arbitrum 节点,它们将能够相互交谈。就像在以太坊上一样,任何人都可以运行 Arbitrum 节点,但很多人会选择依赖其他人运行的节点。

一些 Arbitrum 节点为用户请求提供服务,而另一些则选择仅充当验证者,以确保 Arbitrum 链的正确性。

用户可以完全使用以太坊生态的工具和 Arbitrum 进行交互。

3.3 线上还是线下

线下功能与确保 AVM 以及链正确执行有关。上述功能假设 AVM 将正确执行,并专注于与在第 2 层运行的软件进行交互。

Arbitrum 验证器在线下运行,因为它们参与由 EthBridge 在线下管理的汇总协议,以确保确认 AVM 的正确执行。

Arbitrum 完整节点在线上运行,因为它们在本地运行 AVM 的副本,并假设线下机制将确保它们在本地计算的相同结果最终将由下线确认- 他们不监控的线路机制。

3.4 EthBridge

EthBridge 是一组管理 Arbitrum 链的以太坊合约。EthBridge 跟踪链的收件箱内容、链状态的哈希以及有关输出的信息。EthBridge 是 Arbitrum 链中正在发生的事情的最终权威来源。

EthBridge 是构建 Arbitrum 安全性的基础。EthBridge 在以太坊上运行,因此它是透明的并且无需信任地执行。

Inbox合约管理链的收件箱。收件箱跟踪收件箱中每条消息的(散列)。调用 Inbox 的 send* 方法之一会将消息插入 Arbitrum 链的收件箱。

Inbox 合约确保传入消息中的某些信息是准确的:发送者被正确记录,以太坊区块号和时间戳被正确记录在消息中。

Outbox合约,用于管理链的输出;来自 Arbitrum 的关于应该(最终)在以太坊上发生的事情(特别是提款)的消息。确认汇总块后,该汇总块中产生的输出将被放入发件箱。

Rollup 合约及相关的合约负责管理 rollup 协议。他们跟踪 Arbitrum 链的状态:已提议、接受和/或拒绝的汇总块,以及谁在哪些汇总节点上质押。挑战合约及其朋友负责跟踪和解决验证者之间关于哪些汇总块是正确的任何争议。

4. Arbi 的 RollUp

汇总协议只确认结果。结果由链的收件箱中的消息序列唯一确定。因此,一旦您的交易消息在链的收件箱中,其结果是可知的——Arbitrum 节点将报告您的交易已完成。汇总协议的作用是确认对于 Arbitrum 用户而言已经发生的交易结果。如果每个人都已经知道交易的结果,为什么还要麻烦确认呢?需要汇总协议的两个原因,一个是有人会说谎,另一个是 ETH 并不知知道 Arbi 上面的执行结果。

4.1 汇总链

汇总协议跟踪汇总块链。这些与以太坊区块是分开的。您可以将汇总块视为形成一个单独的链,由 Arbitrum 汇总协议管理和监督。

验证者可以提出汇总块。新的汇总块首先将无法解决。最终,每个汇总块都将通过确认或拒绝来解决。确认的区块构成了链的确认历史。

每个汇总块包含:

  • 汇总块编号
  • 前任块号:在这个(声称是)正确的块之前的最后一个块的汇总块号
  • 链在其历史中完成的计算量(以 ArbGas 衡量)
  • 链历史中已消费的收件箱消息数
  • 在链的历史上产生的输出的哈希
  • AVM 状态的哈希值。

除了 rollup 区块编号,区块的内容都只是区块提议者的声明。Arbitrum 起初并不知道这些字段是否正确。如果所有这些字段都正确,则协议最终应确认该块。如果这些字段中的一个或多个不正确,协议最终应该拒绝该块。

一个块隐含地声称它的前一个块是正确的。这意味着,一个块隐含地声称链的完整历史的正确性:一系列祖先块,一直追溯到链的诞生。

一个块也隐含地声称它的兄弟姐妹(具有相同前身的旧块),如果有的话,是不正确的。如果两个块是兄弟,并且年长的兄弟是正确的,则认为年幼的兄弟是不正确的,即使年幼的兄弟中的其他所有内容都是正确的。

该块被分配了一个截止日期,该截止日期表示其他验证者必须对其做出响应的时间。如果您是验证者,并且您同意汇总块是正确的,则无需执行任何操作。如果您不同意汇总区块,您可以发布另一个具有不同结果的区块,您最终可能会面临与第一个区块的质押者的挑战。

在正常情况下,汇总链将如下所示:

在左边,代表链历史的早期部分,我们已经确认了汇总块。这些已被 EthBridge 完全接受并记录下来。最新的已确认区块,即区块 94,称为“最新确认区块”。在右侧,我们看到一组更新的建议汇总块。EthBridge 还不能确认或拒绝他们,因为他们的截止日期还没有用完。命运尚未确定的最古老的区块 95 被称为“第一个未解决的区块”。

请注意,提议的区块可以建立在先前提议的区块之上。这允许验证者继续提出区块,而无需等待 EthBridge 确认前一个区块。通常,所有提议的区块都是有效的,因此它们最终都会被接受。

如果多个验证器是恶意的,这是链状态可能看起来的另一个示例。这是一个人为的例子,旨在说明协议中可能出现的各种情况,所有情况都被分解成一个场景。

这里发生了很多事情,所以让我们打开它。

  • 区块 100 已被确认。
  • 块 101 声称是块 100 的正确继承者,但 101 被拒绝(因此在其中绘制了 X)。
  • 区块 102 最终被确认为 100 的正确继承者。
  • 区块 103 已确认,现在是最新确认的区块。
  • 块 104 被提议作为块 103 的后继者,而 105 被提议作为 104 的后继者。104 被拒绝为不正确,结果 105 被拒绝,因为它的前身被拒绝了。
  • 块 106 未解决。它声称是块 103 的正确继承者,但协议尚未决定是确认还是拒绝它。这是第一个未解决的块。
  • 块 107 和 108 声称从 106 链接。它们也未解决。如果 106 被拒绝,它们也会被自动拒绝。
  • 块 109 不同意块 106,因为它们都声称相同的前任。至少其中一个最终会被拒绝,但协议尚未解决它们。
  • 块 110 声称跟随 109。它尚未解决。如果 109 被拒绝,110 也会被自动拒绝。
  • Block 111 声称跟随 105。111 将不可避免地被拒绝,因为它的前身已经被拒绝了。但是还没有被拒绝,因为协议是按照区块号顺序解析区块的,所以协议必须依次解析106到110,才能解析111。110被解析后,111可以立即被拒绝.

这种事情在实践中不太可能发生。在这个图表中,至少有四方必须在错误的汇总块上进行质押,当尘埃落定时,至少有四方将失去他们的质押。当然,该协议正确处理这些情况,但它们是罕见的极端情况。该图旨在说明原则上可能出现的各种情况,以及协议将如何处理它们。

4.2 质押

在任何给定时间,一些验证者将成为质押者,而另一些则不是。质押者存入 EthBridge 持有的资金,如果质押者失去挑战,将被没收。目前所有的链都接受 ETH 的股份。

单个权益可以覆盖一系列汇总块。每个质押者都被质押在最新确认的区块上;如果您被质押在一个区块上,您还可以质押该区块的一个继任者。因此,您可能会被押在一系列区块上,这些区块代表了关于链正确历史的单一连贯声明。一个股权就足以让您参与该区块序列。

为了创建新的汇总块,您必须是质押者,并且您必须已经质押在您正在创建的新块的前身上。区块创建的权益要求确保如果该区块最终被拒绝,任何创建新区块的人都会有损失。

EthBridge 跟踪当前所需的质押量。通常这将等于基础质押量,这是 Arbitrum 链的一个参数。但是,如果该链最近进展缓慢,则所需的质押将会增加。

质押规则如下:

  • 如果您没有质押,您可以质押最新确认的汇总区块。执行此操作时,您向 EthBridge 存入当前的最低赌注金额。
  • 如果您被质押在一个汇总区块上,您还可以将您的质押添加到该区块的任何一个后继区块。(EthBridge 会跟踪您质押的最大汇总区块数,并允许您将您的质押添加到该区块的任何后续区块,将您的最大值更新为该后续区块。)这不需要您放置新的质押。
  • 将您的质押添加到后继区块的一种特殊情况是,当您创建一个新的汇总块作为您已经质押的区块的继任者时。
  • 如果您仅在最新确认的区块(可能还有更早的区块)上进行质押,您或其他任何人都可以要求退还您的质押。您的质押资金将退还给您,您将不再是质押者。
  • 如果您输掉了挑战,您的质押将从所有区块中移除,并且您将没收您质押的资金。

请注意,一旦您被质押在汇总块上,就无法取消质押。最终会发生两件事之一:该区块将被确认,或者您将失去您的股份。取回您的质押的唯一方法是等到您质押的所有汇总块都得到确认。

设置当前最低投注额: 我们之前推迟的一个细节是如何设置当前的最低赌注金额。通常,这只是等于基础质押量,这是 Arbitrum 链的一个参数。但是,如果链在确认区块方面进展缓慢,则质押要求将暂时升级。具体来说,基本权益数量乘以一个因子,该因子是自第一个未解决节点的截止日期过去以来的时间指数。这确保了如果恶意方放置虚假赌注以试图延迟进度(尽管他们正在失去这些赌注),则赌注要求会上升,因此这种延迟攻击的成本会成倍增加。随着区块决议再次开始推进,质押要求将回落。

5. 挑战

假设汇总链如下所示:

执行流程图:

块 93 和 95 是兄弟块(它们都有 92 作为前身)。Alice 质押在 93 上,Bob 质押在 95 上。

在这一点上,我们知道 Alice 和 Bob 不同意第 93 块的正确性,Alice 承诺 93 是正确的,而 Bob 承诺 93 是不正确的。(Bob 被质押在 95 上,而 95 声称 92 是它之前的最后一个正确区块,这意味着 93 是不正确的。)

每当有两个质押者被质押在兄弟区块上,并且这些质押者都没有处于挑战中时,任何人都可以在两者之间发起挑战。汇总协议将记录挑战并对其进行裁判,最终宣布获胜者并没收失败者的股份。失败者将作为质押者被移除。

挑战是爱丽丝和鲍勃交替移动的游戏,以太坊合约作为裁判。防御者爱丽丝首先移动。

游戏将分两个阶段进行:解剖,然后是一步证明。剖析将缩小争议的范围,直到争议只涉及一项执行指令。然后一步证明将确定谁对那条指令是正确的。

5.1 解剖协议

K-way dissection:将其声明分成大小为 N/K 的 K 个片段。这需要发布 K-1 中间声明,在声明的执行中间隔均匀的点。这将轮数减少了 log(K)/log(2) 倍。

用剖析来回答剖析:每次挑战移动的大小都会减少 K 倍

按 ArbGas 剖析,而不是按步骤剖析:我们不是通过执行的指令数来衡量间隔的大小,而是通过它消耗的 ArbGas 量来衡量。这允许协议精确地确定验证者检查声明的正确性需要多长时间(因为验证者检查时间与使用的 ArbGas 成正比),这允许协议更精确地设置汇总节点的截止日期。这样做的缺点是不同的指令需要不同数量的 ArbGas,因此我们不能再假设一段执行可以在精确的 N/K 步边界上结束。真实协议允许声明在其目标端点或之后的第一个指令边界处结束;正确性论证说明了各方可能会谎报段的正确端点在哪里。

处理空收件箱案例:真正的 AVM 无法始终执行 N 个 ArbGas 单元而不卡住。机器可能会停止,或者它可能不得不等待,因为它的收件箱已用尽,所以它不能继续,直到有更多消息到达。所以 Bob 必须被允许通过声称 N 个步骤是不可能的来回应 Alice 的 N 个执行单元的声明。因此,真正的协议允许任何响应(但不是初始声明)声明一个特殊的最终状态,这基本上意味着在当前条件下指定的执行量是不可能的。

时间限制:每个玩家都有时间限制。玩家用于所有移动的总时间必须少于时间限制,否则他们将输掉比赛。将时间津贴想象为大约一周。

5.2 效率

挑战协议的设计使得争议可以通过 EthBridge 作为裁判所需的最少工作来解决。当是 Alice 的移动时,EthBridge 只需要跟踪 Alice 使用的时间,并确保她的移动确实包含所需的 K-1 个中间点。EthBridge 不需要关注这些声明是否正确;它只需要知道爱丽丝的举动是否“有正确的形状”。

EthBridge 需要“根据优点”评估移动的唯一点是一步证明,它需要查看 Alice 的证明并确定所提供的证明是否确实确定虚拟机从一步计算后,从前状态到声明的后状态。

6. 验证器

一些 Arbitrum 节点将选择充当验证者。这意味着他们观察汇总协议的进展并参与该协议以安全地推进链的状态。

并非所有节点都会选择这样做。因为汇总协议不决定链将做什么,而只是确认完全由收件箱消息确定的正确行为,所以节点可以忽略汇总协议并简单地为自己计算正确的行为。

每个验证者都可以选择自己的方法,但我们希望验证者遵循三种常见的策略。

  • 主动验证者策略试图通过提出新的汇总块来提升链的状态。一个活跃的验证者总是被质押,因为创建一个汇总块需要被质押。一条链实际上只需要一个诚实的活跃验证者;再多就是对资源的低效利用。对于 Arbitrum One 链,Offchain Labs 运行一个活跃的验证器。
  • 防御性验证器策略监视汇总协议的运行。如果仅提出正确的汇总块,则此策略不会赌注。但是,如果提出了不正确的区块,该策略会通过发布正确的区块或在另一方发布的正确区块上进行干预来进行干预。当事情进展顺利时,这种策略会避免赌注,但如果有人不诚实,它会赌注以捍卫正确的结果。
  • 瞭望塔验证者策略从不赌注。它只是监视汇总协议,如果提出了不正确的块,它会发出警报(通过它选择的任何方式),以便其他人可以进行干预。该策略假设愿意进行质押的其他方将愿意进行干预以获取不诚实提议者的部分股份,并且这可能发生在不诚实区块的截止日期到期之前。(在实践中,这将允许几天的响应。)

在正常情况下,使用防御和瞭望塔策略的验证者除了观察之外不会做任何事情。正在考虑是否尝试作弊的恶意行为者将无法判断有多少防御和瞭望塔验证者正在隐身操作。也许一些防御性验证者会宣布自己,但其他人可能不会,因此潜在的攻击者总是不得不担心防御者正在等待出现。

谁将成为验证者?任何人都可以做到,但大多数人会选择不这样做。在实践中,我们希望人们出于几个原因来验证链。

  • 一些验证者将由创建链的一方或其他人支付。在 Arbitrum One 链上,Offchain Labs 将雇佣一些验证者。
  • 在链上拥有大量资产的各方,例如 dapp 开发人员、交易所、超级用户和流动性提供者,可以选择验证以保护他们的投资。
  • 任何选择验证的人都可以这样做。一些用户可能会选择验证以保护自己的利益或只是为了成为好公民。但是普通用户不需要验证,我们预计绝大多数用户不会。

7. AVM:仲裁虚拟机

Arbitrum 虚拟机 (AVM) 是 Arbitrum 的第 1 层和第 2 层部分之间的接口。第 1 层提供AVM 接口并确保虚拟机的正确执行。第 2 层在 AVM 虚拟机上运行,并提供部署和运行合约、跟踪余额以及支持智能合约的区块链需要做的所有事情的功能。

每个 Arbitrum 链都有一个 AVM,它完成所有计算并维护链上发生的所有事情的所有存储。与其他一些系统为每个合约都有一个单独的“VM”不同,Arbitrum 对整个链使用单个虚拟机,就像以太坊一样。Arbitrum 链上多个合约的管理由运行在 AVM 之上的软件完成。

在其核心,链的虚拟机在这个简单的模型中执行,从收件箱中消费消息,改变它的状态,并产生输出。

AVM 设计的起点是以太坊虚拟机 (EVM)。因为 Arbitrum 旨在高效地执行为 EVM 编写或编译的程序,所以 AVM 使用 EVM 的许多方面都没有改变。例如,AVM 采用 EVM 的基本整数数据类型(256 位大端无符号整数),以及对 EVM 整数进行操作的指令。

7.1 为什么 AVM 不同于 EVM

AVM 和 EVM 之间的差异是由 Arbitrum 的第 2 层协议的需求和 Arbitrum 使用交互式证明来解决争议的。

7.1.1 执行与证明

与 EVM 和类似架构不同,Arbitrum 支持执行(通过执行计算来提升计算状态,这在 Arbitrum 中总是在链下完成)和证明(说服 L1 合约或其他受信任方关于执行的声明是正确的) )。基于 EVM 的系统通过重新执行有争议的代码来解决争议,而 Arbitrum 则依赖于更有效的挑战协议,该协议会导致最终证明。

将执行与证明分离的一个很好的结果——并且永远不需要在 L1 链上重新执行代码块——我们可以针对它们将被使用的不同环境优化执行和证明。执行针对速度进行了优化在本地的、受信任的环境中,因为本地执行是常见的情况。另一方面,证明将不需要那么频繁,但即使在繁忙的以太坊 L1 链上也必须足够高效才能可行。很少需要证明检查,但证明必须始终是可能的。执行与证明的逻辑分离允许在不需要证明的常见情况下更积极地优化执行速度。

7.1.2 ArbOS 的要求

另一个不同的要求是 Arbitrum 使用 ArbOS,这是一个在第 2 层运行的“操作系统”。ArbOS 控制单独合约的执行以将它们彼此隔离并跟踪它们的资源使用情况。为了支持这一点,AVM 包括支持保存和恢复机器堆栈、管理跟踪资源使用的机器寄存器以及接收来自外部调用者的消息的指令。这些指令由 ArbOS 自己使用,但 ArbOS 确保它们永远不会出现在不受信任的代码中。

在第 2 层可信软件中支持这些功能,而不是像以太坊那样将它们构建到架构的 L1 强制规则中,在成本方面具有显着优势,因为这些操作可以受益于第 2 层的较低计算和存储成本,而不是不必将这些资源作为第 1 层 EthBridge 合同的一部分进行管理。在第 2 层拥有受信任的操作系统在灵活性方面也具有显着优势,因为第 2 层代码比第 1 层强制执行的 VM 架构更容易演变或为特定链定制。

使用第 2 层可信操作系统确实需要虚拟机指令集的一些支持,例如允许操作系统通过合约限制和跟踪资源使用情况。

7.1.3 支持默克尔化

任何依赖于断言和争议解决的第 2 层协议都必须为 Merkle 散列虚拟机的完整状态定义规则,以便可以有效地向基础层提出关于部分状态的声明。该规则必须是架构规范的一部分,因为它是解决争议的依据。验证者维护 Merkle 哈希和/或在需要时重新计算它也必须相当有效。例如,这会影响架构如何构建其内存。任何大型且可变的存储结构对于 Merkleize 来说都是相对昂贵的,并且用于 Merkleize 的特定算法需要成为架构规范的一部分。

AVM 架构通过仅具有有限大小、不可变的内存对象(“元组”)来应对这一挑战,这些对象可以通过引用包含其他元组。元组不能就地修改,但是有一条指令可以复制带有修改的元组。这允许构建可以表现得像一个大的平面内存的树结构。应用程序可以通过访问内部使用元组的库来使用大型平面数组、键值存储等功能。

元组的语义使得创建元组的循环结构成为不可能,因此 AVM 实现可以通过使用引用计数的不可变结构安全地管理元组。每个 Tuple 值的哈希值只需要计算一次,因为内容是不可变的。

7.1.4 代码点:优化代码以进行证明

传统的代码组织是存储指令的线性数组,并保持程序计数器指向将要执行的下一条指令。使用这种传统方法,证明一条执行指令的结果需要对数时间和空间,因为必须提供 Merkle 证明来证明哪条指令位于当前程序计数器。

AVM 通过将执行与证明分开来更有效地执行此操作。执行使用由程序计数器索引的指令数组的标准抽象,但证明使用等效的 CodePoint 构造,该构造允许在恒定时间和空间内完成证明和验证检查。某个 PC 值处的指令的 CodePoint 是一对(PC 处的操作码,哈希(PC+1 处的代码点))。(如果 PC+1 处没有 CodePoint,则使用零代替。)

出于证明目的,“程序计数器”被替换为“当前 CodePoint 哈希”值,它是机器状态的一部分。此散列的原像将包含当前操作码和以下代码点的散列,这是证明验证者需要验证操作码是什么以及在指令之后当前 CodePoint 散列值将是什么所需的一切,如果指令不是' t 跳跃。

所有跳转指令都使用作为代码点的跳转目标,因此关于跳转指令执行的证明不仅可以立即获得被跳转到的 PC,而且“当前代码点哈希”寄存器的内容将在之后跳转执行。在任何情况下,证明和验证都需要恒定的时间和空间。

在正常执行中(不需要证明时),实现通常只使用传统架构上的 PC 值。但是,当需要一步证明时,证明者可以使用预先构建的查找表来获取与任何相关 PC 对应的 CodePoint 哈希。

7.1.5 在运行时创建代码

代码以两种方式添加到 AVM。首先,在 AVM 开始运行时会创建一些代码。此代码从 AVM 可执行文件(.mexe 文件)中读取,并由 AVM 仿真器预加载。

其次,AVM 具有三个创建新 CodePoints 的指令:一个创建新的 Error CodePoint,两个创建新 CodePoints(一个用于具有立即值的 CodePoint,另一个用于没有立即值的 CodePoint)给定操作码,可能是立即值,以及下一个 CodePoint。ArbOS 在翻译 EVM 代码以供执行时使用这些。

7.1.6 代码点:优化代码以进行证明

传统的代码组织是存储指令的线性数组,并保持程序计数器指向将要执行的下一条指令。使用这种传统方法,证明一条执行指令的结果需要对数时间和空间,因为必须提供 Merkle 证明来证明哪条指令位于当前程序计数器。

AVM 通过将执行与证明分开来更有效地执行此操作。执行使用由程序计数器索引的指令数组的标准抽象,但证明使用等效的 CodePoint 构造,该构造允许在恒定时间和空间内完成证明和验证检查。某个 PC 值处的指令的 CodePoint 是一对(PC 处的操作码,哈希(PC+1 处的代码点))。(如果 PC+1 处没有 CodePoint,则使用零代替。)

出于证明目的,“程序计数器”被替换为“当前 CodePoint 哈希”值,它是机器状态的一部分。此散列的原像将包含当前操作码和以下代码点的散列,这是证明验证者需要验证操作码是什么以及在指令之后当前 CodePoint 散列值将是什么所需的一切,如果指令不是' t 跳跃。

所有跳转指令都使用作为代码点的跳转目标,因此关于跳转指令执行的证明不仅可以立即获得被跳转到的 PC,而且“当前代码点哈希”寄存器的内容将在之后跳转执行。在任何情况下,证明和验证都需要恒定的时间和空间。

在正常执行中(不需要证明时),实现通常只使用传统架构上的 PC 值。但是,当需要一步证明时,证明者可以使用预先构建的查找表来获取与任何相关 PC 对应的 CodePoint 哈希。

7.1.7 在运行时创建代码

代码以两种方式添加到 AVM。首先,在 AVM 开始运行时会创建一些代码。此代码从 AVM 可执行文件(.mexe 文件)中读取,并由 AVM 仿真器预加载。

其次,AVM 具有三个创建新 CodePoints 的指令:一个创建新的 Error CodePoint,两个创建新 CodePoints(一个用于具有立即值的 CodePoint,另一个用于没有立即值的 CodePoint)给定操作码,可能是立即值,以及下一个 CodePoint。ArbOS 在翻译 EVM 代码以供执行时使用这些。

7.1.8 从收件箱中获取消息

收件箱指令使用来自 VM 收件箱的下一条消息并将其推送到 AVM 的堆栈中。如果收件箱中的所有消息都已被消费,则收件箱指令阻塞——VM 无法完成收件箱指令,也不能做任何其他事情,直到有消息到达并且收件箱指令可以完成。如果收件箱已被完全使用,则任何声称的执行收件箱指令的一步证明都将被拒绝。

7.1.9 生产输出

AVM 有两个可以产生输出的指令:send和log。两者都被散列到记录 VM 输出(的散列)的输出散列累加器中,但是send会导致其值被记录为 L1 链上的 calldata,而log不会。这意味着使用 send 生成的输出将对 L1 合约可见,而使用log生成的输出将不会。当然,发送比日志更昂贵。一个有用的设计模式是将一系列值生成为日志,然后将这些值的 Merkle 哈希作为单个发送生成。这允许 L1 合约查看完整输出序列的 Merkle 哈希,以便在看到单个值时验证它们。

7.1.10 ArbGas 和气体跟踪

AVM 有一个 AVM gas 的概念,就像以太坊上的 gas。AVM gas 衡量执行指令的成本,基于验证器执行指令所需的时间。每条 AVM 指令都有一个 AVM gas 成本。

Arbitrum 指令的 gas 成本与以太坊指令不同,原因有两个。首先,在第 2 层系统和以太坊上执行指令 A 和指令 B 的相对成本可能不同。例如,相对于添加指令,Arbitrum 上的存储访问可能更便宜。AVM gas 成本基于 Arbitrum 上的相对成本。

AVM 架构有一个称为 AVM Gas Remaining 的机器寄存器。在执行任何指令之前,该指令的 AVM gas 成本会从 AVM Gas Remaining 中扣除。如果这会使寄存器下溢(表明执行“AVM 气体不足”),则会生成硬错误,并且 AVM 气体剩余寄存器设置为 MaxUint256。

AVM 具有获取和设置 AVM Gas Remaining 寄存器的指令,ArbOS 使用该寄存器来限制和计算用户合约使用的 AVM gas。(出于可用性原因,Arbitrum API 公开了“ArbGas”而不是“AVM gas”,其中 1 ArbGas 被定义为等于 100 AVM gas。这使得 gas 数量和 gas 价格更直观,更符合工具中的旧用户界面像钱包一样。)

7.1.11 错误处理

AVM 执行中可能会以多种方式出现错误情况,包括堆栈下溢、AVM 气体耗尽和类型错误,例如尝试跳转到非 CodePoint 的值。

AVM 架构有一个错误代码点寄存器,可以通过特殊指令进行读写。当发生错误时,Next CodePoint 寄存器设置为等于 Error CodePoint 寄存器,实质上是跳转到指定的错误处理程序。

8. ArbOS

ArbOS 是第 2 层的受信任“操作系统”,可将不受信任的合约相互隔离,跟踪和限制其资源使用,并管理向用户收取费用以资助链运行的经济模型。当 Arbitrum 链启动时, ArbOS 被预加载到链的 AVM 实例中,并准备运行。经过一些初始化工作后,ArbOS 位于其主运行循环中,从收件箱中读取一条消息,根据该消息进行工作,包括可能产生输出,然后循环返回以获取下一条消息。

9. EVM 兼容性

ArbOS 提供了模拟以太坊兼容链执行的功能。它跟踪账户、执行合约代码并处理创建和运行 EVM 代码的细节。客户端可以提交 EVM 交易,包括部署合约的交易,ArbOS 确保提交的交易以兼容的方式运行。

9.1 账户表

ArbOS 维护一个帐户表,该表跟踪模拟的以太坊链中每个帐户的状态。账户的表条目包含账户余额、随机数、代码和存储(如果是合约)以及与 Arbitrum 特定功能相关的一些其他信息。当 Arbitrum 链上的账户第一次发生任何事情时,就会初始化表中的账户条目。

9.2 翻译 EVM 代码以在 AVM 上运行

EVM 代码不能直接在 AVM 架构上运行,因此 ArbOS 必须将 EVM 代码转换为等效的 AVM 代码才能运行它。这是在 ArbOS 内完成的,以确保它是无需信任的。(一些旧版本的 Arbitrum 使用单独的编译器将 EVM 转换为 AVM 代码,但这在安全性和功能上都有很大的缺点,因此我们切换到 ArbOS 中的内置翻译。)

ArbOS 采用 EVM 合约的程序并将其转换为具有等效功能的 AVM 代码段。有些指令可以直接翻译;例如,一条 EVM 添加指令转换为单个 AVM 添加指令。其他指令转换为对 ArbOS 提供的库的调用。例如,EVM CREATE2指令创建一个新合约,其地址以特殊方式计算,转换为对名为evmOp_create2的 ArbOS 函数的调用。

为了部署新合约,ArbOS 获取提交的 EVM 构造函数代码,将其转换为构造函数的 AVM 代码,然后运行该代码。如果成功完成,ArbOS 将获取返回数据,将其解释为 EVM 代码,将其转换为 AVM 代码,然后将该 AVM 代码安装到帐户表中,作为现在部署的合约的代码。未来对合约的调用将跳转到该 AVM 代码的开头。

当 EVM 事务运行时,ArbOS 会保留一个 EVM 调用堆栈,这是一个 EVM 调用帧堆栈,代表事务内部的嵌套调用。每个 EVM 调用帧记录一个调用级别的数据。当内部调用返回或恢复时,ArbOS 清理其调用帧,并传播调用的效果(如果调用返回)或丢弃它们(如果调用恢复)。

EVM 调用指令系列(call、delegatecall 等)调用 ArbOS 库函数,这些函数根据所发出调用类型的 EVM 指定行为(包括 calldata 和 gas 的传播)创建新的 EVM 调用帧。呼叫后剩余的任何气体都会返回给呼叫者,就像在以太坊上一样。

执行 EVM 时的某些错误(例如堆栈下溢)将在 AVM 仿真期间触发相应的错误。ArbOS 的错误处理程序在模拟某个 EVM 调用时检测到错误发生,并相应地恢复该调用,将控制权返回给其调用者或提供适当的交易回执。ArbOS 通过查看 AVM Gas Remaining 寄存器来区分气体不足错误和其他错误,如果发生气体不足错误,该寄存器会自动设置为 MaxUint256。

这些机制的结果是 EVM 代码可以在 Arbitrum 上兼容运行。

与以太坊相比,Arbitrum 上的 EVM 执行存在三个主要区别。

  • 首先,在 L2 链上没有意义的两条 EVM 指令 DIFFICULTY 和 COINBASE 返回固定的常量值。
  • 其次,EVM 指令 BLOCKHASH 返回一个伪随机值,它是链历史的摘要,但与以太坊在相同块号处返回的哈希值不同。
  • 第三,Arbitrum 使用 ArbGas 系统,因此与 gas 相关的一切都以 ArbGas 计价,包括运营的 gas 成本,以及 GASLIMIT 和 GASPRICE 等与 gas 相关的指令的结果。
9.3 部署 EVM 合约

在以太坊上,通过向空账户发送交易来部署 EVM 合约,其中 calldata 由合约的构造函数组成。以太坊运行构造函数,如果构造函数成功,则将其返回数据设置为新合约的代码。

Arbitrum 使用类似的模式。为了部署新的 EVM 合约,ArbOS 获取提交的 EVM 构造函数代码,将其转换为构造函数的 AVM 代码,然后运行该 AVM 代码。如果成功完成,ArbOS 将获取返回数据,将其解释为 EVM 代码,将其转换为 AVM 代码,然后将该 AVM 代码安装到帐户表中,作为现在部署的合约的代码。未来对合约的调用将跳转到该 AVM 代码的开头。

9.4 交易收据

当一个 EVM 交易完成运行时,无论它是否成功,ArbOS 都会使用 AVM日志指令发出交易收据。收据由 Arbitrum 节点检测,可以使用它根据标准的以太坊 RPC API 向用户提供结果。

五. L1->L2 和 L2->L1

1. L1合约到L2

L1 合约可以像用户一样通过调用 EthBridge 提交 L2 交易。此 L2 事务将稍后运行,产生 L1 调用者无法使用的结果。事务将在 L2 执行,但 L1 调用者将无法看到 L2 事务的任何结果。

这种方法的优点是简单,延迟相对较低。与我们将很快描述的其他方法相比,缺点是如果 L1 调用者没有正确获得 L2 汽油价格和最大汽油量,则 L2 交易可能会恢复。因为 L1 调用者看不到它的 L2 事务的结果,所以它不能绝对肯定它的 L2 事务会成功。

这会给某些类型的 L1 到 L2 交互带来严重的问题。考虑一个交易,其中包括在 L1 上存入一个代币,以便在 L2 上的某个地址可用。如果 L1 端成功,但 L2 端恢复,则您刚刚向 L1 收件箱合约发送了一些在 L2 或 L1 上不可恢复的代币。

2. L1 到 L2 基于票据的交易

幸运的是,我们还有另一种用于 L1 到 L2 调用的方法,该方法对与 gas 相关的故障更加稳健,它使用基于票据的系统。这个想法是,L1 合约可以提交“预先打包”的交易并立即收到一个标识该提交的“ticketID”。之后,任何人都可以在L2调用一个特殊的预编译合约,提供ticketID,尝试兑换ticket并执行交易。

预打包的交易包括发送方地址、目的地址、调用值和调用数据。所有这些都被保存下来,调用价值从发送者的账户中扣除,并(逻辑上)附加到预先打包的交易中。

如果兑换成功,则交易完成,开具收据,ticketID 被取消,不能再次使用。如果兑换失败,例如打包交易失败,则兑换报告失败,ticketID 仍可用于兑换。

作为一个选项(并且默认情况下),原始提交者可以在提交时立即尝试赎回他们提交的交易,以期这次赎回会成功。作为一个例子,我们上面的“代币存款”用例应该,在愉快的、常见的情况下,仍然只需要用户的一个签名。如果此即时兑换失败,ticketID 仍将作为后盾存在,其他人可以稍后兑换。

以这种方式提交交易带有提交者必须支付的 ETH 价格,该价格根据交易的 calldata 大小而有所不同。提交后,门票有效期约为一周。在那之后它仍然有效,只要有人每周支付租金来维持它的生命。如果未支付租金且未兑换门票,则将其删除。

当票证被赎回时,预打包的交易运行时发送者和来源与原始提交者相同,目的地、调用值和调用数据是提交者在提交时提供的。(提交者可以指定一个地址,如果交易因缺乏租金而被放弃而没有被赎回,则调用价值将被退还到该地址。)

这种基于租金的机制比直接的 L1 到 L2 交易要麻烦一些,但它的优点是提交成本是可预测的,如果支付了提交成本,票证将始终可以兑换。只要有一些用户愿意赎回票(如果需要支付租金),L2 交易最终将能够执行并且不会被默默地丢弃。

3. L2 到 L1

从 L2 到 L1 的呼叫以类似的方式运行,使用基于票证的系统。L2 合约可以调用预编译的 ArbSys 合约的方法,向 L1 发送交易。当包含提交的 L2 交易的执行在 L1 得到确认时(几天后),在 EthBridge 中创建一个票据。该票可以由调用某个 L1 EthBridge 方法并提交票证的任何人触发。仅当 L1 交易未恢复时,该票证才被标记为已兑换。

这些 L2 到 L1 门票的有效期不受限制,直到成功兑换为止。不需要租金,因为这些费用由在 Arbitrum 其他地方收取的网络费用支付。

六 Gas 和 Fee

ArbGas 被 Arbitrum 用于跟踪 Arbitrum 链上的执行成本。它在概念上类似于以太坊 gas,因为每条 Arbitrum 虚拟机指令都有一个 ArbGas 成本,计算成本是其中指令的 ArbGas 成本的总和。

ArbGas 不能直接与以太坊 gas 相提并论。一般来说,与以太坊 gas 限制中的以太坊 gas 单位数量相比,Arbitrum 链每秒可以消耗更多的 ArbGas 单位。开发人员和用户应该认为 ArbGas 比以太坊 gas 更丰富、更便宜。

[关于术语的注释:实际上,Arbitrum 中有两个相关的 gas 概念:由虚拟机执行跟踪的 AVM gas,以及在 API 中使用的 ArbGas。两者密切相关,因为 1 ArbGas = 100 AVM 气体。为了简化讨论,本节使用单项 ArbGas 并忽略由 Arbitrum 代码正确完成的 100 倍转换。]

1. 为什么选择 ArbGas

Arbitrum 虚拟机 (AVM) 的设计原则之一是每条指令都应花费可预测的时间来验证、证明和验证检查。作为推论,我们想要一种方法来计算或估计验证任何计算所需的时间。

有两个原因。首先,我们要确保证明检查具有可预测的成本,这样我们就可以预测 EthBridge 需要多少 L1 gas,并确保 EthBridge 永远不会接近 L1 gas 限制。

其次,准确估计验证时间对于最大化汇总链的吞吐量很重要,因为它允许我们安全地设置链的速度限制。

2. 汇总块中的 ArbGas

每个汇总块都包含到目前为止计算使用的 ArbGas 数量,这意味着自前一个汇总块以来使用的数量。与汇总块中的其他所有内容一样,该值只是创建该块的质押者提出的声明,如果声明错误,该块将在挑战中被击败。

尽管汇总块中的 ArbGas 值可能不正确,但它可以可靠地用作验证块所需的计算量的限制。这是真的,因为检查区块的验证者可以在消耗了这么多 ArbGas 后切断他们的计算;如果已经消耗了这么多 ArbGas 而没有到达汇总块的末尾,那么汇总块肯定是错误的,检查者可以安全地挑战它。出于这个原因,汇总协议可以安全地使用汇总块中的 ArbGas 声明,减去前一个块中的数量,作为验证汇总块正确性所需时间的上限。

即使 ArbGas 使用是块的唯一错误方面,也可以安全地挑战汇总块。当一个声明被一分为二时,声明将包括(声明的)ArbGas 使用量,它必须与父声明的 ArbGas 使用量相加。因此,如果索赔的 ArbGas 金额错误,则至少有一个子索赔必须有错误的 ArbGas 金额。因此,知道索赔的 ArbGas 金额错误的挑战者将始终能够找到 ArbGas 金额错误的子索赔。

最终争议将归结为一条 AVM 指令,并声称该指令的 ArbGas 使用情况。一步证明验证检查此声明是否正确。因此,一个汇总块中的错误 ArbGas 声明可以一直追查到一条带有错误 ArbGas 数量的指令——然后通过 EthBridge 中的一步证明验证来检测错误。

3. AVM 中的 ArbGas

AVM 架构还在内部进行 ArbGas 核算,使用称为 AVM Gas Remaining 的机器寄存器,它是一个 256 位无符号整数,其行为如下:

  • 该寄存器最初设置为 MaxUint256。
  • 在任何指令执行之前,立即从寄存器中减去该指令的 AVM gas 成本。如果这会使寄存器的值小于零,则会生成错误并将寄存器的值设置为 MaxUint256。(该错误会导致 AVM 规范中指定的控制转移。)
  • 可以使用特殊指令来读取寄存器的值。
  • 另一条特殊指令可用于将寄存器设置为任何所需的值。

此机制允许 ArbOS 控制和说明应用程序代码的 ArbGas 使用情况。ArbOS 可以通过在调用应用程序之前将寄存器设置为 N 来将应用程序调用对 ArbGas 的使用限制为 N 个单位,然后在生成时捕获 out-of-ArbGas 错误。在运行时的错误处理程序开始时,ArbOS 会读取 AVM Gas Remaining 寄存器,然后将该寄存器设置为 MaxUint256 以确保错误处理程序不会用完 ArbGas。如果读取的寄存器给出的值接近 MaxInt256,则应用程序一定会生成 out-of-ArbGas 错误。(可能是应用程序在剩余少量 ArbGas 时生成了不同的错误,然后在错误处理程序的最开始发生了 out-of-ArbGas 错误。在这种情况下,第二个错误会将 AVM Gas Remaining 寄存器设置为 MaxInt256 并将控制权返回到错误处理程序的开头,从而导致错误处理程序得出结论,即应用程序导致了 out-of-ArbGas 错误。这是我们认为是正确的合理行为。)

如果应用程序代码将控制权返回给运行时而不生成 ArbGas 不足错误,则运行时可以读取 AVM Gas Remaining 寄存器并减去以确定应用程序调用使用了多少 ArbGas。这可以记入应用程序的帐户。

运行时可以安全地忽略 ArbGas 记帐机制。如果从不使用特殊指令,寄存器将设置为 MaxInt256,并且会减少,但实际上永远不会归零,因此不会产生错误。

将 EVM 代码转换为等效 AVM 代码的转换器永远不会生成设置 ArbGasRemaining 寄存器的指令,因此不受信任的代码无法操纵其自己的气体分配。

七. AnyTrust 链

AnyTrust 链是 Arbitrum 链类型,不同于 Arbitrum Rollup 链。Arbitrum One 主网链(链 ID 42161)是——并且将永远是——一个汇总链;很快,Offchain Labs 将开放第一个公共 AnyTrust 链测试网(随后是主网!)

Rollup 和 AnyTrust 之间的基本权衡是去中心化与交易成本:Rollup 链直接从第 1 层继承其安全性,而不引入新的信任假设,而 AnyTrust 链引入自己的安全假设,因此能够向用户收取更低的费用。

1. 基本

Rollup 的关键变化在于链数据的存储位置和方式。

要将交易添加到 Rollup 链,交易数据必须作为 calldata 发布在 L1 上。这直接利用了以太坊本身的安全假设来保证链的数据可供任何一方使用,这反过来意味着任何人都可以主动验证链。这个属性,再加上任何一个诚实的验证者都可以强制链的正确执行,意味着汇总链是不信任的。AnyTrust 通过以下方式改变这一点:

  • 交易数据在链下管理
  • 一个链有一个数据可用性委员会,由一个固定的命名方列表组成
  • 数据可用性——以及链的正确性——需要一定数量的委员会成员诚实

例如,委员会可能有 20 名成员,并假设 20 人中至少有两人是诚实的。AnyTrust 的核心优势在于,在正常情况下,交易比 Rollup 便宜得多。

2. K-of-N 诚实

一个有用的速记是将 AnyTrust 链称为做出 20 分之 2 的诚实假设。这意味着有一个 20 人的委员会,安全性依赖于至少 2 名委员会成员的诚实。一般来说,不同的 AnyTrust 链可能有不同的 K 和 N 值。

如果 K-of-N 是诚实的,那么由 N+1-K 委员会成员的“法定人数”担保的任何事情都必须是正确的。即,对于 2-of-20,法定人数是 20 名成员中的任何 19 名,并且 19 名成员保证的任何内容都必须是正确的。这里的逻辑是不诚实的委员会成员不能超过 18 人,因此任何 19 人的法定人数都必须有一个诚实的集体;如果法定人数说某事是真的,那么诚实的一方一定是在说那件事是真的,所以那件事一定是真的。

AnyTrust 的安全性缺点是,如果存在完全邪恶的法定人数,它可能会破坏链的安全性。因此,如果一条链假设 20 人中有 2 人是诚实的,但实际上只有一个是诚实的,那么就有 19 个恶意委员会可以组成一个邪恶的法定人数并窃取一切。这就是为什么我们选择 K 是像 2 这样的小数。

3. 利用链下数据可用性降低成本

在 Rollup 中,我们将以太坊链上的所有交易数据作为调用数据,以确保每个人都可以在需要时获取交易数据。这是运营汇总链的最大成本。

在 AnyTrust 中,如果法定人数表示他们正在存储一些交易数据并将按需提供给其他人,那么我们不需要将该数据放在以太坊上,因为 AnyTrust 诚实假设是有一个诚实的委员会成员会将数据提供给任何需要它的人。

这就是 AnyTrust 降低 L2 交易成本的方式。

4. 回退到汇总

如果没有合作法定人数怎么办?然后,AnyTrust 链作为常规 Rollup 运行。“仲裁模式”和“汇总模式”之间的切换在两个方向上无缝进行。

所以基本上,AnyTrust 链的行为会根据有多少委员会成员诚实和参与而有所不同:

  • Turbo 模式:20 人中有 19 人诚实如果法定人数(例如,20 人中有 19 人)诚实且参与,则链以“turbo 模式”运行;数据保持在链外,以低交易成本实现。
  • Rollup Mode: 2 out of 20 Honest 如果没有诚实的参与法定人数,但 K-of-N(例如 2-of-20)诚实假设成立,则链以“rollup 模式”运行,具有完全rollup 链。
  • 失败模式:20 个邪恶中的 19 个 如果诚实假设不成立并且存在邪恶的法定人数,那么链就会失去安全性。如果发生这种情况,则无法保证。

5. 这个怎么运作

AnyTrust 最好的方面之一是一旦你有一个工作的汇总系统,它是多么容易实现。它只需要对 Arbitrum Rollup 代码库进行轻微修改。

基本上,在 Rollup 中,L1 收件箱合约确保只有当数据在 L1 链上时,某些数据的哈希才能放入链的收件箱。AnyTrust 更改了此规则,因此如果数据在 L1 链上或法定人数已签署提供数据的承诺,则可以将哈希放入收件箱。这就是 Rollup 协议中需要更改的全部内容。验证器软件也有一些变化,但并不太复杂。

6. 选择委员会

显然,AnyTrust 链的数据可用性委员会的成员是谁很重要。 与 Rollup 不同,后者通过构建来确保数据可用性,AnyTrust 链需要明确选择负责数据可用性的各方。 选择委员会本质上是一个治理问题。 至少,委员会成员的身份或他们的选举过程应该是公开信息,以便用户可以在一定程度上确保他们中有足够的部分是值得信赖的。

全部评论(0)