一次对Arbitrum One的研究

L2 扩容，是指把Contract （包括transaction）的计算在offline chain（非以太网主网）进行， 把结果（transactions & state） 打包发到以太网主网。 以达到节省gas费用、提高交易吞吐的目的。

L2 扩容方案，分为两大类：

1. Optimistic rollup： 乐观得认为L2网络的参与者是诚信的。 落到Ethereum上的数据和状态不能保证100%是正确的，通过challege机制，在一定的时间窗口内发现错误的L2区块，并通过仲裁机制剔除错误区块，惩罚和驱逐错误区块的提交者。
2. ZK (zero knowledge) rollup： 区别在于， 落在Ethereum上的数据和状态一定是正确的，功夫都花在提交之前（还未研究） Arbitrum 是一种Optimistic rollup 方案。 他和Optimism的核心区别在于冲突解决（resolve disputes ）的策略不同：
3. Arbitrum 采用 interactive proving: 冲突的两方（validators）在 rollup protocal (on L1) 的协调下， 不断交互，找到产生冲突的最小指令，交给rollup protocal 判断哪方获胜。
4. Optimism 采用 re-executing proving: 可以简单理解为让rollup protocal重新执行争议block内所有的transaction。

两种resolve disputes方案的不同对L2扩容方案产生了不同影响：

1. 在基于interactive proving的方案下： 冲突解决的成本较小，只需要链上验证一个指令的计算结果。 L2合约不需要存储在L1， 因此合约大小、以及合约运行（比如gas limit）的限制可以脱离L1。 但是需要解决“最小冲突指令发现”这个难题。 Arbitrum 实现了一个AVM， 在兼容EVM的同时，实现interactive proving。
2. 在基于re-executing proving的方案下： 冲突解决的成本很大，因为要re-exceute整个区块，技术难点也在这，毕竟EVM可没有replay transaction的功能。 现在， 合约必须同时部署在 L1和L2。 此方案的好处是， 其他方面的成本就很小了， 基本上就是把transaction 打包压缩放到L1上。

接下来，在high level看一下Arbitrum网络的结构，分析下去中心化程度和经济模型。

我们可以把区块链做如此的抽象，上层表示transaciton序列， 下层是block chain。 一条block chain实际上维护的是一个数据库， block 是这个数据库不可更改的一个snapshot。 Transaciton 触发数据库的修改 和 block的生成，对于POW L1来说，这个过程靠node挖矿完成， 对于POS L1来说这个过程由validators 之间 propose & vote block完成。 从这个角度出发，有两个因素决定了区块链数据的一致性：

1. Transaction 一致性： 它决定block的内容。
   • transaction顺序： 相关联transaction之间顺序， 每个transaction相对block的顺序（后者说位置）。
   • transaction的正确性。
2. Block的一致性：对数据库修改的正确性。

我们先假设Transaction一致性是已经解决了的，我们看Arbitrum 是如何保证Block一致性的。

上图分为上下两部分，上半幅为L2， 下半幅为L1。 在L1中 ， 左边绘制了一条链， block1 ~ block4。 右边Rollup Protocal 表示Arbitrum 用于冲突解决的合约。 block1 ~ block4 并不是以太坊的block, 而是Arbitrum的block, 他存储在以太坊合约的CallData中。 block 1 ~ block3 已经finalised, 并且没有纠纷。 Block 是L2 网络的validator写入的。 为了能约束validator的行为， validator 需要在L2质押ETH。 我们看发生在Block4上的分叉， validator A propose了block 4A, 但是validator B 认为A是错误的， 所以B propose了区块4B， 并触发了Rollup Protocol, 进行仲裁。 接下来是仲裁的过程。 冲裁分为两个阶段：

1. 第一个阶段： L2上的A和B需要找出存在歧义的计算机指令。 采用的方式是通过二分法（dissection Protocol) , B不断挑战 A的部分指令执行结果，直到找到存在歧义的计算机指令（one step proof）。 这里需要特殊虚拟机的支持。
2. 第二阶段： 在L1上， Rollup Protocol 验证第一阶段的one step proof。 判断A是错误的，则将4B选择为head block。 Vildator A 质押的ETH将充公。 Validator A 将不能继续propose new block。

思考上述过程，有几个有意思的点：

1. 只要（至少）有一个诚实的Validator , L2区块链就能（才能） 正常运行
2. Validator 的角色又有不同，这Arbitrum白皮书也解释了：区块生产者、监督挑战者、监听者。 Arbitrum 背后的组织OffchainLabs运营了区块生产者，我猜这是全网唯一的区块生产者，因为在白皮书中并没有看到对多个诚实的区块生产者并存的描述。 任意的Arbitrum的使用者，都可以作为挑战者或者监听者去运营自己的validator。

这是否是去中心化的？ 我觉得它在“有监督的中心化”和“完全去中心化”之间。

现在，回到transactions一致性的问题上。 仍用简图描述这件事：

同样，分为L1和L2两部分。 在L1中，有两个“box”存放transactions。 所谓box, 实际为某个以太坊合约的callData存储区域。

1. delay-inbox: 任何人都可以往delay-inbox提交transaction, 但是不能确定顺序，不能确定何时被执行。
2. Inbox: inbox中的transaction是有序的，即将被validator打包到block的。也就是说，当transaction进入到inbox后，可以认为一定被执行了， 基于inbox, 任何人能计算出L2 blcok chain 将会变成怎样的状态。 因此，提交到inbox的transaction应该被认为立即确认。 合约控制了delay-inbox到inbox的转移。

再来看L2， FullNode 类似以太坊的fullNode。 他可将L2 transaction批量打包发到L1的box。 普通FullNode只能把tx发往delay-inbox。 如果允许的话，一条L2 Arbitrum链上可以有Sequencer FullNode, 他可以直接把tx batch发往inbox。 Sequencer 是特权节点。

在我看来，在tx发布这个问题上， Arbitrum就非常中心化了。

1. 如果链上没有Sequencer。 我们仍然要相信某一个Common FullNode不会作恶。 因为，我并没有看到有什么共识机制，保证了 FullNode往delay-inbox中提交的tx就是用户提交的tx。 当然，我们可以运维自己的fullNode解决这个问题。
2. 如果链上有Sequencer。 用户需要抉择: 选择Sequncer, 交易立即确认，但是完全丧失去中心化； 选择自己更信任的common FullNode, 交易慢。

抛开去中心化的思考。来想想Arbitrum的经济模型。 在这个系统中，那些参与者是需要激励的？

1. FullNode:
   • 在L2，他要运行他收到的transaction
   • 往L1提交tx batch时，需要消耗L1 gas
2. Validator:
   • L2上，它要运行所有的transaction
   • L1上，它要写入block
3. Arbitrum 部署在L1 上的支撑起整个系统的合约。 这些合约在白皮书中统称为EthBridge。

因此，即使合约跑在L2上，也需要收取过路费，以养活这套系统。 同时，Arbitrum要让L2手续费相比直接使用L1足够低。通常来说，一个去中心化网络还要有足够吸引人的激励机制，来激励网络节点运营者，不过，由于当前Arbitrum有一些中心化的组件， 激励机制显得不重要。