CN113875190A - 包括基于哈希的验证的可运行代码的区块链交易 - Google Patents

Abstract

一种计算机实现的方法，所述方法包括在区块链网络的验证节点处：获取第一交易，所述第一交易包括可运行代码；接收第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的r部分的提交实例和s部分，并且所述信息还包括随机数；运行所述第一交易的所述代码。所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是所述r部分的所述提交实例，d是所述随机数，H_PoW是哈希函数，f是组合q和d的函数。

Description

包括基于哈希的验证的可运行代码的区块链交易

技术领域

本公开涉及实现在区块链上下文中的工作量证明(PoW)的想法。

背景技术

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

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

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

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

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

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

另一种交易模型是基于账户的模型。在这种情况下，每笔交易均不通过参考过去交易序列中先前交易的UTXO来定义转移的金额，而是通过参考绝对账户余额进行定义。所有账户的当前状态由矿工单独存储到区块链中，并不断更新。基于账户的模型的交易也能够包括智能合约，其运行在每个节点并同时核实交易有效。

在任一模型中，交易可以包括知识证明。“知识证明”是一个技术术语，指一方知道某些数据片段的任何测试，例如将其称为d。以基于输出的交易模型为例，一个交易Tx₁的输出中的锁定脚本可以包括哈希难题。如果第二交易Tx₂的输入指向Tx₁的该输出，则Tx₂的该输入中的解锁脚本将必须破解该哈希难题，以便成功地赎回Tx₁的输出。该哈希难题包括哈希值h，其是d的哈希值，即h＝H_puz(d)。该难题还包括一段脚本，当在节点处与Tx₂的解锁脚本一起运行时，该一段脚本将从Tx₂的解锁脚本中获取声称为d的数据值d’，使用哈希函数H_puz对该数据值进行哈希处理，并将其与Tx₁的锁定脚本中包括的哈希值h进行比较。即，如果比较结果为“YES”(或者在本领域术语中为“TRUE”)，则检查是否h＝H_puz(d′)，并将仅解锁Tx₁的输出。因此，如果d包括在Tx₂的解锁脚本中以证明d的知识，则Tx₂的受益人只能解锁Tx₁的输出。

单独使用传统哈希难题存在的问题在于，不择手段的矿工或其他节点可以在Tx₂的解锁脚本中观察到d，然后对Tx₂创建并挖掘(或发布)自己的

版本，在

的输出中向自己付款，而不是支付给如Tx₂中的预期接收者(例如，鲍勃)。避免这种情况的现有方法是在Tx₁的锁定脚本中附加地包括“支付到公钥哈希”(P2PKH)要求。除d的知识证明之外，这还需要将预期收款人的加密签名包括在Tx₂的解锁脚本中。

哈希难题和P2PKH也可以在基于账户的模型中使用智能合约来实现，而不是使用基于输出的模型的锁定脚本和解锁脚本。

如本领域技术人员所熟知的，加密签名可以基于私钥V来生成，并且可以基于私钥-公钥对中的对应的公钥P来验证。在给定通过将私钥V应用于消息m而生成的签名的情况下，另一方可以使用P来验证该签名是使用V生成的，而无需知道V(因此，验证签名本身是另一种知识证明)。

用于这种情况的一种算法是基于椭圆曲线加密算法(ECC)执行操作的椭圆曲线数字签名算法(ECDSA)。在这种情况下，P和V之间的关系如下：

P＝V·G

其中P是二元向量(P_x，P_y)，V是标量，G是二元向量(G_x，G_y)，该二元向量表示二维椭圆曲线上的预定点(“生成点”)。运算“·”是标量椭圆曲线乘法-一种已知运算形式，从椭圆曲线上的一点转换到另一点。

ECDSA签名是一种元组(r，s)，由本领域公知的两个元素，即分别为r部分(r)和s部分(s)组成。签名(r，s)是通过将私钥V应用于消息m而生成的。在将交易记录在区块链中的情况下，m将是交易的一部分，除明文中的这部分之外，签名也将被标记到交易上，以使交易核实有效。例如，在基于输出的模型中，签名对Tx₂的一部分进行签名，并包括在Tx₂的锁定脚本中，以便解锁Tx₁的输出。签名部分通常包括交易的输出，所以在不核实签名无效并因此不核实交易无效的情况下无法更改这些输出。

无论使用何种交易模型，签名(r，s)的计算方式如下：

r＝[R]_x，其中R＝k·G

s＝k^-1(H_sig(m)+rV)mod n

其中[R]_x表示二元向量R＝(R_x，R_y)的x坐标。k称为临时密钥，通常从集合[1，n-1]中随机选择，其中n是素数模，[1，n-1]是范围介于1到n-1(含)的实数集合。H_sig是哈希函数，与哈希难题中使用的哈希函数H_puz相比，该哈希函数可以是相同或不同形式的哈希函数。

在给定签名(r，s)、消息m和公钥P已知的情况下，任何不知道私钥V的一方都可以验证签名是使用消息m的私钥V生成的。这一点可以通过以下方式实现，即计算：

R′＝H_sig(m)s^-1·G+rs^-1·P

并且验证[R’]_x＝r。签名只有在结果为TRUE时才有效，否则无效。这可以视为以下验证，即与公钥P相关联的一方确实是消息的签名者。

发明内容

在区块链网络中，将交易挖掘到区块中所需的工作量证明是网络中每个挖掘节点应用的节点协议的固有特征。然而，本文认识到，可能需要添加附加的“第2层”工作量证明(即，置于基本节点协议的上层)。特别地，根据本公开，这可以通过基于ECDSA签名的r部分在Tx₁中设置挑战来实现，所述挑战是在本文中称为“r难题”的难题类型的变体。

根据在本文中所公开的一个方面，提供了一种计算机实现的方法，所述方法包括在区块链网络的验证节点处：获取第一交易，所述第一交易包括可运行代码；接收第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的r部分的提交实例和s部分，并且所述信息还包括随机数；运行所述第一交易的所述代码。所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是所述r部分的所述提交实例，d是所述随机数，H_PoW是哈希函数，f是组合r和d的函数。

在可选实施例中，在所述第一交易的所述代码中设置的所述r难题还可以包括要求所述第二交易包括所述r部分的指定值的挑战。因此，除工作量证明之外，所述r难题还可以用于实现基于所述签名的所述r部分的知识证明。

当结合P2PKH以避免背景技术中讨论的可能漏洞时，使用哈希难题作为知识证明存在问题，节点可以据此看到d并将其交换到向节点操作员而不是证明者支付的所述第二交易的新版本。虽然P2PKH确保仅向首先知道d的一方付款，但这也意味着Tx₁的输出与特定的预定接收者或接收者集合相关(可以指定可包括替代接收者的替代条件，但它们仍然必须预先标识)。

如本文所认识到的，可能期望允许可由任何未指定方赎回的交易，所述未指定方能够证明特定秘密值的知识，但以避免透露该值的方式。例如，假设爱丽丝想要建立第一交易，该交易可由她向其提供密钥的任何人解锁，但她不想预先指定这些方的身份。例如，第一交易可以向某人付款，让他代表爱丽丝接受诸如信件或包裹等物品的投递；和/或向快递公司付款，用以投递物品。第一交易可由证明知道秘密的第二交易赎回。在下单投递时，爱丽丝可以建立第一交易并将其提供给快递公司或将其发布到区块链(或者仅提供必要的详细信息，例如从而使快递公司能够创建第一交易)。因此，快递公司有信心在投递完成后付款。然而，爱丽丝不想在该阶段决定谁将代表她接收投递物品。相反，她仅在稍后将秘密值提供给一个或多个受信任方(例如，她的合租者查理和/或鲍勃，他们现在已经确认他们将在投递当天到场)。这将使他们中的任何一方能够通过提供证明爱丽丝的秘密值的第二交易来代表她签名。

应当理解的是，这仅仅是一个说明性示例。另一个示例是，可以通过使用交易来表示同意协议条款。爱丽丝可能想要立即订立协议，但仅在事实发生之后，才能决定一个或多个受信任方的子集，以授予代表她签名的签字人授权或授权委托书。例如，在订立协议时，爱丽丝可能一直打算自己签名，但后来才发现她正在丧失心智能力或由于某种原因无法签名，因此需要将授权委托书转让给其他人(例如，在这种情况下，鲍勃和查理可能是她的家庭成员或商业伙伴)。

更通俗地说，虽然对于主要的PoW思想来说不是本质的，也希望可以提供一种对传统哈希难题的替代方案。特别地，该难题的替代方案可以能够实现秘密值的知识证明，而无需向节点透露该值或将其发布在区块链上，并且该值与特定身份无关。

为了解决该问题，根据在本文中所公开的可选实施例，所述方法可以包括：获取公钥，其中所述第一ECDSA签名基于对应于所述公钥的私钥对消息进行签名，所述消息是所述第二交易的一部分；应用ECDSA验证函数以基于所述公钥和所述消息来验证在所述第二交易中接收的所述第一ECDSA签名，其中所述代码被配置为在所述第一ECDSA签名的所述验证的另一条件下返回所述TRUE结果。所述代码还可以包括对应于所述第一ECDSA签名的所述r部分的参考值，所述参考值是所述r部分的引用实例或其变换。在这种情况下，所述代码被配置为检查所述参考值是否对应于在所述第二交易中接收的所述r部分的所述引用实例，并在所述参考值对应于在所述第二交易中接收的所述r部分的所述引用实例的另一条件下返回所述TRUE值。

包括在所述第一交易的所述代码中的所述r部分的标示，可以是所述r部分的所述引用实例，或是其变换，例如，包括所述r部分的组件的哈希值(其中，例如，经过哈希处理的组件可以恰好等同于所述部分本身，或者可以与另一数据元素d级联)。

因此，无论以何种方式，该代码都会建立“r难题”，其证明被挑战者(例如，鲍勃)必须已经知道临时密钥k(在不知道k的情况下提供该解是不可行的)。该难题有利地使用r部分作为该知识证明的基础，并且不要求被挑战者向节点提交临时密钥k，也不要求在第二交易(例如，Tx₂)中透露该临时密钥。这意味着，例如，k可以由第一方(例如，爱丽丝)用作她可以用来向鲍勃和/或查理等的一个或多个第二方转让签字人授权的一种临时私钥或秘密。由于r难题证明知道k而无需透露k，因此恶意矿工或其他节点无法创建他/她自己的签名以形成将向他/她自己付款而不是预期受益人的有效第二交易

此外，由于签名的r部分本身与系统中的任何身份无关，因此这意味着知道k的任何人都可以满足证明要求。第二交易的有效条件不必通过第一交易与特定身份相关。因此，例如，爱丽丝不必事先决定将第一交易锁定给谁。例如，她可以向快递公司提供建立第一交易的详细信息，然后再决定向谁授予代表她接收包裹的签字人授权。

鉴于上述内容，更概括地说，本公开的范围可以扩展到任何“第2层”工作量证明，由此交易中的代码用于将附加的工作量证明难题置于矿工在区块链中已经执行的固有工作量证明的上层。

因此，根据在本文中所公开的另一方面，提供一种计算机实现的方法，所述方法包括在区块链网络的验证节点处：获取第一交易，所述第一交易包括可运行代码；接收第二交易，所述第二交易包含信息，所述信息至少包括第一部分和随机数；运行所述第一交易的所述代码，所述代码被配置为验证H_PoW(f(q，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中q是所述第一部分，d是所述随机数，H_PoW是哈希函数，f是组合r和d的函数。

附图说明

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

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

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

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

图4示出了一种用于根据基于输出的模型的节点协议来处理交易的节点软件的示意性框图；

图5示意性地示出了示例性交易集；

图6A至图6D示意性地示出了椭圆曲线数字签名算法(ECDSA)背后的一些原理；

图7是本文中称为r难题(或同义地称为r挑战)的一种知识证明的一种可能的实现方式的示意图；

图8是r难题的另一种可能的实现方式的示意图；

图9是r难题的另一种可能的实现方式的示意图；

图10是r难题的又一可能的实现方式的示意图；

图11是一种用于根据基于账户的模型的节点协议来处理交易的节点软件的示意性框图；

图12示意性地示出了ECDSA签名的示例性格式；

图13是针对一种形式的r难题的锁定脚本和解锁脚本的示例性实现方式的分步脚本分析；

图14A至图14D示意性地示出了一种r难题的一些示例，该r难题将附加的工作量证明强加在矿工已经完成的固有工作量证明之上作为底层区块链协议的一部分。

具体实施方式

在一些加密方案中，验证者可能需要确信某人(称为证明者或被挑战者)在所谓的知识证明中拥有一些信息。这可以简单地通过将该信息直接提供给验证者来实现。或者，可能需要证明者执行依赖于该信息的计算。优选地，所涉及的计算使得验证者他/她自己无需知道该信息即可设置挑战，也无需向验证者透露该信息即可验证证明者知道该信息。对于计算方法，必须对输入数据执行验证计算。由于加密哈希函数具有抗原像和抗冲突特性，因此证明秘密值知识的直接方法是使用加密哈希函数。这种哈希方法可以很容易地集成到许多区块链应用中，因为哈希函数可构成其私钥-公钥密码系统的基本部分。这种类型的知识证明广泛应用于区块链应用，通常称为哈希难题。

在基于UTXO的区块链中，哈希难题(经过哈希处理的值的原像)解可以设置为花费条件，因此由矿工执行验证作为交易验证的一部分。然而，在该方法中，交易还必须要求使用特定私钥的签名，否则矿工在将交易包括在区块内之前接收哈希难题解。这将使恶意矿工有机会创建花费交易，其输出指向属于该矿工的地址。

在本公开中，提供了一种知识证明，该知识证明可规避该问题，同时仍然允许由矿工(或转发节点)执行核实。为此，知识证明与对应于椭圆曲线数字签名算法(ECDSA)签名的临时密钥相关联。由于该算法中使用的密码原语是许多区块链原生的，因此可以很容易地集成到当前的基础设施中。

示例性系统概述

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

扮演消费用户角色的多方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运行软件400，其被配置为根据节点协议核实交易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₁有效。如果是存储节点104S，这意味着其将添加至等待工作量证明的交易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赎回的条件并不一定包括对签名进行认证。更通俗地说，脚本语言可用于定义任何一个或更多个条件。因此，可以优选更为通用的术语“锁定脚本”和“解锁脚本”。

可选的侧信道

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

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

节点软件

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

因此，脚本引擎402具有Tx_m-1的锁定脚本和来自Tx_m的相应输入的解锁脚本。例如，图4中示出的Tx₁和Tx₂，但同样可以应用于任何交易对，诸如Tx₀和Tx₁等。如前所述，脚本引擎402同时运行两个脚本，这将包括根据正在使用的基于堆栈的脚本语言(例如，脚本)将数据放置到堆栈403上并从该堆栈中检索数据。

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

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

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

示例性交易集

图5示出了根据在本文中所公开的实施例使用的交易集152。该交易集包括：第零交易Tx₀、第一交易Tx₁和第二交易Tx₂。应当注意的是，“第零”、“第一”和“第二”只是便利标签。它们并不一定意味着这些交易将立即相继放置在区块151或区块链150中，也不意味着第零交易是区块151或区块链150中的初始交易。这些标签不一定意味着任何关于他们的交易被发送到网络106的顺序的信息。他们仅指逻辑序列，其中下一交易的输入指向一个交易的输出。需记住的是，在一些系统中，可以在其子交易之后将父交易发送至网络106(在这种情况下，“孤立”子交易将在一个或多个节点104处缓冲一段时间，同时等待父交易到达)。

第零交易Tx₀还可称为就本发明而言的源交易，因为其充当锁定至爱丽丝103a的数字资产金额的来源。第一交易Tx₁还可称为就本发明而言的挑战交易或难题交易，充当根据第二交易Tx₂有条件地从源交易Tx₀转移数字资产金额的中介，从而提供r难题的解。第二交易Tx₂还可称为证明交易或花费交易，因为该交易将提供第一交易中Tx₁设置的r难题的解，并将所得到的付款锁定至证明者(或者证明者代表的潜在受益人)。实施例可以通过示例的方式进行描述，其中证明者(第二方)恰好是鲍勃，但根据稍后的讨论应当理解的是，r难题实际上允许任何第二方成为证明者，而不管其身份如何，只要他们提供破解r难题的有效签名。

如图5所示，源交易Tx₀包括至少一个输出203₀(例如，Tx₀的输出0)，其指定数字资产的金额，并且进一步包含将该输出锁定至爱丽丝103a的锁定脚本。这意味着源交易Tx₀的锁定脚本要求至少满足一种条件，即试图解锁输出(并且因此赎回数字资产的金额)的任何交易的输入必须在其解锁脚本中包含爱丽丝的加密签名(即使用爱丽丝的公钥)。在这种意义上，Tx₀的输出中定义的金额可以说是由爱丽丝拥有。该输出可以称为UTXO。就本发明而言，Tx₀的输入指向的先前交易的输出并不特别重要(只要足以涵盖Tx₀的总输出)。

在这种情况下，解锁源交易Tx₀的输出的交易是第一交易Tx₁(挑战交易)。因此，Tx₁具有至少一个输入202₁(例如，Tx₁的输入0)，该输入包括指向Tx₀的相关输出的指针(所示示例中Tx₀的输出0)，并且进一步包括被配置为根据该输出的锁定脚本中定义的条件解锁Tx₀所指向输出的解锁脚本，其至少要求爱丽丝的签名。Tx₀的锁定脚本所需的爱丽丝的签名需要对Tx₁的一部分进行签名。在一些协议中，Tx₁需要签名的部分可以是Tx₁的解锁脚本中定义的设置。例如，这可以通过SIGHASH标志设置，该标志附加至签名，为一个字节，因此就数据而言，解锁脚本显示为：<Sig P_A><sighashflag><P_A>。或者，需要签名的部分可以仅仅是Tx₁的固定部分或默认部分。无论采用哪种方式，拟签名的部分都通常不包括解锁脚本本身，并且可能不包括Tx₁的部分或全部输入。然而，Tx₁的签名部分将至少包括输出203₁，该输出包含r难题(见下文，在该示例中，Tx₁的输出0)。

第一交易Tx₁具有至少一个输出203₁(例如，Tx₁的输出0，输出也可称为UTXO)。第一交易Tx₁的输出未锁定至任何一方。就像Tx₀，其具有至少一个输出(例如，Tx₁的输出0)，指定随后拟转移的数字资产金额，并且进一步包括锁定脚本，该锁定脚本定义解锁输出并且因此赎回该金额的所需内容。然而，该锁定脚本允许由提供r难题解的任何一方解锁其输出。

第二交易(花费交易)Tx₂具有至少一个输入202₂(例如，Tx₂的输入0)，该输入包括指向Tx₁的前述输出(Tx₁的输出0，如示例所示)的指针，该输入还包括解锁脚本，该解锁脚本被配置为基于满足Tx₁的锁定脚本中定义的解锁条件的一个或多个要求解锁Tx₁的所述输出。根据在本文中所公开的实施例，解锁条件至少包括以下要求，即对应的解锁脚本包括r难题的解。r难题包括基于椭圆曲线加密算法(ECC)签名的r部分的Tx₁的锁定脚本中定义的挑战，该挑战可以由任何一方(在这种情况下恰巧是鲍勃)应对，包括他们在Tx₂的解锁脚本中的签名(或至少其s部分)。应当注意的是，与Tx₀的锁定脚本不同，任何一方的签名都可以用于解锁Tx₁中的锁定条件，只要它是应对r挑战(即r难题)的有效签名即可。稍后将更详细地讨论这方面的示例。在这里，仅选择鲍勃作为证明者或第二方的示例，但r难题实际上允许任何第二方作为证明者，例如查理、多拉、以西结等。在一些实施例中，Tx₁中的解锁条件还可以取决于一个或多个其他条件，例如还要求将爱丽丝的签名包括在Tx₂的解锁脚本中。

第二交易Tx₂具有至少一个输出202₂(例如，Tx₂的输出0)，该输出指定转移给鲍勃的数字资产金额和将此锁定至鲍勃的锁定脚本(即，要求进一步后续交易在要花费的解锁脚本中包括鲍勃的签名)。在这种意义上，目标交易Tx₂的输出可以说是由鲍勃拥有。该输出同样可以称为UTXO。

由证明者签名(例如，如果是鲍勃，则为Sig P_B)签名的Tx₂的部分将至少包括该输出203₂，即将付款锁定至证明者的输出(在该示例中，Tx₂的输出0)。

在实施例中，Tx₁的输出203₁中的锁定脚本可能定义用于解锁输出的多个替代条件，例如多个替代r难题。在这种情况下，如果满足替代解锁条件中的任何一个替代解锁条件，则Tx₂的输入202₂中的解锁脚本解锁Tx₁的输出。

第零交易(即源交易)Tx₀可以由爱丽丝、证明者(例如，鲍勃)或第三方生成，其通常需要先前方的签名，爱丽丝从该先前方获得Tx₀的输入中定义的金额。其可由爱丽丝、鲍勃、先前方或其他第三方发送至网络106。

第一交易(即挑战交易)Tx₁还可以由爱丽丝、证明者(例如，鲍勃)或第三方生成。因为在实施例中需要爱丽丝的签名，所以其可以由爱丽丝生成。或者，其可以由鲍勃或第三方生成作为模板，然后发送至爱丽丝进行签名，例如通过侧信道301发送。然后，爱丽丝可自己将已签名交易发送至网络106，或者将其发送至鲍勃或第三方以供他们转发至网络106，或者仅发送她的签名供鲍勃或第三方组装到已签名Tx₁并转发至网络106。在发送Tx₁至网络106之前的任何链下交换均可通过侧信道301执行。

第二交易(即证明交易或花费交易)Tx₂可以由爱丽丝、证明者(例如，鲍勃)或第三方生成。由于第一版本需要证明者的签名和/或数据，其可由鲍勃生成。或者，其可以由爱丽丝或第三方生成作为模板，然后发送至鲍勃进行签名，例如通过侧信道301发送至鲍勃。然后，鲍勃可自己将已签名交易发送至网络106，或者将其发送至爱丽丝或第三方以供他们转发至网络106，或者仅发送他的签名和供爱丽丝或第三方组装到已签名Tx₂并转发至网络。

应当理解的是，存在可以生成和组装交易的不同元素的多个位置，以及用于随后将其直接或间接地发送至P2P网络106的最终目的地的各种方法。所公开技术的实施方式的范围不限于这些方面中的任何一个。

还应当理解的是，本文中诸如“由爱丽丝”、“由鲍勃”和“由第三方”等词组可分别用作“由爱丽丝103a的计算机设备102a”、“由鲍勃103b的计算机设备102b”和“由第三方的计算机设备”的简略语。此外，需再次注意，给定方的设备可包括由该方使用的一个或多个用户设备、或者诸如该方使用的云资源等服务器资源，或这些的任何组合。这不一定限制在单个用户设备上执行的行为。

椭圆曲线数字签名算法(ECDSA)

在许多不同区块链架构中，公钥密码学用作保护交易的基础。公钥密码学的用途包括公钥加密和数字签名方案。公钥密码学建立在以下原理之上，即某些函数易于计算，但在不具备特殊知识的情况下难以求逆。此类函数称为陷门函数，而求逆此类函数所需的特殊知识称为该函数的陷门。易于计算意味着在合理的时间范围内计算给定输入(或一组输入)的陷门函数在计算上是可行的，而难以求逆意味着在不具备陷门知识的情况下从结果推断该输入(或那些输入)在计算上是不可行的。

在公钥密码学的上下文中，密钥对是指公钥(任何人都可以自由获得)和相应的私钥(假定为秘密，因为这仅对特定实体或组是已知的)。公钥可定义陷门函数，而对应的私钥是求逆该函数所需的陷门。

在公钥加密上下文中，加密基于陷门函数(即，沿“正向方向”执行加密)，而解密基于陷门函数求逆(即，沿“反向方向”执行解密)，这仅在陷门已知时可行。

在数字签名上下文中，使用公钥沿正向方向执行签名验证，而沿反向方向执行签名生成，并且只能使用私钥可行地执行签名生成。

在区块链上下文中，基于公钥密码学的数字签名用作对交易进行加密签名和验证交易签名的基础。

ECC是一种公钥密码学，利用椭圆曲线的数学特性，与DSA(数字安全算法)等其他加密方案相比具有各种优点。

椭圆曲线数字签名算法(ECDSA)是指一类数字签名方案，其使用ECC作为数字签名生成和验证基础。ECDSA的某些原理概述如下。

在数学术语中，ECC利用素数阶有限域上椭圆曲线的代数结构。有限域是指一个有限的元素集合和一组相关联的乘法、加法、减法和除法运算，当应用于该集合中的元素时，这些运算满足一般算术规则(关联性、交换性等)。也就是说，在“一般”意义上不需要加法、乘法等运算，但它们的行为本质上是相同的。

椭圆曲线运算：

在ECC的上下文中，加法、减法和乘法运算分别是椭圆曲线点加法(在本文中表示为“+”)、椭圆曲线点减法(在本文中表示为“-”)和椭圆曲线标量乘法(在本文中表示为“·”)。加法和减法运算分别应用于椭圆曲线上的两个点，并返回椭圆曲线上的第三个点；然而，乘法运算应用于椭圆曲线上的标量和单个点，并返回椭圆曲线上的第二个点。相反，除法是按标量定义的。

为了便于说明，图6A示出了

中的椭圆曲线ε，

是所有实值二维坐标的集合，

表示

的元素。椭圆曲线ε是满足以下等式的点的集合：

ε：y²＝x³+ax+b

加法：ε的数学特性在于，在给定椭圆曲线ε上的任意两个点A，B的情况下，A和B相交的线将仅与ε和一个附加点重新相交，表示为C；A和B的椭圆曲线加法，即A+B，定义为C的“反射”：取与C相交的水平线，C的反射是与该线相交的椭圆曲线上的另一点。该定义适用于A＝B的情况，修改后的C现在是ε的切线在A处与ε重新相交的点。通过将表示为∞的无穷远处的点定义为椭圆曲线上的点，并且任何垂直线在该点处与椭圆曲线相交(例如，标记为D和E的点垂直水平对齐，因此D+E＝∞)，使得该定义适用于与两点相交的线垂直的情况。

减法/加法逆运算：上述反射定义适用于任何点，并提供椭圆曲线点减法的定义：A-B是A与B的反射之和。B的反射更正式地称为B的“加法逆运算”，反过来表示为-B。使用该表示法，椭圆曲线减法可以用数学表示法定义为：

A-B＝A+(-B)。

因此，在图6B中，C＝-(A+B)和(A+B)＝-C。另请注意，在这个定义下，D＝-E，反映了代数结构的一般规则，即椭圆曲线上的任意点与其加法逆运算的椭圆点加法是无穷远处的点，即

无穷远处的点∞更正式地称为“单位元素”(请注意与一般算术的并行性和偏离：在一般算术中，任何数a与其加法逆运算-a的和为0，其中0是一般算术的单位元素)。单位元素∞的另一特性反映了一般算术，即对于包含∞本身的ε上的任意点A的A+∞＝A(类似于任何实数a的语句a+0＝0)

乘法：根据椭圆曲线点加法的定义，椭圆曲线标量乘法的定义如下：椭圆曲线点A与整数v的乘法定义为：

换句话说，作为v，椭圆曲线点A与它本身相加。

注意：椭圆曲线标量乘法在本领域中也称为椭圆曲线点乘法。这两个术语在本公开中具有相同的含义。

除法/乘法逆运算：关于标量定义除法运算：给定标量v，在标量v^-1处定义其“乘法逆运算”，使得：

vv^-1＝1。

图6A提供了上述运算的直观可视化，其中在包括所有实数

的无限域上定义ε。

图6B更精确地示出了上述运算在ECC上下文中的实际应用方式，因为它示出了由等式定义的椭圆曲线ε_n：

ε_n：y²＝x³+ax+bmod p

其中p是素数(素数模)，mod表示模运算。满足上述等式的点的集合是有限的，在图6B中，除一个点之外的所有点表示为白色圆圈；其余点是单位元素∞。

素数p构成椭圆曲线定义的一部分，可以自由选择。为了使椭圆曲线具有良好的加密特性，p应该足够大。例如，在某些区块链模型中指定256位p。

相比之下，下标“n”在本文中是指在上面定义的点加法下由椭圆曲线点形成的组的阶数(这可以简称为椭圆曲线ε_n的顺序)，参见下文。

换句话说，n是组的阶数，p是域的阶数。总共将有n个椭圆曲线点。椭圆曲线上的每个点由两个数字/坐标(x，y)表示，其中x和y都在范围-(p-1)，...0，...，(p-1)内。

可以看出，图6B中的ε_n表现出与图6A中的ε类似的水平对称，这是素数文件上椭圆曲线的一般特性，因此ε_n上点的加法逆运算的定义仍然适用。有些点没有水平对齐的对应点(例如，(0，0))，此类点是它们自己的加法逆运算。

与ε_n上两点A和B相交的“线”l_A，B成为有限的点集合，由较小的黑色圆圈表示，满足类似的几何要求，椭圆曲线标量乘法的定义仍然适用。与图6A类似，图6B示出了点A+B＝-C，该点是点C＝-(A+B)的加法逆运算，线l_A，B在该点处与ε_n重新相交。

ε_n上任意两个点的椭圆曲线加法A+B＝-C可以由以下等式进行代数定义：

A＝(x_A，y_A)，

B＝(x_B，y_B)，

C＝(x_C，y_C)＝-(A+B)，

x_C＝(λ²-x_A-x_B)mod p，

y_C＝(λ(x_C-x_A)+y_A)mod p，

＝(λ(x_C-x_B)+y_B)mod p，

其中

λ＝(y_A-y_B)(x_A-x_B)^-1mod p如果A≠B，

和

出于上述目的，将整数v的乘法逆运算v^-1的定义修改为：

v^-1v≡1(mod p)。

换句话说，整数v的乘法逆运算是v mod p的模逆。

B＝-A的情况是特殊的，通过引入单位元素∞来解决，正如前面提到的，在这种情况下，A+B＝A+(-A)＝∞。B＝∞的情况也是特殊的，如上文所述破解，即A+∞＝A。

椭圆曲线标量乘法的定义采用该椭圆曲线加法的定义，否则保持不变。

在其他上下文中，标量v的乘法逆运算v^-1的定义为：

v^-1v三1(mod n)

在上下文中，可以清楚地看到是否定义了关于mod n或mod p的乘法逆运算。

在实践中，要确定一个数字应视为mod n还是mod p，可以应用以下检查：

1.该数字是否表示EC点的坐标？

a.如果是，则应视为mod p

2.该数字是否用于乘以EC点？

a.如果是，则应视为mod n

应当注意的是，在某些情况下，两项检查都会给出肯定答案，在这种情况下，该数字必须是mod p和mod n。

椭圆曲线加密算法(ECC)

椭圆曲线算术提供了隐藏秘密值的独特功能，并构成了许多现代加密系统的基础。特别地，有限域上椭圆曲线点的标量乘法求逆是一个棘手的问题(在计算上是不可行的)。

私钥V采用整数形式，对应的公钥P是椭圆曲线ε_n上从“生成点”G推导出的点P，该点也是椭圆曲线ε_n上的一个点，如下所示：

其中“·”表示由a、b和n(椭圆曲线参数)定义的椭圆曲线ε_n上的椭圆曲线标量乘法。

对于足够大的V，实际执行V椭圆曲线加法推导P是困难的，即在计算上是不可行的。然而，如果V已知，则P可以通过利用椭圆曲线运算的代数特性来更有效地计算。可用于计算P的高效算法的一个示例是“双加”算法，重要的是，这只有在V已知的情况下才能实现。

相反，如果V未知，则即使G和P已知，也没有在计算上可行的方法来推导出V(即求逆标量乘法)(这就是所谓的“离散对数问题”)。攻击者可以尝试通过从G开始并重复执行椭圆曲线点加法对P进行“蛮力”计算直到达到P；此时，他将知道V是他必须执行的椭圆曲线点加法的次数；但事实证明，这在计算上是不可行的。因此，V在上述意义上满足了陷门的要求。

在ECC中，公钥P、生成器密钥G和椭圆曲线ε_n是公开的，并且假定是已知的，而私钥V是秘密的。

椭圆曲线数字签名验证算法(ECDSA)

在区块链系统中，用户或其他实体通常持有用于证明其身份的私钥V，相应的公钥P将通过以下等式计算：

P＝V·G

私钥V可用于使用ECDSA对数据m(“消息”)进行签名。

例如，可以在以下内容中找到ECDSA的更多信息，其全部内容以引入方式并入本文：“RFC 6979-数字签名算法(DSA)和椭圆曲线数字签名算法(ECDSA)的确定性使用”，Tools.ietf.org，2019年。

图6C示出了签名生成函数(签名生成器_600，其生成公钥-私钥对(V，P)的ECDSA签名(r，s))的示意性功能框图。EDSA签名是一对值，在本文中分别称为r部分(r)和s部分(s)。

签名生成基于用于推导出公钥P的相同椭圆曲线ε_n和生成点G，因此椭圆曲线参数a，b和n以及生成点G被示为签名生成器600的输入。

签名生成器600的临时密钥生成器602生成“临时”密钥k∈[1，n-1]，即范围介于1到n-1(含)。

r部分生成器604根据k计算对应的临时公钥，如下所示：

R＝k·G

然后取计算点的x坐标([]_x表示取椭圆曲线点的x坐标的过程)：

r＝[R]_x

这是签名的r部分。

s部分生成器606使用k mod n的模逆k^-1(即，k^-1k≡1(mod n)如上所述)和消息m的哈希值(表示为H(m)，必要时截断)计算签名的s部分(s)，如下所示：

s＝k^-1(H(m)+rV)mod n

在本示例中，消息m包括要包括在交易608中的数据(本示例中的一个或多个交易输出)。这可以称为对消息m进行签名的过程，并且该消息m可以称为交易的已签名部分。

消息m和签名(r，s)反过来构成交易608的一部分。在本示例中，签名(r，s)作为解锁脚本的一部分包括在交易608的输入中。

图6D示出了用于验证交易608的签名验证函数(签名验证器)620的示意性功能框图。由签名验证器620执行的计算基于相同的椭圆曲线ε_n和生成点G，如上所述，它们是公开的。

虽然签名需要私钥V作为输入，即需要知道私钥才能生成有效的签名，但核实签名(r，s)只需要签名对(r，s)、消息m和公钥P。为了验证签名，签名验证器620对交易m的已签名部分进行哈希处理(应用与用于生成签名(r，s)的哈希函数相同的哈希函数H)。然后使用以下计算执行验证过程：

R′＝H(m)s^-1·G+rs^-1·P

当且仅当[R′]_x＝r时签名才有效(即签名验证成功)，否则签名无效(即签名验证失败)。在本示例中，r表示包括在交易608中的签名的r部分。

例如，在签名验证过程中使用的公钥P可以在先前交易的锁定脚本中指定。在这种情况下，使用在先前交易的锁定脚本中指定的公钥以及(后续)交易608的已签名部分m和签名(r，s)来执行签名验证，并且除非已经基于对应于在先前交易中指定的公钥P和后续交易608的已签名部分m的私钥V生成签名(r，s)，否则该签名验证将失败。因此，只有持有私钥V的人才能声明先前交易的输出(通常通过将他们自己的公钥包括在后续交易608的输出中)，并且在不核实签名(r，s)无效的情况下无法更改后续交易608的已签名部分m。

r难题

下面介绍一种基于ECDSA的新知识证明。作为说明，挑战者是第一方爱丽丝，她通过自己创建并向P2P区块链网络106发布Tx₁，或者通过向第三方提供必要的详细信息以供他们组装到Tx₁中并发布，在第一交易Tx₁中设置r难题。验证者(实际运行证明的一方)是网络的节点104的操作者，例如矿工。通过向网络106发布Tx₂来提供r难题的解。证明者可以是任何第二方，因为r难题本身与身份无关，但是作为示例，下面可以按照证明者恰好是鲍勃的情况来描述。证明者可以自己创建和发布Tx₂，也可以向第三方提供将必要的详细信息以供他们组装到Tx₂中并发布。

加密哈希函数提供了一种确定性地隐藏输入的方法，其中输入中的微小变化会导致输出中的不可预测的变化。传统哈希函数包括MD5、RIPEMD-160、SHA-1和SHA-256[5]，其中每种哈希函数都具有抗冲突特性(找到产生相同输出的两个输入的可能性极小)和抗原像特性(在给定哈希值h＝H(d)的情况下，极难找到输入d)。

传统哈希难题可以如下设置。这种想法是建立第一交易Tx₁，该交易允许第二交易Tx₂在其输入中包括某些特定数据的条件下由第二交易Tx₂赎回其输出。

在区块链交易中，第一方(爱丽丝)可以简单地使用锁定脚本中的哈希值h创建非标准交易Tx₁，如下所示：

OP_HASH160<h>OP_EQUALVERIFY

其中h＝H_puz(d)和H_puz是难题中使用的哈希函数(在上面的示例中，根据锁定脚本，该哈希函数必须是HASH160，但在其他实现方式中可以使用另一形式的哈希函数)。要赎回包括该锁定脚本的UTXO，将需要后续交易的解锁脚本中的哈希难题解。因此，具有地址Addr_Bob的第二方的花费交易Tx₂将使用仅需包含d的解锁脚本来构建。

其中TxID_i是Tx_i的交易ID。锁定脚本表示：从Tx₂的输入中的解锁脚本中获取数据值d，对其进行哈希处理，并检查是否等于Tx₁的输出中的锁定脚本中包括的哈希值h。因此，通过在Tx₂的解锁脚本中提供d来解锁输出。

在本示例中，在看到具有Tx₂的哈希难题解的用户交易之后，第一个接收到该交易的矿工可能会恶意拒绝该交易，并创建一个具有相同哈希难题解的新的延展版本

但会将输出更改为他们自己的地址Addr_Miner。然后，恶意矿工可以尝试将

挖掘到他/她自己的区块151，并且如果他们在Tx₂被挖掘之前成功，则矿工而不是鲍勃将收到付款。

数字签名通常用于区块链交易，以证明所有权并赎回未花费的交易输出(UTXO)。这使Tx₁等交易的输出能够锁定至特定方。最常见的示例是支付到公钥哈希(P2PKH)交易，其中交易的输出锁定至公钥的特定哈希值(也充当该方的地址)。公钥P的锁定脚本为：

OP_DUP OP_HASH160<h_P>OP_EQUALVERIFY OP_CHECKSIG

其中h_P＝H_sig(P)和H_sig是签名中使用的哈希函数(在上面的示例中，根据锁定脚本，该哈希函数必须是HASH160，但在其他实现方式中可以使用另一形式的哈希函数)。为了能够将此UTXO用作另一交易的输入，必须使用P提供具有有效ECDSA签名的解锁脚本：

<sig><P>

整个字符串(解锁脚本+锁定脚本)由矿工评估，检查是否提供了正确的公钥，并且签名是否有效且对应于P。锁定脚本基本上表示：从Tx₂的输入中的解锁脚本中获取公钥P，对其进行哈希处理，并检查是否等于Tx₁的输出中的锁定脚本中包括的哈希值h_P；并且还使用基于的ECDSA验证函数的Tx₂的解锁脚本中的公钥P来验证签名sig，前提是具备Tx₂的已签名部分的知识。ECDSA验证函数由OP_CHECKSIG操作码调用。

因此，只能通过在Tx₂的解锁脚本中提供基于对应于P的私钥V签名的有效签名sig来解锁输出。

将这一点与哈希难题结合在一起，可以通过要求预期接收者的数字签名以及哈希难题解来纠正上述漏洞。锁定脚本将构建为：

OP_HASH160<h>OP_EQUALVERIFY OP_DUP OP_HASH160<h_P>OP_EQUALVERIFY OP_CHECKSIG

对应的解锁脚本必须为：

<sig><P><d>。

然而，这会限制谁能够将其赎回给公钥P的所有者。本文认识到，这在某些应用中可能不是所希望的，例如在爱丽丝希望仅在设置难题之后才保留指定签字人授权的能力的情况下。

本文认识到，可以通过利用ECDSA签名中的r部分来模拟哈希难题功能，该r部分可以是临时随机值。ECDSA签名由r和s两个主要部分组成。如上所述，r＝[k·G]_x。代替传统哈希难题h＝H(d)，逆椭圆曲线加法的难解性可形成类似难题，在本文中称为r难题。要破解该难题，需要获取解值k，其中k是对应于r的临时密钥。

对于传统哈希难题，在破解难题时，存在在区块链透露d的风险。然而，对于r-难题，从未透露k。相反，会透露r，可根据r和签名证明具备k的知识。

为了模拟哈希难题功能，r难题的创建者可以首先对一些其他原像数据进行哈希以获取值k，因为k必须是固定大小，而哈希难题的原像数据可以具有任何长度(并且哈希函数的一个特性是它会输出固定长度的值，而不管输入数据的长度如何)。例如，如果使用256位长的私钥/临时密钥，则应该对r难题的原像数据进行哈希处理以获取k。然而，也可以直接选择k的某个合适长度的值并将其直接用作秘密值(即，不需要从某个其他先前原像中推到出该秘密值)。

该方法可用于任何使用ECDSA签名进行花费的区块链系统。作为说明，下面将介绍基于UTXO的模型中的示例性实现方式。在脚本语言中，OP_CHECKSIG操作码需要堆栈上的签名和公钥(公钥位于堆栈的顶部，签名位于堆栈的正下方)。对于r难题，脚本被配置为检查所提供的签名中的r值与用于r难题挑战的值是否相同。换句话说，该脚本不仅将检查签名在公钥上是否有效(通过OP_CHECKSIG)，还将确保签名是使用r难题的r值创建的，该值将事先发布在区块链上。

现在参考图7至图10讨论r难题的一些示例性实现方式。在每种情况下，证明者(例如，鲍勃)都通过对Tx₂的一部分进行签名来创建签名(r，s)。这种形式的签名有时也可称为“sig”。在加密签名的上下文中，已签名部分也称为“消息”(m)。已签名部分(消息)m至少包括Tx₂的输出203₂，其将最终付款锁定至鲍勃。如果有多个输出，则m可以包括部分或全部输出。如果使用锁定时间，m也可以包括其他部分。然而，通常不包括解锁脚本本身(当然必须至少不包括签名本身)。要签名为消息m的Tx₂的部分可以由Sighash设置，也可以是协议的默认功能或固定功能。

图7示出了最简单的实现方式。Tx₁中的锁定脚本包括这里标记为r’的引用实例或r部分。在该方法中，Tx₂中的解锁脚本仅需至少包含鲍勃签名的s部分(s)。它还可以包括相应于鲍勃用于对m进行签名的私钥V的公钥P。Tx₁的锁定脚本被配置为当由节点104处的脚本引擎402运行时，从Tx₂的解锁脚本中获取s和P并执行以下操作：

I)R′＝H_sig(m)s^-1·G+r′S^-1·P，和

II)检查[R′]_x＝r′，

其中r’是从Tx₁的锁定脚本中获取的，s和m是从Tx₂的解锁脚本中获取的。鲍勃的公钥P也可以从解锁脚本Tx₂中获取，或者可以通过其他方式获知。H_sig是用于在生成第一ECDSA签名时对m进行哈希处理的哈希函数。它可以是任何形式的哈希函数。无论其采取何种形式，都可以假定该哈希函数的形式(类型)是预定的并且在两端都是已知的。G是一个固定的公知向量值。

锁定脚本被配置为在检查为TRUE的条件下返回“TRUE”结果，否则返回“FALSE”结果。在UTXO的情况下，运行锁定脚本和解锁脚本的TRUE(即成功)结果是交易有效的必要条件。因此，Tx₂的有效性可用作r难题结果的代理。或者换句话说，Tx₂的有效性取决于提供r难题的解。即，如果鲍勃没有通过r难题，则他的交易Tx₂将不会在网络106上传播，也不会记录在区块链150中(并且不会赎回在Tx₁的输出中定义的任何付款)。

虽然图7的示例在数学意义上可能是最简单的，但这并不一定意味着与任何给定的节点协议或脚本语言集成都是最简单的。如果花费者在解锁脚本中仅提供<s>和<P>，而不是<r，s>和<P>，则脚本必须考虑到这一点。操作I)-II)不是标准Checksig类型操作码的操作。OP_CHECKSIG操作码期望签名采用DER格式，因此如果解锁脚本中只提供了<s>值，那么锁定脚本中将需要一些额外的操作码(OP_CAT用于级联等)，以便生成DER格式的有效签名。图8简单地示出了替代示例，虽然在数学上涉及额外的步骤，但实际上更简单地集成了Script等脚本语言，这些脚本语言已经具有专用操作码，用于调用基于从Tx₂的输入中获取的r和s的ECDSA签名验证。

还应注意：在所有可能的实施例中不必将P包括在Tx₂中。事实上，根据对消息m和(r，s)(或在这种情况下，(r’，s))的了解，可以计算出公钥的两个可能的值P和-P(但不知道具体情况)。然后可以使用两个验证来标识哪一个是正确的，或者替代地，可以在Tx₂中包括一个位标志，以指示要使用两个可能的解中的哪一个。后一种方法目前在一些基于账户的协议中使用。然而，它倾向于不在当前基于UTXO的协议中使用，在这些协议中，脚本语言(例如，Script)没有用于根据(r，s)和m计算P和-P的运算操作码。然而，不应该排除可以引入一个操作码或者可以简单地将操作显式编码到锁定脚本中的可能性。另一种可能是，爱丽丝已经知道或已经访问P或通过侧信道301接收操作码。然而，这将需要单独查找才能将P映射到Tx₂。

图8中示出了另一示例性实现方式。在这里，r难题要求Tx₂的解锁脚本显式包括r部分的提交实例r。Tx₁的锁定脚本包括对r部分的测试，该测试包括要与提交实例r进行比较的r部分的引用实例r’。在此方法中，Tx₂中的解锁脚本必须至少包含鲍勃签名的r部分(r)和s部分(s)。它还可以包括相应于鲍勃用于对m进行签名的私钥V的公钥P。Tx₁的锁定脚本被配置为当由节点104处的脚本引擎402运行时，从Tx₂的解锁脚本中获取r、s和P并执行以下操作：

I)检查r′＝r，

II)计算R′＝H_sig(m)s^-1·G+rs^-1·P，

III)检查[R′]_x＝r，

其中r’是从Tx₁的锁定脚本中获取的，s、r和m是从Tx₂的解锁脚本中获取的。鲍勃的公钥P也可以从解锁脚本Tx₂获取，或者可以通过其他方式获知，例如如前所述从(r，s)和m或(r，s)和m推导出。

锁定脚本被配置为在步骤I)和III)中的检查均为TRUE的条件下返回结果“TRUE”，否则返回结果“FALSE”。同样，在基于UTXO的情况下，这使得能够根据r难题知识证明的结果来确定交易的有效性。应当注意的是，数字I-III不一定表示顺序。检查I)可以在II)-III)之前或之后执行，III)确实必须在II)之后执行。

在图8的方法中，步骤II)和III)单独是由ECDSA验证函数执行的常规操作。因此，在大多数协议中，它们可以由专用操作码调用，例如脚本中现有的Checksig操作码(OP_CHECKSIG)。步骤I)可以使用通用操作码单独编码到锁定脚本中(稍后给出示例)。也不排除步骤II)和III)原则上可以使用通用操作码而不是使用Checksig等专用操作码来显式编码。

在一个示例性交易协议中，交易ECDSA签名使用ASN.1(抽象语法表示法一)DER(可区别编码规则)编码格式，如图12所示。第一字节字段包含标志0x30，表示ASN.1序列号。第二字节字段包含以十六进制表示的序列长度。第三字节字段包含标志0x02，表示ASN.1整数。之后，ECDSA签名的r值包含在接下来的32或33字节中。字段应为32字节，但是，如果r的第一字节大于0x7f(第一位为1)，则在r值前面添加0的加法字节，使其长度为33字节。这是DER格式编码的结果，该编码将整数的第一位解释为符号。额外的零字节被添加到值的开头，这样它就不会被解释为负值。ECDSA签名的s值也是如此。最后，向DER编码添加一个字节字段，即哈希类型(ht)，该字段对应于交易中的比特币签名类型(SIGHASH_ALL、SIGHASH_NONE等)。

考虑爱丽丝(A)想要创建一个r难题交易的情况，在该交易中，任何获得该难题解的人都可以花费。为此，她将创建如下所示的新交易Tx₁。输入部分包括正在花费的先前交易Tx₀的解锁脚本。为简单起见，假设它是使用爱丽丝签名和公钥的标准P2PKH。输出部分包括锁定脚本(脚本公钥)，换句话说就是r难题挑战。如图12所示，签名可能在某些协议中使用DER编码格式，因此脚本必须从已编码签名中提取r的值，然后检查它是否等于<r>。之后，脚本必须检查公钥上的签名是否有效。图5示出了该脚本工作原理的更详细描述。粗体的操作码本质上只是从签名中提取r的一种方式。

下面示出了对应的解锁脚本，其中签名sig_r使用r，花费者鲍勃(B)可以使用任何私钥/公钥对计算签名。应当注意的是，sig_r是(r，s)。

<PB><sig_r>

图13示出了分步脚本分析。

临时密钥k可以由爱丽丝生成并提供给鲍勃(以及可选地一个或多个其他潜在证明者)。可选地，k可以由鲍勃生成并提供给爱丽丝，以设置只有鲍勃(或鲍勃选择与之共享k的任何人)才能破解的r难题。在任何一种情况下，证明者鲍勃都必须相信发送者爱丽丝不会自己花掉交易，因为她知道r难题的解(k)。为了防止出现这种情况，证明者鲍勃可以创建难题，然后将r值发送给爱丽丝，以便她在创建r难题交易时使用。之后，鲍勃可以在以后使用任何私钥/公钥对赎回输出，只要他保留值k，这就是r-难题的解，并且可以被视为密钥的一种形式。另一方面，在某些情况下，爱丽丝知道k这一事实可能是一个有利的特征。例如，这可以用来创建私钥难题，并通过该难题进行通用的原子交换。

图9通过与支付到公钥哈希(P2PKH)相类比，示出了r难题的另一示例，其在本文中可以称为“支付到r难题哈希”(P2RPH)。为了提高安全性和私密性，r值可以在放置到Tx₁中之前进行哈希处理(其将通过网络106的节点104传播并被放置在区块链150上)。与P2PKH类似，区块链上只有公钥的哈希值，而不是公钥本身，r难题也是如此。

在这里，r难题再次要求Tx₂的解锁脚本包括r部分的提交实例r。Tx₁的锁定脚本再次包括对r部分的测试，但这一次是以r′哈希值形式的r部分的压缩实例的形式，即h＝H(r’)。这将与提交实例r进行比较。在此方法中，Tx₂中的解锁脚本同样必须至少包含鲍勃签名的r部分(r)和s部分(s)。它还可以包括相应于鲍勃用于对m进行签名的私钥V的公钥P。Tx₁的锁定脚本被配置为当由节点104处的脚本引擎402运行时，从Tx₂的解锁脚本中获取r、s和P并执行以下操作：

I)检查h＝H_puz(r)，

II)计算R′＝H_sig(m)s^-1·G+rs^-1·P，

III)检查[R′]_x＝r，

其中h是从Tx₁的锁定脚本中获取的，s、r和m是从Tx₂的解锁脚本中获取的。哈希值h＝H_puz(r)，其中H_puz是在r的哈希难题中使用的哈希函数。它可以是任何形式的哈希函数。它可以是H_sig的相同或不同形式的哈希函数。无论采取何种形式，都可以假定H_puz的形式是预定的并且在两端都是已知的。鲍勃的公钥P也可以从解锁脚本Tx₂获取，或者可以通过其他方式获知，例如如前所述从(r，s)和m或(r，s)和m推导出。

锁定脚本被配置为在步骤I)和III)中的检查均为TRUE的条件下返回结果“TRUE”，否则返回结果“FALSE”。检查I)可以在II)-III)之前或之后执行，III)确实必须在II)之后执行。

同样，与图8的情况一样，步骤II)和III)单独是由ECDSA验证函数执行的常规操作。因此，在大多数协议中，它们可以由专用操作码调用，例如脚本中现有的Checksig操作码(OP_CHECKSIG)。步骤I)可以使用通用操作码单独编码到锁定脚本中。

交易挑战Tx₁中的锁定脚本示例如下所示：

可以使用在发送者和接收者之间一致的任何类型的哈希函数。然而，为了与P2PKH标准保持一致，使用OP_HASH160、双重哈希SHA-256和RIPEMD-160。

下面示出了对应的解锁脚本(与先前部分相同)，其中签名sig_r使用r，花费者鲍勃(B)可以使用任何私钥/公钥对计算签名：

<P_B><sig_r>

因此，图9的示例与图8类似，不同之处在于它使用r部分的哈希值作为r难题的基础，而不是使用r的未变换实例。

应当注意的是，在上述任何一种情况下，都不排除Tx₁的解锁脚本可能会对“TRUE”结果施加额外标准。例如，锁定时间或附加签名要求。

上述任何一种技术的示例用例都作为一般知识挑战。考虑任何具有某个解k或可以哈希处理到k的解的挑战。然后，爱丽丝可以创建一个r难题，该难题与所述难题相耦合。即，她可以定义r＝[k·G]_x。

例如，爱丽丝是一名数学教授。她可以构建一个r难题交易Tx₁，其中潜在的k值是激励学生破解的数学问题的解。无论谁设计出解决方案，都可以使用该解来创建签名(r，s)，其中r将匹配锁定脚本中的值，因此，从而申请奖励。签名不仅提供了真实性，还充当了解的知识证明，而不会将解决方案透露给其他任何人。因此，r难题提供了一种安全机制来证明具备某些解或一般信息的知识，而不存在暴露风险。它优雅地重用解锁脚本中所需的签名，并允许找到解的任何人以隐私方式申请奖励，因为任何公钥P都可以使用。

该方案还可用作令牌或数字票证的形式。例如，活动组织者可以向参与者发放不同值的k作为数字票证。当参与者想要参加活动时，他们可以通过使用r难题来证明他们具备秘密令牌的知识。

作为另一示例用例，r难题可以用作签字人授权方案，其中一方可以将签名权委托给另一方。考虑r难题交易Tx₁，该交易只有在提供具有与锁定脚本匹配的r值的签名时才能解锁。这意味着只有知道k值(其中，[k·G]_x＝r)的人才能生成此类签名。然而，如果此人将k的知识传递给其他人，那么这实际上是授权其他人代表他或她签名。

例如，假设爱丽丝想要接收投递物品，但她担心自己可能无法接收投递物品。她向鲍勃和查理提供一份k副本，以便他们可以代表她接收投递物品。如果戴夫(Dave)正在投递包裹，她必须获取带有预期r值的签名，才能将包裹提供给鲍勃。

在这样的场景中，可以将k视为充当临时私钥，将r视为充当临时公钥；它们分别类似于V和P，不同之处在于k和r与特定身份无关。

联合值r难题

作为图9的经过哈希处理的r难题(P2RPH)的扩展，可以在哈希处理之前包括与r级联的额外值d(以获取h＝H_puz(r||d))。在这种情况下，证明者(例如，鲍勃)不仅必须破解r难题，而且必须知道r。图10中示出了此方面的实施示例。

Tx₁的锁定脚本被配置为当由节点104处的脚本引擎402运行时，从Tx₂的解锁脚本中获取r、s，P和d并执行以下操作：

I)检查h_joint＝H_puz(r||d)，

II)计算R′＝H_sig(m)s^-1·G+rs^-1·P，

III)检查[R′]_x＝r，

其中r||d表示任意顺序(r在前或d在前)的r和d的级联。交易挑战Tx₁中的锁定脚本示例如下所示：

对应的解锁脚本如下所示(除包括d之外，与上一部分相同)。签名sig_rP_B使用r，证明者鲍勃(B)可以使用任何私钥/公钥对计算签名。

<sig′><P_B><d><sig_r>

额外的签名sig′是为提高安全性而附加的功能(请参见下文关于可选安全功能的部分)。然而，并非所有可能的实施例都必须如此。

一个示例用例是与CLTV相关的r难题。在这种情况下，数据值d可以是与CLTV(检查锁定时间验证)交易输出相关的时间值t。这样做的目的在于，在P2RPH哈希中隐藏输出之前不能花费的时间t，并使其与r难题相关。在这种情况下，证明者(例如，鲍勃)不仅必须破解r难题，而且还必须知道t并等到特定时间来花费它。交易中的锁定脚本示例如下所示：

下面示出了对应的解锁脚本，其中签名sig_rP_B使用r，花费者鲍勃(B)可以使用任何私钥/公钥对计算签名。

<sig′><P_B><t><sig_r>

额外的签名sig′是为提高安全性而附加的功能(请参见下文关于可选安全功能的部分)。然而，并非所有可能的实施例都必须如此。

以上是关于级联的描述。然而，也可以将其概括为某种函数f(r，d)。例如，f可以是r和d相加，例如实现为<r><d>OP_ADD。

r难题工作量证明

作为上述联合值难题的变体，在证明交易Tx₂中接收的值d可以用作一种工作量证明(PoW)难题的随机数值。花费者不仅必须解决所述r难题，而且还必须找到随机数值，所述随机数值会导致具有一定难度的哈希值目标。换句话说，以下等式的签入脚本，或者具有比目标更多的前导零的值。

H_puz(r||随机数)＜目标

注意：通常，给定的哈希函数可以是单个基本哈希函数，也可以是两个或多个组成哈希函数的组合。例如，在实施例中，H_puz＝H[H(...)]。在常见的区块链挖掘协议中，在所述工作量证明中对交易标头进行两次哈希处理。因此，为了模仿这一点，在本文中所公开的r难题PoW的实施例中，还可以对r||d进行两次哈希处理。然而，这是可选的，并且在其他实施例中，H_puz可以仅仅是单个哈希值。

优选地，该检查至少结合对Tx₂中接收的签名元组(r，s)执行的常规ECDSA签名验证，以便验证在工作量证明中使用的r值是否对应于签名。当锁定脚本和解锁脚本一起运行时，如果两项检查都得以满足，即所述随机数与r满足所述目标，并且所述签名经过验证，则仅输出“TRUE”结果。

在这种情况下，Tx₁的锁定脚本被配置为当由节点104处的脚本引擎402运行时，从Tx₂的解锁脚本中获取r、s，P和随机数并执行以下操作：

检查H_PoW(r||d)＜目标，

计算R′＝H_sig(m)s^-1·G+rs^-1·P，

检查[R′]_x＝r，

其中r||d表示任意顺序(r在前或d在前)的r和d的级联，d是随机数，如图14A所示。通常，H_PoW可以是H_sig和/或H_Pow的相同或不同形式的哈希函数。

交易Tx₁中的对应锁定脚本如下所示：

下面示出了对应的解锁脚本(与先前部分相同，但随机数和数据值d除外)，其中签名sig_rP_B使用r，花费者鲍勃(B)可以使用任何私钥/公钥对计算签名。

<sig′><P_B><nonce><sig_r>

额外的签名sig′是为提高安全性而附加的可选功能(请参见下文关于可选安全功能的部分)。然而，并非所有可能的实施例都必须如此。

应当注意的是，这里的随机数不同于固有的底层工作量证明中使用的随机数，因为该固有的底层工作量证明由挖掘节点对其交易池154执行以便根据所有节点104遵守的基本节点协议将交易挖掘到区块151中。因此，所公开的技术将证明者(例如，鲍勃)要执行的附加工作量证明置于在基本区块链协议的上层。为了赎回输出，鲍勃不仅必须知道k值，而且还必须执行一定的工作量证明以获得有效的随机数值。

一个示例性用例是，挑战者爱丽丝仅希望证明者(鲍勃)能够在一定时间(因为工作量证明会花费时间)之后接收在Tx₁的输出中定义的数字资产金额。这可以用作锁定时间的替代方案。

另一个示例是计算能力证明。爱丽丝想要确定谁具有最强的计算能力。为此，她创造了一个PoW r难题，无论谁最先解决该难题都会花费输出，并证明他们具有最强的哈希处理能力。在这种情况下，如果他们可以使用其公钥P或另一P₂将其身份与解联系起来，这也可能是有用的(请参见下一节)。然后，爱丽丝可以选择使用获胜者的一些其他服务，此类服务需要该计算能力。

通常，生成该解的r部分所需的k值可以由爱丽丝或第三方提供给证明者，也可以由证明者(或潜在证明者之一提供)给爱丽丝。例如，在计算能力证明示例中，爱丽丝或第三方可以将k分配给一个或多个潜在证明者，以使他们能够参与挑战。

应当注意的是，在上述示例锁定脚本中，锁定脚本不包括检查使用的r值。这对于验证工作量证明本身并不是必需的。

然而，可选地，在实施例中，解锁脚本将包括一些额外的代码(未示出)以检查使用的r值。例如，这可以通过结合上述PoW r难题与参考图7至图9描述的任何检查来实现。图14B示出了r难题工作量证明与图7中所示验证的组合。图14C示出了r难题工作量证明与图8中所示验证的组合。图14C示出了r难题工作量证明与图9中所示验证的组合。在这些情况下，当锁定脚本和解锁脚本一起运行时，如果所有检查都得以满足，则仅输出“TRUE”结果。应当注意的是，在本文中所使用的数字I)、III)和IV)并不意味着必须遵循检查的特定顺序，通常可以按照相对于彼此的任何顺序来执行检查。

在其他实施例中，锁定脚本中的r部分不具有参考值可能是有利的。这将允许任何人提供解，而不会被他人窃取。这种想法是，证明者可以选择k值，然后计算出r。然后，证明者检查所有可能的d值。如果此类值均不可用，证明者可以尝试不同的k。在找到r和d对之后，证明者可以构建签名，使r作为其r部分。

另一方面，锁定脚本中的固定r′(或r’的哈希值)将要求证明者首先解决r难题或被赋予k值，在这种情况下，这是不可取的。

以上是关于级联的描述。然而，在r难题工作量证明的任何版本中，也可以将其推广到某个函数f(r，d)。例如，f可以是r和d相加，例如实现为<r><d>OP_ADD。此外，f(r，d)要满足的条件不限于哈希值小于目标值或者至少具有预定数量的前导零。通常，任何条件都可以用于工作量证明，例如，f的哈希值大于目标值或在预定范围内。此外，类似的评论适用于证明者的公钥P，如上所述，即P可以在Tx₂中接收，或从r部分和s部分中推导出，或通过一些其他方式接收。

可选安全功能#1

如果发布了基于k的签名，则知道k的值的任何人都可以推导出用于创建签名的密钥V的值。这可以通过在下面的签名等式中破解V来实现。

s＝k^-1(H(m)+rV)mod n

求解V，可以得到：

V＝r^-1(sk-H(m))mod n

这不会带来重大风险，因为在许多情况下，交易的接收者是唯一知道k的人。在其他情况下，花费者必须小心，永远不要重复使用私钥V，该私钥用于对r难题的解进行签名。良好的安全实践表明，用户最好不要重复使用公钥/私钥对(P，V)，而是在收到新资金时始终使用新的公钥/私钥对。

原则上，公钥-私钥对(P，V)是“永久的”。换句话说，它可以使用许多次。随机临时密钥k的使用应确保这一点。然而，已经发生了随机数生成器实现不佳的事件。

如果使用相同的临时密钥k和相同的私钥对两个不同的消息进行签名，则可以从这两个签名推导出私钥V。即在给定(r，s)和k的情况下，可以算出V，其中r＝[k·G]_x和V是签名中使用的公钥P的私钥。如果随机数生成器在签名过程中失败，它可能会生成与上次相同的随机数，从而将私钥泄露给公众。为了解决这个问题，人们开始避免重复使用公钥，而不是修复随机数生成器。

在本示例中，如果爱丽丝知道k但她不知道鲍勃的公钥的私钥V。当爱丽丝将k传递给鲍勃时，鲍勃将能够通过使用其私钥提供(r，s)来破解这个难题。当爱丽丝看到签名时，由于她知道k，因此她将能够推导出V。这可能不是鲍勃所希望的。因此，鲍勃最好避免重复使用(P，V)。

但是，这样做存在的一个问题在于，鲍勃的公钥P不能用作标识鲍勃的持久方式。

为了解决这个问题，根据在本文中所公开的实施例，鲍勃可以使用具有对应公钥P₂的单独私钥V₂时在Tx₂中包括鲍勃的附加签名sig₂。他还包括P₂和额外的签名。因此，存在两种类型的公钥-私钥对。第一种类型是为一次性使用而动态生成的公钥-私钥对。另一种类型是根据一些额外协议(例如，HD钱包)生成的公钥-私钥对。鲍勃可以将第一种类型的密钥对用于r难题签名，并将第二种类型的密钥对用于第二签名。

然后，基于公钥与身份之间的映射，爱丽丝可以使用该另一公钥来查找鲍勃的身份，例如鲍勃的适当名称、用户名或网络地址。例如，该映射可以在将公钥映射到身份的公共数据库中可用，或者该映射可以简单地在爱丽丝与鲍勃之间预先约定(例如，私下存储在爱丽丝的计算机设备102a上)。

再次考虑签字人授权用例。例如，爱丽丝想要接收投递物品，但可能无法亲自接收投递物品。她向鲍勃和查理提供一份k副本，以便他们可以代表她接收投递物品。戴夫正在投递包裹，他必须获取带有预期r值的签名。现在，假设戴夫还需要验证接收者的身份，以满足其记录或法规要求。

假设鲍勃有接收投递物品的机会。如果鲍勃基于k生成其公钥和签名，则爱丽丝和查理都能够计算出鲍勃的私钥V。如果公钥仅供一次性使用，这就不是问题。然而，如果鲍勃将来需要该公钥来证明自己的身份，则不是理想的选择。

为了解决该问题，实施例可以在Tx₂中包括另一签名，该签名独立于可用于标识鲍勃的r难题。例如，可以将额外的签名和对应的公钥P₂添加到戴夫接受的同一交易中的OP_RETURN输出(不可花费的输出)。替代方案是在r难题交易的锁定脚本中包括额外的OP_CHECKSIG。通过浏览交易和用于额外签名的公钥，爱丽丝可以知道谁代表她签名。

在其他一些情况下，可能会担心值k在使用之前泄露。为了解决该问题，爱丽丝可以将P2PKH添加到r难题交易中以提高安全性。假设爱丽丝想将其签名权委托给鲍勃。爱丽丝从鲍勃那里获取一次性公钥k，并创建r难题交易，该交易不仅指定r值，而且还指定额外的公钥P₂。

为了使爱丽丝自己也能够签名，爱丽丝可以选择创建2取1的MultiSig。锁定脚本的示例如下：

应当注意的是，r难题提高了灵活性，因为爱丽丝可以选择何时将r难题的解(即签名权)传递给鲍勃。她可以决定是否继续，即使在交易被挖掘之后也是如此。

如果k泄露，则人们可以发现用于使用已泄露k进行签名的私钥。然而，还有另一私钥V₂：该私钥链接到可用于标识鲍勃的公钥的私钥。要使输出受到攻击，攻击者必须获取两个独立的秘密，这比仅泄露其中一个更加困难。

应当注意的是，在上述示例中，Tx₂的锁定脚本通过常规的P2PKH锁定至鲍勃的额外公钥P₂(通过额外的签名而不是r难题中使用的签名解锁)。r难题技术为用户提供了额外的选择。在一些应用中，可能需要使用r难题，以便允许证明者应对挑战，而不管身份如何。另一方面，在一些其他应用中，哈希难题和P2PKH的组合可能仍然是合乎需要的，并且r难题可以可选地与其结合使用。稍后将更详细地讨论这方面。

然而，如果对应于P₂的额外签名是查找身份和/或确保安全所需的，但是没有像在P2PKH中那样预先绑定到特定证明者的身份的Tx₁的锁定脚本，则可以相应地修改上述锁定脚本。换句话说，它只能在额外的签名上包含Checksig，而不能在对应的公钥P₂上包含OP_EQUALVERIFY。

可选安全功能#2

上述方法的另一潜在安全漏洞是签名可伪造性。这可能会被试图申领资金的矿工利用(类似于哈希难题)。(从花费者)收到交易的矿工可以更改交易以将资金发送给自己，同时使用与原始交易中使用的签名相同的签名。

具体操作如下：

将P＝V·G设为公钥/私钥对，用于对由m表示的原始交易进行签名，以获取签名(r，s)，使得：

r＝[k·G]_x，

s＝k^-1(H(m)+rV)mod n。

要花费该交易，花费者将使用以下解锁脚本：

<P><r，s>

收到该交易的矿工可以使用以下新解锁脚本将交易更改为新交易(由m’表示)，通过该新交易将资金发送给自己：

<P′><r，s>

其中P′＝V′·G是公钥/私钥对，使得：

V′＝V+r^-1[H(m)-H(m′)]，

P′＝P+r^-1[H(m)-H(m′)]·G。

应当注意的是，矿工不需要知道V′(因为他们不知道V)。使用以下计算完成验证过程：

R′＝H(m)s^-1·G+rs^-1·P

当且仅当(R′)_x＝r时签名才有效，否则签名无效。

对于新交易m’和新解锁脚本，验证过程如下：

R′＝H(m′)s^-1·G+rs^-1·P′

＝H(m′)s^-1·G+rs^-1·{P+r^-1[H(m)-H(m′)]·G}

＝rs^-1·P+H(m)s^-1·G

＝r

(应当注意的是，素数表示法在这里的含义与前面不同-在该上下文中，素数不指引用实例。)

为了解决该潜在漏洞，各实施例可以在另一消息m_sighash的解锁脚本中包括另一额外签名sig′，除非矿工知道密钥V，否则他们将无法提供该签名。在这种情况下，解锁脚本为：

<sig′><P><sig_r>

sig′可能是不同消息m_sighash上的签名，因此要更改消息，只需使用与原始消息不同的SIGHASH标志(例如，SIGHASH_NONE而不是默认标志SIGHASH_ALL)。此外，sig′必须使用r的不同值，以便它不会泄露私钥(因为私钥可以从使用相同临时密钥的两个签名推导出)。最后，交易需要在末尾包括另一OP_CHECKSIG，如下所示。

这必须使用与r难题相同的公钥P，以便只有知道公钥P的私钥V的人才能创建另一签名，因此上述攻击无法实现。

攻击者试图将公钥替换为攻击者不知道其私钥的另一公钥。为了防御该攻击，挑战还要求具备私钥的知识。在这种情况下，一个签名是不够的。因此，需要两个签名。这两个签名均被视为同一私钥的知识证明。这是安全的，因为挑战强调这两个签名将拥有不同的临时密钥。

P2PKH+P2PRPH

与将r难题用作知识证明的方式相同，P2PKH输出也是对应于P2PKH输出中的公钥的私钥的知识证明。这实际上是通过将难题k替换为映射到P2PKH输出中的公钥P_puzzle＝V_puzzle·G的私钥V_puzzle来实现的。在r难题的实施例中，知识证明随附公钥，该公钥可由证明者选择并可用于链接到身份。在P2PKH中，通常的花费签名和公钥(证明具备秘密难题的知识)必须随附另一签名和公钥才能链接到特定身份。通常，证明者可以向P2PKH解锁添加另一签名和公钥，该签名和公钥对应于锁定脚本的另一OP_CHECKSIG，如下所示。

对应的解锁脚本如下所示：

<sigP_ID><P_ID><sigP_puzzle><P_puzzle>

应当注意的是，<sigP_ID><P_ID>与难题甚至交易之间没有加密链接。实际上，矿工和任何人都可以用另一公钥上的另一签名替换它们，这种方式在一定程度上类似于矿工拦截未解决的哈希难题。矿工或拦截者无法更改消息以将资金发送给自己(与未解决的哈希难题一样)。然而，没有什么能够阻止他们将<sigP_ID><P_ID>替换为自己的身份，使其看起来与自己的身份相关联。

另一方面，基于在本文中所公开的技术，可以在同一脚本中同时使用P2PKH和P2RPH来强制第二签名上的加密链接，以免像上述情况那样被拦截和替换。

在锁定脚本中，P_puzzle＝V_puzzle·G，而r＝[R]_x＝[V_puzzle·G]_x，使得它们在本质上是等效的。它们实际上并不相等，因为公钥既可以压缩，也可以解压缩，而且无论哪种方式，都会在公钥前面加上前缀。还可以在从签名提取r值时显式地将前缀添加到脚本中，以获取<H(P_puzzle)>＝<H(r_puzzle)>，如下所示。然而，这并没有真正带来多少好处。

(应当注意的是，在锁定脚本的示意性表示中，H(...)用三角括号<>表示，实际上是指哈希值，而不是哈希函数。三角括号<>表示将该值放置在堆栈上。)

这两笔交易的对应解锁脚本如下所示：

<P_ID><r_puzzle，s><sigP_puzzle><P_puzzle>

基于账户的模型中的替代实现方式

上文在很大程度上是根据基于输出的模型(例如，基于UTXO的模型)中的实现方式来描述的。然而，应当理解的是，这不是限制性的。图11示出了使用基于账户的模型的一种可能的替代实现方式。

简而言之，在基于账户的模型中，r难题功能可以包括在由用户调用的智能合约函数中。一方可以在智能合约中设置r难题值(或经过哈希处理的r难题值)，然后另一方随后将签名提供给智能合约。

在UTXO区块链架构中，第一交易的解锁脚本中包含的要求必须由第二交易的锁定脚本来满足，以便第二交易被视为有效并记录在区块链中。在当前上下文中，这是有益的，因为它利用了矿工在交易核实过程中已经完成的工作。作为当前上下文中的具体示例，交易已添加到区块链这一事实意味着它已由整个区块链网络中的节点验证，而这又意味着其锁定脚本满足某些特定的有用要求。相关方不需要自己检查是否满足这些要求，他们可以根据交易已在区块链中成功重新编码这一事实简单地假设满足这些要求。这是因为脚本必须在完成时返回“TRUE”结果才能使交易有效(为了使交易有效可能还有其他要求)，并且如果脚本返回“FALSE”结果(根据在本文中所使用的术语，这包括脚本失败的情况，例如因为OP_VERIFY操作码终止脚本)，则交易无效。

然而，在其他区块链模型(例如，某些基于账户的架构)中，不一定会反映交易有效性与交易代码运行结果之间的这种相互依赖关系。例如，在某些智能合约区块链中，交易可能是有效的，因此可以用于记录在区块链上，前提是它们满足区块链协议强加的一组“基本”有效性要求。因此，即使第二交易不满足包含在第一交易的代码中的某些要求，第二交易仍然可能被视为有效并记录在区块链中。例如，第一交易的代码可以是智能合约代码。

假设第二交易是针对由第一交易创建的智能合约账户，则取决于智能合约代码来确定如何响应该交易，例如，如果不满足某些要求，则可以忽略(或者返回FALSE结果)，而如果满足该要求，则可以使用从智能合约账户的余额中扣除并贷记的数字资产金额来奖励证明者(或者以其他方式返回TRUE结果)。从某种意义上说，这将智能合约(代理)的“代理级”处理(即，在智能合约代码中显式编码)从节点“隐式”执行的“协议级”处理(即对交易执行的处理)中进行抽象化处理，以确定其是否满足区块链网络借以操作的区块链协议强加的有效性要求。因此，在此类区块链架构中，在各个交易中由协议级的节点作出的“有效/无效”决定可以与通过智能合约在代理级针对该交易返回的“TRUE/FALSE”结果分离，因为交易可以被确定为在协议级有效，但仍然在代理级返回FALSE结果。

这与UTXO架构相关，在UTXO架构中，需要返回“TRUE”结果的脚本才能使交易有效；如果脚本终止或完成，在堆栈上留下除TRUE以外的任何内容，则交易无效(如在本文中所使用的术语，这些结果中的任何一个结果都会构成“FALSE”的结果)。

交易有效的基本要求之一可以是交易包括有效签名。因此，尽管在上述UTXO示例中，签名由挑战交易本身的代码来验证(例如，使用已验证签名并针对签名验证返回TRUE/FALSE的OP_CHECKSIG操作码，或者使用以相同方式检查签名并且附加地验证结果为TRUE的OP_CHECKSIGVERIFY操作码，如果不是，则脚本终止)，在替代区块链架构中，签名可以在上述意义上由处理节点隐式验证，这可以避免需要在交易代码本身中对签名检查进行编码。

作为当前上下文中的具体示例，交易可以在协议级视为有效，例如因为它包括有效签名，但是仍在应用级返回FALSE结果，例如因为不满足某些其他要求。

图11示出了用于根据基于账户的模型来处理交易的节点软件400的替代方案，节点软件在此标记为400acc。该节点软件400acc的实例可以在网络106的基于账户的版本的每个节点104处实现。基于账户的节点软件400acc包括基于账户的协议引擎401acc、合约引擎402acc(在某种程度上类似于脚本引擎402)、应用级决策引擎404以及一个或多个区块链相关功能模块405的集合。在任何给定节点104处，这些模块可以包括以下三个模块中的任何一个、两个或全部：挖掘模块405M、转发模块405F和存储模块405S(取决于该节点的一个或多个角色)。协议引擎401acc被配置为识别交易的不同字段，并根据节点协议处理此类字段。节点软件400acc还在相应节点104的存储器中维护多个账户中的每个账户的账户状态406。这些账户可以例如包括爱丽丝、证明者(例如，鲍勃)和/或根据爱丽丝和证明者之间将要制定的合约而被借记或贷记的另一方的账户。合约引擎402acc被设置为根据在交易中接收的智能合约的结果来修改账户状态。智能合约也称为“代理”。

图11还示出了一对交易

和

它们可以实现如上所述关于图7至图10的相同或相似的r难题功能。每笔交易包括源账户地址1102(在源地址字段中)和目标账户地址1103(在目标地址字段中)。第一交易

包括源账户地址1102a和目标账户地址1103a。第二交易

包括源账户地址1102b和目标账户地址1103b。第一交易

还包括智能合约1101。智能合约1101可以包括爱丽丝的挑战(难题)。它可以由爱丽丝创建，也可以由代表爱丽丝的第三方使用爱丽丝提供的详细新创建。可选地，第二交易

可以包括用于携带用户指定的净荷数据的一个或多个自由数据字段1104。可以包括由证明者(例如，鲍勃)提供的难题的解的至少一部分。交易

和

还分别由爱丽丝和证明者签名。每笔交易还包括相应当事方的签名1105a、1105b。

交易在网络106上广播。当协议引擎401acc接收到每笔交易时，它会隐式地验证签名1105是否有效。即，这是协议引擎401acc的固有特征，不需要在智能合约1101中指定。因此，协议引擎401acc至少在相应签名有效的条件下核实用于转发和/或挖掘的每笔交易有效。它还可能需要一个或多个附加条件才能满足有效性要求。如果有效，则应用级决策引擎404可以选择是否控制挖掘模块405M和/或转发模块405F分别挖掘和/或转发交易。

在这种基于账户的模型中，爱丽丝、鲍勃和智能合约本身分配有不同的账户，具有不同的账户地址。交易被视为“从”其源地址字段中的地址发送“至”其目标地址字段中的地址。为了创建智能合约账户，将包含智能合约字节码的交易上载到交易中的区块链。对于此类账户创建交易，目标字段中的目标地址1103应为区块链中从未使用过的地址，并且一旦交易被接受，该地址就会成为新创建的智能合约账户的地址。此后，可以将另一交易发送到该地址，以便“调用”智能合约，即使智能合约的字节码能够根据该另一交易运行。“目标”地址1103充当用于制定合约的中介地址-爱丽丝将

发送到该地址以创建指定一个或多个要求的智能合约；鲍勃将

发送到同一地址以调用智能合约，转而使智能合约验词

是否满足那些指定要求。“源”地址1102指定作为合约当事方的用户的账户-在智能合约确定

确实满足指定要求的情况下，智能合约可以被配置为从其自身账户余额中扣除数字资产金额，并使得在

中具有源地址1102b的账户(即鲍勃的账户)余额以该金额(直观地，通过发送

鲍勃有效地请求智能合约(如在目标地址字段中标识的)贷记其账户(如在源地址字段中标识的)。

当协议引擎401acc接收到

时，在其有效的条件下，它将查找与

中的目标地址1103b匹配的账户。假设

已处理并有效，该账户将凭借

而存在，并将与TX₁中提供的智能合约代码相关联。作为响应，协议引擎401acc控制合约引擎402acc从

运行智能合约1101，根据合约中定义的标准，从智能合约的一个或多个字段获取数据作为操作数数据。操作数数据可以例如包括来自一个或多个自由数据字段1104的数据和/或来自签名字段1105b的签名。在

的操作数数据满足在

的智能合约1101中定义的一个或多个标准的条件下，合约引擎402acc根据在智能合约1101中定义的修改来修改一个或多个当事方(爱丽丝、证明者和/或一个或多个第三方)的账户状态406。否则，不对账户状态406进行该修改。然而，应当注意的是，在某些基于账户的系统中，智能合约的结果不是交易有效性的条件。因此，如果

未能满足在

的智能合约1101中设置的标准，则

仍将作为失败交易的记录被传播和挖掘到区块中。它还可以仍然影响挖掘费用(因此协议引擎401仍然可以修改当事方之一和获胜矿工的账户状态406)。

为了实现r难题，可以将r难题功能中的至少一些编码到

的智能合约1101中，并且可以在

的一个或多个数据字段1104中呈现解。例如，这可以用于实现图7的变体。可选地，可以利用协议引擎401acc的一些隐式签名验证功能，例如实现图8至图10的变体之一。在图8至图10的情况下，当协议引擎401acc验证

的签名时，步骤II)和步骤III)可以是协议引擎401acc的隐含功能(请谨记，签名验证本身是由协议引擎401acc实现的节点协议的固有特征)。因此，只需要在

的智能合约1101中将步骤I)置于这一点之上。智能合约检查I)的结果是否为TRUE以及协议引擎401ac是否指示

有效。如果两者都是肯定的，则声明验证的总体结果为“TRUE”，即鲍勃已经成功应对r难题设置的挑战。应对注意的是，在图8至图10的实现方式中，只有在图9和图10的情况下的数据值d需要包括在自由数据字段1104中。签名信息包括在签名字段1105b中。

智能合约账户还具有索引的“数据寄存器”(未示出)，它们是与账户相关联的(逻辑)数据存储元素。在上述UTXO模型中，值嵌入锁定脚本本身中，并且对于特定的智能合约代码1101也可能是如此。然而，智能合约的智能合约字节码可以替代地或附加地在存储在其一个或多个账户寄存器中的数据上运行。此外，通常可以在创建智能合约账户之后将值存储在智能合约账户寄存器中。因此，例如，可以通过包含智能合约字节码的挑战交易

来创建智能合约账户。然后，可以向(现在存在的)智能合约账户发送单独的“中间”交易

其作用是将特定值v存储在智能合约账户的寄存器$R中。智能合约可以被配置为仅接受来自指定的源账户地址(例如)的此类数据，例如，最初创建智能合约的同一方(爱丽丝)。当接收到

时，由合约引擎402acc执行的操作(例如，“访问寄存器$R，并将该值与

的数据字段$D中的值进行比较”)由挑战交易

中提供的智能合约字节码定义；但$R中存储的值已由中间交易

设置。根据在本文中所使用的术语，

仍然被视为设置一个或多个要求的挑战交易，只是现在可以引用在一个或多个中间交易(例如，

)中提供的数据来定义这些要求。

因此，在一些实现方式中，挑战交易

可以定义r难题的操作(例如，将证明交易

的签名的r部分与寄存器$R中的值进行比较，以查看它们是否匹配等)，但是$R中与证明交易

的r部分进行比较的值可能已经由中间交易

设置。

还请注意：一些基于账户的模型不需要将公钥P包括在签名1105中。相反，只需包括1位标志flg即可。如上所述，可以从(r，s)和消息推导出两个可能的密钥P和-P。标志flg用于指示这两种可能的解中的哪一种方案实际上是对应于证明者用于对

中的消息进行签名的私钥V的公钥。协议引擎401acc使用(r，s)和flg来推导出证明者的公钥P，而不是在

中显式地接收它。该技术在基于输出的模型中也是可能的，并且不特定于基于账户的模型，但是在许多当前基于输出的模型中使用的脚本语言中恰巧没有用于从r和s推导出P的专用操作码，因此使用基于堆栈的语言的现有通用操作码将此功能显式地编码到解锁脚本中将是复杂的。还应当注意的是，某些基于账户的模型从用于对该交易进行签名的公钥推导出该交易的源地址。因此，源地址不必在交易中单独编码，并且在公钥从签名推导出的情况下，这意味着源地址也可以间接从签名推导出。

结论

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

更概括地说，根据在本文中所公开的教导的第一实施例，提供了一种计算机实现的方法，所述方法包括在区块链网络的验证节点处：获取第一交易，所述第一交易包括可运行代码；接收第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的r部分的提交实例和s部分，并且所述信息还包括随机数；运行所述第一交易的所述代码。所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是所述r部分的所述提交实例，d是所述随机数，H_PoW是哈希函数，f是组合r和d的函数。

在实施例中，根据在本文中所公开的第二可选实施例，可以提供一种根据所述第一实施例所述的方法，其中：f是级联r||d。

根据本公开的第三可选实施例，可以提供一种根据所述第二实施例所述的方法，其中所述预定条件是H_puz(r||d)小于预定目标值或者至少具有预定最小数量的前导零。

根据本公开的第四可选实施例，可以提供一种根据所述第一、第二或第三实施例所述的方法，所述方法包括：获取公钥，其中所述第一ECDSA签名基于对应于所述公钥的私钥对消息进行签名，所述消息是所述第二交易的一部分；应用ECDSA验证函数以基于所述公钥和所述消息来验证在所述第二交易中接收的所述第一ECDSA签名，其中所述代码被配置为在所述第一ECDSA签名的所述验证的另一条件下返回所述TRUE结果。

在基于输出的模型(例如，基于UTXO的模型)中，所述ECDSA验证函数可以由所述第一交易的输出(例如，UTXO)的锁定脚本中的操作码调用。所述操作码可以调用预先存储在所述验证节点上的所述ECDSA验证函数的实例。或者，例如在基于账户的模型中，ECDSA验证函数可以是所述节点的隐式函数，该函数作为节点协议的一部分自动运行，而不需要由所述第一交易中的所述代码(在基于账户的情况下可以是智能合约)显式调用。作为另一替代方案，不排除可以将所述ECDSA验证显式编码到所述代码中。

根据第五可选实施例，可以提供一种根据所述第四实施例所述的方法，其中：所述代码还包括对应于所述第一ECDSA签名的所述r部分的参考值，所述参考值是所述r部分的引用实例或其变换；所述代码被配置为检查所述参考值是否对应于在所述第二交易中接收的所述r部分的所述引用实例，并在所述参考值对应于在所述第二交易中接收的所述r部分的所述引用实例的另一条件下返回所述TRUE值。

根据第六可选实施例，可以提供一种根据所述第五实施例所述的方法，其中：所述参考值是所述ECDSA签名的所述r部分的引用实例。

根据第七可选实施例，可以提供一种根据所述第六实施例所述的方法，其中所述代码被配置为执行以下操作：

检查H_PoW(f(r，d))是否满足所述预定条件，

所述ECDSA验证函数执行以下操作：

计算R′＝H_sig(m)s^-1·G+r′s^-1·P，

检查[R′]_x＝r′，

其中r′是所述第一ECDSA签名的所述r部分的所述引用实例，s是所述第一ECDSA签名的所述s部分，P是所述第一公钥，m是由所述第一ECDSA签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，G是椭圆生成点，[R′]_x表示R′的x坐标，“·”表示椭圆曲线标量乘法。在这种情况下，所述代码被配置为在所述两项检查均为TRUE的条件下返回所述TRUE结果，否则返回FALSE结果。

H_PoW是哈希难题中使用的哈希函数。H_sig是所述ECDSA签名和验证中使用的哈希函数。H_PoW和H_sig可以是也可以不是相同形式的哈希函数。

根据第八可选实施例，可以提供一种根据第六实施例所述的方法，其中所述代码被配置为执行以下操作：

检查H_PoW(f(r，d))满足预设条件，

检查r′＝r，

其中，所述ECDSA验证函数执行以下操作：

计算R′＝H_sig(m)s^-1·G+rs^-1·P，

检查[R′]_x＝r，

其中r是所述第一ECDSA签名的所述r部分的所述提交实例，r′是所述第一ECDSA签名的所述r部分的所述引用实例，s是所述第一ECDSA签名的所述s部分，P是所述第一公钥，m是由所述第一ECC签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，G是椭圆生成点，[R′]_x表示R′的x坐标，“·”表示椭圆曲线标量乘法。在这种情况下，所述代码被配置为在所有三项检查均为TRUE的条件下返回所述TRUE结果，否则返回所述FALSE结果。

根据第九可选实施例，可以提供一种根据所述第五实施例所述的方法，其中：所述参考值是所述第一ECDSA签名的所述r部分的引用实例的变换，所述代码被配置为通过以下方式执行所述检查所述提交实例是否对应于所述参考值：对所述提交实例执行相同的变换并与所述参考值进行比较。

根据第十可选实施例，可以提供一种根据所述第九实施例所述的方法，其中：所述参考值是哈希值，所述哈希值是所述第一ECDSA签名的所述r部分的所述引用实例的哈希值。

根据第十一可选实施例，可以提供一种根据第十实施例所述的方法，其中所述代码被配置为执行以下操作：

检查H_PoW(f(r，d))满足预设条件，

检查h＝H_puz(r)，

其中，所述ECDSA验证函数执行以下操作：

计算R′＝H_sig(m)s^-1·G+rs^-1·P，

检查[R′]_x＝r，

其中，r′是所述第一ECDSA签名的所述r部分的所述引用实例，r是所述第一ECDSA签名的所述r部分的所述提交实例，s是所述第一ECDSA签名的所述s部分，h是所述哈希值，H_puz是用于对r’进行哈希处理以生成h的所述哈希函数，P是所述第一公钥，m是由所述第一ECC签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，G是椭圆生成点，[R′]_x表示R′的x坐标，“·”表示椭圆曲线标量乘法。在这种情况下，所述代码被配置为在所有三项检查均为TRUE的条件下返回所述TRUE结果，否则返回FALSE结果。

H_puz是哈希难题中使用的哈希函数。H_puz可以是也可以不是与H_sig和/或H_PoW相同形式的哈希函数。

根据第十二可选实施例，可以提供一种所述第一至第十一实施例中任一个所述的方法，其中：所述获取所述第一公钥包括接收所述第一公钥作为所述第二交易中的所述信息的一部分。

或者，在所述第二交易中的所述信息包括所述第一ECDSA签名的所述s部分和所述r部分的提交实例，并且所述获取包括从所述第一ECDSA签名的所述s部分和所述r部分的提交实例的组合中推导出所述第一公钥。

作为另一替代方案，不排除所述获取可以包括：例如，通过与所述第二交易相关联的侧信道接收所述第一公钥；或者，在所述第二交易中或通过所述侧信道接收所述第一公钥的索引或所述第一公钥和私钥的所有者的身份，并使用其来查找所述第一公钥。

根据第十三可选实施例，可以提供一种根据第一至第十二实施例中任一个所述的方法，其中：所述第一ECDSA签名的所述r部分的所述提交实例和所述s部分由第二方使用以下各项生成：临时密钥，所述临时密钥由第一方提供给所述第二方，反之亦然；所述第一私钥，所述第一私钥是所述第二方的私钥；所述随机数也由所述第二方通过在所述第二方的计算机设备上执行工作量证明生成。

根据第十四可选实施例，可以提供一种根据所述第十三实施例所述的方法，其中：P＝V·G，k∈[1，n-1]，R＝k·G，r＝[R]_x，s＝k^-1(H_sig(m)+rV)mod n，其中P是所述第一公钥，V是所述第一私钥，k是所述临时密钥，G是椭圆生成点，n是素数模(所述生成点的素数阶)，m是由所述第一ECDSA签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，[R]_x表示R的x坐标，“·”表示椭圆曲线标量乘法。

根据第十五可选实施例，可以提供一种根据所述第十三或第十四实施例所述的方法，其中：所述接收所述第二交易包括从所述第二方接收所述第二交易。

根据第十六可选实施例，可以提供一种根据所述第十三至第十五实施例中任一个所述的方法，所述方法包括：在由所述代码返回的所述结果为TRUE的条件下为所述第一方触发服务。

例如，所述服务可能已由所述第一方委托，可以代表所述第一方执行，和/或可以为了所述第一方的利益而执行。所述服务可以是计算机化服务，并且所述触发可以包括自动触发所述服务。

通过将所述临时密钥提供给所述第二方(“鲍勃”)，这使所述第一方(“爱丽丝”)能够让鲍勃代表她对所述服务进行签名，而无需鲍勃向所述节点透露所述临时密钥k或将其发布在所述区块链上。此外，由于该过程不限于任何特定私钥(或其对应的公钥)，这意味着爱丽丝还可以将所述临时密钥的副本提供给第三方(“查理”)，然后鲍勃和查理中的任一方都可以成功地对所述服务进行签名。这是可能的，因为所述r部分用作挑战基础，并且所述r部分未映射到任何特定身份。

根据第十七可选实施例，可以提供一种根据所述第十三至第十六实施例中任一个所述的方法，其中：在所述第二交易中接收的所述信息包括所述第二方使用所述第二方的另一私钥对所述第二交易的一部分进行签名的另一加密签名，所述另一私钥对应于另一公钥。

所述另一签名可以是ECC签名或另一类型，例如RSA签名。

根据第十八可选实施例，可以提供一种根据所述第十七实施例所述的方法，其中：映射可用于使所述第一方和/或第三方能够基于所述另一公钥来查找所述第二方的身份。

例如，所述身份可以是所述第二方的个人姓名、公司名称、用户名或网络地址。例如，所述第三方可以是上述服务的提供商。

根据第十九可选实施例，可以提供一种根据所述第十七或第十八实施例所述的方法，其中：所述代码被配置为使用所述另一公钥验证所述另一加密签名，并在所述另一加密签名被验证的另一条件下返回所述TRUE结果。

根据第二十可选实施例，可以提供一种根据所述第十七至第十九实施例所述的方法，其中：在所述第二交易中接收的所述信息还包括所述第一方使用所述第一方的私钥对所述第二交易的一部分进行签名的加密签名。

在实施例中，所述方法可以包括获取对应于所述第一方的所述私钥的公钥，其中所述代码被配置为验证所述第二方的所述加密签名，并在所述第一方的所述加密签名被验证的另一条件下返回所述TRUE结果。

在实施例中，映射可用于使所述第二方和/或第三方能够基于所述第一方的所述公钥来查找所述第一方的身份。例如，所述第一方的所述身份可以是所述第一方的个人姓名、公司名称、用户名或网络地址。

根据第二十一可选实施例，可以提供一种根据所述第十三至第二十实施例中任一个所述的方法，其中：在所述第二交易中接收的所述信息包括附加的ECDSA签名，所述附加的ECDSA签名具有与所述第一ECDSA签名不同的值的所述r部分，但是使用与所述第一ECDSA签名相同的第一私钥；所述代码被配置为使用第一公钥验证所述附加的ECDSA签名，并在所述附加的ECDSA签名被验证的另一条件下返回所述TRUE结果。

在一些实施例中，所述附加的ECDSA签名可以对不同于所述第一ECDSA签名的所述第二交易的一部分进行签名。

根据第二十二可选实施例，可以提供一种根据所述第一至第二十一实施例中任一个所述的方法，其中：所述交易中的每笔交易包括数据结构，所述数据结构包括一个或多个输入和一个或多个输出，其中每个输出包括锁定脚本，每个输入包括解锁脚本和指向另一交易的输出的指针；其中所述代码包含所述第一交易的所述锁定脚本，其中在所述第二交易中接收的所述信息包含所述第二交易的输入中的所述解锁脚本，并且其中所述第二交易的所述输入中的所述指针指向所述第一交易的所述输出；并且，所述方法包括至少在所述代码返回所述TRUE结果的条件下核实所述交易有效，并且响应于所述核实，包括以下各项中的至少一项：将所述第二交易包括在交易池中，以便由所述验证节点挖掘到一个或多个区块中；和/或将所述第二交易转发到所述区块链网络的至少一个其他节点。

对于包括所述第一和第二交易的多笔交易中的每笔交易，所述网络的所述节点中的至少一些节点被配置为在所述交易有效的条件下传播每笔交易，并且所述网络的所述节点中的至少一些节点被配置为在所述交易有效的条件下将每笔交易记录在所述区块链的至少一部分的副本中。所述第二交易的有效性至少取决于返回所述TRUE结果的所述代码。

根据第二十三可选实施例，可以提供一种根据所述第一至第二十一实施例中任一个所述的方法，其中：所述交易根据基于账户的模型进行配置，所述代码包含包括在所述第一交易中的智能合约。

在实施例中，在任一模型中，所述验证节点可以是挖掘节点、转发节点和/或存储所述区块链的至少一部分的存储节点(例如，存储所述区块链的完整副本的完整副本存储节点)。在实施例中，所述获取所述第一交易可以包括从第一方(例如，上述第一方)接收所述第一交易的至少一部分。在实施例中，所述获取所述第一交易可以包括从所述第一方接收所述第一交易。或者，在实施例中，所述获取所述第一交易可以包括在所述验证节点处形成所述第一交易。在实施例中，所述获取所述第一交易可以包括至少从所述第一方接收所述r部分的所述引用实例，并在所述节点中的所述一个节点处形成所述第一交易。在实施例中，所述获取所述第一交易可以包括形成所述第一交易，包括在所述验证节点处生成所述r部分。

在实施例中，所述接收所述第二交易可以包括从第二方(例如，上述第二方)接收所述第二交易。在实施例中，所述第二交易至少部分由所述第二方生成。在实施例中，所述第二交易由所述第二方生成。在实施例中，所述接收所述第二交易可以包括直接或经由所述第一方或第三方从所述第二方接收所述第二交易。在实施例中，所述第二交易由第三方至少基于由所述第二方提供给所述第三方的所述第一ECDSA签名的所述s部分(以及在实施例中所述第一ECDSA签名的所述r部分的所述提交实例和/或所述数据元素)生成。

根据本文公开的教导的第二十四可选实施例，可以提供一种计算机程序，所述计算机程序包含在计算机可读存储器上，并且被配置为当在网络的节点上运行时，执行根据所述第一至第二十三实施例中任一个所述的方法。

根据本文公开的教导的第二十五可选实施例，提供了一种网络的节点，所述节点包括：存储器，所述存储器包括一个或多个存储单元；处置装置，所述处置装置包括一个或多个处理单元；其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上时，执行根据所述第一至第二十三实施例中任一个所述的方法。

根据第在本文中所公开的教导的二十六可选实施例，提供了一种计算机实现的方法，所述方法包括在第二方的计算机设备上：观察第一交易，所述第一交易包括可运行代码，所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是ECDSA签名的r部分，d是随机数，H_PoW是哈希函数，f是组合r和d的函数，所述r部分由第一方指定；基于临时密钥生成所述r部分；搜索所述随机数d的值，使得H_PoW(f(r，d))满足所述预定条件；形成与所述第一交易相关的第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的所述r部分和s部分，并且所述信息还包括所述随机数d；发送要通过区块链网络传播的所述第二交易以使其记录在区块链中。

在实施例中，在所述第二方的所述设备上执行的所述方法还可以包括对应于在本文中所公开的任何实施例或其他特征。

根据在本文中所公开的教导的第二十七实施例，提供了一种用于记录在区块链中的交易集，所述交易集包括包含在一个或多个计算机可读介质上的以下各项：第一交易，所述第一交易包括可运行代码；第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的r部分的提交实例和s部分，并且所述信息还包括随机数；其中所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是所述r部分的所述提交实例，d是所述随机数，H_PoW是哈希函数，f是组合r和d的函数。

在实施例中，所述第一实施例和所述第二实施例还可以根据在本文中所公开的任何实施例或其他特征进行配置。

根据在本文中所公开的教导的第二十八实施例，可以提供一种计算机实现的方法，所述方法包括在区块链网络的验证节点处：获取第一交易，所述第一交易包括可运行代码；接收第二交易，所述第二交易包含信息，所述信息至少包括第一部分和随机数；运行所述第一交易的所述代码，所述代码被配置为验证H_PoW(f(q，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中q是所述第一部分，d是所述随机数，H_PoW是哈希函数，f是组合q和d的函数。

在本文中所公开的与基于r难题的工作量证明相关的任何特征可以推广到任何此类“第2层”工作量证明。

所述第一部分q可以是数据的任何预定部分，也可以是所述第二交易的任何部分，所述随机数除外。

在实施例中，在本文中所公开的与r难题工作量证明(PoW)难题相关的任何特征还可以应用于该更一般的PoW难题。例如，在实施例中，f是级联q||d。在实施例中，所述预定条件可以是H_puz(q||d)小于预定目标值或者至少具有预定最小数量的前导零。

在实施例中，在所述第二交易中接收的所述信息还可以包括加密签名。所述方法可以包括：获取公钥，其中所述加密签名基于对应于所述公钥的私钥对消息进行签名，所述消息是所述第二交易的一部分。所述方法可以包括：应用验证函数以基于所述公钥和所述消息来验证在所述第二交易中接收的所述加密签名，其中所述代码被配置为在所述加密签名的所述验证的另一条件下返回所述TRUE结果。在实施例中，所述公钥可以映射到证明者的身份。这可以由第一方用于查找所述证明者的身份。

根据其他实施例，可以提供一种对应于所述第二十八实施例的程序、在第二方的设备上执行的方法或交易集。

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

Claims (27)

1.一种计算机实现的方法，所述方法包括在区块链网络的验证节点处：

获取第一交易，所述第一交易包括可运行代码；

接收第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的r部分的提交实例和s部分，并且所述信息还包括随机数；

运行所述第一交易的所述代码，所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是所述r部分的所述提交实例，d是所述随机数，H_PoW是哈希函数，f是组合r和d的函数。

2.根据权利要求1所述的方法，其中f是级联r||d。

3.根据权利要求1或2所述的方法，其中所述预定条件是H_puz(r||d)小于预定目标值或者至少具有预定最小数量的前导零。

4.根据权利要求1、2或3所述的方法，所述方法还包括：

获取公钥，其中所述第一ECDSA签名基于对应于所述公钥的私钥对消息进行签名，所述消息是所述第二交易的一部分；

应用ECDSA验证函数以基于所述公钥和所述消息来验证在所述第二交易中接收的所述第一ECDSA签名，其中所述代码被配置为在所述第一ECDSA签名的所述验证的另一条件下返回所述TRUE结果。

5.根据权利要求4所述的方法，其中所述代码还包括对应于所述第一ECDSA签名的所述r部分的参考值，所述参考值是所述r部分的引用实例或其变换；

所述代码被配置为检查所述参考值是否对应于在所述第二交易中接收的所述r部分的所述引用实例，并在所述参考值对应于在所述第二交易中接收的所述r部分的所述引用实例的另一条件下返回所述TRUE值。

6.根据权利要求5所述的方法，其中所述参考值是所述ECDSA签名的所述r部分的引用实例。

7.根据权利要求6所述的方法，其中所述代码被配置为执行以下操作：

检查H_PoW(f(r，d))是否满足所述预定条件，

所述ECDSA验证函数执行以下操作：

计算R′＝H_sig(m)s^-1·G+r′s^-1·P，

检查[R′]_x＝r′，

其中r′是所述第一ECDSA签名的所述r部分的所述引用实例，s是所述第一ECDSA签名的所述s部分，P是所述第一公钥，m是由所述第一ECDSA签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，G是椭圆生成点，[R′]_x表示R′的x坐标，“·”表示椭圆曲线标量乘法；

其中所述代码被配置为在所述两项检查均为TRUE的条件下返回所述TRUE结果，否则返回FALSE结果。

8.根据权利要求6所述的方法，其中所述代码被配置为执行以下操作：

检查H_PoW(f(r，d))是否满足所述预定条件，

检查r′＝r，

其中，所述ECDSA验证函数执行以下操作：

计算R′＝H_sig(m)s^-1·G+rs^-1·P，

检查[R′]_x＝r，

其中r是所述第一ECDSA签名的所述r部分的所述提交实例，r′是所述第一ECDSA签名的所述r部分的所述引用实例，s是所述第一ECDSA签名的所述s部分，P是所述第一公钥，m是由所述第一ECC签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，G是椭圆生成点，[R′]_x表示R′的x坐标，“·”表示椭圆曲线标量乘法；

其中所述代码被配置为在全部三项所述检查均为TRUE的条件下返回所述TRUE结果，否则返回所述FALSE结果。

9.根据权利要求5所述的方法，其中所述参考值是所述第一ECDSA签名的所述r部分的引用实例的变换，所述代码被配置为通过以下方式执行所述检查所述提交实例是否对应于所述参考值：对所述提交实例执行相同的变换并与所述参考值进行比较。

10.根据权利要求9所述的方法，其中所述参考值是哈希值，所述哈希值是所述第一ECDSA签名的所述r部分的所述引用实例的哈希值。

11.根据权利要求10所述的方法，其中所述代码被配置为执行以下操作：

检查H_PoW(f(r，d))是否满足所述预定条件，

检查h＝H_puz(r)，

其中，所述ECDSA验证函数执行以下操作：

计算R′＝H_sig(m)s^-1·G+rs^-1·P，

检查[R′]_x＝r，

其中r’是所述第一ECDSA签名的所述r部分的所述引用实例，r是所述第一ECDSA签名的所述r部分的所述提交实例，s是所述第一ECDSA签名的所述s部分，h是所述哈希值，H_puz是用于对r’进行哈希处理以生成h的所述哈希函数，P是所述第一公钥，m是由所述第一ECC签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，G是椭圆生成点，[R′]_x表示R′的x坐标，“·”表示椭圆曲线标量乘法；

其中所述代码被配置为在全部三项所述检查均为TRUE的条件下返回所述TRUE结果，否则返回FALSE结果。

12.根据权利要求4或从属于其的任意一项权利要求所述的方法，其中所述获取所述第一公钥包括接收所述第一公钥作为所述第二交易中的所述信息的一部分。

13.根据前述任一项权利要求所述的方法，其中所述第一ECDSA的所述r部分的所述提交实例和所述s部分由第二方使用以下各项生成：临时密钥，所述临时密钥由第一方提供给所述第二方，反之亦然；所述第一私钥，所述第一私钥是所述第二方的私钥；

所述随机数也由所述第二方通过在所述第二方的计算机设备上执行工作量证明生成。

14.根据权利要求13所述的方法，其中：

P＝V·G，

k∈[1，n-1]，

R＝k·G，

r＝[R]_x，且

s＝k^-1(H_sig(m)+rV)mod n，

其中P是所述第一公钥，V是所述第一私钥，k是所述临时密钥，n是素数模，G是椭圆生成点，m是由所述第一ECDSA签名进行签名的所述第二交易的所述部分，H_sig是在生成所述第一ECDSA签名时用于对m进行哈希处理的哈希函数，[R]_x表示R的x坐标，“·”表示椭圆曲线标量乘法。

15.根据权利要求13或14所述的方法，其中所述接收所述第二交易包括从所述第二方接收所述第二交易。

16.根据权利要求13至15中任一项所述的方法，所述方法包括在由所述代码返回的所述结果为TRUE的条件下为所述第一方触发服务。

17.根据权利要求13至16中任一项所述的方法，其中在所述第二交易中接收的所述信息包括所述第二方使用所述第二方的另一私钥对所述第二交易的一部分进行签名的另一加密签名，所述另一私钥对应于另一公钥。

18.根据权利要求17所述的方法，其中映射可用于使所述第一方和/或第三方能够基于所述另一公钥来查找所述第二方的身份。

19.根据权利要求17或18所述的方法，其中所述代码被配置为使用所述另一公钥验证所述另一加密签名，并在所述另一加密签名被验证的另一条件下返回所述TRUE结果。

20.根据权利要求17至19中任一项所述的方法，其中在所述第二交易中接收的所述信息还包括所述第一方使用所述第一方的私钥对所述第二交易的一部分进行签名的加密签名。

21.根据权利要求13至20任一项所述的方法，其中：

在所述第二交易中接收的所述信息包括附加的ECDSA签名，所述附加的ECDSA签名具有与所述第一ECDSA签名不同的值的所述r部分，但是使用与所述第一ECDSA签名相同的第一私钥；

所述代码被配置为使用第一公钥验证所述附加的ECDSA签名，并在所述附加的ECDSA签名被验证的另一条件下返回所述TRUE结果。

22.根据前述任一项权利要求所述的方法，其中所述交易中的每笔交易包括数据结构，所述数据结构包括一个或多个输入和一个或多个输出，其中每个输出包括锁定脚本，每个输入包括解锁脚本和指向另一交易的输出的指针；

其中所述代码包含所述第一交易的所述锁定脚本，其中在所述第二交易中接收的所述信息包含所述第二交易的输入中的所述解锁脚本，并且其中所述第二交易的所述输入中的所述指针指向所述第一交易的所述输出；

所述方法包括至少在所述代码返回所述TRUE结果的条件下核实所述交易有效，并且响应于所述核实，包括以下各项中的至少一项：

-将所述第二交易包括在交易池中，以便由所述验证节点挖掘到一个或多个区块中；和/或

-将所述第二交易转发到所述区块链网络的至少一个其他节点。

23.根据权利要求1至21中任一项所述的方法，其中所述交易根据基于账户的模型进行配置，所述代码包含包括在所述第一交易中的智能合约。

24.一种计算机程序，所述计算机程序包含在计算机可读存储器上，并且被配置为当在网络的节点上运行时，执行根据前述任一项权利要求所述的方法。

25.一种网络的节点，所述节点包括：

存储器，所述存储器包括一个或多个存储单元；

处置装置，所述处置装置包括一个或多个处理单元；

其中，所述存储器存储被设置为在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时执行根据权利要求1至23中任一项所述的方法。

26.一种计算机实现的方法，所述方法包括在第二方的计算机设备上：

观察第一交易，所述第一交易包括可运行代码，所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是ECDSA签名的r部分，d是随机数，H_PoW是哈希函数，f是组合r和d的函数，所述r部分由第一方指定；

基于临时密钥生成所述r部分；

搜索所述随机数d的值，使得H_PoW(f(r，d))满足所述预定条件；

形成与所述第一交易相关的第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的所述r部分和s部分，并且所述信息还包括所述随机数d；

发送要通过区块链网络传播的所述第二交易以使其记录在区块链中。

27.一种用于记录在区块链中的交易集，所述交易集包括包含在一个或多个计算机可读介质上的以下各项：

第一交易，所述第一交易包括可运行代码；

第二交易，所述第二交易包含信息，所述信息至少包括第一ECDSA签名的r部分的提交实例和s部分，并且所述信息还包括随机数；

其中所述代码被配置为验证H_PoW(f(r，d))是否满足所述代码中定义的预定条件，并在满足所述代码中定义的预定条件的条件下返回TRUE结果，其中r是所述r部分的所述提交实例，d是所述随机数，H_PoW是哈希函数，f是组合r和d的函数。

Images