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

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

　　https://developer.offchainlabs.com/docs/developer_quickstart

　　整体框架

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

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

　　EthBridge和AVM执行环境对应的源代码：

　　https://github.com/OffchainLabs/arbitrum.git

　　ArbOS对应的源代码：

　　https://github.com/OffchainLabs/arb-os.git

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

　　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结果。

　　AVM使用c++实现，AVM表示的逻辑实现在MachineStateKeys类的machineHash函数（machinestate.cpp）中。AVM的特别之处就是除了执行外，还能较方便的表达（证明）执行状态。深入理解AVM的基本数据结构，AVM的基本的数据类型包括： (责任编辑：admin)