分叉链、孤块与区块重组_作者Shdders是比特币(BSV)扩容计划的首席开发_区块链大发棋牌APP下载_区块链神吐槽
区块链大发棋牌APP下载资源分享
追寻中本聪先生的脚步

分叉链、孤块与区块重组_作者Shdders是比特币(BSV)扩容计划的首席开发

分叉链的安全性与未分叉链的安全性几乎相同,没有交易损失或双花,重组是比特币的特性。

​​作者:Shadders,原文标题《On forks,orphans and reorgs》,首发于www.yours.org | 2019-4-21

注:Shdders是比特币(BSV)扩容计划的首席开发

概要(TLDR):

  • 分叉链的安全性与未分叉链的安全性几乎相同。
  • 没有交易损失或双花。
  • 重组是比特币设计的一部分,并激励励更安全的零确认。
  • 该设计将分布式系统的不可靠性从一个问题转化成一个特性。

背景

2019年4月18日,我们在比特币 SV 区块链上看到了一个有趣的事件。两组矿工开始采矿竞争链,导致两链重组。

Twitter上的标题数字是:重组了3个区块,紧接着又重组了6个区块。没有被指出的是,6个区块重组封装了3个区块重组,所以从局外人的角度来看,它就像链条的一部分切换到一个更长的分叉,然后一旦原来分叉变得更长,又切回去。想象一下,如果有人领先,然后又退回到第二位。

我还知道没有报道的标题数字是:在事件中,没有任何链与比另一链领先两个区块。也许更重要的是,我们很少看到关于对用户影响的讨论。

也有评论:

基于目前最大工作量的BSV 链,系来自分叉的所有 txid (币基交易除外)组成的主链。因此,似乎没有发生双重花费。

什么是重组?

简而言之,它是中本聪共识的正常组成部分。首要的是明确概念。重组是一次事件,而孤块(或链)是事件的结果。早在2014年,CEX.io的报道就指出,BTC区块链每天约有1-3次孤块发生:

What is an Orphan Block?

当两个矿工在接近同一时间发现一个区块时,网络就分成两组矿工在不同区块的高度开采。这通常在找到下一个块时解决。其中一个竞争区块被保留下来,因为它现在是更长链的一部分,而另一个成为孤块。偶尔有两个第二块在接近同一时间被发现,竞争继续,一旦第三个区块挖出,可能有两个区块被孤立。

缓慢的区块传播会加剧这种情况。我们早些时候注意到"矿工们几乎在同一时间发现了一个区块"。真正重要的不是矿工找到区块的时间,而是其他矿工看到区块的时间。

他们将开始在他们首先看到并验证的高度之上进行挖掘。矿工们受到高度激励,将避免他们的区块被孤立(如果这种情况发生,他们将失去区块奖励) ,同时他们也受到高度激励去迅速传播区块。

用户为什么要关心这个?

简而言之,他们可能无需关注,这只是矿工们的问题。人们有一个普遍迷思,即认为孤块中的交易发生了不好的事情。或者丢失了,或者双花了?我们可以证明前者是错误的,而后者是如此不可能,以至于不值得担心。我们还可以证明,从用户的角度,分叉链的安全性与未分叉链的安全性几乎完全相同。

然而,他们关心的一个可能原因是想理解这是如何工作的。关于比特币如何真正安全地工作,已经错过了过去的10年,这是一个宝贵的教训。

重组时,节点中发生了什么?

首先需要指出,所有节点对比特币账本状态的视图略有不同。这个视图通常被称为 UTXO 集,我们将看到 UTXO 实际上并不是一个静态的东西即每个块只改变一次,它的视图是恒定变化的。

一个节点的作业可以归结为回答一个简单的问题。“此交易是有效的还是无效的?” 这个问题的答案取决于他们对比特币历史的看法。

这段历史由两部分组成,一部分是节点看到的包含在最长链区块中的交易,另一部分是它们看到的未验证交易(又称内存池)。复合视图(请记住,这是瞬态 UTXO 集)是通过将后者叠加在前者之上获得的。

这使得他们要回答这样一个问题:"这笔新的交易中有哪些input是双花的?"。

此视图是不断变化的,通常是为了响应看到的新交易。偶尔是为了响应重组。但是在后一种情况下,它并没有改变太多,事实上也许根本没有改变。

当一个节点看到一个新的最长链时,它会经历重组过程。首先是回滚,然后是前滚。引擎盖下面是这样的:

  1. 对于孤立链上的每个块(从最高的开始向后工作),它获取该块中的每个交易并将其放回内存池中。这些交易暂时被认为是"未经验证的"。请注意,这些块中不能有任何双花,因为节点已经验证了它们,已在其内存池的所有交易都已在历史上经过测试,该历史也确保了这个区块不存在双花。
  2. 一旦我们到达了分叉块,我们就开始在新的最长链上向前工作,以通常的方式验证新块。对于新块中的每个交易,我们检查内存池中是否有该交易。如果我们这么做,它会被从内存池中驱逐出去。我们还检查我们的内存池是否包含该交易的双花,也将其驱逐出去

步骤1可能是最需要注意的。节点正在做的是有效地从孤块中提取交易,以确保如果它们不在更长链中,不会丢失。

Bitmex 的研究证实了这种情况:

基于目前最大工作量的BSV 链,来自分叉的所有 txid (币基交易除外)使其成为主链。因此,似乎没有发生双重花费。

但是,如果内存池达到了它的极限,它们就会丢失,据我所知,所有挖矿节点** 都配置了许多 GB 的内存池,因此需要大规模的重组才能发生这一事件。在未来,我们计划将这些交易写到磁盘上,以便在这种罕见情况下,万一内存池确实满了,可以回退。

因此,节点的交易历史复合视图可能出现的唯一变化发生在,当新的最长链包含了节点尚未看到的交易时。在通常情况下,这种情况应该相当罕见,但即使发生了,也不会伤害任何人。

对节点实际上如何处理重组的理解,以及"先见原则"的魔力,将我们引向了一个有趣的问题。

只需问一问矿工。

最近几个月,我一直在谈论先见规则。

如果一个矿工接受了一个交易,他们不会让双花交易进入内存池,即使它有更高的费用。唯一的例外是,如果他们接受了一个包含双花的重组链(某些条件下它们也许不会出现在未来)。

因此,如果你想确保一笔交易即使面临重组也不会双花,你可以通过询问所有的矿工来得到一个相当肯定的答案。如果您是一家理解风险 / 回报的企业,您可能不会对所有交易都这样做,也许只是一个高价值交易的样本。但是,如果所有的矿工都回应并告诉你,他们已经接受了这笔交易,那么即使其中一个矿工进行了重组,你的交易也将包含在分叉的两边。

是的,这种大发棋牌APP下载确实需要一种查询矿工的方法,其中之一是我们目前正在开发的“商户到矿工(merchant to miner)” API,它将在第三季度的某个时候采用,不过它也证明了解决那些关心确认数的少数用户的问题是多么的简单。

那么双花呢?

只要没有不诚实的矿工潜伏在网络的某个地方,上述技巧就是有效的。然而,这并没有改变双花发生的风险,只是在你可能知道的时候改变了。在几乎所有情形下,这都将是下一个区块。较长时间的重组所带来的额外风险,只有在恶意矿工正在秘密开采一个长链并计划在稍后释放时才会显现。从逻辑上讲,他们不会这么做,除非他们拥有超过51% 的哈希能力。这就是中本聪在白皮书中描述的攻击,假设51% 的节点都是诚实的,是比特币安全主张的基础。因此,我们可以安全地得出这样的结论: 因为重组而产生的双花风险与正常情况下发生的双花风险没有什么不同。

在后面的帖子中,我将解释,为什么我认为即使是这种情况也不太可能发生在比特币 SV 网络上,一旦在不久的将来做出一些改变。

我们能从中学到什么?

关于安全

如果有一个工具可以同时监控两个链(比如交易所),这将不是一个问题。 @nikitazh 在推特上评论道:

“网络基本上停滞了1.5个小时,这表明即使6次确认也不够。”

我会假定Nikita是善意的,并认为这是误解,而不是误导。对于那些看到两条链的人(两条链的区块头都被广播以便任何人请求区块),最多出现一个两区块的高度差异。如果你可以看到你的交易包含在链的两个分叉,那么重组就算有100个区块长度也无关紧要了。在没有另一个隐藏链时,无论谁赢,你的交易总能得到确认。

这只关系到那些因为选错分叉而受到惩罚的矿工。事实上,这是这个系统的一个特征。通过激励矿工提升自己的能力以避免这种惩罚,随之获得了更快地接受和传播交易的能力,此对于确保强大的零确认安全至关重要。这就是中本聪设计的精妙之处。它解决了分布式系统设计的基础问题,而不是试图解决所有问题,它把这些问题与激励结合起来,使之成为一个特性。

这次事件是关键是什么呢?

“分叉不是问题,要害在于选择正确的工具"。

比特币目前的状态是,许多企业过于依赖节点软件来做不该做的事情。如果你真的关心确认数(据我所知,只有交易所才真正关心确认数),那么设置你的系统,使得可以监视两个分叉,然后从这两个分叉中选择一个最小的确认数作为你的决策依据。如果你想要一个健壮的系统来计算确认数,这就是所需要的。如果您正在运行一个每天处理上千万美元规模的交易所,那么对于开发团队,这不是一个大的要求。

另一种方法是要求更多的确认,这样可以简单地把责任抛回节点,除非有一个分叉比需要的确认数更长。我们不要忘记2013年发生的24个区块重组。 那次事件是因为一个软件错误。但它也可能发生于主网故障或任何其他原因,所以你得预计这种情况可能时时发生。

关于服务的延续性

在这次事件中,我们确实观察到一件不幸的事情,那就是在比特币 SV 区块链顶端运行的一些服务跟不上。挖矿节点 * * 运行很好,尽管有点紧张,响应速度有点慢,我稍后将介绍,但其他方面都按预期工作。一些区块浏览器要么停止更新,要么响应迟滞,unwriter 的一些服务在处理重组时遇到了问题。

压力测试是有用的,因为他们聚焦了这种能力不仅及于节点软件,还及于使用区块链的服务。我们有一个持续进行压测的地方,叫扩容测试网络(也称为 STN)。我借此机会邀请任何受到影响的服务在 STN 上运行其服务的测试实例。 在这些问题未成为主网的问题之前,先行聚焦,并为开发团队提供有用的数据来帮助发现性能瓶颈。顺便说一句,我们将在几天内向开发者和企业发出正式邀请。

节点性能

前面提到过挖掘节点 * * 的行为与预期一样,尽管速度减慢。多年来众所周知,两个相同大小的区块,一个有少量的大交易,另一个有大量的小交易,将具有完全不同的性能特征,这并不奇怪。然而,这个事件凸显了另一些问题,通过对节点性能、区块时间和区块大小的分析,倾向于证实我们从广泛的研究中得出的大多数结论,即不仅仅是节点性能,更是交易和区块的传播性能问题。幸运的是,针对这几个问题的修复工作已取得进展,其中一些将在6月份发布,其余大部分将在下一次发布。不幸的是,这些细节太长,本文不足容纳,所以我将很快另写帖子阐明。

* * 备注: 在本文中,我多次提到"挖矿节点",以区分向矿工提供区块模板的比特币 SV 实例和不向矿工提供区块模板的比特币 SV 实例。应该注意的是,挖矿是节点定义的一部分。 那些没有参与挖矿的比特币 SV 实例更适合被称为"胖钱包(fat wallet)"或"区块链监听器(blockchainlisteners)"。

译校:刘晔律师,上海市海上律师事务所合伙人


微博@上海刘晔律师


分享到:更多 ()
区块链神吐槽

来评论吐槽 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

区块链资源分享

韭菜的自我进化