原文标题：《L2 - 深入理解 Arbitrum》
撰文：Star Li

Arbitrum 是 Layer2 Rollup 的一种方案。和 Optimism 类似，状态的终局性采用「挑战」(challenge) 机制进行保证。Optimism 的挑战方法是将某个交易完全在 Layer1 模拟执行，判断交易执行后的状态是否正确。这种方法需要在 Layer 1 模拟 EVM 的执行环境，相对复杂。Arbitrum 的挑战相对轻便一些，在 Layer1 执行某个操作（AVM），确定该操作执行是否正确。Arbitrum 介绍文档中提到，整个挑战需要大概 500 字节的数据和 9w 左右的 gas。为了这种轻便的挑战机制，Arbitrum 实现了 AVM 虚拟机，并在 AVM 虚拟机中实现了 EVM 的执行。AVM 虚拟机的优势在于底层结构方便状态证明。

Arbitrum 的开发者 文档 详细介绍了 Arbitrum 架构和设计。对 AVM 以及 L1/L2 交互细节感兴趣的小伙伴可以耐心地查看「Inside Arbitrum」章节。

整体框架

Arbitrum 的开发者文档给出了各个模块关系：

Arbitrum 的系统主要由三部分组成（图中的右部分，从下到上）：EthBridge，AVM 执行环境和 ArbOS。EthBridge 主要实现了 inbox/outbox 管理以及 Rollup 协议。EthBridge 实现在 Layer1。ArbOS 在 AVM 虚拟机上执行 EVM。简单的说，Arbitrum 在 Layer2 实现了 AVM 虚拟机，在虚拟机上再模拟 EVM 执行环境。用 AVM 再模拟 EVM 的原因是 AVM 的状态更好表达，便于 Layer1 进行挑战。

这个模块关系图太过笼统，再细分一下：

EthBridge 主要实现了三部分功能：inbox，outbox 以及 Rollup 协议。inbox 中「存放」交易信息，这些交易信息会「同步」到 ArbOS 并执行。outbox 中「存放」从 L2 到 L1 的交易，主要是 withdrawl 交易。Rollup 协议主要是 L2 的状态保存以及挑战。特别注意的是，Arbitrum 的所有的交易都是先提交到 L1，再到 ArbOS 执行。ArbOS 除了对外的一些接口外，主要实现了 EVM 模拟器。整个模拟器实现在 AVM 之上。整个 EVM 模拟器采用 mini 语言实现，Arbitrum 实现了 AVM 上的 mini 语言编译器。简单的说，Arbitrum 定义了新的硬件（machine）和指令集，并实现了一种上层语言 mini。通过 mini 语言，Arbitrum 实现了 EVM 模拟器，可以执行相应交易。

AVM State

因为所有的交易都是在 AVM 执行，交易的执行状态可以用 AVM 状态表示。AVM 相关实现的代码在 arbitrum/packages/arb-avm-cpp 中。

AVM 的状态由 PC，Stack，Register 等状态组成。AVM 的状态是这些状态的 hash 值拼接后的 hash 结果。 (责任编辑：admin)