LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资产 > 全面解析 Arbitrum 安全机制

全面解析 Arbitrum 安全机制

2021-06-17 DeGate爱好者 来源:区块链网络

前言

Layer 2扩容解决方案是当前以太坊社区乃至整个区块链技术圈最热门的话题,而Arbitrum在率先部署主网测试版之后,又获得Uniswap、Compound等核心Defi项目的支持,无疑成为了当下最引人注目的Layer2 方案。

对于打算从以太坊主网迁移到Layer 2网络的用户来说,Layer 2方案的安全机制是其最关心的议题之一。本文将全面解析Arbitrum的安全机制,包括:Arbitrum是如何继承以太坊安全性的、为什么挑战期设置为7天、如何防御审查攻击等。

继承以太坊安全性

大家都知道Layer 2相比其他扩容方案,最大的优势之一就是完全继承以太坊安全性,但可能大多数人知其然而不知其所以然,Arbitrum到底是如何继承以太坊的安全性的呢?

首先我们再回顾下Optimistic Rollup方案的主要特点:

1、在Rollup方案中,交易数据被写入L1(作为calldata),但合约的实际计算和存储则是在L2上完成,以此来实现扩容;

2、某个验证者(Validator),会将一个断言提交到L1,可以理解为该断言就是将一个Rollup区块内的所有交易、结果打包到了L1的一笔交易里;

3、而Optimistic主要是指系统对待断言的态度是乐观的,即当一个断言发布时,它不需要包含任何保证其有效性的附带证明,相反,会有一个时间窗口供任何质疑的人去挑战。挑战成功,则这个断言包含的所有交易都将被回撤,发布断言的验证者将被没收所有押金;挑战失败/无人挑战,则断言被接受并获得终局性。

了解了具体方案,我们再从几个角度考量Arbitrum是如何继承以太坊安全性的。

数据可用性

在L2上执行的所有交易,首先都会被提交到L1上运行的Inbox智能合约中,即作为calldata写入L1。任何人都可以通过这些数据,还原L2上的所有交易,并将L2恢复到中断之前的正确状态。这些数据的可用性是通过L1来保证的,也因此人们完全不用担心L2的故障或者下线会导致自己在L2上的资产受损。

AnyTrust

AnyTrust是Rollup协议的关键安全属性,它表示任何一个诚实的验证者都可以强制确认L2链的正确执行,也就是说无论有多少想作恶的人试图阻止你,你或你雇佣的人都可以强制正确处理你自己的交易,你无须信任任何第三方。

紧急退出机制

目前Arbitrum并没有专门定义紧急退出机制,但一系列的安全机制已经确保了用户可以达成紧急退出的目的:

首先,数据可用性确保了用户在二层的资产、数据随时可以从L1恢复,永远不会丢失;

其次,任何用户都可以将交易请求发送到L1的Inbox合约中,来强制发起提现;

最后,AnyTrust机制确保了用户自己就可以强制L2正确的处理这笔提现交易。

以上三点,用户都无须信任任何第三方,这充分表明Arbitrum完全继承了以太坊的安全性,是Trustless的。

为什么挑战期是7天

Arbitrum是多轮交互式Rollup方案,方案会首先乐观的认为验证者提出的断言是正确的,直到在挑战期内由其他验证者提出挑战或反驳。大多数情况下并不会出现挑战,因此整个系统得以更快速和低成本的推进执行。

显而易见,挑战期越长,整个系统会越安全,但同时用户体验则会越差(因为用户提款时需要等待一个挑战期结束),所以如何找出挑战期的最优时长?

Arbitrum团队提出了这样的模型来计算最优挑战期时长:

1、假设一个挑战期为C个区块的时长,攻击者可以获得的最大收益为L2上的所有资产V,则攻击者得到的预期收益为:V exp(-AC),注:exp指e的指数函数,A为某个常数,AC前的负号指C和预期收益成反比;

2、为了应对攻击,断言者需要质押的资产远远大于攻击可得的收益,我们假设为10倍,则断言者的成本为10V exp(-AC)I,I为资金利率;

3、我们再假设提现用户被锁定在挑战期内的提现资金为CWV(W为小数,WV即L2总资产的一部分,每一个时间点将有C个区块未结束挑战),则用户的资金成本为CWVI

4、最佳挑战期时长即断言者和提现用户的资金总成本最低,即C取何值时,10V exp(-AC)I+CWVI最小。V和I在前后两项中都存在,因此不影响最小点,可将其约掉,我们只需对C求导,再令倒数等于0,然后解出C:

C = ln(10A/W) / A


现在我们将某个合理数值代入上面的公式,即可得到一个粗略的最优挑战期。

假设一个区块的时间内持续审查的成功率高达99.99%,则A=-ln(0.9999)=0.0001;

再假设每天都有1%的资金需要取出,按15秒1个区块计算,每个区块的取款比例约为W=0.000002;

代入公式得出最优挑战期为C=62146个区块,即10.79天,这与Arbitrum团队最终选择的7天最优挑战期已经非常接近。

如何防御审查攻击

这一节我们讨论Arbitrum如何应对主要的4种审查攻击:分叉攻击、拒绝服务攻击、阻塞攻击、饱和攻击。

分叉攻击:矿工串通(或被贿赂)弃置包含正常挑战的区块,并通过分叉,使另一条没有包含任何挑战的区块链被接受。

首先,由于挑战者的存在,一旦发生分叉攻击,必然会被某个挑战者发现。而当大家发现所处的区块链存在算力垄断者(这是分叉攻击的前提条件),并且会为了利益不受约束的破坏规则时,对于这个区块链将会是毁灭性的打击,Arbitrum是否采取挑战期设计模式已经无关紧要了。

拒绝服务攻击:矿工密谋(或被贿赂)在出块时不打包正常的挑战。

我们假设垄断者控制了90%的算力,挑战窗口期为50个区块,那么需要连续50个区块都由垄断者打包才能完成攻击,其概率为0.9的50次方,仅为0.5%,而实际的挑战期远远多于50个区块,因此攻击成功概率极小。而在Arbitrum的设计中,每次攻击失败,攻击者都将支付大量的罚金,所以发起拒绝服务攻击对垄断者而言是相当不经济的。

阻塞攻击:攻击者通过传统的拒绝服务攻击(DoS),使得其他人无法提出挑战(无法发出包含挑战的交易)

由于只要出现一个正直的挑战者,攻击就会失败,所以攻击者必须阻止“所有”可能的挑战者,如果挑战者足够多,这是很难完成的。更进一步的,利益相关方可能会雇佣暗中监视者,它们作为后备方案,只有在参与方来不及或难以发出挑战时才介入,攻击者根本无法提前辨别这些潜伏的挑战者,自然也没办法对其发起DoS攻击。

饱和攻击:攻击者在很短的时间内提出大量的链上断言,让其他人来不及在时间窗口内对所有断言进行检查和挑战。

Arbitrum防御饱和攻击的方法是对提出断言的频率进行限制,保证协议在设定的挑战窗口期内的任何时间点,全网都有足够的能力去检查待处理的断言和挑战。具体来说,会针对一条Rollup区块链的智能合约处理能力实施速度限制,使得即使存在某个能快速提出大量断言的人,最终也不得不慢下来。

综上所述,我们基本上不需要对分叉攻击过于担心,因为存在一个作恶的算力垄断者让这条区块链毫无吸引力;至于另外三种审查攻击,Arbitrum都能够通过合理的设计和实践进行有效的防御。

Sequencer Mode的优势和风险

Sequencer Mode是Arbitrum的一个可选特性,主网上线的初期,官方(Offchain Labs)会运营唯一的Sequencer节点。

Sequencer被赋予权利,可以控制每笔交易在Inbox中的顺序,从而确保它可以立即确定客户交易的结果,而无须等待以太坊上5分钟左右的区块确认时间,甚至也不需要等待15秒的区块创建时间。

同时,一个正直的Sequencer可以有效的防御抢跑攻击(Front-Running Attack)。

因此,由官方运营一个中心化的正直的Sequencer节点,对项目早期的发展可能是非常有益的,可以减少很多麻烦,但安全风险也显而易见(虽然很难想象官方会去自己作恶)。所幸官方承诺,会在技术成熟后,尽快切换至去中心化的多Sequencer节点方案。

除此以外,Inbox会被一分为二,一个接受Sequencer提交的交易,一个接受常规的Aggregator或者用户提交的交易,这也给不信任中心化Sequencer的用户提供了另一个选择。

写在最后

DeGate作为专注以太坊二层的去中心化交易所,用户的资产安全是我们的首要考量。通过对Arbitrum安全机制的全面研究,可以看出官方确实在安全问题上下了很大功夫,方方面面考虑的较为全面,且有相应的文档对其安全理念进行了阐述。

DeGate将积极研究在Arbitrum上搭建部署相关产品,并将很快上线DeGate Bridge服务,为用户提供方便快捷的Arbitrum和以太坊之间的跨链资产桥。

了解DeGate:

Website: https://degate.com/

Medium: https://medium.com/degate

Twitter: @DeGateDex

Telegram ENG: https://t.me/degate_public

Telegram 中文: https://t.me/degate_chinese

Discord:https://discord.gg/s2e8EujXnn

Docs: https://docs.degate.com/

—-

编译者/作者:DeGate爱好者

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...