CN119301899A - 用于提供对与区块链相关联的多个功能和应用程序的访问的计算机实现的方法和系统 - Google Patents

Abstract

提供了一种计算机实现的方法和系统，所述方法和系统能够实现设备与资产转移平台之间的交互。只有在许可证数据结构允许的情况下才会交互。

Description

用于提供对与区块链相关联的多个功能和应用程序的访问的 计算机实现的方法和系统

技术领域

本公开总体涉及用于实现与一个或多个客户端的分布式分类账(即，区块链)相关联的一项或多项服务的平台的方法和系统。具体而言，本公开涉及但不限于提供对与一个或多个客户端的区块链相关联的多个功能和应用程序的访问，例如实现数字或令牌化资产的转让。

背景技术

在本文中，“区块链”一词涵盖所有形式的基于计算机的电子分布式分类账。这些分类账包括基于共识的区块链和事务链技术、许可和非许可的分类账、共享分类账、公共和私有区块链，及其变体。应注意，本公开不限于与落入本公开范围内的任何类型的数字资产或数字资产的表示相关联的替代区块链实施方案和协议一起使用。在本文中，术语“客户端”、“实体”、“节点”、“用户”、“发送者”、“接收者”、“支付者”和“收受者”可以指基于计算或处理器的资源。术语“数字资产”可以指任何可转让的资产，例如表示至少一部分财产的令牌、智能合约、执照(即，软件执照)或媒体内容的DRM合约等。应当理解的是，贯穿本文使用的术语“数字资产”表示可能与价值相关联的商品，该价值可以作为事务中的支付从一个实体转移到另一实体或提供给另一实体。

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

为了将事务写入区块链，必须对其进行“核实”。网络节点进行工作以确保每个事务均有效，而无效事务则被网络拒绝。安装在这些节点上的软件客户端通过执行其锁定脚本和解锁脚本对未花费事务(UTXO)执行该核实工作。如果锁定脚本和解锁脚本的执行评估为真(TRUE)，则该事务有效，然后将该事务写入区块链。因此，为了将事务写入区块链，该事务必须：i)由接收该事务的第一节点进行核实，如果该事务通过核实，则该节点将其中继到网络中的其他节点；ii)添加到新区块中；iii)进行挖掘，即添加到过去事务的公共分类账中。

应当理解的是，网络节点执行的工作的性质将取决于用于维护区块链的共识机制的类型。应当理解的是，可以使用其他共识机制，诸如权益证明(proof of stake，简称PoS)、委托权益证明(delegated proof of stake，简称DPoS)、容量证明(proof ofcapacity，简称PoC)、过去时间证明(proof of elapsed time，简称PoET)、权威证明(proofof authority，简称PoA)等。不同的共识机制在节点之间的挖掘分布方式上有所不同。应当理解的是，事务费用的处理是将数据提交到公共区块链的底层机制的一部分。

如先前所提及的，给定区块中的每个事务对区块链系统参与者之间的数字资产控制权转移进行编码。例如，数字资产可能与文档、图像、实体对象等的数字表示有关。在某些情况下，参与者之间的转账可能由不同于和/或独立于使用区块链维护事务分类账的实体的实体来处理。

一旦作为UTXO存储在区块链中，用户就可将相关联资源的控制权转移到与另一事务中的输入相关联的另一地址。这种转移通常使用数字钱包完成，但实际上并非如此。该数字钱包可以是：设备；物理介质；程序；诸如台式机、笔记本电脑或移动终端等计算设备上的应用程序；或与诸如互联网等网络上的域相关联的远程托管服务。数字钱包存储公钥和私钥，并可用于：跟踪与用户相关联的资源、令牌和资产等的所有权；接收或花费数字资产；转移可能与诸如执照、财产或其他类型的资源等数字资产相关的令牌。

数字企业家正在探索如何利用加密安全系统和可存储在区块链上的数据来实现新的系统。如果区块链可以用于自动任务和过程，则会非常有利。这种解决方案将能够发挥区块链的优势(例如，永久性防篡改事件记录、分布式处理等)，同时其应用将更加广泛。

当前研究的一个领域是使用区块链实现“智能合约”。这些是设计成自动执行机器可读合约或协议条款的计算机程序。与以自然语言编写的传统合约不同，智能合约是机器可执行程序，它包括能够处理输入以产生结果的规则，然后使得根据这些结果执行动作。

具体地，研究的一个领域是资产转移以及如何将其记录在区块链上，以确保转移从区块链的不可变性中受益。此外，除了记录此类转移的手段之外，还需要提供一种高效、安全的资产转移协议，以确保在底层区块链基础设施的支持下安全地记载和记录资产转移。

发明内容

贯穿本说明书使用的词语“包含”或变体(例如“包括”或“包含”)将被理解为意味着包含规定的元素、整数、步骤或者元素、整数或步骤的群组，但不排除任何其他元素、整数或步骤或者元素、整数或步骤群组。

在一些实施例中，提供了一种核实至少一个数据项的计算机实现的方法。所述数据项可以在资产转移事件期间提供。所述数据项可以是字符的字母数字序列。所述数据项可以是数字。所述数据项可以是随机生成或伪随机生成的字符串。所述方法通过处理资源来实现。所述处理资源可以是基于软件或基于硬件的资源。所述方法可以包括从计算设备接收请求数据。所述计算设备可以是移动计算设备。所述请求数据可以包括指令数据集，所述指令数据集包括与所述资产转移事件相关联的实体的标识符。所述请求数据还可以包括挑战数据结构。所述挑战数据结构可以包括所述至少一个数据项的第一数字标识符；和/或所述至少一个数据项的表示。

所述方法可以包括通过以下方式确定所述至少一个数据项的有效性：

-通过确定所述指令数据集中或与所述实体相关联的许可证数据结构中存在对应的凭证，确定所述至少一个数据项的所述表示与所述许可证数据结构中存储的数据项之间的一致性(concurrence)。对应的凭证可以是相同的数据项，也可以是与所述数据项等效的另一数据项。例如，所述对应的凭证可以是所述数据项的哈希。

所述方法可以包括针对相应指令数据集或许可证数据结构中的所述对应的凭证生成第二数字标识符。

所述方法可以包括生成包括以下各项的响应数据：所述对应的凭证的标识符；和/或所述第二数字标识符；和/或与所述第一数字标识符和所述第二数字标识符相关联的签名。

所述方法还可以包括将所述响应数据发送到所述计算设备。

在其他实施例中，提供了一种核实至少一个数据项的计算机实现的方法。所述数据项可以在资产转移事件期间提供。所述数据项可以是字符的字母数字序列。所述数据项可以是数字。所述数据项可以是随机生成或伪随机生成的字符串。所述方法通过第一处理资源来实现。所述第一处理资源可以是支付处理资源或支付处理资源的实例。所述方法可以包括生成请求数据。所述请求数据可以包括指令数据集，所述指令数据集包括与所述资产转移事件相关联的实体的标识符和/或挑战数据结构，其中所述挑战数据结构可以包括所述至少一个数据项的第一数字标识符；和/或所述至少一个数据项的表示。

所述方法还可以包括将所述请求数据发送到第二处理资源。所述第二处理资源可以是任何计算设备。所述第二处理资源可以是支付处理资源的实例。

所述方法还可以包括从所述第二处理资源接收响应数据。

所述方法还可以包括通过以下方式核实所述数据项：根据所述响应数据来确定存在第二数字标识符与所述第一数字标识符相结合的组合的签名。

在一些实施例中，提供了一种提供对资产转移处理平台的访问的计算机实现的方法。所述资产转移处理平台可以是根据支付处理协议来处理支付的资源。所述资产转移处理平台可以使用任何处理资源来实现。所述方法可以通过处理资源来实现，所述处理资源可以通过云或通过本地化硬件或软件资源的集合来实现。所述方法可以包括从与用户相关联的客户端设备接收消息。所述消息可以通过数据通信网络或另一种合适的手段(例如，通过应用程序编程接口(API)调用)来接收。所述客户端设备可以是任何计算设备。所述消息可以包括与所述消息相关联的消息类型的至少一个标识符。这可以使用API调用中的参数来实现。这也可以使用通过数据通信网络传输的消息中的参数来实现。所述消息还可以包括与在所述资产转移处理平台上注册的简档(profile)相关联的至少一个标识符，其中所述简档与所述资产转移处理平台提供的至少一个事件流(event stream)相关，其中所述至少一个事件流与至少一个资产类型相关联。

事件流可以包括区块链支持的仅附加日志，其中区块链事务中记录的数据被添加到按照时间排序的日志中。也就是说，事件流记录按照时间顺序(即，按照在区块链事务序列中发生的顺序)记录在区块链上的数据。事件流可以使用任何合适的数据结构来实现。事件流可以包括存储在序列中的一系列条目，其中所述序列中的每个条目在所述序列中通过单调增加的数字来引用。也就是说，事件流中的第一条目是条目1，第二条目是条目2，等等。利用区块链事务将数据写入事件流意味着可以保证所述事件流中的各个条目自写入以来没有被修改，先前连续条目之间没有插入任何条目，没有删除任何条目，也没有重新排序任何条目。未经授权的各方也不可能将事件附加到事件流中。所述消息还可以包括与请求相关的请求数据，所述请求与所述消息和所述简档相关联。所述请求数据可以包括与所述请求相关的指令数据。所述指令数据可以标识要用于处理所述请求的各方和/或许可证数据结构(permit data structure)。

简档可以对应于资产转移平台资源的分配，所述资产转移平台资源用于使用所述资产转移平台来处理资产转移。与简档相关联的资产转移平台的实例可以利用所述分配的资源来执行作为所述方法的一部分的处理步骤。

所述方法还可以包括根据所述接收的消息来确定与所述消息相关联的所述消息类型和在所述资产转移处理平台上注册的所述简档。确定所述消息类型可以包括处理所述请求以确定API调用中参数的存在或通过数据通信网络传输的消息中参数的存在。

所述方法还可以包括基于所述确定的消息类型来标识用于所述确定的消息类型的消息响应协议。所述消息响应协议定义了一系列标准，所述一系列标准用于确定待要提供给请求者的响应的响应类型或内容。所述消息响应协议可以定义请求的要求，以便对请求执行操作。所述消息响应协议可能需要访问许可证数据结构来确定数据项或加密签名的存在。

所述方法还可以包括标识所述简档的许可证数据结构，其中所述许可证数据结构至少提供标准，所述标准定义哪些用户可以使用所述确定的消息类型与所述简档交互。许可证数据结构可以包括公钥、使用与所述公钥对应的私钥生成的加密签名、至少一个数据项和许可证标识符。所述私钥和所述公钥可以以加密方式配对。所述私钥和所述公钥可以使用椭圆曲线数字签名算法(Elliptic Curve Digital Signature Algorithm,简称ECDSA)技术生成。所述数据项可以是字母数字序列或数字序列。

所述方法还可以包括处理所述请求数据以确定存在用于对所述请求数据进行签名的加密签名，并且基于确定存在用于对所述请求数据进行签名的加密签名，进一步处理所述请求数据以从所述请求数据中提取数据项。

所述方法还可以包括对所述提取的数据项应用所述标识的消息响应协议。所述应用可以包括使用所述请求数据中的所述数据项来确定是否可以响应于所述请求而采取动作。所述数据项可以包括各方的标识、许可证数据结构的标识、账户持有者和/或账户管理者的标识以及资产类型的标识。

账户持有者可以对应于与在所述资产转移平台上注册的所述简档相关联的用户。账户持有者可以对应于账户，所述账户可以是资金账户，所述资金账户包含在使用所述资产转移平台的事务中使用的货币供应量。替代地或附加地，所述账户可以对应于资产登记册，其中可以登记特定资产类型的资产的供应。此类账户可以是黄金账户。账户管理者可以对应于管理所述资金账户的银行或用于管理所述资产登记册的资产登记处。例如，在黄金账户的示例中，所述账户管理者可以是位于英国兰特里森特CF72 8YT的皇家铸币厂，所述资产登记处是个人在皇家铸币厂开设的账户。另一示例可以是在汇丰银行开设的资金账户，其中所述账户管理者将是汇丰银行，并且所述资产登记处将是其GBP(即，英镑)储蓄的资金账户。

所述方法还可以包括通过以下方式，基于所述消息响应协议、所述提取的数据项和所述许可证数据结构来生成对所述消息的响应：使用所述许可证数据结构来确定是否允许所述用户使用所述标识的消息类型与所述简档交互。

所述方法还可以包括使用所述消息响应协议来确定所述提取的数据项是否满足所述确定的消息类型的要求；以及基于所述确定的消息类型的所述要求被满足，通过与所述至少一个事件流交互来生成响应内容，所述至少一个事件流与所述简档相关联。

在其他实施例中，提供了一种使得用户能够更新与资产转移处理平台相关联的余额的计算机实现的方法。所述资产转移处理平台可以是根据支付处理协议来处理支付的资源。所述资产转移处理平台可以使用任何处理资源来实现。所述方法可以通过处理资源实现，所述处理资源可以使用软件或硬件或使用基于云的资源来实现。

所述方法还可以包括从与用户相关联的客户端设备接收消息。

所述消息还可以包括以下各项中的至少一项：与余额更新相关联的标识符；与在所述资产转移处理平台上注册的简档相关联的至少一个标识符。

所述方法还可以包括从所述接收的消息来确定在所述消息中标识的至少一个简档。简档可以对应于所述资产转移平台的实例。

所述方法还可以包括对所述提取的数据项应用更新请求协议(an updaterequest protocol)以确定是否可以更新所述余额。所述更新请求协议可以包括一系列标准，所述一系列标准用于确定是否可以更新余额，即是否可以从所述账户进行转账。从所述账户进行转账可以是将所述资产的一部分转移给另一方。

所述方法还可以包括通过以下方式，基于所述更新请求协议、所述提取的数据项和所述权限数据结构(permissions data structure)来生成对所述消息的响应：使用所述权限数据结构来确定所述用户是否拥有更新所述余额所需的加密权限；使用所述更新请求协议来确定是否可以进行所述更新；以及基于满足所述确定的消息类型的要求，通过更新所述余额并与所述至少一个事件流交互来生成响应内容，所述至少一个事件流与所述简档相关联。

与所述事件流交互可以包括以下各项中的至少一项：查看所述事件流；从所述事件流中检索数据；写入所述事件流；从所述事件流读取；或者将数据附加到所述事件流。与所述事件流进行任何交互都可以生成其自己的响应内容。所述响应内容可以是发送给请求与所述事件流交互的实体的消息，也可以是发送给与所述事件流相关联的实体的消息。

在一些实施例中，提供了一种使得能够访问所述资产转移处理平台的计算机实现的方法。所述方法可以通过处理资源来实现。所述方法可以包括初始化所述计算设备上的应用程序，所述应用程序被配置为生成消息。所述消息可以包括以下各项中的至少一项：与所述消息相关联的消息类型的至少一个标识符；与在所述资产转移处理平台上注册的简档相关联的至少一个标识符，其中所述简档与所述资产转移处理平台实现的至少一个事件流相关联，其中所述至少一个事件流与至少一个资产类型相关联；与请求相关的请求数据，所述请求与所述消息和所述简档相关联。

所述方法还可以包括从用户接收输入，所述输入标识要发送到所述资产转移处理平台的消息的消息类型。所述输入还可以标识在所述资产转移处理平台上注册的简档。所述输入还可以包括请求数据，所述请求数据包括要向所述资产转移处理平台提出的请求的内容。

所述方法还可以包括对所述请求数据应用加密签名以生成已签名请求数据。

所述方法还可以包括生成包括以下各项的消息：所述用户标识的所述消息类型的标识符；在所述资产转移处理平台上注册的所述简档的标识符；以及所述已签名请求数据。

所述方法还可以包括将所述消息发送到所述资产转移处理平台。

在其他实施例中，提供了一种资产转移处理平台。所述平台可以被配置为从与用户相关联的客户端设备接收消息，所述消息包括：

-与所述消息相关联的消息类型的至少一个标识符；

-与在所述资产转移处理平台上注册的简档相关联的至少一个标识符，其中所述简档与至少一个事件流相关联，所述至少一个事件流与所述资产转移处理平台相关联，其中所述至少一个事件流与至少一个资产类型相关联；以及

-与请求相关的请求数据，所述请求与所述消息和所述简档相关联。

所述平台可以被配置为根据所述接收的消息来确定与所述消息相关联的所述消息类型和在所述资产转移处理平台上注册的所述简档。

所述平台还可以被配置为基于所述确定的消息类型来标识用于所述确定的消息类型的消息响应协议。

所述平台还可以被配置为标识所述简档的许可证数据结构，其中所述许可证数据结构提供标准，所述标准定义哪些用户可以使用所述确定的消息类型与所述简档交互。

与所述简档的交互可以包括与所述事件流的任何交互，所述事件流与所述简档相关联。

所述平台可以被配置为处理所述请求数据以确定存在用于对所述请求数据进行签名的加密签名，并且基于确定存在用于对所述请求数据进行签名的加密签名，进一步处理所述请求数据以从所述请求数据中提取要用于使用所述标识的消息响应协议来确定响应的数据项。

所述平台可以被配置为对所述提取的数据项应用所述标识的消息响应协议。

所述平台还可以被配置为通过以下方式，基于所述消息响应协议、所述提取的数据项和所述权限数据结构来生成对所述消息的响应：使用所述许可证数据结构来确定所述用户是否具有使用所述标识的消息类型与所述简档交互所需的加密权限；使用所述消息响应协议来确定所述提取的数据项是否满足所述确定的消息类型的要求；以及基于所述确定的消息类型的所述要求，通过与所述至少一个事件流交互来生成响应内容，所述至少一个事件流与所述简档相关联。

在一些实施例中，提供了一种将条目附加到至少一个事件流的计算机实现的方法。事件流可以包括区块链支持的仅附加日志，其中区块链事务中记录的数据被添加到按照时间排序的日志中。也就是说，事件流按照时间顺序(即，在区块链上出现的顺序)记录在所述区块链上的数据。事件流可以使用任何合适的数据结构来实现。事件流可以包括存储在序列中的一系列条目，其中所述序列中的每个条目在所述序列中通过单调增加的数字来引用。也就是说，事件流中的第一条目是条目1，第二条目是条目2，等等。利用底层区块链意味着可以保证所述事件流中的各个条目自写入以来没有被修改，先前连续条目之间没有插入任何条目，没有删除任何条目，也没有重新排序任何条目。未经授权的各方也不可能将事件附加到事件流中。所述至少一个事件流可能属于与在资产转移平台上注册的用户相关联的资产账户。所述方法可以通过处理资源来实现。所述处理资源可以是硬件或软件实现的。

所述方法可以包括接收将条目附加到所述至少一个事件流的请求，所述条目包括指令数据和所述至少一个事件流的标识符。所述指令数据可以涉及通过所述处理资源或通过与所述处理资源通信的另一资源正在处理的事务。所述请求可以通过数据通信网络或通过应用程序编程接口(API)调用来接收。所述方法还可以包括从所述请求中检索所述至少一个事件流的所述标识符。所述标识符可以标识与所述至少一个事件流相关联的支付处理资源的实例。基于所述标识符，所述方法还可以包括访问所述至少一个事件流，以及获取与所述标识的至少一个事件流相关联的先前条目的日志。可以修剪所述先前条目的日志。所述修剪可能会删除早于指定到期日期的条目。所述方法还可以包括从所述请求中检索所述指令数据。所述指令数据可以包括可以通过所述处理资源进一步处理的多个数据项。

所述方法可以包括生成所述指令数据的唯一标识符。生成所述唯一标识符可以包括从所述指令数据中检索所述唯一标识符。此类唯一标识符可以是用于对所述指令数据进行签名的加密签名。生成所述唯一标识符可以包括处理所述指令数据以使用哈希算法等来生成所述标识符。

基于所述生成的唯一标识符，所述方法还可以包括确定与所述指令数据相同的数据是否存在于与所述标识的事件流相关联的所述先前条目的日志中。这可以包括在所述日志中搜索所述生成的唯一标识符，以确定其是否存在于所述先前条目的日志中。所述先前条目的日志可以是已经记录在所述事件流中的事务的数据库。

基于所述确定步骤的结果，所述方法还可以包括将条目附加到所述至少一个事件流，所述条目包括所述指令数据的所述唯一标识符；或者拒绝所述事件流的所述条目作为重复条目。

实施例可以全部或部分结合使用。

附图说明

现将仅通过举例的方式并参考附图对本公开的各方面和实施例进行说明，其中：

图1a示出了根据实施例的系统；

图1b示出了被配置为实现软件以便核实区块链事务的节点；

图1c示出了区块链网络；

图1d、图1e和图1f是分层许可证结构的示意图；

图2示出了根据实施例的支付处理资源的实例的建立；

图3是示出计算设备如何交互以从事件流中检索信息的流程图；

图4a和图4b是示出支付处理设备可以如何处理事务的流程图；

图5a和图5b是示出如何使用挑战数据结构和响应数据结构来核实数据项的流程图；

图6是示出事件流如何附加与事务相关的数据的流程图；

图7示出了会合事务；

图8示出了尘埃链；

图9示出了事务各方的事件流；

图10是示出如何调整支付处理资源的实例的设置的流程图；以及

图11是示出如何防止重复事务的流程图。

具体实施方式

现在，提供对本公开的方面和实施例的详细讨论，以向读者提供对本公开的全面和完整的理解。

从第一方面来看，存在一种核实至少一个数据项的计算机实现的方法。所述数据项可以在资产转移事件期间提供。所述数据项可以是字符的字母数字序列。所述数据项可以是数字。所述数据项可以是随机生成或伪随机生成的字符串。所述方法可以通过处理资源来实现，所述处理资源可以是任何计算设备。所述处理资源可以是支付处理资源。所述方法可以包括从计算设备接收请求数据。所述请求数据可以在应用程序编程接口(API)调用中传递。所述请求数据可以使用数据通信网络来传输。

所述请求数据可以包括指令数据集，所述指令数据集包括与所述资产转移事件相关联的实体的标识符。所述请求数据可以包括挑战数据结构，其中所述挑战数据结构可以包括所述至少一个数据项的第一数字标识符；和/或所述至少一个数据项的表示。所述表示可以是字母数字序列。所述表示可以是所述至少一个数据项的哈希。

所述方法还可以包括通过以下方式确定所述至少一个数据项的有效性：通过确定所述指令数据集中或与所述实体相关联的许可证数据结构中存在对应的凭证，确定所述至少一个数据项的所述表示与所述许可证数据结构中存储的数据项之间的一致性(concurrence)。所述对应的凭证可以是所述数据项的哈希。

所述方法还可以包括针对相应指令数据集或许可证数据结构中的所述对应的凭证生成第二数字标识符。

所述方法还可以包括生成包括以下各项的响应数据：所述对应的凭证的标识符；和/或所述第二数字标识符；和/或与所述第一数字标识符和所述第二数字标识符相关联的签名。

所述方法还可以包括将所述响应数据发送到所述计算设备。

根据第一方面的方法提供了一种安全地核实数据项的方法。所述数据项可以在资产转移事件(例如，资金转移)期间进行交换。所述数据项被安全地核实，因为只有在所述数据项可以基于所述许可证数据结构或另一数据结构进行核实的情况下才会提供所述签名。可以提供多个数据项，并且可以针对所述多个数据项中的每个数据项重复所述方法。所述响应数据结构的提供者需要提供与所述第一数字标识符和所述第二数字标识符相关联的所述签名，以表明他们已经对所述数据项进行核实。无法基于所述响应数据的所述提供者不拥有的许可证数据结构来提供所述签名，因为生成所述签名需要所有者的私钥。所述响应数据结构可以(例如，使用许可证标识符)标识令人满意的许可证数据结构，并且这使得一方能够确定可以用于检查所述签名的许可证数据结构，所述签名已经用于生成与所述标识符相关联的所述签名。所述签名可以是加密签名。所述挑战数据结构的提供者提供数字标识符(所述第二数字标识符)，使得所述响应数据结构的所述提供者无法仅仅从他们不拥有的许可证数据结构重放签名。所述响应数据结构的所述提供者提供数字标识符，使得所述挑战数据结构的所述提供者无法简单地“钓鱼式地”获取某个有用消息的签名。

所述第一数字标识符和所述第二数字标识符可以是针对相应数据项或响应数据生成的随机数。所述第一数字标识符和所述第二数字标识符可以是基于所述相应数据项或响应数据的随机数。所述第一数字标识符和所述第二数字标识符的组合可以是所述第一数字标识符和所述第二数字标识符的级联(concatenation)，其中所述第二数字标识符可以位于所述第一数字标识符和所述第二数字标识符的所述级联中的第一位置。

所述方法可以包括通过以下方式，确定所述数据项的所述表示与许可证数据结构中存储的数据项之间的一致性，所述许可证数据结构与所述实体相关联：

-从所述挑战数据结构获取所述数据项的所述表示；

-查询所述指令数据集以获取与所述数据项对应的凭证；以及

-基于所述查询，检索与所述凭证对应的标识符，或者查询与所述实体的所述标识符相关联的许可证数据结构以获取与所述数据项对应的凭证；以及

-基于对所述许可证数据结构的所述查询，检索对应于与所述数据项对应的所述凭证的标识符。所述方法还可以包括生成响应内容，所述响应内容包括对所述数据项的核实的指示。

如果所述相应指令数据或许可证数据结构包含包含所述数据项的相同表示的字段，则所述查询可以仅返回与所述数据项对应的凭证。如果所述相应指令数据或许可证数据结构不包含包含所述数据项的相同表示的字段，则所述查询提供拒绝响应。

所述挑战数据结构还可以包括所述挑战数据结构的标识符，并且所述响应数据包括所述响应数据结构的标识符。所述挑战数据结构和所述响应数据结构的所述标识符可以以某种合适的方式对应。这可能意味着所述响应数据结构是指所述挑战数据结构。所述挑战数据结构的所述标识符可以与所述响应数据结构的所述标识符相同。所述响应数据结构的所述标识符提供了所述响应数据结构和所述挑战数据结构以及对应的许可证数据结构之间的可记录链接的优点。

从第二方面来看，提供了一种在资产转移事件期间核实至少一个数据项的计算机实现的方法。所述方法可以通过第一处理资源来实现。所述方法可以包括生成请求数据。所述请求数据可以包括：

-指令数据集，所述指令数据集可以包括与所述资产转移事件相关联的实体的标识符；和/或

挑战数据结构，其中所述挑战数据结构包括：

○所述至少一个数据项的第一数字标识符；和/或

○所述至少一个数据项的表示。

所述方法可以包括将所述请求数据发送到第二处理资源。所述请求数据可以使用任何合适的手段(例如，数据通信网络或API调用)来发送。

所述方法可以包括从所述第二处理资源接收响应数据。

所述方法可以包括通过以下方式核实所述数据项：根据所述响应数据来确定存在第二数字标识符与所述第一数字标识符相结合的组合的签名。

根据第二方面的方法提供了一种核实数据项的方法，所述方法涉及向第二处理资源发送请求数据，所述请求数据包括挑战数据结构，所述挑战数据结构标识所述数据项并且包括所述数据项的表示。只有所述提供签名才能确定所述数据项。可以使用可以在所述响应数据中提供的许可证标识符来检查所述签名。

第一方面和第二方面可以使用适当配置的系统来实现。

从另一方面来看，提供了一种提供对资产转移处理平台的访问的计算机实现的方法。所述方法可以通过处理资源来实现。所述方法可以包括从与用户相关联的客户端设备接收消息。所述消息可以包括与所述消息相关联的消息类型的至少一个标识符。所述消息还可以包括与在所述资产转移处理平台上注册的简档相关联的至少一个标识符，其中所述简档与所述资产转移处理平台提供的至少一个事件流相关，其中所述至少一个事件流与至少一个资产类型相关联。所述消息还可以包括与请求相关的请求数据，所述请求与所述消息和所述简档相关联。所述方法还可以包括根据所述接收的消息来确定与所述消息相关联的所述消息类型和在所述资产转移处理平台上注册的所述简档。所述方法还可以包括基于所述确定的消息类型来标识用于所述确定的消息类型的消息响应协议。所述方法还可以包括标识所述简档的许可证(permit)数据结构，其中所述许可证数据结构至少提供定义哪些用户可以使用所述确定的消息类型与所述简档交互的标准。所述方法还可以包括处理所述请求数据以确定存在用于对所述请求数据进行签名的加密签名，并且基于确定存在用于对所述请求数据进行签名的加密签名，进一步处理所述请求数据以从所述请求数据中提取数据项。所述方法还可以包括对所述提取的数据项应用所述标识的消息响应协议。所述方法还可以包括通过以下方式，基于所述消息响应协议、所述提取的数据项和所述许可证数据结构来生成对所述消息的响应：使用所述许可证数据结构来确定是否允许所述用户使用所述标识的消息类型与所述简档交互；使用所述消息响应协议来确定所述提取的数据项是否满足所述确定的消息类型的要求；以及基于满足所述确定的消息类型的所述要求，通过与所述至少一个事件流交互来生成响应内容，所述至少一个事件流与所述简档相关联。

根据该另一方面的方法提供了一种用户可以与资产转移平台交互的方法。所述交互通过许可证数据结构提供的权限(permission)来确定，所述许可证数据结构为所述交互提供加密安全性。这意味着许可证可能允许某些交互，而可能不允许某些交互。

所述方法还可以包括向所述客户端设备提供所述响应内容。所述响应内容可以基于来自所述事件流的条目来确定。所述响应内容可以包括记录在所述事件流中的数据。所述数据可以与字母数字短语结合使用。所述响应内容可以是对所述消息的拒绝，并且由于未对所述请求数据进行加密签名而提供所述拒绝；并且/或者如果所述消息类型标识符与消息类型不对应，则可以提供所述拒绝；并且/或者如果无法确定在所述资产转移处理平台上注册的简档，则提供所述拒绝。

所述方法使得能够从事件流中检索内容并将其提供给客户端。这基于所述许可证数据结构提供的加密安全性所实现的内容。

所述许可证数据结构可以包括标识以下各项中的至少一项的数据：与所述简档相关联的资产类型；资产管理者标识符；通过所述简档向所述资产管理者提供的权限；向与所述简档相关联的所述用户提供的权限。

所述消息响应协议可以确定要对所述事件流应用的操作。该操作可以是写操作或读操作。

该操作的效果是，仅允许对所述事件流进行特定操作，并且根据所述消息响应协议及其针对所述许可证数据结构的内容设置的标准来确定这些操作。

所述标识的消息类型可以对应于检索请求，进一步地，其中所述消息响应协议是检索请求协议，其中应用所述检索请求协议可以包括通过确定是否已向所述客户端设备颁发会话许可证来确定所述客户端设备是否被授权访问所述简档，其中如果已向所述客户端设备颁发会话许可证，则所述处理资源从与所述标识的简档对应的所述事件流中检索当前状态，并提供余额作为提供给所述客户端设备的所述响应的一部分；并且进一步地，其中如果尚未向所述客户端设备颁发会话许可证，则所述处理资源生成拒绝消息并将所述拒绝消息提供给所述客户端设备。

也就是说，如果可以提供会话许可证，所述方法可以使得客户端能够从事件流中检索数据。可以提供仅在指定时间段内有效的会话许可证。许可证数据结构的持有者也可以撤销会话许可证。

所述标识的消息类型对应于更新请求，所述更新请求用于请求更新与资产类型相关联的至少一个账户，进一步地，其中所述消息响应协议是更新请求协议，其中应用所述更新请求协议包括：通过确定先前附加到所述事件流的事件日志中存在对应指令数据，基于从所述请求数据中提取的所述数据项来确定所述更新是否是重复更新；进一步地，其中如果所述更新是重复更新，则生成要提供给所述客户端设备的响应消息，所述响应消息指示所述更新是重复更新；以及进一步地，其中如果所述更新不是重复更新，则对所述请求数据应用更新处理协议以确定所述更新的有效性；如果所述更新有效，则将所述更新附加到所述事件流；如果所述更新无效，则针对所述客户端设备生成拒绝消息。

也就是说，如果先前尚未提出所述更新请求，所述方法可以使得客户端能够根据所述许可证数据结构所实现的内容来更新余额。

生成所述更新请求可以包括生成区块链事务，所述区块链事务用于同步与所述请求数据中标识的实体对应的事件流，其中对于所述请求数据中标识的所述实体中的每个实体，所述区块链事务包括尘埃输入和与所述请求相关联的未花费事务输出，所述尘埃输入花费与上一个事务相关联的尘埃输出和与所述尘埃输入对应的相应未花费事务输出；更新与所述请求数据中标识的所述实体对应的事件流。

所述标识的消息类型可以对应于设置请求，所述设置请求用于请求改变与所述资产转移处理平台相关联的所述简档中的至少一个字段，并且其中所述消息响应协议是设置请求协议，其中应用所述设置请求协议包括：从所述数据项中提取至少一个标识符，所述至少一个标识符分别标识要修改的简档设置；根据所述许可证数据结构来确定是否允许所述用户进行所述修改；基于所述许可证数据结构来修改至少一个设置。

也就是说，所述方法可以允许基于所述许可证数据结构来改变简档的设置。

所述数据项可以包括标识所述消息生成时间的时间戳；以及所述处理资源可以被配置为：如果所述时间戳指示所述消息是在从当前时间开始确定的时间段内生成的，则接受所述请求；并且如果所述时间戳指示所述消息的生成时间在所述确定的时间段之外，则拒绝所述请求。

从另一方面来看，提供了一种使得用户能够更新与资产转移处理平台相关联的余额的计算机实现的方法。所述方法可以通过处理资源来实现。所述方法可以包括从与用户相关联的客户端设备接收消息。所述消息可以包括与余额更新相关联的标识符；与在所述资产转移处理平台上注册的简档相关联的至少一个标识符，其中所述简档与所述资产转移处理平台提供的至少一个事件流相关联，其中所述至少一个事件流与至少一个资产类型相关联；以及与所述余额的所述更新相关的请求数据。所述方法还可以包括根据所述接收的消息来确定在所述消息中标识的至少一个简档。所述简档可以是所述处理资源的资源分配，并且可以是所述处理资源的实例。所述实例可以通过云或通过硬件或软件来实现。所述方法还可以包括标识许可证数据结构，其中所述许可证数据结构提供定义哪些用户可以更新所述余额的标准。所述许可证数据结构可以将加密签名与数据项相关联。所述数据项可以是字母数字序列或数字序列。所述数据项可以是随机、确定性地或伪随机生成的。

根据该另一方面的方法提供了一种资产转移平台可以处理更新余额的请求的安全方式。所述方法利用许可证数据结构来提供加密支持，以防止无权更新所述余额的用户更新所述余额。

所述方法还可以包括处理所述请求数据以确定存在用于对所述请求数据进行签名的加密签名，并且基于确定存在用于对所述请求数据进行签名的加密签名，进一步处理所述请求数据以从所述请求数据中提取要用于所述余额的所述更新的数据项。所述方法还可以包括对所述提取的数据项应用更新请求协议以确定是否可以更新所述余额。所述余额的所述更新可能是由于基于所述客户端提供的指令数据的事务。所述指令数据可以通过基于许可证数据结构来核实的加密签名进行签名。

所述方法还可以包括基于所述更新请求协议、所述提取的数据项和所述权限数据结构来生成对所述消息的响应。这可以通过以下方式实现：使用所述权限数据结构来确定所述用户是否拥有更新所述余额所需的加密权限；使用所述更新请求协议来确定是否可以进行所述更新；以及基于满足所述确定的消息类型的要求，通过更新所述余额并与所述至少一个事件流交互来生成响应内容，所述至少一个事件流与所述简档相关联。

从另一方面来看，提供了一种使得用户能够使用计算设备来访问资产转移处理平台的计算机实现的方法。所述用户可以使用标识符来访问所述资产转移处理平台。所述资产转移处理平台可以是支付处理资源。所述资产转移处理平台可以通过软件或硬件来实现。对所述资产转移处理平台的所述访问可以通过数据通信网络或通过另一种合适的方法(例如，通过API调用)，所述API调用利用所述用户的标识符和参数来标识所需的交互。所述方法可以通过处理资源来实现。所述处理资源可以是软件或硬件实现的。所述处理资源可以是云实现的或分布在多个处理器上。所述方法可以包括初始化所述计算设备上的应用程序，所述应用程序可以被配置为生成包括以下各项的消息：与所述消息相关联的消息类型的至少一个标识符；与在所述资产转移处理平台上注册的简档相关联的至少一个标识符，其中所述简档与所述资产转移处理平台实现的至少一个事件流相关联，其中所述至少一个事件流与至少一个资产类型相关联；以及与请求相关的请求数据，所述请求与所述消息和所述简档相关联。所述方法可以包括从用户接收输入，所述输入标识：要发送到所述资产转移处理平台的消息的消息类型；在所述资产转移处理平台上注册的简档；请求数据，所述请求数据包括要向所述资产转移处理平台提出的请求的内容。所述方法还可以包括对所述请求数据应用加密签名以生成已签名请求数据。所述方法还可以包括生成包括以下各项的消息：所述用户标识的所述消息类型的标识符；在所述资产转移处理平台上注册的所述简档的标识符；以及所述已签名请求数据。所述方法还可以包括将所述消息发送到所述资产转移处理平台。

根据该另一方面的方法提供了一种用户可以向所述资产转移平台传输消息的方法。所述应用程序使得所述用户能够提供指令数据，然后对所述指令数据进行签名，以便所述指令数据可以与许可证数据结构结合使用，从而使得所述用户能够安全地与所述资产转移平台交互。

从另一方面来看，提供了一种资产转移处理平台，所述资产转移处理平台被配置为从与用户相关联的客户端设备接收消息，所述消息包括：与所述消息相关联的消息类型的至少一个标识符；与在所述资产转移处理平台上注册的简档相关联的至少一个标识符，其中所述简档与所述资产转移处理平台实现的至少一个事件流相关联，其中所述至少一个事件流与至少一个资产类型相关联；以及与请求相关的请求数据，所述请求与所述消息和所述简档相关联。所述资产转移处理平台可以被配置为根据所述接收的消息来确定与所述消息相关联的所述消息类型和在所述资产转移处理平台上注册的所述简档。所述资产转移处理平台还可以被配置为基于所述确定的消息类型来标识用于所述确定的消息类型的消息响应协议。所述资产转移处理平台可以被配置为标识所述简档的许可证数据结构，其中所述许可证数据结构提供定义哪些用户可以使用所述确定的消息类型与所述简档交互的标准。所述资产转移处理平台还可以被配置为处理所述请求数据以确定存在用于对所述请求数据进行签名的加密签名，并且基于确定存在用于对所述请求数据进行签名的加密签名，进一步处理所述请求数据以从所述请求数据中提取要用于使用所述标识的消息响应协议来确定响应的数据项。所述资产转移处理平台还可以被配置为对所述提取的数据项应用所述标识的消息响应协议。所述标识的消息响应协议可以包括一系列标准，所述一系列标准用于确定是否可以提供响应以及所述响应可能是什么。所述消息响应协议可以通过以下方式，基于所述消息响应协议、所述提取的数据项和所述权限数据结构来生成对所述消息的响应：使用所述许可证数据结构来确定所述用户是否具有使用所述标识的消息类型与所述简档交互所需的加密权限；使用所述消息响应协议来确定所述提取的数据项是否满足所述确定的消息类型的要求；以及基于所述确定的消息类型的所述要求，通过与所述至少一个事件流交互来生成响应内容，所述至少一个事件流与所述简档相关联。

根据该另一方面的方法提供了一种平台，用户可以通过所述平台与事件流交互，所述事件流与账户相关联。所述交互通过许可证数据结构提供的权限来确定，所述许可证数据结构为所述交互提供加密安全性。这意味着许可证可能允许某些交互，而可能不允许某些交互。

从另一方面来看，提供了一种将条目附加到至少一个事件流的计算机实现的方法。事件流可以包括区块链支持的仅附加日志，其中区块链事务中记录的数据被添加到按照时间排序的日志中。也就是说，事件流按照时间顺序(即，在区块链上出现的顺序)记录在所述区块链上的数据。事件流可以使用任何合适的数据结构来实现。事件流可以包括存储在序列中的一系列条目，其中所述序列中的每个条目在所述序列中通过单调增加的数字来引用。也就是说，事件流中的第一条目是条目1，第二条目是条目2，等等。利用底层区块链意味着可以保证所述事件流中的各个条目自写入以来没有被修改，先前连续条目之间没有插入任何条目，没有删除任何条目，也没有重新排序任何条目。未经授权的各方也不可能将事件附加到事件流中。

所述至少一个事件流可能属于与在资产转移平台上注册的用户相关联的资产账户。所述用户的所述注册可以包括在所述资产转移平台上生成简档。所述简档可以对应于处理资源(例如，支付处理资源)的实例。所述方法可以通过处理资源来实现。所述处理资源可以包括基于硬件的资源或基于软件的资源。所述方法可以包括接收将条目附加到所述至少一个事件流的请求，所述条目包括指令数据和所述至少一个事件流的标识符。所述请求可以通过数据通信网络或API调用来接收，所述API调用接收所述至少一个事件流的所述标识符作为参数。所述至少一个事件流的所述标识符还可以标识支付处理资源的实例。

所述方法可以包括从所述请求中检索所述至少一个事件流的所述标识符。基于所述标识符，所述方法还可以包括访问所述至少一个事件流，以及获取与所述标识的至少一个事件流相关联的先前条目的日志。所述先前条目的日志可能受到条目数量或预定义时间段(即，秒数、分钟数、小时数、天数、月数或年数)的限制。

所述方法可以包括从所述请求中检索所述指令数据。所述指令数据可以包括标识以下各项的数据项：账户；与账户相关联的各方；与所述账户相关联的许可证数据结构；以及账户管理者。

所述方法可以包括生成所述指令数据的唯一标识符。生成所述唯一标识符可以包括从所述指令数据中检索所述唯一标识符。所述唯一标识符可以是用于对所述指令数据进行签名的加密签名。生成所述唯一标识符还可以包括通过对所述指令数据或另一合适的技术应用哈希算法来生成所述唯一标识符。

基于所述生成的唯一标识符，所述方法还可以包括确定与所述指令数据相同的数据是否存在于与所述标识的事件流相关联的所述先前条目的日志中。这可以通过以下方式实现：使用所述生成的唯一标识符作为所述先前条目的日志中的搜索关键词。

基于所述确定步骤的结果，所述方法还可以包括将条目附加到所述至少一个事件流，所述条目包括所述指令数据的所述唯一标识符；或者拒绝所述事件流的所述条目作为重复条目。

根据该另一方面的方法防止重复条目被放置在事件流中。这一点很重要，因为重复条目可能包括所述事件流的不可变性，这会降低对记录在所述事件流中的数据完整性的信任。所述指令数据的所述唯一标识符可以包括用于对所述指令数据进行加密签名的加密签名。所述加密签名可以使用ECDSA技术来生成。所述加密签名可以从与实体相关联的许可证数据结构中检索，所述实体与所述事务相关联。

所述请求可以是将条目附加到多个事件流，并且所述方法还可以包括从所述请求中检索所述多个事件流中的每个事件流的所述标识符。所述请求还可以包括标识所述多个事件流中的每个事件流以及先前条目的对应日志。所述方法还可以包括使用所述唯一标识符作为搜索关键词来确定与所述指令数据相同的数据是否先前已被添加到所述日志中的任何日志中。基于所述确定步骤的结果，所述方法还包括使用所述唯一标识符将所述条目附加到所述事件流中的每个事件流；或者拒绝将所述条目附加到所述多个事件流。

该操作的效果是，如果请求标识多个事件流，则即使所述事务已被记录在那些事件流中的一个事件流中，也无法处理所述事务。

所述方法还可以包括根据所述指令数据来确定所述至少一个事件流的条件，必须满足所述条件才能将所述条目添加到所述至少一个事件流中，并且在将所述条目添加到所述至少一个事件流中之前确定是否满足所述条件。所述条件可以是所述事件流的索引必须小于或等于所述指令数据中定义的整数和/或所述条目在预定时间段内被添加到所述事件流中。

所述处理资源可以被配置为通过删除所述日志中存在时间超过预定义最大时间段的条目来将所述日志维持在最大大小。

在接收到与将条目添加到所述至少一个事件流中的所述请求基本上同时接收的另一请求时，所述另一请求包括与将条目添加到所述至少一个事件流中的所述请求相同的指令数据，所述方法包括拒绝这两个请求。该操作的效果是，所述事件流的所述数据完整性不会受到同时发送两次指令数据的情况的影响，即在所述处理之前就意识到所述日志的条目中存在重复。

实施例和根据实施例的方面可以部分或全部结合在一起。

现在参考附图以图示方式描述具体实施例，其中相似的附图标记表示相似的特征。

现在参考图1a描述系统100，该系统使得能够记录系统100的第一用户与第二用户之间的资产的转移。

系统100包括第一计算设备102和第二计算设备104。第一计算设备102和第二计算设备104可以是任何计算资源。第一计算设备102和第二计算设备104中的每一个被配置为通过相应的第一应用程序编程接口(API)和第二应用程序编程接口(API)108与支付处理资源106交互。

支付处理资源106被配置为使用事件流资源110来初始化针对名为爱丽丝(110a)的第一用户、名为鲍勃(110b)的第二用户和支付处理资源(110c)中的至少每一个提供的事件流和/或与该事件流交互。根据于2021年2月18日以nChain Holdings Limited名义递交的申请号为2102314.8的英国专利申请案，应当理解的是，支付处理资源106初始化事件流并与该事件流交互。

如下文将进一步描述的，支付处理资源106可以被配置为与事件流资源110交互，该事件流资源提供使用支付处理资源106处理的事务的顺序日志。

区块链112包括至少一个公共工作证明区块链，它是由事务组成的区块(BSV1、BSV2、BSV3)的仅附加分类帐。

区块链112包括由现在结合图1b描述的软件配置的多个节点126。每个节点都根据该软件配置为区块链的一部分，如下文结合图1c所描述的。

图1b示出了在基于UTXO或基于输出的模型的示例中，在网络132的每个区块链节点126上运行的节点软件450的示例。应当注意的是，另一实体可以运行节点软件450，而不被分类为网络132上的节点126，即，不执行节点126所需的动作。节点软件450可以包含但不限于协议引擎451、脚本引擎452、堆栈453、应用级决策引擎454以及一个或多个区块链相关功能模块455的集合。每个节点126可以运行节点软件，该节点软件包含但不限于以下所有三个：共识模块455C(例如，工作证明)、传播模块455P和存储模块455S(例如，数据库)。协议引擎401通常被配置为识别事务152的不同字段，并根据节点协议处理此类字段。当接收到具有指向另一先前事务152i(Tx_m-1)的输出(例如，UTXO)的输入的事务152j(Tx_j)时，协议引擎451标识Tx_j中的解锁脚本并将其传递给脚本引擎452。协议引擎451还基于Tx_j的输入中的指针来标识和检索Tx_i。Tx_i可以在区块链150上发布，在这种情况下，协议引擎可以从存储在节点126处的区块链150的区块151的副本中检索Tx_i。或者，Tx_i还可以在区块链150上发布。在这种情况下，协议引擎451可以从节点126维护的未发布有序事务集154中检索Tx_i。无论采用哪种方式，脚本引擎451都会标识Tx_i的引用输出中的锁定脚本，并将其传递给脚本引擎452。

因此，脚本引擎452具有Tx_i的锁定脚本和来自Tx_j的对应输入的解锁脚本。例如，在图1b中示出了被标记为Tx₀和Tx₁的事务，但是同样的事务也可以应用于任何事务对。如前所述，脚本引擎452一起运行两个脚本，这将包括根据所使用的基于堆栈的脚本语言(例如，Script)将数据放置到堆栈453上和从堆栈453中检索数据。

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

在基于输出的模型中，来自脚本引擎452的结果“TRUE”是事务有效性的条件之一。通常，还必须满足由协议引擎451评估的一个或多个进一步协议级条件；例如，Tx_j的输入中所指定的数字资产的总数额不超过其输出中指向的总数额，并且Tx_i的指向输出尚未被另一有效事务花费。协议引擎451评估来自脚本引擎452的结果以及一个或多个协议级条件，并且只有当它们都为TRUE时，协议引擎才核实事务Tx_j有效。协议引擎451将事务是否有效的指示输出到应用级决策引擎454。只有在Tx_j确实有效的条件下，决策引擎454才可以选择同时控制共识模块455C和传播模块455P，以执行其就Tx_j的相应区块链相关功能。这包括共识模块455C，向节点的相应有序事务集154添加Tx_j，用于并入区块151中；以及传播模块455P，将Tx_j转发到网络106中的另一个区块链节点126。可选地，在实施例中，应用级决策引擎454可以在触发这些函数中的一个或两个函数之前应用一个或多个附加条件。例如，决策引擎可以只选择在事务有效且预留足够事务费用的条件下发布事务。

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

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

应当理解的是，上述描述通常可以应用于任何区块链。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

客户端应用程序105最初可通过(例如，从服务器下载的)适当计算机可读存储介质，或通过诸如可移动SSD、闪存密钥、可移动EEPROM、可移动磁盘驱动器、软盘或磁带等可移动存储设备、诸如CD或DVD ROM等光盘或可移动光驱等提供给任何给定方103的计算机设备。客户端应用程序105分别对应于图1c中所示的设备102a和102b上的105a和105b。

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

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

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

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

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

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

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

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

区块链112中记录的事务模拟了价值转移，该价值转移已花费或未花费并由锁定脚本保护。事务通过其输入花费价值，并通过其输出支付价值。事务输入的价值必须等于或超过上一个事务输出的价值，任何剩余输入均作为事务费用收取。如果出现以下情况，则事务无效：针对锁定脚本(即，解锁脚本)提供的解决方案不正确；如果该事务输出的价值大于作为输入的价值；如果该事务花费已经花费的输出，或者该事务试图花费根本不存在的价值。

锁定脚本和解锁脚本均以机器可读脚本语言表示，允许各种脚本花费条件，包括可以嵌入任意数据(以可证明不可花费的输出形式)作为数据载体输出的脚本。

图1a中的支付处理资源106可以被配置为与区块链112交互。这可以在生成区块链事务时进行，其中，它可以检索未花费输出，以用作其他区块链事务的输入的基础。在生成区块链事务时，支付处理资源106可以将区块链事务的生成记录为事件流管理器110实现的对应事件流中的事件。事件流的功能的更多详细信息可以在以nChain Holdings Limited名义递交的GB2002285.1、以nChain Holdings Limited名义递交的GB2020279.2和以nChain Holdings Limited名义递交的PCT/IB2021/051261中找到。

图1a中的支付处理资源106被配置为与密钥存储模块122和支付数据存储器124交互。密钥存储模块122被配置为存储与使用支付处理资源106以使得能够开展事务的各方的账户对应的密钥。密钥存储模块122可以利用任何合适的存储装置，并且将利用数据库管理系统(DBMS)来初始化、存储和检索来自各方的数据库内的记录的数据，各方在密钥存储模块122中存储加密密钥。支付数据存储器124被配置为存储与使用支付处理资源106实现的任何支付相关的数据。

相应计算设备与支付处理资源106之间的交互可以根据支付处理资源106生成的许可证数据结构来确定。

现在描述与许可证相关的许可证数据结构的概念，该许可证与支付处理资源106的用户相关联。许可证提供了一种标识用户并说明该用户能够执行的操作的方法。标识方面是通过使用公钥密码学进行的，而与该用户的授权相关的方面是通过使用权限来管理的。

许可证提供了一种标识用户并说明许可证持有者能够执行的操作的方法。标识方面是通过使用公钥密码学进行的，而“持有者可以执行的操作”是通过使用本文描述的许可证进行的。

在一个实施例中，每个许可证具有相关联的许可证数据实例(其也被描述为相关联的许可证数据或许可证数据)。许可证数据实例包括有关许可证本身以及规定许可证的持有者可以执行的操作的权限的数据。可选地，每个许可证包括至少一个权限，并且更可选地包括多个权限。权限被配置为确定许可证的持有者能够执行的操作。可选地，权限由名称值(也称为密钥值)对定义。可选地，名称是一串字符。更可选地，该串字符是人类可读的，并且提供关于权限相关内容的指示。可选地，值是字符串、数字或数据结构，其中该数据结构是一个或多个名称值对。可选地，权限采用下面在“权限”标题下进一步详细讨论的形式。可选地，当引用包括本文使用的一个或多个权限的许可证时，这引用包括名称值权限的许可证数据实例。可选地，权限以集合或群组的形式提供(在本文描述的示例中称为permissionSet)。可选地，权限群组是每个许可证的一部分，作为“扩展”(extension)。

每个许可证还包括数据，使得可以验证许可证的持有者的身份。可选地，许可证包括与许可证的持有者相关联的公钥。对许可证持有者的身份的验证可以通过以下方式来确定：持有者使用其私钥对消息(或任何数据)进行签名，然后验证许可证持有者的身份的一方可以将签名和消息和与许可证持有者相关联的公钥进行比较。可选地，与许可证持有者相关联的公钥存储在相关联的许可证数据实例中。

可选地，每个许可证都由许可证标识符来标识。可选地，许可证标识符不提供关于许可证的内容的指示。可选地，许可证标识符是伪随机生成的字符串。

在一个实施例中，该系统提供了一种根据用户的许可证验证其签名的方法，从而验证用户是或不是该许可证的持有者。

可选地，许可证是层级结构的一部分。参考图1d，示出了许可证200的层级结构。所有许可证(根202除外)都将具有父许可证，并且可选地具有一个或多个子许可证。可选地，子许可证不能具有多个父辈。所得到的许可证层级结构是树。父许可证能够创建子许可证。

可选地，许可证包括一组规则，该组规则允许许可证持有者创建包含给定“域”或“命名空间”内权限的子许可证，但不能跨越其他域或命名空间。使用这些命名空间可以防止不同的组织干扰使用许可证系统的其他组织。该组规则可以在下面讨论的“特殊权限”中找到。

此外，该组规则允许将权力委托给子许可证，赋予子许可证在域名或命名空间内创建孙辈的权利，并且递归地向下延伸，但受可选深度和总数限制的约束。

顶级根许可证202能够创建大量甚至无限数量的子许可证，几乎不受任何限制。可选地，凭借如此广泛的能力，用于创建根许可证的私钥/公钥对可以得到安全管理。可选地，与根许可证相关联的私钥离线保存在安全设备中。

顶级根许可证202(而不是组织级根许可证206、208、210)的创建是一次性进程。该方法类似于创建子许可证，只是没有父许可证可供引用，因此，与检查父许可证的权限(permission)、认证(authentication)、授权(authorisation)和其他功能相关的所有检查都会被跳过或以其他方式忽略。可选地，在该实施例中，仅运行一次，并且不再运行。

在图1d的示例性许可证层级结构200中，存在四个不同的组织使用许可证。nChain(TM)是根许可证的持有者，并且Org ABC、Org PQR和Org XYZ都使用的许可证是nChain许可证的子辈。本领域技术人员应当理解的是，特定公司仅作为示例使用。此外，此类许可证系统中可能存在任何数量的组织。图1d中所示的示例性层级结构和组织举例说明了当使用本文描述的多个本公开实施例时许可证构建的灵活性。

继续该示例，Org ABC具有组织级根许可证206。这是根许可证，因为它是Org ABC许可证的根，而不是整个树的顶级根202。Org ABC已经创建至少两个子许可证212、214。这些子许可证适用于不同的客户和/或终端用户。

Org XYZ具有根许可证210。Org XYZ已经选择具有不同的层级结构，其中每个国家都有许可证。XYZ UK许可证216被示为具有针对成员和/或终端用户的至少两个许可证218、220。

在一个实施例中，根许可证的持有者创建同一持有者的多个子许可证204。这些子许可证被配置为使得它们可以为系统的其他用户创建其他子辈206、208、210许可证。这样，每当新用户或组织需要许可证时，无需使用顶级根许可证202来进行进一步的许可证创建，从而减少发生攻击的机会并提高根许可证的安全性。

可选地，每个许可证都包含对其父许可证以及一个或多个命名权限的引用。创建后，父许可证将提供指示权限集的数据和与许可证持有者相关联的公钥(holderPubKey)。从下面的示例性许可证数据实例中可以看出，默认情况下，权限存储在extensions[“default”]对象下。

可选地，在称为许可证数据实例或许可证数据的数据结构中跟踪许可证信息。该数据结构至少包括下表中列出的以下元素中的一些元素。可选地，需要这些元素中的所有元素。这些元素的一些值可以设置为空、零，或者长度为零。更可选地，父许可证是必需的，而不是空的。

可选地，每个许可证都具有定义的有效期。可选地，许可证的有效期从当前时间到结束时间和日期；更可选地，其中结束时间和日期在许可证数据实例中“revoked”元素下设置。一旦被撤销，许可证就可能无法重新激活。

可选地，确定许可证是否已被撤销取决于当前时间。每个许可证都包括“revoked”元素，该元素包括时间。对于被认为已被撤销的许可证，当前时间必须在许可证中存储的撤销时间之后。更可选地，并且根据另一实施例，提供了一种方法，其中在未来的某个时间提供许可证，并且返回该许可证在当时是否有效。

可选地，命名权限的映射在扩展映射中通过其名称来引用。存储初始扩展时将使用名称“默认值”。

或者，不使用扩展映射，并且仅一个权限集与许可证相关联。

下面以JSON格式示出了示例性许可证数据实例，其中使用了所有元素(尽管其中一些元素设置为空)。

本领域技术人员应当理解的是，上面是示例性许可证，并且根据本文描述的特定实施例，可以删除、不使用或修改该许可证数据实例的一些特征。本领域技术人员应当进一步理解，这里提供的JSON作为表示许可证的示例。许可证及其内容可以使用其他格式来表示，例如XML、二进制编码格式或任何其他适当的格式。

参考图1e，示出了一个简单的示例(其中省略了最终的顶级根许可证)。这里，组织的根许可证302具有至少两个子许可证304、306。该组织是NBW(国家水道局)，其颁发钓鱼许可证304、306(在该示例中仅限于钓鱼者)。可选地，NBW提供移动应用程序，该应用程序保存持有者许可证的标识符和秘密密钥，该秘密密钥允许许可证的持有者验证他们持有该许可证。每个钓鱼者的许可证304、306包括称为“org.nbw.angler.rights”的权限，并且可选地具有以下结构：

可选地，还存在与个人身份相关联的其他权限，例如会员编号和用户姓名。

在使用中，希望确认用户(例如，持有第一子许可证304的Fred Bass)正在使用正确类型的设备钓鱼并捕获正确类型的鱼的钓鱼检查者可以使用该许可证来执行这些操作。检查者可以使用许可证标识符(可选地，通过二维码从Fred Bass的手机获取)。使用该许可证标识符，检查者可以查询许可证实例本身，以核实权限(使得Fred Bass使用钓竿并且仅捕获鲤鱼、沟鱼或梭鱼)和身份(使得Fred实际上是许可证的持有者，并且他没有复制其他人的许可证标识符)。

权限

可选地，使权限具有命名空间。更可选地，通过限制名称值对的名称来使权限具有命名空间。这些命名空间使用以“.”(句点)分隔的反向DNS域类结构。一些示例性命名空间包括：

com.example.user.id

com.example.user.type

com.example.acme.user.id

org.nbw.angler

可以看出，这些命名空间是从左到右构建的，其中最左边的前缀是最不具体的特征，而最右边的后缀是最具体的特征。

可选地，这些权限的名称值对的名称和值都是可定制的(只要名称在父许可证的允许命名空间内)。可选地，名称和值都可以是任何任意值。可选地，名称和值都由许可证系统的用户提供。因此，名称和值是用户生成的。通过提供用户生成和/或可定制的名称和值，许可证的用例可以非常灵活，从而可以在大量不同的应用程序中使用。

可选地，命名空间只能变得更长。这也可以理解为，子许可证的权限只能是根据父辈权限允许的权限子集。可选地，命名空间允许将权限结构化为层级结构(这是附加的并且与许可证分离，尽管通常匹配，但是许可证也是分层的)。

可选地，权限层级结构遵循与许可证相同的结构。此外，应当理解的是，每个子许可证包括作为父辈的子集(按命名空间)的权限。

以“$”命名空间为前缀的特殊权限集提供有关许可证本身的信息和/或限制。“$”命名空间对这些许可证可以添加到子许可证的权限提供限制。这些限制可以包括：

对子辈中的所有权限强制执行一个或多个命名空间前缀；

向子辈授予创建其他许可证的权利，以递归方式达到给定深度；

限制能够创建的子辈和后代的数量；和/或

限制能够创建的扩展的数量(下面在“扩展”标题下讨论)。

或者，存储在这些特殊权限中的信息(即，许可证的限制和其他信息)不会存储在特殊权限中，而是存储在许可证数据实例中。可选地，这些限制中的每个限制都作为其自身的元素存储在许可证数据实例中。本领域技术人员应当理解的是，这些限制可以存储在与许可证相关联的任何数量的不同位置。

可选地，“$”命名空间还用于定义许可证的有效期。

表1-示例性特殊($)权限

特殊($)命名空间不需要遵循上述“$.children.namespace”规则。可选地，只能创建特定的特殊权限集。更可选地，上述集合是许可证可以拥有的唯一特殊权限。

可选地，$.valid.after和$.valid.before权限使用本地时间。可选地，这些权限是可选的，并且不是必需的。可选地，$.valid.after和$.valid.before定义许可证和/或扩展的有效期。可选地，如果父辈设置了$.valid.after和$.valid.before权限中的任一者，则从其创建的任何子许可证都必须在相同或更窄的时间窗口内传送。因此，可以看出，子许可证的有效期不能超过其父许可证的有效期。

可选地，这些特殊权限仅存储在初始/默认扩展中，因为这些特殊权限是指整个许可证。存储在不同扩展中的任何特殊权限都会被忽略或拒绝。

参考图1e的先前示例，NBW根许可证302至少包括以下权限：

$.children.namespace＝“org.nbw”

$.children.levels＝1

这些权限规定，NBW根许可证302的持有者可以创建所需数量的子许可证，只要子许证的权限以“org.nbw”开头并且子许可证的深度仅为一个层级。

参考图1f，这里示出了另一示例性许可证结构320。该结构类似于参考图1e描述的结构。NBW根许可证302拥有等于2(或更多)的“$.children.levels”权限。在该示例中，NBW许可证302持有者希望允许俱乐部为其自身成员创建许可证。NBW许可证302创建俱乐部许可证BLFC 322(大湖钓鱼俱乐部)，该俱乐部许可证包括以下权限：

org.nbw.club.id＝“BLFC”

$.children.namespace＝“org.nbw.angler”

$.children.levels＝1

$.children.max＝50

这些权限允许BLFC为其成员创建最多50个许可证，但仅限于命名空间“org.nbw.angler”内的权限。因此，任何子许可证都不允许使用“org.nbw.club.id”等权限，因此子许可证不能冒充俱乐部许可证的权限(例如，如果子许可证包括权限“org.nbw.club.id”，则子许可证可以假装自己是俱乐部并采取与俱乐部相关联的任何动作)或任何其他类似权限。

BLFC许可证322创建至少两个子许可证324、326。这些子许可证必须拥有以“org.nbw.angler”为前缀的权限。

扩展

可选地，权限存储在“扩展”中。可选地，扩展包括：权限集(称为permissionSet)、revoke元素和holderPubKey元素。扩展存储在扩展映射中的许可证数据实例中，并由名称引用。可选地，名称是用户生成的。可选地，名称是人类可读的。可选地，初始扩展和/或默认扩展被标记为“默认值”。这里，人类可读是指任何编码，使得可以被人类自然读取。可选地，编码是ASCII或Unicode文本。

可选地，扩展提供一种方式来引用由至少一个权限构成的群组。更可选地，权限提供一种人类可读方式来引用由至少一个权限构成的群组或集合。

每个扩展都包括多个元素。下面的表2中提供了扩展的示例性元素。可选地，所有这些元素都是必需的。

表2-扩展元素

本领域技术人员应当理解的是，没有必要严格遵循扩展的结构和格式以及扩展的存储方式。对于权限的扩展和/或集合，可能存在替代结构。示例性替代方案可以是，扩展可以不严格地存储在扩展映射中，而是可以存储在列表或其他适当的数据结构中。或者，本文描述的扩展对象还可以具有不同的结构，因为它们仅包括权限列表或权限引用列表，并且权限本身存储在许可证的其他位置。

在许可证的有效期内，扩展可以用于添加和替换权限。扩展可以由父许可证添加或撤销。可选地，添加到许可证的所有权限都由父许可证的持有者进行签名。

在一个实施例中，扩展使得许可证持有者能够将不同的设备与许可证相关联。例如，如果许可证用于访问特定资源(可选地是计算资源)，则单个许可证持有者可能拥有一个“iPhone”扩展来管理其iPhone与计算资源的交互和一个“桌面”扩展来管理其桌面计算机与计算资源的交互。如上所述，可以撤销扩展。有利地，如果用户丢失了其iPhone，他们可以联系其许可证提供商(该提供商对创建该用户的许可证的父许可证拥有控制权)，并且他们可以撤销iPhone扩展，而不会影响用户的其他设备与服务的交互。因此，可以看出，扩展系统在提供/删除对资源的访问时提供了改进的灵活性和控制。将这与许可证的中央控制和/或缺乏证书撤销列表相结合，在核实相关扩展内的权限时，由于不需要分发和维护此类列表，因此可以节省计算资源。

与许可证的交互

如上所述，可选地，本文描述的许可证系统使用请求进行交互。可选地，这些请求是HTTP请求。更可选地，这些请求被发送到REST端点。存在两个相关的REST端点：

…/send，用于请求对许可证进行操作，包括创建和撤销子许可证；和

…/query，用于检查许可证的有效性和权限。

可选地，多个交互将要求请求包括签名，因此希望与其用于创建、撤销或其他交互的许可证的交互的组织将需要设置私钥/公钥对。任何请求还将需要包括感兴趣的许可证的实例id。实例id和公钥可以公开查看或已知，但是私钥必须保密。

向这些端点传输请求也可以被描述为“调用”它们，因为它们以RESTful API的形式呈现。因此，请求的发送者也可以被认为是“调用者”。

可选地，记录发送到“…/send”端点的任何请求。可选地，记录发生在区块链上，使得第三方可以审计请求。可选地，不记录发送到“…/query”端点的任何请求。

在一个实施例中，交互被记录在区块链上，或者至少交互的子集被记录在区块链上。可选地，这些交互中的所有交互都是在链下记录的，并且交互的子集被记录在区块链上。可选地，交互被记录到多个交互集合中，其中每个交互集合与单个许可证相关。每个交互集合还在区块链上具有相关联的表示(通过使用事务)。因此，希望跟踪与感兴趣的许可证的交互的审计员只能审计感兴趣的集合。

可选地，记录在区块链上的交互中的每个交互都包括先前交互的不可变引用(可选地，也存储在区块链上)。可选地，引用是先前交互的哈希。可选地，所有交互都包括对先前交互的引用，从而建立所有交互的不可变链。因此，不可变日志只需要记录在区块链上的交互子集。可选地，仅在区块链上记录第一次交互和最后一次交互。

可选地，使用每个许可证的事件流来进行记录。可选地，存在通过API交互的记录服务，以提供记录实施例。事件流如下所述：

nChain Holdings Limited于2021年2月15日提交的PCT/IB2021/051258；

nChain Holdings Limited于2021年2月15日提交的PCT/IB2021/051260；和

nChain Holdings Limited于2021年2月17日提交的PCT/IB2021/051333。

可选地，通过使用事件流API将指示与许可证的任何交互的数据传输到事件流。可选地，事件流API是RESTful API。许可证的当前状态可以通过以下方式来验证：采用与许可证的这些交互中的所有交互(包括其创建)，以及通过再次执行/回放所有交互步骤来重新创建“虚拟许可证(dummy permit)”(这也可以被描述为“空运行”，因为实际上没有创建新的许可证)。“虚拟许可证”的最终状态应当具有与真实许可证相同的当前状态。如果许可证的任何中间状态已知，则验证所述中间状态也是如此。

因此，可以看出，通过记录与许可证的交互，许可证的状态被记录，因此当前状态或任何先前状态是可审计和验证的。通过事件流将这些状态更改提交到区块链，许可证将变得永久可审计和验证，并且具有高数据完整性置信度。

对端点的一些示例性请求可能在报头中包含以下特征：

POST https://{AWS ID}.amazonaws.com/api/v1/processInstance/{instanceID}/send

或

POST https://{AWS ID}.amazonaws.com/api/v1/processInstance/{instanceID}/query

其中，{AWS ID}是AWS(TM)端点的id，{instance ID}是许可证标识符。本领域技术人员应当理解的是，可以使用其他URL和服务。例如，可以使用非AWS URL。本领域技术人员应当理解的是，本文提供的请求是示例性的，并且可以采用不同的形式。请求被示出为包括请求被发送到的URL。可选地，不以这种方式提供完整的URL，而仅提供路径。

可选地，请求报头还包括AWS API密钥。

可选地，POST的主体应当是包含为正被发送的消息或交互命名的单个属性的JSON对象。可选地，通过使用发送者的私钥对参数进行签名并将结果置于请求的签名属性中来对请求进行认证和授权。例如：

应当注意的是，正被签名的请求的一部分需要作为请求内容的字符串表示而不是JSON对象本身发送。这是为了确保请求的发送者和请求的接收者使用相同的对象表示(与间隔、顺序等无关)来计算签名。除了字符串化之外，还可以使用对象的规范结构。可选地，该规范结构根据RFC8785进行定义。规范化方案是发送者和接收者双方商定的方案。该方案可能事先商定，或者该方案由发送者标识，使得接收者了解正在使用哪种方案。

可选地，对上述请求的响应具有结果属性和可选消息。例如：

消息(msg)的确切内容将取决于请求的上下文及其处理方式。

下面给出了描述不同交互许可证的许多不同实施例。可选地，这些实施例中的任何数量的实施例都可以与任何数量的不同其他实施例一起使用。本领域技术人员应当理解的是，一些实施例可能不会在每个可想象的系统中使用。例如，可能不使用扩展，因此可能不使用与扩展的创建或撤销相关的任何交互。

每个许可证数据结构可以存储在许可证数据存储器180中。许可证数据存储器180可以通过合适的API或其他手段从支付处理资源106访问。许可证数据结构以任何合适的方式存储在许可证数据存储器180中，使得许可证标识符可以用于标识许可证。例如，这使得能够在检查加密签名期间访问许可证数据结构的其他元素。

支付处理资源106使得用户能够建立他们可以用来管理账户的支付处理资源106的实例。现在将参考图2描述这一点。支付处理资源106的实例用于管理围绕资产的活动，该资产由根据于2021年6月24日以nChain Licensing AG名义递交的GB2109064.2中规定的过程在支付处理资源106上建立的账户管理。

与用户相关联的第一计算设备102下载应用程序代码，该应用程序代码将该第一计算设备配置为使用API 108来生成应用程序编程接口(API)调用，这些调用将由支付处理资源106接收。支付处理资源106向第一计算设备102提供支付处理资源标识符，API可以使用该支付处理资源标识符来标识支付处理资源106。标识符可以是字符的字母数字序列，也可以是字符的纯数字序列。

第一计算设备102通过生成对API 108的端点的API调用来发起建立支付处理资源106的实例的过程，该API调用对应于对支付处理资源106的新实例的请求。这是步骤S200。API调用包括支付处理资源106向第一计算设备102提供的支付处理资源标识符。

支付处理资源106可以与字符串化JavaScript对象表示法(JSON)对象相关联，该对象可以具有与对应账户管理的资产的标识符对应的元素；账户管理者的标识符、账户管理者的许可证数据结构的标识符、账户持有者的许可证数据结构的标识符、账户发起者的标识符(例如，可以是银行的客户)、使得能够检查账户持有者的许可证中的表达式的表达式以及条款和条件(包括使得能够检索条款和条件的统一资源位置、条款和条件的哈希、账户持有者的加密签名)、配置参数(例如，最小和最大余额设置)、关于如何控制数字的设置以及对应资金账户的花费限制。

账户管理者和账户持有者的许可证数据结构可以如上所述构建，其中提供各种权限，这些权限可以由支付处理资源106使用许可证数据结构进行加密验证。

支付处理资源106通过请求与支付处理资源106的对应实例使用的元素对应的数据来进行响应。这是步骤S202。

然后，第一计算设备102提供支付处理资源106使用的相应元素来建立对应用户与支付处理资源106交互所需的支付处理资源106的实例。这是步骤S204。

在建立支付处理资源106的实例时，支付处理资源106有效地生成用户的简档，该简档由实例标识符(其生成和使用如下所述)标识。这意味着，当使用标识符访问支付处理资源106时，支付处理资源106可以确定要访问哪些文件，并且还可以确定将资源(即，存储器、目录和寄存器)正确分配给该实例上的活动。支付处理资源106可以单独运行、访问和利用每个实例。

在支付处理资源106通过基于云的资源实现的情况下，支付处理资源106的实例可以使用通过跨云基础设施的必要硬件运行的对应软件来实现。这使得支付处理资源106能够将资源适当地分配给任何一个实例。

在接收到相应元素时，支付处理资源106处理所需元素并核实为支持账户持有者和账户管理者的许可证而提供的数据。这样，它会获取与两个许可证对应的公钥。它还获取两个许可证的标识符并检查两个许可证的表达式的有效性。这是步骤S206。这是通过引用与相应许可证对应的许可证数据结构来实现的。条款和条件上的加密签名还通过引用账户持有者的许可证数据结构来进行检查。这可以使用上述方法来进行检查，其中条款和条件以及加密签名被提供给许可证数据存储器180，并请求针对对应的许可证数据结构来验证加密签名。然后，使用已知技术来验证加密签名，例如基于椭圆曲线数字签名算法(ECDSA)或Rivest-Shamir-Adleman(RSA)方法来生成和验证数字签名。如果请求中提供的签名被成功验证，则认为数字签名有效。如果未被成功验证，则可以发出拒绝消息。

然后，将资产和账户管理者的标识符记录在针对该实例生成的实例数据结构170中。另外，将与账户持有者和账户管理者的许可证对应的标识符记录在实例数据结构170中。这是步骤S208。实例数据结构170包括提供对账户持有者和账户管理者的标识符的访问所需的任何合适的数据结构。支付处理资源106可以使用任何合适的手段(例如，通过附加API或通过数据通信网络)来访问实例数据结构170。

另外，将对应资金账户的余额设置为零，并且还在实例数据结构170中设置与数字的表示、花费限制以及最小和最大余额相关的其他设置。当用户接收到该账户的消息时，还会生成实例标识符，向支付处理资源106标识该实例。这是步骤S210。然后，将实例标识符提供回第一计算设备102，该实例标识符可以保存在该第一计算设备中，用于与支付处理资源106进一步交互。这是步骤S212。如果其他用户需要与支付处理资源106的对应实例交互，则该实例标识符也可以由他们使用。向第一计算设备102提供实例标识符会完成与步骤S204中提供的信息中标识的资产的资金账户对应的支付处理资源106的实例的生成。向第一计算设备102提供实例标识符也会触发生成将资源分配给支付处理资源106的对应实例所需的参数。在完成支付处理资源106的实例的生成时，支付处理资源106与事件流管理器110交互，以初始化与支付处理资源的实例对应的事件流。这是步骤S214。事件流将用于记录与对应资金账户相关联的完整历史记录。只能对事件流执行读操作或附加操作。

初始化事件流可以包括设置和配置实现特定事件流所需的计算资源和数据结构。替代地或附加地，完成支付处理资源106的实例的生成可能导致访问预先存在的事件流。初始化预先存在的事件流还可以包括附加条目，以附加确认支付处理资源106的实例已被建立的数据。预先存在的事件流可以是包含支付处理资源106的所有实例的条目的事件流。预先存在的事件流还可以是将每个其他事件流同步到单个事件流中的事件流，该单个事件流也由事件流管理器110管理。事件流的功能的更多详细信息可以在以nChain HoldingsLimited名义递交的GB2002285.1、以nChain Holdings Limited名义递交的GB2020279.2和以nChain Holdings Limited名义递交的PCT/IB2021/051261中找到。

建立支付处理资源106的实例并提供实例标识符使得第一计算设备102等设备能够与支付处理资源106的实例交互。除了第一计算设备102之外的其他设备也可以与所生成的实例交互，只要许可证数据结构允许它们这样做，如下所述。

在计算设备与支付处理资源106的实例之间的交互的第一示例中，下面描述第一计算设备102可以如何利用API 108来发起与步骤S200至步骤S214中生成的支付处理资源的实例的会话。如稍后将描述的，该会话随后可以用于实现与实例的其他交互。

具体地，参考图3描述第一计算设备102如何获取会话密钥，以实现与资金账户的交互，该资金账户与支付处理资源106的实例相关联。

在步骤S300中，第一计算设备102使用API 108发出调用，以请求与支付处理资源106的实例的会话。这利用API 108的会话端点。请求会话的API调用将实例标识符(与支付处理资源106的相应实例相关联)传递到会话端点，以初始化与支付处理资源106的实例的会话。API调用还包含指令数据，该指令数据包含确认调用时间的时间戳。指令数据还可以包括可以利用会话的时间段(以及本质上将使用对应会话密钥的时间段)和确认指令是否来自账户管理者的标志(如果指令来自账户持有者，则设置为FALSE)。

指令数据还可以包含数据，该数据包括标识许可证数据结构的许可证标识符和许可证数据结构中的凭证，该凭证可以示出第一计算设备102访问事件流的授权。稍后在如何核实数据项的上下文中讨论此类凭证的核实。此类凭证还可以被描述为许可证数据结构中的权限。指令数据还可以包含与许可证数据结构对应的公钥。

也就是说，支付处理资源106基于API调用和所提供的实例标识符来确定来自第一计算设备102的消息与在第一计算设备102与支付处理资源106的实例之间建立会话的请求相关。

指令数据还包括来自账户持有者的加密签名，该账户持有者对应于与支付处理资源106的所标识的实例相关联的资金账户。也就是说，指令数据由账户持有者进行加密签名，并且该加密签名包括在指令数据中。该加密签名可以利用椭圆曲线数字签名算法(ECDSA)技术，使用与账户持有者的许可证数据结构相关联的私钥来生成。或者，该签名可以使用基于RSA的技术来生成。

响应于API调用，支付处理资源106执行一些初始检查，以确定是否可以生成会话密钥或者是否应该立即拒绝请求。这是步骤S302。也就是说，支付处理资源106检查时间戳，以查看距离当前时间是否最多一分钟。如果时间戳距离当前时间超过一分钟，则拒绝会话请求。如果时间戳距离当前时间小于或等于一分钟，则接受会话请求。该时间段距离时间戳指示的时间可能相差不是一分钟。对于安全意识较高的应用程序，该时间段可能远远小于一分钟，但是对于安全意识较低的应用程序，该时间段可能更长。

通过检查相对于时间戳指示的时间的当前时间以确定自提出请求以来已经过了多长时间，支付处理资源106可以防止重放攻击。

支付处理资源106还检查该时间段(也称为会话周期)以确定会话可能被使用的时间。该时间段通常以秒或分钟的形式表示，但也可以表示为预期使用会话的日期范围。

在步骤S304中，支付处理资源106向许可证数据存储器180发出请求，以验证加密签名(包括在指令数据中)。这可以通过单独的API或通过经由电信网络传输到许可证数据存储器180的消息来实现。或者，许可证数据存储器180可以位于支付处理资源108本地，因为它占用同一本地化硬件资源群组。该请求将包括步骤S300中提供的指令数据和用于对该指令数据(即，正被验证的指令数据)进行签名的加密签名。该请求还可以包括由提出验证请求的支付处理资源106的特定实例使用的引用，并且还可以包括标识作为该请求的来源的设备的字符串。例如，如果请求是从Apple发出的，则字符串可能是“iPhone”。该字符串可以在指令数据中提供，并由支付处理资源106从指令数据中提取。特定实例使用的引用可以是步骤S300中提出的请求的事件流索引。这是有利的，因为这有助于在提出请求时结合相关联的事件流(即，针对支付处理资源106的实例生成的事件流)的状态来验证许可证数据结构的状态。也就是说，当提出验证加密签名的请求时，这可能有助于核实许可证数据结构是否在其当前状态下产生了正确的响应。该请求还包括支付处理资源106的相应实例的实例标识符，并且另外包括许可证标识符，以使得许可证能够由许可证数据存储器180标识。

然后，许可证数据存储器180将对与许可证标识符所标识的许可证对应的记录执行检查。这是步骤S306。如果在与许可证对应的许可证数据结构中找到加密签名，则检查将返回确认。这涉及使用标准ECDSA或RSA签名验证技术来验证签名。将所生成的签名与指令数据中提供的加密签名进行比较。这是步骤S308。如果加密签名不匹配，则检查将返回拒绝。这是步骤S310，并且该请求失败或不再处理。如果确认指令是否来自账户管理者的标志被设置为TRUE，则用于验证签名的公钥来自账户管理者拥有的许可证数据结构。

如果检查返回确认，即签名确实匹配，则支付处理资源106将步骤S300中请求的会话周期与支付处理资源106为与支付处理资源106的对应实例的会话设置的最大周期进行比较。这是步骤S312。如果会话周期小于支付处理资源106设置的最大周期，则支付处理资源106将针对具有所请求会话周期的所请求会话生成会话密钥(也可以称为会话令牌)。这是步骤S314。会话密钥将由支付处理资源使用任何合适的技术生成。会话密钥可以使用与许可证数据结构中找到的许可证对应的公钥来生成。会话密钥可以利用分层密钥生成技术，使用与账户持有者的许可证相关联的公钥/私钥对作为基本密钥来生成。会话密钥然后可以与会话已被初始化的消息一起返回到第一计算设备102。然后，会话密钥可以与指令数据一起用于请求与事件流交互的其他请求。然而，会话密钥只能在已经请求的会话周期内使用。

如果步骤S312中的比较返回的结果指示会话周期大于最大周期或小于支付处理资源的实例也为与支付处理资源106的会话设置的最小值，则支付处理资源106将不会生成会话密钥并且请求将失败，即不再处理。

替代地或附加地，如果加密签名被验证，但所请求的会话周期小于为与支付处理资源106的实例的会话设置的最小值，则支付处理资源106可以生成会话密钥并将允许的会话周期增加到最小值。

在生成会话密钥时，支付处理资源106可以从本地存储器中检索余额。可选地，支付处理资源106还可以向事件流管理器110发出查询，以获取来自事件流的事务的顺序日志，该事件流对应于与由实例标识符标识的支付处理资源的实例相关联的资金账户。该查询可以返回事件流的部分或完整版本，从而提供与资金账户相关的事务历史记录的概述，该资金账户与支付处理资源106的实例相关联。如果查询指定事件流管理器110将返回日期之间所有条目的日期范围，则可以返回部分版本。日期范围可以在步骤S300中提出的初始请求中指定，或者可以由支付处理资源106自动生成。这是步骤S316。

事件流管理器110将生成该查询的时间戳和事件流的索引。这是步骤S318。响应于该查询，事件流管理器110可以将条目添加到事件流中。

然后，将余额(如果已获取)、事件流的时间戳和索引返回到第一计算设备102。这是步骤S320。然后，在步骤S320中，还可以将会话密钥传输到第一计算设备102。

然后，第一计算设备102可以使用会话密钥来从事件流请求只读数据，该事件流与由步骤S300中提供的实例标识符标识的支付处理资源的实例相关联。这不需要重复生成会话密钥所涉及的认证过程。也就是说，可以在从第一计算设备102到支付处理资源的API调用中提供会话密钥。

这可能是请求的一部分，该请求是查看通过事件流跟踪的账户的状态，或者获取有关所述账户的历史记录的信息。获取有关历史记录的信息的请求可能会请求由日期范围、索引范围甚至相应事务数据的哈希指定的事务的详细信息。请求还可以是针对完整的事务历史记录。

也就是说，计算设备可以使用实例标识符与支付处理资源106的实例交互，然后从相关联的事件流获取只读信息。或者，计算设备可以与支付处理资源106的实例交互以生成会话密钥，该会话密钥随后可以用于与事件流进一步交互。在提出请求时，使用许可证数据结构来验证与所提供的加密签名对应的许可证数据结构，并且只有在验证加密签名的情况下，该请求才会继续。使用许可证数据结构来验证加密签名并确定会话周期既不太短也不太长充当确定消息的可接受性的协议，尤其是用于获取与事件流相关的只读数据的请求，该事件流与支付处理资源的实例相关联。第一计算设备102的用户仅在会话可以被授权的情况下才能访问只读数据，并且仅在协议的要求(即，签名的存在和会话周期的长度)可以被满足的情况下才能授权会话。授权会话包括向请求用户提供会话密钥。用户可以使用会话密钥对指令数据进行签名，并且当用户请求访问对应事件流时，支付处理资源106可以检查签名。支付处理资源106可以基于从第一计算设备接收的API调用来确定需要上述协议，因为它可以提供标识正被提出的请求的类型的参数。替代地或附加地，如果第一计算设备102通过数据通信网络提供请求，则消息可以提供标识特定类型的请求的参数。

现在，参考图4a，描述在资金从与支付处理资源106的一个实例相关联的资金账户转移到支付处理资源106的另一个实例期间，第一计算设备102可以如何与支付处理资源106的实例交互。这导致转移被记录在相关联的事件流中。

在步骤S400中，支付处理管理模块195生成有关爱丽丝向鲍勃支付5GBP的指令数据。指令数据是根据从爱丽丝接收的支付元数据生成的(可能使用第一计算设备102或第二计算设备104)，该支付元数据指示爱丽丝希望向鲍勃支付的数额、爱丽丝的支付处理资源106的实例(与从中向鲍勃支付的资金账户对应的实例)的实例标识符、爱丽丝希望支付的货币(即，GBP)、鲍勃的标识符以及与鲍勃的资金账户相关联的支付处理资源106的实例的标识符，为了简单起见，鲍勃的资金账户是由与爱丽丝相同的账户管理者管理的GBP账户。指令数据的生成包括从爱丽丝接收的支付元数据和与鲍勃的资金账户相关联的信息的组合。

然后，支付处理管理模块195使用API 108进行API调用以更新爱丽丝的余额，这也可以被理解为从爱丽丝的资金账户中借记5GBP并将该数额存入鲍勃的资金账户的请求。这是步骤S402。API调用接收由支付处理管理模块195生成的指令数据作为该调用的一部分。在进行API调用时，第一计算设备使得支付处理资源106能够接收在步骤S400中生成的指令数据。API调用还包括附加数据(也由支付处理资源106接收)，该附加数据可以包括事务标识符(可以在同一步骤中根据指令数据的哈希生成)和可以在事务中使用的其他信息(可以称为一个或多个标签)。当事务已被完成并且有关事务的信息被添加到事件流中时，标签将被包括在事件流条目中。例如，标签可能显示“从爱丽丝借记5GBP”和/或“向鲍勃支付5GBP”。API调用还包括来自爱丽丝和鲍勃账户的加密签名。加密签名可以利用ECDSA(或RSA)技术，使用与爱丽丝和鲍勃的许可证数据结构对应的私钥来生成。

事务标识符唯一地标识资金转移，并且可以使用指令数据的安全哈希算法(SHA)256哈希来形成。标签可以包括当事务被附加到事件流中时也将在事件流条目中使用的信息。标签可以被格式化为字符串阵列，其中每个字符串包括字母数字字符串。

也就是说，支付处理资源106可以基于API调用和API调用中提供的标识符来确定第一计算设备102处的爱丽丝想要与鲍勃开展事务，即事务将被处理。

在步骤S404中，解析在API调用中接收的数据以生成包含分别与爱丽丝和鲍勃的账户对应的指令和加密签名的JSON对象。这些指令将(从爱丽丝的账户)标识账户管理者、资产的标识(即，GBP)、正被转移的值(即，5GBP)、资金账户的标识符(可能与实例标识符不同)、包含对事务的引用的字母数字字符串(即，向鲍勃支付)、资金转移的时间限制以及响应数据结构，这将在下面进一步讨论。这些指令还将(从爱丽丝的账户)标识爱丽丝在创建她的资金账户时同意的条款和条件、爱丽丝同意的条款和条件的加密签名以及这些条款和条件的统一资源定位符。

这些指令还将(从鲍勃的账户)标识账户管理者、资产的标识(即，GBP)、正被接收的值(即，5GBP)、鲍勃的资金账户的标识符(可能与对应的实例标识符不同)、包含对事务的引用的字母数字字符串(即，爱丽丝的支付)、事务的随机数以及挑战数据结构，这也将在下面进一步讨论。这些指令还将(从鲍勃的账户)标识鲍勃(在创建他的资金账户时)同意的条款和条件，并且还可以包括鲍勃同意的条款和条件的加密签名以及这些条款和条件的统一资源定位符。

作为协调爱丽丝与鲍勃之间资金转移的资源，支付处理资源106可以动态管理资金转移，正如现在描述的那样，因为它管理爱丽丝和鲍勃两者提供的凭证以及与许可证数据结构和事件流的交互。这不需要存储指令数据。

可选地，这些指令可以由爱丽丝的支付处理资源106的实例作为待处理事务存储在该实例的存储器中。该存储可以由步骤S402中生成的事务标识符来标识。这些指令还可以由鲍勃的支付处理资源106的实例作为待处理事务存储在为该实例分配的存储器中。

解析在API调用中接收的数据还检索与爱丽丝的资金账户相关联的支付处理资源的实例的实例标识符。然后，在步骤S406中使用该实例标识符来检索与爱丽丝的资金账户相关联的指令数据。这些指令构成资金账户的约束以及可以使用资金账户完成的事务的限制。

与爱丽丝的资金账户相关联的指令数据可以包括账户管理者的标识符、正被转移的资产的标识符(即，GBP)、可以转移的最大值、与爱丽丝的资金账户相关联的支付处理资源的实例的实例标识符、正被处理的事务的序列号、正被处理的事务的随机数、与事务可被完成的时间段(即，最小日期和时间以及最大日期和时间)对应的字段、对事务的引用、事务的跟踪标识符、指示要采取的动作的字母数字字符串(即，借记5GBP)、一方(即，账户持有者)的标识符以及标签。

与爱丽丝的资金账户相关联的指令数据还可以包括响应数据结构，现在将描述该响应数据结构的用途。

也就是说，爱丽丝的资金账户被表示为JSON对象，该对象需要与每个所述字段对应的输入，并且该输入由所解析的数据提供。

然后，处理所解析的数据使得支付处理资源106能够使用响应数据结构和挑战数据结构来处理支付。然后，将所解析的数据传递到支付协议模块120以处理所请求的支付。支付处理资源106可以能够基于在初始API调用中提供的参数来确定需要支付协议模块120并且需要支付处理协议。或者，可以在指令数据中标识特定协议。或者，可以由通过数据通信网络传输的请求中的参数来标识特定协议。

支付协议模块120对所解析的数据应用支付处理协议，以确定爱丽丝是否有权进行支付以及是否可以进行支付，而不考虑来自爱丽丝的许可证数据结构的授权。这是步骤S408。

应用支付处理协议的第一个步骤是确定指令是否得到适当授权。这通过确定指令是来自账户持有者还是账户管理者来实现。在该示例中，指令来自爱丽丝，因此提供授权的是账户持有者。这可以使用实例数据结构170来验证，其中存储了与爱丽丝的支付处理资源106的实例对应的实例标识符。然后，支付处理协议确定爱丽丝的签名的有效性。这使用爱丽丝的许可证数据结构来执行。支付协议模块120向许可证数据存储器180发出请求，以检查爱丽丝的签名的有效性。这是步骤S410。该请求使用爱丽丝在指令数据中提供的许可证标识符来标识许可证。许可证标识符还可以从支付处理资源106维护的许可证存储器获取。该请求接收指令数据、包括爱丽丝的签名的字符串、包含与爱丽丝的资金账户相关联的事件流的当前事件流索引的引用以及爱丽丝用来提供指令数据的设备的名称(这可以包含在用于生成指令数据的支付元数据中，并在生成指令数据时传递)。

在接收到请求时，许可证数据存储器180标识与许可证标识符对应的许可证，并确定爱丽丝提供的签名是否对应于与爱丽丝的许可证数据结构相关联的加密签名。这是步骤S412。该检查返回答案YES或NO。

如果返回答案NO，则该过程失败，并向爱丽丝提供一条消息，表明事务无法继续进行。如果返回答案YES，则支付协议模块120可以移至支付处理协议的下一步骤。

然后，支付处理模块120从实例数据结构170发出对鲍勃的实例标识符(即，用于标识鲍勃的支付处理资源106的实例的标识符)的请求。这是步骤S414。这是为了检查事务对方(即，鲍勃)是否真实。

如果实例数据结构170无法提供鲍勃的实例标识符，则返回拒绝消息。这是步骤S416。这导致向爱丽丝发出拒绝，表明由于指令数据中标识的事务对方账户无效，她的事务无法继续进行。该过程失败，并且该请求不再处理。

如果实例数据结构170可以提供鲍勃的实例标识符，则支付处理模块120转到支付处理协议的下一步骤。

然后，在步骤S418中，支付处理模块120的第三实例(负责成功处理事务的实例)确认爱丽丝和鲍勃提供的指令是互补的。也就是说，支付处理资源确认与事务双方对应的指令数据是互补的，一方向另一方支付，或者换句话说，一方发送资金，另一方接收资金。这是步骤S420。

响应于否定确定，即来自鲍勃侧的指令不对应，鲍勃的支付处理资源106的实例提供拒绝消息。然后，支付处理资源106将该拒绝消息转换为拒绝事务，并将其传输给爱丽丝。然后，该过程失败，并且该请求不再处理。

如果鲍勃的支付处理资源106的实例正在提供补充指令，则支付处理模块120转到支付处理协议的下一步骤，其中处理事务数据以确定是否未突破最小和最大余额阈值。这是步骤S422。在该阶段，可能会进行检查，以查看双方的账户是否已被冻结。

如果确定阈值中的任何一个阈值已被突破和/或账户已被冻结，则支付处理资源106向爱丽丝发出拒绝，表明无法完成事务。这是步骤S424。

如果确定阈值尚未被突破和/或没有冻结命令，则支付处理模块120转到支付处理协议120的下一步骤，在该步骤中确定是否满足事务的零和要求。这是步骤S426。

为了确定是否满足零和要求，检查爱丽丝和鲍勃的指令数据中的值元素。在该示例中，爱丽丝向鲍勃支付5GBP，因此爱丽丝侧的值应为-5GBP(事实确实如此)，鲍勃侧的值应为5GBP(事实确实如此)。这是因为5GBP是从爱丽丝的账户中借记的，5GBP是从鲍勃的账户中贷记的。这意味着满足零和要求。如果鲍勃侧的值字段读数为4.90，则会有0.10未被计入，并且将不满足零和要求。由于已经满足零和要求，因此支付处理模块120可以转到下一步骤。如果不满足零和要求，则拒绝事务，并且该过程返回步骤S400。

如果满足零和要求，则支付处理模块120随后可以选择确定指令数据中是否提供了对于正在执行的特定作业正确的标签。也就是说，来自爱丽丝的指令数据中的标签是否显示“借记5GBP并从鲍勃贷记5GBP”。这是步骤S428。如果是账户管理者对指令数据进行了签名，则将处理标签以确定是否存在其他标签。例如，如果账户管理者是银行，并且事务涉及货币兑换，则应包括适当的标签。这些标签包括在指令数据中，并且通常包括在附加到事件流中以记录事务的数据中。因此，确保它们的准确性至关重要。

支付处理模块120还可以向鲍勃的支付处理资源106的实例发出请求，以确定鲍勃的实例是否正在突破最小或最大余额阈值。这是步骤S430。如果鲍勃是向爱丽丝支付的一方，则还将检查最大支付阈值。

继续执行支付处理模块120应用的步骤，对爱丽丝提供的指令数据(即，请求)应用支付处理协议。确定是否可以完成事务的剩余步骤是，基于许可证数据结构来确定爱丽丝是否具有从其支付账户向鲍勃支付所需的凭证。

现在将描述如何使用挑战数据结构和响应数据结构来核实爱丽丝的凭证，以声明她可以从引用的资金账户进行这个支付。这参考图5a和图5b来实现。

挑战数据结构由鲍勃提供，并且由鲍勃的实例提供，以请求爱丽丝能够证明她被允许开展事务。在接收到有关从爱丽丝向鲍勃的支付的指令数据时，鲍勃的支付处理资源106的实例会生成挑战数据结构。挑战数据结构包括挑战数据结构的标识符。挑战数据结构的标识符可以是字母数字序列或数字序列。挑战数据结构的标识符可以是随机或伪随机生成的。挑战数据结构还包括要核实的数据项的随机数。数据项的随机数将与响应数据结构中提供的随机数结合使用，并且当数据项被核实时，这将构成爱丽丝的支付处理资源106的实例提供的加密签名的基础(如下所述)。挑战数据结构还包括正被核实的数据项。该数据项可能具有反向DNS域类结构(即，com.example.user.id)。该数据项可以是字符的带有命名空间的字母数字序列。或者，该数据项可以是字符的任何字母数字序列。可以是人类可以理解的表达式，也可以是随机生成的字符集合。该数据项表示爱丽丝声称她可以支付。也就是说，该数据项表示爱丽丝在指示支付处理资源106处理对鲍勃的支付时声明的凭证。该数据项可以是如上关于许可证数据结构描述的表达式。

响应数据结构由爱丽丝在与她的支付处理资源106的实例相关联的指令中提供。当接收到向鲍勃支付的指令时，响应数据结构可以由爱丽丝的支付处理资源106的实例生成。响应数据结构包括响应数据结构的标识符。该标识符可以是字母数字序列或数字序列。挑战数据结构的标识符可以是随机或伪随机生成的。响应数据结构还包括随机数。响应数据结构还包括爱丽丝拥有的对应许可证数据结构的标识符。响应数据结构还可以包括标识爱丽丝使用的设备的标识符。

响应数据结构还包括响应数据结构中提供的随机数和挑战数据结构中提供的随机数的级联的SHA256哈希的加密签名。加密签名可以基于与爱丽丝拥有的公钥对应的私钥(即，与响应数据结构中标识的许可证数据结构对应的公钥)来生成。加密签名还可以使用在与爱丽丝相关联的数字钱包中找到的(与公钥)配对私钥来生成。现在描述生成响应数据结构的步骤。

在步骤S500中，支付处理资源106检索鲍勃提供的挑战数据结构。在步骤S502中，支付处理资源106使用挑战数据结构的标识符来搜索响应数据结构。响应数据结构的标识符应与挑战数据结构的标识符匹配。

在该示例中，响应数据结构由爱丽丝在步骤S400中提供作为她的指令数据的一部分，并且是满足挑战数据结构相关要求的响应数据结构，以证明许可证数据结构的所有权(正如现在所阐述的)。稍后将描述如果最初没有提供响应数据结构并且需要请求，支付处理资源106将如何继续进行。也就是说，支付处理资源106在爱丽丝已经提供的内容中找到具有对应标识符的响应数据结构。当响应者(即，爱丽丝)已经知道挑战者(即，鲍勃)将寻求哪个许可证数据结构来支持核实爱丽丝的支付权限时，可能会发生这种情况。也就是说，响应者已经知道鲍勃将从她的许可证数据结构中寻求核实哪个数据项，并且可以基于许可证数据存储器180中的对应许可证数据结构来相应地生成随机数和签名。当爱丽丝提供指令数据时，响应数据结构中的随机数将在步骤S400中生成。当相应各方就爱丽丝向鲍勃的支付达成一致时，将生成挑战数据结构中的随机数。然后，支付处理管理模块195可以生成随机数的级联的加密签名，然后将其提供在爱丽丝提供的指令数据中包括的响应数据结构中。级联可以包括来自响应数据结构的随机数，随后是来自挑战数据结构的随机数。

然后，在步骤S504中，支付处理资源106从响应数据结构中提取随机数的级联的加密签名。在步骤S506中，使用已知的签名验证技术(例如，PKI)来验证该签名。然后，支付处理资源106转到步骤S508，在该步骤中，该支付处理资源核实第一随机数和第二随机数的级联的SHA256哈希的加密签名。如果核实表明签名无效，则支付处理资源106向爱丽丝和鲍勃提供失败的事务消息，其中包含爱丽丝无法开展事务的消息。这是步骤S510。

与爱丽丝和鲍勃相关联的指令数据可能不提供相应的响应数据结构和挑战数据结构；或者，如步骤S510中所述，相应的响应数据结构和挑战数据结构不会使得能够核实爱丽丝向鲍勃支付5GBP的授权。现在将参考图5b描述如果指令数据中提供的响应数据结构没有提供有效签名或完全没有被提供，则鲍勃的支付处理资源106的实例可以如何检查爱丽丝是否可以进行支付。

在步骤S512中，鲍勃的支付处理资源106的实例将生成挑战数据结构(如果该挑战数据结构尚未在指令数据集中生成或提供)。

挑战数据结构将包含要核实的数据项，以便处理(从爱丽丝)向鲍勃支付5GBP的事务。该数据项可以是字母数字序列，其内容类似于“uk.co.Alice-Bank-Account”。替代地或附加地，该数据项可以是纯数字序列，例如“31415192”。挑战数据结构还包含随机数。该随机数可以基于数据项随机生成，或者可以独立于数据项随机生成。此外，为挑战数据结构分配标识符。

然后，在步骤S514中，将挑战数据结构提供给爱丽丝的支付处理资源106的实例。然后，爱丽丝的支付处理资源106的实例被配置为根据待处理指令数据集来确定是否已经提供响应数据结构(对于该示例来说，尚未提供)，然后在没有提供响应数据结构的情况下，向许可证数据存储器180发出查询(使用爱丽丝的许可证数据结构的标识符)，以获取对应的许可证数据结构(即，由爱丽丝拥有)，该对应的许可证数据结构包含字母数字序列“uk.co.Alice-Bank-Account”并且在提出请求时是有效的。该核实步骤在步骤S516中执行。总之，核实步骤旨在确定表达式“uk.co.Alice-Bank-Account”是否与对应的许可证数据结构相关联，即该表达式是否存在于与爱丽丝的许可证数据结构相关联的权限中。

也就是说，查询许可证数据存储器180，以确定爱丽丝的支付处理资源106的实例是否与包含字母数字序列“uk.co.Alice-Bank-Account”的许可证数据结构加密关联，以及对应的许可证数据结构是否仍然有效。

包含字母数字序列“uk.co.Alice-Bank-Account”的有效许可证数据结构的存在确保爱丽丝已经通过指定的KYC过程(由她的账户管理者执行)并被账户管理者允许开展该事务。

在步骤S516中发出的查询以字母数字序列作为参数。可选地，还可以接收其他参数，因为查询还可以携带以下各项：用于所提供的字母数字序列类型的标志；与爱丽丝的支付处理资源的实例相关联的事件流的索引(以便在进行查询(在步骤S516中发出)时核实与支付处理资源的实例相关联的事件流中的最后一个条目的索引)；指示爱丽丝使用(或过去使用)以向支付处理资源106提供指令的设备的名称的扩展。

如果许可证数据存储器确实返回爱丽丝拥有的许可证数据结构(即，可以用爱丽丝的许可证数据结构的标识符来标识的许可证数据结构)，并且与爱丽丝的许可证数据结构相关联的权限(即，permissionSet)包含字母数字序列“uk.co.Alice-Bank-Account”，则在步骤S518中，支付处理资源106将生成响应数据结构，该响应数据结构包含挑战数据结构的标识符、挑战数据结构中提供的随机数、爱丽丝拥有的并包含字母数字序列的许可证的标识符、指示爱丽丝使用的设备的名称的扩展，以及挑战数据结构中提供的随机数与挑战数据结构中提供的随机数的另一副本的级联的SHA256哈希的加密签名。加密签名可以由爱丽丝使用她的私钥(即，与许可证数据结构中标识的公钥对应的私钥)来生成。加密签名还可以使用在与爱丽丝相关联的数字钱包中找到的与爱丽丝相关联的私钥来生成。由于爱丽丝的支付授权已被核实，因此事务可以继续进行。这是步骤S520。然后，支付处理资源106转到事务的下一步骤，如下面关于生成会合区块链事务(rendezvous blockchaintransaction)所描述的。

如果许可证数据存储器不返回爱丽丝拥有的并且包含字母数字序列“uk.co.Alice-Bank-Account”的许可证数据结构，则支付处理资源106继续拒绝事务。这是步骤S522。

如果在挑战数据结构中提供了多个字母数字序列，则可以重复步骤S512至步骤S522，直到许可证数据存储器返回爱丽丝拥有的许可证数据结构，该许可证数据结构包含所提供的字母数字序列中的一个字母数字序列(来自挑战数据结构)。

替代地或附加地，如果在爱丽丝提供的指令数据集中提供了响应数据结构，则对于来自挑战数据结构的每个提供的字母数字序列，支付处理资源106可以检查签名是否正确以及对应的许可证是否存在。

也就是说，对于来自挑战数据结构的每个字母数字序列，支付处理资源106形成来自响应数据结构和挑战数据结构的相应随机数的级联。然后，支付处理资源106通过提供来自爱丽丝提供的响应数据结构的级联和加密签名来向许可证数据存储器查询许可证数据结构。支付处理资源还提供来自响应数据结构的许可证标识符，以标识应在其中找到对应签名的许可证。当进行查询时，该查询还可以提供包含与爱丽丝的支付处理资源106的实例相关联的事件流的索引的参数。该查询还可以包含爱丽丝在事务被处理时使用的设备的指示符。

为了核实加密签名，使用存储在所检索的许可证数据结构中的公钥来构建签名，以便检查它是否在所提供的随机数组合上返回相同的签名。如果是，则认为响应数据结构中提供的加密签名有效。如果否，则因未提供开展事务的授权而拒绝响应数据结构。

响应于确定加密签名有效，支付处理资源提供对与要核实的加密签名对应的相应字母数字序列的请求。这包括向许可证数据存储器提供对要核实的相应字母数字序列的请求。这包括向许可证数据存储器提供(所标识的许可证的)许可证标识符，并请求返回由许可证标识符标识的许可证数据结构，并且在返回许可证数据结构时检查是否在所标识的许可证数据结构中找到对应的字母数字序列。如果在所标识的许可证结构中找到对应的字母数字序列，则接受爱丽丝的支付授权。如果在所标识的许可证结构中没有找到对应的字母数字序列，则拒绝爱丽丝的支付授权。然后，支付处理资源106可以继续进行事务并生成会合区块链事务，这将参考图6进行描述。

会合事务(rendezvous transaction)是一种区块链事务，可以包括多个尘埃链输入/输出对和标记有OP_RETURN操作码的输出，以使输出不可花费并允许添加数据载体。OP_RETURN操作码导致立即结束执行对应的兑换脚本，并使其无效，即输出无法兑换。这意味着输出无法花费，并且数据载体作为会合事务的一部分保留在区块链上。尘埃链输入/输出对在事务中可以具有相同的索引，并且可以分别进行输入资金和变更输出。数据载体可以是最终输出。构成会合事务的多个尘埃链输入可以来自不同的相应事件流。

在步骤S600中，支付处理资源106随后向事件流管理资源110发出请求，以基于与爱丽丝和鲍勃(以及作为其账户管理者的汇丰银行)中的每一个相关联的相应事件流建立会合区块链事务。这将参考图7中的说明性示意图进行描述。也就是说，对于爱丽丝，请求事件流管理资源110访问爱丽丝的账户的当前状态(与鲍勃的事件流类似)。下面参考图8和图9描述尘埃链及其与事件流的关系。

针对爱丽丝检索到的区块链事务702包括尘埃输出(Tx0，爱丽丝)，并且针对鲍勃检索到的区块链事务704包括尘埃输出(Tx0，鲍勃)。

然后，支付处理资源106生成新的会合区块链事务406，该新的会合区块链事务包括爱丽丝和鲍勃中的每一个的尘埃输入，该尘埃输入花费来自在步骤S600中检索到的区块链事务的相应尘埃输出。这是步骤S602。尘埃输出可以从对应于与爱丽丝和鲍勃相关联的事件流的尘埃链中检索。图7中也示出了这一点。702与704至706之间的事务链可以被描述为尘埃事务链，并且爱丽丝和鲍勃中的每一个都将存在一个尘埃事务链，对应于他们各自的事件流。在本公开的区块链事务上下文中，“尘埃”被理解为数字资产的可花费事务，该数字资产的输出具有低价值或极小价值，即该价值可以远远小于在区块链中挖掘输出的费用。也就是说，新的会合事务通过生成事务来同步以爱丽丝和鲍勃名义的事件流，该事务将支持附加到两个事件流的条目。

或者，支付处理资源106可以使用不构成预先存在的事件流的一部分的尘埃和分层确定性(HD)密钥链的组合来生成新的尘埃事务，如申请号为2102217.3的英国专利申请案中所描述的。换句话说，生成尘埃事务，该尘埃事务使用尘埃作为输入并且包括与爱丽丝和鲍勃中的每一个对应的输入，其中该尘埃先前尚未在事件流中使用。拥有HD密钥链的一方可以使用其中一个子密钥和尘埃来生成新事件流中的第一事务。简而言之，可以基于尘埃来发起新事件流，该尘埃可以从区块链112上的现有事务中检索并用作新事件流开始的基础。也就是说，该尘埃可以用于生成事务(以便启动新事件流)，然后在用于发起另一事件流之前返回到平台。

现在将参考图8进一步阐明尘埃事务链与事件流之间的关系。

图8示出了有序的仅附加的数据存储系统的基本数据结构和范例。这也可以被描述为数据记录系统。图8所示的特定系统是用于记录事件的事件流系统。例如，事件流全文用于说明性目的，然而，本领域技术人员将会理解，本文中描述的所提出系统和方面一般可以与数据记录一起使用，还可以与有序的仅附加的数据项记录或存储系统一起使用。数据记录是指实际数据的哈希。该哈希可以是正被记录在与各方相关联的支付处理资源106的实例对应的事件流中的事务的指令数据的哈希。使用哈希代替数据本身有利地为数据提供了存在证明，而不需要将数据(对于事务来说可能很大，甚至过大)存储在事务上。这还保护了数据的隐私，因为即使哈希在链上发布，数据也无法与哈希区分开来。这里描述的数据是与支付处理资源106正在记录的支付相关的支付指令数据。

仅附加日志中的每个事件502被映射到区块链事务504，并且区块链事务的序列被排序并使用“尘埃链”链接506。与每个事件相关联的数据作为每个事务的一部分存储在有效载荷(下面描述)中。数据有效载荷(即，支付指令元数据的哈希)保存在事务的不可花费OP_RETURN输出中，此类事务的示例是如上所述的会合事务706。这是脚本操作码，其可以用于在区块链上写入任意数据，也可以将事务输出标记为无效。再如，OP_RETURN是脚本语言操作码，用于创建事务的不可花费输出，其可以将元数据等数据存储在事务中，从而将元数据不可变地记录在区块链中。

尘埃的链(或尘埃链)是一个不间断的输入和输出的链，这里使用这些输入和输出链将序列中的每个区块链事务在其直接的前任事务上施加花费依赖性。

在事务中使用尘埃输出对于维护所有事务在事件流等有序的仅附加的数据存储系统中发生时的不可变顺序记录是有利且至关重要的。这是因为，尽管通过将事务发布到区块链，所有区块链事务都将带有时间戳，并且一旦在区块链上确认或添加，则按顺序保留在区块链中，但这并不保证其顺序保持不变。这是因为，事务可能在不同时间被挖掘到区块中，和/或事务甚至按不同顺序处于同一个区块内。使用由序列中的下一个事务的第一输入所花费的尘埃输出有利地确保事务的顺序按时间顺序跟踪，并且对事件本身和事件的序列排序创建防篡改记录。这是因为，一旦挖掘到区块中，从序列中的上一个事务到下一个事务的尘埃支付即可确保：根据一些区块链协议规则，称为有效载荷的嵌入数据载体元素的序列无法重新排序，并且不会发生插入或删除，这可能会改变序列，而不会立即明显地表明事件流已被破坏。在一些实施例中，双重花费保护机制确保尘埃在不同事务输入和输出之间的移动保持时间顺序。尘埃事务的链接利用拓扑排序可以保持区块间和区块内事务(以及相关的事件和数据)顺序。因此，这改进了有序的仅附加的数据项存储的完整性。

以这种方式，区块链事务504形成事务的有向图。应当注意的是，图形的方向可以被认为是单向的，即从序列中的上一个事务指向下一个事务，如边缘806所示。虽然图8中的边缘506上的箭头指示指向下一个事务，但是事务中的花费关系实际上是从一个事务到上一个事务。该图是通过事务之间的花费关系创建的。这些花费关系可以被认为是一种引用类型。关于如何将事件附加到事件流中的更多详细信息可以在申请号为2102314.8的英国专利申请案中找到，具体地但不完全地，其中提到了“有序的、仅附加的数据存储”、“事件流和尘埃链”和“尘埃链中的向后引用”。

会合区块链事务(例如，图7中所示的事务706)是用于同步多个事件流的区块链事务，每个事件流与上述给定实体/用户相关联。这通过花费多个尘埃输出作为对应的输入来实现。在该示例中，这允许与爱丽丝、鲍勃中的每一个对应的尘埃链(即，尘埃输入/输出对)通过单个事务。尘埃链输入/输出对在事务中必须具有对应的输入/输出索引。在这种情况下，使用尘埃链输入/输出对(如下所述)，以使得支付能够记录在与事务相关联的所有事件流中。

花费爱丽丝的尘埃输出的尘埃输入被表示为Tx1,Alice，而花费鲍勃的尘埃输出的尘埃输入被表示为Tx1,Bob。在步骤S602中生成新的会合区块链事务706。

会合区块链事务706中的资金由支付处理资源106添加，并将返还给支付处理资源106。可以将会合区块链事务706发送到区块链112进行核实。

会合区块链事务706包括其他尘埃输出，该其他尘埃输出分别花费Tx1,Alice和Tx1,Bob。由于是会合事务，因此分别对应于爱丽丝和鲍勃的输入/输出对的索引是相同的，例如，可以将Tx1,Alice的输入索引分配为编号1，并且将对应的尘埃输出的输出索引分配为输出索引编号1。

支付处理资源106还以数据载体712a和712b的形式向爱丽丝和鲍勃中的每一个的区块链事务706添加可证明不可花费的输出。

这些数据载体中的每个数据载体可以保存不同的数据摘要和/或不同的流摘要，其中流摘要也可以进行加盐处理。

相应数据载体内保存的数据有效载荷(即，支付指令元数据的哈希)保存在事务的不可花费OP_RETURN输出中，这意味着数据有效载荷随后可以作为不可花费输出存储在区块链中。

数据载体712内的数据包括支付处理资源195生成的指令数据的哈希。该哈希在步骤S334中生成。可证明不可花费的输出使得会合事务706能够携带事务中支付指令数据集的哈希，并且使得哈希能够存储在区块链上。这意味着支付指令数据集以及支付记录存储在区块链上。这意味着支付记录受益于区块链的不可变性。

然后，可以检查区块链事务706，以查看用户与事务的对应是否正确并且是否对应于用户(即，爱丽丝和鲍勃)。这是步骤S604。

支付处理资源106向事件流资源110发出通知，确认在步骤S602中生成的区块链事务706可以用作将数据附加到事件流(即，关于爱丽丝和鲍勃的事件流)中的基础。

事件流是区块链支持的仅附加日志。在该示例中，爱丽丝和鲍勃各自具有自己的事件流，但如果不具有，则可以初始化事件流。也就是说，爱丽丝具有事件流(E-Alice)，鲍勃具有事件流(E-Bob)。事件流中的条目可以表示为ESn，其中n可以是非零正整数或非负整数。

如图8所示，事件流可以被示为一系列条目，其中流中的任何条目都可以通过单调增加的序列号来引用，即第一条目可以被称为ES1，第二条目可以被称为ES2。

只有在爱丽丝和鲍勃被授权访问或附加事件流的情况下，支付处理资源106才附加到相应事件流中。例如，可以通过将用于对指令数据进行签名的加密签名与支付处理资源106处存储的签名进行比较来检查授权。通过将支付数据附加到事件流中，可以记录支付并受益于记录在与区块链112相关联的不可变日志中。简而言之，事件流用于跟踪与爱丽丝和鲍勃相关联的账户的事务顺序。也就是说，事件流中的条目是与区块链112相关联的不可变日志。上述事件流确保：

●事件流中的各个条目自写入后未曾修改；

●先前连续条目之间未插入任何条目；

●未删除任何条目；

●未对任何条目进行重新排序；

●未经授权方不得将事件附加到流中。

支付处理资源106通过以下方式，使用会合事务706来使支付与事件流E-Alice和E-Bob同步：向这些事件流中的每个事件流附加条目，该事件流包含区块链事务706中的数据载体中包含的支付指令元数据的哈希。这是步骤S608。图9中示意性地示出了这一点。账户管理者(例如，汇丰银行)还可以具有事件流E-HSBC，该事件流还附加有指令数据的哈希。

然后，支付处理资源706生成添加到这些事件流中的每个事件流的条目的标识符。这是步骤S610。标识符可以是字母数字标识符，也可以是基于指令数据的哈希生成的数字。例如，如果指令数据的哈希是由SHA256密码生成的，则可以通过对指令数据的哈希应用另一SHA256密码来生成标识符。也就是说，标识符可以是指令数据的哈希的哈希。

然后，支付处理资源106将标识符与指令数据的副本一起存储在支付数据存储器124中。这使得能够根据要求验证爱丽丝与鲍勃之间的支付。支付处理资源106还将用于对指令数据进行签名的加密签名与标识符一起存储。

支付处理资源106还与支付数据存储器124相关联地维护事件流中存储的所有指令数据集的日志，该事件流与和支付处理资源106的每个实例相关联的事件流相关联。这可以用于防止将重复事务附加到事件流中。

也就是说，在向支付处理资源106传输消息之后处理来自爱丽丝向鲍勃的支付，该支付处理资源随后使用许可证数据结构和支付处理协议来确定是否可以进行支付以及应该做出什么响应，即事务是否应该继续进行。

现在参考图10描述如何调整支付处理资源106的实例的设置。

为了更改与支付处理资源106的实例对应的设置，第一计算设备102提供对API108的调用，该API标识与设置调整相关的支付处理资源106的相应实例的实例标识符。这是步骤S1000。基于该API调用和实例标识符，支付处理资源106可以确定正在提出更改设置的请求，并且需要应用调整后的设置协议。

该请求还包括指令数据集，该指令数据集包括与通过API 108提供请求的时间对应的时间戳、标识与第一计算设备102对应的特定计算设备的扩展、对最大余额的所请求调整(如果正在调整)、对最低余额的所请求调整(如果正在调整)、用于指示资金账户中要持有的货币数额的冻结数额(如果正在调整)、要冻结的账户的实例标识符(如果正在冻结)、与冻结命令的法律依据对应的字段、用于支付处理资源106的实例的标签(如果正在进行调整)、账户用于提供余额更新的小数点数(如果正在调整)、与支付处理资源106的实例相关联的资金账户的花费限制(如果正在调整)以及账户持有者提供的加密签名。

在步骤S1002中处理请求中提供的调整后的设置，以确定设置调整是否正确(即，不违反支付处理资源106的要求)。例如，如果数据无效，则设置调整可能不正确。例如，一个示例可能是时间戳，该时间戳是一个负数。另一示例可能是要冻结的账户的实例标识符不正确，即与请求中标识的账户的实例标识符不匹配。另一示例可能是最小余额大于最大余额。如果设置调整不正确，则支付处理资源106将向第一计算设备发出失败的请求消息。这是步骤S1004。在包含多个调整的请求中，支付处理资源106可以被配置为在发现其中一个调整不正确的情况下拒绝对所有调整的请求。

如果设置调整正确，则支付处理资源106将继续检查请求中提供的加密签名。这是步骤S1006。

实例标识符与对应于支付处理资源106的实例的许可证数据结构的对应许可证标识符一起存储在实例数据结构170中。支付处理资源106从实例数据结构170中检索许可证标识符。然后，支付处理资源106向许可证数据存储器180发出请求，以检查步骤S1000中请求中提供的加密签名。

这将涉及在请求中提供数据(即，已经使用加密签名的数据)以及加密签名，以便可以使用合适的技术来验证加密签名。如果请求中提供的加密签名与公钥生成的加密签名相同，则可以在步骤S1008中继续进行设置调整的请求，然后生成响应以确认设置被更新。然后，可以将对设置的更改记录在与支付处理资源106的实例对应的事件流中。可以生成指令数据的哈希并将其包括在事件流中，并且可以将其包括在对第一计算设备102确认设置更改的响应中。如果所比较的签名不相同，则在步骤S1010中向第一计算设备102发出拒绝消息。

关于图10描述的过程可以用于更改支付处理资源106的实例的设置。确定设置更改正确以及检查签名可以形成调整后的设置协议。这可以用于更改最大余额和最小余额，但也可以用于冻结或解冻账户。在接收到更改设置的请求时，检查许可证数据结构以查看签名是否正确。如果正确，则可以进行调整。如果不正确，则无法进行调整。

在某些情况下，账户管理者可以生成设置更改并提供步骤S1000中描述的调用。在这种情况下，账户管理者可能会检查其许可证数据结构，以确保许可证数据结构提供进行更改的权利。

现在将描述如何使用用于对指令数据进行签名的加密签名来防止处理重复事务以及将重复条目添加到相关联的事件流中。这将参考图11进行描述。虽然这是针对支付处理资源106的单个实例进行描述的，但是应当理解的是，这可以应用于事务中涉及的支付处理资源106的每个实例。

在步骤S1100中，支付处理资源106接收处理事务的请求。该请求包括如上在步骤S400中所述的指令数据。该请求标识支付处理资源106的实例，解析指令数据(在步骤S404中)可以标识事务的其他各方(即，鲍勃)，并且因此标识事务处理中涉及的其他实例。

在步骤S1102中，支付处理资源106标识借方(在上面的示例中是爱丽丝)用来对指令数据进行加密签名的加密签名。

或者，支付处理资源106可以标识事务的另一方(例如，贷方)的签名。

在步骤S1104中，支付处理资源106访问支付数据存储器124，以确定加密签名是否已经记录在支付数据存储器124中，即作为已经开展并且将在与事务中涉及的各方相关联的事件流中的事务。支付数据存储器124可以根据任何合适的值对事务进行分类，例如事务日期、用于对指令数据进行签名的加密签名或任何其他合适的值。

如果加密签名已经存在于支付数据存储器124中，则很可能已经对事务进行处理，并且在步骤S1106中提供拒绝消息。在一些实施例中，支付数据存储器124中的日志可以仅在预定义的时间段(例如，前30天)内检查，或者检查可以仅限于最近的100个条目。

如果加密签名尚未存在于支付数据存储器124中，则事务很可能尚未被处理，并且事务转到步骤S406至步骤S428以及步骤S500至步骤S520中概述的步骤。

也就是说，支付处理资源106可以确定事务先前可能已被处理。重复事务(即，同时执行相同的指令)对于账户持有者和账户管理者来说都是不可取的，需要予以防止。

爱丽丝和鲍勃(使用先前示例)可能同时提交指令数据，这将为爱丽丝生成继续响应，并为鲍勃生成拒绝响应。在这种情况下，支付处理资源106随后可以在指定的时间段(例如，100-300毫秒)后通过重新处理来作出响应，以允许正确更新对应的事件流，并且因此可以再次确定是否存在重复。

应当注意的是，上述方面和实施例是说明而不是限制本公开，并且本领域技术人员在不脱离由所附权利要求书所限定的本公开的范围的情况下将能够设计许多替代实施例。在权利要求书中，括号中的任何附图标记都不应解释为对权利要求的限制。词语“包括”等不排除任一项权利要求或说明书中整体列出的元件或步骤之外的元件或步骤的存在。在本说明书中，“包括”是指“包含”或“由......组成”。元件的单数形式并不排除此类元件的复数形式，反之亦然。本公开可以通过包括几个不同元件的硬件以及通过适当编程的计算机来实现。在列举几个装置的设备权利要求中，这些装置中的几个装置可以由同一硬件来体现。在互不相同的从属权利要求中引用某些措施的事实并不意味着不能有利地使用这些措施的组合。

Claims (12)

1.一种计算机实现的方法，用于核实在资产转移事件期间提供的至少一个数据项，所述方法通过处理资源来实现，所述方法包括：

从计算设备接收请求数据，所述请求数据包括：

-指令数据集，所述指令数据集包括与所述资产转移事件相关联的实体的标识符；

-挑战数据结构，其中所述挑战数据结构包括：

○所述至少一个数据项的第一数字标识符；

○所述至少一个数据项的表示；

通过以下方式确定所述至少一个数据项的有效性：

-通过确定在所述指令数据集中或在与所述实体相关联的许可证数据结构中存在对应的凭证，确定所述至少一个数据项的所述表示与在所述许可证数据结构中存储的数据项之间的一致性；

针对相应指令数据集或许可证数据结构中的所述对应的凭证生成第二数字标识符；

生成响应数据，所述响应数据包括：

-所述对应的凭证的标识符；

-所述第二数字标识符；

-与所述第一数字标识符和所述第二数字标识符相关联的签名；

将所述响应数据发送到所述计算设备。

2.根据权利要求1所述的方法，其中所述第一数字标识符和所述第二数字标识符是针对相应数据项或响应数据生成的随机数。

3.根据权利要求1或2所述的方法，其中所述第一数字标识符和所述第二数字标识符的组合是所述第一数字标识符和所述第二数字标识符的级联。

4.根据权利要求3所述的方法，其中所述第二数字标识符位于所述第一数字标识符和所述第二数字标识符的所述级联中的第一位置。

5.根据前述任一项权利要求所述的方法，其中所述数据项的所述表示包括字符的至少一个字母数字序列。

6.根据前述任一项权利要求所述的方法，其中确定所述数据项的所述表示与许可证数据结构中存储的数据项之间的一致性包括以下步骤，其中所述许可证数据结构与所述实体相关联：

-从所述挑战数据结构获取所述数据项的所述表示；

第2/2页

-查询所述指令数据集以获取与所述数据项对应的凭证；以及

-基于所述查询，检索与所述凭证对应的标识符，或者查询与所述实体的所述标识符相关联的许可证数据结构以获取与所述数据项对应的凭证；以及

-基于对所述许可证数据结构的所述查询，检索对应于与所述数据项对应的所述凭证的标识符。

7.根据权利要求6所述的方法，其中如果所述相应指令数据或许可证数据结构包含包含所述数据项的相同表示的字段，则所述查询返回与所述数据项对应的凭证。

8.根据权利要求6所述的方法，其中如果所述相应指令数据或许可证数据结构不包含包含所述数据项的相同表示的字段，则所述查询提供拒绝响应。

9.根据前述任一项权利要求所述的方法，其中所述挑战数据结构还包括所述挑战数据结构的标识符，并且所述响应数据包括所述响应数据结构的标识符。

10.根据权利要求9所述的方法，其中所述挑战数据结构的所述标识符和所述响应数据结构的所述标识符相同。

11.一种计算机实现的方法，用于在资产转移事件期间核实至少一个数据项，所述方法通过第一处理资源来实现，所述方法包括：

生成请求数据，所述请求数据包括：

-指令数据集，所述指令数据集包括与所述资产转移事件相关联的实体的标识符；

-挑战数据结构，其中所述挑战数据结构包括：

○所述至少一个数据项的第一数字标识符；

○所述至少一个数据项的表示；

将所述请求数据发送到第二处理资源；

从所述第二处理资源接收响应数据；

通过以下方式核实所述数据项：根据所述响应数据来确定存在第二数字标识符与所述第一数字标识符相结合的组合的签名。

12.一种系统，所述系统包括被配置为实现根据权利要求1至10中任一项所述的方法的硬件。