CN113875188A - 哈希函数攻击 - Google Patents

Abstract

在区块链网络的节点接收至少一笔证明交易，并且包括至少一个椭圆曲线数字签名算法(ECDSA)签名和至少一个零知识证明(ZKP)组成部分。该节点基于与所述至少一笔证明交易的ECDSA签名和签名部分相关联的公钥来验证所述至少一笔证明交易的ECDSA签名，并确定ZKP组成部分对于ECDSA签名以及定义哈希值和定义哈希函数是否正确，因为该ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于定义哈希值相对于定义哈希函数的原像。

Description

哈希函数攻击

技术领域

本公开涉及一种零知识证明，这种零知识证明可用于证明是否存在哈希函数攻击成功而不披露攻击本身的细节。

背景技术

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

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

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

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

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

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

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

交易可能包括数字签名作为该交易附加身份的证据。如本领域技术人员所熟知的，加密签名可以基于私钥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是哈希函数。

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

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

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

加密哈希函数(例如上述H)构成了许多关键加密函数的基础。例如，加密哈希函数广泛应用于现今使用的许多加密和数字签名系统中。例如，在区块链环境中，这种哈希函数构成了用于生成和验证应用于交易的数字签名的过程的一部分，例如上文所述ECDSA的一部分。SHA-256是区块链系统中广泛使用的一种加密哈希函数的示例。加密哈希函数是一种单向函数，将任意大小的数据映射到固定长度的位串。哈希函数返回的位串称为“哈希值”(或等同于“图像”)，哈希函数为其返回给定哈希值的任何数据段称为该哈希值的原像(相对于所述哈希函数)。

单向意味着函数应该易于计算，但难于反向计算，其中“容易”和“难”用于特定的密码学意义。也就是说，如果给定原像(d)，则可计算该原像的加密哈希函数(H)并由此获得相应的哈希值(h＝H(d))；实际上，这通常意味着计算可以在多项式时间内完成。然而，如果给定哈希值(h)和哈希函数(H)，则无法计算恢复该哈希函数的任何原像(即任何d，使得H(d)＝h)，例如，因为反向计算只能在指数时间内完成。多项式时间和指数时间表示完成一种算法所需的运算次数相对于该算法的输入大小调整所采用的方式，当输入足够大时，指数时间算法实际上不可行。

发明内容

在密码学中，对加密哈希函数的“原像攻击”是指试图将至少一个原像恢复到指定的哈希值。哈希值可以直接指定，也可以参考给定的数据段，如果哈希值参考给定的数据段，其目的是找到第二个数据段，在该数据段上，哈希函数返回与第一个数据段相同的哈希值(所谓的“次原像攻击”)。“碰撞攻击”是指试图恢复至少两个具有相同哈希值的原像，即两个彼此不同但哈希函数对其返回相同哈希值(即H(d₁)＝H(d₂)＝九)的数据段(d₁，d₂)。对于碰撞攻击，可以指定也可以不指定哈希值h(注意，根据此定义，次原像攻击是一种预先指定哈希值的碰撞攻击形式)。加密哈希函数的原像或碰撞攻击成功可表示基于该哈希函数保护的任何加密系统中存在漏洞。例如，在区块链环境中，这种攻击如果成功，可以用作数字签名伪造的基础，使攻击者能够在不知道相应公钥的情况下使用有效签名创建交易。这种攻击也可以在其他情况下用作伪造的基础，例如数字签名伪造。

成功攻击加密哈希函数的影响是具体的，可能很严重。例如，2008年12月，一组安全研究人员成功地伪造了X.509公钥证书，利用在MD5哈希函数方面发现的碰撞攻击(见“如今视为有害的MD5-创建流氓CA证书”Alexander Sotirov等人；2008年12月30日)。MD5最初被设计成加密哈希函数，但其安全性现在已经严重受损。因此，MD5在密码学领域受到了广泛的质疑，MD5几乎已经停止在密码学中使用(但仍然在非密码学中使用，例如用于分布式数据库中)。除了用于说明哈希函数攻击成功的实际后果外，MD5的历史还用于说明本公开中采用的术语点：除非另有说明，本文中的术语“加密哈希函数”是简写形式，表示假定加密哈希函数，即假定其具有良好的加密特性；然而，哈希函数攻击成功可能会暴露出该假设为“false”。

在本文中，“攻击者”不需要有恶意。在恶意攻击者发现安全漏洞之前，可以尝试对哈希函数进行善意攻击，尝试发现安全漏洞并采取措施缓解这些漏洞。在这种情况下，能够以稳健且可验证的方式传达哈希函数攻击成功有显著的好处。本公开提供了一种机制，通过该机制，可以通过区块链交易的方式证明哈希函数的原像或碰撞攻击成功，而不透露攻击中发现的原像(即，证明是密码学意义上的“零知识”)。本公开认识到区块链网络是高度适用的去中心化平台，用于在密码学专家和其他相关方之间安全地传播知识，并永久记录该知识。

证明者在ECDSA签名(r，s)的r部分(r)构造零知识证明(ZKP)，使其纳入证明交易中。ZKP作为证明交易的ZKP组成部分(π)，与ECDSA签名(r，s)本身的r部分(r)相结合。接收用于处理的证明交易的区块链网络节点：

(i)根据相关联的公钥P和证明交易的签名部分m验证证明交易的签名(r，s)，

(ii)应用证明验证算法(V)来确定证明交易的ZKP组成部分π对于已验证签名(r，s)的r部分(r)以及定义哈希值h和定义哈希函数H是否正确，即证明以下陈述：

“签名(r，s)的r部分(r)的对应临时密钥对应于定义哈希值h相对于定义哈希函数H的原像”。

换句话说，证明证明者知道临时密钥k，使得H(k)＝h，R＝k.G，其中r＝[R]_x。证明是零知识证明，因为证明交易中不透露原像d本身。

因此，除了提供ECDSA签名的一般优点外，签名本身还与ZKP组成部分一起证明哈希函数H攻击成功。这具有各种优点，下文将参考所述实施例对这些优点作更详细的说明。在签名的r部分构造证明的独特优势是，无需对证明交易附加任何预先指定的身份，即不需要使用预先指定的私钥对交易进行签名，或者说，不需要交易包括与预先指定的公钥相关联的签名；在上述意义上，只要签名有效并且ZKP组成部分π对于签名的r部分是正确的，便可使用任何私钥V生成签名。

在本公开的实施例中，证明交易提供了对定义哈希函数H的哈希碰撞攻击成功的零知识证明。为此，证明交易可以包括第一和第二ECDSA签名(r₁，s₁)、(r₂，s₂)，以及第一和第二ZKP组成部分π₁，π₂。在这种情况下，可以构造证明验证算法

来验证第一和第二签名的r部分r₁，r₂是使用不同临时密钥k₁，k₂生成的，但是对于这些临时密钥，定义哈希函数H返回相同的哈希值h(碰撞的两个要求；k₁和k₂在该事件中称为碰撞原像)。在哈希碰撞攻击方面的特别好处是，除了对碰撞原像k₁，k₂进行保密外，不需要提前知道哈希值h(因此不需要在挑战交易、任何其他交易、区块链的任何其他地方或以其他方式指定)。

不需要透露原像，这对于安全性很重要：如果在交易中透露原像，另一个有权限访问证明交易的恶意攻击者可以立即在现实环境中复制攻击(例如，将其用作数字签名伪造的基础)。此外，在挑战交易提供数字资产以换取正确证明的情况下，恶意方(如矿工)可以为自己申请数字资产，因为他知道原像。然而，零知识证明可以防止这种情况发生，同时仍然提供关于系统中任何漏洞的有价值的信息，该系统基于哈希函数受到保护，并允许采取行动来缓解这些漏洞；即使不知道原像，攻击存在证明在安全方面仍然非常有价值，因为它可以揭示现在可以缓解的安全漏洞是否存在，而有权限访问交易的恶意攻击者只是知道攻击存在，但不知道如何进行复制。

本公开的第一方面提供了一种在区块链网络的节点处理至少一笔证明交易的计算机实现的方法，该方法包括：

接收所述至少一笔证明交易，其中所述至少一笔证明交易包括至少一个椭圆曲线数字签名算法(ECDSA)签名和至少一个零知识证明(ZKP)组成部分；

基于与所述至少一笔证明交易的ECDSA签名和签名部分相关联的公钥来验证所述至少一笔证明交易的ECDSA签名；

通过确定ZKP组成部分对于ECDSA签名以及定义哈希值和定义哈希函数是否正确，确定至少一个ZKP组成部分是否证明知道哈希函数攻击成功，因为所述ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于所述定义哈希值相对于所述定义哈希函数的原像。

附图说明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图14示出了哈希冲突赏金交易和相应的证明交易；

图15示出了(a)算术电路门和(b)算术电路；

图16示出了另一示例性算术电路；

图17示出了一种用于验证算术电路证明的方法的处理流程。

具体实施方式

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

在基于UTXO的区块链中，“哈希难题”(经过哈希处理的值的原像)解可以设置为花费条件，因此由矿工执行验证作为交易验证的一部分。如果第二交易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也可以在基于账户的模型中使用智能合约来实现，而不是使用基于输出的模型的锁定脚本和解锁脚本。

然而，使用哈希难题作为知识证明并结合P2PKH以避免可能的矿工攻击存在的问题在于，虽然P2PKH确保仅向首先知道d的一方付款，但这也意味着Tx₁的输出与特定的预定接收者或接收者集合相关(可以指定可包括替代接收者的替代条件，但它们仍然必须预先标识)。

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

哈希函数攻击——概述

所述实施例将区块链技术作为传达和记录哈希函数攻击的基础。成功攻击哈希函数的证明提交给区块链网络节点，以在交易中进行处理。该节点处理该交易，以确定提交的交易是否确实证明攻击成功。该处理可以作为应用于交易的交易核实过程的一部分隐式执行。确实提供此证明的交易存储在区块链网络维护的区块链中(假设该交易符合所述区块链网络规定的任何有效性要求)，从而提供证明攻击成功的不可变记录。该记录又可以被任何能够访问区块链的人使用，例如作为缓解措施的基础，旨在缓解成功攻击所暴露的任何安全漏洞。

如上文所述，该证明是零知识证明(ZKP)。ZKP是指证明一方知道某个值(在本文中，是原像)，而不透露该值本身(即在本文中，不透露原像)。

在区块链环境中，还希望能够将身份归属于发现成功攻击哈希函数的一方，为此，可以在对交易的一部分进行签名的交易中提供有效数字签名，在这种情况下，将身份附加到交易中，作为“持有与数字签名相关联的公钥的私钥对应部分的一方”。

然而，仅仅包含数字签名本身并不能防止恶意矿工从交易中提取哈希攻击的证明，并将其纳入用自己的私钥签署的新交易中，从而附加不同的身份。然而，能够缓解这种情况的做法是在签名本身中提供一个证明元素，这样，如果签名更改，证明便不再正确(有效)。

所述实施例利用了这样一个事实，即可以构造以下形式的零知识证明：

“哈希值h相对于哈希函数H的原像等于标量乘数d，其中P＝d·G”。

这可以等价于证明H(d)＝h、d·G＝P。其中，“·”表示在定义的椭圆曲线ε_n和定义的生成点G上的椭圆曲线标量乘法。该证明是零知识证明，因为该证明可以在不透露d的情况下有力证明上述陈述，即哈希函数的原像在密码学意义上保密；为了证明知道d，一方可以用d推导出椭圆曲线上的对应点P，并连同零知识证明组成部分π一起呈现P，证明自己知道d(而不是提供d本身)。验证(即确定正确性)ZKP组成部分证明π所需的唯一公开信息是ε_n，G、P、h和H。

注意：为其构造证明的哈希函数H可以与用于生成和验证ECDSA签名的哈希函数H_sig相同，也可以不同。虽然在下面的描述中有时会使用符号H来表示用于生成签名(即H_sig)的哈希函数，但这纯粹是为了简单起见，并不一定意味着与为其构造证明的哈希函数相等。

在上述基础上构造零知识证明的一种方法是使用原像d来推导公钥，即用于生成ECDSA签名的P＝d·G。这可以等效地表述为使用原像d作为私钥对消息m进行签名。考虑一笔交易Tx＝(m，P，(r，s)，π)，即由签名部分m(消息)、与公钥P相关联的ECDSA签名(r，s)和零知识证明组成部分π组成的交易。通过这种结构，零知识证明组成部分π将基于P进行验证，即确定零知识证明组成部分π是否确实证明P的对应私钥是哈希函数的原像。这样做的后果是，恶意旷工不能通过新的签名简单地将π包含在新的交易中：新的签名将与不同公钥P′相关联，而零知识证明组成部分π将对于P′不正确(因为相应的私钥不再是h的原像)。

然而，本公开认识到这种方法存在一个问题，即将能够提供交易的一方的身份限制为私钥d的持有者。

本公开进一步认识到，ECDSA签名实际上依赖于椭圆曲线标量乘法的两个实例以及两个保密值来生成给定消息m的签名：一个是(根据私钥V)推导出公钥为P＝V.G，另一个是(根据临时密钥k)推导出公钥为R＝k.G。本公开不是在公钥P上构造证明，而是在签名(r，s)的r部分(r)上构造零知识证明，即推导出r部分为：

R＝d·G

r＝[R]_x

H(d)＝h

根据这个新结构，给定一笔交易Tx＝(m，P，(r，s)，π)，如果ZKP组成部分π证明了以下陈述，那么该ZKP组成部分正确：

“哈希值h相对于哈希函数H的原像等于用于推导签名(r，s)的r部分r的标量乘数d”

这又可以根据ε_n，G、h、H和r.进行验证。这可以等同于证明用于推导r部分r的临时密钥k是h的前像，即k＝d，其中H(d)＝h。因此，除了要求签名有效且r部分的证明正确之外，现在对用于生成签名的私钥V没有任何限制。

本文中使用的术语“r难题”与在ECDSA签名的r部分上构造的任何知识证明相关。r难题可以作为一个或多个证明要求包含在挑战交易的代码中，证明交易中至少一个ECDSA签名的r部分必须满足该要求(如果满足所有要求，则认为证明交易“解决”了挑战交易的r难题)。对r部分的要求对用于推导r部分的临时密钥k提出了隐性要求，因此r难题的解证明了挑战者(证明者)拥有满足这些要求的临时密钥k，而没有透露临时密钥k本身。根据这一定义，由于零知识证明构造在签名的r部分，因此对前段所述陈述提供正确证明的要求是一种特殊形式的r难题。

在证明知道成功攻击加密哈希函数的具体情况下，r难题要求证明交易包含(i)至少一个有效签名(r，s)和(ii)至少一个零知识证明组成部分π，该组成部分对于该签名的r部分r以及定义哈希值h和哈希函数H正确。

在证明知道成功攻击哈希函数的更具体情况下，r难题要求至少有两个有效签名(r₁，s₁)和(r₂，s₂)以及至少两个零知识证明组成部分π₁，π₂，其中π₁和π₂分别对于r₁和r₂是正确的，同时对于彼此相同的哈希值h和相同的哈希函数H是正确的。

如上所述，虽然本公开的教导适用于更普遍的情况，但是在哈希碰撞攻击方面仍然有特别的好处，因为在设置r难题之前，不需要知道哈希值h和碰撞原像k₁、k₂(即k₁、k₂，其中k₁≠k₂、H(k₁)＝H(k₂)＝k)。

为了激励仁慈的攻击者提供成功攻击哈希函数的证明，可以提供“赏金”来换取解决相应r难题的交易(证明交易)。在UTXO模型中，赏金可以包含在一个或多个未花费交易输出的锁定脚本中，而该输出只能由包含解决r难题的解锁脚本的交易来“赎回”(使用)。在这种情况下，上述证明结构的一个好处是，恶意矿工不能改变交易来为自己赎回未花费的交易输出(赏金)。

在基于账户的模型中，可以对智能合约进行编码，从智能合约的账户中发放一定数量的数字资产作为赏金，从而换取解决r难题的交易。

在本文中，可以通过这种交易换取赎回的交易称为“赏金”交易——本文中使用该术语为例说明“挑战”交易。

“哈希碰撞赏金”交易要求对定义哈希函数提供哈希碰撞攻击。这样的交易不需要指定哈希值h(也不需要预先以任何其他方式指定哈希值h)，在这种情况下，只需要证明一方知道两个返回彼此相同的哈希值的原像。

“哈希原像赏金”交易需要证明对定义哈希函数的原像攻击，该证明可以在哈希原像赏金交易中定义(例如在其锁定脚本中)或由相关交易定义(例如在基于账户的模型中，h可以在创建智能合约账户的交易之外的中间交易中上传到智能合约寄存器)。

下面将进一步详细说明，但首先就一些示例性实施例再提供一些背景信息。

示例性系统概述

图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>||[ChecksigP_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中。例如，元数据可包括需存储在区块链中的文件。

注意：符号<H(x)>表示“将值h推送到堆栈上”，其中值h＝H(x)在解锁脚本中提供，而不提供H或x。

签名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+b mod 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，

和

如果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上的椭圆曲线标量乘法。

椭圆曲线ε_n的阶数n相对于生成点G定义为满足以下等式的标量：

n·G＝∞，

因此，n既取决于椭圆曲线的选择，也取决于生成点G的选择。虽然n可以简称为椭圆曲线ε_n的阶数，但更准确地说n是生成点G相对于椭圆曲线的阶数或者该生成点相对于椭圆曲线生成的子组的阶数。在实际的ECC上下文中，应选择G，使得n较大且为素数。因此，在实践中，p和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_HASH 160<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)。

<P_B><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。

下面示出了对应的解锁脚本(与先前部分相同)，其中签名sigr使用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难题，而且必须知道d。图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值语句

另一可能是具有r的多个预定值，例如，r₁、r₂和r₃，它们解锁不同的语句并与其相关联。如果将语句S_i分配给每个r_i，就可以通过在签名中使用对应的r_i来确认特定语句。例如，这可以用于签名以表示同意协议中的一个或多个备选条款。

可以构建锁定脚本来检查解锁脚本中使用的r值，并且可以为r值分配解释。实现上述想法的锁定脚本可能如下所示：

每个<statementi>都会替换为不同的锁定条件，这些锁定条件只有在破解对应的r难题之后才能访问。解锁脚本如下所示，其中r_i是访问已设定语句所需的独特r值。

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

可选安全功能#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难题交易中以提高安全性。假设爱丽丝想将其签名权委托给鲍勃。爱丽丝从鲍勃那里获取一次性公钥P₂，并创建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。

哈希冲突赏金

通过构建表1中所示类型的交易输出，可以在区块链上实现哈希冲突赏金，所述交易输出可以由能够找到哈希函数(以下示例中的SHA1)冲突的任何人赎回(花费)。

表1：哈希冲突赏金交易

可以通过具有对应的解锁脚本的证明交易来“申请”赏金(即，可以花费哈希赏金交易的输出)：

<preimage₁><preimage₂>

无论谁找到经过哈希处理能实现相同值的两个不同原像，都会获得赏金奖励。

赏金相关的问题是，无论谁试图申请赏金，都必须透露解。因此，看到证明交易的任何人都将能够窃取答案并创建自己的证明交易来为自己申请赏金。此外，恶意攻击者可以随意复制攻击，这可能会带来安全风险。

这个问题是使用一种针对原像赏金的r难题交易来解决的，其构建关于ECDSA签名的r部分的零知识证明。

哈希冲突赏金交易有效地奖励能够推导出三元组(x₁，x₂，h)的任何人，使得x₁≠x₂和H(x₁)＝H(x₂)＝h，其中H是赏金中的哈希函数。

构建赏金交易的一方不知道可以采用的值(x₁，x₂，h)，因此无法在赏金交易中指定这些值。

该解使用零知识证明哈希电路，应用国际申请PCT/IB2019/052184[1]，其全部内容以引入方式并入本文。

下面描述示例性证明验证算法

的更多详细信息。

图14示出了赏金交易1402(在该示例中为挑战交易)和对应的证明交易1404。赏金交易1402对证明如下所述的哈希冲突攻击成功进行奖励。

在以下示例中，哈希函数被定义为要作为哈希函数的SHA256。这在赏金交易1402的锁定脚本中定义。

通过应用[1]的方法，基于以下语句构建零知识证明：

“h的原像与ECDSA公钥R的ECDSA私钥相同”。

该证明体现为包括在证明交易中的零知识证明组成部分π，其针对ECDSA签名的r部分和哈希值h(也包括在证明交易中)证明上述语句。

证明验证算法

采用三个输入(h，R，π)和输出1(TRUE)，前提是π是关于(h，R)的有效证明，否则为FALSE。当

输出1时，这意味着证明者知道秘密值d，使得H(x)＝h和d·G＝R。证明验证算法

在伪码中表示为[ZK_VERIFY]。该算法对一项或多项证明要求进行编码，证明交易的零知识证明组成部分π必须针对R和π满足所述一项或多项证明要求。

应用与EDCSA相关联的术语，可以看出d履行临时密钥的角色(即，上述符号中的d＝k)。

假设存在SHA256冲突(d₁，d₂，h)，其中所有三个值都是未知的，使得R₁＝d₁·G

R₂＝d₂·G

应当注意的是，d₁≠d₂意味着R₁≠R₂。

证明者必须提供两份证明(π₁，π₂)，其中π₁是关于(h，R₁)的证明，并且π₂是关于(h，R₂)的证明，应当注意的是，这两份证明都是针对相同的哈希值h的，在当前上下文中，该哈希值事先是未知的，并且未在赏金交易中或区块链中的任何其他地方(或以其他方式)指定。

赏金交易1402是针对使用锁定脚本构建的SHA256冲突赏金的r难题交易，该锁定脚本可以用伪代码表示如下：

在这里，[EXTRACT_r]表示从ECDSA签名(r，s)中提取r的函数。

在该示例中，作为证明验证算法v([ZK_VERIFY])的一部分，在挑战交易1402的锁定脚本中将哈希函数H定义为SHA256。

证明交易1404中的解锁脚本为：

<r₁，s₁><r₂，s₂><P₁><P₂><h><π₁><π₂>

其中r₁＝[d₁·G]_x，并且r₂＝[d₂·G]_x。

可以看出，当赏金交易1402中的锁定脚本应用于证明交易1404中的解锁脚本时，检查r₁≠r₂。假设是这种情况，验证算法的第一实例提取r₂，从r₂推导出R₂，然后验证关于(h，R₂)的证明π₂。如果证明有效，则提取r₁，从r₁推导出R₁，然后验证关于(h，R₁)的π₁。

某些r_l值将对应于两个可能的椭圆曲线点，表示为

和

在这种情况下，可以包括与r_l相关联的标志，以指示应使用两个点

中的哪一个。或者，可以省略该标志，并且验证算法可以应用于

和

并且在这种情况下，该证明对于

和

中的一个是正确的即可。对于两个r部分，r₁、r₂，可以有多达四个唯一的R配对，即，

并且这些配对中的一个是正确的，即被证明对应于冲突原像即可。

或者，椭圆曲线上的点R₁和R₂可以显式地包括在证明交易1404中。在这种情况下，相关签名(r_i，s_i)的“r部分”是点R_i的x坐标，该坐标与该点的y坐标一起用于检查证明π_i。

如果证明也是有效的，则所有签名都将被验证。应当注意的是，为简单起见，锁定脚本中省略了验证安全签名的步骤。实际上，他们将以技术人员显而易见的方式包括在锁定脚本中。这些步骤基于与其相关联的相应公钥P₁、P₂(如上所述包括在解锁脚本中或可以其他方式从解锁脚本推导出)以及表示为m₁、m₂的交易的相应已签名部分来验证签名(r₁，s₁)、(r₂，s₂)中的每一个。通常，已签名部分可以是相同的(即m₁＝m₂)或不同的(m₁≠m₂)；同样，公钥P₁和P₂可以是相同的(P₁＝P₂)或不同的(P₁≠P₂)。然而，在P₁＝P₂和m₁≠m₂时，会获得特定的好处(请参见下文)。

对证明者的身份没有限制，即证明交易1404的公钥P₁和公钥P₂未在赏金交易1402中或区块链中的任何其他地方(或以其他方式)指定。换句话说，提供具有不同r部分的有效签名对以及对于这些签名的相应r部分是正确的零知识证明组成部分的任何一方都可以申请赏金，而不管谁的一个或多个公钥与这些签名相关联(即不管用于验证他们的一个或多个私钥P₁，P₂)。

可选安全功能#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或同一条消息m的解锁脚本中包括另一额外签名sig′(防伪签名)，除非矿工知道密钥V，否则他们将无法提供该签名。在这种情况下，解锁脚本包括：

<sig′><P><sig_r>

sig′必须是不同消息m′的签名，例如m′＝m_sighash，但使用相同的公钥V生成。在UTXO区块链环境中，可以使用不同的“sighash标志”来实现这一点(例如SIGHASH_NONE，而不是默认标志SIGHASH_ALL)。

此外，sig′必须使用r的不同值(即不同的临时密钥)，这样就不会泄露私钥(因为私钥可以从使用相同临时密钥和相同公钥的两个不同消息的签名推导出，这是ECDSA的一个已知属性)。

在这种情况下，将对解锁脚本进行修改，纳入防伪签名sig′附加检查。

对于申请哈希碰撞赏金的证明交易，可以用三个签名来实现——两个证明碰撞攻击的签名，以及第三个单独的防伪签名。

然而，为了避免使用第三个签名，证明交易1404中的两个签名(r₁，s₁)、(r₂，s₂)可以用于同时证明碰撞攻击并防止伪造。这是通过使用相同的私钥生成两个签名来实现的(其结果是相关联的公钥相同，P₁＝P₂)，这两个签名可以在交易的不同部分生成，也可以不在交易的不同部分生成(即m₁≠m₂或m₁＝m₂)。注意，这些签名要求使用不同的临时密钥来申请赏金。这是一种同样强大的解决方案，但有两个签名而不是三个。

在这种情况下，仍然没有预先指定公钥P₁(这意味着任何有解决方案的人都可以申请赏金)，但解锁脚本确实要求签名对相同的公钥有效(无论该公钥可能属于谁)。

哈希原像赏金

还可以提供指定哈希值h的挑战交易，该交易可以用证明知道单个原像的证明交易来赎回。这可能被称为哈希原像赏金交易。

例如，挑战者可以为哈希值h创建哈希原像赏金交易，其原像d对挑战者来说是保密的(即挑战者没有向任何其他人透露)。在这种情况下，如果其他人能够独立地推导出h的原像(而挑战者未向其告知原像d)，就构成了成功的原像攻击。

用例

如前所述，一旦知道攻击的存在，该知识就可以用来识别和缓解依赖于所述哈希函数的加密系统中的漏洞。

例如，依赖于哈希函数安全性的数字证书可能被撤销。

在区块链环境中，具有一个或多个基于所述哈希函数的未花费输出的交易(例如“哈希难题”交易，其要求提供指定哈希函数的原像，以赎回所述输出)可以由例如一旦哈希函数中的漏洞被暴露就发布该交易的一方赎回，以防止恶意方利用该漏洞为自己非法赎回所述输出。

证明验证算法

在下面的描述中使用符号π来表示所描述类型的零知识证明组成部分。与π有关的所有描述同样适用于π₁和π₂。同样，使用符号k表示在r难题的上下文中作为临时密钥的秘密值，并且与k有关的所有描述同样适用于上述k₁和k₂。同样，交易签名由(r，s)引用和表示，并且所有相关描述同样适用于(r₁，s₁)和(r₂，s₂)。与R有关的所有描述同样适用于R₁和R₂。

必须证明的一个方面是证明者知道值k，该值是哈希值h相对于哈希函数H的原像。这是在零知识的情况下进行证明的，因为虽然哈希函数H和哈希值h是已知的(在哈希冲突赏金的情况下，后者在证明交易1404中提供)，但是k本身(即原像)仍然是秘密的。根据本领域中使用的术语，k在此上下文中可以称为“见证者”(w)。“k(见证者w)是h相对于H的原像”语句据说是在零知识的情况下进行证明的，换句话说，它可以在不透露见证者w的情况下进行证明。应当注意的是，在当前上下文中，这只是必须在零知识的情况下中进行证明的两个方面中的第一方面，同时必须在零知识的情况下进行证明的第二方面是k，也是用于生成ECDSA签名(r，s)的临时密钥。

就各种哈希函数H(包括SHA256)而言，有许多现有机制可用于在零知识的情况下证明第一方面。一些此类机制利用了“算术电路”。

例如，零知识“简洁的非交互式零知识论证”(zkSNARK)提供了一种在零知识的情况下证明可表示为算术电路的任意计算有效的方法。zkSNARK的两个属性是：非交互式(证明者一步将证明发送给验证者)；简洁(证明很小且易于验证)。算术电路是由“门”和连接所述门的“线”构成的逻辑电路。所讨论的哈希函数H被实现为算术电路。哈希函数的此类算术电路实现在本领域中是已知的。存在用于实现SNKARK的各种库，并且这些库将是本领域技术人员所熟悉的。

又如，“Zcash”是一种已知的机制，其将zk-SNARK应用于哈希函数，以便提供给定哈希值h的原像的知识，而不透露h。这是基于所讨论的哈希函数H的算术电路实现。例如，SHA256的已知实现使用27,904个算术门，并且已经在Zcash的环境中应用。

通过将哈希函数H和椭圆曲线标量乘法运算“.”(下文等效地表示为×)实现为算术电路，并对其应用零知识证明协议(如Sigma协议，请参见下文)，可以在该框架内证明第二方面，即原像和临时密钥的等效性。对于本领域的技术人员而言，在给定“·”的算术电路实现的情况下，考虑到在本文中所提供的教导，如何将其用于构建此类证明将是显而易见的。

然而，为了避免需要实现椭圆曲线标量乘法的算术电路，可以替代地应用在上文提到的国际申请PCT/IB2019/052184[1]中指定的方法。这提供了一种方法，该方法可以被应用于有效地提供两个所需的方面，即除证明h的原像的知识之外，还证明所述原像对应于用于生成签名的临时密钥(不需要在算术电路上植入椭圆曲线标量乘法)。

该方法在当前上下文中的相关方面以及该方法的背景如下所述。

∑协议

∑(Sigma)协议是一种交互式零知识证明系统，涉及证明者与验证者之间的多个步骤(通信)。通常，∑协议涉及3个步骤：证明者向验证者发送初始承诺(a)，然后验证者以随机挑战(ξ)做出响应，最后证明者以最终响应或“期初值”(z)做出回答。然后，验证者基于记录(a，ξ，z)接受或拒绝该语句。

∑协议可用于证明只有证明者知道的见证者(w)的知识或有关该见证者的语句。如果协议未向验证者透露任何有关见证者的信息，则该协议是零知识，除非与见证者相关的语句为真。有关更多详细信息，请参见Jonathan Bootle等人的“高效的零知识证明系统(Efficient zero-knowledge proof systems)”，《安全分析与设计基础VIII(Foundationsof Security Analysis and Design VIII)》，施普林格出版社，卡姆，2015年，第1-31页，【Bootle 2015】，其全部内容以引入方式并入本文。

佩德森承诺

承诺方案是许多加密协议的核心部分，也是实现电路可满足性的交互式零知识协议的组成部分。承诺使证明者能够预先承诺秘密值，然后可验证地透露(公开)秘密值。承诺方案具有两个主要属性：1)隐藏属性：即承诺确保值是秘密的；2)捆绑属性：承诺只能对最初承诺的值公开。

可以在当前上下文中采用的方案的示例是佩德森承诺【Bootle 2015】。该方案涉及两个椭圆曲线生成点：素数阶p的组

中的G和F，对所有当事方已知。提交者在字段

中生成安全随机数ρ，然后计算(通过椭圆曲线加法/乘法)对秘密值σ的承诺¹：

Com(s，r)＝σ×G+ρ×F

其中，计算对秘密值σ的承诺¹：在这里，×表示椭圆曲线点乘法。

提交者可以在稍后阶段通过提供值ρ和σ来完全公开承诺(即可以进行验证)。作为Sigma协议的一部分，提交者还可以响应特定的挑战值公开承诺(而不透露ρ或σ)。

佩德森承诺的一个有用属性是它们是相加同态的，这意味着将两个承诺相加(在椭圆曲线上)会得到对承诺值之和的承诺，即：

(σ₁×G+ρ₁×F)+(σ₂×G+ρ₂×F)＝(σ₁+σ₂)×G+(ρ₁+ρ₂)×F

这种同态属性用于算术电路可满足性的零知识证明。

零知识情况下算术电路可满足性的证明

算术电路(在域

上)是算术门的逻辑结构，这些算术门通过线连接(形成有向无环图)，能够执行任意复杂的计算²。每个门有两条输入线和一条输出线，并对输入执行乘法(×)或加法(+)运算。完整的电路具有定义外部(电路)输入和输出值的自由输入线和自由输出线。

其中，能够执行任意复杂的计算²：计算仅限于整数运算，并且不能有数据依从循环或可变状态。

线的值的合法分配被定义为满足电路要求的一组分配的线值，即每条线分配有一个值，其中每个门的输出正确地对应于输入的乘积或和(即，门是一致的)。

图15示出了：(a)具有左侧(w_L)和右侧(w_R)线输入和一个线输出(w_O)的乘法门的示意图；(b)具有三个门、三条输入线(w₁、w₂、w₃)、一条输出线(w₆)和两条内部线(w₅、w₆)的简单算术电路。

对于给定的算术电路，为了向验证者证明他们知道该电路的合法分配，而无需透露线路值，证明者可以首先承诺合法分配中的每个线路值(通过佩德森承诺)，然后以线路值为见证，与验证者一起针对电路中的每个门执行特殊的Sigma协议(可以并行执行)。这些Sigma协议利用佩德森承诺的同态属性，如下所述。

为了提供证明(满足电路要求)，证明者最初生成对电路中的每条线w_i的承诺(i＝1，...，m，其中m是线的数量)，并将其发送给验证者：

W_i＝Com(w_i，ρ)

∑_zero协议：

对于电路中的每个加法门，执行∑_zero协议：这涉及(在零知识的情况下)证明w_L+w_R-w_O＝0(即，满足加法门要求：输入线w_L和w_R等于输出线w_O)。

注意：下标R是线索引，在此上下文中不表示点R＝k.G。

1.证明者生成零承诺：B＝Com(0，ρ_B)，并将其发送给验证者。

2.验证者以随机挑战值：

做出响应。

3.然后，证明者计算期初值：z＝ξ(ρ_L+ρ_R-ρ)+ρ_B，并将其发送给验证者。

4.验证者检查Com(0，z)＝ξ×(W_L+W_R-W_O)+B作为w_L+w_R-w_O＝0的证明。

根据4，为了验证证明，证明验证算法

要求：

对以下项式执行

(z，ξ，W_L，W_R，W_O，B)

应当注意的是，这是针对单个加法门的。

∑_prod协议：

对于每个乘法门，执行∑_prod协议：这涉及证明(在零知识的情况下)每个乘法门w_L·w_R＝w_O(即，满足乘法门要求)。

1.证明者生成5个随机盲值：

2.证明者计算C₁＝Com(t₁，t₃)、C₂＝Com(t₂，t₅)和C₃＝t₁×W_R+t₄×F，然后将其发送给验证者。

3.验证者以随机挑战值：

做出响应。

4.证明者计算期初值：

e₁＝w_Lξ+t₁

e₂＝w_Rξ+t₂

z₁＝ρ_Lξ+t₃

z₂＝ρ_Rξ+t₅

z₃＝(ρ_O-w_Lρ_R)ξ+t₄

并将其发送给验证者。

5.然后，验证者检查以下等式：

Com(e₁，z₁)＝ξ×W_L+C₁

Com(e₂，z₂)＝ξ×W_R+C₂

e₁×W_R+z₃×F＝ξ×W_O+C₃

作为w_L·w_R＝w_O的证明。

根据5，验证算法

要求：

(e₁，e₂，z₁，z₂，z₃，ξ，W_L，W_R，W₀，C₁，C₂，C₃)

电路证明

∑_zero和∑_prod协议可以并行运行，以验证电路中的每个门，并且所有门都可以使用相同的验证者挑战值(ξ)。

例如，考虑图15(b)中的电路：对于要在零知识的情况下向验证者证明他们知道合法分配(即满足电路要求的线值)的证明者，证明者最初向验证者发送线承诺(W₁，...，W₆)和每个门的∑协议承诺(这是每个加法门的一个额外承诺和每个乘法门的五个额外承诺)。

然后，验证者以随机挑战

做出响应，证明者计算每个门的期初值(每个加法门一个期初值，每个乘法门五个期初值)，并将其发送回验证者。然后，验证者执行∑协议检查，以验证：

w₁·w₂＝w₄

w₄·w₅＝w₆

w₂+w₃＝w₅

因此，承诺W₁，...，W₆对应于满足线值w₁，...，w₆要求。

如果证明者想要证明，除满足电路要求之外，特定线还具有特定值，他们可以完全公开对相关线的承诺。在该示例中，证明者可以附加地向验证者发送值w₆和ρ₆(然后，验证者可以确认W₆＝Com(w₆，ρ₆))，以证明w₆是特定合法分配的实际输出。

为便于说明，图15(b)示出了简化电路。实际上，有用的电路由更多的门组成。特别令人关注的是SHA-256哈希函数的算术电路-该电路使证明者能够证明他们知道哈希处理到特定(输出)值的SHA-256函数的原像(输入)，而不透露原像。SHA-256算法的其中一种最有效的电路实现包括27,904个算术门【例如，采用Zcash实现】。要证明SHA-256原像的知识，则需要在上述协议的初始承诺和公开轮次中发送约5MB的数据，并且证明者和验证者需要执行约200,000次椭圆曲线运算(每个运算需要几秒钟的处理器时间)。最近发布的一些协议可以大幅降低这些计算成本和证明大小，而不会对承诺的性质施加任何限制。

无配对算术电路可满足性的高效零知识论证

已经制定了几种方法来显著提高并行∑协议方法的性能，以证明上一节所述的算术电路可满足性。请参考以下内容，其中每一个的全部内容以引入方式并入本文：

Jens Groth，“具有次线性零知识论证的线性代数(Linear Algebra with Sub-linear Zero-Knowledge Arguments)”，CRYPTO期刊，第5677卷，2009年，【Groth 2009】；

Jonathan Bootle等人，“离散对数环境下算术电路的高效零知识论证(Efficientzero-knowledge arguments for arithmetic circuits in the discrete logsetting)”，《密码技术理论和应用国际会议(International Conference on the Theoryand Applications of Cryptographic Techniques)》，德国柏林施普林格出版社，2016年，【Bootle 2016】。

【Bootle 2016】和【Groth 2009】中描述的方法涉及对电路线值的承诺进行批处理，以大幅减少必须从证明者发送给验证者的数据大小(即降低通信复杂性)。这些方法可实现通信复杂性从

降低到

或

的证明系统。

同样，作为证明同一SHA电路的可满足性的比较，【Bootle 2016】的协议的证明密钥大小仅为5KB，密钥生成时间为180ms。证明大小为24KB，生成时间约为4s，验证时间也约为4s。

除声明所采用的主矢量批处理协议(如下所述)之外，这些方法在这里是完整的。这遵循与标准佩德森承诺相同的属性，但承诺使用n个元素(m＝m₁，...，m_n)仅需发送单个组元素即可：

1.证明者和验证者就组元素

达成一致。

2.证明者生成n个随机数

3.证明者计算点K_i＝ξ_i×F(对于i＝1，...，n)。这些值构成发送给验证者的证明密钥PrK。

4.证明者生成随机值：

5.证明者计算承诺：

并将其发送给验证者。

证明验证运算

-示例

本节描述了证明验证算法v(上述[ZK_VERIFY])的不同示例，以及该算法在基于批处理和非批处理承诺的零知识证明系统中的实现。

零知识证明协议涉及两方：证明者(P)和验证者(V)。该协议的目的是让证明者说服验证者，使验证者确信给定语句

为真，同时将有关该语句的见证者的信息保密。该语句包括具有q个门和m条线的算术电路

以及关于对应于一个(或多个)电路线值：pk_l(其中下标l是密钥语句的线索引)的椭圆曲线公钥的相关断言。此外，该语句还可以包括关于完全公开(公共)线值(即电路的公共输入/输出)的断言。

该语句中指定的椭圆曲线公钥对应于目标椭圆曲线规范(由全套椭圆曲线参数：

定义)。对于脚本，这些参数由secp256k1规范定义。该规范包括基本生成点G。

除指定基点之外，该语句还必须指定第二点F(其中F＝f×G，f是

的元素)。f的值必须是可证明的随机数(例如，创始区块153的哈希值)，或者是“唯一”数字，如π的二进制表示的前256位³。

其中，f的值必须是可证明的随机数(例如，比特币创始区块哈希值)，或者是“唯一”数字，如π的二进制表示的前256位³：允许证明者自由选择f使他们能够生成虚假证明。

图16示出了具有四个门和五条线的示例性电路。一条输入线(w₁)的公钥通过线承诺(W₁)透露(“公开”)，具有“密钥公开”值ko₁。

实施例1：单独的线承诺

本节描述了当验证者对电路中的每条线有单独承诺时的密钥公开(即遵循∑协议以实现算术电路可满足性，请参见上文)。

1.电路中的每条线i(i＝1，...，n)都有佩德森承诺：

W_i＝Com(w_i，ρ_i)

其中：

Com(w，r)＝w×G+ρ×F

2.对于需要对应的公钥证明(密钥语句证明)的电路线l，证明者还发送密钥公开：

ko_l＝ρ_l×F

3.如果电路线j需要公开显示(完全公开的线)，则证明者发送“完全公开”元组：

(w_j，ρ_j)

4.然后，使用上述Sigma协议在零知识的情况下证明电路的每个门都满足要求⁴。

其中，使用上述Sigma协议在零知识的情况下证明电路的每个门都满足要求4：这涉及证明者计算并发送每个门的∑_zero和∑_prod承诺(即分别是B或C₁，C₂，C₃)，验证者以挑战值(ξ)做出响应，证明者发送公开值(z和e值)，以及验证者根据承诺进行检查。

5.一旦验证者确认电路满足要求，验证者就通过椭圆曲线点减法计算线l的公钥：

pk_l＝Com(w_l，ρ_l)-ko_l

6.然后，验证者确认每个pk_l与该语句中指定的密钥相匹配(并且完全公开的线与指定值相匹配)，以完成核实。

图17示出了证明者(P-提供证明交易1404的人员)和验证者(V)(设置挑战交易1402的挑战者)之间关于证明语句

的示例性协议流。该语句包括电路描述，并且线l的公钥为pk_l。

实施例2：批处理矢量承诺

在涉及批处理矢量承诺的电路可满足性压缩证明系统的情况下【Bootle 2016，Groth 2009】，下面描述的方法可以用于从批处理电路线承诺中提取密钥语句证明。不会描述完整的证明协议，而是仅描述批处理线承诺的生成和证明包含指定公钥的协议。

按如下所述生成批处理承诺，其中线l将提供有密钥公开。在矢量承诺中，m条线在一起进行批处理。

1.证明者生成m-1个随机数

2.证明者计算椭圆曲线点K_i＝ξ_i×G(对于i＝1，...，m-1)。这些值加上K_m＝G构成发送给验证者的证明密钥PrK。

3.证明者生成随机值：

4.证明者计算对线值w_i的矢量w的承诺(对于i＝1，...，m)，其中w_m将进行密钥公开处理：

并且将其发送给验证者作为【Bootle 2016】中协议的一部分。

5.证明者还发送矢量承诺的密钥公开：

6.验证者通过椭圆曲线算法计算密钥语句线(线密钥)的“公钥公开”：

pk_m＝Com(w)-ko_m

哈希原像与椭圆曲线私钥的等效性证明

本节描述了可在哈希附加赏金的上下文中使用的密钥语句零知识证明的示例。

仅作为示例，为了申请赏金而要证明的语句

在该示例中具体表示为：

“在给定在secp256k1椭圆曲线上具有公共输出h和公共点R的SHA-256哈希函数(H)的情况下，哈希值的秘密原像d(即h＝H(d))等于椭圆曲线点乘数(即对应的临时密钥，即R＝d×G))”。

在上述方法中，该语句包括针对SHA-256哈希函数

的单个算术电路(具有m条线w_i(i＝1，...，m)和q个门)，以及关于输入线(w₁)是公用点R的私钥并且输出线(w_m)等于h的断言，即：

线

满足

的要求，且w₁×G＝R，且w_m＝h

因此，要完全验证该语句，证明者必须向验证者证明，他们知道使用基于secp256k1的承诺方案对SHA256电路进行了令人满意的分配，然后只需提供线1(ko₁)的密钥公开和线m(w_m、ρ_m)的完全公开。验证者不会获得输入线(w₁)的值，或者除完全公开的输出线w_n之外的任何其他线的值。

因此，可以如下在r难题框架中构建证明验证算法

为了验证上述语句

证明验证算法需要满足以下条件：

E1)z_i-每个加法门一个，每个乘法门三个；

E2)B_i-每个加法门一个；

E3)W_i-每个加法门三个，每个乘法门三个；

E4)e_i-每个乘法门两个；

E5)C_i-每个乘法门三个；

E6)ko₁；

E7)w_m和ρ_m。

E1-E7共同构成了证明交易1404的证明π，并且在本文中可以称为证明π的元素。

应当注意的是，这里故意省略了ξ。ξ被定义为由验证者设置的挑战。在非交互式ZKP中，ξ可以被定义为W_L、W_R和B或C_i的哈希值。因此，验证者将能够根据上面给出的信息计算出ξ。换句话说，挑战交易1402指定推导出ξ的步骤即可，而不必指定ξ的实际值。验证算法

进而可以从证明π本身推导出ξ的值。

然后，可以如下针对给定的公共临时密钥R实现验证算法

1.基于上述E1-E5验证算术电路的每个门-加法门(如上面的∑_zero部分中所述)和乘法门(如上面的∑_prod部分中所述)；

2.验证其他原像要求，如下所示：

a)提取ko₁＝ρ₁·F；

b)计算

c)检查

即2b)的结果与适用签名的公共临时密钥是否相匹配；

d)检查等式W_m＝w_m·G+ρ_m·F；

e)检查w_m是否确实是h。

注意：步骤e)适用于预先指定h的情况。然而，在哈希冲突赏金的情况下可以省略该步骤，下面将对此进行说明。

对于哈希冲突赏金，接收两个此类证明π₁、π₂。

为了使证明者提供所需的两个证明π₁，π₂，关于由证明者发现的冲突原像，根据证明(第一和第二实例)构建算术电路的两个实例。

在符号上，第一证明π₁的元素是与上面描述完全相同的E1-E7；第二证明π′的等效元素使用相同的字符表示，但加了引号：

E1’)z′_i-每个加法门一个，每个乘法门三个；

E2’)B′_i-每个加法门一个；

E3’)W′_i-每个加法门三个，每个乘法门三个；

E4’)e′_i-每个乘法门两个；

E5’)C′_i-每个乘法门三个；

E6’)ko′₁；

E7’)w′_m和ρ′_m。

然后，可以如下针对给定的公共临时密钥对R₁、R₂实现验证算法

1A.基于E1-E5验证算术电路的第一实例；

1B.基于E1‘-E5’验证算术电路的第二实例；

2A.验证π₁的原像要求：

a)提取ko₁＝ρ₁·F；

b)计算

c)检查

d)检查等式W_m＝w_m·G+ρ_m·F；

2B.验证π₂的原像要求：

a)提取ko′₁＝ρ′₁·F；

b)计算

c)检查

d)检查等式W′_m＝w′_m·G+ρ′_m·F；

3.验证原像的等式：

a)w_m＝w′_m

应当注意的是，如从3a)中显而易见的那样，尽管在图14中h与证明交易1404中的π₁和π₂分开示出，但它实际上并不需要作为单独的元素，并且可以通过w_m＝w′_m隐式定义。

保留输入线w₁、w₁′，并且这些值不可从输入线w₁、w₁′上提供的密钥公开ko₁、ko′₁推导出。通过这种方式，可以在不显示输入线的情况下显示密钥公开。

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

上文在很大程度上是根据基于输出的模型(例如，基于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的专用操作码，因此使用基于堆栈的语言的现有通用操作码将此功能显式地编码到解锁脚本中将是复杂的。还应当注意的是，某些基于账户的模型从用于对该交易进行签名的公钥推导出该交易的源地址。因此，源地址不必在交易中单独编码，并且在公钥从签名推导出的情况下，这意味着源地址也可以间接从签名推导出。

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

更笼统地说，根据本文公开的一个方面(“示例1”)，提供了一种在区块链网络的节点处理至少一笔证明交易的计算机实现的方法。在该节点接收所述至少一笔证明交易，该证明交易包括至少一个椭圆曲线数字签名算法(ECDSA)签名和至少一个零知识证明(ZKP)组成部分。该节点基于与所述交易的ECDSA签名和签名部分相关联的公钥来验证所述证明交易的ECDSA签名，并确定ZKP组成部分对于ECDSA签名以及定义哈希值和定义哈希函数是否正确，因为该ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于定义哈希值相对于定义哈希函数的原像。

下面列出了进一步列举的示例实施例。

示例2.一种根据示例1所述的方法的实施方式，其中所述至少一笔证明交易包括第二ZKP组成部分和第二ECDSA签名，其中节点验证所述第二ECDSA签名，并通过以下方式确定第一和第二ZKP组成部分是否共同证明知道对所述定义哈希函数的碰撞攻击成功：

检查所述第一和第二ECDSA签名是否具有不同的r部分，

确定所述第一ZKP组成部分对于所述ECDSA签名以及所述定义哈希值和所述定义哈希函数是否正确，

确定所述第二ZKP组成部分对于所述第二ECDSA签名以及与所述第一ZKP组成部分相同的定义哈希值和定义哈希函数是否正确，因为所述第二ZKP组成部分证明所述第二ECDSA签名的r部分的对应临时密钥对应于所述定义哈希值相对于所述定义哈希函数的原像。

示例3.一种根据示例2所述的方法的实施方式，其中基于与ECDSA签名相同的公钥验证所述第二ECDSA签名。

示例4.一种根据示例1或2所述的方法的实施方式，其中所述至少一笔证明交易包括防伪签名，所述节点基于与所述ECDSA签名相同的公钥验证所述防伪签名。

示例5.一种根据示例1、2、3或4所述的方法的实施方式，其中所述至少一笔证明交易识别至少一笔挑战交易的代码，从而使所述节点根据所述至少一笔证明交易运行所述至少一笔挑战交易的代码，这又使所述节点通过确定所述ZKP组成部分是否满足所述至少一笔挑战交易的代码中包含的一个或多个证明要求来确定所述至少一笔证明交易的所述或每个ZKP组成部分是否正确。

示例6.一种根据示例5所述的方法的实施方式，其中用于验证所述ECDSA签名的所述公钥在所述至少一笔证明交易中显示，但不是由所述至少一笔挑战交易指定。

示例7.一种根据示例6所述的方法的实施方式，其中所述公钥在所述至少一笔证明交易中被编码为字符串，从而在所述至少一笔证明交易中显示，或从所述至少一笔证明交易的ECDSA签名中推导出，由此所述公钥由所述ECDSA签名本身显示。

示例8.一种根据示例5至7中任一项所述的方法的实施方式，其中所述哈希值在所述至少一笔证明交易中定义，而不是由所述至少一笔挑战交易指定。

示例9.一种根据示例5至7中任一项所述的方法的实施方式，其中所述哈希值在所述至少一笔挑战交易中定义。

示例10.一种根据从属于示例2的示例5至9中任一项所述的方法的实施方式，其中所述至少一笔挑战交易的代码还包含所述第一和第二ECDSA签名具有不同r部分的要求。

示例11.一种根据从属于示例3的示例5至9中任一项所述的方法的实施方式，其中所述至少一笔挑战交易的代码还包含使用相同私钥生成所述第一和第二ECDSA签名的要求。

示例12.一种根据示例5至11中任一项所述的方法的实施方式，其中所述至少一笔挑战交易的代码使所述节点验证所述至少一笔证明交易中的所述ECDSA签名或每个ECDSA签名。

示例13.一种根据示例5至11中任一项所述的方法的实施方式，其中所述挑战交易的代码包括所述挑战交易的一个或多个未花费交易输出的锁定脚本，所述ECDSA签名和所述ZKP组成部分嵌入到所述证明交易的解锁脚本中。

示例14.一种根据示例13所述的方法的实施方式，其中通过将所述挑战交易的锁定脚本与所述证明交易的解锁脚本级联并运行所述级联脚本，根据所述证明交易运行所述挑战交易的代码。

示例15.一种根据示例5至12中任一项所述的方法的实施方式，其中所述至少一笔挑战交易的代码是虚拟机字节码，在所述至少一笔证明交易的一个或多个数据字段中提供所述ZKP组成部分或每个ZKP组成部分。

示例16.一种根据示例5至11中任一项所述的方法的实施方式，其中所述ECDSA签名的验证是由所述节点根据区块链网络的区块链协议执行的隐式函数。

示例17.一种根据示例5至16中任一项所述的方法的实施方式，其中如果所述ZKP组成部分不正确，则所述至少一笔挑战交易的代码返回的结果为“false“，其中所述代码要求所述ZKP组成部分正确，以便返回的结果为“true”。

示例18.一种根据示例17所述的方法的实施方式，其中如果所述ECDSA签名验证失败，则所述代码返回的结果也为“false”，其中所述代码要求所述ZKP组成部分正确且所述ECDSA签名验证成功，以便返回的结果为“true”。

示例19.一种根据从属于示例2的示例17或18所述的方法的实施方式，其中如果任何ECDSA签名验证失败和/或如果任何ZKP组成部分不正确和/或如果所述第一和第二ECDSA签名具有相同的r部分，则返回的结果为“false”，其中为了使返回的结果为“true”，每个所述ECDSA签名需要验证成功，每个所述ZKP组成部分需要正确，所述第一和第二ECDSA签名需要具有不同的r部分。

示例20.一种根据从属于示例4的示例17至19中任一项所述的方法的实施方式，其中防伪签名需要验证成功，以便返回的结果为“true“，如果防伪签名验证失败，则返回的结果为“false”。

示例21.一种根据示例5至20中任一项所述的方法的实施方式，其中所述至少一笔证明交易包括挑战交易的交易标识符，从而识别挑战交易的代码。

示例22.一种根据示例5至20中任一项所述的方法的实施方式，其中所述至少一笔挑战交易将所述代码与账户地址相关联，所述至少一笔证明交易包括匹配的账户地址，从而识别所述挑战交易的代码。

示例23.一种根据示例5至22中任一项所述的方法的实施方式，其中所述哈希函数在所述至少一笔挑战交易中定义。

示例24.一种根据前述任一项示例所述的方法的实施方式，其中执行处理步骤是为了核实所述证明交易，如果确定所述证明交易有效，则所述节点使所述证明交易记录在由区块链网络维护的区块链中。

示例25.一种根据从属于示例17至19中任一项的示例23所述的方法的实施方式，其中所述节点要求由所述挑战交易的代码返回的结果为“true”，以确定所述交易有效。

示例26.一种计算机程序，包括代码，当所述代码在区块链网络节点的一个或多个处理器上运行时，使所述一个或多个处理器处理根据示例1至25中任一项所述的证明交易。

示例27.一种用于区块链网络的节点，所述节点包括：

用于存储代码的存储器；

一个或多个耦合到所述存储器以运行所述代码的处理器，其中当所述代码在所述一个或多个处理器上运行时，使所述一个或多个处理器处理根据示例1至25中任一项所述的在所述网络接口处接收的证明交易。

示例28.一种根据示例27所述的节点的实施方式，其中所存储的代码包括根据示例5或其任何从属示例所述的挑战交易的代码。

示例29.至少一笔挑战交易，包括代码，当所述代码根据至少一笔证明交易在区块链网络节点运行时，使区块链网络节点确定所述至少一笔证明交易的零知识证明(ZKP)组成部分对于所述至少一笔证明交易的椭圆曲线数字签名算法(ECDSA)签名以及定义哈希值和定义哈希函数是否正确，因为所述ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于所述定义哈希值相对于所述定义哈希函数的原像。

示例30.一种根据示例29所述的至少一笔挑战交易的实施方式，其中所述代码用于使所述区块链网络节点基于与所述至少一笔证明交易的所述ECDSA签名和签名部分相关联的公钥来验证所述至少一笔证明交易的所述ECDSA签名。

示例31.一种方法，包括以下步骤：根据示例29或30创建至少一笔挑战交易，并将所述至少一笔挑战交易提交给区块链网络的节点进行处理。

示例32.一种交易生成计算机系统，包括：

网络接口；

用于存储代码的存储器；

耦合到所述存储器以运行所述代码的一个或多个处理器，其中当所述代码在所述一个或多个处理器上运行时，使所述一个或多个处理器根据示例29或30创建至少一笔挑战交易，并通过网络接口将所述至少一笔挑战交易提交给区块链网络的节点进行处理。

示例33.至少一笔用于在区块链中重新编码的证明交易，所述至少一个证明包含在计算机可读数据介质上，包括椭圆曲线数字签名算法(ECDSA)签名、签名部分和至少一个零知识证明(ZKP)组成部分，所述ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于定义哈希值相对于定义哈希函数的原像，而在所述至少一笔证明交易中不透露原像。

示例34.一种根据示例33所述的证明交易的实施方式，包括至少两个ZKP组成部分和至少两个具有不同r部分的ECDSA签名，其中所述至少两个ZKP组成部分证明所述不同r部分对应于相对于所述定义哈希函数的碰撞原像，而不透露所述碰撞原像。

示例35.一种根据前述任一项示例所述的方法、交易节点或系统的实施方式，其中所述ZKP组成部分或每个ZKP组成部分涉及算术电路，证明所述算术电路的一组电路线满足所述哈希函数，并且透露(i)所述算术电路的输出线和(ii)所述算术电路的输入线上的密钥公开，而不透露所述输入线。

示例36.一种根据示例35所述的方法、交易、节点或系统的实施方式，其中所述节点基于所述ZKP组成部分验证所述算术电路，并使用所述密钥公开检查与所述输入线相关联的线密钥是否与所述ECDSA签名的r部分相匹配。

示例37.一种根据示例35至36中任一项所述的方法、交易、节点或系统的实施方式，其中所述哈希值由输出线定义。

示例38.一种根据示例1至27或35至37中任一项所述的方法的实施方式包括：使用所述至少一个ZKP组成部分识别所述区块链网络或其他基于所述哈希函数保护的加密系统中的漏洞，以及采取一项或多项措施来缓解识别的漏洞。

示例39.根据示例38所述的方法，其中所述一项或多项措施包括以下一项或多项措施：

撤销依赖于哈希函数的数字证书，

赎回区块链交易的一个或多个未花费输出，基于哈希函数锁定所述一个或多个未花费输出，以防止恶意方利用攻击来赎回所述一个或多个未花费输出。

对于包括目标交易的多笔交易中的每笔交易，网络中的至少一些节点被配置为在交易有效的条件下传播每笔交易，并且至少一些节点被配置为在交易有效的条件下将每笔交易记录在该节点处的区块链的副本中。目标交易的有效性至少取决于ECDSA签名是否有效以及ZKP组成部分是否正确。

在实施例中，为了核实证明交易，可以由节点处理上述交易中的任何交易，并且如果所述证明交易被确定为有效，则所述节点使所述证明交易记录在由区块链网络维护的区块链中。

例如，此类核实可以应用于UTXO模型。

替代地或附加地，上述交易中的任何交易可以由返回TRUE结果和FALSE结果之一的节点来处理(并且在该情况下可能需要或可能不需要TRUE结果才能使所述交易有效)。

例如，在基于账户的模型中，有效交易仍可能返回所述FALSE结果。

在任何r难题上下文中，可能的情况是，用于验证至少一笔证明交易的ECDSA签名的公钥在所述至少一笔证明交易中指示，但未由至少一笔挑战交易(或所述区块链上的其他地方或以其他方式)指定。因此，可以使用任何私钥来生成所述ECDSA签名(因此，无论使用谁的私钥来生成签名，签名都可以是有效的)。

公钥可以被编码为所述至少一笔证明交易中的字符串，并由此在所述至少一笔证明交易中指示，或者从所述至少一笔证明交易的所述ECDSA签名推导出，由此由所述ECDSA签名本身指示所述公钥。

所述至少一笔证明交易可以包括所述挑战交易的交易标识符，并由此指示所述挑战交易(或其适用组成部分，如r难题、代码等)。

替代地，所述至少一笔挑战交易可以将r难题、代码或其他组成部分与账户地址相关联，并且所述至少一笔证明交易可以包括匹配的账户地址，并因此指示所述挑战交易的所述组成部分。

根据在本文中所公开的另一方面，可以提供一种包括第一方(挑战者)、第二方(证明者)、可能涉及的任何第三方和节点网络(区块链网络)的动作的方法。

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

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

Claims (39)

1.一种在区块链网络的节点处理至少一笔证明交易的计算机实现的方法，所述方法包括：

接收所述至少一笔证明交易，其中所述至少一笔证明交易包括至少一个椭圆曲线数字签名算法(ECDSA)签名和至少一个零知识证明(ZKP)组成部分；

基于与所述至少一笔证明交易的ECDSA签名和签名部分相关联的公钥来验证所述至少一笔证明交易的ECDSA签名；

通过确定ZKP组成部分对于ECDSA签名以及定义哈希值和定义哈希函数是否正确，确定至少一个ZKP组成部分是否证明知道哈希函数攻击成功，因为所述ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于所述定义哈希值相对于所述定义哈希函数的原像。

2.根据权利要求1所述的方法，其中所述至少一笔证明交易包括第二ZKP组成部分和第二ECDSA签名，其中节点验证所述第二ECDSA签名，并通过以下方式确定第一和第二ZKP组成部分是否共同证明知道对所述定义哈希函数的碰撞攻击成功：

检查所述第一和第二ECDSA签名是否具有不同的r部分，

确定所述第一ZKP组成部分对于所述ECDSA签名以及所述定义哈希值和所述定义哈希函数是否正确，

确定所述第二ZKP组成部分对于所述第二ECDSA签名以及与所述第一ZKP组成部分相同的定义哈希值和定义哈希函数是否正确，因为所述第二ZKP组成部分证明所述第二ECDSA签名的r部分的对应临时密钥对应于所述定义哈希值相对于所述定义哈希函数的原像。

3.根据权利要求2所述的方法，其中基于与ECDSA签名相同的公钥验证所述第二ECDSA签名。

4.根据权利要求1或2所述的方法，其中所述至少一笔证明交易包括防伪签名，所述节点基于与所述ECDSA签名相同的公钥验证所述防伪签名。

5.根据权利要求1、2、3或4所述的方法，其中所述至少一笔证明交易识别至少一笔挑战交易的代码，从而使所述节点根据所述至少一笔证明交易运行所述至少一笔挑战交易的代码，这又使所述节点通过确定所述ZKP组成部分是否满足所述至少一笔挑战交易的代码中包含的一个或多个证明要求来确定所述至少一笔证明交易的所述或每个ZKP组成部分是否正确。

6.根据权利要求5所述的方法，其中用于验证所述ECDSA签名的所述公钥在所述至少一笔证明交易中显示，但不是由所述至少一笔挑战交易指定。

7.根据权利要求6所述的方法，其中所述公钥在所述至少一笔证明交易中被编码为字符串，从而在所述至少一笔证明交易中显示，或从所述至少一笔证明交易的ECDSA签名中推导出，由此所述公钥由所述ECDSA签名本身显示。

8.根据权利要求5至7中任一项所述的方法，其中所述哈希值在所述至少一笔证明交易中定义，而不是由所述至少一笔挑战交易指定。

9.根据权利要求5至7中任一项所述的方法，其中所述哈希值在所述至少一笔挑战交易中定义。

10.根据从属于权利要求2的权利要求5至9中任一项所述的方法，其中所述至少一笔挑战交易的代码还包含所述第一和第二ECDSA签名具有不同r部分的要求。

11.根据从属于权利要求3的权利要求5至9中任一项所述的方法，其中所述至少一笔挑战交易的代码还包含使用相同私钥生成所述第一和第二ECDSA签名的要求。

12.根据权利要求5至11中任一项所述的方法，其中所述至少一笔挑战交易的代码使所述节点验证所述至少一笔证明交易中的所述ECDSA签名或每个ECDSA签名。

13.根据权利要求5至11中任一项所述的方法，其中所述挑战交易的代码包括所述挑战交易的一个或多个未花费交易输出的锁定脚本，所述ECDSA签名和所述ZKP组成部分嵌入到所述证明交易的解锁脚本中。

14.根据权利要求13所述的方法，其中通过将所述挑战交易的锁定脚本与所述证明交易的解锁脚本级联并运行所述级联脚本，根据所述证明交易运行所述挑战交易的代码。

15.根据权利要求5至12中任一项所述的方法，其中所述至少一笔挑战交易的代码是虚拟机字节码，在所述至少一笔证明交易的一个或多个数据字段中提供所述ZKP组成部分或每个ZKP组成部分。

16.根据权利要求5至11中任一项所述的方法，其中所述ECDSA签名的验证是由所述节点根据区块链网络的区块链协议执行的隐式函数。

17.根据权利要求5至16中任一项所述的方法，其中如果所述ZKP组成部分不正确，则所述至少一笔挑战交易的代码返回的结果为“false”，其中所述代码要求所述ZKP组成部分正确，以便返回的结果为“true”。

18.根据权利要求17所述的方法，其中如果所述ECDSA签名验证失败，则所述代码返回的结果也为“false”，其中所述代码要求所述ZKP组成部分正确且所述ECDSA签名验证成功，以便返回的结果为“true”。

19.根据从属于权利要求2的权利要求17或18所述的方法，其中如果任何ECDSA签名验证失败和/或如果任何ZKP组成部分不正确和/或如果所述第一和第二ECDSA签名具有相同的r部分，则返回的结果为“false”，其中为了使返回的结果为“true”，每个所述ECDSA签名需要验证成功，每个所述ZKP组成部分需要正确，所述第一和第二ECDSA签名需要具有不同的r部分。

20.根据从属于权利要求4的权利要求17至19中任一项所述的方法，其中防伪签名需要验证成功，以便返回的结果为“true”，如果防伪签名验证失败，则返回的结果为“false”。

21.根据权利要求5至20中任一项所述的方法，其中所述至少一笔证明交易包括挑战交易的交易标识符，从而识别挑战交易的代码。

22.根据权利要求5至20中任一项所述的方法，其中所述至少一笔挑战交易将所述代码与账户地址相关联，所述至少一笔证明交易包括匹配的账户地址，从而识别所述挑战交易的代码。

23.根据权利要求5至22中任一项所述的方法，其中所述哈希函数在所述至少一笔挑战交易中定义。

24.根据前述任一项权利要求所述的方法，其中执行处理步骤是为了核实所述证明交易，如果确定所述证明交易有效，则所述节点使所述证明交易记录在由区块链网络维护的区块链中。

25.根据从属于权利要求17至19中任一项的权利要求23所述的方法，其中所述节点要求由所述挑战交易的代码返回的结果为“true”，以确定所述交易有效。

26.根据前述任一项权利要求所述的方法，包括：

使用所述至少一个ZKP组成部分识别所述区块链网络或其他基于所述哈希函数保护的加密系统中的漏洞，

采取一项或多项措施来缓解识别的漏洞。

27.根据权利要求26所述的方法，其中所述一项或多项措施包括以下一项或多项措施：

撤销依赖于哈希函数的数字证书，

赎回区块链交易的一个或多个未花费输出，基于哈希函数锁定所述一个或多个未花费输出，以防止恶意方利用攻击来赎回所述一个或多个未花费输出。

28.一种计算机程序，包括代码，当所述代码在区块链网络节点的一个或多个处理器上运行时，使所述一个或多个处理器处理根据权利要求1至27中任一项所述的证明交易。

29.一种用于区块链网络的节点，所述节点包括：

用于存储代码的存储器；

一个或多个耦合到所述存储器以运行所述代码的处理器，其中当所述代码在所述一个或多个处理器上运行时，使所述一个或多个处理器处理根据权利要求1至27中任一项所述的在所述网络接口处接收的证明交易。

30.根据权利要求29所述的节点，其中所存储的代码包括根据权利要求5或其任何从属权利要求所述的挑战交易的代码。

31.至少一笔挑战交易，包括代码，当所述代码根据至少一笔证明交易在区块链网络节点运行时，使区块链网络节点确定所述至少一笔证明交易的零知识证明(ZKP)组成部分对于所述至少一笔证明交易的椭圆曲线数字签名算法(ECDSA)签名以及定义哈希值和定义哈希函数是否正确，因为所述ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于所述定义哈希值相对于所述定义哈希函数的原像。

32.根据权利要求31所述的至少一笔挑战交易，其中所述代码用于使所述区块链网络节点基于与所述至少一笔证明交易的所述ECDSA签名和签名部分相关联的公钥来验证所述至少一笔证明交易的所述ECDSA签名。

33.一种方法，包括以下步骤：根据权利要求31或32创建至少一笔挑战交易，并将所述至少一笔挑战交易提交给区块链网络的节点进行处理。

34.一种交易生成计算机系统，包括：

网络接口；

用于存储代码的存储器；

耦合到所述存储器以运行所述代码的一个或多个处理器，其中当所述代码在所述一个或多个处理器上运行时，使所述一个或多个处理器根据权利要求29或30创建至少一笔挑战交易，并通过网络接口将所述至少一笔挑战交易提交给区块链网络的节点进行处理。

35.至少一笔用于在区块链中重新编码的证明交易，所述至少一个证明包含在计算机可读数据介质上，包括椭圆曲线数字签名算法(ECDSA)签名、签名部分和至少一个零知识证明(ZKP)组成部分，所述ZKP组成部分证明ECDSA签名的r部分的对应临时密钥对应于定义哈希值相对于定义哈希函数的原像，而在所述至少一笔证明交易中不透露原像。

36.根据权利要求35所述的证明交易，包括至少两个ZKP组成部分和至少两个具有不同r部分的ECDSA签名，其中所述至少两个ZKP组成部分证明所述不同r部分对应于相对于所述定义哈希函数的碰撞原像，而不透露所述碰撞原像。

37.根据前述任一项权利要求所述的方法、交易节点或系统，其中所述ZKP组成部分或每个ZKP组成部分涉及算术电路，证明所述算术电路的一组电路线满足所述哈希函数，并且透露(i)一组电路线的输出线和(ii)所述一组电路线的输入线上的密钥公开，而不透露所述输入线。

38.根据权利要求37所述的方法、交易、节点或系统，其中所述节点基于所述ZKP组成部分验证所述算术电路，并使用所述密钥公开检查与所述输入线相关联的线密钥是否与所述ECDSA签名的r部分相匹配。

39.根据权利要求37至38中任一项所述的方法、交易、节点或系统，其中所述哈希值由输出线定义。

Images