观点 | 如何防范对智能合约的审查攻击?
这种设计模式在实践中会遇到的问题是审查攻击(censorship attack)—— 攻击者阻挠其他人在时间窗口内提出挑战。在交互式 rollup 协议中,攻击者可能会提出虚假的 “断言”,同时阻止其他人在窗口期发起挑战,最终导致虚假的断言反倒成为合法的。
我们也假设,攻击者必须先投入一笔资金,一旦攻击失败,它会失去这笔钱;这样一来,我们不需要让系统被成功攻击概率为零,而只要确保攻击成功概率足够小,就不会有人愿意去尝试攻击整个系统。
下文,我会总结有关审查攻击的知识,以及如何对抗审查攻击,最后给出我对这种风险的看法。
审查攻击的类型
审查攻击主要有四种:
- 分叉:矿工串通(或被贿赂)弃置包含正常挑战的区块,并通过分叉,使另一条没有包含任何挑战的区块链被接受。
- 闪躲:矿工密谋(或被贿赂)在出块时不打包正常的挑战。
- 干扰:攻击者通过传统的拒绝服务攻击(DoS),使得其他人无法提出挑战(无法发出包含挑战的交易)。
- 速攻:攻击者在很短的时间内提出大量的链上断言,让其他人来不及在时间窗口内对所有断言进行检查和挑战。
分叉攻击
分叉攻击是指在工作量证明(PoW)区块链上,攻击者获得大多数挖矿算力,并根据需求使用这些算力来孤立包含挑战的区块。
因为这类攻击要求攻击者控制绝大部分算力,所以很难发起——如果攻击者能够轻易获得大部分算力,表示这条区块链本身就有很大的问题。或者换个角度想,一个能够控制绝大部分挖矿算力的卡特尔,一方面会导致大家不信任他们所在的区块链,另一方面,可能也会有比审查攻击能更快从系统中榨出油水来的办法。
你可能会说,慢着!算力垄断者可能并不会高调地声张,只是偷偷摸摸地搞审查;如果攻击者有能力这么做,他们可能会在避免整个区块链信誉受损的前提下,通过分叉进行审查攻击。
这里引出第一个问题:审查攻击对于旁观者来说,是否易于察觉?为了证明分叉攻击是显而易见的,我模拟了分叉。假设攻击者控制了 60% 的算力,在前三十个区块中,出现三条分叉链,长度分别是 1、6、5;这和一般的区块链完全不同。我又做了一次模拟,这次攻击者控制 55% 的算力,这时候一个较早期的分叉可长达 48 个块。根据简单的数学模型预测,当垄断了 60% 的算力,则每 2.5 块会发生一次分叉,分叉导致的孤链平均长度为 5 ;当垄断了 55% 的算力,则每 2.2 块会发生一次分叉,分叉导致的孤链平均长度为 10。
可以看到,随着垄断的算力下降,分叉发生的频率及孤链长度反而增加了;但无论分叉长短,它们的共同之处是( 首块共性 ):在孤立分支上的首个区块一定包含有效挑战,而最终成为主链的分支则绝对不会包含这个挑战 —— 提出该挑战的人一定会发现这点!(攻击者可能会试图在更远处进行分叉来避免首块共性,但这会导致分支过长,而最终孤立的分支仍包含该挑战。)所以审查攻击一旦发生,就一定会被人发现。
我不知道你会怎么想,但如果我发现区块链中存在算力垄断现象,而且垄断者会时不时使用算力干扰应用层协议,我会感到非常担忧。如果其他人也有这种疑虑,整个区块链将不再被用户所信任——任何 51% 算力攻击皆会导致这个结果。
换言之,这种攻击的问题并不是有人会审查你的应用层的交易,而是你所处的区块链存在算力垄断者,它可以为了利益不受约束地破坏规则。对于任何区块链应用来说,不论 TA 是否采用窗口期设计模式,只要出现了这种算力垄断,就是毁灭性的打击。
如果你所在的区块链可能出现分叉攻击,你应考虑转移到其他区块链。
闪躲攻击
如果算力垄断者不采用容易被发现的分叉攻击,还有别的诡计吗?有的,就是闪躲攻击。恶意矿工只要在出块时,拒绝打包包含挑战的交易就行了;只要确保挑战窗口期内所产的区块,都由恶意矿工产出,攻击就能成功。
闪躲攻击成功的可能性有多大?可以这么解释:当垄断者控制的算力比例为 f ,挑战窗口期为 n 个区块,则攻击成功率为 f n 。举例来说,垄断者控制了 90% 的算力,挑战窗口期为 50 个区块,则攻击成功率为 0.5 %(如果控制了 95% 的算力,攻击成功率还要维持在 0.5 %,则窗口期要增加为 100 个区块)。如果攻击者要为攻击失败支付大量罚金 —— 就像 rolluo 协议所设计的那样 —— 他们就不会肆无忌惮地攻击;而且如果罚没的钱能返给受害者,大家还会喜闻乐见这些未遂的攻击。
所以应对闪躲攻击的办法是确保挑战窗口期足够长,使得攻击成功概率低至用户能接受的范围;假设你能接受的攻击成功率为 r ,攻击者至多能控制 f 的算力,则安全的挑战窗口期为 log(r)/log(f) 个区块。
这个建议在现实中也是合理的;假设攻击者能够垄断 99% 的算力,要保证攻击成功率低至 0.1%,则挑战窗口期至少要等于 log(0.001)/log(0.99) = 687 个区块,对于以太坊来说只需要不到三小时。
干扰攻击
在干扰攻击情况下,攻击者通过“传统的拒绝服务攻击”,来阻止其他人发出挑战;也就是“以 DoS 进行审查攻击”。
干扰攻击的问题是,攻击者必须阻止 “ 所有 ” 可能提交挑战的参与方,如果这些参与方足够多,则干扰攻击就很难成功。
对于攻击者来说还有个坏消息是,其他利益相关方可能会暗中雇用监视者 —— 一个暗中观察协议运行的中间方,在参与者来不及或难以发出挑战时介入,对无效的断言发起挑战。攻击者没办法辨别这些潜伏的监视者,也就没办法对他们发起 DoS 。
综上,对于攻击者来说,干扰攻击似乎不是个好选择。
速攻
速攻指的是,攻击者发布大量的断言,使得其他人来不及在挑战窗口期内检查所有断言。
任何的 rollup 协议都需要有防御速攻的机制,其中一种方法是对提出断言的频率进行限制,保证协议在设定的挑战窗口期内的任何时间点,全网都有足够的能力去检查待处理的断言或挑战。
这类机制会在一条 rollup 区块链上,针对智能合约的处理能力实施一种 “速限手段” ——即使存在某个能快速提出大量断言的人,他最终也不得不慢下来,确保其他正常参与者能跟上。
所以要衡量一个 rollup 系统的可扩展性,其中一个很重要的指标就是它在保证安全的前提下的最大速度限制;速限指的是一个系统能安全处理事务的速率,而不是某个参与者能够产出断言的极限速率。
总结
综上所述,有三种审查攻击能够通过合理的设计或实践来避免。
- 防范闪躲攻击:评估攻击者的资源和风险承受能力,制定合理的挑战窗口期。
- 防范干扰攻击:自行雇用(或通过可信的权威方雇用)潜伏的监视者,当你出差池的时候这些监视者能够代替你发起挑战。
- 防范速攻:更细致的设计 rollup 协议。
(完)
原文链接: https://medium.com/offchainlabs/fighting-censorship-attacks-on-smart-contracts-c026a7c0ff02 作者: Ed Felten 翻译&校对: IAN LIU & 阿剑
本文由作者授权 EthFans 翻译及再出版。