CN116210200A - 区块链通证 - Google Patents

区块链通证 Download PDF

Info

Publication number
CN116210200A
CN116210200A CN202180066069.2A CN202180066069A CN116210200A CN 116210200 A CN116210200 A CN 116210200A CN 202180066069 A CN202180066069 A CN 202180066069A CN 116210200 A CN116210200 A CN 116210200A
Authority
CN
China
Prior art keywords
transaction
script
certification
output
payment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180066069.2A
Other languages
English (en)
Inventor
斯坦尼斯拉夫·(斯塔斯)·特洛克
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Taldite Ltd
Original Assignee
Taldite Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Taldite Ltd filed Critical Taldite Ltd
Publication of CN116210200A publication Critical patent/CN116210200A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种通证事务，包括第一通证输出，所述第一通证输出包括第一通证锁定脚本和第一通证数量，其中所述第一通证锁定脚本包括变量组件和常量组件，其中所述变量组件包括第一支付地址，其嵌入在支付模板中，并且其中所述常量组件包括通证机制子组件。

Description

区块链通证
技术领域
本公开涉及一种使用区块链事务发送(例如，发行、转移、拆分、交换、兑换)通证的方法。
背景技术
区块链允许使用事务(transaction)转移标的数字资产(underlyingdigitalasset)。该数字资产通常称为“加密货币”或“原生通证”，是特定区块链固有的数字资产。作为说明性示例，比特币区块链的数字资产称为比特币。
可以使用区块链转移的另一种类型的数字资产是“通证”。在区块链技术环境中，通常使用事务中的附加数据字段来创建和定义通证。区块链用户或特定通证协议的用户将这种称为“通证数据”的附加数据解释为通证。也就是说，用户同意将包含特定通证数据(例如，通证协议标志后跟数量)的事务，或者更具体地是事务的输出部分，解释为通证并用作通证。谁拥有输出(通常意味着输出锁定到其地址的用户)，谁就拥有通证。然后，可以根据特定通证协议为达到特定目的而使用、销售、交易通证。例如，电影票可以向用户发行通证，用户随后支付通证以换取在电影院观看电影，或者银行可以发行通证以换取其客户的美元存款，客户可以在定期支付中使用这些存款，然后第三方在银行换回美元。
发明内容
如上所述，之前使用区块链创建通证的尝试涉及在事务的附加数据字段中定义通证，通常是通过将通证数据包括在输出脚本代码的未执行部分中，甚至是所述事务附加的单独未花费输出中。这些通证不同于在其上创建通证的区块链的标的数字资产(其本身由其原生通证构成)。也就是说，根据这些先前的方案，包含通证的事务正常使用所述标的数字资产(或“原生通证”)，同时还在附加数据结构中创建新通证。所述新通证与所述原生通证无关。
将新创建的通证与其原生关联者分离需要繁重且不必要的协调，为了实现这种协调进行的所有最新尝试都失败了，最终阻止了所述通证达到预期的大规模采用。
根据本文提供的一个方面，提供了一种使用区块链事务发送数字通证的计算机实现的方法。每个通证由区块链的标的数字资产原生单位的单个单位表示。所述方法包括：生成第一通证事务，以及将所述第一通证事务传输到区块链网络。所述第一通证事务包括第一通证输出，并且所述第一通证输出包括第一通证锁定脚本和第一通证数量。所述第一通证锁定脚本包括变量组件和常量组件。所述变量组件包括嵌入在支付模板中的第一支付地址。所述常量组件包括通证机制子组件，当与花费事务的输入脚本一起执行时，所述输入脚本包括除其自身以外的所有的所述花费事务、以及相应的锁定脚本和正在被花费的先前事务输出中锁定的数量，所述通证机制子组件被配置为执行以下操作。第一操作包括：从所述花费事务的所述输入脚本获得一个或多个数据对，每个数据对包括i)包括在所述花费事务输出的相应锁定脚本中的至少相应支付地址，和ii)由所述输出的所述相应锁定脚本锁定的所述标的数字资产的对应数量。另一操作包括：验证所述花费事务的一个或多个输出包括相应的锁定脚本，所述锁定脚本包括a)包括预定支付地址的相应支付脚本模板，或b)包括除了所述预定支付地址以外的相应支付地址的相应变量组件，后跟所述常量组件。另一操作包括：对于所述花费事务的一个或多个输出，验证由所述一个或多个输出的所述相应锁定脚本锁定的所述标的数字资产的总量等于所述第一通证数量。所述通证机制子组件被配置为：如果验证步骤中的任意一项失败，则在执行期间失效。
与之前的通证尝试不同，根据本发明的新发行的通证是所述标的数字资产通证本身。也就是说，所述原生通证本身转换为一种新的通证类型。这些新通证不再执行其作为所述原生通证的常规功能，除非在发行时根据自身编码的某些特定条件转换回所述标的数字资产。
为了花费、分配或以其他方式转移通证，并因此发挥通证的作用，要成功的花费事务必须在其后续输出中具有与正在花费的先前事务输出(称为UTXO*)相同格式的锁定脚本。也就是说，与正在花费的所述通证事务输出一样，为了能够成功传输，所述花费事务必须包括具有锁定脚本的输出，所述锁定脚本具有与新通证输出相同的常量组件。在通证的整个生命周期内，所述常量部分在兑换之前既不能改变，也不能省略。
所述常量部分是所述通证的代码部分，在其各种操作中，为了将通证的性质从一个事务转换为另一个事务：1)其自身的不可变性；2)其自身遗漏的不可能性；以及3)最重要的是，保持通证数量，也就是说，锁定所述通证，使其数量(全部或部分)既不会作为矿工费用泄露(在总输出数量小于总输入数量的情况下)，也不会花费到除其自身智能锁定脚本格式输出以外的任何地方(除非兑换到指定地址，在发行时自行编码)。
简言之，所述常量部分使原生通证无法在执行新定义的通证时正常使用，从而改变原生通证的性质。
这会导致所述标的数字资产的每个单个单位现在都代表重新定义的单个通证，并停止其正常功能。继续以所述比特币区块链为例，单个聪现在重新定义为单个通证。一个或多个通证的所有者不能将所述一个或多个通证移动到另一个用户，除非所述锁定脚本包含完全相同的常量组件，这将执行新的通证机制。所述锁定脚本中可以更改的只有变量组件，所述变量组件可以是负责转移所有权的标准模板(例如，以与标的资产的原生通证相同的方式使用)，也就是说，使当前所有者能够根据此类标准模板中包含的地址将所述一个或多个通证的部分或全部移动到后续的所有者。
换言之，与之前依赖元数据附件来表示通证的尝试不同，根据该方案，本发明的通证是所述标的数字资产的单个单位，已被重新配置为用作不同的实体，按照不同的规则(自身编码)进行操作。
如上所述，当且仅当所述通证满足上述脚本常量部分中编码的特定条件
(例如，移动到预定兑换地址)时，所述通证才可以转换回所述标的数字资产，即，再次用作所述原生通证。也就是说，只有硬编码用户或机构(即，对所述兑换地址具有控制权的实体)才有能力将所述通证变回常规标的数字资产的性质，从而恢复其原始功能。
附图说明
为了帮助理解本公开的实施例并显示如何实施此类实施例，现将仅通过举例的方式参考附图进行说明，其中：
图1示意性地示出了示例性通证事务；
图2示意性地示出了示例性通证锁定脚本；
图3A和图3B示意性地示出了常规通证事务和原子交换通证事务之间的区别；以及
图4示意性地示出了通证从发行到兑换的示例性流程。
具体实施方式
本发明的实施例涉及区块链事务的创建和传输。虽然技术人员将熟悉区块链技术本身，但在详细描述实施例本身之前，首先提供区块链的简要概述。
区块链是分布式数据库(或分类账)的一种形式，作为传输到区块链网络的所有有效事务的记录。
在区块链网络上广播的有效事务由矿工(也称为挖矿节点)以区块的形式记录在区块链上。区块链事务用于转移一定数量的数字资产的保管权(即，所有权)。示例性区块链是比特币区块链，其数字资产称为比特币。存在许多不同的区块链，本发明不限于任何特定的实现方式。除其他事项外，每个事务包括至少一个输入和至少一个输出。输入包括对先前事务的未花费事务输出(UTXO)的引用。事务使用未花费事务输出(UTXO)作为输入，并将其值分配给新的输出。输出通常包括锁定该输出的值的锁定条件，要求在新的后续事务的输入中提供某些数据(例如，一组签名或其他信息)，以便解锁。输出也可以用于将数据(例如，文本、图像等)记入分类账。事务的输入通常包括对所述事务的至少一部分进行签名的数字签名。因此，事务链包括数字签名链，所述数字签名链描绘了数字资产有效交换的整个历史记录，一直追溯到其创建。
区块链以“创世区块”开始，这是有史以来创建的第一个区块。区块链上的每个区块都引用了先前区块，一直追溯到所述创世区块。也就是说，第n个区块引用第n-1个区块，第n-1个区块引用第n-2个区块，依此类推，直到所述创世区块。
区块包含区块链事务的有序列表和区块头。区块头包括通过将区块链事务的有序列表哈希处理为默克尔树而生成的默克尔根、时间戳、对当前区块基于其构建的先前区块的引用，以及核实其他矿工接受该区块作为有效区块所需的“工作量证明”的手段。该核实手段是对每个区块都唯一的哈希难题的答案。区块链网络的挖矿节点运行的区块链协议使用哈希算法，所述哈希算法要求这些矿工在尝试解决难题之前预先构建候选区块。如果没有正确的答案，新的区块就无法提交给网络，“挖矿”的过程本质上是竞争成为下一个找到“解决”当前区块的答案的过程。每个区块中的哈希难题很难解决，但一旦找到有效的解决方案，网络的其余部分就很容易确认该解决方案是正确的。任何给定的区块都有多个有效的解决方案，对于要求解的区块，只需要找到其中一个解决方案。
下面简要描述了尝试将新区块挖掘到区块链的过程。当区块链事务传输到挖矿节点时，首先根据区块链网络的共识规则对其进行核实。如果事务有效，则将其添加到未确认事务的池中。所述池有时称为“内存池”。内存池充当要挖掘到下一区块中的事务的临时存储池。每个挖矿节点都有自己的内存池，如果任何给定事务已经广播到多个挖矿节点，则可以包含在多个内存池中。
矿工获取其打算包含在下一区块中的事务，然后将所述事务哈希处理到默克尔树结构中，并将生成的默克尔根包含在候选区块头中。然后，矿工对该候选区块头进行哈希处理，试图找到有效的工作量证明。默克尔树是一种哈希值树形式的数据结构。在区块链环境中，对事务进行哈希处理，以形成树的叶节点。在叶节点对级联后进行哈希处理，以在树的更高层中形成节点。然后对该层中的节点对进行级联和哈希处理，以在树的更高层中形成节点。重复该过程，直到只剩一个节点，称为根节点或默克尔根。
哈希函数是一种将任意长度的数据字符串转换为固定长度的唯一(事实上冲突概率为零)值的函数，该值称为哈希值或哈希摘要。哈希是单向函数，这意味着通过查看输入数据产生的哈希值来确定输入数据是不可行的。另一方面，通过相同的哈希函数运行相同的输入数据并重新生成相同的哈希非常简单。一些区块链协议使用SHA-256哈希算法，而一些协议使用两次SHA-256哈希算法，即，候选区块头通过相同的哈希算法传递两次。
对候选区块头(结合其他数据，如下文所述)进行哈希处理，直到结果小于另一个值(称为目标值)，从而可以找到有效的工作量证明。目标值通过区块链协议自动调整，因此，区块链网络平均需要10分钟才能找到有效的工作量证明。
为了改变哈希值，挖矿节点必须向候选区块头添加附加信息。挖矿节点通常使用两个“随机数字段”来更改要进行哈希处理的值，从而更改生成的哈希值。第一随机数字段包含在区块头本身中，第二随机数字段包含在“Coinbase事务”中。Coinbase事务是由挖矿节点创建并包含在候选区块中的事务。每个字段包括一个可以递增的计数器参数。哈希函数循环遍历第一随机数字段的所有值，然后递增(或以其他方式更改)第二随机数字段，然后再次遍历所述第一随机数字段的全部排列。递增第二随机数字段涉及在修改默克尔树中包含的Coinbase事务的哈希时重新计算默克尔根。
当挖矿节点找到区块(即，哈希处理到小于目标值的值的候选区块头)的有效工作量证明哈希时，将新区块广播到区块链网络的其余部分。只有在新区块中的所有事务均有效且尚未包含在区块中时，网络上的其他节点才接受该新区块。每个区块都有时间戳，并引用其上一区块的哈希，从而形成区块链，因此使用术语“区块链”。
现在将更详细地描述区块链事务。下表是根据一些区块链协议的典型事务结构的示意图。应当理解的是，不同的区块链协议可以使用不同的事务结构。因此，以下讨论仅针对上下文，并非用于限制所有实施例。
如下表所示，事务由一组数据字段组成。原始形式的事务由通常以十六进制表示的一组序列化数据字段组成。
Figure BDA0004146452600000061
一个事务具有一个或多个输入，每个输入引用先前事务的输出。每个输入可以引用相同的先前事务的不同输出，或不同事务的输出，或其组合。每个输入包含一个解锁脚本(有时称为“ScriptSig”)，如果包含正确的数据，该解锁脚本将解锁引用的输出。然后，当前事务的输出可以花费(即，分配给该输出)先前事务的未锁定输出，或者更确切地说是之前锁定到该输出的数字资产的数量。数字资产的解锁数量可以通过单个输出全部花费，也可以分布在当前事务的多个输出中。
事务还具有一个或多个输出，所述输出共同分配输入解锁的数字资产的总量。通常，输出值之和小于输入值之和，差值作为费用支付给在新区块中记录事务的挖矿节点。输出可以是可花费输出，也可以是不可花费输出。可花费输出包含锁定脚本(有时称为“ScriptPubKey”)，所述锁定脚本定义了一个或多个条件，必须满足这些条件才能被后续事务的输入解锁。不可花费输出不包含可以解锁的锁定脚本。换句话说，不可花费输出包含会导致锁定脚本的执行失败的锁定脚本。
本发明的实施例使第一方(称她为“爱丽丝Alice”)能够向第二方(称他为“鲍勃Bob”)发送一个或多个通证。以下描述中的至少部分描述将涉及第一方爱丽丝向第二方鲍勃发送通证。然而，应当注意的是，这仅用于说明目的。这些实施例同样适用于第二方鲍勃向第三方(例如，商家)发送通证。此外，还将涉及通证发行者，即最初发行通证的一方(例如，爱丽丝)。此外，以下描述中的至少部分描述将涉及“第一通证事务”。除非上下文另有要求，否则第一通证事务可以由爱丽丝、鲍勃或通证发行者中的任何一者创建。
图4示出了示例性系统，该系统包括多方，例如通证发行者、爱丽丝、鲍勃和商家。虽然术语“一方”可以用于指用户(例如，爱丽丝)，但是一方可以采取其他形式，例如公司或其他形式的组织等用户集体。也不排除一方可以是自主实体，即，基于一个或多个条件执行预定动作的实体。此类自主实体在本领域中有时称为“代理”。
虽然图中未示出，但各方操作相应的计算机设备。各方的计算机设备包括相应的处理装置，其包括一个或多个处理器，例如一个或多个CPU、GPU、其他加速器处理器、特定应用程序处理器和/或FPGA。各方的计算机设备还包括存储器，即采用非瞬时性计算机可读介质形式的计算机可读存储器。该存储器可以包括一个或多个存储器单元，其采用一个或多个存储器介质，例如诸如硬盘等磁介质、诸如SSD、闪存或EEPROM等电子媒介和/或诸如光盘驱动器等光学介质。各方的计算机设备上的存储器存储软件，其包括被设置为在处理装置上运行的至少一个客户端应用程序的相应实例。应当理解的是，在本文中归因于给定方的任何动作均可通过在相应计算机设备的处理装置上运行的软件执行。各方的计算机设备包括至少一个用户终端，例如台式电脑或笔记本电脑、平板电脑、智能手机或诸如智能手表等可穿戴设备。给定方的计算机设备还可以包括一个或多个其他网络资源，诸如通过用户终端访问的云计算资源。
客户端应用程序最初可通过例如从服务器下载的适当计算机可读存储介质，或通过诸如可移动SSD、闪存密钥、可移动EEPROM、可移动磁盘驱动器、软盘或磁带等可移动存储设备、诸如CD或DVD ROM等光盘或可移动光驱等提供至任何给定方的计算机设备。
通证发行者是向初始接收者(例如，爱丽丝)发行一个或多个通证的一方。可以使用通证发行者生成的初始通证事务向爱丽丝发行一个或多个通证，或者爱丽丝自己可以生成初始通证事务。例如，通证发行者和爱丽丝可以就要向爱丽丝发行的通证数量(以及任何其他适用的合同条件)达成一致，然后爱丽丝可以通过将一个或多个通证移动到另一方(例如，鲍勃)来有效地向自己发行通证。
爱丽丝(或通证发行者)生成初始通证事务。该通证事务包括一个或多个输入以及一个或多个输出。如果需要，所述输入中的一个输入可以用作向挖矿节点支付事务费用的费用支付，以在区块中记录通证事务。事务费用并不总是必需的，因此此类费用支付并不必要。与所有区块链事务一样，通证事务包括用于解锁先前事务的输出的输入。对于初始通证事务，先前事务的引用输出必须至少包括重新配置为通证的标的资产的数量。如图4所示，初始通证数量为1000，因此引用的输出必须具有至少1000个标的资产单位的值。应当理解的是，该数字是任意选择的，通常可以使用任何数字作为初始通证数量。为简洁起见，标的资产的单位称为聪。虽然这是比特币区块链的特定单位，但这绝不限于所有实施例。
初始通证事务包括第一通证输出。所述第一通证输出锁定初始通证数量
(1000聪Satoshi)。也就是说，所述第一通证输出包括第一通证锁定脚本，该脚本将初始聪量锁定为相同数量的新定义的通证。所述第一通证锁定脚本包括变量组件和常量组件。换句话说，所述变量组件是所述第一通证锁定脚本的一个部分(即，一部分)，而所述常量组件是所述第一通证锁定脚本的另一个部分(即，一部分)。顾名思义，不同通证事务中的变量组件可能会有所不同，而常量组件将保持不变。
所述变量组件是通证锁定脚本的一部分，允许通证移动到另一方。所述变量组件包括包含(例如，围绕)支付地址的支付模板。所述支付地址可以基于接收方的公钥。例如，所述支付地址可以是公钥哈希(PKH)地址，即，公钥的哈希(或双重哈希)。如果初始通证事务是由通证发行者生成的，则所述支付地址将链接到爱丽丝。如果爱丽丝生成初始通证事务，所述支付地址将由爱丽丝选择。爱丽丝可以选择链接到自己的另一个地址，或者可以选择链接到鲍勃或商家等另一方的地址。所述支付地址可以视为所述变量组件的子组件。所述变量组件可以包括一个或多个附加常量子组件。例如，所述变量组件可以包括一个或多个常量操作码(opcode)，用于创建支付到公钥哈希(P2PKH)格式输出。
所述常量组件包括通证机制子组件，简称为“通证子组件”，是所述常量组件的常量子组件。所述通证子组件是所述第一通证锁定脚本的一部分，可以将标的数字资产重新用作通证，例如，将1000聪转换为1000个通证。所述通证子组件被配置为从花费事务的输入获得数据，并执行至少两个验证步骤。此外，所述通证子组件被配置为在验证失败时导致通证锁定脚本的执行失败。即，如果任何一个验证步骤失败，则通证锁定脚本的执行以及花费事务输入的解锁脚本的执行将失败。
所述通证子组件要求花费事务的输入(特别是输入的解锁脚本)包括某些数据，以便有效执行。所述花费事务的所述输入称为花费输入。具体地，所述花费输入的解锁脚本必须包括所述花费事务的至少部分数据，即，除了所述解锁脚本本身以外的花费事务数据(某些部分按原样，而仅对其他部分的结果进行哈希处理)。从现在起，该数据称为哈希原像(因为其哈希作为ECDSA验证公式中的输入)，或者直接称为原像。所述原像包括所述花费事务和正在花费的事务的字段，以及基于这些事务字段生成(哈希处理)的数据项。在其他实施例中，所述花费事务的所有数据字段逐字包括在所述花费输入的所述解锁脚本中。
所述通证子组件被配置为在执行时，从所述花费输入的所述解锁脚本获得除原像以外的一个或多个数据对。每个数据对至少包括所述花费事务的锁定脚本的支付地址，以及该锁定脚本锁定的标的数字资产的对应数量。在一些示例中，所述花费事务仅包含一个输出，即，一个锁定脚本。在这种情况下，所述通证子组件获得一个数据对。在其他示例中，所述花费事务包含多个输出，即，多个锁定脚本。在这种情况下，所述通证子组件获得多个数据对。
可以通过解析所述花费输入的所述解锁脚本并提取数据对来获得所需的数据。这可能需要在预定义位置将数据对包含在解锁脚本中。下面提供了更详细的讨论。
在获得一个或多个数据对之后，所述通证子组件被配置为验证所述花费事务的一个或多个输出具有特定格式。所述花费事务的至少一个输出必须包括预定支付地址(仅作为预定标准支付模板的一部分)或任意地址(作为预定标准支付模板的一部分)，但也必须后跟通证输出的常量组件(即，完全相同的常量组件)。所述通证子组件可以确定并验证所述花费事务的多个输出包括嵌入到预定标准支付模板中的任意支付地址，后跟通证输出的常量组件。所述花费事务可以验证所述花费事务包括不包含预定支付地址(仅具有其对应的标准模板)或任意支付地址(具有其对应的标准模板)的一个或多个输出，后跟通证输出的常量组件。
所述通证子组件还被配置为验证花费事务(包含预定支付地址或后跟常量组件的任意支付地址)的输出锁定的值之和等于所述初始通证数量(即，与其相同)。包含预定支付地址或常量组件的花费事务的输出可以称为智能通证输出。所述通证子组件验证智能通证输出锁定的通证总数等于所述初始通证数量，从而防止其泄漏回原始格式或任何其他使用格式。
例如，考虑所述花费事务包含单个智能通证输出(所述花费事务的第一输出)的情况。所述通证子组件被配置为验证所述花费事务的所述第一输出具有采用特定格式或更确切地说包含特定数据的第一锁定脚本。具体地，所述第一锁定脚本必须包含预定支付地址(作为支付模板的一部分)或任意支付地址(作为支付模板的一部分)，后跟通证锁定脚本的常量组件。只需要这两个地址中的一个地址，但如果这两个地址都缺失，验证将会失败。该验证过程是可实现的，因为所述通证子组件已经从花费输入的解锁脚本中获得了所述花费事务的所述第一锁定脚本。因此，所述通证子组件可以在所述第一锁定脚本中搜索预定支付地址或常量组件。
如上文所述，所述花费事务可以包含多个输出。一些附加输出也可以是智能通证输出，或者可以用于不同的目的。在这种情况下，所述通证子组件被配置为验证所述花费事务的多个输出包含预定支付地址或任意支付地址，后跟通证事务的常量组件(即，通证锁定脚本的常量组件)。根据实现方式，所述通证子组件可以被配置为验证花费事务的多个输出中的每个输出都包括预定支付地址或常量组件。在其他示例中，所述通证子组件可以被配置为验证多个输出中的一些而不是全部输出包含预定支付地址或常量组件。例如，所述通证子组件可以验证花费事务的预定数量的输出包含常量组件，例如前两个输出(即，花费事务中逻辑上最先出现的两个输出)。
在花费事务包括单个智能通证输出的示例中，所述通证子组件被配置为验证所述花费事务的所述第一锁定脚本锁定的标的数字资产的第一数量等于所述初始通证数量(即，1000聪)。在本文中，具有所述第一锁定脚本的所述第一输出是所述花费事务中逻辑上最先出现的输出。
如果所述花费事务包括多个输出，例如具有锁定数字资产的第二数量的第二锁定脚本的第二输出，则所述通证子组件被配置为验证所述第一数量和所述第二数量之和等于所述初始通证数量。在本文中，所述第二输出是所述花费事务中逻辑上第二个出现的输出。通常，如果所述花费事务包括包含预定支付地址或常量组件的多个输出，则所述通证子组件验证其相应的数量之和等于所述初始通证数量。
对于所述花费事务的任意数量的输出，可以重复该过程。可以允许所述花费事务包含锁定数字资产数量的输出，这将导致所述花费事务的所有输出锁定的数字资产之和大于初始通证数量。在这种情况下，所述通证子组件被配置为验证所述花费事务的预定数量的智能通证输出一起锁定了等于所述初始通证数量的数字资产数量，并且不考虑非智能通证输出锁定的数量。非智能通证输出可以是费用变更输出或原子交换输出。例如，通证事务的前两个输出锁定的总数必须等于所述初始通证数量，而第三输出(例如，费用变更输出)可以锁定由附加输入提供资金的附加数量。应当注意的是，所述第三输出用于说明目的。费用变更输出将在下文中详细讨论。现在可以说，只有在费用变更输出(或不同类型的“附加输出”)不是通证输出(即，不包含通证锁定脚本的常量组件)时，才允许这样做。
通证锁定脚本的常量组件可以包含预定支付地址。也就是说，预定支付地址可以硬编码到常量组件中，因此必须包括在所述花费事务的所述第一锁定脚本中。预定支付地址可以是兑换地址，例如部分或全部通证可以移动到此处以便兑换除通证以外的其他事项(例如，法定货币)的地址。
如上文所述，花费事务的花费输入的解锁脚本可以包括原像。所述原像可以包括下表所示字段中的一个、部分或全部。
Figure BDA0004146452600000111
应当注意的是，包括原像的这种特定结构是为了说明目的，可以使用其他结构，例如，数据字段的大小可以根据用于实现本发明的特定区块链而有所不同。
在这些示例中，通证子组件可以被配置为通过从原像中提取来获得初始通证事务的通证锁定脚本(即，输入的scriptCode)和初始通证数量(即，输入花费的输出值)。由于原像的所有数据字段(scriptCode除外)的大小都是已知的，因此所述通证子组件可以通过解析和提取预定位置的数据来提取所需字段。
如上表所示，原像可以包括花费事务的输出的哈希(hashOutput)。这是每个输出的哈希，即，锁定脚本锁定的值和锁定脚本本身。因此，如果花费事务包含单个输出，则hashOutput包含与一个锁定脚本级联的一个值的哈希。如果花费事务包含两个输出，则每个值锁定脚本对级联后进行哈希处理，以形成hashOutput。所述通证子组件可以通过解析和提取特定位置的数据等方式从原像中提取hashOutput。
如上文所述，花费事务的解锁脚本包含一个或多个数据对。需要记住的是，每个数据对包括一个值和一个锁定脚本。所述通证子组件可以被配置为生成其自己的hashOutput版本，即生成一个或多个数据对的哈希，然后验证所述生成的哈希是否等于从原像中提取的哈希(即，hashOutput)。这样做可能是为了确认花费用户(例如，爱丽丝或鲍勃)在花费事务的解锁脚本中包含了正确的数据对。
在一些示例中，所述通证子组件可以被配置为验证花费事务的解锁脚本中包括的原像已经正确生成，即，原像的数据字段对应于花费事务的实际数据字段。如果不能假定系统用户能够正确地生成花费事务，则这是必要的。为此，所述通证子组件生成其自己的花费事务的预期原像版本，例如，包含上表中所有数据字段的原像。然后，所述通证子组件可以验证从花费事务的解锁脚本中提取的原像是否与通证子组件生成的原像匹配。
验证花费事务的解锁脚本中包含的原像是否正确的一种方式是使用本领域中称为OP_PUSH_TX的伪操作码。然而，可以改用任何等效的操作码，或者更通俗地说，执行与OP_PUSH_TX等效的功能的任何等效码。
通常，所述通证子组件可以被配置为使用来自解锁脚本的原像和私钥来生成数字签名(例如，ECDSA签名)。所述私钥包含在花费事务的解锁脚本中。然后，在针对所述生成的原像(即，所述通证子组件生成的原像)和对应于所述私钥的公钥进行核实时，所述通证子组件验证所述数字签名是有效签名。所述公钥也包含在花费事务的解锁脚本中。只有在这两个原像完全匹配时，所述数字签名才有效。由于所述使用的私钥因记录在区块链上而公开，因此应使用“虚拟”私钥，即，在泄露时不会危及其他数据或区块链事务的安全的私钥。然而，通常可以使用任何私钥，例如，任何随机密钥。可以通过使用OP_CHECKSIG操作码验证签名来执行这种签名检查。OP_CHECKSIG是一个操作码，仅当签名用于当前事务(即，本例中的花费事务)时，该操作码才会成功(即，成功执行)。
回到花费事务的输出，所述通证子组件可以被配置为验证花费事务的一个或多个输出(具体地，其相应的锁定脚本)包含预定类型(即，格式)的相应支付地址。优选地，所述相应支付地址必须与通证事务的变量组件中包含的支付地址类型相同。更优选地，所述支付地址必须是PKH地址。这可以仅基于支付地址本身进行验证，或者可以基于支付地址和一个或多个附加数据项(例如，支付地址两侧的一个或多个操作码或其他数据)进行验证。例如，P2PKH输出包括可以在输出中检查的某些附加数据。
上面已经讨论了所述常量组件的通证子组件。所述常量组件还可以包括常量数据子组件(简称为“数据子组件”)。通常，所述数据子组件可以包含要存储在每个通证输出中的任何数据。例如，所述数据子组件可以包括通证协议标识符，例如，指示通证属于特定协议的标志，例如，指示通证代表法定货币。附加地或替代地，所述数据子组件可以包括记录在区块链上的事务
(称为“通证发行事务”)的事务标识符(TxID)。同样地，所述通证发行事务通常可以包含任何数据，例如，通证发行者发行的通证发行合同和/或初始通证数量。所述数据子组件可以包含在OP_RETURN操作码或执行等效功能的码之后。
以上描述主要涉及初始通证事务和花费事务。下面将更详细地描述花费事务，其本身是通证事务。花费事务将称为“第一通证事务”，以便为引用第一通证事务的输出的后续事务保留术语“花费事务”。
将结合图1描述所述第一通证事务。如图1所示，第一通证事务100包括事务标识符(通证TxID)、一个或多个输入104以及一个或多个输出106。每个输入104包括输入值108和解锁脚本110。应当注意的是，图1是示意图。输入104本身不包含输入值108。相反，输入104包含指向先前输出的未花费事务输出(UTXO)的指针(例如，TXID和VOUT)，所述先前输出锁定值108，该值现在称为输入值108。然而，示出相应解锁脚本110解锁的值108是为了进行说明。每个输出106包括输出值112和锁定脚本114。
首先将描述第一通证事务100的输出106，因为上面已经结合花费事务对其进行了描述。通证事务100至少包括第一通证输出(“兑换/通证输出”)。第一通证输出如图2所示。如图2所示以及如上文所述，第一通证输出200包含变量组件202和常量组件204。常量组件204包含通证机制子组件206，在该示例中，还包含常量数据子组件208。
变量组件202包含向其分配第一通证数量(例如，700个通证)的一方的相应支付地址。通证子组件206被配置为执行上述验证步骤中的部分或全部步骤。例如，通证子组件206被配置为验证花费事务的预定数量(例如，一个或两个)的输出锁定的数字资产的总量等于第一通证数量(700个通证)。第一通证输出200的通证子组件206还被配置为验证尝试解锁第一通证输出200的后续花费事务的输入包括具有包括兑换支付地址的常规支付模板或包括变量组件202和常量组件204的第一通证输出200的完整格式的输出。通常，通证子组件206可以被配置为执行前面描述的任何验证技术。
第一通证事务100还可以包含第二通证输出。所述第二通证输出还包含相应的变量组件和相应的常量组件。与第一通证输出200的变量组件202相比，所述第二通证输出的所述变量组件可以包含不同的支付地址。所述第二通证输出的所述通证子组件被配置为执行与第一通证输出200的通证子组件206相同的验证步骤，不同之处在于现在验证是不同的花费事务(即，具有引用所述第二通证输出的输入的花费事务)。换句话说，第一通证事务100可以具有多个输出，这些输出中的每个输出可以由不同的花费事务花费(解锁)。例如，所述第二通证输出的所述通证子组件被配置为验证花费事务的预定数量(例如，一个或两个)的输出锁定的数字资产的总量等于第二通证数量
(300)。
第一通证事务100可以包含任意数量的通证输出，只要其相应的通证数量之和恰好等于所述第一通证输出中锁定的值(1000个通证)(由事务输入中的TXID字段引用)，就试图进行花费。
第一通证事务100可以包含费用变更输出。该输出使费用变更(X-δ)能够返回到费用变更支付地址。在图1所示的示例中，使用具有输入值(X)的费用支付输入支付事务费用(δ)。
附加地或替代地，第一通证事务100可以包含原子交换输出。下面将描述所述原子交换输出。
在图1所示的示例中，第一通证事务100包括通证输入。所述通证输入相当于上文中详细描述的花费输入。更具体地，所述通证输入引用先前通证事务(例如，所述初始通证事务)的通证输出。在该示例中，所述引用的通证输出锁定1000个通证。所述通证输入包括除其自身以外的所述第一通证事务的全部内容，包括第一通证事务200的每个输出106的相应数据对。也就是说，在该示例中，所述通证输入包括三个值(700、300、X-δ)和三个对应的支付地址，每个地址来自通证的每个锁定脚本(“兑换/通证输出”、“通证输出(拆分)”、“费用变更/原子交换”)。值112和支付地址可以配对，使得第一通证数量(700)后跟来自第一通证输出锁定脚本的支付地址，其次是第二通证数量(300)以及来自第二输出锁定脚本的相应支付地址，等等。所述通证输入还包括用于解锁所述引用的通证输出的签名(即，与所述引用的通证输出的变量组件中包含的支付地址对应的签名)。如果爱丽丝正在移动通证，则爱丽丝的签名将包含在花费事务的输入中。在一些示例中，整个锁定脚本可以包含在输入中(即，作为数据对的一部分)，而不仅仅是支付地址。
如图1所示，第一通证事务100包括费用支付输入。所述费用支付输入引用先前的不同的常规非通证事务输出的输出，并且包括为将第一通证事务100包括在区块中而支付给挖矿节点的费用。所述费用支付输入包括至少一个数字签名，具体取决于其引用的输出的要求。在一些示例中，所述数字签名由第一通证事务100的通证输入所引用的通证输出的所有者生成。例如，如果爱丽丝将1000个通证中的700个通证发送给鲍勃，将300个通证发送给商家，则爱丽丝可以为事务提供资金。在这种情况下，爱丽丝的签名包含在费用支付输入中。然而，不排除另一方(例如，鲍勃)可以通过解锁锁定到鲍勃的UTXO来为事务提供资金。在这种情况下，鲍勃的签名包含在费用支付输入中。上面提到了原子交换输出，在这种情况下，矿工费用支付输入有额外的支付任务(针对通证)。在该示例中，鲍勃通过在费用/“通证购买”输入中包含其签名来为事务提供资金，而“费用变更”/“原子交换”输出锁定到鲍勃。也就是说，“费用变更”/“原子交换”输出包括链接到鲍勃的支付地址，例如，鲍勃拥有的公钥的哈希。
为了执行原子交换，爱丽丝创建了除费用/“通证购买”支付输入以外的完整事务。然后，鲍勃创建并添加费用/“通证购买”支付输入。其中一种方式是爱丽丝用sighash标志(例如，ALL|ANYONECANPAY)对其输入(即，通证输入)和两个对应的输出进行签名，该标志使另一方能够添加输入。然后，鲍勃添加带有不同sighash标志(例如，ALL，完成整个事务，不允许对其进行任何进一步的添加)的输入。
图3A和图3B更详细地说明了原子交换的概念。实线箭头表示强制输入和输出，虚线箭头表示可选输入和输出。图左侧示出了事务的输入，右侧示出了事务的输出。图3A示意性地示出了与图1类似的事务。该示例性通证事务包括爱丽丝生成的解锁先前通证事务的通证输出的通证输入，以及用于支付事务费用(挖矿节点记录区块中的事务所收取的费用)的费用支付输入。所述通证事务还包括发送给鲍勃的通证输出，其中所述通证输出锁定到以通证格式(例如，200)包含在内的地址；以及费用变更输出，其中所述费用变更输出以常规支付格式向爱丽丝支付锁定到其地址的变更(在其输出中指定的变更是费用输入支付和事务费用之间的差值)。
图3B示出了原子交换事务的示例。鲍勃的通证输出以与图3A相同的方式生成。爱丽丝再次生成通证输入，用于解锁先前通证事务的通证输出，但这次她使用‘ALL/ANYONECANPAY’sighash标志对事务进行签名。这意味着爱丽丝的签名对所有输出进行签名，但只对这一个输入(即，花费使用该sighash标志进行签名的通证输出的输入)进行签名。不包括其余输入。该sighash标志使任何人都能够添加或删除其他输入，因此任何人都可以向事务中添加资金，但不能更改其去向和数量。这使得鲍勃能够只添加其支付输入，其中也包括矿工费用。鲍勃具有签名，同时使用‘ALL’sighash标志进行签名。这意味着鲍勃的签名对所有输入和输出进行签名，从而保护所有元素不受任何进一步可能的修改。在该示例中，向爱丽丝支付第二输出，由此添加鲍勃的输入。这具有执行原子交换的效果，因此，当且仅当鲍勃向爱丽丝支付通证时，才会向鲍勃发送通证。如果鲍勃对事务的任何组成部分不满意，他就不提供签名，因此通证不会移动到他的地址，爱丽丝不会收到支付。同样地，由于鲍勃不能修改爱丽丝创建和签名的输入和输出，爱丽丝可以确保鲍勃只能在满足爱丽丝设置的支付条件的情况下接收通证。
图4示出了通证从发行到兑换的示例性流程。流程通常是从上到下。作为可选的第一步，通证发行者和初始接收者爱丽丝之间拟定法律合同。所述合同可以规定通证的各项条款和条件，包括如何兑换通证，以及初始通证数量
(例如，1000)。然后，通证发行者可以创建初始通证事务，并将通证发送给爱丽丝。或者，爱丽丝可以创建初始通证事务，并将其中的部分或全部通证发送给另一个用户(例如，鲍勃)，甚至发送给自己。在图4中，爱丽丝将所有通证发送给鲍勃，即，所有通证都分配给发送到鲍勃的支付地址的单个通证输出。鲍勃随后创建具有两个通证输出的通证事务。第一通证输出将300个通证发送到商家的支付地址。第二通证输出将700个通证发送到鲍勃的支付地址，该支付地址可以是鲍勃的另一个支付地址。然后，商家兑换其300个通证，即，通过将通证发送到兑换支付地址。然后，鲍勃最初也兑换500个通证，同时将剩余的200个通证发送到链接到鲍勃的另一个支付地址。最后，鲍勃兑换200个通证。需要注意的是，在每个事务中，传入通证的数量与传出通证的数量匹配。
上面已经大体描述了本发明的实施例。现在将描述本发明的具体实现方式。该特定示例主要根据代表法定货币的通证进行描述，即，通证是与法定货币挂钩的通证。然而，这只是本发明的许多可能的用例中的一个用例。此外，该示例旨在使用比特币区块链实现。然而，通常可以使用任何基于输出
(例如，基于UTXO)的区块链，其中比特币区块链是一个特定示例。
根据该示例，通证使用比特币表示，或者更具体地，使用比特币的基本单位(称为聪或聪单位)表示。通证输出可以包括表示单个通证(例如，事件、电影票、公共汽车票等的实用型通证)的单个聪。因此，该通证是不可分割的，在其生命周期内不能拆分。或者，通证输出可以包括代表多个通证
(例如，与美元挂钩的通证是代表1美分的通证)的包的多个聪。
通证输出包括变量部分和常量部分。变量部分与常规比特币支付模板相同，该模板通过使用ECDSA传递比特币(即，聪)的所有权。在通证的整个生命周期内，常量部分既不能更改也不能省略。
现在，每个聪代表一个通证，并停止其正常功能，尽管它可以代表比一个聪本身更便宜或更昂贵的东西。爱丽丝无法将任何通证移动到鲍勃，除非她在后续通证事务中保留该模板作为锁定脚本。只能更改变量部分的所有权地址。
应当注意的是，这与之前使用元数据将输出解释为通证输出的通证尝试不同。本发明从根本上改变了聪作为比特币的常规用途的机制。
变量部分故意放在通证锁定脚本的开头，只是常规支付模板(例如，P2PKH模板)。这提供了与现有区块链客户端应用程序和浏览器的最大兼容性，并使支付地址(封装在模板中)能够以当前方式进行搜索和定位。
通证机制部分至少执行三个条件。首先，只有在下一UTXO具有与正在花费的UTXO完全相同的锁定脚本(新的所有权地址除外)时，才可能使用通证花费。其次，使用常规比特币锁定脚本模板(例如，P2PKH、P2PK等)的事务的花费失败，除非该模板是包含预定兑换支付地址的P2PKH。预定兑换支付地址包含在发给爱丽丝的合同中，并且硬编码到通证锁定脚本中。如果通证发行者将兑换地址设置为链接到其自身的地址，这意味着只有发行者有能力将代表资产的聪恢复为作为聪的原始常规用途，例如通过释放代表的美元、黄金等资产，这使得通证无需许可。第三，在移动通证时，当前未花费通证输出(UTXO)的通证输出中聪的数量必须与花费事务(例如，兑换或后续通证事务)的通证输出中聪的数量完全相同，或者拆分为两组或多组通证，其数量之和必须等于UTXO的原始数量。例如，通证可以拆分为花费事务的两个输出，这两个输出的锁定脚本与正在花费的UTXO的锁定脚本相同(变量部分的地址除外)。
在这些有状态事务中推入的状态是每次跳动更新的所有权地址以及(仅在通证包的情况下)通证的数量，其中通证可以通过拆分减少。
常量数据部分有两个字段。一个字段包含通证协议标识符，例如，与法定货币挂钩的通证的通证协议标志。该标识符用于指定通证类型。第二字段是指向特殊事务的指针(TxID)，其中包含：a)初始发行合同(例如，发行实体和客户之间的初始发行合同)及其所有法律条款、条件、许可和与通证属性和发行相关的任何其他必要信息；以及b)预定在具有通证输出的后续事务(发行事务)中转换为通证的确切聪余额。
常量数据字段放在OP_RETURN操作码后面，只是一个数据附件，避免在脚本求值过程中作为脚本代码的一部分尝试执行。也就是说，常量数据优选地包含在锁定脚本的末尾，紧接在OP_RETURN操作码之后，以最大限度地兼容对OP_RETURN事务执行搜索的应用程序和浏览器。
就事务结构本身而言，通证事务的输出可以采取以下三种类型中的一种类型：i)用于兑换的常规输出；ii)通证输出；或iii)用于费用变更、原子交换等的常规输出。
例如，爱丽丝可以请求合法授权实体代表其发行1000个通证，并向该实体提供其支付地址。该实体以可花费事务的形式创建协议，其中预分配的聪数量对应于所述请求的数量(本例中为1000)。协议的条款、条件和许可规定了爱丽丝所需的动作(例如，向实体转移对应数量的法定货币)，并由实体签名，例如，带有ALL|ANYONECANPAY标志，使爱丽丝能够添加其签名。一旦爱丽丝签名并将协议发布到区块链，并且执行规定的所需动作(转移一定数量的法定货币)，实体就代表她向她的支付地址发行通证。爱丽丝现在可以一次性使用/花费/转移所有通证或部分通证。随后的持有者可以随意兑换通证，因此通证无需许可。
回到通证输出的常量部分，常量部分大致包括两部分。第一部分实现OP_PUSH_TX，负责在脚本执行中访问当前事务的字段。第二部分是通证逻辑。
上面描述了sighash原像。OP_PUSH_TX执行与当前事务(即，解锁通证输出的花费事务)对应的原像的ECDSA签名，该通证输出已推入解锁脚本，以便在执行的脚本中访问。OP_PUSH_TX最终调用OP_CHECKSIG来验证签名。这种内部ECDSA签名是使用可公开访问的任意私钥公钥对(一个临时密钥对，一个常量密钥对)执行的，因此所述私钥公钥对应该与用于通证所有权转让的私钥公钥对无关。此外，在本例中，OP_CHECKSIG充当核实者，因为在调用时，它从实际的先前和当前事务字段构建自己的ECDSA验证原像。因此，它会失败或成功，具体取决于实际字段是否与推入解锁脚本的字段相同。
通证逻辑将比特币聪转化为通证。为此，代码需要访问先前事务(即，包含通证的未花费输出)的聪值(数量)以及当前事务(即，花费事务)的聪值，以控制聪花费。代码还需要访问先前和当前锁定脚本，以控制输出锁定脚本的格式。
一旦推入当前(花费)事务的解锁脚本中的原像经核实与实际的当前事务原像相同，就会对其进行解析，以提取所有相关字段，包括scriptCode和该输入所花费的输出的值，以及hashOutput。虽然锁定脚本和先前UTXO
(即，正在花费的UTXO)的值(即，数量)在原像中原样提供，但是只有所有新创建的输出的锁定脚本(与新值相结合)的哈希处理结果可用。因此，这些新输出的锁定脚本及其对应的值应放在花费事务的解锁脚本中的原像旁边，然后根据原像的hashOutput字段进行核实，之前已经证明过该字段在调用时与OP_CHECKSIG构建的字段相同。
一旦正在执行的代码可以访问先前和后续事务输出的所有锁定脚本及其值(即，数量)，就可以执行通证规则。
可以执行以下示例性规则。应当理解的是，可以根据特定用例实现其他附加或替代规则。在该示例中，允许以下情况：
1.兑换功能——用于定义硬编码地址，该地址可以将通证的性质变回聪的原生性质，即标的数字资产。
2.最多将通证的数量分为两个可能的输出。
3.第三可选输出具有P2PKH格式，用于对矿工费用支付的变更(change)进行接收，通过附加输入完成，或者在“原子交换”的情况下，用于通证出售者接收货币。
更具体地说，规则是：
1.通证事务的第一输出仅用于：
a)兑换——标准P2PKH模板，包括强制硬编码兑换地址，或者
b)通证转让——与先前输出格式相同的智能通证锁定脚本。
2.第二输出对于通证拆分的情况是可选的，并且只能是智能通证类型。此外：
a)如果存在第二输出，其输出数量和第一输出的数量之和必须等于正在花费的UTXO中的数量。
b)否则，第一输出的数量必须等于正在花费的UTXO中的数量。
3.第三输出只是标准的P2PKH模板(地址是任意地址)。如果第三输出存在，则用于更改通证操作的支付(即，通过附加输入完成)。
应当注意的是，P2PKH模板是事务输出脚本，当推入VarInt(指定以下脚本的长度)0x19前面的解锁脚本时，其十六进制形式为“0x76a914+PKH+0x88ac”，因为其长度为25字节。PKH是公钥哈希地址。
现在提供执行这些规则的示例性伪代码。
Figure BDA0004146452600000191
Figure BDA0004146452600000201
以下代码示出了采用比特币脚本语言的实际示例性实现方式。对于该实现方式中，解锁脚本参数的使用顺序与上面的伪代码函数定义中的顺序(从左到右)相同，这意味着首先从最左边推入栈中。硬编码的兑换函数地址设置为锁定脚本的“常量代码”部分的第一字段，因此紧接在解锁脚本数据之后推入栈中(如果不考虑进行ECDSA签名验证的变量部分)。
应当注意的是，该脚本实现方式是空间优化的，而不是时间优化的(因为目前用比特币的费用支付仅取决于TX大小)。
//‘变量数据’部分模板(P2PKH)，其后跟随兑换地址和原像提取：
OP_DUP OP_HASH160 2f2ec98dfa6429a028536a6c9451f702daa3a333OP_EQUALVERIFY OP_CHECKSIG OP_VERIFY25daa25932d355826ce60881978f79621f1dfcd9 OP_7OP_ROLL OP_DUP
//OP_PUSH_TX的实施
OP_HASH256 OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLITOP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLIT OP_1OP_SPLITOP_1OP_SPLITOP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLITOP_1 OP_SPLITOP_1 OP_SPLIT OP_1 OP_SPLIT OP_1 OP_SPLIT OP_1OP_SPLIT OP_SWAP OP_CAT OP_SWAPOP_CAT OP_SWAP OP_CATOP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAPOP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CATOP_SWAP OP_CAT OP_SWAP OP_CATOP_SWAP OP_CAT OP_SWAPOP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CATOP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAPOP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CATOP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAPOP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 00OP_CAT
4091de8968a1066ab9c6f292823ab43111fb1d0630f3f087e7e42f03533f92a2d779753ff4a0922831cf7fd3692ec96055665621e97adc95a8a45766e3e0c26a OP_ADD119ef8f4f04e6864c0608c6d71018e00fb2d17049a8750644299c78b547c2924OP_MUL 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00OP_TUCK OP_MOD OP_2DUPOP_SWAP OP_2 OP_DIVOP_GREATERTHAN OP_IF OP_SUB OP_ELSE OP_NIP OP_ENDIF OP_SIZEOP_DUP 25 OP_ADD 30 OP_SWAP OP_CAT022100c7a2f4a156ecd42ba9326b31a86c61225dec5a71c3238408f360a9d2f3cf0be002 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IFOP_SPLIT OP_SWAP OP_ENDIF OP_ENDIF OP_SIZE OP_DUP OP_IFOP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAP OP_ENDIF OP_ENDIFOP_SIZE OP_DUP OP_IF OP_1SUB OP_DUP OP_IF OP_SPLIT OP_SWAPOP_ENDIF OP_ENDIF OP_CAT OP_CAT OP_CAT OP_CAT OP_CATOP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CATOP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CATOP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CAT OP_CATOP_CAT OP_CAT OP_CAT OP_CAT 41OP_CAT03ea9a8e84d865bcd6fc0d1354816bc2eb423a6adf80e42654f1edc101ed033ce3OP_CHECKSIGVERIFY
//将sighash原像解析为4个相关字段：VarInt(长度),scriptCode,value(待花费的数额),hashOutputs(或有输出的哈希，和与其匹配的相应的数量)
68OP_SPLIT OP_NIP OP_3OP_SPLIT 17OP_SPLIT OP_NIP OP_OVER OP_1OP_SPLITOP_NIP 00OP_CAT 17OP_SUB OP_SPLIT OP_8OP_SPLIT OP_4OP_SPLIT OP_NIP 20OP_SPLITOP_DROP
//准备第一输出数量
OP_10OP_ROLL OP_8OP_NUM2BIN OP_DUP
//根据地址构造第一输出脚本(智能通证锁定脚本或用于兑换的标准
‘P2PKH’)
OP_11OP_ROLL OP_DUP OP_8OP_ROLL OP_EQUAL
OP_NOTIF OP_6OP_PICK 76a914 OP_CAT OP_SWAP OP_CAT OP_5OP_PICK OP_CAT
OP_ELSE 1976a914 OP_SWAP OP_CAT 88ac OP_CAT
OP_ENDIF
//将第一个输出脚本与其先前准备的数量进行配对(级联)
OP_CAT
//构建第二可选智能输出(如果存在)
//强制执行通证数量的不变性(对于两种情况-拆分或单纯转移)
OP_8OP_PICK
OP_IF OP_9OP_PICK OP_8OP_NUM2BIN OP_CAT OP_5OP_PICK76a914 OP_CAT OP_9OP_PICK OP_CAT OP_5OP_PICK OP_CAT OP_CATOP_3OP_ROLL OP_ROT OP_9OP_PICK OP_ADD OP_NUMEQUALVERIFYOP_ELSE OP_3OP_ROLL OP_ROT OP_NUMEQUALVERIFY
OP_ENDIF
//构建用于变更的第三可选标准P2PKH输出(如果存在)
OP_4OP_PICK
OP_IF OP_5OP_PICK OP_8OP_NUM2BIN OP_CAT 1976a914 OP_5OP_PICK OP_CAT88ac OP_CAT OP_CAT
OP_ENDIF
//核实所有新的输出及传递到解锁脚本的其相应的数额(位于堆栈顶部)
//是正确的-它们的哈希结果与来自原像的hashOutputs字段相同(紧随堆栈顶部)，
//在最初一步，其就被证明其与实际花费事务一致。
OP_HASH256 OP_EQUAL
//常量数据部分
OP_RETURN 27ed5442ab151b32db7b586d433879d84af3398a723c903d83cdce9f32246a451652f4b4f469ef78d630bf0f22770cb16bbc187b
结论
应当理解的是，上述实施例仅通过示例的方式进行描述。
更一般地说，根据本文公开的一个方面，提供了一种使用区块链事务发送数字通证的计算机实现的方法，其中每个通证由区块链的标的数字资产原生单位(underlyingdigital asset native units)的单个单位(unit)进行表示，其中所述方法包括：生成第一通证事务；以及，将所述第一通证事务传输到区块链网络；其中所述第一通证事务包括第一通证输出，所述第一通证输出包括第一通证锁定脚本和第一通证数量，其中所述第一通证锁定脚本包括变量组件和常量组件，其中所述变量组件包括嵌入到支付模板中的第一支付地址，其中所述常量组件包括通证机制子组件，并且其中，当与花费事务的输入脚本一起执行时，所述输入脚本包括除其自身以外的所有的所述花费事务、以及相应的锁定脚本和正在被花费的先前事务输出中锁定的数量，所述通证机制子组件被配置为：从所述花费事务的所述输入脚本获得一个或多个数据对，每个数据对包括：i)至少一相应支付地址，其包括在所述花费事务输出的相应锁定脚本中，和ii)所述标的数字资产的对应数量，其由所述输出的所述相应锁定脚本锁定；验证所述花费事务的一个或多个输出包括相应的锁定脚本，所述锁定脚本包括：a)相应支付脚本模板，其包括预定支付地址，或b)相应变量组件，其包括除了所述预定支付地址以外的相应支付地址，后跟所述常量组件；以及，对于所述花费事务的一个或多个输出，验证由所述一个或多个输出的所述相应锁定脚本锁定的所述标的数字资产的总量等于所述第一通证数量；并且，其中，如果任何验证步骤失败，则所述通证机制子组件被配置为在执行期间失败。
花费事务包括至少一个输出，所述输出包括第一锁定脚本格式。花费事务可以包括第二输出和第三输出等多个输出，每个输出具有相应的锁定脚本格式。为了使事务成功，这些花费事务的新输出的所有锁定脚本必须具有与正在花费的先前事务的输出相同的智能通证格式，或者具有含有预定兑换地址的标准支付模板。唯一的例外是可选输出(例如，最后一个输出)，其锁定脚本必须是标准支付模板，其中包含任意地址，例如，用于变更矿工费用支付(如果需要)，或用于原子交换支付接收。花费事务的输入应包含每个输出的数据对以及整个事务的sighash原像，其哈希处理结果作为ECDSA验证公式的输入。通证机制子组件被配置为基于这一假设操作——如果不满足该假设，通证机制子组件的执行将失败，使得无法进行任何通证操作。
如果花费事务有额外的可选矿工费用变更输出，则也是这种情况，该输出不包括试图花费的输出的第一通证锁定脚本的常量组件。此类可选输出中锁定的原生通证不是通过一个事务到另一个事务的新定义通证的保留量的一部分。
花费事务的某些部分以原始形式包含在输入脚本中，而其他部分则作为哈希处理结果包含在内。
每个支付地址可以嵌入到支付模板中。
在一些实施例中，所述花费事务可以包括第一输出和第二输出，所述第一输出包含第一锁定脚本，所述第二输出包含第二锁定脚本，其中所述通证机制子组件被配置为：验证所述花费事务的所述第一输出包括第一锁定脚本，所述第一锁定脚本包括：a)包括预定支付地址的相应支付脚本模板，或b)包括除了所述预定支付地址以外的相应支付地址的相应变量组件，后跟所述常量组件；验证所述花费事务的所述第二输出(如果存在)包括第二锁定脚本，所述第二锁定脚本包括：a)包括预定支付地址的相应标准支付脚本模板，或b)包括除了所述预定支付地址以外的任何地址的相应变量组件，后跟所述常量组件；以及，如果所述第二输出存在，则验证由所述花费事务的所述第一锁定脚本和所述第二锁定脚本锁定的所述数字资产的所述总量等于所述第一通证数量。
在一些实施例中，所述通证机制组件可以被配置为：如果所述花费事务的所述第一锁定脚本不包括包含预定支付地址的所述标准支付脚本模板，则验证所述第一锁定脚本包括相应变量组件，所述相应变量组件包含除了所述预定支付地址以外的一个支付地址，其后跟所述常量组件，所述常量组件与正在花费的先前事务的所述第一通证锁定脚本的对应常量组件相同；和/或，如果所述花费事务的所述第二锁定脚本存在，则验证所述第二锁定脚本包括相应变量组件，所述相应变量组件包含任何支付地址，其后跟所述常量组件，所述常量组件与正在花费的先前事务的所述第一通证锁定脚本的对应常量组件相同。
在一些实施例中，所述常量组件可以包括所述预定支付地址。
换句话说，预定地址硬编码在常量部分中。
在一些实施例中，所述花费事务的所述输入脚本可以包括sighash原像，其中所述原像包括所述第一通证锁定脚本、和所述第一通证数量，其中所述通证机制子组件被配置为：从所述原像中提取正在被花费的所述输出的所述第一通证数量和所述第一通证锁定脚本，以执行所述验证步骤。
花费事务的输入中包含的第一通证锁定脚本是试图花费的输出的锁定脚本，与当时正在执行的锁定脚本相同。花费事务的输入中包含的第一通证数量是试图花费的输出中保留的值。
在一些实施例中，所述原像可以包括一个或多个数据对的级联的哈希，每个数据对包括来自所述花费事务的相应锁定脚本的相应支付地址以及由所述相应锁定脚本锁定的对应数量，其中所述通证机制子组件被配置为：从所述原像中提取一个或多个数据对的所述级联的所述哈希；基于所述一个或多个数据对生成哈希；以及，验证所述生成的哈希等于所述提取的哈希。
根据花费事务输出的格式，所述“对应数量”中的一个或多个对应数量可以是原生通证，例如可选变更或“原子交换”支付接收的输出，所述对应数量中的一个或多个对应数量可以是重新定义的通证，例如用于兑换或通证输出。
在一些实施例中，用于生成所述哈希的所述一个或多个数据对可以：或者是从所述输入脚本获得的，或者是通过从所述原像获得所述先前输出锁定脚本的输入地址和数量对来构建的。
对“哈希”的任何引用可以等同于“双重sha256哈希”。通常，只要自始至终使用同一哈希函数，就可以使用任何哈希函数。
在一些实施例中，所述通证机制子组件可以被配置为：生成所述花费事务数据的原像；以及，验证所述花费事务数据的所生成的原像等于所述花费事务的所述输入中包含的所述原像。
在一些实施例中，所述花费事务的所述输入可以包括虚拟私钥(dummyprivatekey)和对应的虚拟公钥，其中所述通证机制子组件被配置为：通过以下方式验证所述花费事务的所生成的原像等于所述花费事务的所述输入中包含的所述原像：使用所述虚拟私钥以及所述花费事务的所述输入中包含的所述原像的所述哈希来生成数字签名；以及，在针对所述虚拟公钥和所述花费事务的所生成的原像的哈希进行核实时，验证所述数字签名是有效签名。
根据特定的签名算法，例如，用于生成ECDSA签名，可能需要虚拟私有临时私钥。
例如，通证机制子组件可以包括OP_PUSH_TX伪操作码实现方式，其被配置为对生成的原像执行所述验证。
在一些实施例中，所述通证机制子组件可以被配置为：验证所述花费事务的相应锁定脚本中包括的所述相应支付地址与所述第一通证输出的所述变量组件中包括的所述第一支付地址的类型相同。
此外，通证机制子组件可以被配置为验证花费事务的相应一个或多个输出包括与第一通证输出中包含的支付脚本模板相同类型的相应支付脚本模板，例如P2PKH锁定脚本。
在一些实施例中，所述第一支付地址的所述类型可以是公钥哈希地址。
在一些实施例中，所述第一通证数量可以包括所述标的数字资产的单个单位。
在一些实施例中，所述第一通证数量可以包括所述标的数字资产的多个单位。
在一些实施例中，所述常量组件可以包括数据子组件，其中所述数据子组件包括以下一项或两项：通证协议标识符；通证发行事务的标识符，其中所述通证发行事务包括以下一项或两项i)通证发行者和初始通证接收者之间的发行合同，ii)初始通证数量。
常量不可变数据子组件可以放置在OP_RETURN操作码之后。
在一些实施例中，所述花费事务可以包括第三输出，所述第三输出包括第三锁定脚本和对应的第三数量，其中所述通证机制子组件被配置为：验证所述第三锁定脚本包括预定支付类型模板中的相应支付地址及其相应的对应数量。例如，P2PKH支付模板中的PKH地址。
在一些实施例中，所述第一通证事务可以包括第一通证输入，所述第一通证输入花费先前通证事务的相应通证输出，其中所述第一通证输入包括：除其自身以外的所述第一通证事务的所有内容，以及正在被花费的所述先前通证事务输出的相应值和相应锁定脚本；以及，至少一个或多个数据对，每个数据对至少包括所述第一通证事务的相应锁定脚本中包括的支付地址以及由所述相应锁定脚本锁定的所述标的数字资产的对应数量。
在一些实施例中，所述第一通证事务可以包括第二通证输出，其中所述第二通证输出包括第二通证锁定脚本和第二通证数量，其中所述第二通证锁定脚本包括相应的变量组件和相应的常量组件，其中所述相应的变量组件包括第二支付地址，其中所述相应的常量组件与所述第一通证锁定脚本的所述常量组件匹配。
在一些实施例中，所述第一通证事务可以包括第三输出，其中所述第三输出包括第三支付地址。
在一些实施例中，所述第一通证输入可以包括由第一方生成的第一签名，其中所述第一通证事务包括第二输入，所述第二输入包括由第二方生成的第二签名，其中所述第一通证事务包括支付输出，所述支付输出包括支付模板中包括的支付地址，其中所述支付地址链接到所述第一方。
支付输出链接到第一方，以从第二方接收已售出通证的支付。
根据本文公开的另一方面，提供了一种计算机设备，所述计算机设备包括：存储器，所述存储器包括一个或多个存储器单元；以及，处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行以上描述的任一实施例。
根据本文公开的另一方面，提供了一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为，当在计算机设备上运行时，执行以上描述的任一实施例。
根据本文公开的另一方面，提供了一种通证事务，所述通证事务包括第一通证输出，所述第一通证输出包括第一通证锁定脚本和第一通证数量，其中所述第一通证锁定脚本包括变量组件和常量组件，其中所述变量组件包括第一支付地址，其嵌入在支付模板中，其中所述常量组件包括通证机制子组件，并且其中，当与花费事务的输入脚本一起执行时，所述输入脚本包括除其自身以外的所有的所述花费事务、以及相应的锁定脚本和正在被花费的先前事务输出中锁定的数量，所述通证机制子组件被配置为：从所述花费事务的所述输入脚本获得一个或多个数据对，每个数据对包括：i)至少一相应支付地址，其包括在所述花费事务输出的相应锁定脚本中，和ii)所述标的数字资产的对应数量，其由所述输出的所述相应锁定脚本锁定；验证所述花费事务的一个或多个输出包括相应的锁定脚本，所述锁定脚本包括：a)相应支付脚本模板，其包括预定支付地址，或b)相应变量组件，其包括除了所述预定支付地址以外的相应支付地址，后跟所述常量组件；以及，对于所述花费事务的一个或多个输出，验证由所述一个或多个输出的所述相应锁定脚本锁定的所述标的数字资产的总量等于所述第一通证数量；并且，其中所述通证机制子组件被配置为：如果任何验证步骤失败，则在执行期间失效。
根据本文公开的另一方面，提供了一种计算机可读存储介质，其上存储有前述的通证事务。
一旦给出本文的公开内容，所公开技术的其他变体或用例对于本领域技术人员可能变得显而易见。本公开的范围不受所描述的实施例限制，而仅受随附权利要求限制。

Claims (23)

1.一种使用区块链事务发送数字通证的计算机实现的方法，其中每个通证由区块链的标的数字资产原生单位的单个单位表示，其中所述方法包括：
生成第一通证事务；以及
将所述第一通证事务传输到区块链网络；
其中所述第一通证事务包括第一通证输出，所述第一通证输出包括第一通证锁定脚本和第一通证数量，其中所述第一通证锁定脚本包括变量组件和常量组件，其中所述变量组件包括第一支付地址，其嵌入在支付模板中，其中所述常量组件包括通证机制子组件，并且其中，当与花费事务的输入脚本一起执行时，所述输入脚本包括除其自身以外的所有的所述花费事务、以及相应的锁定脚本和正在被花费的先前事务输出中锁定的数量，所述通证机制子组件被配置为：
从所述花费事务的所述输入脚本获得一个或多个数据对，每个数据对包括i)包括在所述花费事务输出的相应锁定脚本中的至少相应支付地址，和ii)由所述输出的所述相应锁定脚本锁定的所述标的数字资产的对应数量；
验证所述花费事务的一个或多个输出包括相应的锁定脚本，所述锁定脚本包括a)包括预定支付地址的相应支付脚本模板，或b)包括除了所述预定支付地址以外的相应支付地址的相应变量组件，后跟所述常量组件；以及
对于所述花费事务的一个或多个输出，验证由所述一个或多个输出的所述相应锁定脚本锁定的所述标的数字资产的总量等于所述第一通证数量；并且，
其中所述通证机制子组件被配置为：如果验证步骤中的任意一项失败，则在执行期间失效。
2.根据权利要求1所述的方法，其中所述花费事务包括包含第一锁定脚本的第一输出以及包含第二锁定脚本的第二输出，其中所述通证机制子组件被配置为：
验证所述花费事务的所述第一输出包括第一锁定脚本，所述第一锁定脚本包括：a)包括预定支付地址的相应支付脚本模板，或b)包括除了所述预定支付地址以外的相应支付地址的相应变量组件，后跟所述常量组件；
如果所述花费事务的所述第二输出存在，验证所述花费事务的所述第二输出包括第二锁定脚本，所述第二锁定脚本包括：a)包括预定支付地址的相应标准支付脚本模板，或b)包括除了所述预定支付地址以外的任何地址的相应变量组件，后跟所述常量组件；以及
如果所述第二输出存在，则验证由所述花费事务的所述第一锁定脚本和所述第二锁定脚本锁定的所述数字资产的所述总量等于所述第一通证数量。
3.根据权利要求1或2所述的方法，其中所述通证机制组件被配置为：
如果所述花费事务的所述第一锁定脚本不包括包含预定支付地址的所述标准支付脚本模板，则验证所述第一锁定脚本包括包含除了所述预定支付地址以外的支付地址的相应变量组件，后跟与正在被花费的先前事务的所述第一通证锁定脚本的对应常量组件相同的常量组件；和/或
如果所述花费事务的所述第二锁定脚本存在，则验证所述第二锁定脚本包括包含任何支付地址的相应变量组件，后跟与正在被花费的先前事务的所述第一通证锁定脚本的对应常量组件相同的常量组件。
4.根据前述任一项权利要求所述的方法，其中所述常量组件包括所述预定支付地址。
5.根据前述任一项权利要求所述的方法，其中所述花费事务的所述输入脚本包括sighash原像，其中所述原像包括所述第一通证锁定脚本、和所述第一通证数量，其中所述通证机制子组件被配置为：
从所述原像中提取正在被花费的所述输出的所述第一通证数量和所述第一通证锁定脚本，以执行所述验证步骤。
6.根据权利要求5所述的方法，其中所述原像包括一个或多个数据对的级联的哈希，每个数据对包括来自所述花费事务的相应锁定脚本的相应支付地址以及由所述相应锁定脚本锁定的对应数量，其中所述通证机制子组件被配置为：
从所述原像中提取一个或多个数据对的所述级联的所述哈希；
基于所述一个或多个数据对生成哈希；以及
验证所述生成的哈希等于所述提取的哈希。
7.根据权利要求6所述的方法，其中用于生成所述哈希的所述一个或多个数据对或者是从所述输入脚本获得的，或者是通过从所述原像获得所述先前输出锁定脚本的输入地址和数量对来构建的。
8.根据权利要求5至7中任一项所述的方法，其中所述通证机制子组件被配置为：
生成所述花费事务数据的原像；以及
验证所述花费事务数据的所生成的原像等于所述花费事务的所述输入中包含的所述原像。
9.根据权利要求8所述的方法，其中所述花费事务的所述输入包括虚拟私钥和对应的虚拟公钥，其中所述通证机制子组件被配置为：
通过以下方式验证所述花费事务的所生成的原像等于所述花费事务的所述输入中包含的所述原像：
使用所述虚拟私钥以及所述花费事务的所述输入中包含的所述原像的所述哈希来生成数字签名；以及
在针对所述虚拟公钥和所述花费事务的所生成的原像的哈希进行核实时，验证所述数字签名是有效签名。
10.根据前述任一项权利要求所述的方法，其中所述通证机制子组件被配置为：
验证所述花费事务的相应锁定脚本中包括的所述相应支付地址与所述第一通证输出的所述变量组件中包括的所述第一支付地址的类型相同。
11.根据前述任一项权利要求所述的方法，其中所述第一支付地址的所述类型是公钥哈希地址。
12.根据前述任一项权利要求所述的方法，其中所述第一通证数量包括所述标的数字资产的单个单位。
13.根据权利要求1至11中任一项所述的方法，其中所述第一通证数量包括所述标的数字资产的多个单位。
14.根据前述任一项权利要求所述的方法，其中所述常量组件包括数据子组件，其中所述数据子组件包括以下一项或两项：
通证协议标识符；
通证发行事务的标识符，其中所述通证发行事务包括以下一项或两项i)通证发行者和初始通证接收者之间的发行合同，ii)初始通证数量。
15.根据权利要求2或其任何从属权利要求所述的方法，其中所述花费事务包括第三输出，所述第三输出包括第三锁定脚本和对应的第三数量，其中所述通证机制子组件被配置为：
验证所述第三锁定脚本包括预定支付类型模板中的相应支付地址及其相应的对应数量。
16.根据前述任一项权利要求所述的方法，其中所述第一通证事务包括第一通证输入，所述第一通证输入花费先前通证事务的相应通证输出，其中所述第一通证输入包括：
除其自身以外的所述第一通证事务的所有内容，以及正在被花费的所述先前通证事务输出的相应数量和相应锁定脚本；以及
至少一个或多个数据对，每个数据对至少包括所述第一通证事务的相应锁定脚本中包括的支付地址以及由所述相应锁定脚本锁定的所述标的数字资产的对应数量。
17.根据权利要求16所述的方法，其中所述第一通证事务包括第二通证输出，其中所述第二通证输出包括第二通证锁定脚本和第二通证数量，其中所述第二通证锁定脚本包括相应的变量组件和相应的常量组件，其中所述相应的变量组件包括第二支付地址，其中所述相应的常量组件与所述第一通证锁定脚本的所述常量组件匹配。
18.根据权利要求17所述的方法，其中所述第一通证事务包括第三输出，其中所述第三输出包括第三支付地址。
19.根据权利要求16至18中任一项所述的方法，其中所述第一通证输入包括由第一方生成的第一签名，其中所述第一通证事务包括第二输入，所述第二输入包括由第二方生成的第二签名，其中所述第一通证事务包括支付输出，所述支付输出包括支付模板中包括的支付地址，其中所述支付地址链接到所述第一方。
20.一种计算机设备，所述计算机设备包括：
存储器，所述存储器包括一个或多个存储器单元；以及
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据权利要求1至19中任一项所述的方法。
21.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为，当在计算机设备上运行时，执行根据权利要求1至19中任一项所述的方法。
22.一种通证事务，所述通证事务包括第一通证输出，所述第一通证输出包括第一通证锁定脚本和第一通证数量，其中所述第一通证锁定脚本包括变量组件和常量组件，其中所述变量组件包括第一支付地址，其嵌入在支付模板中，其中所述常量组件包括通证机制子组件，并且其中，当与花费事务的输入脚本一起执行时，所述输入脚本包括除其自身以外的所有的所述花费事务、以及相应的锁定脚本和正在被花费的先前事务输出中锁定的数量，所述通证机制子组件被配置为：
从所述花费事务的所述输入脚本获得一个或多个数据对，每个数据对包括i)包括在所述花费事务输出的相应锁定脚本中的至少相应支付地址，和ii)由所述输出的所述相应锁定脚本锁定的所述标的数字资产的对应数量；
验证所述花费事务的一个或多个输出包括相应的锁定脚本，所述锁定脚本包括a)包括预定支付地址的相应支付脚本模板，或b)包括除了所述预定支付地址以外的相应支付地址的相应变量组件，后跟所述常量组件；以及
对于所述花费事务的一个或多个输出，验证由所述一个或多个输出的所述相应锁定脚本锁定的所述标的数字资产的总量等于所述第一通证数量；并且，
其中所述通证机制子组件被配置为：如何验证步骤中的任一项失败，则在执行期间失效。
23.一种计算机可读存储介质，其上存储有根据权利要求22所述的通证事务。
CN202180066069.2A 2020-07-29 2021-03-09 区块链通证 Pending CN116210200A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2011753.7 2020-07-29
GB2011753.7A GB2597672A (en) 2020-07-29 2020-07-29 Blockchain tokens
PCT/EP2021/055905 WO2022022864A1 (en) 2020-07-29 2021-03-09 Blockchain tokens

Publications (1)

Publication Number Publication Date
CN116210200A true CN116210200A (zh) 2023-06-02

Family

ID=72339173

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180066069.2A Pending CN116210200A (zh) 2020-07-29 2021-03-09 区块链通证

Country Status (7)

Country Link
US (1) US20230291561A1 (zh)
EP (1) EP4189913A1 (zh)
JP (1) JP2023536163A (zh)
KR (1) KR20230044262A (zh)
CN (1) CN116210200A (zh)
GB (1) GB2597672A (zh)
WO (1) WO2022022864A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116976883A (zh) * 2023-07-31 2023-10-31 北京神州数码方圆科技有限公司 基于区块链的预付费卡资金监管方法和系统

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11907939B2 (en) * 2020-08-06 2024-02-20 James Cramer Methods for user authentication using non-fungible digital assets
EP4256751A1 (en) * 2020-12-02 2023-10-11 Trock, Stanislav Blockchain
GB2622627A (en) * 2022-09-23 2024-03-27 Nchain Licensing Ag Atomic swap token trades

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB201720767D0 (en) * 2017-12-13 2018-01-24 Barker Trevor Computer-implemented system and method

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116976883A (zh) * 2023-07-31 2023-10-31 北京神州数码方圆科技有限公司 基于区块链的预付费卡资金监管方法和系统

Also Published As

Publication number Publication date
GB202011753D0 (en) 2020-09-09
WO2022022864A1 (en) 2022-02-03
GB2597672A (en) 2022-02-09
EP4189913A1 (en) 2023-06-07
US20230291561A1 (en) 2023-09-14
JP2023536163A (ja) 2023-08-23
KR20230044262A (ko) 2023-04-03

Similar Documents

Publication Publication Date Title
JP7535362B2 (ja) ブロックチェーンベースの暗号通貨のためのトークンを検証する、コンピュータにより実行される方法及びシステム
JP7381625B2 (ja) 分散ハッシュテーブル及びピア・ツー・ピア分散型台帳を利用した契約の実行を制御する方法及びシステム
JP7569400B2 (ja) ブロックチェーントランザクションの中へ以前トランザクションのバイトコードを注入することの強制
CN108833081B (zh) 一种基于区块链的设备组网认证方法
US11743052B2 (en) Platform for generating authenticated data objects
KR20210128455A (ko) 블록체인 네트워크를 통한 이전을 구현하는 컴퓨터 구현 시스템 및 방법
CN116210200A (zh) 区块链通证
KR20220143879A (ko) 플랫폼 서비스 검증
CN113874839A (zh) 区块链交易内的脚本内函数
KR20210106532A (ko) 블록체인을 통해 행해지는 전송의 성능을 제어하거나 강제하기 위한 컴퓨터-구현된 시스템 및 방법
EP3907644B1 (en) Blockchain
KR20220143873A (ko) 블록체인과 연관된 이벤트들의 시퀀스에 대한 이벤트 스트림들
CN114531941A (zh) 多标准区块链协议
CN118648008A (zh) 使用有序的仅追加数据存储的选择性存在证明
KR20220143688A (ko) 이벤트 스트림들의 동기화
Linus et al. BitVM2: Bridging Bitcoin to Second Layers

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination