Avalanche 如何解决比特币现金中的常见问题

描述

一位 Reddit 用户前几天表示，他不明白 Avalanche 的必要性，也不明白它真正解决了什么问题。 这似乎是对 Avalanche 的普遍看法。 在这篇文章中，我将尽力阐明我们目前在比特币现金方面遇到的问题以及 Avalanche 如何解决这些问题。 Avalanche 可以以两种方式使用——共识前和共识后——所以我将在本文中描述它们。

预共识

有什么问题？ 实际上有两个——区块传播和零确认。

块传播

既然我们已经了解了 Graphene 等块压缩算法，我们社区中似乎有很多人认为块传播是一个已解决的问题。 但是这个问题还真的没有完全解决。 我们所有的区块传播算法，包括 Graphene、XThin、Compact Blocks 和 XThinner，都依赖于网络中每个节点的内存池相互同步。

如果每个节点都已经拥有区块中的所有交易，那么区块传播只会成为一个挑战，即只传输最少的必要数据以便在内存池中传输区块中的这些交易，而不是完成交易本身。

但是，内存池可能不同步的原因可能有很多，尤其是当网络上的交易量增加时。 这些原因包括：

1. 不同的内存池策略：节点总是可以自由选择自己的内存池策略。 一些节点拒绝非标准交易，而其他节点则接受它们。 一些节点拒绝接受零费用的交易，而另一些节点则接受等等。 这些差异不一定会导致一次性差异，而是建立在这些交易上的任何未经确认的交易链都将在拒绝其依赖项之一的节点的内存池中丢失。

2.双花：当同时发送双花时，不同节点第一次看到的交易不同。 与上述情况一样，如果未确认的交易链建立在这一交易或另一交易之上，则内存池差异会被放大。

3. 高容量：在交易量非常大的情况下，网络中有很多交易，节点会因为正常的传播延迟最终产生完全不同的内存池。

那么当内存池不同步时会发生什么？ 这意味着我们的块压缩算法不能很好地工作，甚至根本不能工作，因为我们需要通过块来传输完整的交易，而它们不在 mempool 中。

这是 BU Gigablock 测试网研究的结论之一。 在大约 100MB 块的持续吞吐量下，有时网络上各个节点的内存池彼此不同步，以至于 XThin 压缩算法根本无法为传播 100MB 块提供任何压缩。

而且，由于传播一个完整的 100MB 区块可能需要超过 10 分钟或更长时间，这意味着区块链将分叉并继续前进，导致共识失败和系统彻底崩溃。 Peter Rizun 的研究中提到了这一点。

雪崩如何提供帮助？

作为一种预共识机制，Avalanche 可以帮助保持内存池同步，以不同方式部署它。 在这一点上，我们仍然只是在谈论 Avalanche 并研究最好的方法，但是如果你要求所有交易在被允许打包之前使用 Avalanche，那么你最终会得到所有 Avalanche 感知节点允许在网络共识设置下打包交易集，因此块总是以最大速度传播，因为每个节点已经在块中拥有完整的交易集。

零确认

我们提出了一种改进的零确认双花证明方法，以防止快速重花​​攻击。 在这种情况下，攻击者几乎同时广播了两笔双花交易，由于彼此的结果都是非零概率，所以双花的两笔交易都会被打包。 我们的双花中继证明可帮助商家检测这些双花并拒绝付款。

一种棘手的双花攻击是矿工贿赂。 在这种情况下，攻击者会在双花交易中附加一大笔交易费用，试图贿赂矿工接受它。 在之前的文章中，给出的例子是攻击者购买了一台价值 4000 美元的电视。 他以 2,000 美元的费用广播双花。 如果任何矿工接受贿赂，他们将获得 2,000 美元，而攻击者将获得 2,000 美元的折扣。

如果即使是一小部分矿工愿意接受贿赂，零确认对任何人都不起作用，因为在这个可以进行欺诈的支付系统中，5-10% 的时间对于大多数商家来说是不可能使用的。

Peter Rizun 提出的研究表明，当今网络上有矿工乐于收受贿赂来打包双花交易。 所以这是我们想要解决的一个真正的问题。

雪崩如何提供帮助？

通过让节点提前就可接受包含哪些交易达成一致，它们必然会在挖掘区块之前解决冲突交易（双花）之间的冲突。 事实上，Avalanche 可以无缘无故地在几秒钟内批准交易。 假设我们可以做到这一点，任何在付款被接受后广播的双花都不会被接受。 即使大多数矿工，甚至所有矿工愿意收受贿赂来打包双花交易，也是做不到的。 因为他们无法回到过去，无法撤销已被 Avalanche 标记为最终交易的交易。

所以 Avalanche 有可能为我们带来近乎即时的确认。 或者至少在网络延迟允许的情况下尽快批准交易。

后共识

有什么问题？

51%攻击！

回顾白皮书，人们早就知道比特币（以及任何工作量证明加密货币）容易受到控制超过 50% 网络计算能力的恶意方的攻击。 作为采用 SHA-256 哈希算法的小型链，比特币现金处于非常不利的地位。 因为有很多大型比特币矿工，他们个人拥有大量的算力，足以攻击BCH。 尽管BCH采用不同的挖矿算法，拥有自己独有的ASICS，但总是有可能有足够资源的恶意者购买足够的算力来攻击系统。

事实上，这正是 11 月份比特币现金所发生的事情。 一个非理性的恶意行为者（Craig Wright）利用他的财富（或者更具体地说，Caliv Ayre 的财富）购买 ASIC，其公开声明的目标是对比特币现金进行 51% 的攻击。 最终他们失败了，但捍卫比特币现金付出了巨大的代价。 如果克雷格和卡尔文有更多的资源或者愿意花更多的钱去进攻，那么防守就非常困难了。

当时实施的临时应急防御策略是在网络节点构建完10个区块后，让网络节点决定“最终”区块。 Final 意味着软件将给定的块视为区块链的最终和永久部分。 如果没有这条规则，当 51% 的攻击者发布一个更长的链时，就会发生重组，而软件现在会忽略它，因为它试图覆盖标记为最终的块。

从表面上看，这听起来确实是个好主意。 那么，如果没有必要，我们为什么要保持深度重组和 51% 攻击开放呢？ 毕竟，如果历史交易被逆转，货币体系就无法运作。

这个问题的答案与客观性的概念有关。 加入网络的新节点，或从缺席状态返回的节点，只有一个客观指标来确定它们应该遵循哪条竞争链，这就是工作量证明。 如果现有节点拒绝深度重组并以较少的累积工作跟随链，则加入网络的新节点无法知道这一点。 结果是新节点将同步到攻击者的链，而现有节点将跟随他们自己的链，从而导致网络分裂。

还有一些人担心，51% 的攻击者可能会利用竞争条件导致现有节点相互分裂，尽管可以部署技术来减轻此类攻击。

雪崩如何提供帮助？

Avalanche 允许我们在不暴露上述问题的情况下进行终结。 当网络节点使用 Avalanche 来协调他们认为有效的链时，51% 的攻击者不会利用竞争条件来分裂网络。

此外，加入网络的新节点可以使用 Avalanche 来确定其他人正在关注哪个链，并将避免同步到由 51% 攻击者生成的链。

因此，在后共识 Avalanche 的情况下，51% 攻击者无法进行深度重组或任何重组。 这意味着一个确认将与当前系统中的数千个确认具有相同的权重。

51% 的攻击者也无法挖掘区块并对区块链执行某种形式的拒绝服务攻击。 空区块链的挖矿需要进行区块重组操作比特币需要解决的核心问题是，其他矿工挖出的区块都是孤块。 由于雪崩比特币需要解决的核心问题是，这是不可能的。 攻击者可以做的是，他自己挖出的区块有 51% 是空的，但其他人挖出的区块显然不会是空的。

雪崩有多安全？ 在某些方面，我们正在绕过 POW 的权限，这是否意味着现在整个系统的安全都依赖于 Avalanche 的安全？ 答案不是。

如果您查看 Avalanche 论文中的雪球算法，您会注意到具有系统攻击能力的拜占庭攻击者只能在他继续攻击时阻止区块终结。 例如，他不能让一些节点敲定区块 A，而另一些节点敲定区块 B，从而导致网络分裂。

所有这一切意味着，如果 Avalanche 系统遭到破坏，网络将默认回到我们从第一天开始就一直使用的中本聪共识。 块不会被最终确定，节点将跟随具有最多累积工作的链。 一旦攻击停止，区块将再次开始敲定。

因此，在 POW 之上使用 Avalanche 协议可以增强系统抵抗 51% 攻击的能力。 它具有以下安全属性：

如果攻击者的哈希算力 > 50% 大于攻击 Avalanche 所需的攻击拜占庭节点所需的阈值，则无法攻击比特币现金。

如果攻击者拥有 > 攻击 Avalanche 所需的拜占庭节点阈值，但没有 > 50% 的哈希算力，那么也无法攻击比特币现金。

只有当攻击者拥有大部分计算能力和足够多的拜占庭节点来攻击 Avalanche 系统时，才能实现对比特币现金的攻击。

希望这篇文章能消除对 Avalanche 的一些误解。 我们还有更多工作要做，以便能够在共识前和共识后的情况下更好地使用 Avalanche。 Avalanche 似乎是解决自比特币诞生以来就存在的一些棘手问题的有效方法。