CN115427995A - 时间锁定的区块链事务和相关区块链技术 - Google Patents

Abstract

一种基于在多方之间交换的一系列花费事务的区块链支付通道，其中：出资事务，其提交到区块链，包括锁定到所述多方的至少两个公钥的至少一个可花费的事务输出，其中所述出资事务包含或以其它方式证明用于至少部分地计算所述一系列花费事务的函数。所述一系列花费事务中的先前事务在所述多方的一方的计算机设备上接收。所述出资事务中包含或以其它方式证明的所述函数用于至少部分地计算所述当前事务。所述方使用与所述方的所述公钥对应的私钥来对所述当前事务的一部分进行加密签名，所述已签名部分包括所述至少两个可花费的事务输出，从而计算事务签名以包含在所述当前事务的所述事务输入中。

Description

时间锁定的区块链事务和相关区块链技术

技术领域

本公开总体涉及通信框架，其中“时间锁定的”区块链事务(或其组件)在实体之间进行交换，但通常只有在锁定时间到期后，这些事务的子集(例如，单一事务)才提交到区块链。本公开还涉及用于促进此类交换或以其它方式与之相关的步骤、系统、计算机程序和/或事务等。

背景技术

区块链是指一种分布式数据结构形式，其中在点对点(P2P)网络中的多个节点中的每个节点处维护区块链副本。区块链包括一系列数据区块，其中每个区块包括一个或更多个事务(transaction)。每个事务都可以回指序列中的先前事务，其可以扩展一个或更多区块。事务可以通过提交到网络包括在新区块中。新区块的创建过程称为“挖掘”，该过程涉及多个挖掘节点中的每个挖掘节点争相执行“工作量证明”，即基于等待包括在区块中的未决事务池解决加密难题。

区块链中的事务通常用于传递数字资产，即用作价值储存手段的数据。但是也可利用区块链实现区块链上的分层附加功能。例如，区块链协议可允许在事务输出中存储附加用户数据。现代区块链在单一事务中可储存的最大数据容量在不断增加，从而能够并入更复杂的数据。例如，这可用于在区块链中存储电子文档，甚至音频或视频数据。

网络中的每个节点可以具有以下三个角色中的任何一个、两个或全部：转发、挖掘和存储。转发节点在整个网络节点中传播事务。挖掘节点将事务挖掘到区块中。存储节点各自对区块链中的已挖掘区块存储自己的副本。为了将事务记录在区块链中，一方将该事务发送到网络中的节点中的一个节点进行传播。接收该事务的挖掘节点可以争相将该事务挖掘到新区块中。每个节点被配置为遵守相同的节点协议，该协议将包括用于确认事务有效的一个或更多个条件。无效事务将不会传播或挖掘到区块中。假定事务已经核实有效，从而在区块链上被接受，则该事务(包括任何用户数据)将因此作为不可改变的公共记录，继续存储在P2P网络中的各个节点处。

成功解决工作量证明难题以创建最新区块的矿工通常被奖励一个称为“区块创始事务”的新事务，该事务会生成新的数字资产数额。工作量证明激励矿工不要欺骗系统，在他们的区块中包括双重花费事务，因为挖掘区块需要大量计算资源，而包括试图双重花费的区块很可能不会被其他节点接受。

在“基于输出的”模型(有时称为基于UTXO的模型)中，给定事务的数据结构包括一个或更多个输入(事务输入)和一个或更多个输出(事务输出)。任何可花费输出包括指定数字资产数额的元素，有时称为UTXO(“未花费的事务输出”)。该输出还可以包括指定用于赎回该输出的条件的锁定脚本。每个输入包括指向先前事务中的此类输出的指针，并且还可以包括解锁脚本以用于解锁指向输出的锁定脚本。因此，考虑一对事务，将其称为第一事务和第二事务(或“目标”事务)。第一事务包括指定数字资产数额的至少一个输出，并且包括定义解锁该输出的一个或更多个条件的锁定脚本。第二事务(目标事务)包括至少一个输入和解锁脚本，该至少一个输入包括指向第一事务的输出的指针；该解锁脚本用于解锁第一事务的输出。

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

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

在目前使用的区块链协议中，至少有一种区块链协议定义了“序列号”和“锁定时间”的相关概念。在一个特定的基于UTXO的模型中，事务的输入(或每个输入)具有序列号，该序列号可以取介于最大序列号和最小序列号之间的值(例如，以十六进制记数法表示的0x00000000到0xFFFFFFFF之间的值)。事务也可具有定义的锁定时间，并且只有在锁定时间到期后才能生效(即使在该时间点之前满足所有其它有效性要求也是如此)。在该时间点之前，事务被称为“时间锁定的”事务。在创建同一事务的多个版本的情况下(或更准确地说，当创建全部满足解锁相同输出条件的多个事务时)，序列号和锁定时间可实现确定性。如果没有定义的锁定时间，创建两个此类事务将导致“双重花费”的不确定性：两个事务均可提交到区块链网络进行核实，并且不一定能够肯定地预测哪个事务最终会被挖掘到有效的区块中(此时另一个事务将失效)。

但是，具有定义的未来锁定时间的事务只有在锁定时间到期后才能生效。此外，如果两个其它有效事务被提交到区块链网络，这两个事务解锁相同的输出并且锁定时间已到期，则矿工只会接受具有较高序列号的事务——即使锁定时间已到期并且满足所有其它有效性要求，具有较低序列号的事务将失效。

发明内容

序列号和锁定时间可用于实现特定形式的区块链支付通道。在区块链上下文中，“支付通道”一词指支付通道的两方或更多方(参与方)之间的特定形式的“链下”通信。支付通道可用于交换一系列花费事务，解锁相同的输出，并且具有未来的锁定时间和递增的序列号。每个花费事务都可以是有效的，但其锁定时间尚未到期，并且受在该时间点之前创建的具有较高序列号的同等有效的花费事务所约束。这提供了安全的技术框架，其中两方或更多方可以进行协商——期望能够达成彼此同意的结算事务以终止协商，但如果另一方或当事方提前终止协商或以其它恶意方式行事，则每一方均可以选择在锁定时间到期后发布序列号最高的花费事务。

只需在协商的每一步将约定事务提交到区块链，即可取得类似的结果。但是，这需要更多的时间和计算资源来处理每个事务并等待达成必要的共识。通常情况下，各方不仅必须等待事务被挖掘成区块，而且必须等待额外几个区块被挖掘，以便区块链网络在开展下一步协商之前针对区块的有效性达成共识。对于步骤数量较多的协商而言，无论是时间延迟还是处理区块链网络中诸多事务所需的计算资源方面，这都是极其低效的。

本公开总体涉及一种用于实现区块链“支付通道”的新型框架。应当注意的是，尽管有上述术语，本公开的支付通道不限于协商支付，通常而言，本公开的支付通道提供了高效的计算方式，以根据一组协定的规则安全地进行链下通信。本文解决的核心问题在于区块链支付通道上下文中的平衡效率(在时间和计算资源方面)和安全性问题。在当前上下文中，安全性是指支付通道对于违反支付通道约定规则的一方(或更多方)的稳健程度。

根据本文公开的一方面，提供了一种基于在各方之间交换的一系列花费事务建立区块链支付通道的计算机实现的方法，其中：出资事务，其提交到区块链，包括锁定到所述各方的至少两个公钥的至少一个可花费的事务输出，其中所述出资事务包含或以其它方式证明用于至少部分地计算所述一系列花费事务的函数；所述一系列花费事务中的每个事务都有未来的锁定时间，在所述未来的锁定时间之前不能提交到所述区块链，并且包括：(i)至少一个事务输入，其包含指向所述出资事务的所述可花费的事务输出的指针；(ii)至少两个可花费的事务输出，其具有相应的数字资产值；所述一系列花费事务中的初始事务具有最低序列号，所述一系列花费事务中每个后续事务的序列号均高于先前事务的序列号；其中所述方法包括由所述各方中的一方：在所述方的计算机设备上接收所述一系列花费事务中的先前事务；使用所述出资事务中包含或以其它方式证明的所述函数至少部分地计算所述当前事务；使用与所述方的所述公钥对应的私钥来对所述当前事务的一部分进行加密签名，所述已签名部分包括所述至少两个可花费的事务输出，从而计算事务签名以包含在所述当前事务的所述事务输入中。

附图说明

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

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

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

图2A示出了出资事务和两个合作“循环”事务的示例；

图3是另一种用于实现区块链支付通道的系统的示意性框图；

图3A示出了用于实现区块链支付通道的系统的第二示例；

图3B示出了用于实现区块链支付通道的系统的第三示例；

图4A是客户端应用程序的示意性框图；

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

图4C是可由图4A的客户端应用程序表示的示例性用户界面的示意性模型；

图5从概念上示出了如何在UTXO模型中建立区块链事务之间的花费关系；

图6A、图6A和图6B示出了用于实现“支付通道循环”的示例性流程；

图7示出了“for”支付通道循环的一个示例；

图8示出了如何使用定义的功能单元迭代地创建循环事务；

图9A和图9B示出了用于建立安全支付通道的不同“2/2”出资事务的示例；

图10示出了出资事务与循环事务之间的关系；

图11A和图11B分别示出了结算事务及其与出资事务的关系的示例；

图12至图16示出了支付通道循环的不同实施方式的多种示例性流程；

图17示出了“2/3”出资事务；

图18A和图18B分别示出了证明一系列输入值和/或参数的结算事务，以及证明一系列事务的数据结构。

具体实施方式

区块链由区块链网络(区块链节点的对等网络，每个节点执行一个或更多个挖矿角色、转发角色和存储角色)维护。“提交”事务指已由维护区块链的区块链网络的挖矿节点核实并且已由挖矿节点挖掘成区块链的有效区块的事务(并且因此不可改变地记录在区块链中；在实践中，为了使区块有效，这意味着事务的有效性已由足够数量的挖矿节点确认，以针对区块的有效性达成共识)。根据定义，提交事务必须相对于区块链网络的区块链协议有效。

相比之下，“已发布”事务指已提交到区块链网络的节点进行核实(由区块链网络的该节点和/或其它节点核实)，但尚未挖掘成区块的事务，该事务可能有效或无效。已发布事务不一定会被挖掘(即在适当的时候可能会被挖掘或可能不会被挖掘，具体视情况而定)。例如，已发布事务可保存在事务的挖矿池中，这些事务是被挖掘的潜在候选事务(可能对区块链的其他用户可见)，但尚未不可改变地记录在区块链中，并且可能永远不会不可改变地记录在区块链中，因为该事务可能有效，也可能无效。

短语“在所述方的计算机设备上接收所述一系列花费事务中的先前事务”不仅包括从其他方中的一方的计算机设备等远程来源接收，而且包括从本地接收，例如从同一方的计算机设备的本地存储器进行本地接收。例如，先前事务可能已由另一方创建(或至少最终确定)并从该方接收，或可能已由同一方创建(或至少最终确定)并存储在本地，以使同一方能够创建(但不一定最终确定)当前事务，或至少计算其输入值和/或其数字资产分配等任何其它相关组件。

在当前上下文中，当事务的输入满足解锁出资事务输出的条件时，该事务被称为“已完成”事务。需要注意的是，即使事务的结构和内容满足区块链的区块链协议规定的所有有效性要求，该一系列花费事务中的事务在完成时也不一定有效。这是因为事务只有在其锁定时间到期后才能生效，而且仅在未发布具有较高序列号且锁定时间到期的其它已完成花费事务时才有效(即挖矿节点一致认为有效)。也就是说，如果在相应的锁定时间到期后发布多个已完成花费事务，则这些花费事务中只有一个事务被挖矿节点一致认为有效，该个花费事务即具有最高序列号的花费事务。

由于出资事务的输出被锁定到各方的至少两个公钥，因此完成事务需要至少两个事务签名。对于该公钥中的不同公钥而言，每个事务签名均有效。例如，事务完成的时间点可以是各方中的第二方签署事务的时间点，在第二方中的第一方签署事务的较早时间点之后。

需要注意的是，术语“至少一个锁定到至少两个公钥的可花费的输出”不一定意味着解锁(花费)该输出的唯一要求是提供两个分别对这些密钥有效的事务签名。也就是说，可能存在或者也可能不存在附加的解锁要求(诸如提供指定哈希难题的解决方案的要求等)。例如，完整的锁定脚本可能类似于：

[Hash puzzle H(X)][Multisig 2-of-2]，

这意味着资源未由密钥完全锁定(解锁)，并且可能存在解锁资源的最低附加要求，即提供对H(X)进行哈希处理的原像。

在该特定上下文中，动词“加密签名”指使用与该方的公钥对应的私钥来将签名生成函数至少应用于花费事务的输出，从而生成事务签名以包含在当前事务的输入中的过程。签署事务的该方不一定会将事务签名添加至事务的输入，例如可将其发送至另一方(或其它外部实体)以添加至输入。签署事务的该方不一定需要拥有整个事务，而仅需拥有已签名部分。

花费事务可以由一方(或实际上由不属于支付通道的外部实体)创建，但由另一方(可选地，在此期间加入到事务中的一个或更多个附加方)完成。或者，在当前上下文中，花费事务可以由同一方创建和完成，但是在这种情况下，至少另一方需要提供有效的事务签名，并且通常至少需要事务的输出来实现这一点。应用函数计算当前事务的输入值和数字资产分配的一方可能会或可能不会创建事务的其余部分。对于后者，例如函数应用方只需计算输入值、数字资产分配和该方的事务签名，并发送给另一实体(例如，另一方)以创建事务的其余部分即可。

“先前事务”和“当前事务”是相对的术语，因此可以指该系列中任何两个时间上相邻的事务(包括先前事务是初始事务的情况以及当前事务是该系列中最终事务的情况)。

短语“锁定至所述各方的至少两个公钥的输出”不仅涵盖输出中指定的每个单一公钥都需要签名的情况，而且涵盖指定m个公钥但将输出锁定到这些公钥中的任何n<m个公钥的输出(即n方中的任何子集可签署事务以解锁出资事务的输出)。根据本领域使用的术语，这可以称为出资事务的输出中的“n/m检查多重签名”(多重签名)条件。

本公开使用“n/m检查多重签名”等类似术语作为任何锁定脚本的简写形式，仅指定m个公钥的子集n需要事务签名。有多种方式可以用区块链脚本对该要求进行编码，但术语不一定意味着任何特定的脚本级实施方式。例如，术语包括以下替代方案(包括更复杂的脚本)：

1.“裸多重签名”，其使用操作码OP_CHECKMULTISGI(VERIFY)，

2.P2SH(支付到脚本哈希)多重签名，其中编写特殊的脚本以满足该要求。

通常情况下，每个花费事务的至少两个可花费的输出可构建用于在至少两方之间分配数字资产数额，但不排除构建在其他方之间分配数字资产数额的花费事务的可能性(例如，支付通道各方可代表其他区块链各方协商或以其它方式同意数字资产的分配)。这些可花费的输出中的每一个均锁定到其中拟分配数字资产的不同方的公钥。当同意经由支付通道进行分配的各方是相同方时，该公钥可能是或者也可能不是出资事务的可花费的输出中指定的相同公钥。

对于每个花费事务而言，数字资产数额的分配根据花费事务输出的相应数字资产值进行定义(取决于函数的应用)。因此，函数以及先前事务的一个或更多个输入值定义了数字资产在各方之间的分配。当然，该分配只有当事务提交到区块链时才会具体化，而反过来，这只能发生在(a)事务的锁定时间到期后以及(b)未发布具有较高序列号的其它花费事务时。

在一些上下文中，优选地，可以将一个或更多个函数变量包含在事务的输出中，从而对函数变量进行签名。例如，这些变量可以包含在事务的一个或更多个可花费的输出中或一个或更多个单独的不可花费的输出中。

1.示例性系统概述

图1示出了一种用于实现区块链150的示例性系统100。系统100包括分组交换网络101，通常是诸如互联网的广域互联网。分组交换网络101包括多个节点104，该多个节点被设置成在分组交换网络101内形成点对点(P2P)覆盖网络106。每个节点104包括对等体的计算机设备，不同的节点104属于不同的对等体。每个节点104包括含一个或更多个处理器的处理装置，例如一个或更多个中央处理单元(CPU)、加速器处理器、特定应用程序处理器和/或现场可编程门阵列(FPGA)。每个节点还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。存储器可包括一个或更多个存储器单元，其采用一个或更多个存储器介质，例如诸如硬盘等的磁介质、诸如固态硬盘(SSD)、闪存或电可擦可编程只读存储器(EEPROM)等的电子媒介和/或诸如光盘驱动器等的光学介质。

区块链150包括一系列数据区块151，其中在P2P网络160中的多个节点中的每个节点处维护相应的区块链150副本。区块链中的每个区块151均包括一个或更多个事务152，其中该上下文中的事务是指一种数据结构。数据结构的性质将取决于用作事务模型或计划的一部分的事务协议类型。给定的区块链通常全程使用一个特定的事务协议。在一种常见的事务协议中，每个事务152的数据结构至少包括一个输入和至少一个输出。每个输出指定一个数额，该数额表示属于输出被加密锁定的用户103的数字资产值(需要该用户的签名进行解锁，从而进行赎回或花费)。每个输入指向先前事务152的输出，从而链接这些事务。

节点104中的至少一些节点扮演转发节点104F的角色，这些节点转发并因此传播事务152。节点104中的至少一些节点扮演挖掘区块151的矿工104M的角色。节点104中的至少一些节点扮演存储节点104S(有时也称为“完整副本”节点)的角色，每个存储节点均在相应的存储器中存储相同区块链150的相应副本。每个矿工节点104M还维护等待挖掘到区块151中的事务152的池154。给定节点104可以是转发节点104、矿工104M、存储节点104S或其中两个节点或所有节点的任意组合。

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

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

上述可称为“基于输出的”事务协议，有时也称为未花费的事务输出(UTXO)的协议(其中输出称为UTXO)。用户的总余额不是用区块链中存储的任何一个数字定义的；相反，用户需要特殊“钱包”应用程序105，以整理该用户的所有UTXO值，这些UTXO值分散在区块链151的许多不同事务152中。

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

无论采用何种类型的事务协议，当用户103希望执行新事务152j时，其希望将新事务从其计算机终端102发送至P2P网络106的节点104中的一个(现在通常是服务器或数据中心，但原则上可以是其他用户终端)。此节点104根据在节点104中的每个节点处应用的节点协议检查事务是否有效。节点协议的详细信息将与相关区块链150中使用的事务协议类型相对应，一起形成整个事务模型。节点协议通常要求节点104检查新事务152j中的加密签名是否与预期签名相匹配，这取决于事务152的有序序列中的先前事务152i。在基于输出的情况下，这可包括检查新事务152j的输入中包含的用户加密签名是否与新事务花费的先前事务152i的输出中定义的条件相匹配，其中该条件通常包括至少检查新事务152j的输入中的加密签名是否解锁新事务的输入所指向的先前事务152i的输出。在一些事务协议中，条件可至少部分地由输入和/或输出中包含的自定义脚本定义。或者，这可仅由节点协议单独确定，或可通过其组合确定。无论采用哪种方式，如果新事务152j有效，当前节点会将其转发到P2P网络106中的一个或更多个其他节点104。这些节点104中的至少一些节点还作为转发节点104F，根据相同的节点协议应用相同的测试，从而将新事务152j转发到一个或更多个进一步的节点104，依此类推。通过这种方式，新事务在节点104的整个网络中进行传播。

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

除核实之外，节点104M中的至少一些节点在称为挖矿的过程中争先创建事务区块，该过程以“工作量证明”为基础。在挖矿节点104M处，将新事务添加到区块中尚未出现的有效事务的池中。然后，矿工争相通过尝试解决加密难题来组装事务池154中事务152的新的有效区块151。通常情况下，这包括搜索“随机数”值，从而当随机数与事务池154并置且进行哈希处理时，哈希值的输出满足预定条件。例如，预定条件可以是哈希值的输出具有某个预定义的前导零数。哈希函数的特性是，相对于其输入，其具有不可预测的输出。因此，该搜索只能通过强力执行，从而在试图解决难题的每个节点104M处消耗大量的处理资源。

解决难题的第一矿工节点104M在网络106上宣布难题解决，提供解决方案作为证明，然后网络中的其他节点104则可以轻松检查该解决方案(一旦给出哈希值的解决方案，就可以直接检查该解决方案是否使哈希值的输出满足条件)。基于已在每个此类节点处检查获胜者的已宣布解决方案，获胜者已为其解决该难题的事务池154之后由充当存储节点104S的节点104中的至少一些节点记录在区块链150中作为新区块151。区块指针155还分配给指向区块链中先前创建的区块151n-1的新区块151n。工作量证明有助于降低重复花费的风险，因为创建新区块151需要大量工作，并且由于包含重复花费的任何区块都可能被其他节点104拒绝，因此挖矿节点104M受到激励，不允许在其区块中包含双重花费。一旦创建，则不可修改区块151，因为其根据相同的协议在P2P网络106中的存储节点104S中的每个存储节点进行识别和维护。区块指针155还向区块151施加顺序。由于事务152记录在P2P网络106中每个存储节点104S处的有序区块中，因此提供了事务的不可变公共分类账。

应当注意的是，在任何给定时间争相解决难题的不同矿工104M可能会根据任何给定时间的未挖掘事务池154的不同快照执行该操作，具体取决于他们何时开始搜索解决方案。解决相应难题的人员首先定义新区块151n中包含的事务152，并更新当前未挖掘事务池154。然后，矿工104M继续争相从新定义的未完成池154中创建区块，依此类推。此外，还存在解决可能出现的任何“分叉”的协议，其中两名矿工104M彼此在很短的时间内解决难题，从而传播区块链的冲突视图。简言之，分叉方向最长的成为最终区块链150。

在大部分区块链中，获胜矿工104M会自动获得特殊类型的新事务作为奖励，该新事务创建新的数字资产值(与将数字资产数额从一个用户转移至另一个用户的正常事务截然相反)。因此，获胜节点被视为已“挖掘”一定数量的数字资产。这种特殊类型的事务有时称为“生成”事务，其自动形成新区块151n的一部分。该奖励可激励矿工104M争相参与工作量证明。通常情况下，常规(非生成)事务152还将在其输出中的一个输出中指定附加事务费用，以进一步奖励创建其中包含事务的区块151n的获胜矿工104M。

由于挖掘中涉及的计算资源，通常至少矿工节点104M中的每个矿工节点采用服务器的形式，该服务器包括一个或更多个物理服务器单元，甚至整个数据中心。每个转发节点104M和/或存储节点104S还可采取服务器或数据中心的形式。但是，原则上来说，任何给定节点104均可采用一个用户终端或联网在一起的一组用户终端的形式。

每个节点104的存储器均存储被配置为在节点104的处理装置上运行的软件，以根据节点协议执行其相应的角色并处理事务152。应当理解的是，在本文中归因于节点104的任何动作均可通过在相应计算机设备的处理装置上运行的软件执行。节点软件可以在应用层的一个或更多个应用中实现，或者在诸如操作系统层或协议层的较低层中实现，或者在这些层的任何组合中实现。此外，在本文中使用的“区块链”一词是指一般技术类型的通用术语，不限于任何特定专有区块链、协议或服务。

扮演消费用户角色的多方103中的每一方的计算机设备102也连接到网络101。他们充当事务中的支付人和收受人，但不一定代表其他方参与挖掘或传播事务。他们不一定运行挖矿协议。出于说明目的，示出了双方103及其相应的设备102：第一方103a及其相应的计算机设备102a，以及第二方103b及其相应的计算机设备102b。应当理解的是，更多此类当事方103及其相应的计算机设备102可能存在并参与系统，但为了方便起见，未进行说明。每一方103均可以是个人或组织。仅出于说明目的，在本文中，第一方103a称为爱丽丝(Alice)，第二方103b称为鲍勃(Bob)，但应当理解的是，这并不仅限于爱丽丝或鲍勃，且本文对爱丽丝或鲍勃的任何引用均可分别用“第一方”和“第二方”替换。

每一方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创建、签名和发送拟在节点104的整个网络中传播的事务152，并因此包含在区块链150中。另一个功能是向相应方汇报其目前拥有的数字资产数额。在基于输出的系统中，该第二功能包括整理分散在区块链150中属于相关方的各种事务152的输出中定义的数额。

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

每个计算机设备102上的客户端应用程序或软件105的实例可操作地耦合到P2P网络106的转发节点104F中的至少一个转发节点。这可以启用客户端105的钱包功能，以将事务152发送至网络106。客户端105还可联系一个、一些或所有存储节点104，以在区块链150中查询相应方103作为接收者的任何事务(或实际上在区块链150中检查其他方的事务，因为在实施例中，区块链150是在某种程度上通过其公开可见性提供事务信任的公共设施)。每个计算机设备102上的钱包功能被配置为根据事务协议制定和发送事务152。每个节点104运行软件，其被配置为根据节点协议核实事务152有效的软件，并且在转发节点104F的情况下转发事务152，以在整个网络106中传播此类事务。事务协议和节点协议相互对应，给定事务协议和给定节点协议一起实现给定的事务模型。区块链150中的所有事务152均采用相同的事务协议(尽管事务协议可允许其内存在不同的事务子类型)。网络106中的所有节点104采用相同的节点协议(尽管其可根据针对该子类型定义的规则区分处理不同的事务子类型，并且不同的节点还可扮演不同的角色，从而实现协议的不同对应方面)。

如上所述，区块链150包括一系列区块151，其中每个区块151包括通过如前所述的工作量证明过程创建的一个或更多个事务152的集合。每个区块151还包括区块指针155，其指向区块链中先前创建的区块151，以定义区块151的顺序。区块链150还包括有效事务池154，其等待通过工作量证明过程包含在新的区块中。每个事务152(除了一生成事务)包括指向先前事务的指针，以定义事务序列的顺序(注：事务152的序列可进行分支)。区块151的区块链一直追溯到创始区块(Gb)153，该创始区块是区块链中的第一区块。区块链150中早期的一个或更多个原始事务152指向创始区块153，而非先前事务。

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

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

一旦进入在一个或更多个存储节点104处维护的区块链150的副本中的池154中，矿工节点104M将开始竞相解决包括新事务152的池154的最新版本方面的工作量证明难题(其他矿工104M可继续尝试基于池154的旧视角解决难题，但首先解决难题的矿工将定义下一个新区块151的结束位置和新池154的开始位置，最终将有人解决包括爱丽丝的事务152j的池154的一部分的难题)。一旦包括新事务152j的池154完成工作量证明，其将不可变地成为区块链150中区块151中的一个区块的一部分。每个事务152包括指向早前事务的指针，因此事务的顺序也被不可变地记录下来。

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

基于UTXO的模型

图2示出了示例性事务协议。这是基于UTXO的协议的示例。事务152(简称“Tx”)是区块链150的基本数据结构(每个区块151包括一个或更多个事务152)。下面将通过参考基于输出或基于“UTXO”的协议进行描述。但这并不限于所有可能的实施例。

在基于UTXO的模型中，每个事务(“Tx”)152包括数据结构，其包括一个或更多个输入202和一个或更多个输出203。每个输出203可包括未花费的事务输出(UTXO)，其可用作另一新事务的输入202的来源(如果UTXO尚未赎回)。UTXO指定数字资产数额(价值储存手段)。它还可包含其来源事务的事务ID以及其他信息。事务数据结构还可包括头部201，其可包括输入字段202和输出字段203的大小指示符。头部201还可包括事务的ID。在实施例中，事务ID是事务数据(不含事务ID本身)的哈希值，且存储在提交至矿工104M的原始事务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中的一个区块中，或者可能仍在池154中等待，在这种情况下，该事务将很快包括在新区块151中。或者，Tx₀和Tx₁可以创建并一起发送至网络102；或者，如果节点协议允许缓冲“孤立”事务，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 P_A><P_A>||[Checksig P_A]

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

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

如果Tx₁中的解锁脚本满足Tx₀的锁定脚本中指定的一个或更多个条件(因此，在所示示例中，如果在Tx₁中提供了爱丽丝的签名并进行认证)，则节点104认为Tx₁有效。如果是挖矿节点104M，这意味着其将添加至等待工作量证明的事务154池。如果是转发节点104F，则其将事务Tx₁转发到网络106中的一个或更多个其他节点104，从而将在整个网络中传播。一旦Tx₁有效并包括在区块链150中，这将把Tx₀中的UTXO₀定义为已花费。请注意，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₁的第二输出中给自己退还物，或者支付给另一方。

在实践中，爱丽丝通常还将需要包括获胜矿工的费用，因为现在仅靠区块创始事务的奖励币通常不足以激励挖掘。如果爱丽丝未包括矿工的费用，Tx₀可能会被矿工节点104M拒绝，因此，尽管技术上有效，但仍然不会传播并包括在区块链150中(如果矿工104M不愿意，矿工协议不会强制他们接受事务152)。在一些协议中，挖掘费不需要其自身的单独输出203(即不需要单独的UTXO)。相反，给定事务152中输入202所指向的总数额与输出203所指定的总数额之间的任何差额都将自动提供给获胜矿工104。例如，假设指向UTXO₀的指针是Tx₁的唯一输入，而Tx₁只有一个输出UTXO₁。如果UTXO₀中指定的数字资产的数额大于UTXO₁中指定的数额，则该差额将自动提供给获胜矿工104M。替代地或附加地，这不一定排除可以在其自身事务152的其中一个UTXO 203中明确指定矿工费用。

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

请注意，脚本代码通常用示意图表示(即非精确语言)。例如，可写入[ChecksigP_A]表示[Checksig P_A]＝OP_DUP OP_HASH160<H(P_A)>OP_EQUALVERIFY OP_CHECKSIG。“OP_...”是指脚本语言的特定操作码。OP_CHECKSIG(又称“Checksig”)是脚本操作码，其取两个输入(签名和公钥)，并使用椭圆曲线数字签名算法(ECDSA)验证签名的有效性。在运行时，移除脚本中任何出现的签名(‘sig’)，但在由‘sig’输入验证的事务中仍保留附加要求，诸如哈希难题。再如，OP_RETURN是脚本语言操作码，用于创建事务的不可花费输出，其可以将元数据储存在事务中，从而将元数据不可变地记录在区块链150中。例如，元数据可包括需存储在区块链中的文件。

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

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

序列号与锁定时间

图2A示出了第二事务152-j-1的示意图，该第二事务在特定形式的支付通道的上下文中具有特定用途。

第二事务152-j-1被示出为包括至少一个输入202-j-1。除了包含指向第一事务151-i的输出203-i的指针和用于解锁该输出203-i的解锁脚本502-j-1(即满足该输出203-i的锁定脚本503-i中指定的(所有)条件)之外，输入202-j-1还包含序列号nS。第一事务151-i的输出203-i包含表示为v(数字资产值)的值，其定义由输出203-i传递的数字资产数额。本说明书的其它位置也使用了相同的符号。

第二事务152-j-1还具有定义的锁定时间T_L，第二事务152-j-1在其锁定时间T_L到期前不得被视为有效。假设满足所有其它有效性要求，一旦锁定时间T_L到期，则第二事务152-j-1只有在区块链网络101未收到任何其它有效且具有较高序列号的“冲突”事务时才被视为有效。如果两个事务都具有花费相同输出的至少一个输入，则这两个事务被称为“冲突”事务(更准确地说，如果这两个事务都具有至少一个包含指向相同输出的指针的输入，并且具有满足该输出的锁定脚本中定义的一个或更多个条件的锁定脚本。但如果存在具有较高序列号的事务，具有较低序列号的事务将被视为有效)。

例如，图2A示出了第三事务151j-2，该第三事务包括至少一个输入202-j-2，该输入包含指向第一事务151-i的相同输出503-i的指针和解锁脚本502-j-2，该解锁脚本还满足该输出203-i的锁定脚本503-i中指定的所有条件。第三事务151-j-2具有锁定时间T′_L(可能与第二事务152-j-1的锁定时间T_L相同或者也可能不同)，第三事务151-j-2的输入202-j-2具有序列号nS′。如果第二事务151-j-1和第三事务151-j-2都在其相应的锁定时间T_L、T′_L到期后提交到区块链网络101，则仅具有最高序列号的事务被视为有效(当然，除非已提交具有较高序列号的另一冲突事务)。

在本示例中，第二事务152-j-1和第三事务152-j-2被示出为都具有至少两个输出，所述输出在第二事务152-j-1时分别具有数字资产值v₁和v₂，在第三事务152-j-2时分别具有数字资产值v′₁和v′₂。尽管图2A中未示出，但这些输出中的每一个通常都有其自身的解锁脚本，必须满足该解锁脚本才能释放相应数额的数字资产。例如，第二事务151-j-1和第三事务151-j-2中每一个的两个输出可具有在两个不同方之间分配由第一事务152-i(如v所定义)的输出203-i传递的数字资产数额的效果，其中：

-如果第二事务151-j-1有效，则第一方接收由v₁定义的数字资产数额，第二方接收由v₂定义的数字资产数额；然而

-如果第三事务151-j-2有效，则第一方接收由v′₁定义的数字资产数额，第二方接收由v′₂定义的数字资产数额。

例如，第一事务151-i可以是具有特定属性的特殊“出资事务”，稍后将具体地参考图6A和图6B进行描述。然后，通过创建具有未来的锁定时间和递增的序列号的连续花费事务，支付通道可以用作两方或更多方之间就出资事务传递的数字资产分配进行协商的基础，该数额以不同的方式进行分配(由花费事务的输出的数字资产值定义)。

侧信道

图3示出了用于实现区块链150的另一系统100。除了附加的通信功能外，该系统100与图1所示的内容基本相同。爱丽丝和鲍勃的每台计算机设备102a,120b上的客户端应用程序分别包括附加通信功能。也就是说，这可使爱丽丝103a建立与鲍勃103b分离的侧信道301(在任何一方或第三方的鼓动下)。侧信道301能够独立于P2P网络实现数据交换。此等通信有时候被称为“链下”通信。比如，当交换爱丽丝与鲍勃之间的事务152时不想将该事务(仍未)发布到P2P网络106或挖掘到区块150，可以采用此等通信，直到其中一方选择将该事务广播到网络106。替代地或附加地，该侧信道301可以用于交换任何其他的事务相关数据，例如密钥、协商的数额或条款、数据内容、等等。

通过与P2P覆盖网络106相同的分组交换网络101可建立侧信道301。此外/或者，通过诸如移动蜂窝网络等不同网络、或者诸如本地无线网络等局域网、或者甚至爱丽丝和鲍勃的设备102a,102b之间的直接有线或无线连接可以建立侧信道301。一般而言，本文所指的侧信道301可包括经由一种或更多种联网技术或者通信介质的任何一个或更多个链路，用于“链下”(即独立于P2P覆盖网络106)交换数据。在多个链路被使用的情况下，整个链下链路的捆绑或集合才可以被称为侧信道301。因此，需要注意的是，虽然爱丽丝和鲍勃通过侧信道301对特定的信息或数据片段或者诸如此类进行交换，但这并不一定意味着所有这些数据片段必须通过相同的链路或甚至同一类型网络进行发送。

图3A示出了图3所示的系统的变体，具有至少三方，其中一方是“可信的预言机”102o。在该示例中，可信的预言机采用一组运行客户端软件105o(类型如上所述，下面将参考图4进行进一步详细讨论)的预言机计算机设备102o的形式，该客户端软件自主运行以执行下述功能(无任何实质性的人为监督)。或者，可信的预言机可以是操作类似计算机设备102o的人类用户，在这种情况下，这些功能在预言机计算机设备102o处以至少人为监督和/或控制的元素来执行。每对当事方之间提供了相应的侧信道，用附图标记301(在爱丽丝103a与鲍勃103b之间)、302(在爱丽丝103a与预言机102o之间)和303(在鲍勃103b与预言机102o之间)表示。

图3B示出了进一步的变体，同样具有至少三方，但是在这种情况下至少两方是可信的预言机102o-1、102o-2。在该特定示例中，第二可信的预言机102o-2实际上承担鲍勃的角色，关于鲍勃103a及其计算机设备102b的所有上述描述同样适用于第二预言机102o-1。

下面参考特定示例对可信的预言机在区块链支付通道上下文中的角色进行详细描述。

客户端软件

图4A示出了用于实现本公开方案的实施例的客户端应用程序105的示例性实施方式。客户端应用程序105包括事务引擎401和用户界面(UI)层402。根据上文讨论的方案以及稍后将进一步详细讨论的内容，事务引擎401被配置为实现客户端105的基础事务相关功能，诸如制定事务152，通过侧信道301接收和/或发送事务和/或其他数据，和/或发送事务以通过P2P网络106传播。根据本文公开的实施例，支付通道的至少一方(可能是或可能不是可信的预言机)的客户端105的事务引擎401包括用于生成和签署支付通道事务的支付通道逻辑403，该事务可根据需要发送给另一方或更多方完成，或由同一方根据需要使用从另一方或更多方接收的信息完成。稍后将对此进行详细描述。

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

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

UI层402的存在假定计算机设备102将由用户操作。实际上，支付通道的某些当事方可以是自主机器实体，即在无任何(或最少)人为监督的情况下运行以生成和签署事务的计算机设备。具体地，支付通道逻辑203可以在有人为监督或者没有人为监督的情况下运行。这既适用于作为可信的预言机的当事方，也适用于不作为可信的预言机的支付通道的任何方。对于前者，尽管在上述示例中爱丽丝103a和鲍勃103b通过示例的方式呈现为人类用户，但他们中一者或两者的角色可以由一个或更多个自主机器承担(也就是说，爱丽丝或鲍勃一方或双方的计算机设备105a、105b都可以自主运行或基本自主运行)。

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

通过图示的方式，图4C从爱丽丝的角度示出了UI 470。UI 470可包括一个或更多个UI元素471、472、472，该一个或更多个UI元素通过用户输出方式呈现为不同的UI元素。

例如，UI元素可包括一个或更多个用户可选择的元素471，这些元素可以是屏幕上的不同按钮、菜单中的不同选项或者诸如此类。用户输入方式被设置成使用户103(在这种情况下为爱丽丝103a)能够选择或以其它方式操作其中一个选项，诸如通过点击或触摸屏幕上的UI元素，或者说出所需选项的名称(注：本文使用的“手动”一词仅用于与自动进行对比，而不一定限于用手执行操作)。例如，这些选项使用户(爱丽丝)能够显示并在适当情况下签署现有(但可能不完整)支付通道事务，或在某些情况下创建新的支付通道事务。此外/或者，UI元素可包括一个或更多个数据输入字段472，用户通过该字段执行此类操作。这些数据输入字段通过用户输出方式呈现，例如屏幕上，并且数据可通过用户输入方式输入到字段中，例如键盘或触摸屏。或者，数据可以例如基于语音识别口头地接收。

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

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

节点软件

图4B示出了在基于UTXO或基于输出的模型的示例中，在P2P网络106的每个节点104上运行的节点软件450的示例。节点软件450包括协议引擎451、脚本引擎452、堆栈453、应用级决策引擎454以及一个或更多个区块链相关功能模块的集合455。在任何给定节点104处，这些模块可以包括以下三个模块中的任何一个、两个或全部：挖掘模块455M、转发模块455F和存储模块455S(取决于该节点的一个或更多个角色)。协议引擎401被配置为识别事务152的不同字段，并根据节点协议处理此类字段。当接收到具有指向另一先前事务152i(Tx_m-1)的输出(例如，UTXO)的输入的事务152j(Tx_j)时，协议引擎451标识Tx_j中的解锁脚本并将其传递给脚本引擎452。协议引擎451还基于Tx_j的输入中的指针来标识和检索Tx_i。如果Tx_i尚未在区块链150上，则可以从相应节点自身的未决事务池154中检索Tx_i；或者，如果Tx_i已在区块链150上，则可以从存储在相应节点或另一节点104处的区块链150中的区块151的副本中检索。无论采用哪种方式，脚本引擎451都会标识Tx_i的指向输出中的锁定脚本，并将其传递给脚本引擎452。

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

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

在基于输出的模型中，来自脚本引擎452的结果“TRUE”是事务有效性的条件之一。通常，还必须满足由协议引擎451评估的一个或更多个进一步协议级条件；例如，Tx_j的输出中所指向的数字资产的总数额不超过其输入指定的总数额，并且Tx_i的指向输出尚未被另一有效事务花费。协议引擎451评估来自脚本引擎452的结果以及一个或更多个协议级条件，并且只有当它们都为TRUE时，协议引擎451才核实事务Tx_j有效。协议引擎451将事务是否有效的指示输出到应用级决策引擎454。只有在Tx_j确实核实有效的条件下，决策引擎454才可以选择控制挖掘模块455M和转发模块455F中的一个或两个来执行它们涉及Tx_j的相应区块链相关函数。这可以包括：挖掘模块455M，该挖掘模块将Tx_j添加到节点的相应池154以挖掘到区块151中；和/或转发模块455F，该转发模块将Tx_j转发到P2P网络106中的另一节点104。然而，应当注意的是，在实施例中，虽然决策引擎454不会选择转发或挖掘无效事务，相反，这并不一定意味着，仅因为事务有效，该决策引擎就必须触发该事务的挖掘或转发。可选地，在实施例中，应用级决策引擎454可以在触发这些函数中的一个或两个函数之前应用一个或更多个附加条件。例如，如果节点是挖掘节点104M，则决策引擎可以仅在事务有效且预留足够挖掘费用的条件下选择挖掘该事务。

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

2.区块链支付通道

支付通道允许用户和/或自主实体(机器)通过事务进行点对点通信。支付通道不仅充当通信信道，而且可以作为协商和结算过程。在设计支付通道时，需要重点关注安全与效率之间的平衡。

下面描述了许多通用支付通道设计，以提供与本公开技术所描述的实施例相关的情况。

简言之，所描述的实施例利用本文中所称的“出资型Nakamoto支付通道”，以保证安全性，从而确保所有参与方不会被其他人欺骗。

可以向支付通道应用附加的“应用层”规则(用于确定事务有效性的区块链协议的任何“原生”规则除外)。此类应用层规则可使用本文传授的一种或更多种支付通道方法来实施。

2.1准备事项

2.1.1区块链脚本

简要回顾上文更详细的描述，区块链150包含事务152的区块151，其中每个事务152可以使用基于堆栈的脚本语言(本文通常称为脚本(大写S))对数字资产从一个地址转移到另一地址进行编码。

事务包含用该语言编写的脚本(脚本代码)，可以出现在它们输入202和输出203的一个或两个中。输出脚本通常具有通过设置花费条件来锁定数字资产数额的函数，而输入脚本具有通过满足此类花费条件来解锁此类数字资产数额的函数。因此，本文中分别将输入脚本和输出脚本称为解锁脚本和锁定脚本。

需要注意的是，有时可能会使用“scriptSig”和“scriptPubKey”分别代替“解锁脚本”和“锁定脚本”。此类术语假定数字资产数额被锁定到至少一个公钥，从而需要至少一个事务签名才能解锁。在实践中通常如此，但并不是基于输出的协议的要求——可以定义任何锁定脚本，可能需要或者可能不需要有效的事务签名进行解锁。因此，应当理解的是，与“scriptSig”和“scriptPubKey”相关的所有描述同样适用于任何形式的锁定/解锁脚本，但上下文另有要求时除外。

脚本执行

为了核实事务，由区块链网络101的至少一些节点104进行脚本执行。这确保事务152输入用于花费数字资产数额的解锁脚本满足由传递该数字资产数额的先前事务(源事务)的锁定脚本所定义的花费条件。图2中示出了这一点，并且上文中也详细描述了这一点。

具有单一输出203的事务152所传递的数字资产数额由单一输出的数字资产值定义。具有多个输出203的事务152所传递的数字资产数额由这些多个输出的数字资产值定义。

需要注意的是，本文中“数字资产单位”一词指比特币的数额v，由带标识符TxID的给定事务Tx的输出中的锁定脚本锁定。

脚本执行过程负责确保解锁脚本满足锁定脚本，以如图2所示创建成功的花费关系。该过程可总结如下：

1.使用新堆栈453执行解锁脚本。

2.在(1)中保持堆栈453在执行结束时的状态。

3.使用(2)中的堆栈453执行锁定脚本。

4.如果(3)之后的栈顶项非零且非空，则花费有效。

上述过程准确地描述了如何通过核实事务152的节点104在实际上实现脚本执行。但是，可以通过如下解释脚本执行，来从概念上理解该过程：

1.将解锁脚本和锁定脚本放在一起，具体如下：

[解锁脚本]OP_CODESEPARATOR[锁定脚本]

1.使用公共堆栈从左到右执行(1)中生成的脚本。

2.如果(2)之后的栈顶项非零且非空，则花费有效。

图5示出了对脚本执行过程的这种概念性解释的简要概述，其中第一事务152-i的输出中的解锁脚本和第二事务152-j的输入中锁定脚本分别用附图标记503-i和附图标记502-j表示。以上步骤1到3用方括号加相应编号表示。如所示出的，第二事务152-j的输入具有指向第一事务152-i的输出的指针(采用指向第二事务152-j的点以及第一事务152-i的输出的索引的形式，参见上文图2)。

2.2支付通道

“支付通道”一词通常指以点对点的方式在多方之间建立的通信信道(侧信道，诸如上述侧信道301、302和303中的一个)，由此消息以事务152的形式经由通信信道进行交换。在支付通道中，可能并非所有这些事务都提交到区块链152，并且甚至可能不会发布(在上述定义的情况下)。事实上，在实践中，实际上可能只发布少量事务消息，以表示此类信道的结算(以及可选的鼓动)(但并不一定是最终结算的所有中间协商步骤)。

许多场景可能涉及不需要全部发布的许多潜在高频事务，包括小额支付等点对点交互。

支付通道的一般概念有许多变体。本说明书仅侧重两种支付通道架构，具体如下：

Nakamoto支付通道——基于nSequence和nLocktime。

出资型Nakamoto(FN)支付通道——有资源支持的Nakamoto架构。

尽管存在差异，但是所有这些支付通道架构均可描述为三阶段过程，奠定支付通道概念的基础。这些阶段包括：

1.建立阶段——初始化支付通道；

2.协商阶段——创建链下中间状态；

3.结算阶段——关闭支付通道。

本说明书首先考虑双方(诸如爱丽丝和鲍勃)希望进行多次事务，但只在链上发布交互的初始状态和/或最终状态的情况。

方向性

在详细描述不同的示例性支付通道架构之前，定义与支付通道方向性相关的某些术语：

双向型——资源的初始状态包括双方出资的支付通道称为双向型支付通道。这意味着总体而言，支付通道可诱导对任何一方进行净支付。

单向型——在双方之间进行且资源的初始状态仅包括一方(支付人)出资的支付通道称为单向型支付通道。这意味着总体而言，支付通道可诱导对第二方(收受人)(即不向通道的初始状态出资的一方)进行净支付。

需要注意净支付与状态转换的区别。在双向型支付通道和单向型支付通道中，中间状态转换可以将资源重新分配给任何一方(即以任意方向)。但是，支付通道中任何可能的净变化的方向均由向初始状态的出资方定义。

2.1.1 Nakamoto支付通道

下述文件描述了Nakamoto支付通道架构，其全部内容以引入方式并入本文：S.Nakamoto和M.Hearn，[Bitcoin-development]出于tx替代目的防御DoS(Anti DoS fortx replacement)，Lists.linuxfoundation.org，2019。

此类支付通道以下述方式利用序列号和锁定时间(参见图2A)。

该架构基于以下事实：输入中具有“非最终”nSequence编号的事务可以在nLocktime生效之前进行多次更新。

为了简单起见，下面假设双方之间存在支付通道。但是，含两个以上参与方的支付通道是可行的，稍后将描述此类支付通道的多个示例。

此类双方之间的简单Nakamoto支付通道可以视为简单的三阶段过程，具体如下所示。

1.建立阶段：

·爱丽丝和鲍勃都出资并签署输入，以创建彼此间事务的初始版本。该初始版本表示支付通道的初始状态，并保持链下状态。该事务是时间锁定的，这意味着非零nLocktime值设置为未来的适当时间点T_L。

2.更新阶段：

·爱丽丝和鲍勃通过签署在其输入上具有较高序列号的初始事务(事务替代)的新版本来更新支付通道的状态，其中更新了事务详情，以反映所需的新支付状态。

·该过程是重复的，在达到nLocktime之前根据需要多次创建新的中间状态。每当签署具有较高高序列号的新版本时，具有较低序列号的所有版本都将失效。

3.结算阶段：

·爱丽丝和鲍勃可通过以下任一种方式结算支付通道：

(i)在nLocktimeT_L到期之后，发布具有最高nSequence编号的事务版本；或

(ii)通过使用最大值序列号(nSequence＝0xFFFFFFFF)进行相互签名，在nLocktime之前最终确定事务。

需要注意的是，不需要发布任何初始事务，仅需发布最终状态并将其挖掘到区块链上。但是，可能存在安全漏洞，由此在结算前的任何时间任何一方的输入都可能被“双重花费”，因为在结算前没有发布事务。

Nakamoto支付通道可以通过双向或单向配置实现，只需更改初始状态的出资方即可。

图6示出了Nakamoto支付通道架构的示例性流程图。

流程图中示出了本说明书提供的双向配置的标准Nakamoto支付通道。符号‘nS’用作nSequence的简写形式，‘M’表示序列号nS可取的最大值，例如4字节值(0xFFFFFFFF)，‘I_n’表示状态n(I₀表示初始状态)，‘S’表示结算事务。白色圆圈表示未完成的事务，黑色圆圈表示已完成的事务，交叉线型圆圈表示已成功挖掘的事务。在这种情况下，“状态”一词指不一定被挖掘或发布的部分或已完成的花费事务。

附图标记600用于表示随着时间的推移，通过支付通道创建的一系列花费事务。支付通道通过一系列步骤实现，其中Sn表示创建状态I_n的步骤(S0表示建立初始状态I₀的初始步骤)。最终步骤SF创建结算事务S，该步骤SF可能发生或者也可能不发生，具体取决于各方在整个协商期间是否保持合作。

2.2.2出资型Nakamoto(FN)支付通道

“出资型”支付通道指在开始协商前向区块链150提交特殊出资事务的情况。Spilman支付通道是出资型支付通道的一个示例，其中不使用锁定时间的序列号。

Nakamoto通道和Spilman通道两者具有不同的特征和属性，并且存在不同的安全漏洞，具体取决于通道的情境要求。具体地，安全性缺陷总结如下：

Nakamoto支付通道——由于没有出资事务，因此任何一方都可能在结算之前的任意时间点恶意进行双重花费。

出资型(Spilman)支付通道——由于在更新阶段不使用nSequence和nLocktime，因此如果实施不当，其中一方可能会恶意广播早期状态。

本节介绍出资型Nakamoto(FN)支付通道的概念，以说明如何缓解这两个安全性缺陷。

“出资型Nakamoto支付通道”一词用于描述存在以下两种情况的任何支付通道：

·通过采用nLocktime和递增的nSequence，在更新阶段使用事务替代，类似于Nakamoto支付通道(2.2.1)；

·使用出资事务“托管”交互方的资源，并在链上记录支付通道的初始状态。

采用双向配置的FN支付通道的示例性三阶段过程如下所述：

1.建立阶段：

·爱丽丝和鲍勃合作创建出资事务，将资源一起托管到2/2多重签名地址。这定义了他们资源的初始状态，并且必须在链上发布。

·爱丽丝和鲍勃合作创建退还事务，其根据初始状态将托管资源返回给原始所有者。该事务是时间锁定的，这意味着非零nLocktime值设置为未来的适当时间点T_R。

2.更新阶段：

·通过提供各自签名，爱丽丝和鲍勃合作创建花费出资事务输出的事务。这是支付通道的第一中间状态，反映了初始支付方向。该中间状态的时间锁定到未来的适当时间T_L，使得T_L≤T_R。

·爱丽丝和鲍勃通过签署具有较高序列号的初始状态事务(事务替代)的新版本来更新支付通道的状态，其中更新了事务详情，以反映所需的新支付状态。每个新状态的nLocktime始终保持在值T_L的水平。

·该过程是重复的，在中间事务nLocktimeT_L到期之前根据需要多次创建新的中间状态。

3.结算阶段：

·爱丽丝和鲍勃可通过以下任一种方式结算支付通道：

(i)在nLocktimeT_L到期之后，发布具有最高nSequence编号的事务版本；或

(ii)通过使用最大值序列号(nSequence＝0xFFFFFFFF)进行相互签名，在nLocktimeT_L之前最终确定事务。

·在这两种情况下，都发布最终状态并将其挖掘到区块链150上。

符号T_R和符号T_L分别用于区分退还事务和中间事务版本的nLocktime限制。这些时间可能是不同的，因为中间状态协商必须停止的时间T_L可能不同于交互或协商失败时，双方希望相互退还的时间T_R。他们之间的关系应该是T_L≤T_R，以确保可以在任何一方能够退还前停止协商。如果在更新阶段期间可能出现一方退还，则会引发问题。

图6A和图6B分别示出了双向和单向配置的出资型Nakamoto支付通道的两个示例。

在这两种情况下，可以看到初始步骤S0中各方创建并签署特殊的出资事务F，并在继续之前提交到区块链150(如该节附图右侧交叉线型圆圈所示，表示步骤S0)。

通常，出资事务F具有输出，该输出至少需要来自不同方的两个有效事务签名，以进行解锁(可能存在或者也可能不存在附加要求)。在最简单的情况下，只需要爱丽丝和鲍勃的签名，但稍后将描述使用更复杂的多重签名锁定条件的扩展，诸如“m/n多重签名要求”(参见下文)。

如图6、图6A和图6B所示，如果一切按计划行事，最终解锁出资事务F的输出的事务将是结算事务S。但是，如果在完成任何结算事务S之前终止协商，则任何一方均可发布一系列花费事务600中具有最高序列号的已完成事务I_n，该事务将解锁出资事务F的输出。解锁出资事务F的输出的事务具有在各当事方(或一部分当事方)之间分配出资事务的输出值v的效果。

本说明书已参考图2A概述了如何随着时间的推移创建一系列花费事务，以在两方或更多方之间协商数字资产数额的分配。

在图6A的示例中，每一方都向花费事务提交数字资产数额，爱丽丝和鲍勃分别提交￡11和￡1(其中，“￡”表示根据相关区块链协议量化数字资产的任何单位；在其它位置，字母“BSV”可用于表示数字资产单位)。这些数额通过出资事务F中的两个已签名输入提交，其中一个输入有效地花费属于爱丽丝的￡11(需要爱丽丝的有效事务签名)，另一个输入有效地花费属于鲍勃的￡1(需要鲍勃的有效事务签名)。退还事务R具有两个输出，该输出可以恢复现状，即如果拟挖掘退还事务R，则向爱丽丝返还￡11，向鲍勃返还￡1(为了简单起见，忽略任何挖掘费用)。然后，支付通道用于协商鲍勃份额的递增增加，以抵消爱丽丝份额的相应减少。

在图6B中，原理是相同的，但在这种情况下，只有爱丽丝最初在出资事务F中提交任何数字资产，而退还事务R将把所有这些都转回爱丽丝。连续花费事务递增地增加支付给鲍勃的数额，从而抵消了退回爱丽丝的任何数额。

3.支付通道循环

支付通道可用于实现循环，这可以通过多种方式来实现。本公开涉及使用支付通道作为支付通道循环(PCL)来实现的循环。

当使用支付通道实现此类循环功能的执行时，通常需要某种形式的链下处理。这指可能涉及以下一项或更多项的任何类型的处理：

(i)读取事务；

(ii)写入事务；

(iii)将脚本引擎452的链下实例应用于脚本片段；

(iv)使用替代引擎来执行替代语言的代码(本文称为“非脚本”)。

实现PCL的最终目标是允许在链下执行迭代过程，同时确保与通道相关联的资源在参与方之间正确地进行分配。这意味着资源应取决于过程的结果，并符合通道的所有规则。过程的最终状态和/或初始状态也可以记录在链上。

“链下”一词指不作为事务核实过程的一部分执行的处理，即在区块链协议之外执行。通常情况下，这会发生在不属于区块链网络101的外部系统上，但该外部系统可以访问区块链网络101，因此可以看到已发布的事务。这将包括例如由爱丽丝、鲍勃或上述任何可信的预言机150o、150o-1、150o-2进行处理。

在某些方面，支付通道循环与基于账户的区块链相匹配，并且在某些方面超过了与之相关的优势。带图灵完备的虚拟机的基于账户的区块链可以在“链上”执行程序循环，以作为事务核实的一部分。一方面，这是有利的；但是在另一方面，计算资源价格昂贵。智能合约可能会被多个后续事务调用多次。每次调用时，网络中核实事务的所有节点都会执行智能合约代码以核实后续事务。

某些基于脚本的UTXO区块链的限制性因素在于不能在链上执行循环。因此，PLC是通过提供结构化框架来增强此类区块链的原生区块链功能的一种高效机制，其中循环的执行可以按照定义的规则在链下执行，鼓励所有方按照这些规则行事，并在任何一方未能遵守规则的情况下进行强有力的控制。在这种情况下，链下循环执行的优势在于不会给整个网络带来执行循环的负担，这意味着可以节约大量的计算资源。

本说明书的以下部分涵盖下述示例：

·通常将循环映射至支付通道架构；

·双向PCL；

·单向PCL。

由于可能适用于不同的用例，因此对双向PCL和单向PCL进行了区分。例如，双向PCL可用于实现过程的迭代，其中支付将通过状态转换在任意方向重新平衡，而单向PCL可能更适合于爱丽丝以递增的方式(即每次操作)向鲍勃支付计算资源的“付费计算”场景。

3.1通用PCL架构

本节介绍如何将循环的主要特征映射到一般支付通道架构的特征(参见2.2)。

3.1.1.将循环映射至支付通道

循环

通常，支付通道中可实现任何类型的循环。出于演示目的，本说明书侧重讨论‘for’循环。

映射至支付通道的通用‘for’循环的表达如下：

V＝V_initial

循环的元素包括循环计数器i、起点(0)和计数器上限(M)、传递给循环V_i的初始值和每次循环迭代时拟执行的代码Function()(或F()作为简写形式)的重复单元。该循环的目的在于将循环的元素映射至PLC。

图7示出了‘for’循环元素到支付通道的可能映射。该映射的描述如下所示。

递增nSequence

例如，循环迭代计数器i可在PCL中替换为更新阶段的事务输入中使用的nSequence值(或nS作为简写形式)。

nSequence的可能值的范围为0至M，其中M是最大nSequence值，被区块链协议视为‘最终’值。在某些区块链协议中，最大的8字节值0xFFFFFFFF指事务已最终确定事务，即在这种情况下，循环的上限是M＝0xFFFFFFFF。如果用十进制数表示，该值略低于43亿。

将循环计数器i映射至序列号nS允许通过略低于43亿次循环迭代来更新事务，这意味着在最终确定事务之前，主体中的语句至少可以执行43亿次。

需要注意的是，尽管循环计数器i逐步均匀递增，但nS的值可以按任意大小的非均匀步长递增。这是因为支付通道发挥作用对nS的唯一约束是在每一步中均有所增加，这意味着可以在任何循环的i值与nS值之间创建一对一映射。

但是，需要注意的是，该示例将nSequence值与‘for’循环的计数器联系起来纯粹是为了进行演示。如上所述，可以将任何形式的循环映射至支付通道中的一组事务。这可以通过以下方式实现：选择循环重复拟链下验证的任何条件，诸如‘while(六月下雨)’或‘foreach(Liverpool FC赢得游戏)’，并确保nSequence值在条件为TRUE。

使用基于预言机的系统可以实现用于验证此类条件语句的准确性的方法(参见第4节)。

输入值和参数

传递给循环的“初始输入”称为V_Initial，其中字母V表示‘值’。但是，更通俗地说，循环可能将取决于许多不同的输入值和参数，具体定义如下：

·输入值φ_i——传递给循环的值，可通过每次迭代的循环进行更新。需要注意的是，函数F()的输入不同于事务152的输入203，这在上下文中很明确。“输入值”一词可用于指作为函数的输入，“事务输入”一词可用于在有用的情况下在两者间进行显式隐藏。

·参数ω_i——传递给循环的值，可在每次迭代时从外部更新至循环。

输入值和参数都是“函数变量”的示例，本文使用的是后者。“函数变量”和“参数”可以同义使用。

第i^th次循环迭代获取的一组输入值和参数可以写成参数V_i：＝(φ_i,ω_i)的元组，其中第i^th组输入值和参数分别表示为φ_i和ω_i。

在大多数情况下，预计V_i中由第i^th事务作为参数的至少一部分元素将在第(i-1)^th事务中以某种方式编码或表示。换言之，预计第i^th事务将取决于第(i-1)^th事务，由此依赖关系由循环的重复函数F()进行定义。

需要注意的是，输入参数(φ_i,ω_i)可驻留在事务的任何字段中。鉴于未签名事务的输入脚本，无论是属于不可花费的输出(OP_RETURN)还是属于可花费的输出(在锁定脚本中)，都可能需要将参数(φ_i,ω_i)驻留在已签名输出中。

对于某些区块链协议而言，代码OP_RETURN应指一对操作码OP_0OP_RETURN。这可在必要时安全地恢复任何此类协议的OP_RETURN功能。关于更多细节，参见S.Shadders，“返回OP_RETURN——创世纪路线图第4部分——BitcoinSV(The return of OP_RETURN–roadmap to Genesis part 4-BitcoinSV)”，BitcoinSV，2019。

3.1.2重复功能单元F()

重复功能单元一词指拟通过PCL实现的循环主体，是包括可执行语句的部分代码。在本示例中，这是代码的功能单元，用上面的F()表示。

就PCL架构而言，重复功能单元F()是部分代码，在每次循环迭代中，该部分代码将在链下执行。功能单元F()可以视为“黑盒子”，不仅接收一个或更多个参数(一个或更多个输入和/或参数)，而且返回输出作为下一输入。因此，输入可以从先前事务中衍生，输出可用于形成下一事务。

例如，图8示出了功能单元F()，其中将第二事务152-j-1作为‘参数’，并生成第三事务152-j-2的一个或更多个组件作为‘输出’。这些事务使用上述数学符号分别表示为I_i-1和I_i。

例如，可以通过这种方法创建图2A所示的第三事务152-j-2。尽管图8中未示出，但第二事务152-j-1和第三事务152-j-2中的每一个都将花费与图2A中所示相同的第一事务152-i的输出。

图8通过以下方式突出了输入事务与输出事务之间的某些差异：(i)使nSequencei-1→i值递增；(ii)更新输入值和参数(φ_i-1,ω_i-1)→(φ_i,ω_i)，其中(φ_i-1,ω_i-1)表示第二事务152-j-1中的函数变量，(φ_i,ω_i)表示第三事务152-j-2中的函数变量。

Sig P_A和Sig P_B分别表示爱丽丝和鲍勃提供的有效事务签名；根据定义，输入值φ_i通过执行函数F()来进行计算，即作为F(φ_i,ω_i)(或其中一部分)(也就是说，应用于第二事务152-j-1的函数变量(φ_i,ω_i)的函数F())；根据定义，参数ω_i并非在执行F()时进行计算，而是由一个或更多个外部来源800提供(即循环外部，不一定是应用F的装置/系统/设备外部；例如，外部来源可以是爱丽丝、鲍勃、预言机102o(或预言机102o-1、预言机102o-2中的一个或两个)和/或其它任何外部来源)。

在本示例中，每个事务152-j-1、152-j-2都有两个事务输出，如图2A所示，分别具有数字资产值v₁,v₂和v′₁,v′₂。函数F()也可以确定退回事务152-j-2的输出的值v′₁,v′₂，并且可使用输入事务142-j-1的输出的数字资产值v₁,v₂，可用于确定v′₁,v′₂，此外(φ_i-1,ω_i-1)。尽管在该示例中每个事务具有两个输出，但这通常不是必需的；每个事务可以具有任意数量的输出，包括一个输出，并且可能有或可能没有相同数量的输出。

下节对如何在PCL中重复执行(至少每次循环迭代执行一次)功能单元F()进行了详细描述。要求‘至少’一次是因为一次循环迭代可能需要该单元的一些整数k≥1应用。

在表达PCL中使用的函数F()时，有两个方案可供选择；可以用脚本语言(即区块链150的脚本语言)进行编写或一些替代性语言(非脚本)进行编写。此处的选择可能会影响PCL的实现方式：

·脚本——在这种情况下，功能单元可以作为可花费的输出脚本的一部分存在，可使用比特币脚本引擎由解释器与参数(φ_i-1,ω_i-1)一起在链下执行，以生成下一事务的一个或更多个组件。

·替代性非脚本语言——在这种情况下，功能单元可能需要作为不可花费的(例如，OP_RETURN)输出的一部分存在。然后，代码单元F()可以使用其它引擎或参数(φ_i-1,ω_i-1)在链下执行，以生成下一事务的一个或更多个组件。

稍后将详细描述示例性PCL实施方式，其中演示这两种方法在不同的情况下如何发挥作用。

应当注意的是，即使功能单元F作为事务中的脚本，但在所描述的示例中，事务的有效性可以不取决于在节点104处执行F()的结果。也就是说，事务的有效性并不一定取决于函数F()。相反，函数F()定义一组“支付通道规则”，支付通道根据这些规则在链下实现。因此，支付通道的实施方式取决于F的链下执行(不论是使用脚本还是使用非脚本进行编码)，但任何已发布事务的有效性都不一定取决于F(即使使用脚本进行编码)。

容纳零函数

最后需要考虑的是，在某些情况下，F()在脚本中实现，并且执行F()是锁定脚本或解锁脚本的一部分。迭代的输出值φ_i可能取值为“零”，这会使事务无效。由于可以充当结束循环的信号，因此这可能是可取的。但是，如果情况并非如此，则零值可以用α等占位符替换，对于一些非零值α，通过向功能单元添加比特币脚本条件语句：

其中[F()]表示比特币脚本中代码的功能单元，[G()]现在表示可容纳零值结果的重复单元的版本。如果仔细选择α，则其也可以作为一些特殊事件的标志，诸如到达循环的终点。

3.1.3 PCL中的事务

在本节中，描述了许多可能的“框架”事务架构，该事务架构可用于实现通用PCL。这些事务分别根据第(2.2)节中的以下支付通道的术语进行分类：出资、更新阶段和结算事务。

出资事务

在PCL中，出资事务(funding transaction)F扮演下述双重角色：(i)将参与方的资源托管至支付通道；(ii)建立循环过程中拟使用的功能单元F()。

角色(ii)是PLC中所述出资事务F的重要特征。出资事务F用于不可改变地记录实现支付通道所必须遵循的规则，这些规则包含在函数F()中。这些规则由签署出资事务F的各方约定。一旦提交到区块链150，出资事务F便充当约定规则的不可改变的证据。

出资事务F可包含体现函数F()的代码，或可以其它方式证明该代码。例如，代码可包含在提交到区块链150的另一事务中，函数事务F可通过哈希值或出资事务F中包含的该代码的其它唯一标识符来证明该代码。

对于双向支付通道，以及其中功能单元用脚本编写的情况，如图9A所示构建出资事务F。与图2A和图8相同，出资事务F用附图标记152-i表示。在该示例中，重复单元是可花费的脚本的一部分。

在这种情况下，只存在单一输出，该输出包括脚本的两个不同部分。第一部分是简单的2/2多重签名脚本，需要共同托管双向支付通道的资源。第二部分是重复功能单元F()，在该示例中用脚本编写。

在出资事务F中包含函数F()的另一动机是只需写入和存储一次，而不是像功能单元F()驻留在更新阶段的事务600中那样创建多个副本。出资事务在下文中作为事务1进一步进行详细描述。

事务1：一种出资事务(详细描述)，其中重复单元是可花费的脚本的一部分。

或者，如果功能单元用不同的编程语言编写，则可构建类似的出资事务，具体如图9B所示。

在这种情况下，提供了分离多重签名脚本与功能单元的两个输出，该功能单元现在用非脚本语言编写。为此，代码单元被存储在不可花费的(例如，OP_RETURN)输出中，这意味着在事务核实过程中，矿工永远不会执行这部分事务。

图9B所示的出资事务在下文中作为事务2进一步进行详细描述。

事务2：一种出资事务(详细描述)，其中重复单元存储在OP_RETURN输出中。

在PCL的建立阶段，作为初始步骤S0的一部分，为出资事务F创建相应的退还事务(refund transaction)R。退还事务R的nSequence值为0(或小于最大值的任何数)，nLocktime值设定为未来的T_R。

此类退还事务的示例如下文作为事务3所示。

事务3：一种退还事务(详细描述)，其花费出资事务的输出。

该退还事务R只需花费用于将资源托管到通道的出资事务F的可花费的输出。退还事务R的目的仅仅是在PCL的更新阶段没有其它相互签名的状态I_n的情况下，将资源的初始状态返回给参与方。需要注意的是，无论是否使用图9A或图9B所示的出资事务F类型，退还事务R均可采取相同的形式。

循环事务

在本文中，与支付通道的更新阶段相对应的事务被重命名为循环事务(looptransaction)，因为这些事务将表示每次相应循环迭代的输入和输出。也就是说，图6至图6B中所示的一系列花费事务600中的每个事务均称为循环事务。

每个循环事务I_i包含一组值V_i：＝(φ_i,ω_i)，表示在循环的下一迭代中使用的相应输入值和参数。请记住，通常，值(φ_i,ω_i)可驻留在事务中的任何位置是合理的。但是，为了简单起见，在本文中将它们显示在输入中。但是，替代地，在输出(例如，OP_RETURN输出)中存储这些值可能是有利的，因为这些值将成为事务的已签名消息的一部分，而输入脚本本身不是已签名消息的一部分。

具体地，图10示出了花费出资事务F的输出的初始循环事务I₀。如图6至图6B所示，在支付通道协商S1的第一步中(紧接在建立出资事务和退还事务F,R的初始步骤S0之后)创建初始循环事务I₀。

图10示出了循环事务，并且示出了其输入如何发送出资事务的可花费的输出。正如预期的那样，对于出资型Nakamoto支付通道，循环事务具有设置为未来某个时间T_L的nLocktime值，其nSequence值不是最大值。

循环事务的输出可以采用任何形式。

下面给出了循环事务的两个示例，即事务4和事务5，这两个事务都表示循环I_i的第i^th次迭代，其中i是介于0与最大值M之间的整数。请记住，该事务不一定锁定至未来的时间T_L，nSequence值不断递增，直至达到最大值M或时间T_L到期。

第一示例示出了循环事务，由此第i^th次循环迭代的输入值φ_i和参数ω_i均存储在循环事务的输入中。

第二示例示出了循环事务，其中φ_i和ω_i存储在OP_RETURN输出中。这样做的另一优势在于，值和参数可以是由事务输入中的签名所签署消息的一部分，这可以通过适当地选择SIGHASH标志(例如，SIGHASH ALL)来实现。

需要注意的是，在两种情况下，为了简单起见，输出中的支付值示出为单调递增(1+i)或单调递减(11-i)，与单向通道的情况一样。但是，这通常不是必须的，输出的数字资产值可以改变或保持不变，具体取决于执行支付循环函数F()的结果。

事务4：一种循环事务I_k(详细描述)，其中输入值和参数均存储在输入中。

事务5：一种循环事务I_k(详细描述)，其中输入值和参数均存储在输出中。

结算事务

结算事务(settlement transaction)S具有与最新的循环事务完全相同的数据，但现在具有最大nSequence值。这会禁用nLocktime值，并使结算事务对于挖掘到区块链150上是有效的。

图11A示意性地示出了示例性结算事务S。

图11B示意性地示出了结算事务如何花费S原始出资事务F。

下面为结算事务S的详细示例，即事务6。假设N次循环迭代后发生结算(因此φ_N,ω_N)。

事务6：一种示例性结算事务S(详细描述)，其中输入值和参数均存储在输出中。

3.1.4实现循环

图12示出了如何使用出资事务F中建立的功能单元F()与在支付通道更新阶段创建的循环事务I₀,I₁,I₂,…的组合来实现PCL循环功能的流程图。

第一循环事务I₀包括输入值和参数值的初始集(φ₀,ω₀)，该输入值和参数值并非通过执行功能单元而生成的。这些值是循环过程开始时的初始状态。

用于N≤M的每个后续循环事务I₁,…,I_N是功能单元F()作为运营商应用于先前事务的结果。例如，I₁＝F(I₀)、I₂＝F(I₁)，以此类推。这也可以理解为功能单元应用于前一组输入值和参数：φ_i＝F((φ_i-1,ω_i-1))。

如上所述，功能单元F()也可以计算数字资产值或每个循环事务I_i的输出值或输出。这些数字资产值表示为v_i，先前事务I_i的数字资产值v_i-1可用于实现此目的。根据上述定义，数字资产值v_i是输入值φ_i的一种形式。也就是说，输入值ω_i可包含或包括循环事务I_i的数字资产值v_i。有时，本公开对数字资产值v_i与数字资产值v_i之外的输入值进行了区分。对于后者，可以使用符号φ′_i。其中包括除数字资产值v_i之外的输入值φ′_i的示例。具体举例来说，先前事务I_i-1的非数字资产输入值φ_i-1可用于计算当前事务I_i的数字资产值v_i：

v_i＝F(φ′_i-1)

注意F可取其它参数和/或返回附加的输入值。

通常，功能单元F()只接受输入值φ_i或参数ω_i，或可同时接受两者。

再如，功能单元F()可以具有以下效果：

2)生成新类型的数据字段并将其插入I_i(与更改现有的数据字段相反)，该新类型的数据字段与先前事务I_i-1中的任何现有数据字段均不对应。例如，向事务I_i添加OP_RETURN输出。

3)从I_i-1中删除现有类型的数据字段，使得先前事务I_i-1包含与新创建的事务I_i中的任何数据字段都不对应的数据字段。

功能单元F()取自每次循环迭代的出资事务F，可以存储在存储器中，但不可以复制。

任何一次循环迭代的执行都在链下完成，即每个步骤(S1、S2……SN+1)都在链下完成。

双方在每个新状态I_i(即，新循环事务)上签名，以表示循环的计算进度。一旦双方签署一个状态，则可以通过再次执行功能单元F()来继续操作，以生成下一状态I_i+1进行签名。

3.2双向PCL

图13示出了用于根据支付通道循环实现双向通道循环的示例性流程。

前一节建立了通用框架，该通用框架用于在支付通道中实现循环功能。其中包括一组事务模板以及使用这些事务模板的循环机制，该机制允许在链下执行循环。

下述示例利用该框架展示如何利用双向支付通道来实现双方之间的简单支付循环。

场景

假设有两个矿池玩家：爱丽丝和鲍勃。他们希望进行一对一的锦标赛，其中包括大量N场游戏。爱丽丝和鲍勃也希望对锦标赛的结果进行风险投资，但他们知道存在其中一个玩家可能拒绝继续比赛并在任意时间点离开桌子的风险。

因此，他们决定使用双向支付通道，以确保根据每个玩家在每场游戏后所玩游戏的比例重新平衡总奖励。这样，每个玩家最多可被骗取一场游戏的奖励。

他们的支付通道执行如下操作：

1.爱丽丝和鲍勃都同意风险投资W/2，其中W是锦标赛可能的总奖池。

2.爱丽丝和鲍勃合作构建：

i.出资事务，用于托管他们的全部资源W；

ii.相应退还事务，时间锁定到未来的T_R。

需要注意的是，出资事务的可花费的输出包括功能单元F()，这会每轮更新爱丽丝获胜的次数、并使游戏的总次数增加一次。这用比特币脚本编写为：

3.在每轮矿池结束后，爱丽丝和鲍勃构建循环事务，nLocktime设置为未来的时间T_L，并花费出资事务。该事务具有输入，输入中包含：

i.φ_i＝{Total No.Games,No.Games won by Alice already}＝{K,k_A}

ii.ω_i＝{Outcome of this round}＝1(Alice wins)or 0(Alice loses)(注意，0和1可以是分别表示爱丽丝获胜和失败的任意值)。

4.该过程重复至达到总游戏数N为止，然后爱丽丝和鲍勃进行结算；或者，一方决定停止继续比赛，他们提前进行结算。

在该场景中，重复单元F()更新爱丽丝获胜的游戏数和每轮的总游戏数。这意味着在每个循环事务中，支付数额可以根据每个玩家获胜的游戏比例进行重新平衡，即k_A/K∶1-k_A/K。

关于双向PCL的观测结果

由于是双向通道，因此最终状态可能有利于任何一方。预计该方将检查事务的最终状态，并鼓励他们发布拟挖掘的最终状态。

通道的任何两个连续状态之间的资源再分配可能对一方有利，也可能对另一方有利。预计至少一方(最有可能是每个状态转换所支持的一方)将检查最新的状态(即状态转换的输出)。当一方选择“提前结算”时，只是在T_L到期时广播最新的状态，而不是继续进一步递增nSequence。

由于nSequence值和nLocktime值在更新阶段事务中的影响，任何一方均不能通过发布早前事务来欺骗另一方。如果一方发布早期状态，则另一方只需发布更近的状态(具有较大nSequence值)，从矿工的角度而言，这将覆盖早期状态。

在更新阶段创建和更新事务的行为可以由爱丽丝、鲍勃或一些链下预言机系统执行(参见第4节)。每个事务的签名顺序也可能取决于该流程的确切配置，以及使用PCL的场景的情境要求。

这里假设功能单元用脚本编写，并存储在可花费的输出中。但是，如前所述，这可以替换为用任何编程语言编写的功能单元F()，并存储在OP_RETURN输出或其它不可花费的输出中，因为循环语句主体的执行是在链下执行的。

3.2.1双向PCL

双向PCL的可能用例包括：

·重复使用公用设施的小额支付；

·监控服务费用支付；

·涉及多个商户流入和流出的贸易；

·涉及重复动作的比赛(例如，回合制RPG)。

3.3单向PCL

图14示出了示例性单向PCL的流程。

本节介绍如何使用单向PCL作为一般PCL的特殊情况来实施某些任务的示例。具体地，任务包括：

·付费计算；

·重复小额支付。

下面的说明考虑了付费计算的情况。

场景

假设有两方：爱丽丝和鲍勃。爱丽丝是在偏远地区工作的研究人员，几乎无法获得计算资源；而鲍勃是专注“按计算付费”服务的服务提供商。

爱丽丝希望向鲍勃付费以计算2^N值，其中N是非常大的整数，因此爱丽丝自己无法高效地计算所需的值。鲍勃收到付费后提出为爱丽丝计算该值。但是，他明确要求希望使用小额支付以递增方式付费，即每次计算支付数额k。

为了实现这一点，爱丽丝和鲍勃同意在彼此之间实现单向PCL。选择的PCL变体是单向的，因为爱丽丝(支付人)始终在每次循环迭代中向鲍勃(收受人)付费。他们的支付通道循环如下所示：

1.爱丽丝和鲍勃就每轮计算的价格k＝￡1达成一致。这是爱丽丝在每次循环迭代中因鲍勃计算(φ_i,ω_i)＝F((φ_i-1,ω_i-1))而向鲍勃支付的数额。

2.爱丽丝和鲍勃合作构建：

i.出资事务，托管爱丽丝的全部资源k×N；

ii.相应退还事务，时间锁定到未来的T_R。

出资事务的可花费的输出包括功能单元F()，其简单地将输入参数V_i＝φ_i＝<Argument>乘以2，用比特币脚本编写为：

[F()]＝<2>OP_MUL

3.爱丽丝创建初始循环事务，其中包括初始输入参数φ₀＝<2>，其使用功能单元得出拟乘以2的值。

4.鲍勃(或鲍勃操作的预言机)构建每个后续循环事务，该后续循环事务花费步骤2中的出资事务，并将nLocktime设置为未来的T_L。对于i>0，每个循环事务的输入包含新计算的值φ_i＝<2ⁱ>。

5.该过程重复至鲍勃计算出最终值φ_N＝<2^N>时为止，或一方决定终止交互并提前结算为止。

关于单向PCL的观测结果

由于是单向通道，因此最终状态可能始终有利于鲍勃(接收方)。预计该方将检查事务的最终状态，并鼓励他们发布拟挖掘的最终状态。需要注意的是，由于是单向通道，因此始终鼓励鲍勃发布最终(或最新)事务。

而且，在单向通道中，始终鼓励发送方(爱丽丝)发布非最终(或早期)事务。但是，nSequence和nLocktime的机制用于阻止爱丽丝这样做。如果爱丽丝发布早期状态，则鲍勃只需发布更近的状态(具有较大nSequence值)，从矿工的角度而言，这将覆盖早期状态。当一方选择“提前结算”时，只是在T_L到期时广播最新的状态，而不是继续进一步递增nSequence。

通道的任何两个连续状态之间的资源再分配可能对一方有利，也可能对另一方有利。预计至少一方(最有可能是每个状态转换所支持的一方)将检查最新的状态(即状态转换的输出)。但是，在付费计算的情况下，当所有状态转换都有利于鲍勃(接收方)时，预计鲍勃将检查支付通道资源的新状态。

在更新阶段创建和更新事务的行为可以由爱丽丝、鲍勃或一些链下预言机系统执行(参见第4节)。每个事务的签名顺序也可能取决于该流程的确切配置，以及使用PCL的场景的情境要求。

假设功能单元F()用脚本编写，并存储在可花费的输出中。但是，如前所述，这可以替换为用任何编程语言编写的功能单元F()，并存储在OP_RETURN输出或其它不可花费的输出中，因为循环语句主体的执行是在链下执行的。

在实践中，爱丽丝不太可能验证鲍勃的所有计算(因为如果她验证所有计算，则可能一开始便不会将计算外包)。但是，爱丽丝可以对鲍勃提供的有限数量的计算结果进行“抽检”(例如，通过随机抽检)，并亲自验证计算结果是否匹配。

出资事务中的函数变量

需要注意的是，除了在第一循环事务I₀中包含初始函数变量(φ₀,ω₀)外，还有一种替代方案，即可以在出资事务F本身中包含或以其它方式证明并且表示为(φ₀,ω₀)的初始条件。这样将可以始终在链上发布初始状态。在这种情况下，初始状态可以与稍后在链上发布的状态进行比较，以在结算阶段关闭通道。通过比较现在都驻留在链上的初始状态与结算状态，可以看出循环进程执行的进度，即是否达到预期的终止时间点或是否提前终止。图15示出了使用该原理的单向PCL的示例。该图示出了过程的早期步骤，相比图14，自出资事务F提取初始值(φ₀,ω₀)；之后，如图14所示继续该过程。需要注意的是，尽管单向PCL只是作为示例进行考虑，但这同样适用于双向PCL。

证明结算事务S中的输入值φ_i/参数ω_i

图18A示出了用附图标记1800表示的结算事务S，其中包含附加信息1802。该附加信息1802证明导致结算事务1800的输入值和/或参数的完整序列，即(φ₀,ω₀),(φ₁,ω₁),…,(φ_M,ω_M)。在本示例中，该信息采用图18B所示的默克尔树1801的默克尔根哈希1802的形式。

图18B示出了默克尔树1801，其中包含多个叶节点1804，每个叶节点表示一组输入值/事务(φ_i,ω_i。例如，每个叶节点1804可以是该组的哈希值。该组输入值/参数按根迭代进行排序，即从0到M。默克尔树还包括中间节点1806的层次结构。最低级别的中间节点通过对一对非叶节点进行哈希处理来创建，在以上任意级别的每个中间节点均通过对下一级的非叶节点进行哈希处理来创建，直至根哈希1802为止。在这种情况下，动词“进行哈希处理”指“通过应用至少一个加密哈希函数来生成”，从而包括双重哈希等。默克尔树本身称为用于证明和高效地验证排序数据元素的数据结构。因此，默克尔树1802的结构不再进一步进行详细描述。只要根哈希1802简洁、可靠地证明了输入值/参数的整个序列即可。

一旦发布结算事务S，则出资事务F(现在由提交的结算事务S花费)中的功能单元F()可用于验证结算事务S，即鉴于输入值/参数的可验证序列验证其输出的值v_M所定义的数字资产的最终分配(假设功能单元F()用于计算这些值v_i)。输入值/参数的给定序列可以使用该序列计算重构的根哈希来验证，以与结算事务S中的根哈希1802进行比较。

默克尔根哈希1802只是可证明输入值/参数序列的一段数据的一个示例。例如，可以使用该序列的简单哈希、双重哈希等，或实际上序列本身可仅包含在结算事务S中，其中该信息为不敏感信息。默克尔树1801的优势在于，任何一组输入值/参数(φ_i,ω_i)均可通过默克尔证明验证为属于默克尔树1802，这种能力在某些情况下可能是有利的，但不一定是必需的。默克尔证明本身是已知的，本文中不再描述。

3.3.1用例

双向PCL的可能用例包括：

·付费计算；或

·递归性商户-客户交互，例如小额订阅支付。

3.4其它考虑因素

激励模型

支付通道至少在一定程度上依赖于激励模式，以确保通道中的任何参与方都无法成功地欺骗任何其他参与方，使得后者的收益低于其本身应得的收益。本文所述支付通道的广义激励模型如下所示：

·Nakamoto模型——主要由于环境原因，鼓励双方不欺骗其他方。如果参与方一直更新事务状态，一旦一方选择双重花费其输入并使协商失效，则会损害他们的关系。

·出资型Nakamoto模型——在任意时间点，均可能鼓励任何一方欺骗其他方，具体取决于通道的状态。但是，(i)建立出资事务以及(ii)nSequence和nLocktime功能用于通过发布事务的早期版本，确保任何一方都不能成功地欺骗另一方来减少欺骗动机。

安全与效率的权衡

当针对特定用例选择支付通道架构时，通常需要进行权衡，尤其是安全与效率的权衡。这些术语的广义定义如下：

·安全——由于支付通道通常涉及多方之间的资源转移，因此必须注意确保任何一方实际上都不会骗取另一方的资源。因此，通道安全指参与方的欺骗能力。

·效率——对于支付通道而言，效率可以统称为必须交换的数据量、必须产生的延迟和必须牺牲的财务成本，以实现通道，从而达到特定目标。

通常，需要选择是使用出资型Nakamoto通道(高安全性)还是使用Nakamoto通道(高效率)。

如第2.2.2节所述，出于两个原因，FN通道被称为“高安全性”通道。同时使用nSequence和nLocktime可以降低挖掘早于最终状态或当前状态的状态的可能性。此外，使用出资事务降低了任何一方通过在建立阶段提交共同托管而“双重花费”通道资源的可能性。

Nakamoto通道被称为“高效率”通道，因为不需要出资事务(也不需要相关的退还事务)。这意味着不仅建立阶段更简洁，数据密集度更低，而且通道只需发布和挖掘一个事务，从而降低实现通道所需的“事务费用”总成本。

例如，假设爱丽丝和鲍勃分别是客户和信誉良好的商户。他们都希望使用支付通道记录一组重复购买的项目，而不发布每个单独购买的事务。Nakamoto支付通道适用于这种情况，因为爱丽丝和鲍勃有外部的真实理由信任另一方，这使得效率成为首要考虑因素。

相反，如果爱丽丝和鲍勃是通过互联网连接的远程对等方，并且希望通过支付通道交换数据，则每一方可能都无法核实对方的可信性。在这种情况下，安全性是首要考虑因素，因此FN通道方案可能更好。

关键在于，不同的支付通道可用于执行相同的任务或不同的任务，具体视情况而定。在介绍第4节中支付通道循环的概念时，这一推理同样适用。使用一种架构实现特定的循环并不一定会妨碍使用另一种架构来实现该特定的循环。

更新阶段竞态条件

在涉及nSequence和nLocktime的通道——Nakamoto和FN架构中，如果在接近公共锁定时间T_L时发布两个具有未最终确认的nSequence值的冲突状态，则可能出现竞态条件。

问题在于，一旦锁定时间到期，具有不同nSequence值但具有公共nLocktime值T_L的两个此类替代版本都将独立地显示为有效。因此，一个版本I₁(即早期版本，有利于爱丽丝)可能由爱丽丝在接近T_L时发布，并很快被挖掘。

虽然鲍勃可以看到当发布早期版本并通过发布更近的版本I₂(有利于鲍勃)来进行响应时，在I₂之前挖掘I₁的概率仍然为非零，相当于通道中的双重花费。

鉴于所有挖矿节点可能在发现新区块之前接收到两个事务(如果快速连续地广播)，而任何诚实的矿工都会丢弃I₁并认为I₂nSequence编号更高的是唯一有效的版本，此类事件发生的可能性非常小。然而，有许多方法可以缓解此类场景的风险，其中两种方法如下：

·可变nLocktime——每当nSequence值增加时，则减少更新阶段事务中的nLocktime值，以确保事务的最新版本始终比旧版本更早地进行有效挖掘。

·增加费用——通过增加更新阶段事务的每个新版本的总事务费用，可以激励矿工基于盈利能力挖掘最新版本。

接收方检查

具体地，参考第3.2节和第3.3节，至少有一个交互方(或预言机，参见第4节)有责任检查PCL中每个更新阶段事务的输出中分配的资源值。

通常，这可能是作为“接收方”的任何一方的责任。如第2节(“方向性”)所述，任何一方都可以是双向PCL和单向PCL中给定状态转换的净受益方。因此，对于任何状态转换而言，任何一方都可能有责任检查资源的分配以及事务本身的完整性。但是，在单向通道中，最终状态应始终由整个接收方进行检查。

φ_i值的验证

PCL架构的重要特征在于，输入值/输出值φ_i根据重复单元在每次循环迭代中进行更新，具体如下：φ_i＝F((φ_i-1,ω_i-1))。

但是，这通常由‘计算方’(例如，鲍勃)完成，因此本说明书未考虑对于给定输入值φ_i-1，‘非计算方’(例如，爱丽丝)如何验证输出值φ_i的正确性。通常，至少有三种方法可以做到这一点：

·陷门函数——如果重复单元涉及找到难以计算的陷门问题的解决方案，诸如通过重复哈希处理在目标值下找哈希摘要，则最终将有陷门用于快速验证。这意味着非计算方将能够快速验证计算值给出的最终值φ_N是正确有效的。

·随机抽查——因为预期重复单元将在每次循环迭代中被重复利用，‘非计算方’可以采用单一输入φ_i-1并验证其生成如‘计算方’所计算的正确候选输出φ_i。非计算方可以在循环中的任意时间点以随机间隔执行此操作，这意味着计算方的行为可以在任何时刻进行检查。

·使用预言机系统——功能单元F()可以在某种基于预言机的系统中建立，其中关于预言机如何操作的‘规则’是众所周知的，并且能够提前进行审核。参见下文第4节。

3.5链接式PCL

单个PCL过程中可以实现的操作数量是有限的。在比特币中，目前大约有43亿次操作，或更确切地说有2³²-1次操作。在大多数实际情况下，这应该是足够的。

然而，仅仅通过将多个PCL链接在一起便可克服这一限制条件。通过这种方式，操作的最大数量可以扩展到任意大的数量，其中每个单独的PCL过程用于覆盖大约43亿次操作。

方法

实现PCL的方法比较简单，将一个PCL的结算阶段作为下一PCL的建立阶段即可。

这涉及通过以下方式修改PCL的正常结算阶段：

·在正常的单一PCL中，结算阶段仅涉及通过签署表示相同状态但nLocktime值为0的事务来最终确定最新签署的更新阶段事务。这允许广播最新状态并将最新状态发布到区块链上。提交到区块链的该事务表示通道的最终状态，并向双方提供反映该最终状态的输出。

·为了实现一系列链接式PCL，一个PCL的结算涉及签署将资源锁定到多重签名输出而不是多个相关方的多个输出的最终状态。通过锁定到多重签名输出，结算事务在功能上等同于出资事务，可用于开始下一PCL。

·签署新的退还事务，根据先前PCL的最终状态将新出资事务的输出返还参与方。这可确保先前PCL的结果被保留为下一PCL的缺省的退还结果。

图16中概述了一系列链接式PCL的这种设计。标记为1300的区域强调第一PCL与第二PCL之间的交叉(注意，第一PCL的结算和第二PCL的建立视为一个阶段)。

在该混合阶段，创建第一结算事务(S1)等同于创建第二出资事务(F2)。其中还示出了第二退还事务(R2)，该第二退还事务以与第一PCL的最终更新阶段事务(I_N)完全相同的方式将F2的资源返还参与方。

4.支付通道预言机

第3节考虑了两个参与方爱丽丝和鲍勃，他们以点对点的方式行事。在所有情况下，均依赖于双方中的至少一方来负责在链下执行循环的重复代码单元F()。

但是，可以推广该链下过程，并委托至预言机的角色(例如，图3A中的预言机102o或图3B中的预言机102o-1、102o-2)，该预言机读取每个连续循环事务与初始出资事务，并执行函数以产生下一事务。

可信的预言机本身是区块链技术中的已知概念。可信的预言机的典型作用是提供可信的外部数据源，例如可能与时间有关的外部数据源。例如，在基于账户的模型中，智能合约的执行依赖于当前的天气条件，或者体育赛事的结果，其中该信息由双方约定的预言机提供。

在当前上下文中，可信的预言机的状态类似于双方约定的特定可信的预言机，但是可信的预言机的作用是应用一组预定义的(且预先约定的)规则来创建支付通道事务，即在功能单元F()中编码的规则。

执行预言机可以在支付通道中构建事务。事务可被参数化为：

1.锁定时间；

2.序列号；

3.输出

a.索引；

b.值；

c.锁定脚本。

也就是说，执行预言机可根据迭代的计算结果设置锁定时间、序列号或事务的输出。需要注意的是，为了简单起见，假设事务的输入是出资事务的输出点，不能由给预言机进行更改。一旦预言机创建花费事务的新版本，则相关参与方可签署事务。

有一些特定的规则适用于任何此类预言机的实现：

1.锁定时间：

2.序列号：max>s_i>s_i-1>0。

3.总输出值小于或等于出资事务值或输入的总值。

这可以通过允许在支付通道中实现任何一个或更多个预言机来进行推广。如果支付通道中的所有参与方都同意一组作为预言机实现的规则，则经由支付通道交换的所有事务除了在比特币协议下有效外，还必须遵循新规则。

也就是说，支付通道提供具有功能和效用的定制型交互通道实例，其中安全性和支付由比特币协议支持。

4.1国际象棋支付通道

在第一示例中，爱丽丝和鲍勃可以一起下国际象棋。此处的核心理念是实现执行国际象棋规则的可信的预言机——在功能单元F()中编码。需要注意的是，此示例用于介绍通常适用于任何支付通道的概念，其中预言机充当双方之间的“中介”，即大致如图3A所示。尽管国际象棋游戏示例的上下文中有所描述，但相关的描述同样适用于任何此类场景。

预言机是可信的，不会与任何玩家串通。

建立

爱丽丝和鲍勃都验证了实现第三方可提供的国际象棋预言机的源代码。爱丽丝、鲍勃和国际象棋预言机创建2/3(2-out-of-3)出资事务F和相应的退还事务R，以打开国际象棋支付通道。为使游戏更为有趣，当吃掉对方的棋子时，爱丽丝和鲍勃可获得一小部分资源作为奖励。

2/3出资事务具有事务输出，其中分别包含爱丽丝、鲍勃和预言机的三个公钥，作为2/3检查多重签名操作的操作数。因此，爱丽丝、鲍勃和预言机中的任何两个均可通过提供相对于其指定的公钥有效的事务签名来解锁输出。

图17示出了用附图标记1700表示的2/3出资事务F的示例。特定出资事务1700与图9A所示的“2/2”出资事务152-i相同，但出资事务1302的可花费的输出指定爱丽丝、鲍勃和预言机102o的三个公钥，只需两个有效事务签名即可解锁，即爱丽丝+鲍勃可以解锁，爱丽丝+预言机可以解锁，鲍勃+预言机也可以解锁。

预言机102o的公钥构成预言机102o的公开身份，因此，通过签署出资事务并将其提交到区块链，爱丽丝和鲍勃可以选择相互授权预言机102o在支付通道中充当中介，并在区块链150中不可改变地记录该授权。通过这种方式，各当事方同意预言机102o的身份，并且该协议不可更改地记录在出资事务F中。如果任何一方对特定预言机没有足够的信任，则他/她/它可以自行拒绝签署支付事务。

预言机102o的作用是执行出资事务1300中指定的功能单元F()，以创建循环事务(或至少其组件)，并为每个循环事务提供两个所需签名中的一个签名。可以假设，爱丽丝和鲍勃只有在他们都信任预言机102o按预期履行该职责时才会签署出资事务1300。

下棋

通过支付通道实现的国际象棋游戏逐步进行描述。在每一步行动中，预言机102o将为玩家准备事务模板(爱丽丝或鲍勃轮流选择棋局的走棋)。功能单元F()用于验证每个游戏的行动，并在行动有效时更新游戏的状态。在上述内容中，每个游戏的行动都是参数w_i(由玩家在循环外部确定)，每个游戏状态都是输入值φ_i(通过将F()应用于先前的游戏状态φ_i-1和最新的行动w_i-1来确定)。

玩家将能够从事务中读取

1.棋盘的当前状态，以及

2.反映当前棋盘状态的奖励分配。

然后，玩家在OP_RETURN有效载荷中填写他们的行动，并签署事务。

收到已签名事务后，预言机102o会检查行动和签名的有效性。如果两者都有效，则预言机102o签署事务，以组成2/3多重签名。

预言机102o将行动应用于棋盘，并计算产生的状态。预言机102o根据新状态计算两个玩家之间奖励的相应分配。然后，预言机102o创建带较低锁定时间、较高序列号和三个更新输出的新事务模板，其中一个是包含新状态和所有历史行动的OP_RETURN有效载荷。

事务列表如下所示。

行动1：

假设爱丽丝开始第一步走棋(move)。她从国际象棋预言机102o-获得事务模板，完成走棋并签署事务。

其中data₁包括：

一旦国际象棋预言机102o收到事务或仅收到爱丽丝的走棋和签名，则检查是否爱丽丝的走棋是否有效。如果是，则国际象棋预言机102o将其签名添加到事务的输入中，并将其传递给鲍勃进行记录。然后，国际象棋预言机102o计算棋盘的新状态。该新状态将包含在鲍勃的下一事务模板中。由于未吃掉棋子并且不满足获胜条件，则与当前事务模板一样，在下一事务模板中在两个玩家之间平均分配奖励。

这标志着行动1的结束。

行动2：

鲍勃从预言机102o获得第二事务模板，并填写行动内容：

需要注意的是，第二事务可视为第一事务的更新版本。锁定时间

比

更接近当前的时间范围。序列号增加1到0x00000002。OP_RETURN数据有效载荷已进行更新，以反映棋盘的当前状态和鲍勃的下一走棋。然后，将事务发送至预言机102o，以在发送给爱丽丝之前进行验证和签名，正如行动1一样。

行动3：

与先前事务类似，爱丽丝在第三事务中填写她的走棋内容，并发送至预言机102o-。

在该走棋中，假设爱丽丝吃掉了鲍勃的士兵。预言机102o完成所有计算，并得出棋盘的新状态和相应的输出。但是，预言机102o只在鲍勃的下一走棋的事务模板中包含这些变更。它签署第三事务，并将其转给鲍勃。

当鲍勃通过预言机102o-收到爱丽丝的走棋时，如果他作弊并在失败时离开支付通道，则爱丽丝或预言机102o可以发布反映结果的事务。需要注意的是，出资事务仅需两个签名就能进行花费。因此，鲍勃没有动机单方面离开通道。

鲍勃的下一步走棋模板如下所示：

结算

假设爱丽丝在行动21中赢得棋局。爱丽丝将第21个事务提交到预言机102o。

预言机102o验证鲍勃的国王将在爱丽丝走棋后被吃掉。如果属实，则签署事务并将其连同最终事务模板一起传递给鲍勃。当鲍勃收到模板时，他接受失败并签署最终事务以结算支付通道。如果鲍勃单方面选择离开通道，则爱丽丝和预言机102o可以签署最终事务，以结算支付通道。

4.2工作证明支付通道

在该场景中，爱丽丝是矿工。她想将自己的挖掘计算委托给哈希预言机。这与图3B的场景相对应，其中预言机102o-1、102o-2是哈希预言机和(在这种情况下)单一非哈希参与方(矿工爱丽丝)。

在不失一般性的前提下，假设两个哈希预言机102o-1、102o2(简称奥利维亚和奥斯卡)相互竞争(在实践中可能有两个以上相互竞争的预言机)。

为了实现“挖矿池”的形式，爱丽丝为其支付通道将网络难度降低到合理的水平。也就是说，如果网络需要用于有效区块的区块哈希≤BH，则爱丽丝可以设置计算上更简单的任务，即找到产生区块哈希<BH′的随机数，其中BH′>BH。

每当参与方找到符合标准的随机数时，她都会给予奖励。她希望在支付通道的有效使用期间，其中一个答案将产生小到足以应对网络难题的哈希值。

基本思路是，每一方都试图解决比区块挖掘问题更简单的问题，在试图解决简单问题时，其中一个问题将最终解决区块挖掘问题(每个挖掘预言机都是奖品——能有效集中精力，并收到爱丽丝希望最终获得的挖掘费的一部分)。

参与方提交出资事务，以打开PoW支付通道。

支付通道的目标是实现：

一旦打开支付通道，两个预言机都会得到缺少随机数的区块头。他们对随机数进行迭代，并试图找到能生成难度较小的哈希值的随机数。

假设奥利维亚首先找到一个。她向爱丽丝提交事务：

爱丽丝检查随机数是否生成难度较小的哈希值。如果是这样的话，则她签署事务，然后转给奥利维亚和奥斯卡。需要注意的是，爱丽丝也可实现执行所有验证的预言机。

在这种情况下，功能单元F()用于基于所确定的随机数来确定爱丽丝与挖掘预言机之间数字资产的新分配。所确定的随机数是上述术语中的参数ω_i，从功能单元F()的外部确定。

在一个实施方式中，唯一的输入值是数字资产值v_i，该数字资产值根据先前的数字资产值v_i-1进行计算。

在另一个实施方式中，爱丽丝负责正确地结算数字资产值(预言机可在签名前进行验证)。此时，功能单元没有输入值φ_i，只有参数ω_i。

假设奥斯卡找到下一个。他更新事务并将其提交给爱丽丝：

爱丽丝验证申请，并签署事务(如果属实)。

爱丽丝有责任确保奖励分配的正确性。如果爱丽丝单方面离开支付通道，则奥利维亚和奥斯卡都将发布最新事务，以领取奖励。如果奥斯卡单方面离开支付通道，则其他参与方有可能要求领取更新事务中奥斯卡的所有奖励。

该设计鼓励参与方在其有效使用期限内一直留在支付通道中。当奖励用完、锁定时间即将到期或发现生成足够小的哈希值的随机数时，可以关闭支付通道。

应当理解的是，上述实施例仅通过示例的方式进行描述。

更通俗地说，可以根据下述任何一个或更多个语句提供一种方法、装置或程序。

语句1、本公开的第一方面提供一种建立区块链支付通道的计算机实现的方法，其基于在多方之间交换的一系列花费事务，其中：出资事务，其被提交到区块链，其包括锁定到所述多方的至少两个公钥的至少一个可花费的事务输出，其中所述出资事务包含或以其它方式证明一函数，所述函数用于至少部分地计算所述一系列花费事务；所述一系列花费事务中的每个事务都有未来的锁定时间，在所述未来的锁定时间之前不能提交到所述区块链，并且包括：(i)至少一个事务输入，其包含指向所述出资事务的所述可花费的事务输出的指针，和(ii)至少两个可花费的事务输出，其具有相应的数字资产值；所述一系列花费事务中的初始事务具有最低序列号，所述一系列花费事务中每个后续事务的序列号均高于先前事务的序列号；其中所述方法包括由所述多方中的一方执行：在所述方的计算机设备上，接收所述一系列花费事务中的先前事务；使用所述出资事务中包含或以其它方式证明的所述函数来至少部分地计算所述当前事务；以及，使用与所述方的所述公钥对应的私钥来对所述当前事务的一部分进行加密签名，所述已签名部分包括所述至少两个可花费的事务输出，从而计算事务签名以包含在所述当前事务的所述事务输入中。

该动词“证明”在特定意义上指鉴于一段在事务中证明的实际代码或其它数据，可以验证实际数据(例如，代码)是否与事务证明的数据(例如，代码)相匹配。例如，事务可包括数据的加密哈希值或数据的其它唯一标识符。“加密哈希值”一词在广义上指通过应用一个或更多个加密哈希函数(例如，一段代码的单哈希或双/多重哈希、包含一段代码的哈希树的根哈希等)从一段数据(例如，一段代码)派生的任何哈希值。

下文自语句2起列出示例性实施例。

语句2、根据语句1所述的方法，其中所述函数至少应用于所述先前事务的所述数字资产值，以计算所述当前事务的所述数字资产值。

语句3、根据语句1或2所述的方法，其中所述一系列花费事务中的每个事务均包含一个或更多个输入值；

其中所述函数至少应用于所述先前事务中包含的所述一个或更多个输入值，以计算所述当前事务的所述一个或更多个输入值。

语句4、根据语句2和3所述的方法，其中所述函数至少应用于所述先前事务中包含的所述一个或更多个输入值，以计算所述当前事务的所述数字资产值和所述一个或更多个输入值。

语句5、根据语句1、2、3或4所述的方法，其中所述一系列花费事务中的每个事务均包含一个或更多个外部参数，所述一个或更多个外部参数不通过应用所述函数进行计算；

其中所述函数至少应用于所述先前事务中包含的所述一个或更多个外部参数，以至少部分地计算所述当前事务。

语句6、根据从属于语句3的语句5所述的方法，其中所述一系列花费事务中的每个事务包括所述一个或更多个输入值和所述一个或更多个外部参数，其中所述函数应用于所述先前事务中包含的所述一个或更多个输入值和所述一个或更多个外部参数。

语句7、根据前述任一项语句所述的方法，其中所述当前事务的所述数字资产值通过所述函数的所述应用进行计算。

语句8、根据前述任一项语句所述的方法，其中所述一系列花费事务中的最终事务用于计算结算事务，使用所述相同函数计算所述结算事务的至少两个可花费的事务输出的相应数字资产值，其中所述结算事务包括至少一个事务输入，所述至少一个事务输入包含指向所述出资事务的所述可花费的事务输出的指针，其中所述结算事务提交到所述区块链。

语句9、根据语句8所述的方法，其中所述结算事务包含或以其它方式证明应用所述函数的一个或更多个函数变量，以计算所述花费事务的所述数字资产值。

语句10、根据语句9所述的方法，其中所述结算事务包含所述一个或更多个函数变量的加密哈希值，从而证明所述一个或更多个函数变量。

语句11、根据语句10所述的方法，其中所述加密哈希值是证明所述一个或更多个函数变量的哈希树的根哈希。

语句12、根据前述任一项语句所述的方法，其中所述函数的所述应用为所述当前事务创建新数据字段，所述新数据字段与所述先前事务中包含的任何现有数据字段均不对应，所述当前事务包含所述新数据字段。

语句13、根据前述任一项语句所述的方法，其中所述函数的所述应用防止现有类型的数据字段从所述先前事务传播至所述当前事务，使得所述先前事务包含与所述当前事务中的任何数据字段均不对应的数据字段。

语句14、根据前述任一项语句所述的方法，其中所述出资事务的所述可花费的事务输出指定所述多方的m个公钥并锁定到所述m个公钥中的任何2≤n<m个公钥，应用所述函数的所述方是可信的预言机，由此所述多方中的任何其他n-1方可签署所述当前事务的一部分，以解锁所述出资事务的所述可花费的事务输出。

其中n＝2，“n-1方”指单一另一方。另一n-1方/其他方可以在可信的预言机之前、之后或同时签署当前事务的一部分。可信的预言机可以是各方的唯一可信的预言机，或其中两方或方可以是可信的预言机。

语句15、根据语句14所述的方法，其中所述可信的预言机在从所述多方中的另一方至少接收到所述当前事务的事务签名后签署所述当前事务，所述当前事务对于所述另一方的公众有效。

可信的预言机可将另一方的事务签名以及可信的预言机的签名添加到当前事务的事务输入中，或者可信的预言机可将签名发送到其它位置，以添加到当前事务中。或者，可信的预言机可向另一方或外部来源发送其事务签名，以便该另一方/外部来源添加到当前事务中。事务签名可以单独接收，也可与(例如)当前事务的完整副本，或者更通俗地说与当前事务的一个或更多个组件一起接收。

语句16、根据语句15所述的方法，其中所述可信的预言机使用所述出资事务来确定或验证拟应用的所述函数。

语句17、根据前述任一项语句所述的方法，其中所述出资事务包含或证明包含所述函数的一段可执行代码，所述函数通过在所述计算机设备的一个或更多个计算机处理器上执行所述一段代码来应用。

语句18、根据语句17所述方法，其中所述一段代码包含在以下内容中：

所述出资事务；或

所述区块链中记录的另一事务，在这种情况下，所述出资事务包含所述一段代码的标识符。

语句19、根据从属于语句16的语句18所述的方法，其中所述可信的预言机从所述区块链检索所述一段代码用于执行，从而确定拟应用的所述函数。

语句20、根据从属于语句16的语句18或19所述的方法，其中所述可信的预言机从链下来源接收所述一段代码，并且使用所述出资事务来验证所述接收的一段代码。

语句21、根据语句5或其任何从属语句所述的方法，其中所述当前事务的所述一个或更多个外部参数由所述多方中的另一方提供，而不是由应用所述函数的所述方提供。

语句22、根据语句21所述的方法，其中所述当前事务的所述一个或更多个外部参数包含在所述当前事务的所述已签名部分中，所述方在所述另一方已提供所述一个或更多个外部参数后签署所述当前事务。

语句23、根据语句3或其任何从属语句所述的方法，其中所述方还至少将所述相同函数应用于所述当前事务的所述一个或更多个输入值，以计算：(a’)下一事务的一个或更多个输入值，所述下一事务是所述一系列花费事务中所述当前事务之后的事务；以及(b’)所述下一事务的所述数字资产值。

语句24、根据语句5或其任何从属语句所述的方法，其中所述方至少将所述相同函数应用于所述当前事务的所述一个或更多个外部参数，以计算所述下一事务的所述数字资产值。

语句25、根据语句23或24所述的方法，其中所述方创建至少包含所述下一事务的所述数字资产值的所述下一事务，对所述下一事务的一部分进行加密签名，并且将所述下一事务和所述事务签名发送给所述多方中的另一方。

语句26、根据语句6或其任何从属语句所述的方法，其中：

所述一系列花费事务中每个事务的所述一个或更多个输入值表示游戏状态；

所述先前事务中的所述一个或更多个外部参数定义游戏的行动(game move)，所述先前事务中的所述一个或更多个外部参数由所述多方中的第二方确定；

其中所述函数用于更新所述先前事务的所述游戏状态，以实现所述先前事务的所述游戏的行动，所述更新的游戏状态由所述当前事务的所述一个或更多个输入值表示，由此响应于所述游戏的行动计算所述当前事务的所述数字资产值。

语句27、根据语句26所述的方法，其中所述当前事务被发送给所述多方中的第三方，以供所述第三方确定用于所述当前事务的所述一个或更多个外部参数，表示响应于所述第二方的游戏的行动的所述第三方的游戏的行动。

在一些此类实施例中，将函数用于更新游戏状态的一方是可信的预言机。函数捕获一组游戏规则，用于核实游戏的行动并更新响应于有效行动的游戏状态。当在区块链中提交/证明函数时，游戏规则可完全由区块链定义(或至少能够从区块链进行明确验证)。

语句28、根据前述任一项语句所述的方法，其中所述当前事务的所述一个或更多个输入值包含在所述当前事务的所述已签名部分中。

语句29、根据前述任一项语句所述的方法，其中所述方在所述先前事务已由所述多方中的至少两方签署后应用所述函数。

语句30、根据语句5或其任何从属语句所述的方法，其中所述先前事务的所述一个或更多个外部参数包括随机数值，其中所述函数用于：

将所述随机数值添加到部分数据集，从而确定包括所述随机数值的完整数据集；

对所述完整数据集应用哈希函数，从而计算哈希值；

确定所述哈希值是否满足定义的要求；

根据所述哈希值是否满足定义的要求，确定所述当前事务的所述数字资产值。

语句31、根据前述任一项语句所述的方法，其中所述一系列花费事务中的所述最终事务用于计算结算事务，方法是通过将所述相同函数应用于所述最终事务的一个或更多个函数变量来计算所述结算事务的至少两个可花费的事务输出的相应数字资产值，其中所述结算事务包括至少一个事务输入，所述事务输入包含指向所述出资事务的所述可花费的事务输出的指针，其中所述结算事务提交到所述区块链。

语句32、根据语句31所述的方法，其中所述结算事务具有可能的最大序列号。

在这种情况下，结算事务可能不一定具有未来的锁定时间，即可能不存在关于何时可提交结算事务的条件。结算事务也可能包含一个或更多个相同类型的函数变量，或者可能不包含任何此类函数变量(因为不需要计算进一步的事务，可能不需要此类函数变量)。

语句33、根据前述任一项语句所述的方法，其中在至少通过应用两个或更多个所需事务签名来最终确定所述先前事务之前，所述函数不会用于计算所述当前事务的所述数字资产值。

语句34、一种计算机设备，所述计算机设备包括一个或更多个计算机处理器，所述一个或更多个计算机处理器被配置为实现根据前述任一项语句所述的方法。

语句35、存储在一个或更多个暂时性或非暂时性计算机可读介质上的计算机程序指令，所述计算机程序指令用于对计算机设备进行编程，以执行根据语句1至33中任一项所述的步骤。

语句36、另一方面提供了一种记录在区块链中的出资事务，所述出资事务包含在一个或更多个暂时性或非暂时性计算机可读介质上，并且包括：

至少一个可花费的输出，其锁定到至少两个公钥；

其中所述出资事务包含或以其它方式证明一函数，所述函数用于根据一个或更多个函数变量来确定所述出资事务的所述至少一个可花费的输出所传递的数字资产数额在至少两方之间的分配。

语句37、根据语句36所述的出资事务，其中所述函数体现为所述出资事务中包含或以其它方式证明的一段代码，所述一段代码被配置为当在一个或更多个计算机处理器上执行时，根据所述一个或更多个函数变量来确定所述数字资产数额的所述分配。

语句38、根据语句37所述的出资事务，其中所述一段代码以所述出资事务遵循的区块链协议的脚本语言进行编码。

语句39、根据语句38所述的出资事务，其中所述一段代码以计算机编程语言进行编码，而不是以所述出资事务遵循的区块链协议的脚本语言进行编码。

语句40、根据前述任一项语句所述的出资事务，其中包含所述函数的加密哈希值，从而证明所述函数。

语句41、根据语句36至40中任一项所述的出资事务，其中所述可花费的输出指定所述多方的m个公钥并锁定到所述m个公钥中的任何2≤n<m个公钥。

语句42、根据语句36至41中任一项所述的出资事务，其中所述出资事务遵循区块链协议，但所述出资事务相对于所述区块链协议的有效性与所述函数无关，由此应用所述区块链协议的区块链节点将核实所述出资事务是否应用所述函数，但忽略结果，以核实所述出资事务。

语句43、另一方面提供了一种记录在区块链中的结算事务，所述结算事务包含在一个或更多个暂时性或非暂时性计算机可读介质上，并且包括：

1)至少一个输入，其包含：

指向出资事务的可花费的输出的指针，所述出资事务的所述可花费的输出锁定到至少两个公钥，和

至少两个事务签名，对于所述可花费的输出锁定的所述至少两个公钥中的不同公钥，每个事务签名均有效，用于解锁所述出资事务的所述可花费的输出；以及

2)至少两个可花费的输出，其具有相应数字资产值，所述数字资产值定义一分配，所述分配是在至少两方之间的分配，所述分配是数字资产数额的分配，所述数字资产数额是至少部分地由所述出资事务的所述可花费的输出传递的；

其中所述结算事务包含或以其它方式证明至少一个函数变量，用于应用所述出资事务中定义或以其它方式证明的函数来验证所述数字资产数额的分配。

语句44、根据语句43所述的结算事务，其中包含所述至少一个函数变量的加密哈希值，从而证明所述至少一个函数变量。

语句45、根据语句44所述的结算事务，其中所述加密哈希值是哈希树的根哈希，其中证明了所述至少一个函数变量。

语句46、一个区块链事务的群组，所述群组包括根据语句36至42中任一项所述的出资事务和根据语句43至44中任一项所述的结算事务。

根据本文公开的另一方面，可以提供一种包括第一方、第二方、可能涉及的任何第三方和节点网络的动作的方法。

根据在本文中所公开的另一方面，可以提供一种系统，所述系统包括第一方的计算机设备、第二方的计算机设备、任何第三方的计算机设备和节点网络。

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

Claims (46)

1.一种建立区块链支付通道的计算机实现的方法，其基于在多方之间交换的一系列花费事务，其中：

出资事务，其被提交到区块链，其包括锁定到所述多方的至少两个公钥的至少一个可花费的事务输出，其中所述出资事务包含或以其它方式证明一函数，所述函数用于至少部分地计算所述一系列花费事务；

所述一系列花费事务中的每个事务都有未来的锁定时间，在所述未来的锁定时间之前不能提交到所述区块链，并且包括：(i)至少一个事务输入，其包含指向所述出资事务的所述可花费的事务输出的指针，和(ii)至少两个可花费的事务输出，其具有相应的数字资产值；

所述一系列花费事务中的初始事务具有最低序列号，所述一系列花费事务中每个后续事务的序列号均高于先前事务的序列号；

其中所述方法包括由所述多方中的一方执行：

在所述方的计算机设备上，接收所述一系列花费事务中的先前事务；

使用所述出资事务中包含或以其它方式证明的所述函数来至少部分地计算所述当前事务；以及

使用与所述方的所述公钥对应的私钥来对所述当前事务的一部分进行加密签名，所述已签名部分包括所述至少两个可花费的事务输出，从而计算事务签名以包含在所述当前事务的所述事务输入中。

2.根据权利要求1所述的方法，其中所述函数至少应用于所述先前事务的所述数字资产值，以计算所述当前事务的所述数字资产值。

3.根据权利要求1或2所述的方法，其中所述一系列花费事务中的每个事务均包含一个或更多个输入值；

其中所述函数至少应用于所述先前事务中包含的所述一个或更多个输入值，以计算所述当前事务的所述一个或更多个输入值。

4.根据权利要求2和3所述的方法，其中所述函数至少应用于所述先前事务中包含的所述一个或更多个输入值，以计算所述当前事务的所述数字资产值和所述一个或更多个输入值。

5.根据权利要求1、2、3或4所述的方法，其中所述一系列花费事务中的每个事务均包含一个或更多个外部参数，所述一个或更多个外部参数不通过应用所述函数进行计算；

其中所述函数至少应用于所述先前事务中包含的所述一个或更多个外部参数，以至少部分地计算所述当前事务。

6.根据从属于权利要求3的权利要求5所述的方法，其中所述一系列花费事务中的每个事务包括所述一个或更多个输入值和所述一个或更多个外部参数，其中所述函数应用于所述先前事务中包含的所述一个或更多个输入值和所述一个或更多个外部参数。

7.根据前述任一项权利要求所述的方法，其中所述当前事务的所述数字资产值通过所述函数的所述应用进行计算。

8.根据前述任一项权利要求所述的方法，其中所述一系列花费事务中的最终事务用于计算结算事务，使用所述相同函数计算所述结算事务的至少两个可花费的事务输出的相应数字资产值，其中所述结算事务包括至少一个事务输入，所述至少一个事务输入包含指向所述出资事务的所述可花费的事务输出的指针，其中所述结算事务提交到所述区块链。

9.根据权利要求8所述的方法，其中所述结算事务包含或以其它方式证明应用所述函数的一个或更多个函数变量，以计算所述花费事务的所述数字资产值。

10.根据权利要求9所述的方法，其中所述结算事务包含所述一个或更多个函数变量的加密哈希值，从而证明所述一个或更多个函数变量。

11.根据权利要求10所述的方法，其中所述加密哈希值是证明所述一个或更多个函数变量的哈希树的根哈希。

12.根据前述任一项权利要求所述的方法，其中所述函数的所述应用为所述当前事务创建新数据字段，所述新数据字段与所述先前事务中包含的任何现有数据字段均不对应，所述当前事务包含所述新数据字段。

13.根据前述任一项权利要求所述的方法，其中所述函数的所述应用防止现有类型的数据字段从所述先前事务传播至所述当前事务，使得所述先前事务包含与所述当前事务中的任何数据字段均不对应的数据字段。

14.根据前述任一项权利要求所述的方法，其中所述出资事务的所述可花费的事务输出指定所述多方的m个公钥并锁定到所述m个公钥中的任何2≤n<m个公钥，应用所述函数的所述方是可信的预言机，由此所述多方中的任何其他n-1方可签署所述当前事务的一部分，以解锁所述出资事务的所述可花费的事务输出。

15.根据权利要求14所述的方法，其中所述可信的预言机在从所述多方中的另一方至少接收到所述当前事务的事务签名后签署所述当前事务，所述当前事务对于所述另一方的公众有效。

16.根据权利要求15所述的方法，其中所述可信的预言机使用所述出资事务来确定或验证拟应用的所述函数。

17.根据前述任一项权利要求所述的方法，其中所述出资事务包含或证明包含所述函数的一段可执行代码，所述函数通过在所述计算机设备的一个或更多个计算机处理器上执行所述一段代码来应用。

18.根据权利要求17所述的方法，其中所述一段代码包含在以下内容中：

所述出资事务；或

所述区块链中记录的另一事务，在这种情况下，所述出资事务包含所述一段代码的标识符。

19.根据从属于权利要求16的权利要求18所述的方法，其中所述可信的预言机从所述区块链检索所述一段代码用于执行，从而确定拟应用的所述函数。

20.根据从属于权利要求16的权利要求18或19所述的方法，其中所述可信的预言机从链下来源接收所述一段代码，并且使用所述出资事务来验证所述接收的一段代码。

21.根据权利要求5或其任何从属权利要求所述的方法，其中所述当前事务的所述一个或更多个外部参数由所述多方中的另一方提供，而不是由应用所述函数的所述方提供。

22.根据权利要求21所述的方法，其中所述当前事务的所述一个或更多个外部参数包含在所述当前事务的所述已签名部分中，所述方在所述另一方已提供所述一个或更多个外部参数后签署所述当前事务。

23.根据权利要求3或其任何从属权利要求所述的方法，其中所述方还至少将所述相同函数应用于所述当前事务的所述一个或更多个输入值，以计算：(a’)下一事务的一个或更多个输入值，所述下一事务是所述一系列花费事务中所述当前事务之后的事务；以及(b’)所述下一事务的所述数字资产值。

24.根据权利要求5或其任何从属权利要求所述的方法，其中所述方至少将所述相同函数应用于所述当前事务的所述一个或更多个外部参数，以计算所述下一事务的所述数字资产值。

25.根据权利要求23或24所述的方法，其中所述方创建至少包含所述下一事务的所述数字资产值的所述下一事务，对所述下一事务的一部分进行加密签名，并且将所述下一事务和所述事务签名发送给所述多方中的另一方。

26.根据权利要求6或其任何从属权利要求所述的方法，其中：

所述一系列花费事务中每个事务的所述一个或更多个输入值表示游戏状态；

所述先前事务中的所述一个或更多个外部参数定义游戏的行动，所述先前事务中的所述一个或更多个外部参数由所述多方中的第二方确定；

其中所述函数用于更新所述先前事务的所述游戏状态，以实现所述先前事务的所述游戏的行动，所述更新的游戏状态由所述当前事务的所述一个或更多个输入值表示，由此响应于所述游戏的行动计算所述当前事务的所述数字资产值。

27.根据权利要求26所述的方法，其中所述当前事务被发送给所述多方中的第三方，以供所述第三方确定用于所述当前事务的所述一个或更多个外部参数，表示响应于所述第二方的游戏的行动的所述第三方的游戏的行动。

28.根据前述任一项权利要求所述的方法，其中所述当前事务的所述一个或更多个输入值包含在所述当前事务的所述已签名部分中。

29.根据前述任一项权利要求所述的方法，其中所述方在所述先前事务已由所述多方中的至少两方签署后应用所述函数。

30.根据权利要求5或其任何从属权利要求所述的方法，其中所述先前事务的所述一个或更多个外部参数包括随机数值，其中所述函数用于：

将所述随机数值添加到部分数据集，从而确定包括所述随机数值的完整数据集；

对所述完整数据集应用哈希函数，从而计算哈希值；

确定所述哈希值是否满足定义的要求；

根据所述哈希值是否满足定义的要求，确定所述当前事务的所述数字资产值。

31.根据前述任一项权利要求所述的方法，其中所述一系列花费事务中的所述最终事务用于计算结算事务，方法是通过将所述相同函数应用于所述最终事务的一个或更多个函数变量来计算所述结算事务的至少两个可花费的事务输出的相应数字资产值，其中所述结算事务包括至少一个事务输入，所述事务输入包含指向所述出资事务的所述可花费的事务输出的指针，其中所述结算事务提交到所述区块链。

32.根据权利要求31所述的方法，其中所述结算事务具有可能的最大序列号。

33.根据前述任一项权利要求所述的方法，其中在至少通过应用两个或更多个所需事务签名来最终确定所述先前事务之前，所述函数不会用于计算所述当前事务的所述数字资产值。

34.一种计算机设备，所述计算机设备包括一个或更多个计算机处理器，所述一个或更多个计算机处理器被配置为实现根据前述任一项权利要求所述的方法。

35.存储在一个或更多个暂时性或非暂时性计算机可读介质上的计算机程序指令，所述计算机程序指令用于对计算机设备进行编程，以执行根据权利要求1至33中任一项所述的步骤。

36.一种记录在区块链中的出资事务，所述出资事务包含在一个或更多个暂时性或非暂时性计算机可读介质上，并且包括：

至少一个可花费的输出，其锁定到至少两个公钥；

其中所述出资事务包含或以其它方式证明一函数，所述函数用于根据一个或更多个函数变量来确定所述出资事务的所述至少一个可花费的输出所传递的数字资产数额在至少两方之间的分配。

37.根据权利要求36所述的出资事务，其中所述函数体现为所述出资事务中包含或以其它方式证明的一段代码，所述一段代码被配置为当在一个或更多个计算机处理器上执行时，根据所述一个或更多个函数变量来确定所述数字资产数额的所述分配。

38.根据权利要求37所述的出资事务，其中所述一段代码以所述出资事务遵循的区块链协议的脚本语言进行编码。

39.根据权利要求38所述的出资事务，其中所述一段代码以计算机编程语言进行编码，而不是以所述出资事务遵循的区块链协议的脚本语言进行编码。

40.根据前述任一项权利要求所述的出资事务，其中包含所述函数的加密哈希值，从而证明所述函数。

41.根据权利要求36至40中任一项所述的出资事务，其中所述可花费的输出指定所述多方的m个公钥并锁定到所述m个公钥中的任何2≤n<m个公钥。

42.根据权利要求36至41中任一项所述的出资事务，其中所述出资事务遵循区块链协议，但所述出资事务相对于所述区块链协议的有效性与所述函数无关，由此应用所述区块链协议的区块链节点将核实所述出资事务是否应用所述函数，但忽略结果，以核实所述出资事务。

43.一种记录在区块链中的结算事务，所述结算事务包含在一个或更多个暂时性或非暂时性计算机可读介质上，并且包括：

1)至少一个输入，其包含：

指向出资事务的可花费的输出的指针，所述出资事务的所述可花费的输出锁定到至少两个公钥，和

至少两个事务签名，对于所述可花费的输出锁定的所述至少两个公钥中的不同公钥，每个事务签名均有效，用于解锁所述出资事务的所述可花费的输出；以及

2)至少两个可花费的输出，其具有相应数字资产值，所述数字资产值定义一分配，所述分配是在至少两方之间的分配，所述分配是数字资产数额的分配，所述数字资产数额是至少部分地由所述出资事务的所述可花费的输出传递的；

其中所述结算事务包含或以其它方式证明至少一个函数变量，用于应用所述出资事务中定义或以其它方式证明的函数来验证所述数字资产数额的分配。

44.根据权利要求43所述的结算事务，其中包含所述至少一个函数变量的加密哈希值，从而证明所述至少一个函数变量。

45.根据权利要求44所述的结算事务，其中所述加密哈希值是哈希树的根哈希，其中证明了所述至少一个函数变量。

46.一个区块链事务的群组，所述群组包括根据权利要求36至42中任一项所述的出资事务和根据权利要求43至44中任一项所述的结算事务。

Images