WAGMi Venture：5分钟了解Arbitrum发展历史与未来方向

原文来源：WAGMi Venture

原文作者：0xMoonda

随着 DeFi 与 NFT 的普及，以太坊在过去几年中已发展成为加密经济的主要结算层。但受区块链本身属性限制，其单次可处理的交易数量是有限的。在链上交易极度活跃的情况下，用户之间为了争夺有限的区块空间经常使网络陷入拥堵的状态。大大降低用户的体验——高昂的 gas 费用与长时间的 pending 交易。为解决上述问题，以太坊社区采取了链上与链下扩容的方法。从 2021 年开始，开发者们开始将焦点转向链下——在以太坊网络的基础上创建 L2 rollups，Arbitrum 就是一种这样的 L2 rollup 技术。

Arbitrum 是如何解决以太坊扩容问题的？

Arbitrum 网络主要由两类节点组成：batcher 与 validator。两类节点共同与以太坊主网交互，以维持独立链的状态，这条独立的链被称为 L2。batcher 负责记录用户在 L2 中的交易并将数据提交至 L1。validator 负责读取 L1 中的数据，处理交易并更新 L2 的状态。随后 validator 会将更新后的 L2 状态数据发布到 L1，这样其它节点就可以对新状态的有效性进行验证。整个过程大致如下：

· 用户将 L2 的交易发送至 batcher，常被称为 sequencer；

· sequencer 在收到足量的交易后，会将数据打包并发送至 L1；

· validator 会读取 L1 合约中的交易并对在 L2 状态下的本地副本进行处理；

· 处理完成后会在本地生成新的 L2 状态，validator 将新 stateRoot 发送至 L1 的合约中；

· 其它 validator 开始处理同批处于 L2 状态下的本地副本；

· validator 将 L2 stateRoot 的结果与发送至 L1 合约中的原 stateRoot 进行比对；

· 如果 validator 获得的 stateRoot 与发布至 L1 的 stateRoot 不同，那么 validator 会在 L1 中发起 challenge；

· challenge 要求 challenger 与发布原 stateRoot 的 validator 轮流证明正确的 stateRoot 是什么；

· 无论哪方输掉 challenge，其质押都会被削减。若原 L2 的 stateRoot 无效，则会被下一个 validator 销毁，不会保存至 L2 中。

batcher 与 L2 交易数据

batcher 使用两种不同的 L1 合约发布数据，一个是「delayed inbox」，另一个是「sequencer inbox」。任意节点都可以将交易发送至 delayed inbox，只有 sequencer 可以将交易数据发送至 sequencer inbox。sequencer inbox 从 delayed inbox 中提取交易数据，并将其与 sequencer 提交的其它 L2 交易混在一起。因此，sequencer inbox 是每个 validator 提取最新 L2 交易数据的主要合约。batcher 的类型分为三种：forwarder、aggregator、sequencer。用户可将 L2 的交易发送至三种类型中的任意一种。forwarder 将 L2 交易发送至另一节点的指定地址。aggregator 地址作为指定的节点既可以是 sequencer 也可以是 aggregator。

aggregator 接收传入的 L2 交易并将它们分批处理成单个信息发送至 delayed inbox 当中。Sequencer 也会接收传入的 L2 交易并将它们分批处理成单个信息，但它会将信息发送至 sequencer inbox。如果 sequencer 停止向 sequencer inbox 发送交易，那么任意节点都可以通过智能合约调用要求 sequencer inbox 中包含来自 delayed inbox 的交易。这样既可以保证 Arbitrum 网络的可用性，同时又可以抵抗恶意 sequencer。目前，Arbitrum 在主网运行的是自己的独立 sequencer，未来计划将 sequencer 实现去中心化。

本质上来说，batcher 的任务是将 L2 交易数据提交至 L1。一旦这些交易在 L2 中被处理并生成新状态，那么 validator 也必须将该状态数据提交至 L1。

validator 与 L2 状态数据

使 validator 提交与存储 L2 状态数据的一系列智能合约被称为 rollup。rollup 的本质是由不同区块连接而成的链，也就是说 rollup 其实就是 L2。值得注意的是，在 Arbitrum 的代码库中会将这些组成链的区块称为「节点」。为了防止与上面的 validator 与 batcher 混淆，在下面的阐述中会将 rollup 的「节点」用「区块」表示。

由于单个区块中包含 L2 状态数据的哈希值，所以 validator 可以从 sequencer inbox 中读取数据与处理交易，然后将更新后的 L2 状态数据哈希提交至 rollup 智能合约，rollup 将会用更新后的数据创建一个新的区块并添加至链中。当 validator 将 L2 状态数据提交至 rollup 智能合约时，validator 也会明确说明当前链中的哪个区块是新区块的父区块。

为惩罚提交无效状态数据的 validator，流程中引入了质押系统。为了可以向 rollup 提交新的 L2 状态数据，validator 必须进行质押，他们必须存入一定数量的 ETH（或者根据 rollup 的要求存入其它代币）。这样的话，如果恶意 validator 提交了无效的状态数据，其它 validator 可以对该区块发起 challenge，恶意 validator 就会失去质押物。

当 validator 成为 staker 后，可以在不同的区块上进行质押，质押规则如下：

· staker 必须在他们创建的任意区块中进行质押；

· 多位 staker 可以在同一个区块上质押；

· staker 不能在两个不同的区块路径上进行质押。当 staker 在新区块进行质押时，新区块必须是之前所质押的区块的子区块（除非是 staker 第一次质押）；

· staker 在新区块上进行质押时无需增加新的质押物；

· 若某一区块在 challenge 中失利，那么所有在该区块上有过抵押的 staker 或者该区块的子区块有过质押的 staker 的都会失去抵押物。

若某一区块满足以下所有条件，那么该区块则将会永远被 L1 接收且不会重置：

· 区块创建时间超过 7 天

· 没有被其它区块 challenge

· 至少有一位 staker 在其上进行质押

若某一区块满足以下所有条件，可以被销毁：

· 其父块比最新确认的区块存在时间更长（最新确认的区块在另一分支上）

· 有 staker 在其兄弟区块上进行质押

· 无 staker 在此区块质押 ·自区块创建之日起超过 7 天

validator 的类型

每个 validator 可以使用不同的策略来保证网络安全。目前网络中支持三种类型的验证策略：Defensive、StakeLatest、MakeBlocks（在代码库中被称为 MakeNodes）。Defensive validator 负责对 rollup 中的区块进行监控，寻找分叉或冲突的区块。一旦检测到分叉，validator 会切换至 StakeLatest 策略。因此，如果没有存在冲突的区块，Defensive validator 也不会有任何质押。

如果区块中包含有效的 L2 状态数据，StakeLatest validator 会在 rollup 中的现有区块上进行质押，并且会尽可能会在链中最正确的区块上进行质押。StakeLatest validator 通常不会创建新区块，除非识别出包含错误状态数据的区块。在这种情况下，validator 会创建一个包含正确数据的新区块并在新区快上进行强制质押。

MakeBlock validator 也会选择在 rollup 中最正确的区块上进行质押。但即便是在没有无效区块的情况下，MakeBlock validator 若在链的末端进行质押时也会创造新的区块，它们是负责用新的状态数据推进链发展的重要角色。

L1 的交易与状态数据存储

交易数据存储

综上所述，aggregator 与 sequencer 接收 L2 的交易并将其提交至 L1 的 delayed inbox 与 sequencer inbox 中，将数据提交到 L1 在 L2 的费用占有很大的比例。aggregator 接收用户在 L2 中的交易，将 calldata 压缩至字节数组，然后将多个压缩的 calldata 组合成一系列的字节数组（这些数组被称为批量交易）。最后，aggregator 将批量交易提交至 delayed inbox。delayed inbox 将批量交易进行散列处理并将哈希保存至合约中。sequencer 与 aggregator 的工作流程类似，但 sequencer inbox 中还必须包含 delayed inbox 中消息数量的数据。该数据是 sequencer inbox 保存至合约中的最终哈希值的一部分。

状态数据存储

MakeBlock validator 从 sequencer inbox 中读取与处理 L2 交易后，会将更新后的 L2 状态数据提交至 rollup 智能合约。然后 rollup 智能合约对状态数据进行散列处理并将哈希保存到合约中。

检索交易与状态数据

即便只有交易哈希与状态数据保存在合约当中，其它节点也可以通过检索从以太全节点提交至 L1 的数据的交易 calldata 来查看原始数据。发送至 delayed inbox 或 sequencer inbox 的交易 calldata 包含所有经过 aggregator 与 sequencer 批量处理的 L2 交易数据。发送至 rollup 的交易 calldata 中包含了所有与 L2 相关的状态数据，对于 validator 来说有充足的时间来判断它们是否有效。为了使查询交易更加便捷，智能合约会向以太坊日志发送一个事件，允许任何节点可以检索 L2 交易数据或状态数据。

由于智能合约只需在其存储中保存哈希而非完整的交易或状态数据，因此节省了大量的 gas。Rollup 的主要成本来自将此数据存储至 L1 当中。因此，这种存储机制可以大幅降低 gas 费用。

Arbitrum 的技术更新与进展

Arbitrum Nitro

Nitro 是对 Arbitrum 的重大升级，在以下几方面进行了改进：

· 优化 calldata 的压缩方式：减少发布至 L1 的数据量从而降低在 Arbitrum 的交易成本；

· 将常规执行与错误性证明隔离：提高 L1 的节点性能，减少 gas 费用；

· 与以太坊 L1 的 gas 兼容：使 EVM 操作的定价及核算与以太坊完全一致；

· 增加与 L1 的互操作性：如与 L1 区块编号更加紧密地保持同步，支持对以太坊 L1 进行预编译；

· 保证 retryable ticket 的安全性：消除无法创建 retryable ticket 的故障模式；

· Geth 追踪：支持更大范围的调试。

Arbitrum Nova

Nova 是基于 AnyTrust 技术开发的新链，与 EVM 完全兼容，通过将数据发送至 DAC（Data Availability Committee）的方式大幅降低成本，只有在 DAC 未能完成处理的情况下才会将退回的数据放到链上。Nova 在处理交易数据的过程中添加了最小的信任假设——假设至少有两名 DAC 成员是诚实的。它用将数据与 DAC 进行共享的方式来替代由 sequencer 批量处理与发送 calldata 到 L1 的方法。DAC 为批量交易签署数据可用性证书（DACerts），只有证书会被发送到 L1，这样就大幅降低了对 L1 存储空间的要求。为保证数据的可用性，DAC 负责运行数据可用性服务器（Data Availability Server），开放 REST API 允许通过哈希来获取数据批次。因此，Nova 是为游戏、社交以及一些对 gas 成本较为敏感的应用而设计的。

Arbitrum Virtual Machine（AVM）

由于 Arbitrum 的 L2 交易不在 L1 中执行，所以不必遵循与 EVM 完全相同的规则进行计算。因此，Arbitrum 团队构建了自己的虚拟机 Arbitrum Virtual Machine（AVM）。AVM 与 EVM 非常相似，目的是支持 EVM 编译智能合约的兼容性，但也有不同。区别是 AVM 必须支持 Arbitrum 的 challenge。challenge 要求交易执行的步骤必须是可证明的，所以 AVM 引入了代码点。当代码执行时，指令保存在一维数组中，程序计数器指向当前指令。使用程序计数器是为了找出哪一条执行指令需要对数时间，然后其将时间复杂度降低至恒定时间。数组中的每条指令都有代码点，这样 AVM 可以立即显示出在程序计数器上正在执行的指令。代码点虽然增加了 AVM 的复杂性，但 Arbitrum 系统只有在需要对交易执行进行证明时才会使用。一般情况下还是会使用普通的程序计数器。

ArbOS

ArbOS 是 Arbitrum 的操作系统，负责管理与跟踪代码执行期间所使用的智能合约资源。ArbOS 有一个账户表，用于跟踪每个账户的状态，还为参与 rollup 协议的 validator 运行资金模型。AVM 的内置指令提升了 ArbOS 运行及其跟踪资源的性能。AVM 对 ArbOS 的支持使 ArbOS 可以在 L2 中运行某些规则，不一定非要到 L1 中去执行，因为任何从 L1 到 L2 的计算都会花费大量 gas，这样可以节省大量成本。

Arbitrum 生态发展数据

协议收入

该数据衡量的是用户在一段时间内支付总交易费用的美元价值。自 8 月完成 Nitro 升级之后，Arbitrum 的协议收入为升级前的 2 倍，达到 4 万美元。10 月末迎来高峰至 7.5 万美元。目前受宏观经济与 FTX 事件影响回落至 3 万美元左右，下降约 60%。

独立地址

自主网上线以来，Arbitrum 的独立地址数增长显著。进入 10 月日均新增地址为 6000 左右；11 月后日均新增地址突破 1 万关口，约为 10 月的 2 倍，新增最高点在 10 月 24 日，日均新增为 1.7 万，且呈持续上升趋势。

日活跃用户

9 月至 10 月间，Arbitrum 的活跃用户数维持在 3 万左右。进入 10 月后出现爆发式增长，推测主要与搏取空投交互相关。近几日达到年内高点日活跃用户数超 6.4 万。

TVL

进入 9 月 Arbitrum 的 TVL 一直在 9.3 亿美金上下浮动，11 月 8 日达阶段性高点超 10 亿美金。FTX 事件发生后之后下跌至 8.9 亿美金，目前处于回升状态。

链上应用

Arbitrum 生态中 TVL 排名前十的应用分别是：GMX、Stargate、Uniswap V3、Curve、Sushi、Synapse、AAVE V3、Radiant、Vesta Finance、Beefy。值得注意的是，GMX 的 TVL 占前十位应用总 TVL 的 48.73%，达 3.94 亿美元。GMX 是一个现货与永续合约交易的 DEX 平台，聚焦于衍生品业务，前身为 BSC 上的 Gambit，后迁移至 Arbitrum 同时支持 Avalanche。

跨链

目前，使用 Arbitrum 进行跨链的用户约为 45.4 万人，跨链总金额为 19.8 万枚 ETH（按市价折算约为 2.3 亿美元）；截止至 11 月 21 日，7 日内存款人数为 2 万人，7 日内跨链总金额接近 2 万枚 ETH。与其它 L2 协议 Optimism、zkSync、StarkNet 相比，除 Optimism 在 7 日内存款人数为 10 万之外，其余三个维度的数据均处于领先位置。

Gas

从 gas 费用来看，Arbitrum 在众多 L2 协议中转账费用排名第三，比以太坊 L1 的转账成本低了 93%。Swap 的费用在 L2 协议中排名第二，比在以太坊 L1 进行 swap 的成本低 96%。（注：下图中所显示的费用是浮动的，但变化幅度相对较小）

NFT

以 Opensea 为例，30 天内 Arbitrum 中排名前 5 的 NFT 总交易额为 1025 ETH，比同为 L2 扩容方案的 Optimism 高出 103%。NFT 最高地板价格为 0.38 ETH，是 Optimism 生态中 NFT 最高地板价格的 38 倍。

Arbitrum 未来展望

综上所述，Arbitrum 很好的继承了以太坊的 DeFi 基因，众多 DeFi OG 项目迁移至 Arbitrum 进行持续建设，它们的存在为生态带来了稳定的用户基础；Arbitrum 与以太坊 L1 保持高度兼容，支持任何 EVM 语言为开发者带极大便利，同时可以共享以太坊生态庞大的开发者社区资源；比以太主网低超 90% 的 gas 增加了用户对链上交易的接受度，以上几方面为孕育 DeFi 创新应用创造了一个包容度很高的环境。其次，为适应游戏与社交的高频交互需要 Arbitrum 开发了新链 Nova 作为解决方案，与其 DeFi 生态隔离开也是一次不错的尝试，不过与 Polygon 目前已经相对成熟的游戏、社交生态相比还存在一定差距。从这个角度看，未来 Arbitrum 在 DeFi 层面的发展更加值得期待。

*本文以上内容均为观点阐述，非投资建议。

原文链接

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia