Layer 2 扩容解决方案是当前以太坊社区热议的话题，也是整个区块链技术社区正在讨论的热门话题。基于 Optimistic Rollups 的 Arbitrum 是目前最具有吸引力的 Layer 2 扩容解决方案之一。它率先部署了主网 beta 版本，并获得了 Uniswap 和 Compound 等核心 DeFi 项目的支持。
对于打算从以太坊主网迁移至 Layer 2 的用户来说，他们最关心的一个问题就是 Layer 2 解决方案的安全机制如何。本文将深入探讨 Arbitrum 的安全机制，包括： Arbitrum 如何植根于以太坊的安全性中；为什么挑战期是七天；以及如何防御审查攻击。
植根于以太坊的安全性中
众所周知 Layer 2 解决方案与其他扩容解决方案相比，最大的一个优势就是其安全性依赖于以太坊主网的安全性。然而，大部分人可能都知道这个道理，但却不知道为什么。那么 Arbitrum 如何根植于以太坊的安全性中呢？
我们首先来回顾一下 Optimistic Rollup 解决方案的主要特点：
在一个 Rollup 解决方案中，交易 (作为 calldata) 编写在 L1 上，但是其实际计算和合约的存储在 L2 上完成，以实现扩容。
2.验证者在 L1 上发布一个断言 (assertion)，可以理解为将所有交易和结果打包成一个 Rollup 区块，然后发送到 L1 的交易中。
Optimistic Rollup 之所以称为”乐观的“ rollup 解决方案，因为当一个断言发布时，其不包含保证其有效性的随附证明，即默认该断言有效。相反，届时会有一个时间窗口，而任何人都可以在这个时间内挑战该断言。如果挑战成功，那么此断言内的所有交易都将被撤回，并且提出断言的人会失去其保证金。如果挑战期到期且没人挑战成功，那么断言就会被最终确认。
在了解了这个解决方案之后，我们再从几个角度来思考 Arbitrum 是如何植根于以太坊的安全性的。
数据可用性
所有在 L2 上执行的交易首先会提交至在 L1 上运行的收件箱智能合约，然后作为 calldata 编写进 L1 中。任何人都可以利用该数据来检索回 L2 上的所有交易并将 L2 恢复到其原始状态。这些数据可用性通过 L1 得到保证，用户不必担心 L2 因出现故障而导致其损失 L2 上的资产。
AnyTrust
AnyTrust 是 Rollup 协议的关键安全功能。这个功能允许任意诚实验证者确保交易在 L2 上正确地执行。无论有多少攻击者恶意阻止交易的进行，你或者你雇佣的任何人都能够强制确保交易的正确执行，而无需信任任何第三方。
紧急退出机制
Arbitrum 当前没有一个特定的紧急退出机制，但是有一系列安全机制来确保用户可以安全退出。
首先，数据可用性确保用户存储在 L2 上的资产和数据可以在任意时候从 L1 上恢复，并且永远不会丢失。
其次，任意用户都能向 L1 上的收件箱合约发送一个交易请求来强制退出。
最后，AnyTrust 机制确保用户可以强制 L2 正确地处理退出交易。
在以上三点中，用户不需要信任任意第三方，这充分地展示了 Arbitrum 植根于以太坊的安全性中，并且是去信任的。
为什么挑战期是七天
Arbitrum 是一个多轮交互的 Rollup 解决方案。这个解决方案首先会乐观地相信验证者做出的断言是有效的，而在挑战期其他验证者可能会对此提出质疑和挑战。在大多数情况下，不会有挑战提出，那么整个系统就可以更高效且成本更低。
显然，挑战期越长，整个系统就越安全，但同时用户体验也会更差 (因为用户需要等到挑战期结束之后才能退出)。那么我们是如何确定最佳的挑战时期呢？
Arbitrum 团队提出这种模型来计算最佳的挑战时期：
假设一个挑战时期等于 C 区块的长度，以及攻击者在 L2 上可以获得的最大值为 V。
则攻击者获得的预期价值为 V exp(-AC)。
注解：exp 为指数函数”e“，A 为某常数 A，AC 前的 ”-“ 符号表示 C 与预期收益成反比。
断言者需要保证其资产远超过攻击的资产价值以应对攻击。我们假设超过 10 倍，则断言者的成本为 10V exp(-AC)I。I 指的是资本利率。
我们假设某退出用户在挑战期被锁定的提款资产为 CWV (W 为小数，WV 是 L2 上总资产的一部分，每个时间点都会有 C 个未结束挑战的区块) 和用户的资产成本为 CWVI。
最佳的挑战期限应该设为断言者和提款用户的资产总成本最低的情况下。即取 C 的值时，10V exp(-AC)I+CWVI 最小。V 和 I 在两项中都出现，它不会影响最小值点，可以忽略。我们只需对 C 求导，将所得导数设为 0，并得到 C = ln(10A / W) / A。
现在我们将一些合理的数字插入上述等式中，以获得一个大概的最佳挑战期限。
假设一个区块时间内的连续审查成功率高达 99.99%，即 A = -ln(0.99) = 0.01。
进一步假设每天提款为总值的 1%，并且每个区块的提款百分比约为 W=0.000002，基于出块时间为 15 秒的前提。
将这些代入公式中，我们得到的最佳挑战期限为 C = 62146 区块，即 10.79 天。这与 Arbitrum 团队最终选择的 7 天挑战期限非常接近。
如何防御审查攻击
在这一部分，我们讨论了 Arbitrum 如何防御四种主要的审查攻击：分叉攻击 (forking attacks)、回避攻击 (shunning attacks)、干扰攻击 (jamming attacks) 和快速攻击 (speed demon attacks)。
分叉攻击 (forking attacks)：矿工合谋 (或受贿) 丢弃包含正常挑战的区块，以便接受不包含挑战的替代链。
首先，由于挑战者的存在，一旦发生分叉攻击，难免会被某个挑战者发现。而当大家发现区块链中的挖矿算力垄断者 (这是分叉攻击的先决条件) 为了盈利而肆无忌惮地违反规则时，区块链本身就被摧毁了。此时，Arbitrum 是否采用挑战期设计模型还存在争议。
回避攻击 (shunning attacks)： 矿工们合谋 (或受贿) 忽略掉他们生产出的区块中的普通挑战。
我们假设垄断者控制了 90% 的挖矿算力，并且期限为 50 个区块。那么垄断者需要将 50 个连续的区块打包起来才能完成攻击。这个概率是 0.9 的 50 次方，也就是 0.5%。而实际挑战期限远不止 50 个区块，所以攻击成功的概率极小。在 Arbitrum 的设计中，攻击者在攻击失败时会支付巨额罚款，因此垄断者发起回避攻击是非常不划算的。
干扰攻击 (jamming attacks) ：攻击者发起”老式的拒绝服务攻击 (DoS)“ 来阻止任何一方发布任何交易 (不能发布包含挑战的交易)。
因为只要有一个正直的挑战者，攻击就会失败，所以攻击者必须阻止所有有可能的挑战者。如果有很多这样的挑战者，攻击将很难完成。更糟糕的是，任意利益相关的一方都可能雇佣一个沉默的监察者以作为备用计划。他们只在主要参与方太晚发布挑战或者在发布挑战时遇到了困难时才会介入。攻击者并不知道网络中是否有沉默的监察者，或者尽管知道他们存在，也不知道他们是谁，所有在这些监察者有实际行动之前，攻击者都无法向他们发起 DoS 攻击。
快速攻击 (speed demon attacks)：攻击者生成链上断言的速度十分快，以至于其他方不能在时间截止之前检查并且挑战所有断言。
Arbtirum 采取的应对方法是：限制创建断言的速率，以确保在任何时候检查未决断言和挑战其中一个断言所需的总工作量能够在协议的期限之内完成。具体来说，对 Rollup 链中的智能合约运作进程施加速度限制，因此即使有人能够快速生成大量断言，它最终也必须慢下来。
总之，我们不需要太担心分叉攻击。如果出现恶意挖矿算力垄断的情况，那么可以说这个区块链已经基本上变得没有吸引力了。Arbitrum 可以通过适当的设计或者实践来防御其他三种审查攻击。
序列器模式 (Sequencer Mode) 的优势和风险
Sequencer 模式是 Arbitrum 的一个可选功能，Offchain Labs 在主网的发布版本上运行唯一的 Sequencer 节点。
Sequencer 被赋予有限的权力来控制收件箱中每笔交易的排序，以保证用户的交易结果能够立即被确定，无需在以太坊上等待五分钟至区块被确认，甚至不需要像在以太坊一样等待 15 秒的出块时间。
同时，一个表现良好的 sequencer 可以有效地防御抢跑攻击。
因此，一个由 Offchain Labs 运营的中心化的、表现良好的 Sequencer 节点，对于项目的早期开发是非常有利的，并为其减少了很多麻烦。但是安全隐患也很明显 (虽然很难想象 Offchain Labs 会作恶，但也不排除这样的可能性)。Offchain Labs 承诺在技术成熟后立即切换到去中心化的、多个 Sequencer 节点的解决方案。
此外，收件箱也将一分为二，一个接受由 Sequencer 提交的交易，另一个则接受由常规聚合器或者用户提交的交易，这也为不信任中心化的 Sequencer 的用户提供了另一种选择。
Did you enjoy this issue? Yes No
Jun.C
Jun.C @oleander8226
我相信分享的力量。我懂得一同分享我们的收获与成功是一份快乐，更深知愈加弥足珍贵的是分享我们坚守的信念、追求的梦想、成长的毅力与跨越的艰难。
In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.