CN116097264A - 电子文件签名 - Google Patents

Abstract

根据第一方面，提供了一种以加密方式链接多个文件的计算机实现的方法，其具有多个电子签名要求，其经由一系列区块链事务，所述方法包括：计算文件签名数据，其满足对现有文件的第一签名要求，所述第一签名要求被定义在包含或引用所述现有文件的区块链事务之中；其中，所述文件签名数据对包含或引用补充文件的链接事务的一部分进行签名，所述链接事务包括输入，所述输入用于有效地花费所述区块链事务的可花费输出，由此所述文件签名以加密方式链接所述补充文件与所述现有文件；其中，被签名的所述部分包括所述链接事务的多个输出；其中，所述多个签名输出中的第一签名输出是可花费的并且与所述现有文件相关联，被签名的所述部分定义对所述现有文件的第二签名要求；其中，所述多个签名输出中的第二签名输出是可花费的并且与所述补充文件相关联，被签名的所述部分定义对所述补充文件的签名要求。

Description

电子文件签名

技术领域

本公开涉及电子文件签名，具体地，涉及用于对多个相互关联的文件应用可以加密方式验证的数字签名并稳健地记录这些签名的系统和方法，所述文件具有随时间的推移发生变化的多个签名要求。

背景技术

文件通常需要由参与者签名，例如，以授权文件或作为对协议或接收的确认。传统上，签署文件的副本，并在必要时通过邮寄或电子方式发送。最近，电子签名变得更加普遍。电子签名允许参与者以电子方式签署文件，而参与者无需获取文件的副本。

有许多不同类型的签名可以粗略地描述为“电子”签名。其中包括实体签名的扫描图像、在平板电脑或其他电子书写设备上生成的手写签名、键入的姓名、视频签名以及实体选中以显示同意的复选框。这种签名可包括附加信息，例如指示参与者提供其签名的时间的时间戳和/或签名时参与者的位置。

相比之下，利用现代密码学原理的数字签名更加可靠和安全。数字签名是一种使用电子签名的加密机制，除非另有说明，本文中提到的电子签名、文件签名等是指这个意义上的数字签名。有效签名的存在给予已签名文件的接收保证，保证文件已由已知发件人发送，并且在运输过程中未被改动。因此，数字签名经常用于检测伪造或篡改至关重要的情况。

数字签名方案使用参与者的私钥和公钥来签署文件和验证签名，这两个密钥以加密方式链接。私钥用于生成签名，该签名可由拥有相应公钥的任何人验证。签名通常是基于待签名文件的加密哈希生成的。如果文件在签名后被改动，那么它将不再与签名的加密哈希匹配，因此签名对于改动后的文件将是无效的。

在不访问签名者的私钥的情况下伪造签名实际上是不可能的。因此，数字签名可提供不可否认性，这意味着签名者不能成功地声称没有提供自己的签名，同时还声称自己的私钥仍然是保密的。也就是说，要么私钥不再是保密的，签名由现在可以访问密钥的第三方提供，要么签名者提供了他们的签名。

发明内容

毫无疑问，支撑数字签名的强大加密机制使其比传统的文件签名更安全。然而，更广泛地使用数字签名进行文件签名的一个障碍是缺乏用于追踪和记录应用于文件的电子签名的类似稳健系统。

当文件的签名要求在文件有效期内发生变化时，和/或当文件需要修改或更新时，这种情况更加严重。例如，被授权签署文件的参与者可能会在文件有效期的不同时间点发生变化。谁被授权可能取决于许多因素。例如，可能存在一个被授权签名的参与者的顺序列表，这样只有列表中参与者之前的人已经签署了文件，该参与者才能签署文件。另一个示例是，参与者只有在他们或其他参与者执行了特定任务时才被授权签名。

如果需要链接多个已签名的文件，这会更加复杂。例如，当特定的参与者对初始文件应用签名时，这可能取决于一个或多个补充文件。这种补充文件在创建初始文件时不一定存在，因此这就需要能够在不同的时间链接不同的文件，即不局限于在创建文件时链接文件。

因此，需要提供一种能够满足更复杂签名需求的文件签名技术。具体地，需要提供将密码验证数字签名应用于多个相互关联的文件的系统和方法，这些文件可在不同的时间点创建，具有随时间推移发生变化的多个签名要求，并且必须由多方以特定的顺序完成。此外，需要提供一种系统，以确保所有各方一致性的方式稳健地记录这些资料。

本公开认识到，区块链数据结构为实现上述要求提供了理想的框架。区块链提供了事务的连续记录，其中将每个新的区块链事务记录到区块链中都是以满足某些要求为条件的。在本文中，利用区块链数据结构的连续性质向现有文件添加新的签名要求，这些要求必须按照特定的顺序完成。在区块链事务的可花费输出中定义了文件签名要求，在定义新签名要求的同时，可以经由具有多个可花费输出的链接事务，可以加密方式验证的方式将多个文件链接在一起。

根据本文公开的一个方面，提供了一种经由一系列区块链事务以加密方式链接具有多个电子签名要求的多个文件的计算机实现的方法，所述方法包括：计算满足对现有文件的第一签名要求的文件签名数据，所述第一签名要求被定义在包含或引用所述现有文件的区块链事务之中；其中，所述文件签名数据对包含或引用补充文件的链接事务的一部分进行签名，所述链接事务包括输入，所述输入用于有效地花费所述区块链事务的可花费输出，由此所述文件签名以加密方式链接所述补充文件与所述现有文件；并且其中，被签名的所述部分包括所述链接事务的多个输出；其中，所述多个签名输出中的第一签名输出是可花费的并且与所述现有文件相关联，被签名的所述部分定义对所述现有文件的第二签名要求；并且其中，所述多个签名输出中的第二签名输出是可花费的并且与所述补充文件相关联，被签名的所述部分定义对所述补充文件的签名要求。

根据本文公开的第二方面，提供了一种用于区块链的链接事务，所述链接事务包括输入和多个输出，所述输入用于有效地花费包含或引用现有文件的区块链事务的可花费输出；其中文件签名数据对包含或引用补充文件的所述链接事务的一部分进行签名，由此所述文件签名以加密方式链接所述补充文件与所述现有文件；并且其中被签名部分包括所述链接事务的多个输出；其中所述多个签名输出中的第一签名输出是可花费的、且与所述现有文件相关联，所述被签名部分定义对所述现有文件的第二签名要求；并且其中所述多个签名输出中的第二签名输出是可花费的、且与所述补充文件相关联，所述被签名部分定义对所述补充文件的签名要求。

在此框架内，还可以可验证的方式方便改变文件的内容或状态。例如，本发明的实施例通过包含在已签名事务中的状态标志承认状态改变。在这种情况下，区块链数据结构的连续性质不仅被用作定义和完成复杂文件签名要求的方式，而且还提供了对已签名文件的内容和/或状态的任何改变的完整历史的不可变和一致的记录。

该技术的实施例利用用于保护区块链的事务验证机制额外提供附加的文件签名验证功能。在这种情况下，文件签名采用事务签名的形式来验证事务，尤其是验证事务之间的花费关系。这样做的好处是，由节点执行的验证区块链事务的现有工作也有助于验证文件签名要求。

附图说明

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

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

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

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

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

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

图5示意性地示出了通用链接事务；

图6示出了示例性进出口流程；

图7示出了提单的图；

图8示出了在进出口流程中使用提单的示例性序列；

图9示出了在进出口流程中使用信用证的示例性流程；

图10示意性示出了如何在区块链上和区块链下验证对文件的修改；

图11示意性地示出了用于链接文件的一组事务。

具体实施方式

示例性系统概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于UTXO的模型

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

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

比方说爱丽丝103a希望创建转移相关数字资产数额至鲍勃103b的事务152j。在图2中，爱丽丝的新事务152j标记为“Tx₁”。该新事务获取在序列中先前事务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₁的输入中的解锁脚本是否包含爱丽丝签名预期部分的数据时的签名。也需要包括预期的部分数据本身(“消息”)，以便执行此认证。在实施例中，签名的数据包括整个Tx₁(因此不需要包括一个单独的元素来明文指定签名的部分数据，因为其本身便已存在)。

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

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

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

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

在实践中，爱丽丝通常还需要包括用于比特币节点104的费用，该比特币节点104在区块151中成功包含爱丽丝的事务104。如果爱丽丝未包括此类费用，则Tx₀可能会被区块链节点104拒绝，并且因此尽管在技术上有效，但可能不会传播并且包括在区块链150中(如果区块链节点104不希望接受事务152，节点协议不强迫区块链节点104接受)。在一些协议中，事务费用不需要其自身的单独输出203(即不需要单独的UTXO)。相反，输入202指向的总数额与给定事务152的输出203指定的总数额之间的任何差额都将自动提供给发布事务的区块链节点104。例如，假设指向UTXO₀的指针是Tx₁的唯一输入，并且Tx₁仅具有一个输出UTXO₁。如果在UTXO₀中指定的数字资产数额大于在UTXO₁中指定的数额，则可以由赢得工作量证明竞赛以创建包含UTXO₁的区块的节点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包括事务引擎401和用户界面(UI)层402。根据上文讨论的方案以及稍后将进一步详细讨论的内容，事务引擎401被配置为实现客户端105的基础事务相关功能，诸如制定事务152，通过侧信道301接收和/或发送事务和/或其他数据，和/或发送事务至一个或更多个节点104以通过区块链网络106传播。根据本文公开的一些实施例，每个客户端105的事务引擎401包括用于生成链接事务的功能403。

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

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

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

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

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

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

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

例如，信息元素503可呈现由用户签名授权的现有文件的可视化表示。用户可查看文件，并决定是否使用签名对文件进行授权。用户可指示希望通过如下所述的可选择元素501或数据输入字段502签署文件。

用户可通过用户可选择元素501或数据输入字段502提供输入，来指示要链接到现有文件的补充文件。例如，在生成链接事务之前，用户可将补充文件上传到电子签名应用程序105，或上传到电子签名应用程序105可访问的数据库，从而存储补充文件库，并存储每个所存储的补充文件的唯一引用。例如，在UI 500上以下拉菜单格式向用户呈现唯一的引用，供用户选择表单。然后，与所选择唯一引用相关联的补充文件链接到链接事务中的现有文件。替代地或附加地，用户可以在生成链接事务时上传补充文件。

一旦用户在链接事务中表示了要链接到现有文件的补充文件，用户提供另一输入，例如通过可选择元素501，该输入启动与链接事务相关联的文件签名数据的计算。该第二用户输入包括与用户相关联的至少一个私钥(例如，用于文件签名的密码或生物特征)。然后，用户的私钥用于计算文件签名数据，用于授权一部分链接事务。用户可能需要将他们的私钥输入数据输入字段502。替代地或附加地，私钥可存储在电子签名应用程序105中，或存储在电子签名应用程序105可访问的某些位置，以便用户提供一些其他用户验证，例如密码或用户生物特征，其授权电子签名应用程序105使用存储的私钥。私钥可以加密或未加密的形式存储。如果采用加密形式，则第二用户输入包括用于解密计算文件签名数据所需的私钥的数据。

电子签名应用程序105使用区块链事务在UI 500上呈现现有文件。如稍后讨论的，区块链事务可包括现有文件的文件数据或对现有文件的引用。因此，可以通过访问区块链事务中的文件数据(如果存储在那里)，或者访问与存储现有文件数据的上一个区块链事务相关的数据，来使用区块链事务呈现现有文件。现有文件可以加密形式(例如，文件的哈希)或未加密形式(例如，明文)存储在区块链上。

或者，电子签名应用程序105可以从链下源(例如，授权文件的最后一个参与者或负责创建文件的参与者)接收现有文件并呈现给用户。电子签名应用程序105可以使用区块链事务来验证所接收的现有文件。文件的副本或哈希存储在区块链上，并可用于该验证。在文件被存储的情况下，电子签名应用程序105可以直接对两个文件进行比较。如果它们相同，则验证接收到的版本。在文件的哈希存储在区块链上的情况下，电子签名应用程序105生成接收到的现有文件的哈希。如果电子签名应用程序105生成的哈希与从区块链事务检索到的哈希匹配，则验证接收到的文件。

电子签名应用程序105在由区块链网络维护的区块链中定位区块链事务。在UI上将现有文件呈现给用户以便用户使用签名授权之前，电子签名应用程序105对区块链事务至少应用了一次有效性检查。可由电子签名应用程序105实现的有效性检查的示例包括在将现有文件呈现给用户以便使用签名授权之前检查区块链事务已不可变地提交到区块链。

在一些实施例中，电子签名应用程序105提供了用于验证文件修改的方法。用户可以通过检查之前谁签署了文件，并将其与已知规则进行比较来验证这些修改。在信息元素503中向用户显示上一个签名者的姓名。可以通过电子签名应用程序105向用户指示上一个签名者已由第三方验证的指示，例如，通过在上一个签名者的姓名旁边呈现指示第三方验证的符号。也可以向用户显示上一个签名者执行的修改，以便他们根据已知的规则进行检查。

电子签名应用程序105本身可以提供验证功能。例如，电子签名应用105知晓已知规则。电子签名应用程序105的验证功能对照已知规则检查从区块链检索到的数据。电子签名应用程序105向用户指示所检索到的数据是否满足已知规则所规定的要求。在一些实施例中，如果满足要求，则文件仅呈现给用户进行签名。在其他实施例中，可以向用户呈现符号或某些其他验证消息，指示是否已满足规则要求。

例如，上面提到的已知规则可以是定义哪些方可以签署文件、各方可以对文件进行的修改类型、各方必须签署文件的顺序和/或是否需要将任何附加文件链接到该文件的规则。应当理解的是，每种不同类型的文件的规则可以是不同的。

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

节点软件

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

一次性支票

如所讨论的，本公开的实施例提供了一种用于在区块链上记录对文件的修改并链接不同文件的方法。为了进一步说明，本文教授了一些可以受益于数字签名技术的可能的现实世界用例。

通过使用如下所述的区块链，区块链提供了文件的不可变记录，记录了任何修改，例如转让、背书和撤销，以及谁对文件进行了修改。

此外，通过文件和比特币事务之间以及比特币钱包地址和身份之间的映射，区块链可以在开发每个文件时提供身份证明、认证、授权、不同文件之间的链接性和可追溯性。应当理解的是，本公开不限于使用比特币和其他类似的基于区块链的可花费硬币。

所公开的方法利用了比特币和类似硬币等加密货币的双重花费预防功能。无法双重花费意味着比特币事务的任何未花费的输出都是一次性的。一次性使用特性可适用于可转让票据。

所公开的方法增加了将任何映射文件伪造到高级别的难度。在使用这些文件的数字副本时，这一点至关重要。提供了文件和未花费事务输出之间的映射。文件状态的任何改变(例如，转让所有权、替换文件或撤销文件)都是通过在新事务中花费事务输出来完成的，该新事务的输出反映了文件的新状态。因此，通过检查包含文件的未花费输出，可以很容易地检查文件的当前状态。在没有授权的情况下，使用过期的文件、伪造文件或改变文件在计算上是不可行的。

如上所述，比特币事务中的解锁脚本包括数字签名，目的是授权将BSV从一个锁定脚本分配到另一个锁定脚本。在这种情况下，UTXO所有者的身份无关紧要。

本文提供的方法将解锁脚本中的数字签名重新使用为插入事务中的数据(例如，文件)的有意义的数字签名。因此，签名者的身份变得相关。

需要公钥证书来提供公钥和所有者身份之间已验证的链接。然而，由于建议不要在多个事务中使用公钥值——否则，在临时密钥生成不够随机时，私钥可能会泄漏——因此在签名事务中使用证书公钥并不理想。

本文提供的方法使用“可链接签名”来解决这个问题。下面将更为详细地说明可链接签名。从本质上讲，区块链用户拥有授权的证书公钥

当他们在区块链上使用签名事务授权时不会使用该公钥。相反，他们使用两个子公钥P_Si和P′_i，其中

可以为单个证书公钥生成许多对子密钥。签名者可以证明知道

的密钥，如果她能提供公钥P_Si和P′_i的签名。这些公钥与三个私钥相关，具有相同的关系，因此

可链接的数字签名可以是包含两个签名的单个事务输入的形式，其中锁定脚本由[P2PKH P_SiP2PKH P′_i]给出。下面示出了可链接签名的示例。

本公开提供了一种将事务的可花费输出链接到文件的方法。

所有权被映射到未花费事务输出的所有者。未花费输出的所有者被称为链接到可花费输出的文件的当前授权参与者。文件可以由当前授权的参与者在新事务中修改。授权的参与者使用其可链接的签名修改和授权新事务。

在本公开中，可转让票据(negotiable instrument)被用作可以修改并链接到其他文件的文件的示例。

可转让票据是所有权或债务凭证，可以在事务中代替货币自由转让。可转让票据是无条件的支付命令或承诺，包括支票、汇票、无记名债券、一些存单、本票、汇票和银行票据。转让收款权的过程，即转让包含付款命令或承诺的文件的过程，称为议付。

可转让性是文件的特征，允许其合法且可无条件地转让。它允许通过背书或交付将其所有权从一方(转让人)转移到另一方(受让人)。

合同文件可以用许多不同的方式修改。这些可能的修改包括：

·创建或签发；

·替换或编辑；

·背书或接受；

·转让；

·完成；以及

·撤销。

应当理解的是，其他类型的修改也是可能的，并且修改的类型取决于文件和用例。这些修改类型将在下面的示例中更详细地讨论。

在任何可转让票据(NI)事务中，都有两个主要参与者:

1.转让人(转让NI所有权的NI当前所有者)，在本文中也称为当前授权参与者；以及

2.受让人(接受NI所有权的NI的新所有者)，在本文中也称为下一授权参与者。

除上述情况外，在票据首次创建时，还可能会有可转让票据签发人作为转让人。

在本文所公开的方法中，转让人必须用其签名授权事务输入，而受让人会知道可解锁事务输出的解锁脚本。为了结合身份证明和认证要求，可链接签名用于授权事务。

每个新事务至少有一个输入，包括对未花费事务输出的引用和与该输出相关联的相应解锁脚本，其中解锁脚本是与授权参与者的证书公钥相关联的一对子密钥的签名。

每个新事务也至少有一个可花费输出。每个输出包括文件数据本身或对文件的引用、下一授权参与者(即可以修改与输出相关联的文件的参与者)的标识符以及对下一授权参与者的证书公钥的引用。在可链接签名的情况下，对证书公钥的引用是与下一授权参与者的证书公钥相关联的一对子密钥的某种形式。

还可以将状态插入到事务的输出中，其指示由使用签名授权事务的授权参与者所执行的修改类型。

首次创建文件时，它被插入到事务输出中，状态为“创建”或“签发”。每当文件被修改时，记录修改的事务输出中的文件状态将被改变以指示该修改。

下面是创建可转让票据的示例性事务。可转让票据从签发人转让给受让人(爱丽丝)。签发人通过使用与公钥P_issuer1和P′_issuer1相对应的秘钥s_issuer和s′_issuer进行签名来使用一种可链接签名的形式，其中具有

并且

是签发人证书公钥。

插入TxID_Issue的数据通常包括以下内容：

1.<NI_Data>，其包括：

a.数据类型的标志和使用的标准，例如通用商业语言(UBL)；

b.对票据的描述；

c.NI的条款和条件或对条款和条件的引用；和

d.统一资源标识符。

2.插入<flag_issue>的数据：

指示NI状态的标志。在上述示例中它的类型是签发。

3.插入<ID_Alice>中的数据包括：

a.下一所有者或授权参与者(爱丽丝)的身份证明；和

b.对签发人证书和身份证明的引用。

插入<P_Alice>的数据是爱丽丝(受让人)的可链接地址，例如，其形式可以是[P2PKHP_AkiceiP2PKHP_A′lii]或2/2多重签名。

然后爱丽丝可以通过使用签名TxID_Issue||0授权在事务中将NI传递给鲍勃。

包含在TxID_Transfer中的数据通常与TxID_Issue不同：

1.添加对首次签发票据的签发事务的引用。这里不重复NI的数据，因为NI数据没有改变；

2.状态已改变为“转让”；并且

3.下一授权参与者的身份证明已改变为鲍勃。

应当理解的是，在某些事务中，新的所有者身份证明可能不会改变。例如，如果授权参与者编辑或替换文件数据，仍然可能授权该参与者修改已编辑或替换的文件。

观察者可以很容易地追踪TxID_Transfer到父事务TxID_Issue，并检查签发人的认证以及确认NI没有双重花费。

NI可以转手给许多所有者。每次它都被记录在事务TxID_i上，其中TxID_i将TxID_i-1作为输入(即父事务)。包含在TxID_i中的数据通常包括状态转让、下一授权参与者和对有效NI数据事务TxID_Issue的引用。

图5示出了根据本发明的修改事务500的示例。TxID_Transfer和TxID_Issue都是修改事务500的示例。修改事务500可由其唯一的事务ID 502标识。唯一的事务ID 502可用于追踪区块链上的文件及其修改。

修改事务500包括输入列表和输出列表，该输入列表包括至少一个输入，该输出列表包括至少一个输出。在图5的示例中示出了两个输入506a、506b和四个输出504a-c，但是应当理解的是，在单个事务中可以使用任意数量的输入和输出。因此，可以使用单个修改事务500来修改多个文件。

修改事务500的每个输入506a、506b包括输出点和锁定脚本。输出点引用上一个修改事务的输出。在传播修改事务500时，不需要将上一个修改事务发布到区块链。

每个输入506a、506b还包括锁定脚本。锁定脚本包括输出点引用的输出的当前授权参与者的可链接签名。

锁定脚本还可包括SIGHASH标志，该标志指示与可链接签名相关联的当前授权参与者正在授权修改事务的哪个输出。例如，如果SIGHASH标志设置为SIGHASH_ALL，则当前授权参与者授权修改事务500的所有修改，即授权事务输出列表中的所有修改。但是，如果设置为SIGHASH_SINGLE，则当前授权参与者只授权修改事务500的单个输出的修改。

修改事务500的每个输出504a、504b、504c、504d都是可花费输出。每个输出504a、504b、504c、504d都有一个关联值，这里显示为satoshi中的数额。应当理解的是，任何区块链货币和任何货币单位都可用来为输出分配值。每个输出504a、504b、504c、504d可在一个或多个后续修改事务中单独分配。

每个输出504a、504b、504c、504d包括锁定脚本。锁定脚本有两个组成部分：存储到区块链的数据和与输出相关联的文件的下一授权参与者的身份。

要存储到区块链的数据包括可转让票据的文件数据或对可转让票据的引用。文件数据不需要在每个事务中存储到区块链，只有在文件数据被改变的事务中才需要存储到区块链，例如在签发或替换文件时。如果需要，可以使用文件引用和每个事务的输出点通过区块链追踪文件的修改，从而找到文件数据。在图5的示例中，有包括文件数据的两个输出504a、504d，和包括对文件的引用的两个输出504b、504c。输出504b和504c中引用的文件的文件数据在上一个修改事务中发布到区块链。

要存储到区块链的数据还包括文件的状态。如上所述，状态指示可转让票据在事务中发生的修改类型。修改由使用签名授权事务的当前授权参与者执行。

例如，输入506a的当前参与者授权修改事务500的所有输出504a、504b、504c、504d。这是由锁定脚本中的SIGHASH_ALL标志指示的。然而，输入506b的当前授权参与者仅授权输出504b，如SIGHASH_SINGLE标志所指示的。输出504a、504c和504d中的文件状态对应于由输入506a的授权参与者执行的修改，输出504b中的文件状态对应于由输入506a和506b的授权参与者执行的修改。

可以使用其他类型的SIGHASH标志。例如，如果需要两个参与者授权修改，但两个参与者中只有一个授权了事务，则可以使用SIGHASH_AnyOneCanPay。也就是说，第二签名参与者可以在稍后添加更多的输入。

使用OP_PUSHDATA脚本操作码插入要存储到区块链的数据。该操作码以输出可花费的方式将数据推送到堆栈上。这与OP_RETURN脚本操作码的情况不同，在OP_RETURN脚本操作码中，数据被推送到堆栈，但输出是不可花费的。应当理解的是，可以使用OP_RETURN脚本而不是OP_PUSHDATA脚本来插入数据。

每个输出504a-d的解锁脚本还包括与输出504a-d相关联的文件的下一授权参与者的标识符。下一授权参与者是被授权在后续修改事务中修改文件的参与者。标识符可包括下一授权参与者的证书公钥和/或下一授权参与者的一对子公钥。

下一授权参与者的标识符可以是支付到公钥(P2PK)或支付到公钥哈希(P2PKH)的形式。在本文使用的示例中使用P2PKH。

输出504a和504c仅标识下一授权参与者。而输出504b和504c标识了两个下一授权参与者。应当理解的是，可以为单个输出标识任何数量的下一授权参与者。

输出504b和504c标识了两个下一授权参与者。输出504d需要1/2多重签名。这允许两个标识的下一授权参与者中的一个或另一个修改文件，而无需另一个标识的下一参与者的授权。下一授权参与者可以执行的修改可能会受到限制。例如，P_next5标识的参与者只有在P_next6标识的参与者尚未修改文件时才能授权对Document_A进行修改。

输出504b需要2/2多重签名。也就是说，需要两个标识的下一授权参与者授权对Documentent_y进行修改。

在后续修改事务中修改文件的下一授权参与者是该文件在后续事务中的当前授权参与者。

每个参与者可被授权仅对文件进行一种或几种类型的修改。例如，当前授权用户可被授权替换或背书文件，但不能将其标记为完成。如上所述，授权参与者被授权进行的修改可能取决于另一授权参与者是否对文件进行了某些修改。这里可以使用1/2多重签名。例如，只有当第二当前授权参与者尚未背书文件时，才可授权第一当前授权参与者将其撤销。

下面将描述修改事务500的示例性实现方式。在本文所举的示例中，已使用运输(进出口流程)中可转让票据的使用作为示例性实现方式。这并非限制性示例，技术人员应当理解的是，所公开的方法可用于涉及可转让票据的修改的任何用例。

在进出口流程中有六个主要角色：出口者、进口者、托运人、承运人、银行和商会。

出口者是拥有商品的人，也称为卖方或制造商。在本文中，使用术语出口者。她/他需要填写：商业发票和原产地证书(COO)。

进口者是购买商品的个人或公司，也称为买方。如果信用证是双方约定的支付方式，则适用信用证。

托运人是负责预定承运人和安排运输的一方。这个人可能是货主，也可能是代理人。它可以是出口者，也可以是进口者。这也称为发货人或运输用户。该方需要填写：装箱单和托运人指示函。

承运人也称为运输服务提供者，负责货物的实际运输。

在国际贸易中，银行起着重要的支付担保作用。稍后将在信用证(LoC)一节中讨论关于它们的不同角色的更多信息。

商会或其他授权的政府机构可能需要签署原产地证书。原产地证书要提交当地商会背书。为了验证出口者的索赔，商会必须能够查阅相关文件，例如商业发票(CI)和提单(BoL)。

图6示出了在进口者604和出口者602之间示例性的出口和进口流程。为了简单起见，图6示出了任何其他参与者。其他参与者的角色将在稍后讨论。

在步骤S610中，进口者604从出口者602处对进口者品进行询价。

在步骤S612中，出口者筛选潜在进口者604和商品将进口到的国家。这一步可能涉及确定是否有进口限制或税收。

在步骤S614中，出口者602向进口者604提供形式发票。

然后在进口者604和出口者602之间完成销售。该步骤包括双方602、604商定以下事项：支付条款、销售条款、商品将如何运输、谁负责运输、谁负责雇用货运代理或承运人、谁负责归档、事务将如何支付(例如，信用证)以及法规要求的其他文件。

在步骤S618中，出口者准备商品。运输文件也在该步骤准备好。运输文件包括：商业发票、装箱单、原产地证书(COO)、托运人指示函和提单(BoL)。附件A描述了这些文件。附件B-E列出了文件的可能状态。

商品在步骤S620中被运输到进口者604，出口者602在步骤S622中执行记录保存任务。

在运输和国际销售中使用的两种主要可转让票据是信用证和提单。稍后将更详细地讨论这些文件。

提单(BoL)有三种功能:

1.它是承运人向托运人发出的决定性收据，即确认货物已装船。

2.它证明了运输合同的条款。

3.它作为商品的所有权凭证(即可转让票据)。

除了3份副本，承运人(或承运人的代理)通常签发3份BoL原件。BoL必须伴随运输产品，并由承运人、托运人和接收人(收货人)的授权代表签名。

BoL中有三个重要参与者：

1.托运人：也称为发货人。这是与承运人订立运输合同的人。可以是进口者或出口者，取决于他们商定的销售条款。

2.承运人：运输公司代表，或船长。这是提供实际运输服务的一方。

3.收货人：根据提单上指示的运输合同有权提货的人。可能是进口者，进口者的银行或开立信用证的银行。

BoL修改到区块链的映射见附件D。

没有真实的BoL，托运人不能放行货物。保护BoL不被伪造是至关重要的。

图7示出了提单的图。BoL包括用于说明货物中的商品类型、每种特定商品的数量和商品目的地的字段。提单应由托运人、承运人和收货人共同签署。

提单可以是可转让的，其中收货人的名字可以改变，以便BoL可以多次转让；或提单可以是不可转让的，以便商品交付给指定的人，并且不能转让。

图8示出了在进出口流程中使用提单的示例性序列。

在步骤S810中，托运人804将带运输的商品转移给承运人802，承运人在步骤S812中装载货物，并在步骤S814中签发BoL。承运人802在签发BoL时签名。

承运人802将BoL提供给托运人804，托运人在步骤S816中签署BoL。

在步骤S818中，承运人802将商品运输到目的地。

在步骤S820中，进口者604签署BoL。BoL并非由三方802、804、604签署。

进口者602在步骤S822中向承运人802显示由三方签署的BoL。这作为进口者604有权获得商品的证明。然后，在步骤S824中，承运人802将商品放行给进口者604。

信用证(LOC)保证进口者或银行向出口者进行支付。如果是后者，则也称为跟单信用证(documentary LOC)。跟单信用证是一种合同，根据该合同，银行同意向出口者进行支付，该支付与特定商品出口相关，但需出示与这些商品相关的特定文件。跟单信用证是应进口者(信用证申请人)的要求，以出口者(信用证受益人)为受益人开立的。信用证通常是一种可转让票据，因为开证行向受益人或受益人指定的任何银行进行支付。

图9示出了在进出口运输方面使用信用证的示例性流程。在这个流程中有四个主要参与方。

受益人904是开立信用证的受益方。在运输方面，这是基础合同中商品的出口者602。

申请人902是应其要求开立信用证的一方。在运输方面，这是进口者604。

在步骤S911中，申请人902和受益人904约定销售条款并交换电子销售合同。

在步骤S912中，申请人902向开证行906申请电子LOC。

开证行906是开立和完成LOC的银行。它是应申请人902的要求或代表其自身开立信用证的银行。它是LOC的最终支付人。自开证行开立信用证之日起，开证行906就不可撤销地有义务对相符提示予以兑付。开证行906主要从两方面评估信用证申请：是否符合开证行政策；以及申请人指令的正确性。

在步骤S913中，开证行906向通知行908开立LOC。这可能受制于一套规则，例如《跟单信用证统一惯例规则》(eUCP)。

通常，通知行908和出口者602位于同一个国家，彼此有业务关系。在事务的议付阶段，出口者602将其通知行908偏好告知进口者604。

通知行908有两个主要职责：

·必须表明其确信信用证或修改书的表面真实性；以及

·必须确保LOC的通知准确反映开证行906的信用证或修改书的条款和条件。

在步骤S914中，通知行908向受益人904通知信用证。然后，受益人904在步骤S915中将货物运输给申请人902，并在步骤S916中将派发的电子文件发送给通知行908作为运输证明。

在步骤S917中，通知行908向开证行906提交电子文件。在步骤S918中，开证行906实施文件控制流程，然后向受益人904发放与运输商品相关联的支付物。这个支付物可以通过通知行908发送给受益人904。

在步骤S919中，开证行906向申请人902发放电子文件。

图11示出了示例性的一组事务，包括三个“链接”事务，用于在运输使用。链接事务TxID₂、TxID₃和TxID₄随着时间的推移依次创建，随后分别创建区块链事务TxID₅和TxID₆。

事务TxID₂和TxID₃是将一个或多个新的补充文件链接到先前事务包含或引用的现有文件的链接事务。事务TxID₄链接至少两个现有文件(都包含在上一个区块链事务中或在其中引用)。

将在下面的描述中提供关于事务TxID₂、TxID₃和TxID₄可能采用的形式的进一步细节，以及伴随描述的事务表。

图11所示的链接事务提供了一种将如附件B-E所示的进出口流程中涉及的文件的不同修改进行链接的方法。

这里使用术语“修改事务”，指修改现有文件的内容或状态的事务。在下面的示例中，链接事务TxID₂、TxID₃和TxID₄在这个意义上也是修改事务，但通常，链接事务不一定是修改事务，修改事务可以是或可以不是链接事务。

爱丽丝是A国的网球制造商和出口者，鲍勃是B国的进口者，他们就销售条款和使用信用证付款达成一致。包括提单在内的运输文件将在区块链上。有四个阶段：

1.爱丽丝和鲍勃约定销售条款，爱丽丝开出发票；

2.爱丽丝准备运输文件和装运；

3.卡罗尔拥有一家运输公司，负责运输。她从爱丽丝那里接收货物，爱丽丝是托运人。卡罗尔向爱丽丝签发提单；

4.爱丽丝在提供运输证明后得到银行的支付；并且

5.鲍勃与银行进行了结算，并使用BOL从卡罗尔那里得到了货物。

每个阶段的事务如下所示。

阶段1：爱丽丝和鲍勃约定销售条款，爱丽丝开出发票。

首先，需要一个初始事务来创建具有可链接签名的事务。TxID_Certexporter是爱丽丝创建的事务，其中她创建了引用她的公钥证书的事务输出。事务的锁定脚本由P2PKH

和P2PKH

的级联组成，其中

并且

是公钥证书。因此在任何事物中花费

都是花费者知道公钥证书中的密钥的证据(即签名者是爱丽丝)。

类似地，任何其他想要使用可链接签名的玩家都应该创建与

类似的事务。

在下一个事务TxID₁中，爱丽丝在事务中映射已开出的商业发票。

事务TxID₁花费

这证明发票数据是由爱丽丝授权的。

TxID₁||0中的锁定脚本<P_exporter>也可以通过附加证书链接到爱丽丝的证书。因此，锁定脚本看起来像：

OP_PUSHDATA<CommercialInvoice><flag:issued>OP_DROP OP_PUSHDATA<PKCertificate_Alice>OP_DROP

当爱丽丝决定替换或撤销发票、支付发票或想要将发票数据链接到运输文件(如下一步所示)时，爱丽丝可以在新事务中花费TxID₁||0。

阶段2：爱丽丝准备运输文件和装运。

爱丽丝创建具有以下文件的事务TxID₂：托运人指示函、原产地证明和装箱单。

她还在TxID₂的输入中花费TxID₁||0，从而将商业发票链接到运输文件。插入第一输出TxID₂||0<Reference_CI||Status:issued>中的数据链接到包含商业发票(CI)数据的事务，并显示发票的当前状态。如果发票有任何新的改变，则将记录在花费TxID₂||0的新事务中。始终可以从事务TxID₁中检索原始发票。另一方面，在花费输出TxID₁||0之后，改变发票数据或状态的权利从输出TxID₁||0转移到输出TxID₂||0。

在该事务中还插入了原产地证书(COO)。商会(COC)签名被插入到第二输入中。

是链接到COC公共证书的事务(即，

与

类似)。应当注意的是，COO是由出口者和COC双方签名签发和背书的。另一方面，由于只能使用2/2多重签名花费输出TxID₂||1，这意味着该文件需要双方(托运人和COC)的签名才能替换或撤销。

装箱单(PL)和SLI文件是由出口者签发的，但尚未由承运人背书。由于已签发且尚未背书，我们希望允许出口者在没有承运人签名的情况下独自撤销或替换任何其中一项。因此，使用了1/2多重签名。这允许承运人在背书文件时独自花费输出，或者只要承运人还没有背书，允许出口者替换或撤销文件。

阶段3：卡罗尔拥有一家运输公司，负责运输。她从爱丽丝那里收到货物，并向爱丽丝签发提单。

在TxID₃，卡罗尔花费TxID₂||2和TxID₂||3，这相当于背书由爱丽丝(托运人)创建的PL和SLI文件。卡罗尔还签发了提单。只有当父事务TxID₂发送时，TxID₃才可以放入区块链中。还应当注意的是，TxID₃的解锁脚本包含PL和SLI的引用，其状态标志从已签发改变为已背书。要改变SLI或PL任一者的状态分别需要花费输出TxID₃||1和TxID₃||2。即，改变这些文件的状态的权利已从TxID₂||2和TxID₂||3的输出的所有者转移到输出TxID₃||1和TxID₃||2的所有者。应当注意的是，由于SLI和PL现在已背书，因此需要承运人和托运人的签名。因此，在TxID₃的第二和第三输出中使用了2/2多重签名。

阶段4：爱丽丝在提供运输证明后得到银行的支付。

爱丽丝需要提供两个重要文件才能获得付款：由承运人签署的提单和发票。爱丽丝使用未花费输出TxID₃||0和TxID₂||0分别用于BOL和银行发票。银行应做到以下几点：

a.追踪所呈现事务TxID_1to3的所有父事务；

b.检查它们是否确实由所声明的实体签名(这包括检查使用了正确的哈希标志)；和

c.检查运输文件(BOL、PL、SLI、COO)中的细节是否与信用证中的条款和条件相符。

当爱丽丝被支付时，她会签署事务TxID₄，其中她花费了TxID₃||0和TxID₂||0。她还将BOL转让到银行，并将该转让映射为输出TxID₄||0，其包含对TxID₃中的BOL的引用和指示输出TxID₄||0的所有者可以收集商品的标志已转让。她还在第二输出中插入对状态标志为已付的商业发票的引用。

银行还可选择地签署该事务，以指示其背书。银行的输入

是提供到银行证书(与爱丽丝的

类似)的链接的事务。

阶段5：鲍勃与银行结算，并得到转让给他的BOL。

鲍勃支付给银行并得到转让给他的BOL，这样他就可以用它来得到商品了。银行创建事务，该事务花费TxID₄||0并在该事务中将BOL转让给鲍勃。鲍勃可以追踪TxID₅的所有事务，以确保所引用的BOL是由承运人签署的，并符合与爱丽丝约定的条款和条件。

阶段6：鲍勃使用提单从卡罗尔那里得到货物。

现在鲍勃使用未花费事务TxID₅||0，以便从卡罗尔处得到商品。他创建事务TxID₆。

应当注意的是，插入TxID₆||0的输出的数据具有标志：现在已交付。卡罗尔可选择地在事务中添加她的签名以表明背书(此处未示出)。

在一些实施例中，当卡罗尔向鲍勃交付并放行商品时，她提供运输服务的证据被记录在TxID₆中。这可能是一个充分的证明。但是，如果需要将PL和SLI文件的标志状态从已背书状态改变为完成状态。在这种情况下，爱丽丝可以签署一个事务TxID₇partial，该事务花费具有PL和SLI文件的两个输出以及标志完成的输出TxID₃||1,2。该事务仍然需要承运人的签名才能完成，因为TxID₃||1,2需要2/2多重签名。银行将保留未完成的事务，并在鲍勃获得提单时将其传递给鲍勃。成功交付商品后，鲍勃将与卡罗尔签署事务TxID₇complete，卡罗尔将完成事务并将其上传到区块链。SIGHASH函数AnyOneCanPay可用于启用部分授权，如以下示例所示。

如上所述，通过将修改映射到区块链，可以追踪文件到其当前状态，并且可以追踪自创建以来对文件的所有修改。

该技术的实施例利用用于保护区块链的事务验证机制额外提供附加的文件签名验证功能。在这种情况下，文件签名采用事务签名的形式来验证事务，尤其是验证事务之间的花费关系。这样做的好处是，由节点执行的验证区块链事务的现有工作也有助于验证文件签名要求。在一些实施例中，系统参与者(即签署文件的参与者)需要检查签名者的身份，并且例如，检查被签署的内容(即使用的SIGHASH)。也就是说，一个事务可以被节点接受并记录到区块链，尽管它不符合事务中文件的已知规则集。

图10示出了如何使用本文所公开的修改事务500在区块链上和区块链下验证修改。

每次创建事务1002、1004、1006时，都会将其传输到区块链的节点，该节点验证该事务并将其发布到区块中的区块链。该流程在上文有更详细的阐述。

在验证事务时，节点通过与上一个事务的输出中标识的下一授权参与者(即由事务输入的输出点标识的参与者)检查事务输入中的参与者的签名，来检查使用签名授权事务的参与者是否被授权这样做。

通过区块链节点的验证，几乎不可能使用撤销或替换的文件、伪造文件的所有权或两次转让文件。它确保对文件的修改只能由授权方进行。

由于文件数据也在签发事务中发布到区块链，区块链可以作为文件的备份。

但是，区块链节点并不验证授权事务的参与者是否被合法授权进行修改。该步骤在区块链下执行。

图10示出了实体X，它是区块链外的实体。为了检查当前的授权参与者是否是被授权进行某种修改的合法授权参与者，实体X访问执行修改的事务1006。标识了事务相关输入的输出点。

实体X使用输出点定位上一个事务1004，其中事务1006的输入是可花费输出。实体X访问上一个事务1004。参与者的身份由输出点标识的上一个事务1004的输出确定。也就是说，实体X访问上一个事务1004的输出中参与者的子公钥。

然后，实体X找到被合法授权进行修改的参与者的证书事务1002。访问该事务1002并提取证书公钥。实体X可以检查事务输出的子公钥与证书公钥之间的关系是否满足。如果是，参与者被合法授权进行修改。

实体X可以执行类似的流程来追踪文件的改变。实体X访问区块链上的事务1006。这可能是与要追踪的文件相关联的未花费的可花费输出的事务。

标识与文件相关联的输入的输出点，并将其用于定位上一个事务1004，该事务的输入是可花费输出。实体X可以访问上一个事务1004，定位相关的可花费输出，根据输出的状态确定对事务1004中的文件所做的修改，并通过检查哪些签名被用于授权事务来确定谁进行了修改。

如果状态是签发或创建，那么事务1004是其中签发文件的事务，因此不存在包括对文件的修改的其他上一个事务。

但是，如果状态不是签发或创建，则在事务1004之前对文件进行了其他修改。实体X可以通过标识事务1004中相关联输入的输出点然后使用输出点定位文件被修改的上一个事务，以类似的方式找到其他上一个事务。这可以一直持续直到找到签发事务。

可以执行类似的流程来追踪文件到其当前状态。在该流程中，通过区块链追踪与文件相关联的可花费输出，直到找到与文件相关联的未花费的可花费输出。

如本文所述，将文件的修改记录到区块链提供了一种稳健地检查文件状态的机制。

在一些实施例中，比特币节点或其他受信任的第三方可以提供额外的服务，执行与下一个参与者可以对文件执行的修改相关的规则。例如，可以通过配置参与者在授权事务中使用的所有客户端(或钱包)通过网关(可信服务器)连接到区块链来实现这样的实施例，该网关确保只有包括允许修改的事务才能进入区块链。受信任的服务器可以是事务中的另一个签名者，只在使用正确的标志时，即只有当参与者被授权执行标志所表示的修改时，才会添加他的签名。所使用的客户端(或钱包)可以经过认证，以便它们符合系统配置，例如使用正确的标志，并确保用户确切地了解他正在做什么，例如他正在授权哪些文件以及他正在对文件进行哪些修改。在一些实现方式中，比特币节点可以比较输出点和输出中的状态标志，以确保符合规则。

尽管在上文描述中已经描述了可链接签名的使用，但应当理解的是，签名者不必将他们的公钥链接到事务。也就是说，文件的所有权可以匿名传递。对于某些用例，可能存在规则和条例，它们决定了是否允许此类实现方式，或者在使用此类实现方式时必须通过其他验证方法来实现。

在一些实施例中，文件作为解锁脚本的一部分插入到事务的输入中。文件可以作为预哈希插入，仅在花费事务时展示。例如，在此类实施例中，事务将在其输出中具有锁定脚本<hashOftheDocument>，并且当花费该事务时，插入<Document>以解锁。

应当理解的是，根据用例的机密性要求，插入到事务中的部分或全部数据可以采用加密形式。不同的项目预计可能有不同的授权访问要求。在这种情况下，可以修改上述公开的方法以提供对该数据的选择访问。例如，也可以插入文件或NI的哈希，而不是文件本身。这种方法将提供保密性，并允许插入任何大小的文件，而不会与比特币层限制相冲突。除了文件的哈希之外，典型的插入还将具有适当的标志和标识符。系统应设计为使得签名者始终知道他们签署了什么。

当将当前技术用于运输等法律用例时，使用最新的表单和程序是很重要的。在区块链上的出口方案可以帮助确保所使用的模板在填充之前处于UTXO中而是最新方案。流程和文件都可以在区块链中描述，并在更新时进行维护。为区块链提供正确接口的参与者钱包总是可以查找最新的表单，并在链上填写表单时处理并指导参与者。

在上述方法中，OP_PUSHDATA用于插入数据。或者，也可以使用OP_RETURN。包含OP_RETURN的输出必然是无效的(不可花费)，因此该输出不会定义签名要求。但是，在这种情况下，文件或引用可以包含在不可花费输出中，与定义签名需求的单独的可花费输出相关联。

也可以在事务中有多个输出，以便通过在事务输出中包含他们的钱包地址来通知其他方(例如进口者、银行、海关、承运人)。

应当理解的是，可以使用元网协议作为上述方法的替代方案。下面给出了一个示例。

在元网协议中，有一个由节点和边组成的有向图。节点是一个事务，边是两个节点(即事务)之间的关联，其中一个事务(子事务)包含另一个事务(父事务)的标识符。因此，对子事务的更新只有在由父事务密钥签名的情况下才能被接受。

上述事务是一个元网事务，其中节点及其父节点的索引由ID_node＝H(P_node||TxID_node)，ID_parent＝H(P_parent||TxID_parent)给出。

可以使用元网协议在区块链上插入BOL数据，如下所示。当托运人使用承运人时，双方之间进行元网事务，并由双方签署。这可能是一个没有父节点的事务，也称为孤事务。下文的TxID_shipping是一个示例。

当承运人到达接收人时，在承运人和接收人之间进行事务，例如下文所示TxID_receiving。它可与作为子代的TxID_shipping相关联。承运人知道P_shipping私钥。

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

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

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

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

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

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

语句1.一种以加密方式链接多个文件的计算机实现的方法，其具有多个电子签名要求，其经由一系列区块链事务，所述方法包括：计算文件签名数据，其满足对现有文件(existing document)的第一签名要求，所述第一签名要求被定义在包含或引用所述现有文件的区块链事务之中；其中，所述文件签名数据对包含或引用补充文件的链接事务的一部分进行签名，所述链接事务包括输入，所述输入用于有效地花费所述区块链事务的可花费输出，由此所述文件签名以加密方式链接所述补充文件与所述现有文件；以及，其中被签名的所述部分包括所述链接事务的多个输出；其中所述多个签名输出中的第一签名输出是可花费的并且与所述现有文件相关联，被签名的所述部分定义对所述现有文件的第二签名要求；且，其中所述多个签名输出中的第二签名输出是可花费的并且与所述补充文件相关联，被签名的所述部分定义对所述补充文件的签名要求。

语句2.根据语句1所述的方法，其中所述第一签名要求在所述区块链事务的所述可花费输出中定义、并且必须被满足才能花费所述可花费输出，所述文件签名数据采取事务签名数据的形式，所述事务签名数据拟包括在所述链接事务的所述输入中、用于有效地花费所述区块链事务的所述可花费输出；其中对所述现有文件的所述第二签名要求在所述第一可花费输出中定义，并且必须被满足才能花费所述链接事务的所述第一可花费输出；以及，其中对所述补充文件的所述第二签名要求在所述第二可花费输出中定义，并且必须被满足才能花费所述链接事务的所述第二可花费输出。

语句3.根据语句1或2所述的方法，其中所述链接事务的所述签名要求中的至少一个签名要求包括至少一个公钥。

语句4.根据语句3所述的方法，其中所述公钥可从认证事务的公钥证书进行验证，所述链接事务的被签名的所述部分标识所述认证事务。

语句5.根据语句4所述的方法，其中所述链接事务经由一个或多个事务花费关系与所述认证事务直接或间接关联，从而标识所述认证事务。

语句6.根据语句3至5中任一项所述的方法，其中所述公钥认证主公钥，但所述签名要求不要求直接使用对应的私钥，而替代地是包括临时公钥和复合公钥，所述复合公钥是从所述临时公钥和所述主公钥推导出的。

语句7.根据前述任一项语句所述的方法，其中所述区块链事务包括与所述现有文件相关联的第一状态标志，并且所述链接事务的被签名的所述部分包含与所述现有文件相关联的第二状态标志和与所述补充文件相关联的状态标志。

语句8.根据前述任一项权利要求所述的方法，其中所述现有文件包含在所述区块链事务的所述可花费输出中、或在其中引用；其中所述链接事务的所述第一可花费输出包含对所述现有文件的引用，且所述链接事务的所述第二可花费输出包含所述后续文件的数据。

语句9.根据从属于语句7的语句8所述的方法，其中所述现有文件的所述第一状态标志包含在所述区块链事务的所述可花费输出中，所述现有文件的所述第二状态标志包含在所述链接事务的所述第一可花费输出中，所述后续文件的所述状态标志包含在所述链接事务的所述第二可花费输出中。

语句10.根据语句1至7中任一项所述的方法，其中所述现有文件包含在所述区块链事务的不可花费输出中；其中所述链接事务的被签名的所述部分包括一个或多个不可花费输出，所述一个或多个不可花费输出包含对所述现有文件的引用和所述后续文件的数据。

语句11.根据语句1至8中任一项所述的方法，其中所述现有文件的数据包含在所述链接事务的所述输入中，以满足所述区块链事务的所述可花费输出的现有文件挑战。

语句12.根据从属于语句7的语句11所述的方法，其中所述现有文件的所述第二状态标志包含在所述链接事务的所述输入中。

语句13.根据前述任一项语句所述的方法，其中所述链接事务的所述签名要求中的至少一个签名要求需要来自多个参与方的事务签名。

语句14.根据前述任一项语句所述的方法，其中所述链接事务的所述签名要求中的至少一个签名要求标识多个参与方，但仅要求来自被标识的所述参与方的子集的事务签名。

语句15.根据前述任一项语句所述的方法，其中所述补充文件是另一现有文件，并且所述链接事务包括第二输入，所述第二输入用于有效地花费第二区块链事务的可花费输出，所述第二区块链事务包含或引用所述另一现有文件；其中对所述另一现有文件的所述签名要求是对所述另一现有文件的第二签名要求，所述方法包括：计算另一文件签名数据，其满足所述第二区块链事务中定义的对所述另一现有文件的第一签名要求。

语句16.根据从属于语句2的语句15所述的方法，其中对所述另一现有文件的所述第一签名要求被定义在所述第二区块链事务的所述可花费输出中，其中所述另一文件签名数据采取另一事务签名数据的形式，所述另一事务签名数据用于所述链接事务的所述第二输入，所述第二输入用于有效地花费所述第二区块链事务的所述可花费输出。

语句17.一种用于链接和签署多个文件的电子签名应用程序，所述多个文件具有多个签名要求，所述数字签名应用程序在非暂时性介质中体现为程序指令，并且被配置为在计算机上执行时实现前述任一项语句所述的方法。

语句18.根据语句17所述的电子签名应用程序，还被配置为通过以下操作呈现用于链接和签署所述文件的可视化文件签名界面：使用区块链事务呈现拟签名的现有文件的可视化表示；接收第一用户输入，用于表示要链接到所述现有文件的所述补充文件；接收第二用户输入，用于计算所述文件签名数据。

语句19.根据语句18所述的电子签名应用程序，被配置为在由区块链网络维护的区块链中定位所述区块链事务，并且在呈现所述现有文件进行签名之前对所述区块链事务应用至少一次有效性检查。

语句20.根据语句19所述的电子签名应用程序，其中所述至少一次有效性检查包括：在呈现所述现有文件进行签名之前检查所述区块链事务已不可变地提交给所述区块链。

语句21.根据语句19或20所述的电子应用程序，被配置为使用所述区块链事务从所述区块链检索所述现有文件用以在文件签名界面中呈现，所述现有文件以加密或未加密的形式存储在所述区块链中。

语句22.根据语句19或20所述的电子签名应用程序，被配置为接收所述现有文件以从链下源呈现，并使用所述区块链事务来验证所述接收的现有文件，所述区块链存储所述现有文件的副本或哈希以执行所述验证。

语句23.根据语句18至22中任一项所述的电子签名应用程序，其中所述第二用户输入包括用于计算所述文件签名数据的至少一个私钥。

语句24.根据语句18至22中任一项所述的电子签名应用程序，其中所述第二用户输入包括用于对计算所述文件签名数据所需的至少一个私钥进行解密的数据，所述加密的私钥存储在所述电子签名应用程序可访问的位置。

语句25.根据从属于语句3的语句17至24中任一项所述的电子签名应用程序，被配置为根据与所述公钥相关联的认证事务的公钥证书验证所述公钥。

语句26.一种用户设备，包括：一个或多个处理器，被配置为实现根据权利要求17至25中任一项所述的电子签名应用程序；以及，用户界面，用于接收用户输入。

语句27.一种用于区块链的链接事务，所述链接事务包括输入和多个输出，所述输入用于有效地花费包含或引用现有文件的区块链事务的可花费输出；其中，文件签名数据对包含或引用补充文件的所述链接事务的一部分进行签名，由此所述文件签名以加密方式链接所述补充文件与所述现有文件；其中，被签名部分包括所述链接事务的多个输出；其中，所述多个签名输出中的第一签名输出是可花费的、且与所述现有文件相关联，所述被签名部分定义对所述现有文件的第二签名要求；以及，其中，所述多个签名输出中的第二签名输出是可花费的、且与所述补充文件相关联，所述被签名部分定义对所述补充文件的签名要求。

语句28.一种用于区块链网络的节点，其包括一个或多个处理器，被配置为：通过检查对链接事务的被签名部分进行签名的文件签名数据满足区块链事务中定义的第一签名要求来验证根据前述任一项权利要求所述的链接事务。

语句29.一种用于实现根据语句1至16中任一项所述的方法的计算机系统，所述计算机系统包括根据语句26所述的用户设备和根据语句28所述的节点。

根据本文公开的另一方面，可提供一种方法，该方法包括提供文件签名数据的签名方的动作。

附件A

下表简要描述了运输和国际贸易中使用的主要文件。

附件B

商业发票有以下几种状态：

·已由出口者签发；

·已由出口者撤销；

·已由出口者撤销并替换；

·已支付。

下表说明了如何将对商业发票的修改映射到区块链上的事务。

附件C

装箱单和托运人指示函具有以下状态：

·已由发货人创建；

·已由托运人撤销；

·已由托运人撤销并替换；

·已由承运人或代理人背书并接收；

·已由服务提供者提供服务。

下表说明了如何将对装箱单和托运人指示函的修改映射到区块链上的事务。

已背书文件的事务可以通过以下各方花费：

1.当提供并完成已背书文件服务中的服务时，由接受服务的实体进行

2.当承运人和托运人同意撤销或替换文件时，由承运人和托运人进行

3.当托运人想要撤销或替换协议时(如果在该阶段允许)，由托运人独自进行

4.当承运人想要撤销协议时(如果在该阶段允许)，由承运人独自进行

附件D

下表说明了如何将对BoL的修改映射到区块链上的事务。

附件E

原产地证书有以下几种状态：

·已由出口者创建；

·已由出口者撤销；

·已由出口者撤销并替换；

·已由适当的授权机构(例如商会)背书和认证。

下表说明了如何将对原产地证书的修改映射到区块链上的事务。

Claims (29)

1.一种以加密方式链接多个文件的计算机实现的方法，其具有多个电子签名要求，其经由一系列区块链事务，所述方法包括：

计算文件签名数据，其满足对现有文件的第一签名要求，所述第一签名要求被定义在包含或引用所述现有文件的区块链事务之中；

其中，所述文件签名数据对包含或引用补充文件的链接事务的一部分进行签名，所述链接事务包括输入，所述输入用于有效地花费所述区块链事务的可花费输出，由此所述文件签名以加密方式链接所述补充文件与所述现有文件；以及

其中，被签名的所述部分包括所述链接事务的多个输出；

其中，所述多个签名输出中的第一签名输出是可花费的并且与所述现有文件相关联，被签名的所述部分定义对所述现有文件的第二签名要求；以及

其中，所述多个签名输出中的第二签名输出是可花费的并且与所述补充文件相关联，被签名的所述部分定义对所述补充文件的签名要求。

2.根据权利要求1所述的方法，其中所述第一签名要求在所述区块链事务的所述可花费输出中定义、并且必须被满足才能花费所述可花费输出，所述文件签名数据采取事务签名数据的形式，所述事务签名数据待包括在所述链接事务的所述输入中、用于有效地花费所述区块链事务的所述可花费输出；

其中对所述现有文件的所述第二签名要求在所述第一可花费输出中定义，并且必须被满足才能花费所述链接事务的所述第一可花费输出；

其中对所述补充文件的所述第二签名要求在所述第二可花费输出中定义，并且必须被满足才能花费所述链接事务的所述第二可花费输出。

3.根据权利要求1或2所述的方法，其中所述链接事务的所述签名要求中的至少一个签名要求包括至少一个公钥。

4.根据权利要求3所述的方法，其中所述公钥可从认证事务的公钥证书进行验证，所述链接事务的被签名的所述部分标识所述认证事务。

5.根据权利要求4所述的方法，其中所述链接事务经由一个或多个事务花费关系与所述认证事务直接或间接关联，从而标识所述认证事务。

6.根据权利要求3至5中任一项所述的方法，其中所述公钥认证主公钥，但所述签名要求不要求直接使用对应的私钥，而是包括临时公钥和复合公钥，所述复合公钥是从所述临时公钥和所述主公钥推导出的。

7.根据前述任一项权利要求所述的方法，其中所述区块链事务包括与所述现有文件相关联的第一状态标志，并且所述链接事务的被签名的所述部分包含与所述现有文件相关联的第二状态标志和与所述补充文件相关联的状态标志。

8.根据前述任一项权利要求所述的方法，其中所述现有文件被包含于或被引用于所述区块链事务的所述可花费输出中；

其中所述链接事务的所述第一可花费输出包含对所述现有文件的引用，且所述链接事务的所述第二可花费输出包含所述后续文件的数据。

9.根据从属于权利要求7的权利要求8所述的方法，其中所述现有文件的所述第一状态标志包含在所述区块链事务的所述可花费输出中，所述现有文件的所述第二状态标志包含在所述链接事务的所述第一可花费输出中，所述后续文件的所述状态标志包含在所述链接事务的所述第二可花费输出中。

10.根据权利要求1至7中任一项所述的方法，其中所述现有文件包含在所述区块链事务的不可花费输出中；其中所述链接事务的被签名的所述部分包括一个或多个不可花费输出，所述一个或多个不可花费输出包含对所述现有文件的引用和所述后续文件的数据。

11.根据权利要求1至8中任一项所述的方法，其中所述现有文件的数据包含在所述链接事务的所述输入中，以满足所述区块链事务的所述可花费输出的现有文件挑战。

12.根据从属于权利要求7的权利要求11所述的方法，其中所述现有文件的所述第二状态标志包含在所述链接事务的所述输入中。

13.根据前述任一项权利要求所述的方法，其中所述链接事务的所述签名要求中的至少一个签名要求需要来自多方的事务签名。

14.根据前述任一项权利要求所述的方法，其中所述链接事务的所述签名要求中的至少一个签名要求标识多方，但仅要求来自被标识方的子集的事务签名。

15.根据前述任一项权利要求所述的方法，其中所述补充文件是另一现有文件，并且所述链接事务包括第二输入，所述第二输入用于有效地花费第二区块链事务的可花费输出，所述第二区块链事务包含或引用所述另一现有文件；

其中对所述另一现有文件的所述签名要求是对所述另一现有文件的第二签名要求，所述方法包括：

计算另一文件签名数据，其满足所述第二区块链事务中定义的对所述另一现有文件的第一签名要求。

16.根据从属于权利要求2的权利要求15所述的方法，其中对所述另一现有文件的所述第一签名要求被定义在所述第二区块链事务的所述可花费输出中，其中所述另一文件签名数据采取另一事务签名数据的形式，所述另一事务签名数据用于所述链接事务的所述第二输入，所述第二输入用于有效地花费所述第二区块链事务的所述可花费输出。

17.一种用于链接和签署多个文件的电子签名应用程序，所述多个文件具有多个签名要求，所述数字签名应用程序在非暂时性介质中体现为程序指令，并且被配置为在计算机上执行时实现前述任一项权利要求所述的方法。

18.根据权利要求17所述的电子签名应用程序，还被配置为通过以下操作呈现用于链接和签署所述文件的可视化文件签名界面：

使用区块链事务呈现待签名的现有文件的可视化表示，

接收第一用户输入，用于表示要链接到所述现有文件的所述补充文件；

接收第二用户输入，用于计算所述文件签名数据。

19.根据权利要求18所述的电子签名应用程序，被配置为在由区块链网络维护的区块链中定位所述区块链事务，并且在呈现所述现有文件进行签名之前对所述区块链事务应用至少一次有效性检查。

20.根据权利要求19所述的电子签名应用程序，其中所述至少一次有效性检查包括：在呈现所述现有文件进行签名之前检查所述区块链事务已不可变地提交给所述区块链。

21.根据权利要求19或20所述的电子应用程序，被配置为使用所述区块链事务从所述区块链检索所述现有文件用以在文件签名界面中呈现，所述现有文件以加密或未加密的形式存储在所述区块链中。

22.根据权利要求19或20所述的电子签名应用程序，被配置为接收所述现有文件以从链下源呈现，并使用所述区块链事务来验证所述接收的现有文件，所述区块链存储所述现有文件的副本或哈希以执行所述验证。

23.根据权利要求18至22中任一项所述的电子签名应用程序，其中所述第二用户输入包括用于计算所述文件签名数据的至少一个私钥。

24.根据权利要求18至22中任一项所述的电子签名应用程序，其中所述第二用户输入包括用于对计算所述文件签名数据所需的至少一个私钥进行解密的数据，所述加密的私钥存储在所述电子签名应用程序可访问的位置。

25.根据从属于权利要求3的权利要求17至24中任一项所述的电子签名应用程序，被配置为根据与所述公钥相关联的认证事务的公钥证书验证所述公钥。

26.一种用户设备，包括：

一个或多个处理器，被配置为实现根据权利要求17至25中任一项所述的电子签名应用程序；以及

用户界面，用于接收用户输入。

27.一种用于区块链的链接事务，所述链接事务体现在计算机可读介质上，并包括输入和多个输出，所述输入用于有效地花费包含或引用现有文件的区块链事务的可花费输出；

其中，文件签名数据对包含或引用补充文件的所述链接事务的一部分进行签名，由此所述文件签名以加密方式链接所述补充文件与所述现有文件；

其中，被签名部分包括所述链接事务的多个输出；

其中，所述多个签名输出中的第一签名输出是可花费的、且与所述现有文件相关联，所述被签名部分定义对所述现有文件的第二签名要求；

其中，所述多个签名输出中的第二签名输出是可花费的、且与所述补充文件相关联，所述被签名部分定义对所述补充文件的签名要求。

28.一种用于区块链网络的节点，其包括一个或多个处理器，被配置为：通过检查对链接事务的被签名部分进行签名的文件签名数据满足区块链事务中定义的第一签名要求来验证根据前述任一项权利要求所述的链接事务。

29.一种用于实现根据权利要求1至16中任一项所述的方法的计算机系统，所述计算机系统包括根据权利要求26所述的用户设备和根据权利要求28所述的节点。

Images