CN117795516A

CN117795516A - 一种计算机实现的方法和系统

Info

Publication number: CN117795516A
Application number: CN202280053915.1A
Authority: CN
Inventors: 瑞奇·查尔斯·兰德
Original assignee: Blockchain Licensing Jsc
Current assignee: Blockchain Licensing Jsc
Priority date: 2021-08-03
Filing date: 2022-08-01
Publication date: 2024-03-29
Also published as: WO2023012127A1; TW202308351A; US20240323018A1; JP2024529317A; KR20240041944A; GB202111189D0; EP4381410A1

Abstract

详细描述了用于建立委托授权的计算机实现的系统和方法。验证和生成委托授权通证的方法包括获取委托授权通证链中的第一委托授权通证。所述委托授权通证链中的其他委托授权通证基于所述委托授权通证链中的先前委托授权通证来生成。如果验证委托授权通证的有效性，则基于所述委托授权通证链中的所述委托授权通证中的一个委托授权通证与预定值的比较来验证所述第一委托授权通证的有效性。

Description

一种计算机实现的方法和系统

技术领域

本公开涉及用于实现与一个或多个客户端的分布式分类账(即，区块链)相关联的一项或多项服务的平台的方法和系统。更具体地，本公开提供但不限于提供对与区块链相关联的服务的委托访问。

背景技术

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

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

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

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

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

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

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

当前研究的一个领域是使用区块链实现“智能合约”。这些是设计成自动执行机器可读合约或协议条款的计算机程序。与以自然语言编写的传统合约不同，智能合约是机器可执行程序，它包括能够处理输入以产生结果的规则，然后使得根据这些结果执行动作。与区块链相关的另一关注领域是使用“通证(token)”(或“彩色币”)来表示现实世界的实体，并通过区块链转移现实世界的实体。潜在的敏感或保密项目可以由无可辨别意义或价值的通证表示。因此，通证充当允许从区块链引用现实世界项目的标识符。

利用区块链的优点提供永久性防篡改事件记录时，上述示例或场景需要客户端、客户端实体、计算设备或与客户端相关联的终端，以包括或实现软件和/或硬件或处理器/模块，例如一种数字钱包，这种数字钱包用于实现用于管理数字资产以及管理由(例如，比特币中本聪愿景BSV等)区块链使用的椭圆曲线数字签名算法(ECDSA)的加密密钥的功能。此外，客户端设备还需要能够实现区块链事务构建并能够访问BSV库。因此，客户端不仅需要包括实现此类功能的处理，还需要确保在能够利用区块链网络发送、接收和查看数据和/或数字资产之前，对此类流程实施适当的安全措施，其中所述数据和/或数字资产涉及智能合约或表示现实世界资产事务的通证。

发明内容

根据第一方面，提供了一种计算机实现的方法，所述方法包括：获取预定值；接收请求，所述请求包括委托授权通证链中的第一委托授权通证；生成所述委托授权通证链中的多个其他委托授权通证，其中对所述委托授权通证链中的每个其他委托授权通证进行的所述生成是基于所述委托授权通证链中的先前委托授权通证而进行的；基于所述委托授权通证链中的多个所述委托授权通证中的一个委托授权通证与所述预定值的比较来确定所述第一委托授权通证的有效性。

根据第二方面，提供了一种计算机实现的方法，用于生成相关联的委托授权通证链，所述方法包括：获取第一值和第二值；生成所述委托授权通证链中的第一委托授权通证，所述第一委托授权通证基于所述第一值和所述第二值；以及，生成所述委托授权通证链中的至少一个其他委托授权通证，其中对所述委托授权通证链中的每个其他委托授权通证进行的所述生成是基于所述第一值和所述委托授权通证链中的先前委托授权通证而进行的。

根据第三方面，提供了一种核实根据第一方面所述的通证的方法，并且其中第一委托授权通证已经由客户端根据第二方面生成。

根据第四方面，提供了一种方法，所述方法包括以下步骤：接收根据第二方面所述的方法生成的委托授权通证；生成请求，所述请求包括所述委托授权通证；以及将所述请求发送到服务器。

根据第五方面，提供了一种系统，所述系统包括：服务器；代表者；以及客户端，所述客户端被配置为：根据第二方面来生成委托授权通证链和第一值；向所述服务器传输所述第一值和所述委托授权通证链中的最终委托授权通证；以及向所述代表者传输所述委托授权通证链中的所述委托授权通证中的一个委托授权通证。

现在参照附图以图示方式描述所公开方法的一些特定组件和实施例，其中相似的附图标记表示相似的特征。

附图说明

第4/43页

图1描绘了用于实现区块链的示例性系统；

图2示出了示例性事务协议；

图3A和图3B示出了客户端应用程序及其用户界面的示例性实现方式；

图4示出了在网络的每个区块链节点上运行的节点软件的示例；

图5是示出平台处理器、数据库、区块链网络、客户端与代表者之间交互的示意图；

图6示出了用于生成委托授权通证的方法；

图7示出了用于分发代表者与服务交互所需信息的方法；

图8示出了用于核实委托授权通证的方法；

图9A至图9D示出了与核实委托授权通证相关的示例和实施例；

图10A至图10E示出了与事件流服务交互的示例；

图11是总体描绘根据一个方面的用于与区块链相关联的多项服务的平台的示意图；

图12是描绘根据一个方面的用于与区块链相关联的多项服务的平台的组件的示意图；

图13是示出可以实现本公开的各个方面和实施例的计算环境的示意图。

具体实施方式

因此，需要实现安全、低复杂度、用户友好、高效和稳健的技术，这些技术将允许任何客户端(无论在计算上是否复杂)能够以简单、快速、准确、可靠和安全的方式即时访问与区块链相关联的有用应用程序并与其交互，该方式在计算上和功能上不那么繁琐。更具体地，希望允许客户端批准的代表者也以优选的安全、可靠和/或可撤销的方式从此类系统中受益。

现在已设计出这种改进的解决方案。本公开通过提出一种或多种技术来解决上述技术问题，由此数据可以由已经委托授权delegated authorisation(和/或拥有委托授权通证delegated authorisation token)的用户简单地、安全地和/或即时地写入到所述区块链中或从所述区块链获取，以用于写入、读取或与所述区块链相关联的其他动作。为与区块链相关联的一项或多项服务(以及具体地这些服务的委托)提供应用程序编程接口(API)的方法、设备和系统，不需要此类客户端实现用于使用所述区块链的任何处理或功能，也不需要实现用于用户管理的任何处理或功能，同时仍然能够利用与所述区块链及其委托授权相关联的所有优点。

根据第一方面，提供了一种计算机实现的方法，所述方法包括：获取预定值；接收请求，所述请求包括委托授权通证链(a chain of delegated authorisation tokens)中的第一委托授权通证；生成所述委托授权通证链中的多个其他委托授权通证，其中对所述委托授权通证链中的每个其他委托授权通证进行的所述生成是基于所述委托授权通证链中的先前委托授权通证而进行的；基于所述委托授权通证链中的多个所述委托授权通证中的一个委托授权通证与所述预定值的比较来确定所述第一委托授权通证的有效性。

执行根据第一方面所述的方法的一个或多个设备可以被视为核实器，因为它正在核实委托授权通证。有利地，仅利用提供给所述核实器的所述预定值，所述核实器仍然可以核实任何接收到的委托授权通证，从而提供需要最小数据共享并因此需要更小攻击面的安全认证系统。所述更小攻击面意味着整体更高的安全系统。有利地，所述核实器不需要知道它们正在核实的任何受托用户的号码或身份，从而为所述客户端和代表者提供更好的隐私。

可选地，所述生成是基于对所述委托授权通证链中的所述先前委托授权通证进行哈希处理而进行的。

可选地，所述的生成所述委托授权通证链中的其他委托授权通证的步骤包括对每个其他委托授权通证执行以下步骤：确定中间原像，所述中间原像基于所述委托授权通证链中的所述先前委托授权通证；以及，对所述中间原像应用单向函数，所述单向函数的输出是所述其他委托授权通证。优选地，所述单向函数是哈希函数。优选地，所述中间原像附加地基于给定值。

有利地，使用单向函数来确定委托授权通证意味着所述系统的任何成员都不能根据其当前授权通证来计算在所述链中处于较高位置的任何委托授权通证。

有利地，通过将所述原像基于给定值(以下描述为初始值)，在没有所述给定值的情况下，所述系统的任何成员都不能计算在所述链中处于较高位置的任何其他委托授权通证。除了运行根据第一实施例所述的方法的所述设备之外，不向任何其他设备提供所述给定值，从而提高防篡改能力和对恶意方攻击的恢复能力。

可选地，其他委托授权通证的所述生成基于所述委托授权通证链中的所述先前委托授权通证和给定值。

可选地，所述方法还包括以下步骤：从存储设备获取所述给定值。可选地，所述给定值是从客户端接收的。

可选地，所述生成基于所述给定值和所述先前委托授权通证的级联。优选地，所述生成基于对所述给定值和所述委托授权通证链中的所述先前委托授权通证的所述级联进行哈希处理。

有利地，单向函数和给定值的使用的组合不允许具有委托授权通证的用户计算所述委托授权通证链中的任何其他委托授权通证(从而提供额外的安全性)，同时仍然使所述核实服务能够核实委托授权通证，而无需发送所有有效通证。通过消除对客户端或其他设备向运行根据该第一方面所述的方法的所述核实器发送有效通证的需要，再次减少了第三方获取任何有效通证的机会，并且提高了整个系统的安全性。

可选地，所述请求还包括索引号，并且所述委托授权通证链中的委托授权通证的数量基于所述索引号。可选地，所述索引可以表示与客户端生成的最终委托授权通证的距离。

在使用并提供所述索引以供代表者将其包括在其请求中的情况下，提供了一种更高安全性的系统，所述系统要求敌对第三方知道两条信息：哈希和索引。两者都必须正确，服务才能处理所述请求。

或者，不使用索引。在索引未被使用或未被提供给代表者的情况下，有利地，客户端不知道它们在所述链中的位置，因此不能确定有多少其他代表者，从而增强正被核实的所有客户端和用户的隐私。

可选地，所述的确定所述第一委托授权通证的有效性的步骤基于所述委托授权通证链中的最终委托授权通证与所述预定值的比较。

可选地，所述的确定所述第一委托授权通证的所述有效性的步骤包括：比较所述预定值和所述委托授权通证链中的所述最终委托授权通证是否具有相同的值。

可选地，所述请求是向区块链提交或从所述区块链读取。

可选地，所述请求是将数据提交给基于区块链的数据记录服务，使得包括在所述请求中的数据的表示被记录在一个/所述区块链上。附加地或替代地，所述请求是从一项/所述基于区块链的数据记录服务读取数据的表示。优选地，读取数据的所述请求包括对要读取的数据的引用。优选地，所述基于区块链的数据记录服务是如本文所述的平台服务的一部分。

有利地，所述基于区块链的数据记录服务提供了一种简化所述区块链作为商品数据分类账的使用的方式。此外，所述委托授权通证为所述基于区块链的数据记录服务提供了增强的安全性。因此，所述基于区块链的数据记录服务的受托用户能够与所述区块链交互，并以安全的方式利用区块链特性(例如，不可变性、分布式、可选透明度、可追溯性等)来满足其数据存储需求，而不一定需要与事务或所述区块链本身直接交互。

可选地，确定所述请求的所述有效性还基于先前接收的包括相同的第一委托授权通证的请求的数量。

有利地，这使得客户端能够对所述系统进行更精细的控制，并限制恶意行为者发送垃圾邮件的能力。或者，如果恶意第三方要获取有效的委托授权通证，则对可能造成的损害施加限制，从而提高整个系统的安全性。

优选地，所述预定值是客户端生成的委托授权通证。优选地，所述预定值是客户端生成的委托授权通证链中的最后一个委托授权通证。优选地，所述预定值在接收到时存储在所存储的委托授权通证链中。

可选地，所述方法还包括以下步骤：基于所述第一委托授权通证的所述有效性来存储所述委托授权通证链。优选地，所述方法还包括以下步骤：接收其他请求，所述其他请求包括其他委托授权通证；基于所述其他委托授权通证是否存在于所述存储的委托授权通证链中来确定所述其他委托授权通证的有效性。

记录中间哈希结果有利地减少了用于后续验证的处理时间。如果接收到的通证具有比已经接收到的通证更低的索引(即，更接近所述最终委托授权通证或H₀)，则不需要进行哈希处理，并且节省了计算机处理时间和能力。

可选地，所述预定值是具有一个/所述存储的委托授权通证链的最高索引的委托授权通证。优选地，执行生成其他委托授权通证的步骤，直到。

可选地，所述方法还包括：确定所述存储的委托授权通证链的最高索引；基于所述接收的委托授权通证来生成其他委托授权通证，直到生成具有等于所述最高索引的索引的委托授权通证；基于所述最终生成的委托授权通证与所述存储的具有所述最高索引的委托授权通证的比较来确定所述接收的委托授权通证的所述有效性。

可选地，在每个委托授权通证具有与其相关联的索引的情况下，其中在所述索引中可以表示与所述最终委托授权通证的距离，每个委托授权通证与其关联的索引一起存储，并且优选地可以按所述索引来搜索。通过按其索引存储每个委托授权通证，有利地，搜索是否存在任何通证在时间和计算机资源方面变得更高效，因为按索引搜索和/或搜索索引比迭代通过数据集并比较每个值更快并且计算资源密集度更低。

可选地，所述方法还包括以下步骤：提供对所述请求的所述有效性的指示和/或基于所述委托授权通证的所述有效性来处理所述请求。优选地，处理意味着以下各项中的任一项或多项：转发所述请求；丢弃所述请求；允许所述请求；阻止所述请求；允许对基于区块链的存储系统进行访问；允许对所述基于区块链的存储系统进行读取访问；允许对所述基于区块链的存储系统进行写入访问；基于所述请求从所述基于区块链的存储系统提供数据；和/或基于所述请求向所述基于区块链的存储系统写入数据。

执行根据第二方面所述的方法的一个或多个设备通常是所述客户端，其中所述客户端委托其对代表者(delegate)或受托用户(delegated user)的访问。

可选地，所述的生成所述委托授权通证链中的其他委托授权通证的步骤包括对每个其他委托授权通证执行以下步骤：确定中间原像，所述中间原像基于所述第一值和所述委托授权通证链中的所述先前委托授权通证；以及，对所述中间原像应用单向函数，所述单向函数的输出是所述其他委托授权通证。优选地，所述单向函数是哈希函数。优选地，所述中间原像附加地基于给定值。

该方法提供了与关于第一方面所讨论的安全性等相同或相似的优点。

优选地，所述生成基于对所述给定值和所述委托授权通证链中的所述先前委托授权通证的所述级联进行哈希处理。

可选地，所述方法还包括以下步骤：向委托设备提供所述委托授权通证链中的所述委托授权通证中的一个委托授权通证。优选地，还向所述委托设备提供所述委托授权通证的索引，所述索引表示所述提供的委托授权通证在所述委托授权通证链中的位置。

可选地，所述方法还包括以下步骤：向验证设备提供所述第一值和所述委托授权通证链中的最终委托授权通证。优选地，还向所述验证设备提供指示每个代表者的最大读取或写入次数的数字。

可选地，所述委托授权通证链中的所述委托授权通证的数量基于代表者的数量。优选地，所述委托授权通证链中的所述委托授权通证的数量等于所述代表者的数量。

如上关于第一方面所述，可选地，将所述委托授权通证提供给代表者，使得所述代表者可以交互(优选地，通过向基于区块链的数据记录服务写入数据或从所述基于区块链的数据记录服务读取数据)。

因此，应用相同或相似的优点，由此，当访问所述基于区块链的数据记录服务时，上述委托授权通证提供增强的安全性。因此，所述基于区块链的数据记录服务的受托用户能够与所述区块链交互，并以安全的方式利用区块链特性(例如，不可变性、分布式、可选透明度、可追溯性等)来满足其数据存储需求，而不一定需要与事务或所述区块链本身直接交互。

可选地，其中在生成所述第一委托授权通证之后删除所述第二值。

有利地，通过删除所述第二值，无法构建所述第一委托授权通证，因此无法构建整个链，从而通过消除恶意第三方重新生成通证的任何机会来提供改进的安全性。

可选地，所述第一值和所述第二值是随机生成的。

优选地，根据第一方面或第二方面所述的先前委托授权通证是指紧接在所述生成的委托授权通证之前的所述委托授权通证。这也可以是生成或获取的最新委托授权通证。

可选地，所述服务器被配置为根据第一方面所述的方法来接收和处理来自所述代表者的请求。

根据前述方面中的任一项或多项，可选地，经由或使用HTTPS协议从客户端和/或受托用户接收所述请求。附加地或替代地，所述请求的接收器将API实现为Web服务。可选地，所述委托授权通证被配置为提供对事件流和/或数据写入器服务的委托访问。有利地，使用HTTPS和/或API和/或Web服务可以提供互补的安全特征，同时仍然使得Web请求的接收器能够提供灵活的基于区块链的数据服务。提供对基于区块链的数据写入器或读取器的委托访问的其他优点包括允许(以安全方式)除了第一客户端之外的更多数量的用户访问所述基于区块链的数据写入器或读取器服务。

示例性系统概述

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

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

区块链150包括一系列数据区块151，其中在分布式或区块链网络160中的多个区块链节点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。这些用户可以与区块链网络交互，但不参与核实、构造或传播事务和区块。其中一些用户或代理103可以充当事务中的发送者和接收者。其它用户可以与区块链150交互，而不必充当发送者或接收者。例如，一些当事方可以充当存储区块链150的副本(例如，已经从区块链节点104获得区块链的副本)的存储实体。

各方103中的一些或所有当事方可以作为不同网络的一部分连接，例如覆盖在区块链网络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将开始争相解决其各自有序事务集154的最新版本上的工作证明难题，该有序事务集154包括新的事务152(请记住，其它区块链节点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₁”。该新事务获取在序列中先前事务152i的输出203中锁定至爱丽丝的数字资产数额，并至少将此类数额中的一部分转移至鲍勃。在图2中，先前事务152i标记为“Tx₀”。Tx₀和Tx₁只是任意的标记，其不一定意味着Tx₀指区块链151中的第一事务且Tx₁指池154中的下一事务。Tx₁可指向仍具有锁定至爱丽丝的未花费输出203的任何先前(即先行)事务。

当爱丽丝创建其新事务Tx₁时，或至少在她将该新事务发送至网络106时，先前事务Tx₀可能已经有效并包括在区块链150的区块151中。该事务此时可能已包括在区块151中的一个区块中，或者可能仍在有序集154中等待，在这种情况下，该事务将很快包括在新区块151中。或者，Tx₀和Tx₁可以创建并一起发送至网络106；或者，如果节点协议允许缓冲“孤立”事务，Tx₀甚至可以在Tx₁之后发送。本文事务序列上下文中使用的“先前”和“后续”一词是指由事务中指定的事务指针定义的序列中的事务顺序(哪个事务指向哪个其他事务等等)。它们同样可以替换为“前任”和“继任”、“先行”和“后代”或“父项”和“子项”等。这不一定指其创建、发送至网络106或到达任何给定区块链节点104的顺序。然而，指向先前事务(先行事务或“父事务”)的后续事务(后代事务或“子事务”)不会有效除非父事务有效。在父事务之前到达区块链节点104的子事务被视为孤立事务。根据节点协议和/或节点行为，其可被丢弃或缓冲一段时间，以等待父事务。

先前事务Tx₀的一个或更多个输出203中的一个包括特定的UTXO，标记为UTXO₀。每个UTXO包括指定UTXO表示的数字资产数额的值以及锁定脚本，该锁定脚本定义后续事务的输入202中的解锁脚本必须满足的条件，以使后续事务有效，从而成功赎回UTXO。通常情况下，锁定脚本将数额锁定至特定方(该数额的事务的受益人)。即，锁定脚本定义解锁条件，该解锁条件通常包括以下条件：后续事务的输入中的解锁脚本包括先前事务被锁定到的一方的加密签名。

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

因此在示出的示例中，Tx₀的输出203中的UTXO₀包括锁定脚本[Checksig P_A]，该锁定脚本需要爱丽丝的签名Sig P_A，以赎回UTXO₀(严格来说，是为了使试图赎回UTXO₀的后续事务有效)。[Checksig P_A]包含爱丽丝的公私密钥对中的公钥P_A的表示(即哈希)。Tx₁的输入202包括指向Tx₁的指针(例如，通过其事务ID(TxID₀)，其在实施例中是整个事务Tx₀的哈希值)。Tx₁的输入202包括在Tx₀中标识UTXO₀的索引，以在Tx₀的任何其他可能输出中对其进行标识。Tx₁的输入202进一步包括解锁脚本<Sig P_A>，该解锁脚本包括爱丽丝的加密签名，该签名由爱丽丝通过将其密钥对中的私钥应用于预定的部分数据(有时在密码学中称为“消息”)创建。爱丽丝需要签名以提供有效签名的数据(或“消息”)可通过锁定脚本、节点协议或其组合进行定义。

当新事务Tx₁到达区块链节点104时，该节点应用节点协议。这包括一起运行锁定脚本和解锁脚本，以检查解锁脚本是否满足锁定脚本中定义的条件(其中该条件可包括一个或更多个标准)。在实施例中，这涉及并置两个脚本：

<Sig PA><PA>||[Checksig PA]

其中“||”表示并置，“<…>”表示将数据放在堆栈上，“[…]”表示由锁定脚本组成的函数(在该示例中指基于堆栈的语言)。同样，脚本可以使用公共堆栈一个接一个地运行，而不是并置脚本。无论采用哪种方式，当一起运行时，脚本使用爱丽丝的公钥P_A(包括在Tx₀的输出的锁定脚本中)，以认证Tx₁的输入中的解锁脚本是否包含爱丽丝签名预期部分的数据时的签名。也需要包括预期的部分数据本身(“消息”)，以便执行此认证。在实施例中，签名的数据包括整个Tx1(因此不需要包括一个单独的元素来明文指定签名的部分数据，因为其本身便已存在)。

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

如果Tx1中的解锁脚本满足Tx0的锁定脚本中指定的一个或多个条件(因此，在所示示例中，如果在Tx1中提供了爱丽丝的签名并进行验证)，则区块链节点104认为Tx1有效。这意味着区块链节点104会将Tx1添加到有序事务集154。区块链节点104还会将事务Tx1转发到网络106中的一个或多个其它区块链节点104，以便其会在整个网络106中传播。一旦Tx1有效并包括在区块链150中，这会将UTXO0从Tx0定义为已花费。应当注意的是，Tx1仅在花费未花费事务输出203时才有效。如果其试图花费另一事务152已经花费的输出，则即使满足所有其它条件，Tx1也将无效。因此，区块链节点104还需要检查先前事务Tx0中引用的UTXO是否已经花费(即，其是否已经形成另一有效事务的有效输入)。这是为何区块链150对事务152施加定义的顺序很重要的原因之一。在实践中，给定区块链节点104可维护单独的数据库，标记已花费事务152的UTXO 203，但最终定义UTXO是否已花费取决于是否在区块链150中形成了另一有效事务的有效输入。

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

请注意，在基于UTXO的事务模型中，给定UTXO需要作为一个整体使用。不能“留下”UTXO中定义为已花费的一部分数额，而同时又花费另一部分。但UTXO的数额可以在下一事务的多个输出之间分割。例如，Tx₀的UTXO₀中定义的数额可以在Tx₁中的多个UTXO之间分割。因此，如果爱丽丝不想将UTXO₀中定义的所有数额都给鲍勃，她可以使用剩余部分在Tx₁的第二输出中自己找零，或者支付给另一方。

在实践中，爱丽丝通常还需要包括用于发布其事务104的比特币节点的费用。如果爱丽丝未包括此类费用，则Tx0可能会被区块链节点104拒绝，并且因此尽管在技术上有效，但可能不会传播并且包括在区块链150中(如果区块链节点104不希望接受事务152，节点协议不强迫区块链节点104接受)。在一些协议中，事务费用不需要其自身的单独输出203(即不需要单独的UTXO)。相反，输入202指向的总数额与给定事务152的输出203指定的总数额之间的任何差额都将自动提供给发布事务的区块链节点104。例如，假设指向UTXO0的指针是Tx1的唯一输入，并且Tx1仅具有一个输出UTXO1。如果在UTXO0中指定的数字资产数额大于在UTXO1中指定的数额，则可以由发布包含UTXO1的区块的节点104分配该差值。替代地或附加地，这不一定排除可以在其自身事务152的其中一个UTXO 203中明确指定事务费用。

爱丽丝和鲍勃的数字资产由区块链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的单独侧信道301(在任何一方或第三方的鼓动下)。侧信道301使得能够脱离区块链网络交换数据。此类通信有时称为“链下”通信。例如，这可用于在爱丽丝与鲍勃之间交换事务152，而不将该事务(尚未)注册到区块链网络106上或将其发布到链150上，直到其中一方选择将其广播到网络106上。以这种方式共享事务有时称为共享“事务模板”。事务模板可能缺少形成完整事务所需的一个或多个输入和/或输出。替代地或附加地，侧信道301可用于交换任何其它事务相关数据，例如密钥、议付数额或条款、数据内容等。

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

客户端软件

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

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

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

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

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

例如，UI元素可包括一个或更多个用户可选择的元素362，这些元素可以是屏幕上的不同按钮、菜单中的不同选项或者诸如此类。用户输入方式被设置成使用户103(在这种情况下为爱丽丝103a)能够选择或以其它方式操作其中一个选项，诸如通过点击或触摸屏幕上的UI元素，或者说出所需选项的名称(注：本文使用的“手动”一词仅用于与自动进行对比，而不一定限于用手执行操作)。

此外/或者，UI元素可包括一个或更多个数据输入字段362，用户通过该字段能够......。这些数据输入字段通过用户输出方式呈现，例如屏幕上，并且数据可通过用户输入方式输入到字段中，例如键盘或触摸屏。或者，数据可以例如基于语音识别口头地接收。

此外/或者，UI元素可包括向用户输出信息的一个或更多个信息元素363。例如，这/这些可以在屏幕上呈现或可听见。

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

节点软件

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

因此，脚本引擎452具有Tx_i的锁定脚本和来自Tx_j的相应输入的解锁脚本。例如，在图2中示出了事务标记的Tx₀和Tx₁，但是同样的事务也可以应用于任何事务对。如前所述，脚本引擎452一起运行两个脚本，这将包括根据所使用的基于堆栈的脚本语言(例如脚本)将数据放置到堆栈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中的另一个区块链节点104。可选地，在实施例中，应用级决策引擎454可以在触发这些函数中的一个或两个函数之前应用一个或多个附加条件。例如，决策引擎可以只选择在事务有效且预留足够事务费用的条件下发布事务。

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

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

例如，上面的一些实施例已经根据比特币网络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所述的方式相同。

委托授权

图5涉及根据本公开的第一方面的用于提供和使用委托授权通证的系统500，优选地作为平台处理器504的一部分，平台处理器504提供与区块链101相关联的多项服务。可选地，平台处理器504是平台，如下面参考图11和图13更详细地描述的。然而，本领域技术人员应当理解的是，本文所述的委托授权方法和系统可以用于其他服务，包括不与区块链101相关联的服务。平台处理器504被配置为与区块链101、客户端502和/或受托用户506通信和/或以其他方式交互。为了便于说明，平台处理器504在本文中被描述为单片服务器。在使用“客户端”、“用户”或类似术语的情况下，应当理解的是，这通常是指所述客户端或用户拥有的设备。本领域技术人员应当理解的是，它可以被实现为单个服务器、大型主机、服务器集合、微服务、微服务集合、云服务、一个或多个前述和/或其他计算平台的任何组合。如本文中所使用的术语“服务”应当被理解为计算功能或行为集合的通称，并且不严格地专用于在一个服务器上运行的单个应用程序。本文提供了示例和选项的非穷尽列表。服务可以是一个应用程序，也可以是多个应用程序。服务可以在一个硬件服务器/设备上运行，也可以在多个硬件服务器/设备上运行。例如，下面提供了与服务分开的数据库，这同样可以作为同一服务的一部分被包括在内。

系统500包括客户端502，客户端是对平台504上的服务具有授权的用户。客户端的授权允许客户端502向其他用户506(以下称为受托用户delegated user或代表者delegate)提供委托授权。客户端502可以被视为服务的“所有者”，并且优选地触发在平台504上创建服务。客户端502希望委托授权，以便其他用户可以访问服务。优选地，委托授权允许受托用户506与运行服务的平台504交互(512)。更优选地，交互是向服务读取、写入，或同时读取和写入/从服务读取、写入，或同时读取和写入。更优选地，所描述的服务是下面参考图10A至图10C、图11和图12更详细地描述的事件流。本领域技术人员应当理解的是，与本文服务的委托授权相关联的方法和系统也可以用于其他服务。

可选地，受托用户还可以与服务进行其他交互。允许的交互类型将取决于服务。例如，如果服务是提供金融事务，则受托用户可能具有创建或签署事务的委托授权。优选地，委托授权不允许添加更多受托用户或创建委托授权通证。

如下面参考图6和图7更详细地描述的，根据本方面的实施例，客户端502生成委托授权通证并将它们提供(508)给受托用户506。

如下面参考图8和图9A至图9C更详细地描述的，根据本方面的实施例，受托用户506被配置为生成包括这些通证的请求，将请求发送(512)到在平台504上运行的服务。在接收到请求时，服务将核实请求，并根据委托授权通证的有效性来处理请求。

委托授权通证生成

图6示出了根据第一方面的实施例的方法600。方法600描述了委托授权通证(在本文中也被描述为delegatedAuth通证)的生成，并且在客户端502希望授权多个受托用户与委托服务交互时使用。优选地，该方法完全由客户端执行，而不与系统500中的任何其他实体交互。可选地，委托授权通证具有可以与委托授权通证一起提供的相关联的索引。

生成委托授权通证，使得它们形成一组相关通证。优选地，一组相关通证是通证“链”，因为每个委托授权通证(除了第一委托授权通证之外)基于链中的先前委托授权通证，如下所述。

首先，生成(602)两个随机数：初始值(下面称为IV)和种子值(下面称为种子)。

可选地，确定(604)所需的委托授权通证的数量。该数量通常等于(或有时大于)客户端希望向其提供委托授权的用户的数量。

然后，基于这两个值来生成(606)第一委托授权通证。优选地，第一委托授权通证基于初始值和种子值的级联。更优选地，第一委托授权通证基于单向函数，单向函数使用初始值和种子值作为输入。更优选地，第一委托授权通证基于初始值和种子值的级联的哈希。

可选地，安全地删除种子值，使得没有实体可以再次使用种子值。

生成(608)其他委托授权通证。生成的每个委托授权通证至少基于先前生成的委托授权通证。优选地，基于初始值和先前生成的委托授权通证来生成每个其他委托授权通证。优选地，先前生成的授权通证是指紧接在当前正被生成的委托授权通证之前生成的委托授权通证，并且也可以被描述为先前委托授权通证。更优选地，基于初始值和先前生成的委托授权通证的组合来生成每个其他委托授权通证。更优选地，基于单向函数来生成每个其他委托授权通证，单向函数采用初始值和先前生成的委托授权通证的组合作为输入。更优选地，基于初始值和先前生成的委托授权通证的组合的哈希来生成每个其他委托授权通证。甚至更优选地，组合是初始值对先前生成的授权通证的级联。

初始值和先前生成的委托授权通证的组合可以被描述为原像。

将初始值附加在先前委托授权通证前面(上述级联)的替代方案是完全不使用初始值，并且因此先前委托授权通证仅基于先前生成的委托授权通证。为了以这种方式生成下一个委托授权通证，对先前委托授权通证使用单向函数，并且所述函数的输出是下一个委托授权通证。优选地，单向函数是哈希函数。

优选地，委托授权通证采用二进制字符串和/或字节串的形式。二进制字符串的长度取决于所使用的单向函数。如果所使用的单向函数是SHA256，则委托授权通证的长度将为256位(或32字节)。可选地，该二进制字符串可以被表示和/或编码为十六进制字符串、base64字符串或任何其他适当的编码方案。

当生成通证的客户端502确定它们具有足够的通证时和/或当生成的通证的数量等于或大于在步骤604中确定的数量时，停止该生成步骤608。

优选地，上述方法600用于生成受托用户与服务之间的每种类型的交互。优选地，生成一个委托授权通证链用于对服务进行读取访问，并且生成另一个委托授权通证链用于对服务进行写入访问。客户端想要提供读取授权的每个用户接收一个读取委托授权通证，并且客户端想要提供写入授权的每个用户接收一个写入委托授权通证。读取委托授权通证和写入委托授权通证的数量不必相同。

可选地，受托用户可以接收多个通证。对于交互受限的示例，例如本文所讨论的写入，这将允许受托用户进行更多写入。

还可以在下表中示出与生成(606、608)委托通证链相关的步骤。在该表中，“R”用于表示与“读取”授权相关的通证和数据；“W”用于表示与“写入”授权相关的通证和数据。“H”函数是单向函数，优选地是哈希函数；并且优选地，“||”符号表示所述符号的每一侧的级联。仅以示例的方式创建每一侧4个通证。可以针对每种类型的通证使用不同的数字。

R_H3＝H(R_IV\|\|R_seed)	W_H3＝H(W_IV\|\|W_seed)
		R_H2＝H(R_IV\|\|R_H3)	W_H2＝H(W_IV\|\|W_H3)
R_H1＝H(R_IV\|\|R_H2)	W_H1＝H(W_IV\|\|W_H2)
		R_H0＝H(R_IV\|\|R_H1)	W_H0＝H(W_IV\|\|W_H1)

从上表可以看出，委托授权通证链中的最终委托授权通证是H0哈希。

优选地，对于写入委托授权通证，还存在每个通证的最大写入次数。可选地，这扩展到客户端可能希望限制每个通证能够进行的交互次数的其他交互。

参考图10D描述上述方法600的示例。示出了示例性系统1070，其中客户端采用随机初始值IV和种子来创建委托授权通证链。接下来，向事件流服务发送“创建”事件流消息，创建事件流消息包括最终委托授权通证(H0)和初始值。事件流服务创建事件流，将最终通证和初始值与所创建的流相关联，并使用“esid”—“事件流标识符”来回复创建消息。esid用于客户端和/或任何受托用户的任何未来交互。

优选地，创建请求是JSON对象并且包括以下内容：

"readAccessControl":{

"delegatedReadH0":<RH0>,

"delegatedReadIV":<RIV>

},

"writeAccessControl":{

"maxWritesPerDelegate":<integer>,

"delegatedWriteH0":<WH0>,

"delegatedWriteIV":<WIV>

}

根据另一个实施例，图7中示出了分发用于向用户提供委托授权的所需信息的方法700。

利用可选地由如图6所示的实施例生成(702)的委托授权通证，客户端向每个受托用户提供(704)通证，并提供(706)平台或服务确定任何委托通证的有效性所需的任何数据。优选地，平台或服务确定通证的有效性所需的数据包括委托授权通证链中的最后一个委托授权通证(WH0和/或RH0，如在上面的示例中可以看出的)和初始值(WIV和/或RIV，如在上面的示例中可以看出的)。

委托授权通证固有地具有序数性，因此可以被索引。优选地，当向每个受托用户提供(704)他们的通证时，还提供通证的索引。

虽然与向受托用户和平台提供数据相关的步骤704、706是按顺序呈现的，但是它们可以任何顺序或同时进行。

由于每个通证链是按交互(例如，读取或写入)生成的，因此针对客户端希望委托的每种类型的交互执行方法700。

可以在服务建立之前向代表者提供其委托授权通证，或者可以在服务运行时按需提供委托授权通证。

客户端502可以在任何时间撤销这些通证中的任何数量的通证或所有通证。这是通过客户端创建请求来执行的，该请求包括数据，该数据指示他们希望撤销通证的服务(在下面提供的示例中，这意味着标识特定事件流)、要从其中撤销通证的交互类型(例如，读取或写入)、要撤销的通证和/或要撤销的通证的索引。优选地，使用要撤销的通证和索引两者；可选地，仅使用其中一者。优选地，所有通证都以启用/未撤销的方式开始，并且客户端502必须撤销它们。图10C和图10E提供了撤销的具体示例。

能够撤销单个通证可以改进客户端502在管理对服务的访问方面的灵活性和控制。此外，由于受托用户506不知道其他通证并且无法计算其他通证，因此当客户端希望撤销访问时，不需要通知或更新仍被启用/未撤销的任何其他受托用户，从而节省计算资源和时间。

委托授权通证使用

参考图8，示出了根据另一个实施例的方法800，该方法描述了接收(804)、核实(806)和处理(808)请求以与服务交互的过程。在本实施例中，为了便于描述，该方法800被描述为由在平台上运行的服务来执行。在替代实施例中，平台正在运行被配置为在此执行方法800的其他过程。该过程可以被描述为“认证服务”或“访问控制服务”，并且可选地在与正与之交互的服务相同的平台504上运行。作为其他替代方案，在服务接收请求之前，认证服务充当滤波器。

在接收来自受托用户的请求的步骤之前，服务从生成委托授权通证的客户端接收(802)适当的核实数据。核实数据至少包括委托授权通证链中的最终哈希(或最终委托授权通证)。该最终通证也被描述为客户端接收的最终委托授权通证，因为它来自客户端。该最终哈希可以表示为H0、R_H0或W_H0，如本文中所使用的。优选地，核实数据还包括如以上面参考图6所述的在生成委托授权通证链的过程中使用的初始值。

服务可以在核实来自受托用户的请求之前的任何时刻接收(802)该数据。优选地，当创建新的事件流时，向服务提供核实信息。

在稍后某个时间，服务将接收(804)来自受托用户的使用服务和/或事件流的请求。这些请求包括委托授权通证。如果请求不包括委托授权通证，或者不来自客户端，则将该请求视为无效。优选地，来自客户端的请求不需要委托授权通证，并且将使用不同的系统来核实或认证。

服务基于委托授权通证和核实数据来确定(806)请求的有效性。参考图9A至图9D更详细地描述该步骤。核实有时包括从所接收的委托授权通证开始直到最终委托授权通证，重新创建委托授权通证链的子集。如果重新创建的最终委托授权通证与客户端接收的最终委托授权通证相同，则所接收的委托授权通证有效。

可选地，服务还基于委托授权通证是否已被撤销来确定请求的有效性。如果该服务和交互的通证和/或索引已被撤销，则会发现请求无效。

最后，根据在步骤806中确定的有效性来处理该请求。如果通证无效，则不处理该请求。

在该方法800由认证服务运行的情况下，处理步骤806包括认证服务向服务和/或平台提供关于核实结果的指示。或者，在认证服务充当滤波器的情况下，处理步骤806包括丢弃请求，并且在通证无效的情况下不将请求转发到服务。如果请求有效，则在服务上传递请求，并且可选地利用附加信息来指示该请求有效。

图9A至图9D所示的方法描述了关于服务可以如何核实所接收的委托授权通证的不同示例性情况。第一方法900示出了接收到第一请求的情况。从所接收的委托授权通证开始重新创建委托授权通证链。第二方法示出了接收到其他请求的情况，但是该其他请求的索引相对于任何先前接收的委托授权通证在链中处于较高位置，并且服务本来不必计算该索引。第三方法示出了接收到另一其他请求的情况，并且索引在链中出现的时间较晚，并且服务已经计算该索引。

在引用链时使用“较高”和“较低”，这是指所提供的索引。“较高”涉及具有较高的索引号，并且距离最终委托授权通证更远，而“较低”则相反。索引零是最低索引，并索引链中的最终/最后一个生成的委托授权通证。如上所述，具有索引0的委托授权通证是由客户端提供用于验证目的的通证。

优选地，核实方法使用与客户端构建委托授权通证链相同的方法。第一示例性情况方法900、第二示例性情况方法920和第三示例性情况方法940示出了使用与创建哈希链基本相同的方法重建哈希链(或其子集)。

图9A示出了第一核实方法900，其中服务第一次接收(902)通证。第一请求包括第一接收的委托授权通证。优选地，该请求还包括索引。

由于这是第一接收的委托授权通证，因此服务不会生成委托授权通证链的任何其他部分。

接下来，从第一接收的委托授权通证开始，重新生成委托授权通证链。链的生成方法与链的创建方法相同，如上所述。因此，优选地，通过将初始值与第一接收的委托授权通证级联，然后进行哈希处理以接收该链中的下一个委托授权通证来创建链。多次重复该步骤。如果索引存在于请求中，则所生成的链中的委托授权通证的数量基于该索引。索引可以被视为与委托授权通证链中的最终委托授权通证的距离。生成其他委托授权通证，直到生成最终委托授权通证H0′。例如，如果请求中的索引为3，则生成另外三个哈希(H2′、H1′、H0′)，如下所示。符号′用于表示这是基于所接收的委托授权通证生成的链，并且可能与客户端生成的链不同。这里没有使用“R”和“W”，因为读取(“R”)、写入(“W”)或任何其他交互的过程是相同的。

H3′＝Receivedtoken，H2′＝H(IV||H3)，H1′＝H(IV||H2)，H0′＝H(IV||H1)。

还可以通过单个方程式来获取H0′：

H0′＝H(IV||H(IV||H(IV||Received token)))

优选地，如果发现通证有效，则存储所接收的委托授权通证(H3′)和链中的每个中间哈希H2′和H1′(它们也是委托授权通证，并且可以由未来代表者使用)以供将来使用。关于下面图9C所示的示例性方法940进一步描述这些中间通证的使用。更优选地，将所接收的委托授权通证和所生成的委托授权通证存储在数据存储机制(例如，数组、数据库、硬盘驱动器或任何其他类似的系统或模块)中，使得可以根据它们在链中的位置对它们进行索引。有利地，将委托授权通证与它们的索引相关联(也称为索引)可以更容易地进行查找，如在参考图9C描述的情况中。如果发现通证无效，则不存储和/或删除所构建的整个链。

在上述核实方法800的初始步骤802中，基于所生成的最终哈希H0’与作为核实数据的一部分从客户端接收的最终哈希的比较来确定第一接收的通证的有效性。如果H0和H0’相等，则委托授权通证是有效的。

或者，如果没有使用索引，则修改该方法，使得继续生成委托授权通证，并且将每个生成的通证与H0进行比较。当成功进行比较或达到通证的最大数量时，该过程停止。如果达到最大数量并且没有成功进行比较，则发现第一接收的委托授权通证无效。

参考图9B，示出了方法920，其中接收(922)其他请求，该其他请求还包括委托授权通证和索引。出于说明目的，在该示例性方法中，委托授权通证和/或索引之前没有被服务看到，并且不存在于任何预先计算的委托授权通证链中。

在接收到时，服务确定(924)委托授权通证是否已经存在于先前生成的链。优选地，使用所索引的数据存储机制，基于索引进行查找。如果数据存储机制是数组，这意味着访问索引条目处的数据。在本示例中，在索引处不存在委托授权通证。

作为使用索引来对委托授权通证进行索引的替代方案，该方法可以简单地循环遍历所有存储的委托授权通证并检查其是否存在。

由于通证尚未存在于当前存储的链中，因此必须生成更多的委托授权通证链，以确认其存在于客户端生成的链中。链的构建与先前描述的内容相似/相同(优选地，将初始值与其他接收的委托授权通证级联，并将其重复地传递通过单向函数)。优选地，重复这些步骤直到遇到委托授权通证链中的第一先前生成或接收的委托授权通证，而不是一直重复这些步骤直到链(H0)中的最终委托授权通证。由于生成通证的方法是确定性的，因此在给定相同的起始数据的情况下，将生成相同的链。从链中的任何一点开始都是如此，而不仅仅是第一委托授权通证。

由于在构建链时使用了单向函数，因此服务(或系统中包括其他代表者的任何其他设备)不能从任何给定点计算在链中处于较高位置的委托授权通证，即使它们具有附加到其通证前面的初始值也是如此。这是单向函数的一个属性，即利用输出来计算输入是不可能的。因此，链必须始终从任何接收的委托授权通证向前构建。

例如，如果所接收的通证具有索引5，并且索引为3、2、1、0(H3、H2、H1、H0)的委托授权通证已经被存储在数据存储机制中，以确定其他接收的委托授权通证是否有效，则只需执行以下计算：

H5′＝Received token，H4′＝H(IV||H5′)，H3′＝H(IV||H4′)。

如果H3′等于已经存储的H3，则链的其余部分将是相同的，其他接收的委托授权通证将是有效的，并且可以跳过其余级联和单向函数步骤。如果H3′不等于H3，则其余链也将是不同的(因此也可以跳过计算)，并且委托授权通证是无效的。

因此，在该示例中，基于当前生成的委托授权通证(优选地，当前生成的委托授权通证中的最后一个委托授权通证)中的一个委托授权通证与存储的和/或先前生成的委托授权通证的比较来确定接收的委托授权通证的有效性。优选地，具有所存储的和/或先前生成的委托授权通证的最高索引的通证。

所存储的具有最高索引的委托授权通证很可能是被发现有效的先前接收的委托授权通证。因此，该方法还可以被描述为：确定任何先前接收的委托授权通证的最高索引；基于所接收的委托授权通证来生成其他委托授权通证，直到具有等于先前接收的有效委托授权通证的索引的委托授权通证；基于最终生成的委托授权通证与先前接收的委托授权通证的比较来确定所接收的委托授权通证的有效性。如果所接收的通证是有效的，则该通证将是具有任何先前接收的通证的索引最高的通证。

参考图9C，示出了示例性方法，其中接收(942)另一其他请求，该另一其他请求包括另一其他委托授权通证和索引。在该示例中，通证已经是所存储的委托授权通证链的一部分。该通证可能已经被存储，因为该通证之前已经被使用，或者因为在接收该通证之前已经接收到具有较高索引的有效通证。

在接收到(942)另一其他委托授权通证及其索引的情况下，(对于该示例)确定(944)存在与该索引相关联的预先生成和存储的委托授权通证。优选地，该确定包括向数据存储机制查询给定索引处的委托授权通证。在另一其他接收的委托授权通证和所存储的与索引相关联的委托授权通证之间进行比较。通证的有效性基于该比较。优选地，如果通证相同，则所接收的通证是有效的。如果通证不相同，则所接收的通证是无效的。

优选地，第一方法900、第二方法920和第三方法940一起用于核实委托授权通证。有利地，这些方法900、920、940提供高速缓存，使得不需要在每次接收到委托授权通证时计算委托授权通证链，从而节省计算机处理能力和时间，同时仍然提供强大的访问控制安全性。如果存在大量代表者，则哈希过程的计算可能需要一段时间。

或者，仅使用第一方法900。如果仅使用第一方法900，则在接收到每个请求时生成整个委托授权通证链，并且不存储该链中的任何一个委托授权通证。这具有不需要存储甚至可能不被使用的中间委托授权通证的优点，并且仍然保持强大的访问控制安全性。

参考图9D，示出了总体方法960，以说明这些如何以及何时执行这些操作。当接收到(962)包括委托授权通证和索引的任何请求时，确定(964)之前是否已经计算该请求并将其存储在数据存储设备中。

如果之前没有生成委托授权通证，则从索引开始，生成(966)其他委托授权通证，直到生成最终委托授权通证，或者生成先前计算/接收的已知有效的委托授权通证。如果所生成的委托授权通证中的任何委托授权通证在值和索引上与任何先前接收或生成的委托授权通证相同，则认为所接收的通证是有效的。优选地，仅生成足够的委托授权通证，使得满足先前接收或生成的委托授权通证的索引。例如，如果先前接收或生成H3，并且当前接收到H5’，则仅生成H5’、H4’和H3’。通过将具有最低索引的当前委托授权通证与具有最高索引的先前接收/生成的委托授权通证进行比较来确定当前接收的通证的有效性。例如，通过将H3与H3’进行比较，如上面关于图9B所述。

当核实写入委托授权通证时，优选地，在上述核实方法800的第一步骤802中，客户端还提供“最大写入次数”值作为核实数据的一部分。优选地，使用另一核实步骤来确保受托用户不向服务写入超过允许数量的数据。服务存储与每个委托授权通证相关联的“写入次数”值。这从零开始，并在受托用户每次向服务写入时递增。在核实通证之后，还执行“最大写入次数”核实。该核实将“写入次数”与“最大写入次数”进行比较。如果委托授权通证的“写入次数”等于或大于“最大写入次数”值，则不处理请求。如果委托授权通证的“写入次数”小于“最大写入次数”值，则递增“写入次数”值，并且处理请求。可选地，只有当请求成功地将数据写入事件流和/或区块链时，才会递增“写入次数”。本领域技术人员应当理解的是，这可以适用于除了写入之外的其他交互。写入仅作为一个示例。

在一些实施例中，请求采用HTTP(超文本传输协议)请求或HTTPS(安全超文本传输协议)请求的形式。可选地，将委托授权通证存储在HTTP(S)请求的报头中。或者，报头采用以下形式：

Authorization:Delegated base64(<delegatedAuthIndex>":"<delegatedAuth>)

delegatedAuthIndex和delegatedAuth这两个值的base64编码是可选的。或者，使用这两者的二进制表示。

有利地，通过将委托授权移动到报头，授权过程可以与RFC 7235中描述的基本HTTP认证框架更兼容。

单个代表者

如果仅需要一个代表者来进行读取和/或写入，则使用如参考图6所述的方法600仅生成一个哈希，该方法基于用作单向函数的输入的初始值和种子值的组合。出于核实目的，服务接收该“最终”(和唯一的)委托授权通证。初始值永远不会被使用，因为不存在要重建的委托授权通证链，并且因此客户端可以向服务传递他们想要的任何随机数据，或者不传递任何随机数据。服务将仅接收最终委托授权通证，因此任何接收的请求的核实是所接收的请求的委托授权通证与最终委托授权通证的比较。任何其他通证都将是无效的。

平台系统

根据一个方面，与客户端委托相关的前述方面中的任一项或多项可以与本文所述的平台处理器一起使用。优选地，客户端委托方面用于委托对数据服务1502、计算服务1504和/或商务服务1506的访问，通过客户端委托方面进行的访问由API 1508提供。委托访问可以采用读取、写入、读取/写入、提交和/或可能与特定服务相关联的任何其他动作的形式。本方面可以是平台即服务(PaaS)和软件即服务(SaaS)，其有利地可以实现使用诸如BSV区块链的区块链网络来快速递送有用的现实商业和技术应用，诸如软件控制的技术系统或智能合约的管理。

参考图10A至图10E，示出了与平台服务的示例性交互(如下面参考图11至图13更详细地描述的)。所示的示例性交互如下：将事件附加到事件流；查询(或读取)事件流上的事件；撤销受托用户与事件流交互；创建事件流和委托授权通证；以及包括系统的不同实施例和方面的总体方法。这些是通过关于如何在事件流和平台服务的上下文中使用委托授权通证的示例来提供的。

在这些示例性实施例中，平台(如在先前示例性实施例中所描述的)包括多个组件，包括事件流服务1004、客户端认证服务1006、数据库1008和消息总线1010。

在这些示例中，平台服务提供多个不同的事件流，并且同样地，客户端和/或受托用户提供关于他们希望与哪个特定事件流交互的标识符。因此，请求还包括服务标识符。可选地，如果平台仅提供一个此类服务来与之交互，则不需要任何标识符。

从图10A开始，客户端应用程序1002(可以是如上所述的客户端504或受托用户506)将事件附加到事件流服务1004。客户端应用程序1002向事件流服务发送“appendEvent”请求。“appendEvent”请求包括与事件相关联的数据和delegatedAuth信息；如果客户端应用程序是受托用户，则delegatedAuth信息包括委托授权通证和索引。如果客户端应用程序是客户端502，则使用客户端认证服务1006(与上述或具体地如参考图8所述的任何认证服务分开)来执行不同的客户端认证过程。

事件流服务1004核实数据；然后，如果存在与请求相关联的委托授权信息，则将该信息传递(1014)到数据库1008。数据库被配置为执行如参考图8至图9D所述的核实方法，并存储任何先前生成的委托授权通证。数据库用委托授权(未示出)的有效性来响应所接收的委托授权信息。由于这是一项写入服务，因此数据库还将核实与所使用的特定委托授权通证相关联的写入次数是否未超过先前定义的“最大写入次数”。

利用有效授权的指示符，事件流服务1004继续处理附加信息。这包括将事件插入(1016)到数据库1008中，接收(1018)事件的索引，然后继续经由消息总线1010将事件发布(1020)到区块链，最终完成(1022)任何记账动作，最后用事件被成功附加的指示来响应(1024)客户端应用程序1002。

转到图10B，客户端应用程序1002请求从事件流服务1004读取数据。客户端应用程序1002向事件流服务1004发送“queryData”请求。事件流服务1004核实参数并转到授权(1014)(在存在委托授权通证的情况下)或认证(如果使用替代的客户端认证服务)，方法与“appendEvent”示例1000相同或相似。由于这是一项读取服务，因此优选地不存在最大读取次数、写入次数或要记录的其他最大交互次数。

在客户端应用程序1002被认证或授权的情况下，作为数据查询的一部分的任何滤波器(例如，时间范围、数据类型、提供数据的用户等)用于构建数据库查询。数据库查询可以采用SQL格式。在格式化查询的情况下，将查询以选择的形式提交到数据库1008。将任何记账信息提交(1034)到消息总线1010，以供其他服务查看和管理。最后，以JSON响应的形式向客户端应用程序返回(1036)所请求的数据。

在图10C中，客户端应用程序1002希望撤销委托授权通证。优选地，只有客户端502能够执行此类动作，因此不存在要授权的委托授权通证的选项—只有客户端认证方法是可用的。

客户端向事件流服务1004提交(1052)HTTP请求，该请求包括要撤销的PUT方法。该请求包括：

●esid，其是事件流的ID；

●accessType，其是客户端希望修改的交互，以便数据库知道要引用与事件流相关联的哪个链—优选地，“读取”或“写入”；

●index，其是链中的委托授权通证的索引；以及

●token，其是委托授权通证。

核实这些参数，并对客户端进行认证。

事件流服务1004向数据库1008提交(1054)其他请求，以更新存储受托用户信息的数据存储机制。优选地，存在与每个委托授权通证和/或每个索引相关联的列、标志或其他数据片段(因为并非所有委托授权通证都是已知的)。该数据片段将被更新，以反映即使提供了正确的索引和委托授权通证，通证也不会被视为有效。或者，如果存在与服务相关联的“最大写入次数”，则将该委托授权通证的写入次数设置为等于“最大写入次数”，这将确保所有未来交互都将是无效的。

数据库1008将向事件流服务1004返回(1056)委托授权通证已经被使用的次数。将任何记账信息提交(1058)到消息总线1010，以供其他服务查看和管理。最后，优选地，以JSON响应的形式向客户端应用程序返回(1060)包括撤销是否成功的响应。可选地，该响应还包括使用撤销的委托授权通证完成交互的次数。

如上所述，图10D示出了系统1070，其中客户端根据第二方面和根据图6的方法来创建委托授权通证链，然后在事件流服务上创建事件流。

参考图10E，示出了包括本文所述的多个实施例和特征的整个系统。客户端创建委托授权通证链并创建事件流，如参考图10D所述。在稍后某个时间而不一定是紧接着，客户端提供代表者与事件流交互所需的详细信息。详细信息包括标识要与事件流服务上的哪个事件流交互的标识符(图中为“esid”)、它们的委托授权通证(图中为“H”)和索引(在该示例中为“3”)。利用该信息，代表者具有足够的信息来向具有“appendEvent”请求的事件流服务提交数据。该请求包括从客户端接收的所有相同详细信息以及代表者希望向事件流提交的任何数据。

图10E还示出了发生的示例性撤销。在这里，客户端提交撤销委托授权通证的请求。该请求标识要从(esid)撤销通证的事件流、具有通证索引的通证本身和要撤销的交互类型(在该示例中为“写入”)。如果给定事件流的有效通证和索引匹配，则事件流服务禁用该通证。

平台服务的概览可以在图11中看到，图11示出了系统的概要示意图。平台服务具有提供API 1508的平台处理器1500，服务可以通过API 1508由一个或多个客户端访问。

如图11所示，平台服务1500由三个服务系列组成，旨在让用户和组织轻松、安全地利用区块链的独特属性提供的优势，而无需在客户端实际实现任何基于区块链的软件、知识或库。这些服务包括：

-数据服务1502，旨在简化链作为商品数据分类账的使用，数据服务优选地使用这里提供的数据结构和方法来实现对区块链的数据写入和从区块链的数据读取；

-计算服务1504，旨在提供由比特币SV等数字资产支持的通用计算框架；

-商务服务1506，提供企业级能力，用于使用比特币SV等数字资产处理事务。

可以在API处通过或使用HTTPS协议从客户端接收请求，因为API实现为Web服务。然后，所请求的服务由一个或更多个服务模块或处理资源1502-1506使用底层软件1510来实现，此类底层软件1510与区块链相关联，即实现用于创建、处理和提交与区块链相关联的事务的资源、库和/或密钥管理钱包实现方式。处理后，可以将事务提交给区块链网络1512(而不是实现任何此类功能或事务库的客户端)。客户端最多可以或能够实现与加密货币或某些其他数字资产相关联的数字钱包等，但这并不是必需的，因为平台服务1500也可以为客户端提供和管理数字资产。

图12提供了与区块链相关联的多项服务的更详细的示意图，并且该多个服务可以由平台1600来实现，该平台1600与API相关联，通过该API可以访问所提供的服务中的任何一项或多项。如该图12所示，数据服务1602可以包括数据写入器1602a和数据读取器服务1602b。优选地，如上所述的委托授权用于提供对事件流和/或数据写入器和/或数据读取器的委托访问。类似地，希望通过使用数据读取器1602b访问数据档案的受托用户优选地具有如上所述的委托授权。参照申请号为2002285.1的英国专利申请案(于2020年2月19日以nChain Holdings Limited名义递交)的图4至图8讨论了事件流的进一步细节，并通过引用将其并入本文。数据写入器服务1602a使得客户端能够以简单、安全和优化的方式将数据写入到区块链中。数据读取器服务1602b使客户端能够发送查询，该查询返回存储在区块链中的数据。这可以使用过滤后的流，其中，客户端可以临时或定期(即，在特定时间范围内)预定义他们希望从区块链中读取的数据类型，或与在区块链1610中处理的一组相关或不相关事件或文档相关联的数据类型。数据存档功能允许访问指定事件或合约的先前事务的日志。

平台1600的计算服务1606包括与智能合约相关联的应用程序1606a和框架1606b，在一些实施例中，应用程序1606a和框架1606b可以表示为区块链1610中的状态机。计算服务1606与数据服务1602交互，因为需要输入数据并将结果提供给客户端以进行任何此类计算。

商务服务1604负责基于一流的安全实践和技术，通过企业钱包1604a提供企业级能力，以通过区块链1610处理事务。例如，在一些实施例中，当多个人员、用户或账户可能需要确认符合定义标准的事务(即，与超过某个预定义限制的高价值加密货币相关联)时，企业钱包可以实现启用区块链事务处理的功能。企业钱包还可以包括实现阈值数量和/或类型的签名以移动大量数字资产(例如，表示其他资源的加密货币或通证)的功能。然后，在基于此类企业钱包实现方式所应用的标准进行处理之后，这些资产的移动可以在区块链上表示。

简单支付验证(SPV)服务1608是需要来自区块链的信息的应用程序，但不包括指向区块链的直接链路，因为它们不运行矿工节点。此类SPV服务1608允许轻量级客户端验证事务是否包括在区块链中，而无需下载整个区块链1610。

示例性用例

本文所述的系统和方法实现了与智能合约、区块链以及更具体地与事件流相关的许多不同的使用场景。本文提供的用例仅作为示例，本领域技术人员应当理解的是，可以存在更多用例。本领域技术人员应当进一步理解的是，虽然具体参考事件流，但是这些用例也可以使用其他智能合约技术、其他区块链技术或类似技术来执行。

用例1—投票服务

在存在越来越多的实例的情况下，普通公众有机会就一个或另一个主题进行投票(例如，《The Voice》、《Strictly》、《Goal of the Month》、《Favourite Artist》等)。此类投票可能涉及大量希望在有限的时间段内投票的独立人士。此类公开投票通常使用来电广播节目、Web和手机应用程序前端。这里描述的实施例可以提供使用事件流和委托授权来提供透明度和公共审查的低成本可扩展后端。

假设投票管理员(充当如上所述的客户端502)希望在一组投票者(充当如上所述的受托用户506)中进行投票，其中每个投票者可以在有限的时间段内投出1票到N票。这可以使用事件流服务和委托授权通证来实现，如下所示：

1.投票管理员负责在投票期开始之前向投票者群体创建和分发一组delegatedAuth通证及其delegatedAuthIndex值—统称为“投票者授权通证”(VAT)。个人投票者存储其VAT以供在投票时提交。

2.投票管理员创建在特定时间开始和结束的事件流。

3.投票者可以在投票期间内随时通过调用appendEvent端点进行一次或多次投票。投票必须与有效的VAT一起提交。

4.使用VAT来授权每次投票，并在不使用sequenceNumber的情况下将其附加到流中。单个事件的顺序通常不重要。流可以被配置为通过使用在事件流创建期间可选地提供的最大写入次数来接受每个VAT的1票到N票。

5.在投票期结束时，投票管理员将最终确定事件流，并使用queryData端点统计投票。审计员还可以通过以下方式使用queryData，即使用委托读取访问权限来迭代投票，核实事件数据并根据需要验证链上流状态。

这项投票服务的特性包括：

●投票严格限于拥有有效VAT的投票者群体。

●每个投票者的最大投票数在投票期之前受到投票管理员的严格限制。

●投票期由投票管理员直接控制，投票管理员可以在创建流时确定固定的开始和结束时间。

●事件流服务不知道投票者的身份，因此不具有支持一张投票而不是另一张投票的基础(但是条件是投票者的IP地址可能是已知的)。

●投票将大致按到达时间顺序进行记录。

●由于具体的事件流技术和更一般的区块链技术，所有投票的记录都是不可变和可审计的。事件消息本身可能被混淆，也可能不被混淆(根据投票管理员制定的规则)，这将确定公共审计的实用性。

创建事件流时使用的示例性配置数据：

这里使用事件流和区块链技术有利地提供了在其他“公共”投票情况下通常不存在的透明度。可以安排投票，以便任何投票者都能够在数据集中看到他们自己的投票，并自行计算投票结果。当投票数据以纯文本存储时，此类投票的结果将立即可用；但是当投票数据被混淆时，必须等待投票管理员宣布投票结果。

VAT分发

为了公平投票，必须在投票期开始之前向投票者分发VAT。可以适用于该用例的任何方式分发VAT。这种情况的一个示例可能是向电话应用程序分发每个VAT。VAT可以与注册用户相关联，也可以不与注册用户相关联。

替代方案是将VAT保留在账户数据中，并向账户用户提供Web界面。

替代方案是将拨号电话服务连接到驱动器，驱动器将呼叫和/或键盘输入转换为投票数据，并将每个呼叫和键盘输入与VAT的高速缓存相关联。

每个投票者应用程序都将收到VAT，其中包括称为VAT_N的委托授权通证和索引N。每次投票时，必须提交通证和索引。

VAT验证

通过在创建事件流时提供WIV和WH0，事件服务将预期调用appendEvent，其中包括VAT_N和N，但不包括正常的客户端认证数据。验证过程与上面参考图8和图9A至图9D描述的过程相同或相似。如果之前看到，服务将接受或拒绝投票，具体取决于每个VAT的最大投票数的配置，以及使用VAT_N进行投票的先前投票数。如果之前没有看到，服务必须重复对VAT_N进行哈希处理N次，然后将最终结果与WH0进行比较。如果两者相等，则授权投票并对其进行记录。例如，如果N＝3，在WH0等于H(WIV||H(WIV||H(WIV||H(WIV||VAT3))))的情况下，接受投票。

投票评估

优选地，投票管理员的唯一责任是评估投票和确定结果。

用例2—设备活动日志

高端设备制造者希望访问其客户设备的重要活动日志，这可能是保修或服务协议的一部分。通过分析日志，制造者可能能够采取主动措施，确保设备以峰值效率运行。委托授权通证可以在工厂装配到设备中，使得设备能够在其生命周期内自动记录重要事件—从注册开始。

在这种情况下，建议执行以下操作：

●制造者可以为每个产品线配置单独的事件流。

●委托授权通证将在工厂装配到设备中，其中委托索引记录在制造者的客户端数据库中。

●设备将在其生命周期内自动记录重要事件—从注册开始。

●制造者能够远程监控任何活动，包括心跳、运行时数、关键组件的更换、合格材料的使用等。

创建事件流时使用的示例性配置数据：

用例3—通过投标开展招标过程

考虑一个地方议会，该地方议会希望进行诚实和公开的招标过程。该地方议会将发出招标文件，清楚列明中标的各项要求和依据。

假设有20家公司登记了投标意向。该地方议会必须为至少20个元素创建委托通证，并创建事件流来记录投标。这20家公司将分别获得通证，以便在提交投标文件时使用。也可以提供相同或不同的通证，确保每家公司在招标期结束后阅读所有投标。

可以预先使用流ID(前面示例中的“esid”)来检查流的元数据，以确保招标条件是可接受的。

为了确保公平地开展招标过程，可以按如下方式配置事件流：

配置参数说明：

第39/43页

通过这种配置，已经接收到delegatedAuth通证的公司将能够注册投标文件并对其进行最多3次修改。投标书将在指定的期限内被严格接受，并且在招标期结束之前任何人都不能查看标书。将此类投标信息记录在区块链上提供了一种公开审计此类投标过程的方式，从而确保遵守整个过程，并且从而降低恶意行为者干扰投标过程的可能性，同时总体上提高此类多方交互的安全性。

公司还将能够在提交每份投标书之后不久在链上监控其标书摘要。此类摘要作为存在证明，从而确保标书内容在提交与审计之间不会发生变化。有利地，允许记录存在标书而不显示标书。

用例4—消息混淆

对混淆事件数据的需求(下面的ED)取决于用例。为了提高透明度和便于公共审计，优选地使用纯文本事件数据。然而，事件数据可能非常敏感，甚至不应该泄露给提供事件流的服务。在这些情况下，客户端可能要求以允许客户端读取每个事件而不是其他事件的方式对事件进行混淆处理。实现这一点的一种相对简单的方法是通过共享秘密：

●除了delegatedAuth通证和索引之外，客户端还向每个贡献者提供另一随机数IV(下面的fIV)(即，应当秘密保持的共享秘密)。这将在对贡献者的数据进行加密时用作初始向量。

●每个贡献者根据客户端指定的规则来格式化他们自己的事件数据ED。

●然后，使用AES等通用方法对ED进行加密。使用贡献者的个人iv，以便只有贡献者和客户端可以读取ED。

然后，可以按如下方式构建事件消息：

obfuscatedData＝base64(AES(ED,fIV))

当客户端希望评估贡献者的数据时，他们可以使用queryData来获取事件记录。该记录包含代表者的索引，该索引可以用于查找贡献者的id，并且因此包含共享秘密iv。然后，可以将其用于从混淆数据元素中恢复纯文本事件数据。

平台设备

现在转到图13，提供了可用于实施本公开的至少一个实施例的计算设备2600的说明性简化框图。在各种实施例中，计算设备2600可以用于实现以上示出和描述的任何系统或方法。例如，计算设备2600可以被配置为用作先前描述的图5的系统500中的一个或多个组件。计算设备2600可以被配置为与给定用户相关联的客户端实体；该客户端实体向平台处理器发出数据库请求和/或提交。计算设备2600可以被配置为受托用户。受托用户在接收到其委托授权通证时可以向平台处理器发出数据请求和/或提交。因此，计算设备2600可以是便携式计算设备、个人计算机或任何电子计算设备。如图13所示，计算设备2600可包括具有一级或更多级高速缓存的一个或更多个处理器以及存储器控制器(统称为2602)，所述存储器控制器可被配置为与包括主存储器2608和永久存储器2610的存储子系统2606通信。如图所示，主存储器2608可以包括动态随机存取存储器(DRAM)2618和只读存储器(ROM)2620。存储子系统2606和高速缓存存储器2602可用于存储信息，诸如与本公开中所描述的事务和区块相关联的细节。处理器2602可用于提供本公开中描述的任何实施例的步骤或功能。

处理器2602还可以与一个或更多个用户界面输入设备2612、一个或更多个用户界面输出设备2614和网络接口子系统2616通信。

总线子系统2604可以提供用于使计算设备2600的各个组件和子系统能够按预期彼此通信的机制。虽然总线子系统2604示意性地示出为单个总线，但是总线子系统的替代实施例可以利用多个总线。

网络接口子系统2616可以向其他计算设备和网络提供接口。网络接口子系统2616可以作为从计算设备2600接收数据和向其他系统传输数据的接口。例如，网络接口子系统2616可以使数据技术人员能够将设备连接到网络，使得数据技术人员能够在远程位置(例如数据中心)向设备发送数据并从设备接收数据。

用户界面输入设备2612可以包括一个或更多个用户输入设备，例如键盘；指点设备，如集成鼠标、轨迹球、触摸板或图形平板电脑；扫描仪；条形码扫描仪；包含在显示器中的触摸屏；音频输入设备，如语音识别系统、麦克风；以及其他类型的输入设备。一般而言，术语“输入设备”的使用旨在包括用于向计算设备2600输入信息的所有可能类型的设备和机制。

一个或更多个用户界面输出设备2614可包括显示子系统、打印机、或非视觉显示器(例如音频输出设备等)。显示子系统可以是阴极射线管(CRT)、平板设备(例如液晶显示器(LCD))、发光二极管(LED)显示器或投影或其他显示设备。通常，术语“输出设备”的使用旨在包括用于从计算设备2600输出信息的所有可能类型的设备和机制。例如，可以使用一个或更多个用户界面输出设备2614来呈现用户界面，以便于用户与执行所描述的过程和其中变型的应用程序进行交互(当这种交互可能合适时)。

存储子系统2606可以提供计算机可读存储介质，该计算机可读存储介质用于存储可提供本公开的至少一个实施例的功能的基本编程和数据构造。当由一个或更多个处理器执行时，应用程序(程序、代码模块、指令)可以提供本公开的一个或更多个实施例的功能，并且可以存储在存储子系统2606中。这些应用程序模块或指令可以由一个或更多个处理器2602执行。存储子系统2606可另外提供用于存储根据本公开所使用的数据的存储库。例如，主存储器2608和高速缓存存储器2602可以为程序和数据提供易失性存储。永久存储器2610可以提供用于程序和数据的永久(非易失性)存储，且可包括闪存、一个或更多个固态驱动器、一个或更多个磁硬盘驱动器、一个或更多个具有关联可移动介质的软盘驱动器、一个或更多个具有关联可移动介质的光驱动器(例如CD-ROM或DVD或蓝光)以及其他类似的存储介质。这样的程序和数据可以包括用于执行如在本公开中描述的一个或更多个实施例的步骤的程序以及与在本公开中描述的事务和区块相关联的数据。

计算设备2600可以是各种类型的，包括便携式计算机设备、平板电脑、工作站或下文描述的任何其他设备。另外，计算设备2600可包括可通过一个或更多个端口(例如，USB、耳机插孔、闪电连接器等)连接至计算设备2600的另一设备。可以连接到计算设备2600的设备可以包括被配置为接受光纤连接器的多个端口。因此，该设备可以被配置为将光信号转换成电信号，所述电信号可经由将该设备连接至计算设备2600进行处理的端口传输。由于计算机和网络的不断变化的性质，图13所示的计算设备2600的描述仅用作说明设备的优选实施例的特定示例。与图13中描述的系统相比，具有更多或更少组件的许多其他配置是可能的。

上述各种方法可以由计算机程序实现。计算机程序可以包括被设置为指示计算机执行上述各种方法中的一个或多个的功能的计算机代码。计算机程序和/或用于执行这种方法的代码可以提供给计算机等设备上的一个或多个计算机可读介质，或者更一般地，提供给计算机程序产品。计算机可读介质可以是暂时性的或非暂时性的。一个或多个计算机可读介质可以是例如电子、磁、光、电磁、红外或半导体系统，或用于数据传输的传播介质，例如用于通过互联网下载代码。或者，一个或多个计算机可读介质可以采用一个或多个物理计算机可读介质的形式，例如半导体或固态存储器、磁带、可移动计算机磁盘、随机存取存储器(RAM)、只读存储器(ROM)、硬磁盘和光盘，例如CD-ROM、CD-R/W或DVD。

在一种实现方式中，本文所述的模块、组件和其他特征可以被实现为分立组件或集成在ASIC、FPGA、DSP或类似设备等硬件组件的功能中。

“硬件组件”或“硬件模块”是能够执行某些操作的有形(例如，非瞬时性)物理组件(例如，一组一个或多个处理器)，并且可以某种物理方式来配置或安排。硬件组件可以包括被永久地配置为执行某些操作的专用电路或逻辑。硬件组件可以是专用处理器或包括专用处理器，例如现场可编程门阵列(FPGA)或ASIC。硬件组件还可以包括由软件临时配置以执行某些操作的可编程逻辑或电路。

因此，应当理解的是，短语“硬件组件”或“硬件模块”包括有形实体，该实体可以物理方式构建、永久配置(例如，硬连线)或临时配置(例如，编程)，以便以某种方式操作或执行本文所述的某些操作。

此外，模块和组件可以被实现为硬件设备内的固件或功能电路。此外，模块和组件可以在硬件设备和软件组件的任何组合中实现，也可以仅在软件中实现(例如，在机器可读介质或传输介质中存储或以其他方式体现的代码)。

除非另有具体说明，如以下讨论中显而易见的，应当理解的是，在整个说明书中，使用诸如“确定”、“提供”、“计算”、“标识”、“组合”、“建立”、“发送”、“接收”、“存储”、“估计”、“检查”、“获得”等术语的讨论是指计算机系统或类似电子计算设备的动作和过程，其操纵表示为计算机系统的寄存器和存储器内的物理(电子)量的数据并将其转换为类似地表示为计算机系统存储器或寄存器或其它这类信息存储、传输或显示设备内的物理量的其它数据。

本说明书和权利要求书中使用的术语“包括”是指“至少部分包括”。当解释包括术语“包括”的本说明书和权利要求书中的每一个陈述时，呈现的特征也可能不同于以该术语开始的特征。“包括”等相关术语以相同的方式解释。

旨在引用本文公开的数字范围(例如，1到10)也包括对在该范围内的所有有理数(例如，1、1.1、2、3、3.9、4、5、6、6.5、7、8、9和10)以及在该范围内的任何有理数范围(例如，2到8、1.5到5.5和3.1到4.7)的引用，并且因此本文明确公开的所有范围的所有子范围在此明确公开。这些仅是具体意图的示例，并且所列举的最低值与最高值之间的所有可能的数值组合将被认为在本申请中以类似方式明确说明。

第43/43页

如本文所用，术语“和/或”是指“和”或“或”或两者。

如本文所用，在名词后的“(s)”是指名词的复数和/或单数形式。

元件的单数形式并不排除此类元件的复数形式，反之亦然。

应当理解的是，上述具体实施方式旨在是说明性的，而不是限制性的。在阅读和理解上述具体实施方式之后，许多其它实现方式对于本领域技术人员将是显而易见的。尽管已经参考特定示例性实现描述了本公开，但是要认识到，本公开不限于所描述的实现方式，而是可以在所附权利要求的范围内通过修改和改变来实现。因此，本说明书和附图应被认为是说明性的而不是限制性的。因此，本公开的范围应当参考所附权利要求以及这些权利要求有权获得的等效物的完整范围来确定。

Claims

1.一种计算机实现的方法，所述方法包括：

获取预定值；

接收请求，所述请求包括委托授权通证链中的第一委托授权通证；

生成所述委托授权通证链中的其他委托授权通证，其中所述委托授权通证链中的每个其他委托授权通证的所述生成基于所述委托授权通证链中的先前委托授权通证；

基于所述委托授权通证链中的所述委托授权通证中的一个委托授权通证与所述预定值的比较来确定所述第一委托授权通证的有效性。

2.根据权利要求1所述的计算机实现的方法，其中所述生成基于对所述委托授权通证链中的所述先前委托授权通证进行哈希处理。

3.根据权利要求1或2所述的计算机实现的方法，其中所述的生成所述委托授权通证链中的其他委托授权通证的步骤包括对每个其他委托授权通证执行以下步骤：

确定中间原像，所述中间原像基于所述委托授权通证链中的所述先前委托授权通证；以及

对所述中间原像应用单向函数，所述单向函数的输出是所述其他委托授权通证。

4.根据权利要求3所述的计算机实现的方法，其中所述单向函数是一个单向函数。

5.根据权利要求3或4所述的计算机实现的方法，其中所述中间原像附加地基于给定值。

6.根据权利要求1或2所述的计算机实现的方法，其中其他委托授权通证的所述生成基于所述委托授权通证链中的所述先前委托授权通证和给定值。

7.根据权利要求5或6所述的计算机实现的方法，所述方法还包括以下步骤：

从存储设备获取所述给定值。

8.根据权利要求5至7中任一项或多项所述的计算机实现的方法，其中所述给定值是从客户端接收的。

9.根据权利要求5至8中任一项或多项所述的计算机实现的方法，其中所述生成基于所述给定值和所述先前委托授权通证的级联。

10.根据权利要求9所述的计算机实现的方法，其中所述生成基于对所述给定值和所述委托授权通证链中的所述先前委托授权通证的所述级联进行哈希处理。

11.根据前述任一项权利要求所述的计算机实现的方法，其中所述请求还包括索引号，并且所述委托授权通证链中的委托授权通证的数量基于所述索引号。

12.根据前述权利要求中任一项或多项所述的计算机实现的方法，其中所述的确定所述第一委托授权通证的有效性的步骤基于所述委托授权通证链中的最终委托授权通证与所述预定值的比较。

13.根据前述权利要求中任一项或多项所述的计算机实现的方法，其中所述的确定所述第一委托授权通证的所述有效性的步骤包括：

比较所述预定值和所述委托授权通证链中的所述最终委托授权通证是否具有相同的值。

14.根据前述权利要求中任一项或多项所述的计算机实现的方法，其中所述请求是向区块链提交或从所述区块链读取。

15.根据前述权利要求中任一项或多项所述的计算机实现的方法，其中对所述请求的处理还基于先前接收的包括相同的第一委托授权通证的请求的数量。

16.根据前述权利要求中任一项或多项所述的计算机实现的方法，所述方法还包括以下步骤：

存储所述委托授权通证链。

17.根据权利要求16所述的计算机实现的方法，所述方法还包括以下步骤：

接收其他请求，所述其他请求包括其他委托授权通证；

基于所述其他委托授权通证是否存在于所述存储的委托授权通证链中来确定所述其他委托授权通证的有效性；以及

基于所述其他委托授权通证的所述有效性来处理所述其他请求。

18.根据前述权利要求中任一项或多项所述的计算机实现的方法，所述方法还包括以下步骤：

提供对所述请求的所述有效性的指示和/或基于所述委托授权通证的所述有效性来处理所述请求。

19.一种计算机实现的方法，用于生成相关联的委托授权通证链，所述方法包括：

获取第一值和第二值；

生成所述委托授权通证链中的第一委托授权通证，所述第一委托授权通证基于所述第一值和所述第二值；以及

生成所述委托授权通证链中的至少一个其他委托授权通证，其中所述委托授权通证链中的每个其他委托授权通证的所述生成基于所述第一值和所述委托授权通证链中的先前委托授权通证。

20.根据权利要求19所述的计算机实现的方法，其中所述的生成所述委托授权通证链中的其他委托授权通证的步骤包括对每个其他委托授权通证执行以下步骤：

确定中间原像，所述中间原像基于所述第一值和所述委托授权通证链中的所述先前委托授权通证；以及

21.根据权利要求20所述的计算机实现的方法，其中所述生成基于所述第一值和所述先前委托授权通证的级联。

22.根据权利要求21所述的计算机实现的方法，其中所述生成基于对所述给定值和所述委托授权通证链中的所述先前委托授权通证的所述级联进行哈希处理。

23.根据权利要求19至22中任何一项或多项所述的计算机实现的方法，所述方法还包括以下步骤：

向委托设备提供所述委托授权通证链中的所述委托授权通证中的一个委托授权通证。

24.根据权利要求23所述的计算机实现的方法，其中还向所述委托设备提供所述委托授权通证的索引，所述索引表示所述提供的委托授权通证在所述委托授权通证链中的位置。

25.根据权利要求19至24中任何一项或多项所述的计算机实现的方法，所述方法还包括以下步骤：

向验证设备提供所述第一值和所述委托授权通证链中的最终委托授权通证。

26.根据权利要求25所述的计算机实现的方法，其中还向所述验证设备提供指示每个代表者的最大读取或写入次数的数字。

27.根据权利要求19至26中任一项或多项所述的计算机实现的方法，其中所述委托授权通证链中的所述委托授权通证的数量基于代表者的数量。

28.根据权利要求27所述的计算机实现的方法，其中所述委托授权通证链中的所述委托授权通证的数量大于或等于所述代表者的数量。

29.根据权利要求19至28中任一项或多项所述的计算机实现的方法，其中在生成所述第一委托授权通证之后删除所述第二值。

30.根据权利要求19至29中任一项或多项所述的计算机实现的方法，其中所述第一值和所述第二值是随机生成的。

31.根据前述权利要求中任一项或多项所述的计算机实现的方法，其中所述先前委托授权通证是指紧接在所述生成的委托授权通证之前的所述委托授权通证。

32.根据权利要求1至18中任一项或多项所述的计算机实现的方法，其中所述第一委托授权通证已经由客户端根据权利要求19至31中任一项或多项所述的方法生成。

33.一种计算机实现的方法，所述方法包括以下步骤：

接收根据权利要求19至31中任一项或多项所述的方法生成的委托授权通证；

生成请求，所述请求包括所述委托授权通证；以及

将所述请求发送到服务器。

34.一种系统，所述系统包括：

服务器；

代表者；以及

客户端，所述客户端被配置为：

根据权利要求19至31中的任一项或多项来生成委托授权通证链和第一值；

向所述服务器传输所述第一值和所述委托授权通证链中的最终委托授权通证；以及

向所述代表者传输所述委托授权通证链中的所述委托授权通证中的一个委托授权通证。

35.根据权利要求34所述的系统，其中所述服务器被配置为：

根据权利要求1至18中任一项或多项所述的方法来接收并处理来自所述代表者的请求。