短交易标识符冲突检测和协调

技术领域

本公开涉及区块链网络，尤其涉及区块在矿工节点之间的传播。

背景技术

在工作量证明区块链系统中，矿工在发现有效区块时，试图将其成功快速传送给所有其他矿工。这涉及通过区块链网络向所有挖矿节点传播有关该区块的信息。在某些情况下，这可能涉及发送完整的区块数据。在某些情况下，这可能涉及发送区块头和交易列表信息。接收矿工通过哈希处理区块头并确认它与成功的矿工提供的哈希值匹配来验证新区块。

随着区块的大小和交易数量的增加，区块传播中的延迟会加剧临时分叉和孤块的问题。这些情况对矿工和整个系统来说都是代价高昂的。

可能有利的是，当传播区块数据时，设计用于减少区块数据消耗的带宽并提高传播速度的方法和系统；然而，这样的方法和系统可能引入需要有效解决的冲突的可能性。

附图说明

现在将通过示例的方式参考示出本申请的示例实施例的附图，其中：

图1示出了区块链网络的示例区块结构；

图2示出了区块传播的示例方法的流程图；

图3A-3I示意性地示出了根据本申请的区块传播的示例实现方式中的消息和操作的序列；

图4以流程图的形式示出了解决短交易标识符冲突的一种示例方法；

图5以流程图的形式示出了解决短交易标识符冲突的另一种示例方法；

图6以流程图的形式示出了解决短交易标识符冲突的另一种示例方法；

图7示出了默克尔(Merkle)树结构的简化示例；

图8示出了具有错误TXID的默克尔树结构的简化示例；以及

图9以框图形式示出了区块链节点的简化示例。

在附图中使用相同的附图标记来表示相同的元素和特征。

具体实现方式

在一个方面，可以提供一种解决区块链网络中的短交易标识符冲突的计算机实现的方法。该方法可以包括：接收来自发送节点的区块数据，包括来自发送节点的区块默克尔根和短交易标识符集；针对每个短交易标识符，在内存池中定位对应的完整交易标识符；基于完整交易标识符计算默克尔树，该默克尔树具有默克尔根；确定计算出的默克尔根与区块默克尔根不匹配；将来自默克尔树的中间层的默克尔树哈希发送到发送节点；从发送节点接收解决数据，该解决数据标识哪个默克尔树哈希是不正确的；以及重复进行默克尔树哈希的发送和解决数据的接收，直到冲突解决为止。

在一些实现方式中，每个短交易标识符可以是其对应的完整交易标识符的截断。

在一些实现方式中，解决数据可以包括针对中间层的每个默克尔树哈希的标志，其指示该默克尔树哈希是否有效。

在一些实现方式中，解决数据可以包括默克尔树的底层的一部分的完整交易标识符。

在一些实现方式中，中间层可以是默克尔树的如下层：在标识出的不匹配的默克尔哈希和默克尔树的底层之间的层。在某些情况下，该方法可以包括选择中间层。

在一些实现方式中，默克尔树哈希可以包括部分默克尔树哈希。

在一些实现方式中，接收区块数据可以包括从发送节点接收来自默克尔树的选定层的默克尔树哈希的先占集合。

在另一方面，本申请提供了一种解决区块链网络中的短交易标识符冲突的计算机实现的方法。该方法可以包括：接收来自发送节点的短交易标识符集；针对每个短交易标识符，在内存池中定位对应的完整交易标识符，其中，该定位包括：对于至少一个短交易标识符，标识冲突；向发送节点发送消息，该消息请求关于至少一个短交易标识符的冲突的解决方案；以及接收来自发送节点的冲突解决数据，使得能够标识针对至少一个短交易标识符的对应的有效完整交易标识符。

在一些实现方式中，该发送可以包括发送包含至少一个短交易标识符的解决方案请求消息。

在一些实现方式中，该冲突解决数据可以包括对应的有效完整交易标识符。

在另一方面，可以提供一种用于解决区块链网络中的短交易标识符冲突的计算装置。该计算装置可以包括存储器、一个或多个处理器和计算机可执行指令，该计算机可执行指令在被执行时，使处理器执行本文中描述的方法中的一种或多种。

在又一方面，可以提供一种计算机可读介质，其存储用于解决区块链网络中的短交易标识符冲突的处理器可执行指令，该处理器可执行指令包括在由一个或多个处理器执行时，使处理器执行本文描述的至少一种方法的指令。

通过结合附图审阅以下详细描述，本公开的其他示例实施例对于本领域普通技术人员而言将是显而易见的。

在本申请中，术语“和/或”旨在涵盖列出的元素的所有可能组合和子组合，包括单独列出的元素中的任何一个、任何子组合或所有元素，并且不必排除附加元素。

在本申请中，短语“…或…中的至少一个”旨在涵盖列出的元素中的任何一个或多个，包括单独列出的元素中的任何一个、任何子组合或所有元素，而不必排除任何附加元素，也不必需要所有元素。

本申请将涉及哈希处理或哈希函数，其旨在包括多个加密哈希函数中的任何一个，这些加密哈希函数在应用于任意的数据或“消息”集合时，确定性地产生唯一的固定长度的字母数字字符串。哈希函数的结果可以称为哈希值、指纹、哈希结果或等价物。示例包括但不限于SHA-2、SHA-3和BLAKE2。以下任何提及“矿工对区块或候选区块进行哈希处理”将被理解为意味着将加密哈希函数应用于候选区块的区块头部分。

在本文档中，术语“区块链”被理解为包括所有形式的电子的基于计算机的分布式账本(ledger)。这些包括基于共识的区块链和交易链技术、许可的和未被许可的账本、共享账本及其变型。尽管已经提出并开发了其他区块链实现方式，但是区块链技术最广为人知的应用是比特币账本。尽管为了方便和说明的目的在本文中可能提及比特币，如通过比特币SV协议进行示例说明，但是应当注意，本发明不限于与比特币区块链一起使用，并且替代的区块链实现和协议落入本发明的范围内。

区块链是一种点对点的电子分类帐，其实现为基于计算机的去中心化的分布式系统，该系统由区块组成，而区块又由交易组成。每个交易是一种数据结构，该数据结构对区块链系统中参与者之间的数字资产的控制权的转移进行编码，并包括至少一个输入和至少一个输出。每个区块都包含前一个区块的哈希值，因此区块被链接在一起来创建所有交易的永久、不可更改的记录，这些交易自其开始就已经被写入区块链。交易包含嵌入到其输入和输出中的称为脚本的小程序，这些小程序指定如何以及由谁可以访问交易的输出。在比特币平台上，这些脚本是使用基于堆栈的脚本语言编写的。

区块链是在节点网络上实现的。每个节点都是具有网络连接性和执行软件的计算装置，该软件执行适用的区块链协议。节点验证交易并将它们传播到网络中的其他节点。专门的网络节点(称为“挖矿节点”或“矿工”)将未确认的交易(即，待定交易)的集合收集到区块中并尝试“挖掘”该区块。在这些示例中，挖掘是指在网络中的任何其他矿工成功解答其相应的区块的工作量证明之前解答工作量证明(POW)。在比特币示例中，POW涉及对包含随机数的区块头进行哈希处理，直到结果小于通过难度参数设置的阈值。反复地递增随机数并重复哈希处理，直到结果小于阈值为止或直到矿工接收到另一个矿工已经成功的通知为止。挖掘过程的变化对于本领域普通技术人员来说是熟悉的。

典型的区块包含两个数据结构：区块头和交易。图1以图表方式示出了来自比特币协议的示例区块结构100。区块结构100包括区块头102和有效载荷(payload)104。该示例中的区块头102包括针对版本号106、前一个区块哈希值108、默克尔根110、时间戳112、目标难度参数114和随机数116的字段。前一个区块哈希值108将该区块链接到链中的前一个区块，从而产生“区块链”结构，其通过加密哈希将相继的区块链接在一起。默克尔根110指的是基于区块中包含的所有交易的默克尔树结构。随机数116是任意值，挖矿节点可以重复递增或递减该任意值来改变区块头102的内容，以便在挖掘时产生不同的哈希结果。

有效载荷104包括交易计数值118和交易列表120。在一些实现方式中，交易列表120可以是交易ID号的列表。

当挖矿节点成功找到产生小于阈值的哈希结果的区块头时，它继续使用包括成功的哈希结果值的更新后的库存消息(inventory message)通知其他节点。然后其他节点请求新区块的副本并独立地验证其有效性。

区块传播

区块链生态系统日益成熟以通过交易量的大量增加以及由此区块大小的大量增加来提供增加的可用性。随着区块变得更大(在某些情况下超过128MB)，将成功挖掘到的新区块传播到整个网络的其他节点花费更多的时间。传播的延迟是有代价的。首先，不知道已成功挖掘到的区块已被创建的矿工将继续尝试挖掘他们自己的候选区块，如果新区块被证明是有效的，这会白费力气。其次，传播和验证的延迟可能导致(临时)分叉和孤块的可能性增加。

将理解的是，在许多区块链协议中，矿工不发送区块的完整副本，而是在库存消息中发送哈希结果。接收挖矿节点确定他们尚未看到这个所谓的新区块并向成功的矿工发送GETBLOCK或GETDATA消息。成功的矿工不会发送区块的完整副本，而是发送区块头、来自有效载荷的交易计数字段以及区块中包括的有序的交易列表。有序列表可以包括交易的完整交易ID号(TXID)的集合。在一些实施例中，TXID可以是固定长度的交易哈希。例如，TXID可以是通过使用SHA-256对交易进行哈希处理获得的256位(32字节)编号。接收节点可以通过其TXID从内存池中检索标识出的交易来重组完整区块。

然而，随着现代的区块大小增长到128MB并且超过要传输的数据的大小，如果交易的计数很大，则其可能仍然是相当大数量的。例如，包含50万笔交易的区块将具有16MB的TXID有序列表。

因此，一方面，本申请描述了用于区块链网络的方法和系统，其中挖矿节点在对其候选区块进行哈希处理的同时向其他矿工提供关于其相应的候选区块的信息。以这种方式，每个矿工利用发现成功的区块之间的时间延迟向其他矿工提供有关候选区块结构和内容的详细信息，在比特币的示例中该时间延迟约为10分钟。通过提前提供该信息，当找到成功的区块时，成功的矿工只需要发送来自区块头的信息，在某些情况下，还需要发送创币(coinbase)交易，以确保所有其他节点可以组装和验证完整的新区块。该数据可能只有几百字节。这提高了成功的新区块传播通过全网络的速度。

将理解的是，未确认的交易通过包括在有效区块中而在被确认之前通过节点网络传播和验证。在该未确认的状态期间，未确认的交易保存在存储器中。该存储器可称为“内存池”。在某些实现方式中，每个矿工可以维护自己的内存池副本，可以从中选择交易集来组装候选区块。在一些替代架构中，内存池可以实现为跨多个节点的分布式内存池。在某些架构中，区块链网络可采用专门的节点来管理内存池并为挖矿节点提供交易，以将交易包括在候选区块中。本申请考虑了将描述的方法和装置与区块链网络架构中的任何此类变化一起使用。为了解释的简单起见，这里假设每个挖矿节点都维护自己的未确认的交易的内存池。

挖矿节点将内存池用作用于构建候选区块的新交易的来源。挖矿节点还可以在验证来自另一个矿工的新区块时使用内存池，因为每个区块都包含有序的交易列表。有序列表可以通过唯一的交易标识符(如，TXID)来标识交易。因此，接收挖矿节点从有序列表检索交易，根据区块级别标准验证区块，并根据交易级别标准验证交易。通过这种方式，矿工防止双重支付(double-spend)攻击和其他攻击。

为了说明本申请的一个方面，现在参考图2，其以流程图的形式示出了区块链挖掘的一个示例方法200。该方法200由挖矿节点实现。挖矿节点可以在计算装置上实现，该计算装置可以包括一个或多个处理单元。如本领域技术人员将理解的，处理单元可以包括具有专用硬件的专用处理单元，该专用硬件被设计为以显著的速度和效率执行与区块链挖掘相关联的计算操作。然而，处理单元也可以或替代地包括通用计算装置。该计算装置包括处理器可执行软件，该软件包括在被执行时使一个或多个处理单元执行描述的操作的处理器可读指令。计算装置包括存储器和与关联的硬件和软件的网络连接，该网络连接用于根据适用的网络协议获得网络连接并发送和接收消息。

该方法200包括：在操作202中，从未确认的交易的内存池选择交易集以构建候选区块。该选择可以基于交易的年代、为挖掘交易而应付的费用或任何其他因素。这些交易形成有序的交易列表。挖矿节点还基于有序的交易列表确定默克尔根并形成区块头，包括为区块头中的随机数设置初始值。

在操作204中，作为搜索满足难度设置条件的POW的一部分，挖矿节点开始对区块头进行重复哈希处理并开始对随机数进行递增。在针对其候选区块搜索POW的同时，挖矿节点将有关其有序的交易列表的信息发送到其他挖矿节点，如操作206所示。在操作204进行的同时，挖矿节点还接收来自其他挖矿节点的消息，其包括关于这些挖矿节点正在处理的候选区块中的相应的有序的交易列表的信息，如操作208所示。应当理解，虽然依次示出了操作204、206和208，但它们通常并行发生。从其他矿工接收到的有关相应的有序的交易列表的信息由挖矿节点存储在本地。挖矿节点可以将信息存储在表中或其他数据结构中。

继续搜索POW，直到挖矿节点成功地找到POW为止(如操作210所示)，或者直到从另一个挖矿节点接收到其已找到POW的通知为止(如操作212所示)。如果挖矿节点找到POW，则在操作214中，它向其他挖矿节点发送一些区块头信息以传播该区块详细信息。值得注意的是，不需要发送有效载荷。但是，可以发送创币交易。

如果挖矿节点接收到来自另一个挖矿节点的区块头信息，则在操作216中，其基于存储的该挖矿节点的有序的交易列表组装新区块。如果接收到创币，则该交易被添加到区块，挖矿节点可以构造默克尔树以确认默克尔根有效。然后在操作218中，挖矿节点验证新区块，如果无效，它可以丢弃新区块并继续搜索它自己的POW。请注意，可能存在某些有效性检查，如果失败，可以提示挖矿节点采取其他动作，例如从成功的挖矿节点请求附加数据，如后文所述。如果该区块被验证通过，则在操作220中，将其添加到区块链并传播到其他挖矿节点。然后，挖矿节点返回到操作202以构建新的候选区块并重新开始搜索。

将理解的是，描述的预分发候选区块信息以便每个矿工知道各个其他矿工的有序的交易列表的方法确保在找到POW之后仅需要传播最少量的信息。这确保了挖矿节点尽快获得验证新区块所需的信息，从而在另一个矿工已经成功的情况下减少浪费在搜索POW上的时间。挖矿节点具有充分的动机尽可能快地传播和验证新区块，以便他们可以继续搜索下一个区块。在相继区块之间的大约10分钟的时间段期间预分发有序的交易列表时，由于网络延迟而导致的潜在延迟不太受到关注。

在一个示例实现方式中，可以通过将排序信息添加到交易数据包将来自候选区块的有序的交易列表传送给另一个矿工。每个矿工都能够唯一地标识各个其他矿工。在一个示例实现方式中，可以发送如下消息，该消息唯一地标识矿工和矿工正在工作的区块级别，并按顺序列出该矿工的候选区块的TXID。

在另一个示例实现方式中，消息传递协议可以提供将交易附加到矿工的有序列表、从有序列表移除或删除交易、用另一个交易替换交易或对交易进行重新排序。在正常过程中，矿工很可能只使用指定有序的交易列表的“添加”消息。但是，存在矿工可能希望移除或替换交易的一些情况。例如，后续接收到的信息可能指示与交易之一有关的潜在双重支付或与其有效性有关的一些其他潜在问题。作为另一个示例，矿工可能循环遍历随机数的所有增量，并且可能希望重新排序或以其他方式调整交易以改变默克尔根，从而改变区块头以继续挖掘区块。消息结构的精确格式可能因实现方式而异。

可以通过缩短TXID字符串来实现区块传播消息的进一步压缩。在一些示例中，TXID是32字节的字符串。然而，在某些情况下，可以使用压缩的TXID，其依赖于仅发送TXID的一部分。在一个示例中，仅发送前八个字节。

尽管不能保证TXID的前8个字节唯一地标识交易，但是两个TXID冲突的可能性，无论是在单个消息中还是在一般情况下都是很小的。鉴于SHA256输出的是伪随机256位字符串，两个随机TXID冲突的确切可能性，即，任意两个TXID具有相同的前4个字节的可能性为：

其中，TXID

P(N TxIDs中＞0个冲突)＝1-P(TXID

作为示例，如果区块包含一百万个交易，使得消息包含一百万个压缩的TXID(N＝1,000,000)，那么冲突的可能性是：

P(1,000,000TxIDs中＞0个冲突)＝0.0000000271

该概率非常小，即使发生冲突，消息接收方也可以简单地请求未压缩形式的同一消息。或者，发送挖矿节点可以在发送之前首先进行检查以确认压缩的TXID的有序集合不包含任何冲突，如果检测到任何冲突，则发送具有未压缩的TXID的消息。消息中的标志或其他信号可以指示有效载荷中的TXID是压缩格式还是未压缩格式。

根据本文描述的过程，区块链网络中涉及的每个矿工可以接收来自各个其他矿工的消息，该消息指定包含该其他矿工的候选区块的有序的交易列表。为了跟踪该信息，每个矿工可以存储与相应的矿工身份相关联的有序列表。矿工身份可以由IP地址或某个其他的唯一标识符确定。在一个示例实现方式中，每个矿工维护表或类似的数据结构，其中每一行与内存池中的交易之一相关联，而每一列与网络中的矿工相关联。然后，可以将顺序信息存储在表的单元格中，为每个矿工指示矿工在其候选区块中排列交易的顺序。将理解的是，并非所有交易都具有顺序值，因为并非所有交易都包括在每个候选区块中。下表示出了矿工排序数据表的一个简化示例：

在这个简化的示例表中，有矿工ID为A、B、C和D的四个矿工。每个矿工都接收到并验证了交易TX

当矿工(例如，矿工A)接收来自例如矿工C的、指示已经找到区块的区块头消息时，矿工A基于TXID和为矿工C指定的顺序构建默克尔树。矿工A对该区块头进行哈希处理以验证哈希值。如果区块被验证通过，则矿工A以指定的顺序构造具有交易数据的完整区块，将其添加到区块链，并构建新的候选区块以继续挖掘。

在一些示例实现方式中，成功的矿工发送的区块头不包含所有字段。例如，成功的矿工发送的区块头可能只包含随机数和时间戳以及矿工C在对完整区块头进行哈希处理时获得的哈希值。接收矿工可以添加缺失的字段，例如版本、prev_block哈希、矿工已经计算出的默克尔根和难度设置。然后，可以通过对重建的区块头进行哈希处理并将其与接收到的哈希值进行比较来验证重建的区块头。

在一些示例实现方式中，一旦构建了候选区块，就自动发送来自矿工的、指示他们相应的候选区块的有序的交易列表的消息。在一些其他示例实现方式中，响应于来自另一个矿工的请求而提供有序列表信息。

在一些实现方式中，可以定义模板标识符TmID。模板标识符特定于矿工和区块级别，以便有效地指代特定的候选区块，即，特定的交易有序列表。来自矿工的与其有序的交易列表相关的任何消息都可以包括模板标识符，以确保接收矿工将改变与正确的特定有序交易列表相关联。在一个实现方式中，模板标识符可以是区块头中的矿工标识符(minerID)和前一个区块(prev_block)字段的哈希，即，前一个区块的哈希：

TmID＝H(prev block||miner ID)

这将模板标识符与区块级别和特定矿工联系起来。

与有序的交易列表相关的每个消息可以包括模板标识符，并且还可以包括序列号。序列号可以是无符号整数值，用于指示来自一个矿工的消息相对于彼此的顺序。排序有助于消息接收方在某些消息未接收到或被无序接收的情况下唯一地确定针对特定矿工的TXID定序。

如上所述，矿工ID可以是挖矿节点的IP地址或挖矿节点的某个其他唯一标识符。在一些实施例中，当矿工连接到网络时，可能发生初始认证操作，这导致将唯一的矿工ID与该挖矿节点相关联。认证操作可以包括握手操作，其中每个矿工提供公钥和数字签名。认证与数字签名的验证有关。在某些情况下，矿工ID可以基于公钥、数字签名或其某个组合。

在某些情况下，认证阶段的握手操作可能包括在矿工之间建立共享密钥。存在许多用于建立共享密钥的技术。后续的消息传递(例如，与有序的交易列表相关的消息传递)可以被加密，以用于机密性并减少中间人对挖掘过程的攻击的可能性。

现在参考图3A-3I，图3A-3I示意性地示出了根据本申请的实现方式的两个矿工的示例操作状态及其之间的消息传递流。

在图3A中，将看到第一矿工302(即，矿工A)和第二矿工304(即，矿工B)是区块链网络的一部分，并且存在现有的区块链306。在该示例中，第一矿工302和第二矿工304两者都具有区块链306的本地存储副本。区块链306具有特定的“高度”或区块级别。

如图3B所示，矿工302、304均从它们相应的内存池中选择交易集来构建候选区块。具体地，第一矿工302构建包含第一有序交易集的第一候选区块308，第二矿工304构建包含第二有序交易集的第二候选区块310。第一有序集和第二有序集可能包含或可能不包含相同的交易，并且可能使或可能不使交易具有相同或部分相同的顺序，这是因为矿工302、304可以自由地从内存池中选择他们希望的任何交易并按照他们希望的任何顺序对交易分组。

如图3C所示，矿工302、304开始挖掘相应的候选区块308、310，以尝试找到如下随机数，该随机数将导致区块头的哈希小于通过难度设置的阈值。

在搜索成功的工作量证明期间，矿工302、304交换关于其相应的候选区块308、310中的有序交易集的信息。如图3D所示，第一矿工302可以将“添加”消息312发送到第二矿工304，提供来自第一候选区块308的第一有序交易列表。根据该信息，第二矿工304可以构建第一候选区块308的模板314。在一些示例实现方式中，模板314可能是TXID形式的第一有序交易列表。在一些示例实现方式中，模板314可以是表，上面提供了其示例。在其他示例实现方式中，模板314可以是完整候选区块的副本，不包括某些不可用的头字段，但包括完整的交易数据。

以类似的方式，第二矿工304可以将包含来自第二候选区块310的第二有序交易列表的“添加”消息316发送至第一矿工302，如图3E所示。根据该数据，第一矿工302构建第二候选区块310的模板318。现在每个矿工具有他们各自继续挖掘的他们自己的候选区块，以及另一个矿工正在处理的候选区块的模板。

图3F示出了第一矿工302已成功找到满足工作量证明要求的区块头哈希。因此，在其区块头中具有最近测试的随机数的第一候选区块308产生有效区块。然后，图3G和图3H示出了第一矿工302将新区块322添加到区块链306并发送包含创币交易320的消息和包含区块头信息324的消息。区块头信息324至少包括随机数和时间戳。区块头信息可能会还包括或可能不会包括其他区块头字段，例如，默克尔_根(merkle_root)字段。在某些情况下，这可以作为区块头信息324的一部分发送，尽管它可以由第二矿工304计算，以使第二矿工304能够双重检查其默克尔根计算。在某些情况下，第一矿工302向第二矿工304发送新区块322的完整区块头。第一矿工302也可以向第二矿工304发送从对区块头进行哈希处理获得的哈希值，以便第二矿工304可以不仅验证哈希小于难度阈值，而且验证它与第一矿工302声称已经找到的哈希匹配。哈希值可以在创币交易消息320、区块头信息消息324或单独的消息中发送。

一旦第二矿工304具有创币交易，它就可以完成第一候选区块的模板314的交易部分，因此可以计算默克尔根。根据该计算，它可以验证merkle_root字段是否准确，该字段是否包括在区块头信息消息324中。如果没有，则它可以完成merkle_root字段和任何其他缺失的字段，例如版本、prev_block值和位字段，以便针对新区块322组装区块头326。区块头326的其他字段(如随机数和时间戳)由区块头信息消息324提供。然后，第二矿工304可以通过对组装后的区块头326进行哈希处理来验证新区块。

假设第二矿工304处组装后的区块被验证通过，则第二矿工304将该新区块322添加到其区块链306的副本，如图3I所示。

虽然上述序列示出了在区块头信息消息324之前发送创币交易消息320，但是将理解的是，在一些实现方式中，可以首先发送区块头信息消息324，或者两个消息可以组合成单个消息。可以在不改变描述的系统和方法的整体功能操作的情况下对特定实例的操作顺序或实现细节进行其他变化。

区块链网络领域的技术人员可以理解的是，在某些情况下，可以比预期更早地挖掘区块。例如，在比特币中，难度设置提供大约每十分钟发现有效区块，但该定时不确定。有可能更早地找到有效区块。此外，传播交易或交易排序信息的一些消息在通过网络传播时可能遇到网络延迟。

因此，尽管不太可能，但以下这样的可能性仍然存在：矿工找到有效区块并将区块头信息发送到其他矿工，但这些矿工中的至少一个不具有该区块中包括的所有交易或具有成功的矿工的不完整或不正确的有序的交易列表。当该矿工尝试验证新区块头的默克尔根字段时，将发现不匹配，因此该区块被视为无效。一个选择是矿工认为该区块无效并丢弃它。然而，在另一个实施例中，矿工可以向成功的矿工发送针对默克尔叶集(即，TXID的有序列表)的请求消息。在接收到发送的叶子后，矿工于是可以确定默克尔根计算中的错误发生在哪里。如果原因是不正确或不完整的交易排序，则矿工可以更新排序并验证新区块。如果原因是交易缺失，则矿工可以请求新交易并继续验证过程。请注意，在一些实施例中，如果接收另一个矿工的候选区块的有序的交易列表的矿工发现其内存池中没有TXID之一，则可以在成功发现区块之前检测到缺失的交易。在这种情况下，接收矿工可以请求该交易的副本并更新其内存池。

在一些实现方式中，一个或多个矿工可能希望保持对其交易选择和排序一定的机密性。在这样的实现方式中，矿工在挖掘阶段期间分发有序的交易列表时有可能对其进行加密。如果找到有效区块，则矿工将解密密钥与区块头信息和/或创币交易一起分发，从而允许接收矿工解密有序的交易列表并验证新区块。

下表描述了针对用于在矿工之间传播有序交易列表的消息传递的一个说明性实现方式的一个示例消息集：

接收矿工修改与消息中的模板标识符对应的候选区块模板。对于特定模板标识符，可以对根据序列号无序接收到的消息排队，直到接收到干预消息为止。

很可能，接收矿工在其内存池中具有对应于TXID的适用交易，但如果交易缺失，则它可以请求任何缺失交易的副本。

应当理解，上述说明性消息传递协议是一个示例实现方式。

短交易标识符冲突和协调

如上所述，区块传播是以下这种情况：通过使用压缩的交易标识符(即，短TXID)来节省带宽并提高传播速度可能是有利的。短TXID可以是截断的TXID，如上所述，其中，短TXID是完整TXID的一部分。上面给出的示例提出使用256位完整TXID的前4个字节(32位)。在其他实现方式中可以使用其他长度的短TXID。

更一般地，短TXID可以是完整TXID到较短长度标识符的任何映射。映射函数确定性地将完整TXID映射到其对应的短TXID；然而，两个不同的完整TXID映射到同一个短TXID的概率并非为零。在本文使用的示例中，提出的映射是使用完整TXID的一部分(例如，截断的TXID)，部分原因是在内存池中标识与短TXID匹配的完整(一个或多个)TXID非常简单。

使用短TXID在区块传播的情况下可能是有用的，无论是对于找到POW之前的候选区块还是对于找到POW之后的挖掘到的区块。在发送大量交易标识符的其他背景下，短TXID也可能是有用的。

应当理解，短TXID的使用节省了带宽并加速了区块传播，但是带来了冲突的风险。也就是说，存在一个短TXID映射到多于一个的完整TXID的某非零概率。短TXID中使用的位越少，发生冲突的概率就越高。单个区块中冲突的几率可以表示为：

在上面的表达式中，P

将理解的是，即使在32位短TXID和1GB区块的情况下，也可以预计发生相当少的冲突。

存在可能发生冲突的三种潜在场景。首先，发送节点可以标识冲突。例如，在计算短TXID时，发送节点可以标识短TXID中的两个匹配。作为另一个示例，发送节点可以在其内存池中搜索每个短TXID，以查看它是否与内存池中的多于一个的完整TXID匹配。

其次，接收节点可以标识冲突。例如，由于与交易或区块数据相关的传播时间延迟，接收节点在其内存池中可能具有发送节点的内存池中不具有的交易。在这种情况下，当尝试在其内存池中定位对应的完整TXID时，接收节点将确定短TXID与多于一个的完整TXID匹配。

第三，冲突可能是由于如下情况导致的：发送节点的内存池具有映射到短TXID的完整TXID，其中该完整TXID不在接收节点的内存池中(通常是接收节点请求缺失的交易的情况)，但是接收节点的内存池具有恰好映射到同一短TXID的不同的完整TXID。在将短TXID映射到完整TXID时，任一节点不会标识该第三种情况。相反，在发送节点尝试验证区块数据并发现为交易的区块计算的默克尔根与发送节点提供的默克尔根不匹配时，发送节点将发现这种情况。但是，无法根据该信息确定哪个交易由于冲突而被不正确地映射。

本申请提供了解决所有三种冲突情形的方法。

参考图4，其以流程图的形式示出了发送节点处解决短交易标识符冲突的一种示例方法400。在一些示例实现方式中，方法400中描述的操作由一个或多个处理器执行为该一个或多个处理器执行的处理器可执行指令。指令可以体现在软件应用或模块中，在某些情况下存储在一个或多个处理器可访问的存储器中。

方法400可以在区块传播的背景下实现。该区块可以包括区块头和交易标识符的有序列表，即，TXID。

方法400包括：在操作402中，使用适用的映射函数将TXID转换为短TXID。在该示例中，映射函数可以包括截断完整TXID。在一些实现方式中，完整TXID可以是256位，并且可以通过利用合适的哈希函数(例如，SHA-256)对交易内容进行哈希处理而产生。可以通过仅保留TXID的前N位来截断完整TXID，其中，N是完整256位的合适比例，以在不会产生过多的冲突风险的情况下节省带宽。在某些情况下，N是32位。

在操作404中，发送节点确定短TXID是否导致冲突。发送节点可以通过针对每个短TXID搜索内存池的完整TXID以确保只有一个完整TXID具有与短TXID匹配的前32位来实现该操作。如果没有产生冲突，则发送节点发送有序列表中包含该短TXID的消息。该消息可以是区块传播消息。

如果在操作404中检测到冲突，则在操作408中，发送节点用信号通知冲突并发送具有冲突解决数据的消息。在一个示例中，具有冲突解决数据的消息可以是区块传播消息的补充。在另一个示例中，具有冲突解决数据的消息可以是对区块传播消息的修改。冲突解决数据可以包括标识有序列表内导致冲突的交易并提供该交易的完整TXID信息。完整TXID信息可以包括在消息的合适字段中插入完整TXID。完整TXID信息可以包括将TXID的剩余部分插入到合适的字段中，使得当与短TXID组合时，产生完整TXID。完整TXID信息可以包括发送TXID的足够短的附加部分以解决冲突而不发送整个TXID。可以在区块传播消息中用信号通知发生冲突的事实。例如，该消息可以包括用于以信号通知冲突已经发生的专用标志，以及如果设置了该标志，则还包括导致冲突的短TXID的索引和包含冲突解决数据的字段。

现在参考图5，其以流程图的形式示出了接收节点处用于解决短交易标识符冲突的示例方法500。在一些示例实现方式中，方法500中描述的操作由一个或多个处理器执行为该一个或多个处理器执行的处理器可执行指令。指令可以体现在软件应用或模块中，在某些情况下存储在一个或多个处理器可访问的存储器中。

方法500包括：在操作502中，接收包含短TXID的消息。在一些实施例中，该消息可以是区块传播消息。在操作504中，接收节点基于映射函数将短TXID转换为完整TXID。在该示例中，其中短TXID是完整TXID的截断，接收节点搜索其内存池以找到前四个字节与短TXID匹配的完整TXID。

在操作506和508中，接收节点确定短TXID中的任何一个是否导致冲突，即，短TXID之一是否映射到内存池中多于一个的完整TXID。如果是，则接收节点向发送节点请求冲突解决数据。特别地，接收节点可以向发送节点发送标识导致冲突的短TXID的冲突消息。作为响应，发送节点可以在消息中提供冲突解决数据，例如，完整TXID、完整TXID的剩余部分或完整TXID的足够解决冲突的部分。

现在将参考图6，其示出了用于解决根据第三场景的短交易标识符冲突的示例方法600。在该场景下，发送节点或接收节点都检测不到冲突，因为发生冲突的两个完整TXID位于相应的不同的内存池中。可以根据接收节点计算出的默克尔树根与发送节点在区块传播消息中提供的默克尔树根不匹配的事实来推断发生了冲突。为了标识冲突，接收节点和发送节点可以利用默克尔树结构来查明冲突涉及的交易。

在一些示例实现方式中，方法600中描述的操作由接收节点处的一个或多个处理器执行为该一个或多个处理器执行的处理器可执行指令。指令可以体现在软件应用或模块中，在某些情况下存储在一个或多个处理器可访问的存储器中。

方法600包括：在操作602中，接收包含短TXID的消息。在一些实施例中，该消息可以是区块传播消息。操作602还包括接收区块头信息，例如，针对有序的交易列表的默克尔树根。在操作604中，接收节点基于映射函数将短TXID转换为完整TXID。在该示例中，其中短TXID是完整TXID的截断，接收节点搜索其内存池以找到前四个字节与短TXID匹配的的完整TXID。

在操作606和608中，接收节点确定短TXID中的任何一个是否导致冲突，即，短TXID之一是否映射到内存池中多于一个的完整TXID。如果是，则接收节点向发送节点请求冲突解决数据。特别地，接收节点可以向发送节点发送标识导致冲突的短TXID的冲突消息。作为响应，发送节点可以在消息中提供冲突解决数据，例如，完整TXID、完整TXID的剩余部分或完整TXID的足够解决冲突的部分。

在没有标识出冲突或者已经解决了任何标识出的冲突之后，在操作610中，接收节点基于操作604中标识出的完整TXID来构建对应于有序的交易列表的默克尔树。在操作612中，接收节点评估计算出的默克尔树根是否与发送节点提供的默克尔树根匹配。如果是，那么接收节点已经验证通过了区块的内容，并且可以继续验证区块和/或将区块传播到下一个节点，或者在候选区块传播的情况下，它可以简单地将候选区块存储在如上所述的存储器中。

如果计算出的默克尔根与发送节点提供的默克尔根不匹配，则该不匹配可能由冲突引起。为了解决冲突，发送节点和接收节点可以通过交换中间层默克尔树哈希数据来缩小可能的交易范围。为了解释，现在还将参考图7，其示出了默克尔树700的简单示例。

默克尔树是通过对子节点的内容进行递归连接和哈希处理直到构建至根节点而构造的。两个子节点的连接和哈希都提供了上层中父节点的内容。例如，在默克尔树700的情况下，表示为T

将理解的是，对叶子节点的任何改变，例如，不正确的TXID，将影响从默克尔树700向上到根节点702的路径中的所有相关节点。现在还参考图8，其示出了具有与默克尔树700(图7)相同结构的默克尔树800。默克尔树800具有根节点802和从0到4标记的五个层。位于层4的叶子节点包括一个错误的TXID 804，如“x”符号所示。标有“o”的节点具有正确的TXID和/或正确的默克尔树哈希。将注意到的是，错误的TXID 804导致向上到达默克尔树根节点802(其也是不正确的)的路径中的由‘x’符号标记的不正确的默克尔树哈希。哈希在如下意义上是“不正确的”：与将由于具有正确的TXID而不是错误的TXID 804而产生的预期的哈希不匹配。

现在返回图6，如果计算出的默克尔根与发送节点提供的默克尔根不匹配，则在操作614中，接收节点发送来自计算出的默克尔树的中间层的默克尔树哈希。可以使该消息构造成指示默克尔树层并包含默克尔树哈希的有序列表。例如，仍然参考图8，接收节点可以发送数据结构信令层2并且提供来自层2的节点的四个默克尔树哈希。

发送节点接收提供的中间层默克尔树哈希并将它们与来自其自己的默克尔树计算的默克尔树哈希进行比较。然后，发送节点将数据传输到接收节点，以标识哪些默克尔树哈希是不正确的。例如，发送节点可以发送指向不正确的哈希的索引值。在该示例中，在四个哈希的情况下，发送节点可以传输指示哪个哈希不正确的两比特值。在某些情况下，发送节点可以发送指示每个哈希是正确还是不正确的二进制信号。在该示例中，例如，这样的信号可以是0,1,0,0。如果存在多于一个不正确的哈希，这可以允许发送节点发信号通知。

因此，在操作616中，接收节点接收来自发送节点的指示默克尔树哈希中的哪一个不正确的消息。然后，接收节点可以将其搜索范围缩小到不正确的默克尔树哈希以下的子树。因此，如果冲突尚未解决，如操作618所指示的，则接收节点可以在操作614中向发送节点发送另外的消息，该另外的消息具有来自子树内进一步向下的默克尔树哈希。例如，接收节点可以发信号通知其正在发送来自子树内的层4的四个默克尔树哈希(在该情况下，为TXID)。在一些实现方式中，接收节点发信号通知是哪个子树，例如通过在其消息中包括标识子树根位于层2，索引1的数据。在一些其他实现方式中，发送节点可以推断后续消息与位于层2，索引1的子树有关，因为这是发送节点标识为不正确的子树。

在该示例中，在将四个TXID从子树发送到发送节点之后，接收节点然后接收指示TXID中的哪个是不正确的并提供冲突解决数据的消息。例如，冲突解决数据可以包括正确的完整TXID。替代地，发送节点可以发送完整交易。

将理解的是，以上示例是使用特别小的默克尔树的简化说明。对于更大的树，接收节点和/或发送节点可以权衡传输的哈希数量与往返通信的数量。考虑到在包含大约25亿笔交易的TB区块的情况下，默克尔树将有32层。每层是其父层的两倍大。层的大小由2

将理解的是，可以如下来执行上述操作：使发送节点发送来自中间层的正确的默克尔树哈希，并使接收节点通过指示其中哪些与计算出的默克尔树哈希不匹配进行回复。

在一个变型中，可以使用概率方法来进一步减小数据传输的量。节点代替针对每个默克尔树哈希发送整个32字节的哈希值，可以只发送8个字节，即，哈希值的25％。在这种情况下，误报(false positive)的概率是18,446,744,073,709,551,616分之一。这种不太可能发生的事件的结果是搜索不会找到冲突的交易。在这种情况下，可以使用16个字节或使用完整32个字节重新启动搜索协议。误报的可能性足够低使得在某些情况下，可以仅使用4个字节的默克尔树哈希。

在又一变型中，发送节点可以抢先发送默克尔树的某个较高层部分。例如，在发送区块传播消息时，发送节点可以包括中间层(例如，层10)的部分默克尔树哈希(例如，4个字节)。这种传输的成本是4kB。那么冲突的单次往返解析(在1GB区块的情况下)将只需要12层深的子树，成本为16kB。

在预期的攻击场景的情况下，抢先发送默克尔树中间层哈希数据可能特别有用。此外，如果接收节点具有关于中间层的预先信息，则它可以根据其标识的冲突数量改变它的请求方法。

接收节点和发送节点之间发送的消息可以具有规定的结构。作为示例，从接收节点到发送节点的、提供不匹配的默克尔根的通知并提供中间层默克尔树哈希数据的消息可以采用以下形式：

[block_hash:byte[32],

subtree_root_layer:int,

subtree_root_index:int,

data_layer:int,

[hash0,hash1,...hashn]:byte[][32]

]

在上述示例数据结构中，消息引用block_hash作为区块的标识符，并使用subtree_root_layer提供默克尔树的层的索引。如果消息用信号发送子树和子树内的深度，则对数量subtree_root_layer和data_layer进行编码。实际数据的层不是严格必要的，因为它可以通过log2(nElements)计算；然而为了说明的目的，这里包括了实际数据的层。于是，包括n+1个默克尔树哈希。

响应消息可以是不匹配的哈希的索引的数组。如果数据层是底层，例如，默克尔树的叶子节点，那么数据层可能包括与不正确的哈希的索引匹配的TXID或原始交易数据。在一个示例中，这样的响应消息可以采用以下形式：

[

block_hash:byte[32]，

has_txs:bool,//表示树的底层的标志并且包括txs

subtree_root_layer:int,

subtree_root_index:int,

data_layer:int,

[1]:int[],[rawtx1]:byte[][]

]

可以对数据结构进行适当的修改以适应区块中超过一个这样的冲突的不太可能的可能性。

应当理解，各种上述示例方法的上述操作中的一些或全部可以按照不同于所示出的顺序执行和/或可以在不改变那些方法的整体操作的情况下同时执行。

现在参考图4，其以框图形式示出了根据本申请的示例的简化挖矿节点400。该挖矿节点400包括处理器402，其可以包括一个或多个微处理器、专用集成电路(ASIC)、微控制器或类似的计算机处理装置。该挖矿节点400还可以包括存储器404和网络接口606，该存储器可以包括持久性和非持久性存储器以存储值、变量以及在某些情况下还包括处理器可执行程序指令。

挖矿节点800可以包括处理器可执行区块链应用408，其包含处理器可执行指令，这些指令在被执行时使处理器402执行本文所述的一个或多个功能或操作。

以上呈现的各种实施例仅是示例并且绝不意味着限制本申请的范围。本文描述的创新的变化对于本领域普通技术人员来说将是显而易见的，这样的变化在本申请的预期范围内。特别地，可以选择来自上述示例实施例中的一个或多个的特征来创建替代示例实施例，其包括可能未在上文明确描述的特征的子组合。此外，可以从一个或多个上述示例实施例中选择特征并将其组合以创建替代示例实施例，其包括上面可能没有明确描述的特征的组合。本领域技术人员在整体审阅本申请时将容易明白适合于这种组合和子组合的特征。本文和引述的权利要求中描述的主题旨在涵盖和包含所有合适的技术变化。