统一资源标识符

技术领域

本公开总体涉及用于存储、验证或以其他方式管理相互关联的区块链事务的技术。本公开技术具有链下和链上应用。

背景技术

区块链是指一种分布式数据结构，其中在分布式对等(P2P)网络(以下称为“区块链网络”)中的多个节点中的每个节点处维护区块链的副本，并且广泛公开该副本。区块链包括一系列数据区块，其中每个区块包括一个或多个事务(transaction)。除所谓的“coinbase事务”外，每个事务都指向序列中的先前事务，该序列可以跨越一个或多个区块，回到一个或多个coinbase事务。coinbase事务将在下文进一步讨论。提交给区块链网络的事务包括在新区块中。新区块的创建过程通常称为“挖掘”，该过程涉及多个节点中的每个节点争相执行“工作证明”，即，基于等待被包括在区块链的新区块中的一组定义的有序且核实有效的未决事务的表示解决加密难题。应当注意的是，区块链可以在一些节点处被修剪(prune)，并且区块的发布可以通过仅发布区块头来实现。

区块链中的事务可用于以下目的中的一个或多个：传送数字资产(即，一定数量的数字通证)；对虚拟化分类账或注册表中的一组条目进行排序；接收和处理时间戳条目；和/或对索引指针按时间排序。也可利用区块链实现区块链上的层级附加功能。例如，区块链协议可允许在事务中存储附加的用户数据或数据索引。能够存储在单个事务中的最大数据容量没有预先指定的限制，因此可以并入越来越复杂的数据。例如，这可用于在区块链中存储电子文档、音频或视频数据。

区块链网络的节点(通常称为“矿工”)执行分布式事务注册和验证过程，这将后续更详细地描述。总之，在该过程中，节点核实事务并将这些事务插入到区块模板中，这些事务尝试为该区块模板标识有效的工作证明解。一旦找到有效的解，新区块便会被传播到网络的其它节点，从而使得每个节点能够在区块链上记录新区块。为了将事务记录在区块链中，用户(例如，区块链客户端应用程序)将该事务发送到网络中的节点中的一个节点进行传播。接收该事务的节点可以争相寻找将核实有效的事务并入新区块的工作证明解。每个节点被配置为执行相同的节点协议，该协议将包括用于确认事务有效的一个或多个条件。无效事务将不会传播或并入到区块中。假定事务已经核实有效，从而在区块链上被接受，则该事务(包括任何用户数据)将因此在区块链网络中的每个节点上作为不可改变的公共记录进行注册和索引。

成功解决工作证明难题可创建最新区块的节点通常被奖励一个称为“coinbase事务”的新事务，该事务分发数字资产数额，即通证数量。无效事务的检测和拒绝是通过竞争节点的行动来执行的，这些竞争节点充当网络的代理并且通过激励报告和阻止不正当行为。信息的广泛发布使得用户可以连续地审计节点的性能。仅发布区块头使得参与者可以确保区块链具有持续完整性。

在“基于输出的”模型(有时称为基于UTXO的模型)中，给定事务的数据结构包括一个或多个输入和一个或多个输出。任何可花费输出包括指定数字资产数额的元素，该元素可从进行中的事务序列导出。可花费输出有时称为UTXO(“未花费事务输出”)。输出还可以包括锁定脚本，该锁定脚本指定输出的未来赎回条件。锁定脚本是限定核实和传送数字通证或资产所必需的条件的谓词。事务(除coinbase事务之外)的每个输入包括指向先前事务中的此类输出的指针(即引用)，并且还可以包括解锁脚本，用于解锁指向输出的锁定脚本。因此，考虑一对事务，将其称为第一事务和第二事务(或“目标”事务)。第一事务包括指定数字资产数额的至少一个输出，并且包括定义解锁该输出的一个或多个条件的锁定脚本。第二目标事务包括至少一个输入和解锁脚本，该至少一个输入包括指向第一事务的输出的指针；该解锁脚本用于解锁第一事务的输出。

在此类模型中，当第二目标事务被发送到区块链网络以在区块链中传播和记录时，在每个节点处应用的有效性条件之一将是解锁脚本满足在第一事务的锁定脚本中定义的一个或多个条件中的所有条件。另一条件将是第一事务的输出尚未被另一早期有效事务赎回。根据这些条件中的任何一个条件发现目标事务无效的任何节点都不会传播该事务(作为有效事务，但可能注册无效事务)，也不将该事务包括在要记录在区块链中的新区块中。

另一种事务模型是基于账户的模型。在这种情况下，每个事务均不通过参考过去事务序列中先前事务的UTXO来定义转移的数额，而是通过参考绝对账户余额进行定义。所有账户的当前状态由节点单独存储到区块链中，并不断更新。

发明内容

根据本发明的第一方面，提供了一种用于验证所标识的事务存储在区块链中的计算机实现的方法。获取区块链统一资源指示符(blockchain uniform resourceindicator，BURI)字符串。解析所述BURI字符串以标识其中的分隔符字符，并由此提取通过所述分隔符字符隔开的事务标识符部分以及一个或多个默克尔证明部分，所述一个或多个默克尔证明部分用于验证所述标识的事务属于标识的区块。使用所述BURI的至少一部分来获取默克尔根哈希。使用所述一个或多个默克尔证明部分来确定所述事务标识符部分相对于所述默克尔根哈希是否有效，从而使用所述BURI字符串验证所述标识的事务，而无需访问所述标识的区块的有效载荷(payload)。

由所述BURI提供的用于区块链事务的分层引用方案允许用户引用事务，然后使用包含在所述BURI中的分层信息高效地验证所述引用的事务确实已经提交到所述区块链。

例如，在万维网中，URI长期以来一直用于定义分层命名空间。本文中描述的URI用于引用区块链事务的新颖方式提供了用于验证所述引用的事务已经提交到所述区块链的高效手段。所述BURI提供计算默克尔根并验证所述计算的根与存储在所述区块链上的所述事务的所述默克尔根相同所需的信息。URI格式针对引用层级结构中任意级别的资源进行了优化。这里，该结构用于不仅唯一地引用区块链事务，而且还以有助于高效验证所述引用的事务的方式传达所述默克尔证明的所需分层元素。

附图说明

为了帮助理解本公开的实施例并示出如何实施此类实施例，现将仅通过举例的方式参考附图进行说明，其中：

图1是一种用于实现区块链的系统的示意性框图；

图2示意性地示出了可记录在区块链中的事务的一些示例；

图3A示出了客户端应用程序的示意性框图；

图3B示出了可由图3A的客户端应用程序表示的示例性用户界面的示意性模型；

图4示出了用于处理事务的一些节点软件的示意性框图；

图5示意性地示出了示例性默克尔树；

图6示意性地示出了示例性默克尔证明；

图7示意性地示出了根据本发明的一些实施例的示例性系统，其中第三方提供默克尔证明；

图8示出了根据本发明的一些实施例的示例性方法，其中在区块链统一引用标识符中提供默克尔证明；

图9是示出在引用事务中使用区块链统一引用标识符来引用数据的示意图；

图10示意性地示出了区块链统一引用标识符和存储在区块链上的区块的对应组件；

图11示出了根据本发明的一些实施例的示例性方法，其中使用区块链统一引用标识符来请求默克尔证明；

图12示意性地示出了根据本发明的一些实施例的默克尔证明实体存储的数据。

具体实施方式

区块链统一资源标识符(blockchain uniform resource identifier，BURI)可以用于促进基于相同内容的多方之间的交互。

BURI可以被设计成包含执行默克尔证明验证(即，哈希的有序列表和事务索引)所需的所有信息，这允许用户仅基于引用某些内容数据的BURI来独立地验证该数据的存在证明。

BURI的一个优点在于，它允许通过引用数据来执行与现有链上数据的任何交互，而不是复制数据本身，从而避免复制数据，这对于实现链上面向内容的应用程序(例如，社交网络)来说具有空间和成本效益。

第二个优点在于，BURI方案较为灵活，允许在不同上下文中使用不同形式的BURI，同时权衡用户独立性与链接本身的空间效率。它允许用户选择每个BURI是应该包含所有信息以执行默克尔证明验证，还是应该仅包含足够的信息以供他们从第三方检索该信息。前者允许完全独立，但是不太紧凑；另一种依赖于调用第三方来提供默克尔证明数据，但是降低了将BURI包括在链上的成本。

示例性系统概述

图1示出了一种用于实现区块链150的示例性系统100。系统100可以包括分组交换网络101，通常是诸如互联网的广域互联网。分组交换网络101包括多个区块链节点104，该多个区块链节点可以被设置成在分组交换网络101内形成对等(P2P)网络106。虽然未示出，但是区块链节点104可以被设置为近完全图。因此，每个区块链节点104高度连接到其它区块链节点104。

每个区块链节点104包括对等体的计算机设备，不同的节点104属于不同的对等体。每个区块链节点104包括处理装置，该处理装置包括一个或多个处理器，例如一个或多个中央处理单元(CPU)、加速器处理器、专用处理器和/或现场可编程门阵列(FPGA)，以及其它设备，例如专用集成电路(ASIC)。每个节点还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。存储器可包括一个或多个存储器单元，其采用一个或多个存储器介质，例如诸如硬盘等磁介质、诸如固态硬盘(SSD)、闪存或电可擦可编程只读存储器(EEPROM)等电子媒介和/或诸如光盘驱动器等光学介质。

区块链150包括一系列数据区块151，其中在分布式或区块链网络106中的多个区块链节点104中的每个节点处维护区块链150的相应副本。如上所述，维护区块链150的副本不一定意味着完全存储区块链150。相反，只要每个区块链节点150存储每个区块151的区块头(下面讨论)，区块链150就可以进行数据修剪。区块链中的每个区块151均包括一个或多个事务152，其中该上下文中的事务是指一种数据结构。数据结构的性质将取决于用作事务模型或计划的一部分的事务协议类型。给定的区块链全程使用一个特定的事务协议。在一种常见的事务协议中，每个事务152的数据结构至少包括一个输入和至少一个输出。每个输出指定将数字资产的数量表示为财产的数额，其一个示例是输出被密码锁定到的用户103(需要该用户的签名或其它解进行解锁，从而进行赎回或花费)。每个输入指向先前事务152的输出，从而链接这些事务。

每个区块151还包括区块指针155，其指向区块链中先前创建的区块151，以定义区块151的顺序。每个事务152(除coinbase事务之外)包括指向先前事务的指针，以定义事务序列的顺序(注：事务152的序列可进行分支)。区块151的区块链一直追溯到创始区块(Gb)153，该创始区块是区块链中的第一区块。区块链150中早期的一个或多个原始事务152指向创始区块153，而非先前事务。

每个区块链节点104被配置为将事务152转发到其它区块链节点104，从而使得事务152在整个网络106中传播。每个区块链节点104被配置为创建区块151，并将相同区块链150的相应副本存储在其相应的存储器中。每个区块链节点104还维护等待并入到区块151中的事务152的有序集(或“池”)154。有序池154通常称为“内存池”。在本文中，该术语并不意在限制于任何特定的区块链、协议或模型。该术语是指节点104已接受为有效的有序事务集，并且对于该有序事务集，强制节点104不接受试图花费相同输出的任何其它事务。

在给定的当前事务152j中，输入(或每个输入)包括指针，该指针引用事务序列中先前事务152i的输出，指定该输出将在当前事务152j中被赎回或“花费”。通常，先前事务可以是有序集154或任何区块151中的任何事务。尽管为了确保当前事务有效，将需要存在先前事务152i并核实其有效，但是在创建当前事务152j甚至向网络106发送当前事务152j时，不必存在先前事务152i。因此，在本文中，“先前”是指由指针链接的逻辑序列中的前任，而不一定是时间序列中的创建时间或发送时间，因此，不一定排除无序创建或发送事务152i、152j的情况(参见下面关于孤立事务的讨论)。先前事务152i同样可以称为先行事务或前任事务。

当前事务152j的输入还包括输入授权，例如先前事务152i的输出被锁定到的用户103a的签名。反过来，当前事务152j的输出可以加密锁定到新用户或实体103b。因此，当前事务152j可将先前事务152i的输入中定义的数额转移到当前事务152j的输出中定义的新用户或实体103b。在某些情况下，事务152可具有多个输出，以在多个用户或实体间分割输入数额(其中一个可以是原始用户或实体103a，以便进行变更)。在某些情况下，事务还可以具有多个输入，将一个或多个先前事务的多个输出中的数额汇总在一起，并重新分配到当前事务的一个或多个输出。

根据基于输出的事务协议，例如比特币，当诸如个体用户或组织这类的一方103希望颁布新的事务152j时(由该方采用的自动程序或人为地)，该颁布方将该新事务从其计算机终端102发送到接收者。颁布方或接收者将最终向网络106的一个或多个区块链节点104(现在通常是服务器或数据中心，但原则上也可以是其它用户终端)发送该事务。另外还不排除颁布新事务152j的一方103可以将事务直接发送到一个或多个区块链节点104，并且在一些示例中，可以不将事务发送到接收者。接收事务的区块链节点104根据在每个区块链节点104处应用的区块链节点协议来检查事务是否有效。区块链节点协议通常要求区块链节点104检查新事务152j中的加密签名是否与预期签名相匹配，这取决于事务152的有序序列中的先前事务152i。在这种基于输出的事务协议中，这可以包括检查新事务152j的输入中包括的一方103的密码签名或其它授权是否与新事务分配的先前事务152i的输出中定义的条件匹配，其中该条件通常包括至少检查新事务152j的输入中的密码签名或其它授权是否解锁新事务的输入所链接到的先前事务152i的输出。条件可以至少部分地由包括在先前事务152i的输出中的脚本来定义。或者，这可仅由区块链节点协议单独确定，或可通过其组合确定。无论采用哪种方式，如果新事务152j有效，区块链节点104会将其转发到区块链网络106中的一个或多个其它区块链节点104。这些其它区块链节点104根据相同的区块链节点协议应用相同的测试，并因此将新事务152j转发到一个或多个其它节点104等等。通过这种方式，新事务在区块链节点104的整个网络中进行传播。

在基于输出的模型中，给定输出(例如，UTXO)是否分配(例如，花费)的定义是，根据区块链节点协议，其是否通过另一个随后事务152j的输入有效赎回。事务有效的另一个条件是其试图赎回的先前事务152i的输出尚未被另一个事务赎回。同样，如果无效，则事务152j将不会在区块链150中传播(除非被标记为无效并且被传播用于提醒)或记录。这可防止重复花费，即事务处理者对同一个事务的输出分配超过一次。另一方面，基于账户的模型通过保持账户余额防止重复花费。因为同样存在定义的事务顺序，账户余额在任何时候均具有单一定义的状态。

除了核实事务有效之外，区块链节点104还争相成为在通常称为挖矿的过程中创建事务区块的第一个节点，而该过程由“工作证明”支持。在区块链节点104处，新事务被添加到尚未出现在记录在区块链150上的区块151中的有效事务的有序池154。然后，区块链节点争相通过尝试解决加密难题以组装有序事务集154中事务152的新有效事务区块151。通常情况下，这包括搜索“随机数”值，从而当随机数与未决事务有序池154的表示并置且进行哈希处理时，哈希值的输出满足预定条件。例如，预定条件可以是哈希值的输出具有某个预定义的前导零数。注意，这仅仅是一种特定类型的工作证明难题，并且不排除其它类型。哈希函数的特性是，相对于其输入，其具有不可预测的输出。因此，该搜索只能通过强力执行，从而在试图解决难题的每个区块链节点104处消耗大量的处理资源。

解决难题的第一区块链节点104在网络106上宣布难题解决，提供解决方案作为证明，然后网络中的其它区块链节点104则可以轻松检查该解决方案(一旦给出哈希值的解决方案，就可以直接检查该解决方案是否使哈希值的输出满足条件)。第一区块链节点104将一个区块传播到接受该区块的其它节点达成阈值共识，从而执行协议规则。然后，有序事务集154被每个区块链节点104记录为区块链150中的新区块151。区块指针155还分配给指向该区块链中先前创建的区块151n-1的新区块151n。创建工作证明解所需的大量工作(例如采用哈希的形式)发出信号通知第一节点104的意图以遵循区块链协议。这些规则包括如果它分配与先前核实有效的事务相同的输出，则不接受事务为有效，否则称之为重复花费。一旦创建，区块151就不能修改，因为它在区块链网络106中的每个区块链节点104处进行标识和维护。区块指针155还向区块151施加顺序。由于事务152记录在网络106中每个区块链节点104处的有序区块中，因此提供了事务的不可改变公共分类账。

应当注意的是，在任何给定时间争相解决难题的不同区块链节点104可以基于在任何给定时间尚未发布的事务的池154的不同快照来这样做，具体取决于它们何时开始搜索解或接收事务的顺序。解决相应难题的人员首先定义新区块151n中包括的事务152及其顺序，并且更新当前的未发布事务池154。然后，区块链节点104继续争相从新定义的未发布事务有序池154中创建区块，等等。此外，还存在解决可能出现的任何“分叉”的协议，其中两个区块链节点104彼此在很短的时间内解决难题，从而在节点104之间传播区块链的冲突视图。简言之，分叉方向最长的成为最终区块链150。应当注意的是，这不会影响网络的用户或代理，因为同一事务将出现在两个分叉中。

根据比特币区块链(和大多数其它区块链)，成功构造新区块104的节点被授予在分配附加限定数量数字资产的新特殊类型事务中新分配附加的、接受的数额的数字资产的能力(与代理间或用户间事务相反，该事务将一定数量的数字资产从一个代理或用户转移到另一个代理或用户)。这种特殊类型的事务通常称为“coinbase事务”，但是也可以称为“启动事务”或“产生事务”。它通常形成新区块151n的第一事务。工作证明发出信号通知构造新区块的节点的意图以遵循协议规则，从而允许稍后赎回该特定事务。在可以赎回该特殊事务之前，区块链协议规则可能需要成熟期，例如100个区块。通常，常规(非生成)事务152还将在其输出中的一个输出中指定附加事务费用，以进一步奖励创建其中发布该事务的区块151n的区块链节点104。该费用通常称为“事务费用”，并在下文中讨论。

由于事务核实和发布中涉及的资源，通常至少每个区块链节点104采用包括一个或多个物理服务器单元的服务器的形式，或者甚至整个数据中心。但是，原则上来说，任何给定区块链节点104均可采用一个用户终端或联网在一起的一组用户终端的形式。

每个区块链节点104的存储器均存储被配置为在区块链节点104的处理装置上运行的软件，以根据区块链节点协议执行其相应的角色并处理事务152。应当理解的是，在本文中归因于区块链节点104的任何动作均可通过在相应计算机设备的处理装置上运行的软件执行。节点软件可以在应用层或诸如操作系统层或协议层的较低层或这些层任意组合的一个或多个应用中实现。

扮演消费用户角色的多方103中的每一方的计算机设备102也连接到网络101。这些用户可以与区块链网络106交互，但不参与核实事务或构造区块。其中一些用户或代理103可以充当事务中的发送者和接收者。其它用户可以与区块链150交互，而不必充当发送者或接收者。例如，一些当事方可以充当存储区块链150的副本(例如，已经从区块链节点104获得区块链的副本)的存储实体。

各方103中的一些或所有当事方可以作为不同网络的一部分连接，例如覆盖在区块链网络106之上的网络。区块链网络的用户(经常称为“客户端”)可以被称为是包含区块链网络106的系统的一部分；然而，这些用户不是区块链节点104，因为它们不执行区块链节点所需的角色。相反，每一方103可以与区块链网络106交互，从而通过连接到区块链节点106(即，与区块链节点106通信)来利用区块链150。出于说明目的，示出了双方103及其相应的设备102：第一方103a及其相应的计算机设备102a，以及第二方103b及其相应的计算机设备102b。应当理解的是，更多此类当事方103及其相应的计算机设备102可能存在并参与系统100，但为了方便起见，未进行说明。每一方103均可以是个人或组织。仅出于说明目的，在本文中，第一方103a称为爱丽丝，第二方103b称为鲍勃，但应当理解的是，这并不仅限于爱丽丝或鲍勃，且本文对爱丽丝或鲍勃的任何引用均可分别用“第一方”和“第二方”替换。

每一方103的计算机设备102包括相应的处理装置，其包括一个或更多个处理器，例如一个或更多个CPU、图形处理单元(GPU)、其他加速器处理器、特定应用程序处理器和/或FPGA。每一方103的计算机设备102还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。该存储器可包括一个或更多个存储器单元，其采用一个或更多个存储器介质，例如诸如硬盘等磁介质、诸如SSD、闪存或EEPROM等电子媒介和/或诸如光盘驱动器等的光学介质。每一方103的计算机设备102上的存储器存储软件，其包括被设置为在处理装置上运行的至少一个客户端应用程序105的相应实例。应当理解的是，在本文中归因于给定方103的任何行动均可通过在相应计算机设备102的处理装置上运行的软件执行。每一方103的计算机设备102包括至少一个用户终端，例如台式或笔记本电脑、平板电脑、智能手机或诸如智能手表等的可穿戴设备。给定方103的计算机设备102还可包括一个或更多个其他网络资源，诸如通过用户终端访问的云计算资源。

客户端应用程序105最初可通过例如从服务器下载的适当计算机可读存储介质，或通过诸如可移动SSD、闪存密钥、可移动EEPROM、可移动磁盘驱动器、软盘或磁带等的可移动存储设备、诸如CD或DVD ROM等的光盘或可移动光驱等提供至任何给定方103的计算机设备102。

客户端应用程序105至少包括“钱包”功能。这有两个主要功能。其中一个功能是使相应方103能够创建、授权(例如签名)事务152并将其发送到一个或多个比特币节点104，然后在区块链节点104的网络中传播，从而包括在区块链150中。另一个功能是向相应方汇报其目前拥有的数字资产数额。在基于输出的系统中，该第二功能包括整理分散在区块链150中属于相关方的各种事务152的输出中定义的数额。

注意：虽然各种客户端功能可以描述为集成到给定客户端应用程序105中，但这不一定是限制性的，相反，在本文中所描述的任何客户端功能可以在由两个或更多个不同应用程序组成的套件中实现，例如经由API进行接口连接或一个应用程序作为另一个应用程序的插件。更通俗地说，客户端功能可以在应用层或诸如操作系统的较低层或这些层的任意组合实现。下面将根据客户端应用程序105进行描述，但应当理解的是，这不是限制性的。

每个计算机设备102上的客户端应用程序或软件105的实例可操作地耦合到网络106的区块链节点104中的至少一个。这可以启用客户端105的钱包功能，以将事务152发送至网络106。客户端105还可联络区块链节点104，以在区块链150中查询相应方103作为接收者的任何事务(或实际上在区块链150中检查其它方的事务，因为在实施例中，区块链150是在某种程度上通过其公开可见性提供事务信任的公共设施)。每个计算机设备102上的钱包功能被配置为根据事务协议制定和发送事务152。如上所述，每个区块链节点104运行软件，该软件被配置为根据区块链节点协议核实事务152并转发事务152以便在区块链网络106中传播。事务协议和节点协议相互对应，给定事务协议和给定节点协议一起实现给定的事务模型。相同的事务协议用于区块链150中的所有事务152。网络106中的所有节点104使用相同的节点协议。

当给定方103(比方说爱丽丝)希望发送拟包含在区块链150中的新事务152j时，她将根据相关事务协议(使用其客户端应用程序105中的钱包功能)制定新事务。然后，她将事务152从客户端应用程序105发送到她所连接的一个或多个区块链节点104。例如，这可能是与爱丽丝的计算机102最佳连接的区块链节点104。当任何给定区块链节点104接收新事务152j时，其将根据区块链节点协议及其相应的角色进行处理。这包括首先检查新接收的事务152j是否满足变为“有效”的特定条件，具体示例稍后将详细讨论。在一些事务协议中，有效条件可通过事务152中包含的脚本在每个事务的基础上进行配置。或者，条件可仅仅是节点协议的内置功能，或通过组合脚本和节点协议进行定义。

如果新接收的事务152j通过有效性测试(即：“有效”的条件下)，接收事务152j的任何区块链节点104将向在区块链节点104处维护的有序事务集154中添加新的核实有效事务152。进一步地，接收事务152j的任何区块链节点104随后将核实有效事务152传播至网络106中的一个或多个其它区块链节点104。由于每个区块链节点104应用相同的协议，因此假定事务152j有效，这意味着事务很快将在整个网络106中传播。

一旦进入在给定区块链节点104处维护的未决事务有序池154，该区块链节点104将开始争相解决其各自的包含新事务152的池154的最新版本上的工作证明难题(请记住，其它区块链节点104可以尝试基于不同的事务池154来解决难题。但是，首先解决难题的人将定义包括在最新区块151中的事务集合。最终，区块链节点104将解决有序池154的一部分的难题，该有序集154包括爱丽丝的事务152j)。一旦包括新事务152j的池154完成工作证明，其将不可变地成为区块链150中区块151中的一个区块的一部分。每个事务152包括指向早前事务的指针，因此事务的顺序也被不可变地记录下来。

不同的区块链节点104可以首先接收给定事务的不同实例，并且因此在一个实例被发布到新区块151中之前具有关于哪个实例“有效”的冲突视图，此时所有区块链节点104同意所发布的实例是唯一的有效实例。如果区块链节点104将一个实例接受为有效实例，然后发现第二实例已记录在区块链150中，则区块链节点104必须接受这一点，并将丢弃(即，视为无效)其最初接受的实例(即，在区块151中尚未公布的实例)。

作为基于账户的事务模型的一部分，由一些区块链网络操作的另一种类型的事务协议可称为“基于账户的”协议。在基于账户的情况下，每个事务均不通过参考过去事务序列中先前事务的UTXO来定义转移的数额，而是通过参考绝对账户余额进行定义。所有账户的当前状态由网络的节点单独存储到区块链中，并不断更新。在此类系统中，事务使用账户的运行事务记录(也称为“头寸”)进行排序。该值由发送者签名作为其加密签名的一部分，并作为事务引用计算的一部分进行哈希处理。此外，可选的数据字段也可以在事务中签名。例如，如果数据字段中包含先前事务的ID，该数据字段可指向先前事务。

基于UTXO的模型

图2示出了示例性事务协议。这是基于UTXO的协议的示例。事务152(简称“Tx”)是区块链150的基本数据结构(每个区块151包括一个或多个事务152)。下面将通过参考基于输出或基于“UTXO”的协议进行描述。但这并不限于所有可能的实施例。应当注意的是，虽然参考比特币描述了示例性基于UTXO的协议，但是它同样可以在其它示例区块链网络上实现。

在基于UTXO的模型中，每个事务(“Tx”)152包括数据结构，其包括一个或多个输入202和一个或多个输出203。每个输出203可包括未花费事务输出(UTXO)，其可用作另一新事务的输入202的来源(如果UTXO尚未赎回)。UTXO包括指定数字资产数额的值。这表示分布式分类账上的一组通证。UTXO还可包含其来源事务的事务ID以及其它信息。事务数据结构还可包括标头201，其可包括输入字段202和输出字段203的大小指示符。标头201还可包括事务的ID。在实施例中，事务ID是事务数据(不含事务ID本身)的哈希值，且存储在提交至节点104的原始事务152的标头201中。

比方说爱丽丝103a希望创建转移相关数字资产数额至鲍勃103b的事务152j。在图2中，爱丽丝的新事务152j标记为“Tx

当爱丽丝创建其新事务Tx

先前事务Tx

锁定脚本(亦称scriptPubKey)是节点协议识别的域特定语言中写入的一段代码。此类语言的特定示例称为“脚本(Script)”(S大写)，其可由区块链网络所使用。锁定脚本指定花费事务输出203所需的信息，例如爱丽丝签名的要求。解锁脚本出现在事务的输出中。解锁脚本(亦称scriptSig)是提供满足锁定脚本标准所需信息的域特定语言中写入的一段代码。例如，其可包含鲍勃的签名。解锁脚本出现在事务的输入202中。

因此在示出的示例中，Tx

当新事务Tx

||[Checksig PA]

其中“||”表示并置，“<…>”表示将数据放在堆栈上，“[…]”表示由锁定脚本组成的函数(在该示例中指基于堆栈的语言)。同样，脚本可以使用公共堆栈一个接一个地运行，而不是并置脚本。无论采用哪种方式，当一起运行时，脚本使用爱丽丝的公钥P

本领域技术人员将熟悉通过公私密码进行验证的细节。基本上而言，如果爱丽丝已使用其私钥加密签署消息，则给定爱丽丝的公钥和明文中的消息，诸如节点104等其它实体可验证消息必须已经由爱丽丝签名。签署通常包括对消息进行哈希，签署哈希值和将此标记到消息作为签名，从而使公钥的任何持有者能够验证签名。因此，应当注意的是，在实施例中，在本文中对签名特定数据片段或事务部分等的任何引用可以意味着对该数据片段或事务部分的哈希值进行签名。

如果Tx

如果给定事务152的所有输出203中指定的总数额大于其所有输入202所指向的总数额，则这是大多数事务模型中的另一失效依据。因此，此类事务不会传播或包括在区块151中。

请注意，在基于UTXO的事务模型中，给定UTXO需要作为一个整体使用。不能“留下”UTXO中定义为已花费的一部分数额，而同时又花费另一部分。但UTXO的数额可以在后续事务的多个输出之间分割。例如，Tx

在实践中，爱丽丝通常还需要包括用于比特币节点104的费用，该比特币节点104在区块151中成功包含爱丽丝的事务104。如果爱丽丝未包括此类费用，则Tx

爱丽丝和鲍勃的数字资产由区块链150中任何位置的任何事务152中的锁定至他们的UTXO组成。因此，通常情况下，给定方103的资产分散在整个区块链150的各种事务152的UTXO中。区块链150中的任何位置均未存储定义给定方103的总余额的一个数字。客户端应用程序105的钱包功能的作用是将锁定至相应方且在其它随后事务中尚未花费的各种UTXO值整理在一起。为实现这一点，其可以查询存储在任何一个比特币节点104处的区块链150的副本。

应当注意的是，脚本代码通常用示意图表示(即使用非精确语言)。例如，可以使用操作码(opcode)来表示特定功能。“OP_...”是指脚本语言的特定操作码。举例来说，OP_RETURN是脚本语言操作码，当在锁定脚本的开始处在操作码前加上OP_FALSE时，操作码创建事务的不可花费输出，该输出可以在事务内存储数据，从而将数据不可改变地记录在区块链150中。例如，数据可包括需存储在区块链中的文件。

通常，事务的输入包含对应于公钥PA的数字签名。在实施例中，这基于使用椭圆曲线secp256k1的ECDSA。数字签名对特定的数据段进行签名。在实施例中，对于给定事务，签名将对部分事务输入以及部分或全部事务输出进行签名。对输出的特定部分进行签名取决于SIGHASH标志。SIGHASH标志通常是包含在签名末尾的4字节代码，用于选择签名的输出(并因此在签名时固定)。

锁定脚本有时称为“scriptPubKey”，指其通常包括相应事务被锁定到的当事方的公钥。解锁脚本有时称为“scriptSig”，指其通常提供相应的签名。但是更通俗地说，在区块链150的所有应用中，UTXO赎回的条件并不一定包括对签名进行验证。更通俗地说，脚本语言可用于定义任何一个或多个条件。因此，可以优选更为通用的术语“锁定脚本”和“解锁脚本”。

侧信道

如图1所示，爱丽丝和鲍勃的计算机设备102a、120b中的每个计算机设备上的客户端应用程序都可以包括附加通信功能。此附加功能可使爱丽丝103a建立与鲍勃103b的单独侧信道107(在任何一方或第三方的鼓动下)。侧信道107使得能够脱离区块链网络交换数据。此类通信有时称为“链下off-chain”通信。例如，这可用于在爱丽丝与鲍勃之间交换事务152，而不将该事务(尚未)注册到区块链网络106上或将其发布到链150上，直到其中一方选择将其广播到网络106上。以这种方式共享事务有时称为共享“事务模板”。事务模板可能缺少形成完整事务所需的一个或多个输入和/或输出。替代地或附加地，侧信道107可用于交换任何其它事务相关数据，例如密钥、议付数额或条款、数据内容等。

通过与区块链网络106相同的分组交换网络101可建立侧信道107。替代地或附加地，侧信道301可以经由诸如移动蜂窝网络的不同网络或者诸如无线局域网络的局域网建立，甚至经由爱丽丝和鲍勃的设备102a、102b之间的直接有线或无线链路建立。通常，在本文中任何地方所指的侧信道107可以包括经由一项或多项联网技术或通信介质的任何一条或多条链路，这些链路用于“链下”交换数据，即脱离区块链网络106交换数据。在使用多条链路的情况下，链下链路束或集合整体上可以称为侧信道107。因此，应当注意的是，如果说爱丽丝和鲍勃通过侧信道107交换某些信息或数据等，则这不一定意味着所有这些数据都必须通过完全相同的链路或甚至相同类型的网络发送。

客户端软件

图3A示出了用于实现本公开方案的实施例的客户端应用程序105的示例性实施方式。客户端应用程序105包括事务引擎401和用户界面(UI)层402。根据上文讨论的方案以及稍后将进一步详细讨论的内容，事务引擎401被配置为实现客户端105的基础事务相关功能，诸如制定事务152，通过侧信道301接收和/或发送事务和/或其他数据，和/或发送事务至一个或更多个节点104以通过区块链网络106传播。根据本文公开的实施例，每个客户端105的事务引擎401包括函数403，该函数用于生成区块链统一资源标识符(BURI)或引用存储在改区块链上的区块链事务。

该UI层402被配置为通过相应用户的计算机设备102的用户输入/输出(I/O)方式呈现用户界面，包括通过设备102的用户输出方式向相应用户103输出信息，和通过设备102的用户输入方式接收来自相应用户103的输入。例如，用户输出方式可包括提供视觉输出的一个或显示多个屏(触摸或非触摸屏)、提供音频输出的一个或更多个扬声器、和/或提供触觉输出的一个或更多个触觉输出设备等。用户输入方式可包括例如一个或更多个触摸屏的输入阵列(可与用于输出方式的那个/那些相同或不同)；一个或更多个基于光标的设备，诸如鼠标、轨迹板或轨迹球；一个或更多个麦克风和语音或声音识别算法，用于接收语音或声音输入；一个或更多个基于手势的输入设备，用于接收手动或身体手势形式的输入；或者一个或更多个机械按钮、开关或控制杆等。

注：虽然本文中的各种功能可以被描述为集成到同一客户端应用程序105中，但这并不一定构成限制，相反，它们可以在两个或更多个不同应用程序组成的一套程序中实现，例如一个应用程序作为另一个应用程序的插件或经由API(应用程序编程接口)进行接口。比如，事务引擎401的功能可以在单独的应用程序中实现，而不是在UI层402中实现，或者诸如事务引擎401的给定模块的功能可以在多个应用程序之间分割。同时，也不排除部分或全部描述的功能可以在比如操作系统层实现。在本文任何位置引用单个或给定应用程序105或诸如此类的情况下，应当理解的是这只是作为示例，并且更通俗地说，所描述的功能可以在任何形式的软件中实现。

图3B给出了用户界面(UI)500的示例的模型，该UI可由客户端应用程序105a的UI层402在爱丽丝的设备102a上呈现。应当理解的是，类似的UI可以由客户端105b在鲍勃的设备102b或任何其他方的设备上呈现。

通过图示的方式，图3B从爱丽丝的角度示出了UI 500。该UI 500可包括一个或更多个UI元素501、502、503，该一个或更多个UI元素通过用户输出方式呈现为不同的UI元素。

例如，UI元素可包括一个或更多个用户可选择的元素501，这些元素可以是屏幕上的不同按钮、菜单中的不同选项或者诸如此类。用户输入方式被设置成使用户103(在这种情况下为爱丽丝103a)能够选择或以其它方式操作其中一个选项，诸如通过点击或触摸屏幕上的UI元素，或者说出所需选项的名称(注：本文使用的“手动”一词仅用于与自动进行对比，而不一定限于用手执行操作)。这些选项使用户(爱丽丝)能够选择用于包括在区块链事务中的信息，例如区块链通用资源指示符(blockchain universal resource indicator，BURI)或要通过BURI引用的事务/数据，如下所述。这些选项还使用户能够请求验证区块链上是否存在所引用的事务，如下所述。

替代地或附加地，UI元素可以包括一个或多个数据输入字段502，通过该一个或多个数据输入字段502，用户可以提供用于包括在区块链事务中的文本，例如关于存储在通过BURI引用的事务中的数据的评论，或者手动定义要在BURI中引用的事务或存储在事务中的数据。这些数据输入字段通过用户输出方式呈现，例如屏幕上，并且数据可通过用户输入方式输入到字段中，例如键盘或触摸屏。或者，数据可以例如基于语音识别口头地接收。

替代地或附加地，UI元素可包括向用户输出信息的一个或更多个信息元素503。例如，这/这些可以在屏幕上呈现或可听见。

应当理解的是，呈现各种UI元素、选择选项和输入数据的特定方式并不重要。这些UI元素的功能稍后将进行更详细地讨论。还应当理解的是，图3中示出的UI 500只是一个图示模型，在实践中，它可包括一个或更多个进一步的UI元素，为了简洁起见，未对其进行说明。

节点软件

图4示出了在基于UTXO或基于输出的模型的示例中，在网络106的每个区块链节点104上运行的节点软件450的示例。应当注意的是，另一实体可以运行节点软件450，而不被分类为网络106上的节点104，即，不执行节点104所需的动作。节点软件450可以包含但不限于协议引擎451、脚本引擎452、堆栈453、应用级决策引擎454以及一个或多个区块链相关功能模块455的集合。每个节点104可以运行节点软件，该节点软件包含但不限于以下所有三个：共识模块455C(例如，工作证明)、传播模块455P和存储模块455S(例如，数据库)。协议引擎401通常被配置为识别事务152的不同字段，并根据节点协议处理此类字段。当接收到具有指向另一先前事务152i(Tx

因此，脚本引擎452具有Tx

通过同时运行脚本，脚本引擎452确定解锁脚本是否满足锁定脚本中定义的一个或多个标准，即解锁脚本是否对包括锁定脚本的输出进行解锁？脚本引擎452将该确定的结果返回给协议引擎451。如果脚本引擎452确定解锁脚本确实满足在相应的锁定脚本中指定的一个或多个标准，则返回结果“TRUE”。否则，返回结果“FALSE”。

在基于输出的模型中，来自脚本引擎452的结果“TRUE”是事务有效性的条件之一。通常，还必须满足由协议引擎451评估的一个或多个进一步协议级条件；例如，Tx

此外，还应当注意的是，在本文中，术语“TRUE”和“FALSE”不一定限于返回仅以单个二进制数(位)形式表示的结果，尽管这确实是一种可能的实现方式。更通俗地说，“TRUE”可以指指示成功或肯定结果的任何状态，而“FALSE”可以指指示不成功或不肯定结果的任何状态。例如，在基于账户的模型中，可以对签名的隐式协议级核实和智能合约的附加肯定输出的组合来指示结果为“TRUE”(如果两个单独的结果均为TRUE，则认为总体结果为TRUE)。

默克尔树

默克尔树是分层数据结构，能够对数据集合进行安全验证。在默克尔树中，树中的每个节点均提供有索引对(i，j)，并且表示为N(i，j)。索引i、j只是与树中的特定位置相关的数字标签。

默克尔树的一个重要特征是，其每个节点的构造由以下方程式控制：

其中H是加密哈希函数。

图5中示出了根据这些方程式构建的二进制默克尔树。从图中可以看出，i＝j情况对应于叶节点，该叶节点仅仅是数据D

例如，节点N(0，3)由四个数据包D

N(0，3)＝H(N(0，1)||N(2，3))

＝[H(N(0，0)||N(1，1))||H(N(2，2)||N(3，3))]

＝[H(H(D

树的深度M被定义为树中节点的最低级别，节点的深度m是节点所在的层级。例如，m

对于比特币和一些其他区块链中的默克尔树，哈希函数是双重SHA256，即应用标准哈希函数SHA-256两次：H(x)＝SHA256(SHA256(x))。

默克尔证明

默克尔树的主要功能是验证某个数据包D

如果证明者知道所有分组D

使用默克尔证明和使用整个列表的比较如下表所示，其中使用了二进制默克尔树，并假设数据块的数量N正好等于2的整数幂。

下表示出了默克尔树中叶节点的数量与默克尔证明所需的哈希数量(默克尔证明)之间的关系。

在这个简化场景中(其中数据包的数量等于叶节点的数量)，已发现，计算默克尔证明所需的哈希值的数量以对数方式缩放。显然，计算涉及log

方法

如果给定默克尔根R，则希望证明数据块D

i.从可信源获取默克尔根R。

ii.从源获取默克尔证明Γ。在这种情况下，Γ是哈希的集合：

Γ＝{N(1，1)，N(2，3)，N(4，7)}。

iii.使用D

a.对数据块进行哈希处理以得到：

N(0，0)＝H(D

b.与N(1，1)级联并进行哈希处理以得到：

N(0，1)＝H(N(0，0)||N(1，1))。

c.与N(2，3)级联并进行哈希处理以得到：

N(0，3)＝H(N(0，1)||N(2，3))。

d.与N(4，7)级联并进行哈希处理以获取根：

N(0，7)＝H(N(0，3)||N(4，7))，

R′＝N(0，7)。

e.将计算得出的根R′与(i)中获取的根R进行比较：

1.如果R′＝R，则确认树中存在D

2.如果R′≠R，则证明失败，无法确认D

这是一种有效机制，可为作为由默克尔树及其根表示的数据集的一部分的某些数据提供存在证明。例如，如果数据D

图6示出了作为我们的示例性默克尔树的一部分验证存在D

构建默克尔证明所需的最少信息

在构建单叶的默克尔证明时，所需的最少信息为

1.叶的索引：叶在默克尔树的叶层中的位置。

2.哈希值的有序列表：计算默克尔根所需的哈希值。

为了阐明叶的索引的工作原理，请考虑图5所示的默克尔树。鲍勃知道树的根R，但不知道树的所有叶。D

假设默克尔树具有N＝2

p

因此，可以在层级m定义，使得

b

则所提供哈希的索引为

上面的方程式假定索引从0开始。

在本发明的上下文中，索引为i

统一资源标识符

使用多个不同的标识符来定位互联网上的资源。这些标识符允许数据资源的网络交换，并且可以在点对点网络中使用。这些标识符还允许资源命名中的唯一性。

统一资源标识符(URI)是一种用于在线标识内容的方案。用户可以创建通用方案来寻址互联网上可用的协议和资源。该方案具有用户可以定义的多个组件。

通用URI语法由称为方案、权限、路径、查询和片段的组件的分层序列组成：

URI＝scheme″：″hier-part[″？″query][″#″fragment]

其中“hier-part”可以从以下选项中选择

hier-part＝″//″authority path-abempty

/path-absolute

/path-rootless

/path-empty

URI方案可以用于描述协议内的功能以及资源本身。文件传输和邮件功能可以在给定方案内定义。这可以通过统一资源定位符(URL)直接使用。

URI语法是按层级结构组织的，其中组件按重要程度递减的顺序列出。URI的组件通过至少一个分隔符隔开。所保留的字符子集可以用于界定URI内的语法组件。在本文公开的示例中，所使用的分隔符是“：”和“/”，尽管可以理解的是，其他字符可以定义为并且因此用作隔开URI的不同分层语法组件的分隔符。

URI方案可以用作定义和寻址资源的统一方式。

其他URI在本领域中是已知的。

区块链统一资源标识符

现在将描述允许引用目标事务中的内容的URI方案。该URI方案还可以用于验证目标事务是否存在于区块链上。URI可以包括在区块链事务中，在本文中称为引用事务，从而提供用于引用区块链上的目标事务的手段。

通过在URI方案本身中包括与用于目标事务的默克尔树证明相关的信息来实现验证。

简单区块链URI方案

简单区块链统一资源标识符(sBURI)可以用于引用区块链上先前发布的事务的内容。sBURI方案如下：

sBURI:[block identifier]:[TxID]

可以提供区块编号或区块头哈希作为区块标识符来标识包含所引用的事务的区块(目标区块)。

在sBURI方案中仅使用目标事务的TxID不足以验证目标事务是否存在于区块链上。验证者仍然需要获取默克尔树分支信息来完成默克尔树证明。然而，TxID足以使目标事务位于区块链上。

下面示出了引用事务的示例，该事务在其输出中使用sBURI来引用现有目标事务，其TxID为jsf…38r。在该示例性sBURI中已经使用了区块高度，其指示目标事务驻留在区块编号630000中。

虽然上述sBURI包括区块标识符，但是应当注意的是，仅需要TxID来定位目标事务。

完整区块链URI方案

更稳健的区块链URI方案(BURI)还提供默克尔证明信息，以使得能够验证目标事务的存在证明。

该BURI通过区块编号或区块哈希来标识区块，并且还包含与目标事务相关的默克尔树信息和事务ID。完整URI方案的格式编写如下：

BURI:[block identifier]:[Merkle proof data]:[TxID]

验证者可以使用BURI来协助验证目标事务已经包括在区块链上的区块中。在上面所示的BURI方案的一般形式中，默克尔证明数据组件是通过向拥有BURI的任何人提供默克尔证明验证所需的至少一部分附加信息来协助验证的部分。

BURI的默克尔证明数据可以包括以下任一项：

i.目标事务的默克尔索引；或

ii.目标事务的默克尔索引和默克尔证明的哈希的有序列表。

应当注意在BURI方案中包括目标事务的索引(即，与目标事务对应的默克尔树的叶)的重要性，因为正是这条信息允许从默克尔证明中的哈希的有序列表正确地计算默克尔证明。哈希的有序列表是确定目标事务是否由从区块头获取的可信默克尔根验证所需的默克尔证明哈希的子集。默克尔根在本文中也可以称为默克尔根哈希。

如上所述，默克尔分支的索引和对应的默克尔证明哈希可以完全从叶本身的叶层索引中导出。

从图5中可以看出，采用二进制形式的叶的索引从根到叶映射到默克尔树中的树遍历，并因此确定树中与默克尔存在证明验证相关的每个索引点。每个节点的左子节点和右子节点分别标有0和1，并因此指示从根节点遍历到叶节点的路径。例如，在索引3处从根遍历到叶的路径仅仅是以二进制011

本文中描述的BURI可以在区块链上或区块链外使用。下面列出了一个链上使用示例。

考虑由爱丽丝创建的事务TxID

下面的目标事务TxID

下面示出了包含引用目标事务的BURI的事务TxID

鲍勃的事务包含BURI，该BURI通过指定其中包括爱丽丝的事务的区块(15)、该区块内的事务的索引(5)以及最终目标事务ID本身(jsf…38r)来引用爱丽丝的事务。

这意味着这是BURI使用示例，其中BURI的默克尔证明数据组件仅仅是TxID

从其获取默克尔证明的第三方可以是区块链节点(也称为矿工)。或者，第三方可以是下面更详细描述的默克尔证明服务器，其存储相应区块链事务的一组事务标识符，但不向区块链网络发布新的区块链区块。

然而，鲍勃可能希望确保其事务中的BURI可以使任何人能够验证存在证明，而无需咨询第三方来获取证明。鲍勃可以通过在其事务中构造BURI来实现这一点，使得BURI包括整个默克尔证明本身，从而产生如下形式的BURI：

BURI:15:5:3be…f41/2ab…e5c/…/ff1…0de:jsf…38r

其中3be…f41/2ab…e5c/…/ff1…0de是默克尔证明中的一组有序的哈希。

下面示出了鲍勃的事务TxID

应当注意的是，上述BURI还保留了TxID

[Merkle proof data]＝[Index]:[Proof hashes]＝[5]:[3be…f41/2ab…e5c/…/ff1…0de]

存在各种不同的方式，其中关于TxID

然而，由于默克尔证明的哈希的数据会增加引用事务TxID

图9示意性地示出了在引用事务906中使用BURI 908来引用目标事务902。

在该示例中，查理想要在目标事务902中引用存储在区块链上的图像数据。为此，查理生成或以其他方式获取标识目标事务902的BURI 908，并将BURI 908包括在引用事务的输出中。

查理还必须提供引用事务906的输入，用于至少提供引用事务906的事务费用。查理提供标识先前事务904的输出点，其中UTXO被锁定到查理。

从图9可以看出，通过在引用事务906的输出中提供BURI 908，查理能够引用存储在目标事务902中的数据，而不需要将存储在目标事务902中的数据传输给查理。也就是说，查理能够引用他没有所有权的数据。

图10示出了BURI的组件如何对应于目标区块的组件。BURI是这些组件的分层序列，其中BURI的每个后续组件更具体地定义目标数据。

BURI的第一组件是区块标识符，其指示包括在BURI中引用的事务的区块，并指向目标区块的区块头。区块标识符可以是区块编号(高度)，其是区块头的组件，也可以是区块头哈希。这两个组件中的任一个可以用于定位区块链上的目标区块，或者在存储关于区块和事务的信息的数据库内定位。

区块编号(高度)被定义为区块在从创世区块开始的区块的有序序列中的位置。如果两个区块是区块链的并行分支的一部分，则它们可以具有相同的区块编号。

区块头哈希被定义为在区块产生时生成的区块头的双重哈希。它对于区块是唯一的，并且是时不变的。

区块发布将新的区块添加到链中。有时，区块可能会受到孤立过程的影响，在此过程中，区块不会加入永久区块链并且会被放弃。

使用区块编号和区块头哈希作为区块标识符各有优点和缺点。

区块编号/高度是区块的更紧凑标识符。它可以是短字符串(例如，4字节)，因此比存储32字节的哈希值更节省空间。

然而，区块编号不一定是区块的唯一标识符。可能存在两个有效区块具有相同的编号/高度，但是与同一链的不同分支相关联。

区块头的哈希是该区块的唯一标识符，并且在区块发布时创建。

然而，当前区块头哈希的大小(32字节)不如区块编号紧凑。一些区块会受到孤立过程的影响。

总之，区块编号的使用对于最小化与BURI相关联的数据大小是可取的，但是最适用于包含在区块链中足够深的区块中的目标事务，因为这会最小化与区块相关联的孤立风险。相比之下，区块头哈希的使用具有唯一标识特定区块的好处，但是这以必须存储在包含BURI的链上事务中的额外数据为代价。

BURI的第二组件是事务索引，在本文中也称为默克尔索引。如前所述，事务索引指示通过默克尔树遍历到与事务相关联的叶节点的路径。

BURI的第三组件是默克尔证明的哈希的有序列表。这些哈希不对应于目标事务的特定组件，而是提供用于验证。

事务索引和哈希的有序列表形成默克尔证明数据。如上所述，默克尔证明数据可以仅包括索引。默克尔证明数据组件包含关于BURI所针对的事务的默克尔证明的至少部分信息。

在仅包括事务索引的默克尔证明数据的情况下，这种形式的BURI不包含用户独立地验证目标事务存在于区块链上所需的所有信息，因为它们仍然需要默克尔证明中的一组哈希。

然而，在BURI中包括事务索引允许验证者基于该索引向第三方请求默克尔证明。如果第三方是存储每个区块的默克尔树的默克尔路径服务器，则这可能是有益的，因为该索引将允许他们标识树中的哪些哈希构成证明。

通常，事务ID本身可能足以向第三方请求默克尔证明；然而，在BURI中包括索引允许验证者咨询更广泛专业的服务，这些服务可被优化以基于区块标识符和事务索引而不是事务ID来响应对默克尔证明的请求。这对于服务提供者来说可能更高效，因为这将允许他们直接访问正确的默克尔证明，而不必基于TxID蛮力搜索证明哈希。

在未提供哈希列表的情况下，该方案采用以下形式：

BURI:[block identifier]:[Merkle proof data]:[TxID]

例如：

BURI:01111:0101:jsf7r8urige84r43wekefh344iurrh438r

如果索引采用二进制形式，并且：

BURI:01111:5:jsf7r8urige84r43wekefh344iurrh438r

如果索引采用十进制形式。

默克尔树的目标叶的索引可以最紧凑地表示为二进制索引。

或者，目标事务索引及其默克尔证明的哈希的完整序列表都包括在BURI本身中。这具有显著好处，即核实目标事务存在于区块中所需的所有内容独立包含在BURI中。

用户可以简单地获取这种形式的BURI，提取默克尔证明哈希，并通过将目标事务哈希与默克尔证明哈希按顺序组合并基于BURI中还提供的索引与左/右赋值组合来执行默克尔证明验证。用户还可能希望获取原始目标事务，以确保其双重哈希对应于在BURI中提供的TxID，以确保该事务中的实际内容数据也被证明已经在链上发布。

如果默克尔证明数据既包括事务索引又包括哈希的有序列表，则可以隔开索引和哈希，也可以在哈希前面加上索引值。

在第一种情况下，该方案采用以下形式：

BURI:[block identifier]:[Merkle proof data]:[TxID]

例如：

BURI:01111:0101:3be…f41/2ab…e5c/…/ff1…0de:jsf…38r

这里，BURI包含一组完整的默克尔证明哈希以及事务的索引。每个哈希可以基于索引值(0101)分配为左伙伴或右伙伴。

在第二种情况下，该方案采用以下形式：

BURI:[block identifier]:[Merkle proof data]:[TxID]

例如：

BURI:01111:[0]3be…f41/[1]2ab…e5c/…/[1]ff1…0de:jsf…38r

该BURI格式还包含哈希的完整列表和索引，其中每个二进制位已经加到对应哈希的前面以指示其是左伙伴还是右伙伴(例如，哈希3be…f41的前面加有0)。

每种类型的默克尔证明数据(即，具有和不具有默克尔证明哈希的数据)具有优于其他类型的优势。

·效用–在具有哈希列表的情况下，BURI使用户能够在没有任何第三方协助的情况下独立地核实目标事务的存在证明。与不具有哈希的情况相比，这提供了明显更高的效用。

·大小–包括一组完整的默克尔证明哈希意味着BURI大小明显大于BURI中不包括哈希的情况。一组k个默克尔证明哈希的k×32个字节的大小成为BURI总体大小的主导因素，尽管这仅随着包含它的区块中的事务数量n的k～log(n)而增长。

·复制–由于特定事务中的一段内容可能会被多次引用(例如，由对同一帖子发表评论的不同人引用)，因此存储在链上的任何BURI很可能会随着时间的推移而被复制。这将加剧两种类型的默克尔证明数据之间的链上BURI的存储成本的差异，其中包括哈希的BURI的多个实例将复制整个k×32链上默克尔证明。

·持久性–将整个链上默克尔证明放在BURI中的好处在于，可以提供存在证明，并且存在证明比不具有哈希的BURI所引用的内容更持久。这意味着包括哈希的BURI在解决链接失效方面表现更佳，如下所述。

总之，关于是否选择在BURI中包括默克尔证明哈希取决于BURI的创建者想要实现的目的。如果成本是主要考虑因素，则不具有哈希的BURI可能更受青睐；然而，如果存在证明的效用或长期持久性超过相关成本，则包括哈希的BURI可能是首选项。

BURI的第四组件是TxID，其指向目标区块中目标事务的事务标识符。如上所述，这是在区块链上定位事务所需的BURI的唯一组件，因为它对于区块是唯一的。然而，区块标识符和事务索引可提高定位目标事务的效率，因为这些组件提供了关于目标事务的位置的更多信息，并且减少了为定位目标事务而搜索的事务和区块的数量。

图10的框中仅示出了事务TxID

附加的最终组件，即片段组件(未示出)，可以包括在sBURI和BURI方案中。该组件允许URL的附加功能与现代互联网上的现有URL使用相结合，例如标识网页的小节，或实现对资源的基于角色的访问。

完整URI方案的格式编写如下：

BURI:[block identifier]:[Merkle proof data]:[TxID][？details]

其中[？details]组件是片段组件。

通用URI语法的“#fragment”组件使用“#”字符来指定目标资源内的位置。例如，在下面所示的比特币SV维基中，URL可能指示一个页面，然后该页面上的特定小节或副标题使用表示片段名称开始的#字符来指定。

使用该格式的URL的一些示例如下：

https://wiki.bitcoinsv.io/index.php/Main_Page#Transactions

https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script#Stack

在BURI的上下文中，这些附加的片段选项非常适于定位目标事务的特定事务字段或数据项，例如输出内的数据推送或特定输出。此类BURI的示例(扩展了上述示例)可以写为：

BURI:01111:0101:jsf…38r#0ut0#Push2

其中第一片段“#0ut0”标识目标事务的索引0处的输出，第二片段“#Push2”标识该输出的脚本中的第二推送数据项。下面给出了显示该BURI的使用的一对示例性事务，其中第二事务TxID

因此，TxID

附件A总结了现有URI方案标准与本文中提出的BURI方案之间的相似性。

本文中提出的BURI方案的主要技术优势可以概括如下：

·与区块链兼容：BURI方案是一种URI标准，旨在与区块链数据兼容，其结构类似于比特币区块链。

·数据完整性：该方案包括帮助用户验证URI所针对的数据的存在证明的信息。这通过确保目标内容的长期数据完整性来改进现有URI方案，这利用公共区块链的属性来实现这一点。

·去重：所提出的对链上数据使用BURI使用户能够以稳健方式引用目标数据，而不是在添加到内容数据时重复数据本身(例如，通过对其进行评论)，从而促进内容数据的去重。

·允许专门化：将目标事务索引及其事务ID纳入BURI方案中，可以在可能提供默克尔证明数据的第三方之间实现更强的专门化。例如，不同的服务提供者可能专门基于索引和区块哈希来响应对默克尔证明的请求，而其他服务提供者将仅基于TxID来响应。这种专门化还可能促进优化，从而降低提供服务的总体成本。

·减轻“链接失效”：通过将存在证明所需的数据包括在URI方案本身中，用户能够在未来任何时间点验证特定资源是否存在于链上位置。这可减轻互联网资源的现有链接失效问题，即资源可能会随着时间的推移从链接中消失，并且需要可信服务提供者来证明原始内容。BURI方案使用区块链数据的不可变性来减轻这一问题，方法是消除对这些可信第三方的依赖，并默认使用区块链网络本身。

·灵活：BURI方案是通用方案，允许基于应用程序的需要灵活实现。这允许不同的用户创建在大小/成本和效用之间具有不同权衡的BURI，同时仍然能够使用方案的最通用实例在这些不同的BURI形式之间进行转换。

目标区块和目标事务在本文中也可以分别称为所标识的区块和所标识的转换。通过在BURI中至少提供事务标识符，可以明确地标识目标事务，并且由于事务标识符对于目标事务是唯一的，因此也可以标识包括目标事务的目标区块。如果BURI还包括区块标识符，则可以独立于目标事务来标识目标区块。

示例性用例

考虑作者鲍勃在使用区块链的社交网站上发表了一篇文章。个人读者(例如，爱丽丝)希望对这篇文章发表评论，并将其记录在区块链上。

由于文章和评论记录到区块链上，因此它们是公开的，不会改变，并且因此实现了作为书面作品的“不可变性”。区块链是一种确认原始文章以及所发表的任何评论的“不可变性”的方式。此外，爱丽丝可能希望在其评论中包括给鲍勃小费的微事务，这使得区块链成为整个交互的自然选择，因为评论数据和支付两者可以在单个事务中发生。

爱丽丝和鲍勃具有公共地址，当发表评论时，他们之间可能会发生事务。

在该示例中，鲍勃先前已经创建了一篇文章，并将其发布在区块链上的事务TxID

o她对鲍勃文章的评论；

o引用鲍勃文章的BURI；以及

o向鲍勃支付的小额支付。

爱丽丝创建的事务如下所示。

爱丽丝的事务的第一输出包含向鲍勃支付的V BSV的小额支付，第二输出包含OP_RETURN脚本，该脚本包括引用鲍勃文章和爱丽丝对该文章的评论的BURI。

这里包括的BURI包括鲍勃的原始事务TxID

存在证明

图11示出了用于在BURI不包括执行验证所需的数据的情况下验证目标事务的存在的示例性方法1100。也就是说，为了执行验证，必须从第三方获取默克尔证明。

在步骤1中，用户103向客户端105提供BURI。BURI可以由用户在区块链事务(例如，引用事务)中获取，也可以通过互联网(例如，从网页)获取；或者，用户103可以通过选择和/或输入相关信息来获取BURI。

客户端105向解析者1102发送数据请求。该请求可以包括BURI。或者，客户端105可以从BURI中提取BURI的组件以在请求中发送。例如，在BURI包括区块标识符、事务索引和TxID的情况下，客户端105可以提取这些组件中的每个组件，并将这些组件中的一个或多个组件发送到解析者1102。在一些实施例中，将BURI或BURI的组件发送到解析者1102的动作是请求。

在步骤3中，解析者1102从区块链网络106请求目标事务的目标数据。该请求至少包括TxID，以便可以定位目标事务。该请求还可以包括目标区块标识符和/或目标事务索引。通过使用目标区块标识符和/或目标事务索引(如果提供给解析者1102)，可以更高效地找到目标事务。

一旦目标数据已经位于区块链上，则在步骤4中将其从区块链网络106发送到解析者1102。

在步骤5中，解析者1102向证明提供者1104请求与目标事务相关联的默克尔证明。证明提供者1104可以是下面更详细描述的默克尔证明服务器。该请求至少包括TxID。它还可以包括提供给解析者的其他数据，这些数据可以用于定位所存储的关于目标事务的默克尔证明的信息，例如区块标识符和/或事务索引，从而提高获取默克尔根的效率。

在步骤6中，证明提供者1104使用TxID和任何其他接收的数据来定位默克尔证明，并将所请求的默克尔证明发送到解析者1102。从证明提供者1104发送到解析者1102的默克尔证明包括默克尔证明的有序哈希列表。

在一些情况下，还将目标事务索引从证明提供者1104发送到解析者1102。如上所述，采用二进制形式的事务索引指示节点是右伙伴还是左伙伴，并且因此指示哈希应该级联到右侧还是左侧。证明提供者1104可以提供采用二进制形式的索引，或者索引可以采用十进制形式并且稍后转换为二进制形式。

如果BURI不包括目标事务索引，则发送目标事务索引尤其重要。如果BURI包括采用十进制形式的目标事务索引，则可以导出二进制索引，因此不需要证明提供者1104提供二进制索引。在一些实施例中，证明提供者1104总是提供采用二进制形式的目标事务索引。

一旦解析者1102已经接收到数据和默克尔证明，则在步骤7中将数据和默克尔证明从解析者1102发送到客户端105。

然后，在步骤8中，客户端105能够使用事务数据、哈希列表、事务索引和可信默克尔根来验证如上所述的默克尔证明。客户端105从提供给它的区块头列表中获取可信默克尔根。如下面更详细描述的，如果客户端105是SPV客户端，则为这种情况。用于由客户端105访问区块头列表的方法在本领域中是已知的。

客户端105还可以知道当前最长的工作证明链。在这种情况下，在步骤8中检查与客户端105获取的证明对应的默克尔根。

如果客户端105验证默克尔证明，即如果从事务数据和哈希列表计算的所计算默克尔证明与目标事务的可信默克尔证明相同，则验证数据存在于区块链上。

然后，在步骤9中，客户端105将数据显示给用户103。客户端105还向用户103提供指示数据已通过验证的显示消息。

如果数据未通过验证，则客户端105向用户103显示指示该结果的消息。事务数据仍然可以与该失败消息一起显示。或者，如果事务数据未通过验证，则可以不向用户103显示该事务数据。

应当理解的是，上述方法的步骤可以按照不同的顺序执行。例如，请求默克尔证明的步骤可以在从区块链网络请求数据的步骤之前或同时执行。可以在单独的步骤中将事务数据和默克尔证明从解析者发送到客户端，例如，一旦解析者已经接收到相应信息，就可以发送数据和默克尔证明。

在一些实施例中，用户向客户端提供事务数据。例如，用户可以通过网页与BURI一起访问事务数据，并将BURI和事务数据两者提供到客户端。在这种情况下，客户端不需要向区块链网络请求数据来计算所计算的默克尔根。

在用户向客户端提供事务数据的情况下，解析者仍然可以从区块链网络请求事务数据并将其发送到客户端。然后，客户端可以对事务数据执行附加检查，以确认用户发送的事务数据是存储在区块链上的事务数据。

替代地或附加地，客户端可以对从客户端或解析者接收的事务数据进行哈希处理，以生成预期目标事务标识符。这可以与BURI的目标TxID进行比较，以进一步验证事务数据。

在一些实施例中，事务数据不用于计算所计算的默克尔根。相反，使用在BURI中提供的TxID，因为TxID是事务数据的哈希。

应当注意的是，如果通过网页等向用户提供事务数据，并且BURI包括默克尔索引，则不需要访问目标区块的有效载荷(即，事务)。

如果BURI包括默克尔证明，则客户端105不需要经由解析者1102向证明提供者1104请求默克尔证明。相反，使用在BURI中提供的默克尔证明来验证数据。

因此，在一些实施例中，可能不需要使用解析者1102来验证数据，因为默克尔证明和数据可以通过其他方式提供给客户端105。

在一些实施例中，可以从区块链网络106或证明提供者1104获取区块头和/或默克尔根。该默克尔根不用于验证默克尔证明，但是可以用于进一步验证，如下所述。

尽管解析者1102在图11中示为单独的实体，但是它可以是能够接受数据请求(步骤2)并实现对数据的请求和默克尔证明(分别是步骤3和步骤5)的任何服务。例如，解析者1102可以是在客户端的Web浏览器中或由搜索引擎运行的代码。解析者1102的功能可以由客户端105执行。

在图11的系统中，客户端105不信任从区块链网络106获取的数据的完整性，因此需要显式地验证数据完整性。

事务数据可以从区块链网络1106获取，这意味着可以从网络上的任何节点或对等方获取。用户/客户端本身不信任该数据的完整性，因为他们不信任数据的来源；只有当他们可以验证数据的默克尔证明(步骤8)，并且在提供给客户端105的最长工作证明链上的区块头中找到对应的默克尔根时，他们才信任该数据的完整性。

上面提到的显式完整性检查的好处在于，不需要信任事务数据的来源，使得可以从任何来源获取该数据。

在图11的系统中，既不需要信任解析者1102，也不需要信任来自区块链网络106上的对等方的数据来源，只要客户端/用户确信他们具有正确的区块头列表即可。

为了消除对提供默克尔证明的第三方的依赖，并因此提高用户对验证结果的信任，可以在BURI中包括哈希的有序列表。

图8示出了在BURI包括哈希的有序列表的情况下使用BURI来验证目标事务的存在而执行的示例性方法800。

在S802中，用户获取BURI。BURI可以通过引用事务908在链上获取，也可以链下(例如，从网页)获取。

在步骤S804中，从BURI中提取用于定位目标事务的位置信息。该位置信息包括TxID。该位置信息还可以包括事务索引和/或区块标识符。

在步骤S804中提取的位置信息用于在区块链上定位目标事务，以在步骤S810中获取目标数据，并在步骤S812中获取区块头。

在步骤S806中，从BURI中提取默克尔证明。在该示例中，默克尔证明包括事务索引和哈希的有序列表。

在步骤S808中，计算所计算的默克尔根。使用在步骤S810中获取的目标事务的目标数据和BURI中的哈希列表来计算所计算的默克尔根。对目标数据进行哈希处理，以找到与目标事务对应的叶节点的哈希。然后，如结合图6所述，沿着默克尔树的路径按顺序对哈希进行级联和哈希处理，从而计算所计算的默克尔证明。或者，可以使用作为目标事务的哈希的TxID来代替在步骤S808中计算的目标数据的哈希。

在步骤S814中，将所计算的默克尔根与所获取的默克尔根进行比较。所获取的默克尔根是由客户端105获取的目标区块的区块头中规定的目标区块的默克尔根。在步骤S814中使用的所获取的默克尔根是客户端105已知的默克尔根，或者是客户端105通过其作为SPV客户端的功能等可以访问的默克尔根。也就是说，在步骤S814的比较中不使用在步骤S812中获取的区块头。例如，客户端105可以访问区块头列表，并且使用BURI的至少一部分来选择从中提取默克尔的对应区块头。所使用的BURI的一部分可以是事务标识部分或区块标识部分。

在步骤S816中，确定这两个根是否相同。如果根相同，则在步骤S818中，验证目标数据是否存在于区块链上，因为用于计算所计算的默克尔根的哈希对应于存储在区块链上的区块。

然而，在步骤S820中，如果发现根不匹配，则目标数据不存在于区块链上，因此不会被验证为存在。

在方法800中，在链下执行提取默克尔证明(S806)、计算预期根(S808)、将根进行比较(S816)和验证/不验证数据存在于区块链上(S816、S818和S820)的步骤，同时在链上执行获取目标区块(S810)和获取区块头(S812)的步骤。

在一些实施例中，区块头可以从链下来源获取。例如，如上所述，区块头可以从默克尔证明服务器获取。

方法800的链下步骤可以由与用户103相关联的客户端105执行。客户端可以被配置为执行关于事务数据的进一步检查，如下所述。

方法800还可以包括向用户提供关于指示目标数据是否被验证为存在于区块链上的步骤。只有在目标数据被验证为存在于区块链上的情况下，才可以将目标数据呈现给用户。

在一些实施例中，不是获取整个区块头，而是仅获取可信默克尔证明。在其他实施例中，不会直接从区块链或区块链网络获取区块头或默克尔根。

在一些实施例中，在步骤S810中，不从区块链获取目标数据。相反，可以通过网页等将目标数据提供给用户。所提供的事务数据可以用于计算所计算的默克尔根。可以对该事务数据进行哈希处理，并将其与BURI的TxID进行比较，以进一步验证数据。

在一些实施例中，从区块链获取目标数据，并将其与提供给用户的事务数据进行比较。如果数据不匹配，则可以通知用户所提供的数据未通过验证和/或可以阻止向用户显示所提供的数据。

从BURI中提取位置信息和默克尔证明的步骤(步骤S806和步骤S808)包括解析BURI以标识其中的分隔符，以及提取通过分隔符隔开的BURI的部分。

本文中使用的术语“可信默克尔根”是指在比较步骤S814中使用的默克尔根，在本文中也称为“所获取的默克尔根”。在默克尔根已知为真的意义上，术语“可信”不要求根是可信的。相反，这是相对的信任级别，因此可信默克尔根比从默克尔证明计算的默克尔根更可信。

图7示出了用于实现图11的方法的示例性系统600。该系统包括默克尔证明实体(或默克尔证明服务器(MPS))601。应当注意的是，术语“默克尔证明实体”仅用作被配置为执行本文中所描述的动作的实体的便利标签。类似地，术语“默克尔证明服务器”不一定意味着所描述的动作由服务器(即，一个或更多个服务器单元)来执行，尽管这是一种可能的实现方式。

MPS 601被配置为证明事务存在于区块链150上。MPS 601被配置为存储一组事务标识符(TxID)。每个TxID唯一地识别相应事务。TxID是事务的哈希(例如，双重哈希)。MPS601可以存储在区块链150上发布的每个事务的相应TxID。或者，MPS 601可以仅存储部分而非全部已发布事务的相应TxID。例如，MPS 601可以存储具有某些共同之处的所有事务的相应TxID，例如来自特定区块的所有事务、在特定时间(采用UNIX时间或区块高度)之后发布的所有事务、来自特定区块链节点104发布的一个或多个区块的所有事务等。

MPS 601不是区块链节点104。也就是说，MPS 601不是挖矿节点或“矿工”。MPS 601可以由区块链节点操作或连接到区块链节点，但是MPS 601本身不执行以下操作：执行工作证明；构建区块；发布区块；强制遵循共识规则等。在一些示例中，MPS 601不核实事务。然而，不排除以下情况，即MPS 601可以核实事务，而不执行发布区块的操作。

此外，MPS 601不需要存储完整的区块链150，尽管并不排除这种情况。也就是说，MPS 601不需要存储全部已发布事务。在一些示例中，MPS 601不存储任何事务。或者，MPS601可以存储选定的少数已发布事务，例如一个或多个Coinbase事务。

MPS 601被配置为获取目标事务标识符。例如，系统600可以包括一个或多个请求方602。请求方602可以向MPS 601发送目标TxID，作为对目标事务的默克尔证明的请求的一部分。在一些示例中，仅将向MPS 601发送目标TxID视为对默克尔证明的请求。此外，还可以在请求中向MPS 601发送区块标识符和事务索引(如果提供给请求方602)。或者，请求方602可以向MPS 601发送完整的BURI。

MPS 601可以接收目标事务本身，而不是接收目标TxID。也就是说，请求方602可以向MPS 601发送目标事务。然后，MPS 601可以对目标事务进行哈希(例如，双重哈希)处理以获取目标TxID。也不排除以下情况，即MPS 601可以接收目标TxID和目标事务。在该示例中，MPS 601可以确认目标事务的(双重)哈希与目标TxID匹配；如果不匹配，则警告请求方602。

MPS 601还被配置为获取目标事务的“目标默克尔证明”，即用于证明目标事务存在于区块链上的默克尔证明。目标默克尔证明基于所存储的一组TxID中的一个或多个TxID，因为对应默克尔树的叶实际上是TxID。上面已经描述了默克尔证明。目标默克尔证明包括至少一组有序的哈希值。该组有序的哈希值中哈希值的数量基于默克尔树中叶的数量，即包含目标事务的区块151中事务的数量。默克尔证明还可以包括叶的索引，该索引指示该组有序的哈希值中的第一哈希值是应级联到目标TxID的左侧还是右侧。也就是说，BURI可以不包括目标事务索引；相反，该索引由MPS 601获取和提供。

MPS 601可以为每个事务(即，每个TxID)存储相应的默克尔证明。在该示例中，获取目标默克尔证明包括：从存储器中提取目标默克尔证明。例如，MPS 601可以预先计算每个事务的默克尔证明。当获取目标TxID时，MPS 601查找对应的默克尔证明(每个默克尔证明可以与存储器中的相应TxID相关联)。

该MPS可以预先计算并存储一个或多个默克尔树，而不是或不仅仅是存储每个事务或TxID的相应默克尔证明。每个默克尔树包括所存储的一组TxID的子集、一组内部哈希值(或内部节点)和默克尔根。在该示例中，获取目标默克尔证明包括：从包含目标TxID的默克尔树中提取默克尔证明(即，所需的哈希值)。

作为另一示例，MPS 601可以响应于获取目标TxID来计算目标默克尔证明。也就是说，MPS 601可以使用所存储的一组TxID中的一个或多个TxID来计算目标默克尔证明(例如，通过计算完整的默克尔树并提取所需的哈希值)。应当注意的是，该方法要求MPS 601将来自包括目标事务的区块151的所有TxID存储在存储器中。

目标默克尔证明可以包括对应的默克尔树的一个或多个内部哈希或内部节点。在这种情况下，如果BURI不包括二进制形式的事务索引，有用的是向请求方602提供此类内部哈希的索引，使得请求方知道是将先前哈希(例如，目标TxID)级联到内部哈希的左侧还是右侧。因此，当提取目标默克尔证明时，MPS 601使用叶哈希的索引(即，目标事务的TxID)来计算目标默克尔证明中内部哈希的索引。该MPS可能需要计算这些索引，以便从所存储的树中提取默克尔证据，即MPS具有所存储的树，并且叶索引允许其确定从树中挑选哪些内部节点以提取正确的默克尔证明。应当注意的是，至少在一些示例中，MPS 601只需要计算目标TxID的索引。该单个索引可能足以确定所需的内部哈希。

MPS 601还被配置为输出目标默克尔证明。例如，可以将目标默克尔证明直接传输给请求方602。或者，可以在网页等上发布目标默克尔证明。目标默克尔证明可以用作目标事务存在于区块链上的证明。

在一些示例中，MPS 601还从包含目标事务的区块151的区块头输出默克尔根。默克尔根可以作为包含默克尔根的区块头的一部分输出，或者单独输出，亦或与区块头的一个或多个其他数据字段(例如，先前区块哈希)组合输出。默克尔根可以直接输出给请求方602或以其他方式发布。

MPS 601可以基于在其中发布对应事务的区块来成子集存储TxID。也就是说，来自区块n的事务的TxID可以存储在一个子集中，来自区块n-1的事务的TxID可以存储在不同的子集中，以此类推。每个子集中的TxID可以存储在有序列表中，其中TxID的顺序与给定区块中对应事务的顺序匹配。

区块链150的每个区块151包括相应的区块头。MPS 601可以存储一个或多个区块头。例如，MPS 601可以存储每个所公布的区块151的区块头。区块头可以存储在有序列表中。区报头的顺序可以与区块链150中的对应区块151的顺序匹配。在一些示例中，来自给定区块151的TxID可以与该区块151的区块头相关联地存储。

出于安全原因，应存储区块头的所有字段，以便能够复制区块头的值并核实工作证明。然而，不排除以下情况，即在一些示例中，MPS 601可以仅存储区块头的一个或多个而非全部数据字段，而不是存储完整的区块头。例如，MPS 601可以仅存储包含在区块头内的默克尔根。或者，MPS 601可以存储包含在区块头内的默克尔根和先前哈希(存储在区块头n中的先前哈希等于第n-1个区块头)。

MPS 601可以从区块链网络106(例如，从区块链节点)获取部分或全部所存储的TxID。可以从单个区块链节点104获取全部TxID。或者，可以从多个节点获取TxID，例如，从一个区块链节点获取一些，从其他区块链节点获取一些，以此类推。这同样适用于区块头。也就是说，可以从单个区块链节点104或从多个节点104获取部分或全部所存储的区块头(或仅获取所存储的默克尔根和/或先前区块哈希)。在一些示例中，MPS 601可以从来自相同区块链节点104的给定区块(以及可选地，该区块的区块头)获取全部事务的TxID。

在一些示例中，MPS 601可以通过从多个节点104获取相同的TxID和/或区块头来验证部分或全部所获取的TxID和/或区块头。

附加地或替代地，如图7所示，可以从一个或多个简单支付验证(SPV)客户端604获取区块头中的部分或全部区块头。SPV客户端是一种客户端应用程序，其被配置为：存储区块链的一个、部分或全部区块头；以及执行SPV方法。例如，有关详细信息，请参阅https://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verification。例如，MPS 601可以操作SPV客户端，或者具有与由不同实体(不一定是不同的MPS)操作的SPV客户端的连接。

如上所述，MPS 601可以存储一个或多个事务，即原始事务数据。例如，MPS 601可以为每个区块存储一个事务。MPS 601可以存储每个区块的Coinbase事务(请记住，每个区块只有一个Coinbase事务)。然而，不排除以下情况，即MPS 601可以存储除Coinbase事务之外的事务，或者MPS 601可以存储一些区块的相应Coinbase事务以及其他区块的不同事务。

给定区块的所存储的事务将称为“第一事务”。这并不一定意味着该事务最先出现在区块中，尽管Coinbase事务确实如此。在这些示例中，MPS 601可以获取在与目标事务相同的区块中发布的第一事务的默克尔证明。然后，例如，MPS 601可以将第一事务的默克尔证明以及第一事务本身一起输出给请求方602。这可以供请求方602用于验证目标默克尔证明是否具有正确的长度。例如，如果第一事务的默克尔证明的长度为十(即，十个哈希值)，则目标默克尔证明的长度也应当为十。

MPS 601采用计算装置的形式(例如，与图1所示类似)，该计算装置包括一个或多个用户终端，例如台式电脑、笔记本电脑、平板电脑、智能电话、智能手表等可穿戴智能设备或汽车等车辆的板载电脑等。附加地或替代地，该计算装置可以包括服务器。本文中的服务器是指可以包括位于一个或多个地理位置处的一个或多个物理服务器单元的逻辑实体。在需要的情况下，分布式或“云”计算技术本身在本领域中是已知的。服务器的一个或多个用户终端和/或一个或多个服务器单元可以经由分组交换网络彼此连接，例如，该分组交换网络可以包括互联网等广域网、3GPP网络等移动蜂窝网络、以太网等有线局域网(LAN)，或者Wi-Fi、线程或6LoWPAN网络等无线LAN。该计算装置包括控制器和接口。该控制器可操作地耦合到接口204。该控制器被配置为执行归因于该MPS的动作。该接口被配置为发送和接收数据，例如TxID、区块头、默克尔证明等。

控制器和接口中的每一个可以软件代码的形式实现，该软件代码包含在计算机可读存储器上并在处理装置上运行，该处理装置包括CPU等一个或多个处理器、GPU等工作加速器协处理器和/或在位于一个或多个地理位置处的一个或多个计算机终端或单元上实现的其他专用处理器。在其上存储代码的存储器可以包括采用一种或多种存储介质(例如，电子或磁介质)的一个或多个存储器设备，该存储器设备也在位于一个或多个地理位置处的一个或多个计算机终端或单元上实现。在实施例中，控制器和/或接口可以在服务器上实现。或者，这些组件中的一个或两个的相应实例可以在一个或多个用户终端中的一个、部分或全部用户终端中的每个用户终端上部分地或甚至全部地实现。在其他示例中，上述组件的功能可以在用户终端和服务器的任意组合之间拆分。还应当注意的是，在需要的情况下，分布式计算技术本身在本领域中是已知的。也不排除以下情况，即这些组件中的一个或多个组件可以在专用硬件中实现。

现在将描述请求方602。请求方602被配置为向MPS 601发送对默克尔证明的请求。请求方602可以向MPS 601发送目标TxID和/或目标事务。作为响应，该请求方被配置为接收或以其他方式获取目标默克尔证明。如前面描述的，请求方602可以使用目标默克尔证明来证明目标事务存在于区块链上。

在一些示例中，请求方602可以使用目标默克尔证明来证明存在一个或多个父事务。在这种情况下，如果目标事务是子事务，则目标默克尔证明可证明每个父事务已发布在区块链150上(如果每个父事务均未发布在区块链150上，则子事务不会发布在区块链150上)。通常，事务链中最近发布的事务的默克尔证明可证明所有其他事务存在于该链中。

请求方602可以是(或操作)SPV客户端。也就是说，SPV客户端(例如，由花费者操作)可以使用目标默克尔证明来执行SPV方法。在这种情况下，目标事务可以包括UTXO，其锁定到花费者，并且由包括锁定到接收者的UTXO的花费事务来引用。

请求方602可以是(或操作)钱包应用程序。该钱包应用程序可以存储目标事务。在在线模式或状态(即，连接到MPS 601)下，该钱包应用程序可以获取目标事务的目标默克尔证明。然后，该钱包应用程序可以在离线模式或状态(即，未连接到MPS 601)下运行，该钱包应用程序可以向请求方602提供目标事务和目标默克尔证明，作为目标事务存在于区块链上的证明。

请求方602可以采用爱丽丝103a或鲍勃103b的形式。

通用MPS

通用MPS 601充当专用服务器以向接收方(例如，用户)提供默克尔证明。也就是说，通用MPS 601是服务器，如果给定事务发布在区块链上，则该服务器提供该事务或事务ID的默克尔证明。通用MPS 601不存储完整的事务数据。这可以视为对存储默克尔树的区块链网络中SPV客户端的补充。更准确地说，通用MPS具有以下存储要求列表：

1.表示具有最多工作证明的链的区块头的有序列表(可选要求)

2.每个区块头的事务ID的有序列表(核心要求)

3.为每个区块头预先计算的默克尔树，其中默克尔根与区块头中指定的一个默克尔根匹配(可选要求)

4.每个区块中Coinbase事务的原始数据或区块中每个区块头的事务的任何原始数据(可选要求)

第一项要求旨在确保通用MPS 601的数据完整性。区块头中的默克尔根可以用作对事务ID列表的完整性检查。也就是说，当形成默克尔树的叶时，区块头可以用于检查来自给定区块的TxID在区块头中给出默克尔根。例如，如果TxID可信，或者如果通用MPS 601可安全访问可信SPV客户端或任何实体，该实体受信任地以最多工作证明来存储链的区块头，则可以摒弃第一项要求。

第二项要求是核心的，其旨在按照默克尔叶在默克尔树中出现的顺序来提供默克尔叶，以便可以重建默克尔树。应当注意的是，Coinbase事务ID始终是列表中的第一叶或第一哈希。叶的顺序由构建获胜区块的区块链节点确定。在比特币SV中，该顺序应反映拓扑顺序和先见规则。

第三项要求提供在计算与存储之间进行权衡的选项。图12示出了存储要求，其中实线框是必需的(在一些示例中)，虚线框是可选的。应当注意的是，区块头包含所示区块头的附加字段，但是对于默克尔证明，通常仅需根哈希。可以使用先前哈希为根哈希建立索引。关键在于，通用MPS 601不需要存储默克尔树的内部节点。应当注意的是，为了证明指向区块头中工作证明的链接，需要区块头的所有字段。挑选出“先前哈希”字段来命名的原因在于，其说明了区块头之间的链关系。挑选出“根哈希”字段的原因在于，其说明了指向默克尔树的链接。然而，只有在提供所有区块头组件的情况下，才能核实指向工作证明的链接。

第四项要求旨在提供默克尔树的深度证明。这是可由通用MPS 601向其用户提供的额外服务。由于向任何验证者呈现事务的原始数据，任何验证者都可以确信其默克尔证明中的第一哈希实际上是叶，因为对于并非充当叶的给定哈希值，构建有意义的事务在计算上是不可行的。此外，由于默克尔证明的长度意味着默克尔树的深度，因此来自同一树的所有默克尔证明具有相同的长度。当用户不拥有相关事务的原始数据时，该服务尤其有用。

给定事务ID，例如TxID

当新区块发布后，通用MPS 601会获取以下信息：

1.新区块头；

2.新区块的事务ID的有序列表；以及

3.原始Coinbase事务。

可选地，通用MPS 601可以检查以下各项：

1.新区块头具有有效的工作证明；

2.根据事务ID计算的默克尔根等于区块头中的默克尔根；以及

3.Coinbase事务的哈希等于叶中的第一元素。

应当注意的是，服务器不需要获取原始事务或对事务运行签名验证。

下面描述了提供默克尔树的深度是一项有价值服务的原因。SPV客户端将事务ID和默克尔证明作为输入，并且如果默克尔根与区块头中的一个区块头中的默克尔根匹配，则输出True，否则输出False。然而，由于缺少必要信息，这种验证不会检查默克尔证明的长度是否与默克尔树的长度匹配。在某些情况下，攻击者可以提交缩短的默克尔证明，以试图证明存在并不存在的事务ID。这种缩短的默克尔证明可以通过移除叶或后续全部哈希来获取。

作为默克尔证明提供者的通用MPS 601最适合提供验证默克尔证明的长度所需的信息。通用MPS 601提供Coinbase事务的原始数据和其默克尔证明，而不是显式地提供默克尔树的深度。伪造原始事务数据和默克尔证明在计算上是不可行的。因此，这用作默克尔树的深度证明。了解树的深度可以减少上述关键漏洞。应当注意的是，如果SPV提供有相关事务的原始数据和默克尔证明，则它是安全的，不会遭受该漏洞的攻击。如果SPV不具有相关事务的原始数据，可以使用Coinbase事务的原始数据和其默克尔证明，来建立默克尔树的深度或相对于该默克尔树的默克尔证明的正确长度。

理论上，该漏洞还可以用于欺骗通用MPS 601接受叶或任何后续层级被完全移除的默克尔树。然而，通用MPS 601可以连接到多个区块链节点104，以确保所接收信息的一致性和正确性。此外，通用MPS 601还可以选择下载Coinbase事务的原始数据，以验证新区块的默克尔树的深度。

通用MPS 601有时可能不得不处理竞争区块、重组和孤立区块，在同一时间发现同一区块高度的多个区块时会发生这种情况。幸运的是，这种情况不会发生，除非在最近的区块头中，但是这种情况很少发生。区块链150通常在一个或两个区块之后收敛到竞争链中的一个竞争链。因此，当通用MPS 601在同一高度接收多个区块151后，它将保留所有此类区块，直到区块链网络收敛到具有最多工作证明的链。

存储空间节省

目前，BSV全球分类账中共有约5亿个事务(BTC的订单数量类似)。所有TxID需要约15GB的存储空间。BSV区块链本身当前的存储空间为224GB。通用MPS 601将需要存储占整个区块链6.7％的事务。此外，存储空间取决于事务的数量，而不是事务的大小。在区块高度为638009且区块头的大小为80字节时，区块头需要总共49MB的存储空间，每年增加4MB。

如果通用MPS 601要存储默克尔树的预先计算部分以缩短生成默克尔证明所花费的时间：根节点之后的第一层将由2个节点组成，每棵树需要2x32字节。因此，当MPS生成任何Tx的默克尔分支时，级联到区块头的80字节的64字节将使MPS少执行一次哈希计算，即MPS针对每个区块头使用144字节，而不是80字节。默克尔树的第二层由4个节点组成，即每个区块头272个字节，以此类推。第十层将需要每个区块头65552个字节，并将所需存储空间增加到总共39GB。这应包括15GB的TxID，并假设每个区块具有1024个事务。

仅限TxID MPS(TxID-only MPS)的局限性

所述通用MPS 601具有一些局限性。给定未发布事务，例如TxID

应当注意的是，如果通用MPS 601仅存储事务ID和对应的索引，则通用MPS 601无法验证或证明索引未被篡改。通用MPS 601需要完整的原始数据，以便验证或证明索引的完整性。

此外，它将无法向用户提供对事务内特定数据元素的搜索，例如锁定脚本或标志。因此，它将无法支持使用布隆过滤器等的用户，因为他们通常基于事务中包括的锁定脚本和公钥来过滤事务。

这导致需要一种能够提供更细粒度信息的MPS，其称为完整性MPS。完整性MPS将存储一些事务的原始数据。应当注意的是，如果用户给出完整的事务，则可以使用通用MPS601来证明所发布事务的完整性。可以使用完整性MPS，通过存储全部相关事务来证明从所发布事务中提取的一些数据的完整性。用户不需要提供完整的事务。

完整性MPS

完整性MPS存储一组相关事务的原始事务和其对应的默克尔证明。对于关于该组中事务的查询，该服务器可以提供原始事务及其默克尔证明作为其完整性的证明。该服务器还允许搜索部分事务或事务内容中的数据元素。可以基于数据应用程序(例如，WeatherSV、Tokenized、Metanet或任何其他数据协议)甚至数据字符串(例如，锁定脚本、公钥、输出点等)来确定相关事务。因此，可以存在仅用于Weather SV应用程序的完整性MPS，其被配置为存储仅携带Weather SV的事务。

一组相关原始事务被传递到完整性MPS，并且在发布的情况下会持续存在于服务器上。完整性MPS可以视为网关，或者可以访问用于特定应用程序事务的网关。当区块链系统扩展到百万兆字节区块时，这将是维护完整性MPS的最高效方式。对于其他情况，例如完全去中心化的对等数据应用程序，必须采用下载完整的事务区块的机制，并修剪不相关事务，或者使用布隆过滤器过滤比特币改进提案37(BIP37)中的事务。

在操作过程中

在一些实施例中，在默克尔树中维护相关原始事务及其默克尔证明的完整性MPS执行以下步骤：

步骤1：获取相关原始事务。

步骤2：对原始事务进行哈希处理以获取事务ID。

步骤3：查询通用MPS 601以获取默克尔证明。

步骤4：如果事务未发布在区块中，请等待10分钟，然后重试。

可以用下载和修剪机制来代替对步骤3中的通用MPS 601的依赖，尽管这会导致效率低下。可以在预定义时间限制之后丢弃步骤4中的未发布事务，以避免拥塞。该限制可以根据应用的不同而变化。

可以通过提供事务的默克尔证明来证明该事务要发布在区块链150上。或者，可以通过该事务的一个已花费输出来证明这一点。当事务tx

事实上，可以通过以下声明来概括该观察结果，即如果存在事务链，则该链中最后一个事务的默克尔证明和所有事务的原始数据可以证明所有事务均存在于该链中。

这允许删除事务的默克尔证明，并将其替换为该事务的任何子项的默克尔证明。这适用于以下情况：

1.区块大小–子事务发布在远远小于父事务的区块中，在这种情况下，与父事务的默克尔证明的大小相比，子事务及其默克尔证明的总大小更小；或

2.多个输入–子事务具有来自不同事务的多个输入，在这种情况下，与其父事务的所有默克尔证明的总大小相比，子事务及其默克尔明的总大小更小。

例如，对于特定应用程序，所有事务可以具有专用的默克尔证明输出。有时，可以收集并在一个子事务中花费这些输出。子事务及其默克尔证明将能够证明其所有父事务的完整性和存在性。因此，不需要存储任何父事务的默克尔证明。

观察结果可以汇总在下表中，其中列出了可从所提供数据中得出的证明。

该表显示，如果满足以下条件，则证明存在输出：

1.提供原始事务且该事务存在；或

2.该输出或更高的索引输出用于支付现有事务。

结论

一旦给出本文的公开内容，所公开技术的其它变体或用例对于本领域技术人员可能变得显而易见。本公开的范围不受所描述的实施例限制，而仅受随附权利要求限制。

例如，上面的一些实施例已经根据比特币网络106、比特币区块链150和比特币节点104进行了描述。然而，应当理解的是，比特币区块链是区块链150的一个特定示例，并且上述描述通常可以应用于任何区块链。也就是说，本发明决不限于比特币区块链。更一般地，以上对比特币网络106、比特币区块链150和比特币节点104的任何引用可以分别参考区块链网络106、区块链150和区块链节点104来替换。区块链、区块链网络和/或区块链节点可以共享如上所述的比特币区块链150、比特币网络106和比特币节点104的部分或全部所述特性。

在本发明的优选实施例中，区块链网络106是比特币网络，并且比特币节点104至少执行对区块链150的区块151进行创建、发布、传播和存储中的所有所述功能。不排除可能存在仅执行这些功能中的一个或部分功能但不是全部功能的其它网络实体(或网络元件)。也就是说，网络实体可以执行传播和/或存储区块的功能，而不创建和发布区块(请记住，这些实体不被认为是优选的比特币网络106的节点)。

在本发明的另一些实施例中，区块链网络106可以不是比特币网络。在这些实施例中，不排除节点可以执行对区块链150的区块151进行创建、发布、传播和存储中的至少一个或部分功能但不是所有功能。例如，在这些其它区块链网络上，“节点”可用于指被配置为创建和发布区块151但不存储和/或传播这些区块151到其它节点的网络实体。

甚至更通俗地说，上面对术语“比特币节点”104的任何引用可以用术语“网络实体”或“网络元件”代替，其中这样的实体/元件被配置为执行对区块进行创建、发布、传播和存储中的一些或全部角色。这种网络实体/元件的功能可以在硬件中实现，方法与上面参照区块链节点104所述的方式相同。

应当理解的是，上述实施例仅通过示例的方式进行描述。更通俗地说，可根据下述任何一个或多个语句提供一种方法、装置或程序。

语句1.一种计算机实现的方法，用于验证被标识的事务存储在区块链中，所述方法包括：获取区块链统一资源指示符(blockchain uniform resource indicator，BURI)字符串；解析所述BURI字符串以标识其中的分隔符字符，并由此提取一个或多个默克尔证明部分以及事务标识符部分(transaction identifier portion)，其通过所述分隔符字符隔开，所述一个或多个默克尔证明部分用于验证所述标识的事务属于所标识的区块；以及，使用所述BURI的至少一部分来获取默克尔根哈希，以及，使用所述一个或多个默克尔证明部分来确定所述事务标识符部分相对于所述默克尔根哈希是否有效，从而使用所述BURI字符串验证所述标识的事务，而无需访问所述标识的区块的有效载荷。

语句2.根据语句1所述的方法，其中在存储在所述区块链中的后续事务中接收或从中提取所述BURI字符串。

语句3.根据语句1或2所述的方法，其中所述一个或多个默克尔证明部分包括所述标识的事务的默克尔索引。

语句4.根据语句3所述的方法，其中所述一个或多个默克尔证明部分还包括确定所述标识的事务是否由所述默克尔根哈希验证所需的默克尔证明哈希的子集。

语句5.根据语句3所述的方法，其中所述方法还包括：通过实现以下步骤，从第三方计算设备，获取确定所述标识的事务是否由所述默克尔根哈希验证所需的默克尔证明哈希的子集：向所述第三方计算设备，发送所述默克尔索引和所述事务标识符部分；以及，从所述第三方计算设备，接收确定所述标识的事务是否由所述默克尔根哈希验证所需的默克尔证明哈希的所述子集。

语句6.根据语句5所述的方法，其中所述第三方计算设备是默克尔证明实体，所述默克尔证明实体被配置为存储相应区块链事务的相应区块链事务标识符中的事务标识符集合，但不向区块链网络发布新的区块链区块。

语句7.根据语句3或其任何从属语句所述的方法，其中所述默克尔索引采用二进制形式。

语句8.根据前述任一项语句所述的方法，其中所述的解析所述BURI字符串以标识其中的分隔符字符的步骤由此进一步提取区块标识部分(block identity portion)。

语句9.一种引用区块链事务(referencing blockchain transaction)，在所述引用区块链事务的第一索引处的输出处，所述引用区块链事务包括区块链统一资源指示符BURI字符串，所述BURI字符串用于引用先前存储在区块链上的所标识的区块中的所标识的事务，所述BURI包括事务标识符部分和另一部分，所述事务标识符部分和所述另一部分通过至少一个分隔符字符分隔，所述另一部分是用于进一步定义(define)所述标识的事务的分层组件。

语句10.根据语句9所述的引用区块链事务，其中所述另一部分包括一个或多个默克尔证明部分，所述一个或多个默克尔证明部分通过至少一个分隔符字符与所述事务标识符部分隔开。

语句11.根据语句10所述的引用区块链事务，其中所述一个或多个默克尔证明部分包括所述标识的区块中的所述标识的事务的默克尔索引。

语句12.根据语句11所述的引用区块链事务，其中所述一个或多个默克尔证明部分还包括确定所述标识的事务是否由所述标识的区块的默克尔根哈希验证所需的默克尔证明哈希的子集。

语句13.根据语句11或12所述的引用区块链事务，其中所述默克尔索引采用二进制形式。

语句14.根据语句12和13所述的引用区块链事务，其中所述默克尔索引的每个二进制位前置于哈希的有序列表中的对应哈希。

语句15.根据语句9至14中任一项所述的引用区块链事务，其中所述区块标识部分(block identity portion)是所述标识的区块的区块编号。

语句16.根据语句9至14中任一项所述的引用区块链事务，其中所述区块标识部分(block identity portion)是所述标识的区块的区块头哈希。

语句17.根据语句10至16中任一项所述的引用区块链事务，其中所述BURI还包括区块标识部分(block identifying portion)，所述区块标识部分被通过至少一个分隔符字符与所述事务标识符部分和所述一个或多个默克尔证明部分隔开。

语句18.根据语句9至17中任一项所述的引用区块链事务，其中所述BURI还包括片段部分(fragment portion)，所述片段部分用于标识所述标识的事务的片段。

语句19.一种计算机实现的方法，用于将存储在所标识的事务中的数据发送给验证实体，所述方法包括：生成区块链统一资源指示符BURI字符串，所述BURI字符串包括一个或多个默克尔证明部分以及事务标识符部分，其通过分隔符字符隔开，所述一个或多个默克尔证明部分用于验证所述标识的事务属于所标识的区块；以及，使所述BURI能够被所述验证实体利用以用于访问所述数据。

语句20.根据语句19所述的计算机实现的方法，其中使所述BURI能够被利用的步骤包括：将所述BURI存储在区块链的事务中。

语句21.根据语句19或20所述的计算机实现的方法，其中所述一个或多个默克尔证明部分包括所述标识的事务的默克尔索引。

语句22.根据语句21所述的计算机实现的方法，其中所述一个或多个默克尔证明部分还包括确定所述标识的事务是否由所述默克尔根哈希验证所需的默克尔证明哈希的子集。

语句23.一种计算机设备，所述计算机设备包括：存储器，所述存储器包括一个或多个存储器单元；以及，处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据语句1至8中任一项或语句19至22中任一项所述的方法。

语句24.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据语句1至8中任一项或语句19至22中任一项所述的方法。

附件A

下表总结了现有URI方案标准与本文中提出的BURI方案之间的相似性。

本文中公开的BURI的第一元素是区块标识符，其映射到典型的基于互联网的URI中的“权限”。这里的类比可以与比特币节点网络内的代理进行，并且可以与比特币节点网络交互，这些代理可以提供关于区块头的当前最长链的权威事实来源，该权威事实来源可以用于生成和验证BURI的正确性。

例如，BURI的区块标识符组件可以与该信息的一个或多个特定可信提供者(例如，根据矿工ID标准可标识的矿工)相关联。特定浏览器可以被设计成查询多个此类矿工，以根据SPV范式保持规范区块头的最新列表，这意味着比特币挖掘网络的很大一部分成为与BURI方案中的区块标识符相关联的“权限”。