以太坊经典被攻击之后, 国外大神用矿池让51%攻击者付出代价

比如说,如果最后 100 个区块由 50 个不同的矿池挖出,则矿池前后一致性指数将等于 0.

众所周知,在 区块链 中,只有大部分人受利益(挖矿奖励等)的驱动表现出诚实行为整个 区块 链 才能正常运行,但如果诚实行为获益低于欺骗行为,就会有人铤而走险,如果铤而走险的人占据大多数,整个 区块 链 就会出现各种各样的问题,最典型的莫过于 51% 算力攻击。

那么问题来了,去中心化实现了权力的下放,而下放后权力又该如何制衡保证不作恶?

国外大神Tomaz Kariz受到矿池的启发,提出在选择 区块 链 时将 区块 链 中的“诸侯” 矿池 作为一个影响因素,引入 区块 链 评分机制以及惩罚机制,奖惩结合从而让51%攻击的成本更高。

那么, 矿池 与 区块 链 的选择如何结合?效果又会怎样?让我们跟着大神一探究竟!

作者 |phyro — Tomaz Kariz

译者 | Guoxi

出品 | 区块 链 大本营(blockchain_camp)

前段时间,以太坊经典( ETC ) 区块 链 遭受了51%算力攻击,这引起了我深深的思考。

从理论上来说,我认为 51% 算力攻击并不是 区块 链 网络设计的败笔,但我们是否有办法让这些 51% 算力攻击的攻击者付出更昂贵的代价?

当一个 区块 链 节点客户端发现同时存在多个 区块 链 时,它必须决定选择哪个 区块 链 ,这时节点客户端会分别计算每个 区块 链 的评分 chainScore ,然后选择分数最高的 区块 链 。

在PoW共识的 区块 链 中,选择 区块 链 的规则通常被称为“最长链规则”,其中 区块 链 的评分 chainScore 等于该 区块 链 上完成工作量的总和。这种根据评分来选择 区块 链 的好处在于它是完全客观的。

一个主观评分的例子是, 区块 链 节点客户端对 区块 链 的打分标准不仅根据在该 区块 链 上完成了多少工作量,还考虑到了如果切换到该 区块 链 时将从本地维护的 区块 链 中删除多少个 区块 ,即对那些可能需要你更改本地维护 区块 链 的 区块 链 带有偏见。

基于将从本地维护 区块 链 中删除的 区块 数量的主观 区块 链 评分

另一个主观 区块 链 选择规则的例子是照常计算 区块 链 评分 chainScore ,但只有在切换到它需要从本地 区块 链 中删除的 区块 数不超过 20 个时才切换到这个具有更高评分的 区块 链 (该规则通常被称为最大化重组覆盖,max reorg cap )。

这个规则不仅会出现“新节点问题”(如上图所示),而且即使所有节点都运行着相同版本的客户端程序,它也可能会导致硬分叉。

所以我们要避免主观地对 区块 链 进行评分,因为这样做我们的 区块 链 选择逻辑就会很难解释,并且即使每个客户端节点都遵循相同的规则也可能会导致硬分叉。

区块 链 选择规则

以太坊 经典使用的 区块 链 选择规则是选择完成工作量最多的 区块 链 。假设一个名叫 Bob 的 以太坊 经典客户端正在第一次连接 以太坊 经典网络,Bob 必须在多个 区块 链 之间做出选择,不过这并不是问题,他所要做的就是计算每个 区块 链 上完成了多少工作量并选择完成工作量最多的 区块 链 。

即使我们有任意多 Bob 这样的新入网 以太坊 经典客户端,对每个 区块 链 它们都会计算出完全相同的评分 chainScore 。

在 区块 链 系统中给定 N 个节点,这 N 个节点构成一个完全图(每个节点都连接到其他所有节点), 区块 链 选择规则应具有以下属性:

每个节点都应将同一个 区块 链 视为最佳选择。

区块 链 选择规则还应为 区块 链 C 提供相同的评分 chainScore ,不论任意时间点以及任意高度 H ,这意味着评分 chainScore 应该仅取决我们正在评估的 区块 链 上的数据。

这些属性确保 Bob 和长寿命节点就需要追随的 区块 链 达成一致,并使它们随时间的推移逐渐收敛到同一个 区块 链 上。

需要注意的是,正如我们上面提到的,当下 以太坊 经典中评分chainScore最大的 区块 链 是那些完成工作量最多的 区块 链 。

区块 链 挖矿

对于单独 挖矿 的矿工而言,除非他掌控相当大的哈希算力,否则他不太可能会挖出 区块 。

矿池 就是为了解决这个问题而被发明的, 矿池 借鉴了“众人拾柴火焰高”的思想,大量原本单独 挖矿 的矿工聚在一起抱团取暖,共同 挖矿 ,共同分享收益,所以即使某些矿工可能都没有挖出一个 区块 ,但始终能获得稳定的工作回报。

假设 区块 链 网络中有多个 矿池 ,它们总共占据网络中的大部分哈希算力。

每一个 区块 都包含一个被叫做 coinbase / etherbase 的数值,它用来指代挖出该 区块 的矿工,表示应该接收 挖矿 奖励的地址。

大多数 区块 都是由 矿池 开采的,每个 矿池 通常都会指定一个用来接收 挖矿 奖励的地址。

下面是 以太坊 经典 区块 链 上从高度 7283680 到高度 7283695 开采出的 16 个连续 区块 ,以及它们接收 挖矿 奖励的矿工地址:

以太坊 经典 区块 链 上高度 7283680 到高度 7283695 的 区块 ,以及它们接收 挖矿 奖励的矿工地址

正如预期的那样,绝大多数 区块 都是由 以太坊 经典网络中运营的 矿池 开采出的,其中 矿池 Ethermine 开采了 5 个 区块 , 矿池 MiningPoolHub 开采了 4 个 区块 , 矿池 NanoPool 开采了 3 个 区块 。

在灰色的 区块 中 挖矿 奖励被发送到我不知道所有者是谁的地址,但它们很可能也是 矿池 。

这似乎给了我们一点启发……

利用 矿池 降低51%攻击?真的!

假设我们有能连续挖出新 区块 的 矿池 ,我们应该能经常看到 区块 的产出。当攻击者进行 51% 算力攻击时,他通常会离线连续挖掘 N 个 区块 ,然后发布一个比当前共识链更长的 区块 链 ,从而导致当前共识链的重组。

攻击者开采的 区块 通常不使用我们过去观察到的 矿池 的地址。

如果对 矿池 挖矿 的前后不一致性进行惩罚,我们就可以在共识规则大致不变的前提下大大增加攻击者发动攻击的成本,从而保护我们免受51%算力攻击。

在这里,我们需要先明确一下 51% 算力攻击是如何发生的:

    使用算力租赁服务(例如 NiceHash )来执行攻击(假设 NiceHash 并不是 矿池 )。

    一些 矿池 暗中勾结执行攻击。

    上面两者的结合: 矿池 暗中勾结+算力租赁服务执行攻击。

    使用专用集成电路(ASIC)执行攻击。

    矿池 前后一致性指数

    区块 链 选择规则不仅可以考虑已完成的工作量,还可以考虑 矿池 的前后一致性。我们可以通过将 chainScore 的定义更改为以下公式来加入 矿池 的影响:

    chainScore = parentChain.score +block.PoW_score * PCI

    其中 parentChain.score 为前序 区块 链 的评分,block.PoW_score 为该 区块 链 所做的工作量, PCI( 矿池 前后一致性指数,Pools Consistency Index)为介于0和1之间的值。

    这里的 PCI 表示 矿池 的前后一致性。让我们来看一个使用 矿池 信息来评估 区块 链 “健康”程度的一个实现。

    在最后 3000 个 区块 上使用滑动窗口来衡量工作量前后一致性的示例。

    chainScore 函数的代码实现如下所示:

    滑动窗口 矿池 前后一致性增量的参考实现

    当网络中多个 区块 链 共存时,我们认为最可能成为共识链的会是那些矿工在持续 挖矿 的 区块 链 。这种说法并不是百分百正确,但对于大多数情况都是如此,除非出现掌握超过 51% 哈希算力的 矿池 叛变的情况

    这种结合 矿池 信息的方法可以预测 区块 链 的未来是什么样的,并惩罚那些恶意行为者,而这些在过去是不可能实现的。当我们对 矿池 的前后不一致设置非常高的惩罚时,会出现以下两种情况:

      网络中仅存在一个 区块 链 ,一些 矿池 停止 挖矿 。由于对于所有的矿工而言,他们的 PoW 值都会相应的降低,所以这对矿工来说无关紧要,因为 区块 链 评分 chainScore 很低并不会影响他们的 挖矿 收益。

      网络中多个 区块 链 共存,在这种情况下, 矿池 前后一致性较低的 区块 链 (通常是 51% 算力攻击)将受到惩罚。

    那么,这种方法在上面所提到的几种51%算力攻击面前效果如何?

    使用算力租赁服务(例如 NiceHash )来执行攻击

    由于其他 矿池 不会在他的 区块 链 上继续 挖矿 ,随着时间的推移攻击者会受到 矿池 前后不一致惩罚。

    两个共掌握全网 60% 哈希算力的 矿池 联合执行攻击

    为了解决这个问题,我们不仅需要考虑 矿池 的哈希算力,还需要考虑在 区块 链 上 挖矿 的 矿池 的数量。如果我们有大于 10 个具有大致相同哈希算力的 矿池 ,那么这个问题就会变得更容易解决。

    两者的结合

    例如一个掌握全网 40% 哈希算力的 矿池 又租用了全网 30% 的哈希算力执行攻击。

      随着时间的推移攻击者会受到 矿池 前后不一致惩罚。值得注意的是,即使攻击者将租用哈希算力挖出 区块 的矿工地址设置为原本 矿池 的地址也无济于事,因为我们会查看已挖出 区块 过去的数据。

      使用专用集成电路(ASIC)执行攻击

      这看起来像是长期的 51% 算力攻击。攻击者会随着时间的推移受到 矿池 前后不一致惩罚,但如果他能继续坚持下去,他就可能会成为我们参考的“过去的 矿池 ”。在这种情况下,问题演变成了如果一个 矿池 叛变。

      虽然这种方法并没有解决 51% 算力攻击,但它能使攻击者的攻击成本变得更加高昂,因为攻击者会在很长一段时间内持续受到惩罚(很多个 区块 时间)。

      如果几个 矿池 突然停止 挖矿 ,监控系统可以发觉这种情况,社区会有一些时间来做出反应,例如开始自己 挖矿 (但由于惩罚机制的存在他们必须小心)或者只是在发生这种情况时等待更多后续 区块 的确认。

      基于这些情况,我们先做了以下假设:

        将 矿池 作为网络的一部分从而加强 区块 链 的安全性。当然了如果一个 矿池 可以通过各种手段掌握全网 51% 的哈希算力,那么他还是可以执行 51% 算力攻击,不过这并不是我们引起的新问题,就我目前的了解,业界还没有针对这种问题的解决方案。

        一旦 矿池 A 挖出了一个 区块 ,所有接下来的 29 个 区块 都将获得 矿池 A 的前后一致性奖励,无论这些 区块 是由谁挖出的,因此,与其他人相比, 矿池 A 并没有获得任何优势。

        “墙头草”矿工仍然受欢迎,但如果他们突然开始挖出大量 区块 ,他们可能会受到惩罚。如果他们有些前后一致性,我们不会对他们进行大量惩罚,他们可以轻松地挖出新的 区块 。有人可能会说这样会降低安全性,但我的预感是,你从获得 矿池 前后一致性指数获得的收益远远超过没有“墙头草”矿工而失去的收入。

        只要每个新 区块 保证为 区块 链 添加一些积极价值, 挖矿 就可以在没有 矿池 存在的情况下继续运行。

        由于独自 挖矿 的矿工很难开采出一个 区块 ,因此惩罚对他们的影响基本上为零。我认为他们中的大多数人都希望参与到 矿池 之中。

        新来的更大的 矿池 将不得不逐渐加入 区块 链 中,否则它们会因为 矿池 挖矿 前后不一致导致其挖出的 区块 受到惩罚。

        矿池 前后一致性公式( PCI )以及 区块 链 评分 chainScore 可以有多种定义方法。

        对于具有较低 区块 间隔时间的 区块 链 ,这种方法可以更好地工作,因为同样的一段时间里这种 区块 链 可以获得更多有关 矿池 一致性的信息。

        接下来,我们需要用博弈论的方法来对这个假设进行验证。需要注意的是,可以考虑不调整 PoW 的值,而是使用 PCI 作为附加值来保持 PoW 一致。

        滑动窗口 矿池 前后一致性增量测试的结果

        我通过模拟出一个理想的 区块 链 从而在一系列的连续 区块 中检测 矿池 前后一致性的想法。

        虽然结果显示,使用滑动窗口 矿池 前后一致性增量与最长 区块 链 机制(当前被大部分 区块 链 采用)相比, 51% 算力攻击的成本会更加昂贵,但应该注意的是,由于测试过程中可能存在瑕疵,代码中可能存在错误,或者是模拟出的环境过于理想/简单/错误,这样的结论可能会存在问题,因此离在 区块 链 上实际使用可能还有很长的路要走。

        在这次实验中我创建了大约 5500 个 区块 (过程持续了 5500 * 14 秒),攻击者在高度为4850的 区块 处进行分叉。默认情况下, 区块 的间隔时间约为 14 秒,在代码上我做了很多的简化,并没有完全符合在当前 区块 链 中使用的逻辑(例如, 区块 时间的计算不一样,没有叔块)。

        尽管存在差异,但我认为这个实验足以检验我们的想法。实验结果如下所示,结果中 Ratio (比值)表示主链和攻击者在 区块 高度 4850 处生成的分叉链之间 区块 链 评分 chainScore 的比值,如果这个比值低于 1.0 意味着主链的 区块 链 评分 chainScore 的总和低于攻击者分叉链的总和。

        我们还可以从图中看到两个 区块 链 达到的高度。

        实验结果

        从图中我们可以看出,较传统的最长链方法,滑动窗口 矿池 前后一致性增量方法更容易选中主链,不过即使这种方法获胜很多,在真实的 区块 链 环境中这种方法的效用还有待检验。

        从上面这个结果表中我们可以看到,在所有的情况下分叉链最终都挖出了更多的 区块 ,但在滑动窗口评分方法中分叉链的评分 chainScore 从未超过主链(这并不完全正确,因为它可能在开始时获得了更高的分数,但在这次测试中,分叉链最少领先主链 30 个 区块 ,并且评分也更高)。

        如果攻击者能够坚持足够长的时间,他就有可能成为“ 矿池 历史”的一部分,随着时间的推移分叉链的评分chainScore 会超过主链。

        当然了,这次实验代码除了我以外还没有任何人检查过。如果你发现了代码中存在的问题,请向我提交。

        已知的攻击向量

        51%算力攻击

        尽管如此,攻击的成本可能要贵得多。

        矿池 冒充攻击

        攻击者可以挖出更长的 区块 链 并在其中插入其他 矿池 的矿工地址,从而将攻击者挖出 区块 的 矿池 分布调整为与攻击前大致相同的分布。

        为了防范这种情况,我们需要为矿工提供某种形式的身份证明。这可以通过在 区块 头中添加名为 minerSig (矿工签名)的身份验证信息来解决。 minerSig是使用矿工私钥签名的前序 区块 哈希值 parentHash 和该 区块 的随机数 nonce ,为了使 区块 有效,我们需要检查这个验证。

        攻击者加入主网络

        攻击者可以加入主网络并挖出一些 区块 ,以避免以后被识别出突然大量 挖矿 。这种情况可以参考如果一个 矿池 叛变。

        改进措施:摆脱 矿池 假设

        在协议级别上实施 矿池 机制可以保证 矿池 确实存在。但即使我们没有 矿池 ,协议也能够针对这种情况进行相应的优化。

        就比如说,我们可以鼓励矿工聚集起来,组建一定数量的 矿池 ,具体的方法就是根据每个 矿池 的哈希算力给予 挖矿 奖励,从而汇聚成总共 N 个 矿池 。假如我们想要大约 20 个 矿池 ,那么对于占据全网哈希算力 5% 的 矿池 , 挖矿 奖励最高(4 ETC )。

        如果 矿池 的算力多于/少于这个值,那么 矿池 获得较低的奖励,剩余的奖励将根据其他 矿池 的哈希算力分配给他们。由于我们最终为每个 区块 创建了相同数量的 挖矿 奖励(在这种情况下为 4 ),因此它并不会改变货币政策中定义的流通中的总货币。激励措施需要正确完成,以便矿工按照我们的想法聚集。

        这里要提醒开发者以下,即使一个人拥有 5 个 矿池 ,每个 矿池 都掌握全网 5% 的哈希算力,这也没有问题,因为它增强了 矿池 的前后一致性,从而为我们提供了额外的安全性。

        如果已经存在 矿池 ,就比如说当下的 以太坊 经典,那么如果需要,也可以在稍后阶段实施。

        其他可能的 矿池 前后一致性定义

        矿池 前后一致性公式可以执行以下操作。

          基于 矿池 数据和相似分析的线性回归。

          惩罚哈希算力的增长(无论是对单独的矿工还是对整个网络)。对网络惩罚的想法是,如果没有恶意 区块 链 ,那么对每个人的惩罚都是相同的,如果存在一个想要抢占先机的恶意 区块 链 ,那么它将受到更多的惩罚。由于 区块 时间戳可能是伪造的,因此仅从 区块 链 数据中很难给出这样的客观分数。

          如果独自 挖矿 的矿工或 矿池 在给定的 区块 窗口内过快地增加挖掘 区块 的比值,则给他们“超速罚单”。

          对矿工的数据进行统计分析。

          协议级 矿池 的 矿池 前后一致性示例

          假设我们有一个 区块 链 ,它具有内置的激励机制,用于让每个 矿池 的哈希算力收敛到全网的 1% ,从而形成总共约 100 个 矿池 。

          为了使 矿池 能够对 矿池 前后一致性指数做出贡献,它需要在最后 3000 个 区块 上以大约 1% 的哈希算力进行一致地挖掘。 矿池 前后一致性指数将是通过此标准的 矿池 的比值。

          比如说,如果最后 100 个 区块 由 50 个不同的 矿池 挖出,则 矿池 前后一致性指数将等于 0.5 ,因此贡献 0.5 难度。

          在这种情况下,如果攻击者想要进行攻击,他需要挖最后 3000 个具有不同矿工地址的 区块 中的 50% 才能开始获得与主链相同的 矿池 前后一致性指数。除此之外,我们还可以对 矿池 发“超速罚单”。

          假设我们有 100 个具有相同哈希算力的 矿池 ,我们也可以做一些统计分析。所有 矿池 都具有相同的“被选择”的概率,这意味着我们可以计算最后 100 个 区块 状态的可能性,假设它们是随机选择的,那么我们可以对结果不太可能发生的事件进行惩罚。

          写在最后

          说了这么多,我并不是说人们应该改变他们的共识算法,而是应该有一个很好的理由来推进共识算法的改进,并且在考虑任何变动之前都应该很好地研究替代方案。

          这只是我对共识算法改进的一些思考,我的想法能降低网络51%算力攻击发生的可能性。

          无论如何, 矿池 将成为 区块 链 网络的一部分,所以为什么不物尽其用来为 区块 链 增加安全性呢?

          我们仍然可以将这种方法看作一种最长链机制,不同之处在于我们改变了测量 区块 链 长度的方式。我更青睐于人们使用更通用的描述,例如最大 区块 链 评分规则。


          声明:本文来自imtoken平台用户投稿,观点仅代表作者本人,不代表【imtoken-www.5798.com.cn】立场,文章内容仅供参考,如若转载请标注文章来源:【当前页面链接】

区块链相关

区块链媒体相关

区块链技术相关

挖矿相关

比特币相关