CN117480758A - 用于验证区块链上的通证的计算机实现的方法和系统 - Google Patents

用于验证区块链上的通证的计算机实现的方法和系统 Download PDF

Info

Publication number
CN117480758A
CN117480758A CN202280040500.0A CN202280040500A CN117480758A CN 117480758 A CN117480758 A CN 117480758A CN 202280040500 A CN202280040500 A CN 202280040500A CN 117480758 A CN117480758 A CN 117480758A
Authority
CN
China
Prior art keywords
transaction
certification
blockchain
issuer
transactions
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
CN202280040500.0A
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.)
Blockchain Licensing Jsc
Original Assignee
Blockchain Licensing Jsc
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 Blockchain Licensing Jsc filed Critical Blockchain Licensing Jsc
Publication of CN117480758A publication Critical patent/CN117480758A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

实施例提供了用于验证经由区块链上的通证事务提供的一个或多个通证的改进解决方案。通证事务由发行者生成，并在通证事务链中形成链接，该链可追踪到发行者用来生成通证的铸造事务。在链内的一个或多个通证事务中提供至少一个认证元素，其中认证元素由发行者或代表发行者认证通证的真实性。核实实体只需将通证的历史链遍历回包括认证元素的事务，而不是遍历回铸造事务。附加地或替代地，本公开提供了改进解决方案，用于在已经达到预定阈值、限制或指定值时熔化和重新铸造通证。熔化和重新铸造可以包括在通证的历史链中的原始铸造事务之后在区块链上发行新的铸造事务，或者替换与发行者相关联的组件，例如此后用于标识通证、发行者和/或新的或原始铸造事务的标识符。

Description

用于验证区块链上的通证的计算机实现的方法和系统
技术领域
本公开涉及用于核实、发行、更新、替换或以其他方式处理使用通证事务实现的基于区块链的通证(token)的方法和系统。通证事务是包括一个或多个通证输出的区块链事务。本公开的实施例特别适用于其中需要验证通证化资产以确认其合法性和由授权方发行的系统。实施例提供了许多技术优势，包括但不限于提高效率、降低处理要求和提高基于区块链的传输安全性。
背景技术
区块链是指一种分布式数据结构，其中在分布式对等(P2P)网络(以下称为“区块链网络”)中的多个节点中的每个节点处维护区块链的副本，并且广泛公开该副本。区块链包括一系列数据区块，其中每个区块包括一个或多个事务(transaction)。除所谓的“coinbase事务”外，每个事务都指向序列中的先前事务，该序列可以跨越一个或多个区块，回到一个或多个coinbase事务。coinbase事务将在下文进一步讨论。提交给区块链网络的事务包括在新区块中。新区块的创建过程通常称为“挖掘”，该过程涉及多个节点中的每个节点争相执行“工作证明”，即，基于等待被包括在区块链的新区块中的一组定义的有序且核实有效的未决事务的表示解决加密难题。应当注意的是，区块链可以在一些节点处被修剪(prune)，并且区块的发布可以通过仅发布区块头来实现。
区块链中的事务可用于以下目的中的一个或多个：传送数字资产(即，一定数量的数字通证)；对虚拟化分类账或注册表中的一组条目进行排序；接收和处理时间戳条目；和/或对索引指针按时间排序。也可利用区块链实现区块链上的层级附加功能。例如，区块链协议可允许在事务中存储附加的用户数据或数据索引。能够存储在单个事务中的最大数据容量没有预先指定的限制，因此可以并入越来越复杂的数据。例如，这可用于在区块链中存储电子文档、音频或视频数据。
区块链网络的节点(通常称为“矿工”)执行分布式事务注册和验证过程，这将后续更详细地描述。总之，在该过程中，节点核实事务并将这些事务插入到区块模板中，这些事务尝试为该区块模板标识有效的工作证明解。一旦找到有效的解，新区块便会被传播到网络的其它节点，从而使得每个节点能够在区块链上记录新区块。为了将事务记录在区块链中，用户(例如，区块链客户端应用程序)将该事务发送到网络中的节点中的一个节点进行传播。接收该事务的节点可以争相寻找将核实有效的事务并入新区块的工作证明解。每个节点被配置为执行相同的节点协议，该协议将包括用于确认事务有效的一个或多个条件。无效事务将不会传播或并入到区块中。假定事务已经核实有效，从而在区块链上被接受，则该事务(包括任何用户数据)将因此在区块链网络中的每个节点上作为不可改变的公共记录进行注册和索引。
成功解决工作证明难题可创建最新区块的节点通常被奖励一个称为“coinbase事务”的新事务，该事务分发数字资产数额，即通证数量。无效事务的检测和拒绝是通过竞争节点的行动来执行的，这些竞争节点充当网络的代理并且通过激励报告和阻止不正当行为。信息的广泛发布使得用户可以连续地审计节点的性能。仅发布区块头使得参与者可以确保区块链具有持续完整性。
在“基于输出的”模型(有时称为基于UTXO的模型)中，给定事务的数据结构包括一个或多个输入和一个或多个输出。任何可花费输出包括指定数字资产数额的元素，该元素可从进行中的事务序列导出。可花费输出有时称为UTXO(“未花费事务输出”)。输出还可以包括锁定脚本，该锁定脚本指定输出的未来赎回条件。锁定脚本是限定核实和传送数字通证或资产所必需的条件的谓词。事务(除coinbase事务之外)的每个输入包括指向先前事务中的此类输出的指针(即引用)，并且还可以包括解锁脚本，用于解锁指向输出的锁定脚本。因此，考虑一对事务，将其称为第一事务和第二事务(或“目标”事务)。第一事务包括指定数字资产数额的至少一个输出，并且包括定义解锁该输出的一个或多个条件的锁定脚本。第二目标事务包括至少一个输入和解锁脚本，该至少一个输入包括指向第一事务的输出的指针；该解锁脚本用于解锁第一事务的输出。
在此类模型中，当第二目标事务被发送到区块链网络以在区块链中传播和记录时，在每个节点处应用的有效性条件之一将是解锁脚本满足在第一事务的锁定脚本中定义的一个或多个条件中的所有条件。另一条件将是第一事务的输出尚未被另一早期有效事务赎回。根据这些条件中的任何一个条件发现目标事务无效的任何节点都不会传播该事务(作为有效事务，但可能注册无效事务)，也不将该事务包括在要记录在区块链中的新区块中。
发明内容
如上所述，作为区块链协议指定的底层传输机制的一部分，在区块链事务中包括部分加密货币(通证)。然而，区块链事务也可以用于转移对其他附加资产的所有权或控制权，这些资产被通证化并在分类账上表示。本公开的实施例涉及这些附加通证的处理，而不是区块链网络的协议要求的协议级加密货币。
使用区块链来发行和花费通证本身并不新奇。已知方法包括在基于UTXO的方法中使用事务输出来发行通证，例如使用OP_RETURN或OP_FALSE OP_RETURN命令，在基于UTXO的方法中通证耦合到事务输出点。基于UTXO的通证系统与原生区块链系统更加一致，除了安全性外，还具有区块链系统的一些有利特性，例如通证的脚本内智能合约。该系统还使得通证发行者能够将其通证值与原生区块链通证值进行挂钩。
然而，无论采用哪种通证化(tokenisation)方式，都需要核实已经发行的通证，以验证这些通证是否由授权发行实体生成。出于各种原因，可能需要核实给定通证。例如，接收方希望确保所接收的通证是真实的。这通常涉及将通证的事务历史追踪到其原始(铸造)事务，以便能够将已知源自通证发行者的铸造数据的一部分与在通证事务中提供的数据进行比较和核实。
然而，在某些情况下会出现技术挑战，通证的历史链随着时间的推移而增长，使得在所述区块链上将其历史追踪到铸造事务在时间和所需的处理资源量方面变得昂贵。因此，由于使用通证，在所述通证的生命周期内可能会出现效率低下的情况，使得在某些情况下，通证的历史可能变得广泛，使得继续使用所述通证变得不切实际，并且在资源方面成本过高。
发生这种情况时，所述发行者可以选择销毁所述通证或撤销所述通证当前形式的使用，并且可以重新发行所述通证。由于类似于在法定货币系统中的传统硬币随着时间的推移以某种方式受损或损坏时熔化所述传统硬币的概念，因此该过程可以重新称为“熔化和重新铸造”操作。为了保持流通所需数量的硬币，铸造机构可以发行新铸造的替代物。显然，对熔化和重新铸造的需要会产生成本，并且需要用于发行机构的资源，因此必须频繁地执行该操作是不利的。
如本领域公知的，第1层区块链通证在脚本中嵌入通证核实规则。它们的设计可以使得所述脚本证明通证在整个事务链中直至发行的有效性。这是通过创建哈希谜题来实现的，所述哈希谜题要求插入先前事务作为解决方案(事务ID是哈希摘要，而所述事务本身是哈希原像)。然而，由于每个通证事务必须包含先前事务的所有数据，因此通过归纳，每个通证事务必须包含返回到发行的所有先前事务。这意味着每个通证事务的规模都会累积增加，这意味着所述链中的最新事务可能会非常大。因此，这种增加的事务规模增加了与带宽和存储需求相关的资源需求以及写入所述分类账的成本。
因此，至少出于这些原因，希望在不损害由通证化协议或底层区块链协议实现的任何安全特征的情况下，提高在区块链上核实和发行通证的效率。
根据本公开的一个方面，提供了一种计算机实现的方法，所述方法可以定义为至少一种核实(validate)、认证(certify)、和/或背书(endorse)/证实(attest)区块链实现的通证的真实性的方法。“认证”在本文中可以理解为包括：合法性或真实性的印记、来源或起源的证明、和/或作者身份/创建的确认，其由特定实体进行。“核实”可以理解为包括：检查、测试和/或确认区块链实现的通证的合法性、真实性、来源、作者身份、认证或起源。在一些实施例中，所述通证可以根据“第1层通证”协议来形成和/或处理，其中在所述通证事务的脚本中嵌入通证核实规则。
本公开的实施例使得基于区块链的通证能够快速、高效地核实，而无需将所述通证的起源追踪到其在所述区块链上的来源。这为处理所述通证的各方(例如，发送者、接收者、发行者)提供了显著提高的效率和更少的资源需求，因为他们不需要遍历和处理大量通证历史。由于减少了对替换此类通证的需求，或者至少降低了执行该操作的频率，因此还减少了所消耗的资源。此外，通过熔化和重新铸造、或通过印记所述通证，本公开的实施例使得能够重置所述通证事务链中的所述最新事务的规模。因此，显著减小了事务规模。这反过来又降低了带宽需求、存储需求和写入所述分类账的成本。
所述方法包括以下步骤：将认证元素添加到通证事务，所述通证事务是通证事务链中的元素。术语“通证事务”可以包括包含至少一个通证的区块链事务，其中所述通证表示任何形式的通证化资产并且存储在链上或链下，并且所述通证是根据通证化协议形成的，所述通证化协议不同于由网络节点操作的底层区块链协议，但是在所述底层区块链协议之上实现。
所述通证事务链源自由所述发行者或由代表所述发行者的授权方用来生成所述通证的铸造事务。从所述铸造事务开始的每个通证事务将所述通证传递到所述链中的下一元素(通证事务)。因此，所述通证在区块链分类账上具有可追踪、不可变、不间断的历史，以通证事务的形式追踪到其铸造事务。沿着所述历史链的某些通证事务包括认证元素。有利地，这消除了或至少减轻了出于验证/认证目的将所述通证的历史一直追踪到其原始(铸造)事务的需求，因为验证者只需将所述历史追踪到所述链中包含可信认证元素的最后一个通证事务。
所述链中的所述通证事务中的至少一个、一些或所有通证事务包括认证元素，所述认证元素用作与授权实体直接或间接相关联的真实性的可验证标记、证书或印记，所述授权实体是例如所述通证发行者或某个其他参与方，所述某个其他参与方被信任为能够代表所述发行者证实所述通证的来源和/或合法性的授权或获准认证实体。根据替代措辞，所述认证元素可以称为真实性的印记或确认。
所述认证元素可以提供已知与所述发行者相关联或由所述发行者控制的秘密的知识证明。在一个优选实施例中，所述链中的所述通证事务中的一个或一些通证事务但不是所有通证事务可以包括认证元素。这具有以下优点：即由于与在所述通证事务中提供所述认证元素相关的处理成本而提高效率。(此后，术语“发行者”可以包括由所述发行者授权代表其行事的其他各方)。
在一些实施例中，可以在所述链内的多个通证事务中提供相同的认证元素。然而，在其他实施例中，可以为所选择的通证事务中的每个或一些通证事务提供不同的认证元素。然而，重要的是，无论在所述通证事务中使用相同的认证元素还是不同的认证元素，所述认证元素用于上述目的，以便证实所述通证的所述来源。
在一个或多个实施例中，所述认证元素可以采用加密数据的形式，例如可以与所述发行实体可证明地相关联或由所述发行实体授权的加密元素。例如，这可以是加密密钥或使用已知由所述发行者相关联的密钥进行签名的消息。本领域技术人员将容易理解，所述认证元素可以采用任何适当的形式，使得验证实体能够确定所述认证元素已经由所述发行者提供和/或授权，并且在所述通证事务中提供所述认证元素用作所述通证的起源、合法性和/或真实性的证明或证据。
在一个或多个实施例中，例如，当所述通证已经花费(传输)预定次数时，可以根据至少一个预定规则或标准将所述认证元素添加到所述通证事务。所述标准或规则可以由所述发行者、通证所有者/接收者/控制者或某个其他方来确定。在其他实施例中，可以响应于请求、指令或其他信号将所述认证元素添加到所述链中的通证事务。在后一种情况下，所述认证元素的插入可以在更特定基础上执行，而不是以规定的方式执行。
在使用预定规则或标准来控制或影响将所述认证元素添加到所述链内的哪个通证事务的一个或多个实施例中，所述认证元素可以预定间隔(例如，每100个事务)或在指定时间段(例如，每天或每周)之后包括在所述链中(在这种情况下，假设所述通证将涉及足够高的事务活动频率)。可以利用其他标准和规则，但是本质上，本公开的某些实施例包括使用一个或多个预定度量，或者指定要将所述认证元素添加到所述链(事务)的哪些元素。
在一个或多个实施例中，可以本领域已知的任何适当的方式将所述认证元素添加到通证事务。例如，在一些协议中，这可以在OP_RETURN之后，而在其他协议中，这可以在包括OP_FALSE OP_RETURN命令的脚本中。在其他实施例中，所述认证元素可以在所述通证事务中的输出的锁定脚本中提供，和/或作为元数据提供。本领域技术人员将容易理解，可以各种方式并且在所述事务内的各种位置与所述通证事务相关联地提供所述认证元素，以提供相同的有利效果。
根据本公开的另一个方面，提供了一种提供区块链实现的通证的计算机实现的方法。为了缓解与冗长历史链相关的问题，发行者可以熔化和重新铸造在通证事务中提供的一个或多个通证，使得所述通证的先前历史作为原始起源和真实性的可验证和可审计记录保持在链上，但是出于验证目的，新的铸造事务可以取代原始铸造事务。为了减少所述熔化和重新铸造过程所需的处理资源量，这可以被周期性间隔执行，使得对于验证方追踪到铸造事务所需的努力得到减少，但对于发行者/认证方与熔化和重新铸造相关联的开销也得到最小化。
执行所述熔化和重新铸造过程的频率可以根据至少一个规则、标准或度量来预定，所述至少一个规则、标准或度量可以由机器人、预言机或其他软件组件等自动化资源来评估。例如，在已经达到指定阈值、限制或可测量/可量化值时，可以重新发行所述通证。这可以是自原始或最后一个铸造事务以来写入区块链上的所述通证的历史链的事务的数量，或者是每隔x个写入所述链的通证事务，或者是按照周期性的时间间隔，等等。这具有以下优点：即为通证用户和/或所有者提供可预测性。或者，所述熔化和重新铸造过程可以在特定或随机/伪随机的基础上执行。
本公开不限于用于熔化和重新铸造所述通证的特定机制。例如，在一个实施例中，与所述通证相关联并且在其历史中的先前通证事务中使用的标识符可以替换为新的标识符。
附加地或替代地，实施例可以包括一种发行在区块链上的通证事务中提供的至少一个通证的区块链实现的方法。所述方法可以包括以下步骤：在满足条件时熔化和重新铸造所述通证。例如，所述条件可以包括确定已经达到或标识预定阈值、限制或指定值。这具有以下优点：即在某些条件下可以重新启动通证的历史链，从而减少如上所述处理冗长历史所需的资源。因此，此类实施例在区块链实现的传输期间在存储、处理和时间方面提高了效率，这可以保持安全性并防范欺诈，因为保留了对所述通证的真实性的保证。
在此类实施例中，所述通证事务在所述区块链上可以追踪到由至少一个发行者或代表所述至少一个发行者发行的至少一个铸造事务。熔化所述至少一个通证可以包括提供标识元素、标记或数据的其他部分以指示所述通证不再有效。附加地或替代地，重新铸造通证可以包括提供标识元素、标记或数据的其他部分以指示所述通证有效。所述标识符可以提供所述通证已经重新铸造的指示，并且以相对于一个或多个先前版本的修改形式来提供。
所述标识元素可以采用任何适当的形式，例如标识符和/或加密数据。所述标识元素可以与所述至少一个发行者或由所述至少一个发行者授权的一方相关联，并且可以在区块链事务中、在所述通证事务中或在所述区块链外提供的存储资源中提供。
评估是否已经达到或遇到所述预定阈值、限制或指定值的步骤可以包括对所提供的或所计算的值与所述阈值、限制或指定值进行比较。所述预定阈值、限制或指定值可以由所述至少一个发行者或由所述至少一个发行者授权的一方、用户或核实实体确定。
本公开的方法可以在包括计算设备的系统中实现。这可以包括
存储器，所述存储器包括一个或多个存储器单元；以及
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据本文所公开或所要求保护的任何实施例所述的方法。
本公开还提供了一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据本文所公开或所要求保护的任何实施例所述的方法。
附图说明
为了帮助理解本公开的实施例并示出如何实施此类实施例，现将仅通过举例的方式参考附图进行说明，其中：
图1是一种用于实现区块链的系统的示意性框图；
图2示意性地示出了可记录在区块链中的事务的一些示例；
图3A示出了客户端应用程序的示意性框图；
图3B示出了可由图3A的客户端应用程序表示的示例性用户界面的示意性模型；
图4A示意性地将区块链分类账示为由两个事务链分割的有向无环图；
图4B示意性地将区块链分类账示为区块链，其中每个区块包含一个新的coinbase事务；
图5示意性地示出了输出点签名有向无环图的示例；
图6示意性地示出了连接到区块链网络的通证网络的示例；
图7示意性地示出了用于实现本发明的实施例的示例性系统。
具体实施方式
示例性系统概述
图1示出了一种用于实现区块链150的示例性系统100。系统100可以包括分组交换网络101，通常是诸如互联网的广域互联网。分组交换网络101包括多个区块链节点104，该多个区块链节点可以被设置成在分组交换网络101内形成对等(P2P)网络106。虽然未示出，但是区块链节点104可以被设置为近完全图。因此，每个区块链节点104高度连接到其它区块链节点104。
每个区块链节点104包括对等体的计算机设备，不同的节点104属于不同的对等体。每个区块链节点104包括处理装置，该处理装置包括一个或多个处理器，例如一个或多个中央处理单元(CPU)、加速器处理器、专用处理器和/或现场可编程门阵列(FPGA)，以及其它设备，例如专用集成电路(ASIC)。每个节点还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。存储器可包括一个或多个存储器单元，其采用一个或多个存储器介质，例如诸如硬盘等磁介质、诸如固态硬盘(SSD)、闪存或电可擦可编程只读存储器(EEPROM)等电子媒介和/或诸如光盘驱动器等光学介质。
区块链150包括一系列数据区块151，其中在分布式或区块链网络106中的多个区块链节点104中的每个节点处维护区块链150的相应副本。如上所述，维护区块链150的副本不一定意味着完全存储区块链150。相反，只要每个区块链节点150存储每个区块151的区块头(下面讨论)，区块链150就可以进行数据修剪。区块链中的每个区块151均包括一个或多个事务152，其中该上下文中的事务是指一种数据结构。数据结构的性质将取决于用作事务模型或计划的一部分的事务协议类型。给定的区块链全程使用一个特定的事务协议。在一种常见的事务协议中，每个事务152的数据结构至少包括一个输入和至少一个输出。每个输出指定将数字资产的数量表示为财产的数额，其一个示例是输出被密码锁定到的用户103(需要该用户的签名或其它解进行解锁，从而进行赎回或花费)。每个输入指向先前事务152的输出，从而链接这些事务。
每个区块151还包括区块指针155，其指向区块链中先前创建的区块151，以定义区块151的顺序。每个事务152(除coinbase事务之外)包括指向先前事务的指针，以定义事务序列的顺序(注：事务152的序列可进行分支)。区块151的区块链一直追溯到创始区块(Gb)153，该创始区块是区块链中的第一区块。区块链150中早期的一个或多个原始事务152指向创始区块153，而非先前事务。
每个区块链节点104被配置为将事务152转发到其它区块链节点104，从而使得事务152在整个网络106中传播。每个区块链节点104被配置为创建区块151，并将相同区块链150的相应副本存储在其相应的存储器中。每个区块链节点104还维护等待并入到区块151中的事务152的有序集(或“池”)154。有序池154通常称为“内存池”。在本文中，该术语并不意在限制于任何特定的区块链、协议或模型。该术语是指节点104已接受为有效的有序事务集，并且对于该有序事务集，强制节点104不接受试图花费相同输出的任何其它事务。
在给定的当前事务152j中，输入(或每个输入)包括指针，该指针引用事务序列中先前事务152i的输出，指定该输出将在当前事务152j中被赎回或“花费”。通常，先前事务可以是有序集154或任何区块151中的任何事务。尽管为了确保当前事务有效，将需要存在先前事务152i并核实其有效，但是在创建当前事务152j甚至向网络106发送当前事务152j时，不必存在先前事务152i。因此，在本文中，“先前”是指由指针链接的逻辑序列中的前任，而不一定是时间序列中的创建时间或发送时间，因此，不一定排除无序创建或发送事务152i、152j的情况(参见下面关于孤立事务的讨论)。先前事务152i同样可以称为先行事务或前任事务。
当前事务152j的输入还包括输入授权，例如先前事务152i的输出被锁定到的用户103a的签名。反过来，当前事务152j的输出可以加密锁定到新用户或实体103b。因此，当前事务152j可将先前事务152i的输入中定义的数额转移到当前事务152j的输出中定义的新用户或实体103b。在某些情况下，事务152可具有多个输出，以在多个用户或实体间分割输入数额(其中一个可以是原始用户或实体103a，以便进行变更)。在某些情况下，事务还可以具有多个输入，将一个或多个先前事务的多个输出中的数额汇总在一起，并重新分配到当前事务的一个或多个输出。
根据基于输出的事务协议，例如比特币，当诸如个体用户或组织这类的一方103希望颁布新的事务152j时(由该方采用的自动程序或人为地)，该颁布方将该新事务从其计算机终端102发送到接收者。颁布方或接收者将最终向网络106的一个或多个区块链节点104(现在通常是服务器或数据中心，但原则上也可以是其它用户终端)发送该事务。另外还不排除颁布新事务152j的一方103可以将事务直接发送到一个或多个区块链节点104，并且在一些示例中，可以不将事务发送到接收者。接收事务的区块链节点104根据在每个区块链节点104处应用的区块链节点协议来检查事务是否有效。区块链节点协议通常要求区块链节点104检查新事务152j中的加密签名是否与预期签名相匹配，这取决于事务152的有序序列中的上一事务152i。在这种基于输出的事务协议中，这可以包括检查新事务152j的输入中包括的一方103的密码签名或其它授权是否与新事务分配的先前事务152i的输出中定义的条件匹配，其中该条件通常包括至少检查新事务152j的输入中的密码签名或其它授权是否解锁新事务的输入所链接到的上一事务152i的输出。条件可以至少部分地由包括在先前事务152i的输出中的脚本来定义。或者，这可仅由区块链节点协议单独确定，或可通过其组合确定。无论采用哪种方式，如果新事务152j有效，区块链节点104会将其转发到区块链网络106中的一个或多个其它区块链节点104。这些其它区块链节点104根据相同的区块链节点协议应用相同的测试，并因此将新事务152j转发到一个或多个其它节点104等等。通过这种方式，新事务在区块链节点104的整个网络中进行传播。
在基于输出的模型中，给定输出(例如，UTXO)是否分配(例如，花费)的定义是，根据区块链节点协议，其是否通过另一个随后事务152j的输入有效赎回。事务有效的另一个条件是其试图赎回的先前事务152i的输出尚未被另一个事务赎回。同样，如果无效，则事务152j将不会在区块链150中传播(除非被标记为无效并且被传播用于提醒)或记录。这可防止重复花费，即事务处理者对同一个事务的输出分配超过一次。另一方面，基于账户的模型通过保持账户余额防止重复花费。因为同样存在定义的事务顺序，账户余额在任何时候均具有单一定义的状态。
除了核实事务有效之外，区块链节点104还争相成为在通常称为挖矿的过程中创建事务区块的第一个节点，而该过程由“工作证明”支持。在区块链节点104处，新事务被添加到尚未出现在记录在区块链150上的区块151中的有效事务的有序池154。然后，区块链节点争相通过尝试解决加密难题以组装有序事务集154中事务152的新有效事务区块151。通常情况下，这包括搜索“随机数”值，从而当随机数与未决事务有序池154的表示并置且进行哈希处理时，哈希值的输出满足预定条件。例如，预定条件可以是哈希值的输出具有某个预定义的前导零数。注意，这仅仅是一种特定类型的工作证明难题，并且不排除其它类型。哈希函数的特性是，相对于其输入，其具有不可预测的输出。因此，该搜索只能通过强力执行，从而在试图解决难题的每个区块链节点104处消耗大量的处理资源。
解决难题的第一区块链节点104在网络106上宣布难题解决，提供解决方案作为证明，然后网络中的其它区块链节点104则可以轻松检查该解决方案(一旦给出哈希值的解决方案，就可以直接检查该解决方案是否使哈希值的输出满足条件)。第一区块链节点104将一个区块传播到接受该区块的其它节点达成阈值共识，从而执行协议规则。然后，有序事务集154被每个区块链节点104记录为区块链150中的新区块151。区块指针155还分配给指向该区块链中先前创建的区块151n-1的新区块151n。创建工作证明解所需的大量工作(例如采用哈希的形式)发出信号通知第一节点104的意图以遵循区块链协议。这些规则包括如果它分配与先前核实有效的事务相同的输出，则不接受事务为有效，否则称之为重复花费。一旦创建，区块151就不能修改，因为它在区块链网络106中的每个区块链节点104处进行标识和维护。区块指针155还向区块151施加顺序。由于事务152记录在网络106中每个区块链节点104处的有序区块中，因此提供了事务的不可改变公共分类账。
应当注意的是，在任何给定时间争相解决难题的不同区块链节点104可以基于在任何给定时间尚未发布的事务的池154的不同快照来这样做，具体取决于它们何时开始搜索解或接收事务的顺序。解决相应难题的人员首先定义新区块151n中包括的事务152及其顺序，并且更新当前的未发布事务池154。然后，区块链节点104继续争相从新定义的未发布事务有序池154中创建区块，等等。此外，还存在解决可能出现的任何“分叉”的协议，其中两个区块链节点104彼此在很短的时间内解决难题，从而在节点104之间传播区块链的冲突视图。简言之，分叉方向最长的成为最终区块链150。应当注意的是，这不会影响网络的用户或代理，因为同一事务将出现在两个分叉中。
根据比特币区块链(和大多数其它区块链)，成功构造新区块104的节点被授予在分配附加限定数量数字资产的新特殊类型事务中新分配附加的、接受的数额的数字资产的能力(与代理间或用户间事务相反，该事务将一定数量的数字资产从一个代理或用户转移到另一个代理或用户)。这种特殊类型的事务通常称为“coinbase事务”，但是也可以称为“启动事务”或“产生事务”。它通常形成新区块151n的第一事务。工作证明发出信号通知构造新区块的节点的意图以遵循协议规则，从而允许稍后赎回该特定事务。在可以赎回该特殊事务之前，区块链协议规则可能需要成熟期，例如100个区块。通常，常规(非生成)事务152还将在其输出中的一个输出中指定附加事务费用，以进一步奖励创建其中发布该事务的区块151n的区块链节点104。该费用通常称为“事务费用”，并在下文中讨论。
由于事务核实和发布中涉及的资源，通常至少每个区块链节点104采用包括一个或多个物理服务器单元的服务器的形式，或者甚至整个数据中心。但是，原则上来说，任何给定区块链节点104均可采用一个用户终端或联网在一起的一组用户终端的形式。
每个区块链节点104的存储器均存储被配置为在区块链节点104的处理装置上运行的软件，以根据区块链节点协议执行其相应的角色并处理事务152。应当理解的是，在本文中归因于区块链节点104的任何动作均可通过在相应计算机设备的处理装置上运行的软件执行。节点软件可以在应用层或诸如操作系统层或协议层的较低层或这些层任意组合的一个或多个应用中实现。
扮演消费用户角色的多方103中的每一方的计算机设备102也连接到网络101。这些用户可以与区块链网络106交互，但不参与核实事务或构造区块。其中一些用户或代理103可以充当事务中的发送者和接收者。其它用户可以与区块链150交互，而不必充当发送者或接收者。例如，一些当事方可以充当存储区块链150的副本(例如，已经从区块链节点104获得区块链的副本)的存储实体。
各方103中的一些或所有当事方可以作为不同网络的一部分连接，例如覆盖在区块链网络106之上的网络。区块链网络的用户(经常称为“客户端”)可以被称为是包含区块链网络106的系统的一部分；然而，这些用户不是区块链节点104，因为它们不执行区块链节点所需的角色。相反，每一方103可以与区块链网络106交互，从而通过连接到区块链节点106(即，与区块链节点106通信)来利用区块链150。出于说明目的，示出了双方103及其相应的设备102：第一方103a及其相应的计算机设备102a，以及第二方103b及其相应的计算机设备102b。应当理解的是，更多此类当事方103及其相应的计算机设备102可能存在并参与系统100，但为了方便起见，未进行说明。每一方103均可以是个人或组织。仅出于说明目的，在本文中，第一方103a称为爱丽丝，第二方103b称为鲍勃，但应当理解的是，这并不仅限于爱丽丝或鲍勃，且本文对爱丽丝或鲍勃的任何引用均可分别用“第一方”和“第二方”替换。
每一方103的计算机设备102包括相应的处理装置，其包括一个或更多个处理器，例如一个或更多个CPU、图形处理单元(GPU)、其他加速器处理器、特定应用程序处理器和/或FPGA。每一方103的计算机设备102还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。该存储器可包括一个或更多个存储器单元，其采用一个或更多个存储器介质，例如诸如硬盘等磁介质、诸如SSD、闪存或EEPROM等电子媒介和/或诸如光盘驱动器等的光学介质。每一方103的计算机设备102上的存储器存储软件，其包括被设置为在处理装置上运行的至少一个客户端应用程序105的相应实例。应当理解的是，在本文中归因于给定方103的任何行动均可通过在相应计算机设备102的处理装置上运行的软件执行。每一方103的计算机设备102包括至少一个用户终端，例如台式或笔记本电脑、平板电脑、智能手机或诸如智能手表等的可穿戴设备。给定方103的计算机设备102还可包括一个或更多个其他网络资源，诸如通过用户终端访问的云计算资源。
客户端应用程序105最初可通过例如从服务器下载的适当计算机可读存储介质，或通过诸如可移动SSD、闪存密钥、可移动EEPROM、可移动磁盘驱动器、软盘或磁带等的可移动存储设备、诸如CD或DVD ROM等的光盘或可移动光驱等提供至任何给定方103的计算机设备102。
客户端应用程序105至少包括“钱包”功能。这有两个主要功能。其中一个功能是使相应方103能够创建、授权(例如签名)事务152并将其发送到一个或多个比特币节点104，然后在区块链节点104的网络中传播，从而包括在区块链150中。另一个功能是向相应方汇报其目前拥有的数字资产数额。在基于输出的系统中，该第二功能包括整理分散在区块链150中属于相关方的各种事务152的输出中定义的数额。
注意：虽然各种客户端功能可以描述为集成到给定客户端应用程序105中，但这不一定是限制性的，相反，在本文中所描述的任何客户端功能可以在由两个或更多个不同应用程序组成的套件中实现，例如经由API进行接口连接或一个应用程序作为另一个应用程序的插件。更通俗地说，客户端功能可以在应用层或诸如操作系统的较低层或这些层的任意组合实现。下面将根据客户端应用程序105进行描述，但应当理解的是，这不是限制性的。
每个计算机设备102上的客户端应用程序或软件105的实例可操作地耦合到网络106的区块链节点104中的至少一个。这可以启用客户端105的钱包功能，以将事务152发送至网络106。客户端105还可联络区块链节点104，以在区块链150中查询相应方103作为接收者的任何事务(或实际上在区块链150中检查其它方的事务，因为在实施例中，区块链150是在某种程度上通过其公开可见性提供事务信任的公共设施)。每个计算机设备102上的钱包功能被配置为根据事务协议制定和发送事务152。如上所述，每个区块链节点104运行软件，该软件被配置为根据区块链节点协议核实事务152并转发事务152以便在区块链网络106中传播。事务协议和节点协议相互对应，给定事务协议和给定节点协议一起实现给定的事务模型。相同的事务协议用于区块链150中的所有事务152。网络106中的所有节点104使用相同的节点协议。
当给定方103(比方说爱丽丝)希望发送拟包含在区块链150中的新事务152j时，她将根据相关事务协议(使用其客户端应用程序105中的钱包功能)制定新事务。然后，她将事务152从客户端应用程序105发送到她所连接的一个或多个区块链节点104。例如，这可能是与爱丽丝的计算机102最佳连接的区块链节点104。当任何给定区块链节点104接收新事务152j时，其将根据区块链节点协议及其相应的角色进行处理。这包括首先检查新接收的事务152j是否满足变为“有效”的特定条件，具体示例稍后将详细讨论。在一些事务协议中，有效条件可通过事务152中包含的脚本在每个事务的基础上进行配置。或者，条件可仅仅是节点协议的内置功能，或通过组合脚本和节点协议进行定义。
如果新接收的事务152j通过有效性测试(即：“有效”的条件下)，接收事务152j的任何区块链节点104将向在区块链节点104处维护的有序事务集154中添加新的核实有效事务152。进一步地，接收事务152j的任何区块链节点104随后将核实有效事务152传播至网络106中的一个或多个其它区块链节点104。由于每个区块链节点104应用相同的协议，因此假定事务152j有效，这意味着事务很快将在整个网络106中传播。
一旦进入在给定区块链节点104处维护的未决事务有序池154，该区块链节点104将开始争相解决其各自的包含新事务152的池154的最新版本上的工作证明难题(请记住，其它区块链节点104可以尝试基于不同的事务池154来解决难题。但是，首先解决难题的人将定义包括在最新区块151中的事务集合。最终，区块链节点104将解决有序池154的一部分的难题，该有序集154包括爱丽丝的事务152j)。一旦包括新事务152j的池154完成工作证明，其将不可变地成为区块链150中区块151中的一个区块的一部分。每个事务152包括指向早前事务的指针，因此事务的顺序也被不可变地记录下来。
不同的区块链节点104可以首先接收给定事务的不同实例，并且因此在一个实例被发布到新区块151中之前具有关于哪个实例“有效”的冲突视图，此时所有区块链节点104同意所发布的实例是唯一的有效实例。如果区块链节点104将一个实例接受为有效实例，然后发现第二实例已记录在区块链150中，则区块链节点104必须接受这一点，并将丢弃(即，视为无效)其最初接受的实例(即，在区块151中尚未公布的实例)。
作为基于账户的事务模型的一部分，由一些区块链网络操作的另一种类型的事务协议可称为“基于账户的”协议。在基于账户的情况下，每个事务均不通过参考过去事务序列中先前事务的UTXO来定义转移的数额，而是通过参考绝对账户余额进行定义。所有账户的当前状态由网络的节点单独存储到区块链中，并不断更新。在此类系统中，事务使用账户的运行事务记录(也称为“头寸”)进行排序。该值由发送者签名作为其加密签名的一部分，并作为事务引用计算的一部分进行哈希处理。此外，可选的数据字段也可以在事务中签名。例如，如果数据字段中包含先前事务的ID，该数据字段可指向先前事务。
基于UTXO的模型
图2示出了示例性事务协议。这是基于UTXO的协议的示例。事务152(简称“Tx”)是区块链150的基本数据结构(每个区块151包括一个或多个事务152)。下面将通过参考基于输出或基于“UTXO”的协议进行描述。但这并不限于所有可能的实施例。应当注意的是，虽然参考比特币描述了示例性基于UTXO的协议，但是它同样可以在其它示例区块链网络上实现。
在基于UTXO的模型中，每个事务(“Tx”)152包括数据结构，其包括一个或多个输入202和一个或多个输出203。每个输出203可包括未花费事务输出(UTXO)，其可用作另一新事务的输入202的来源(如果UTXO尚未赎回)。UTXO包括指定数字资产数额的值。这表示分布式分类账上的一组通证。UTXO还可包含其来源事务的事务ID以及其它信息。事务数据结构还可包括标头201，其可包括输入字段202和输出字段203的大小指示符。标头201还可包括事务的ID。在实施例中，事务ID是事务数据(不含事务ID本身)的哈希值，且存储在提交至节点104的原始事务152的标头201中。
比方说爱丽丝103a希望创建转移相关数字资产数额至鲍勃103b的事务152j。在图2中，爱丽丝的新事务152j标记为“Tx1”。该新事务获取在序列中先前事务152i的输出203中锁定至爱丽丝的数字资产数额，并至少将此类数额中的一部分转移至鲍勃。在图2中，先前事务152i标记为“Tx0”。Tx0和Tx1只是任意的标记，其不一定意味着Tx0指区块链151中的第一事务且Tx1指池154中的下一事务。Tx1可指向仍具有锁定至爱丽丝的未花费输出203的任何先前(即先行)事务。
当爱丽丝创建其新事务Tx1时，或至少在她将该新事务发送至网络106时，先前事务Tx0可能已经有效并包括在区块链150的区块151中。该事务此时可能已包括在区块151中的一个区块中，或者可能仍在有序集154中等待，在这种情况下，该事务将很快包括在新区块151中。或者，Tx0和Tx1可以创建并一起发送至网络106；或者，如果节点协议允许缓冲“孤立”事务，Tx0甚至可以在Tx1之后发送。本文事务序列上下文中使用的“先前”和“后续”一词是指由事务中指定的事务指针定义的序列中的事务顺序(哪个事务指向哪个其他事务等等)。它们同样可以替换为“前任”和“继任”、“先行”和“后代”或“父项”和“子项”等。这不一定指其创建、发送至网络106或到达任何给定区块链节点104的顺序。然而，指向先前事务(先行事务或“父事务”)的后续事务(后代事务或“子事务”)不会有效除非父事务有效。在父事务之前到达区块链节点104的子事务被视为孤立事务。根据节点协议和/或节点行为，其可被丢弃或缓冲一段时间，以等待父事务。
先前事务Tx0的一个或更多个输出203中的一个包括特定的UTXO，标记为UTXO0。每个UTXO包括指定UTXO表示的数字资产数额的值以及锁定脚本，该锁定脚本定义后续事务的输入202中的解锁脚本必须满足的条件，以使后续事务有效，从而成功赎回UTXO。通常情况下，锁定脚本将数额锁定至特定方(该数额的事务的受益人)。即，锁定脚本定义解锁条件，该解锁条件通常包括以下条件：后续事务的输入中的解锁脚本包括先前事务被锁定到的一方的加密签名。
锁定脚本(亦称scriptPubKey)是节点协议识别的域特定语言中写入的一段代码。此类语言的特定示例称为“脚本(Script)”(S大写)，其可由区块链网络所使用。锁定脚本指定花费事务输出203所需的信息，例如爱丽丝签名的要求。解锁脚本出现在事务的输出中。解锁脚本(亦称scriptSig)是提供满足锁定脚本标准所需信息的域特定语言中写入的一段代码。例如，其可包含鲍勃的签名。解锁脚本出现在事务的输入202中。
因此在示出的示例中，Tx0的输出203中的UTXO0包括锁定脚本[Checksig PA]，该锁定脚本需要爱丽丝的签名Sig PA，以赎回UTXO0(严格来说，是为了使试图赎回UTXO0的后续事务有效)。[Checksig PA]包含爱丽丝的公私密钥对中的公钥PA的表示(即哈希)。Tx1的输入202包括指向Tx1的指针(例如，通过其事务ID(TxID0)，其在实施例中是整个事务Tx0的哈希值)。Tx1的输入202包括在Tx0中标识UTXO0的索引，以在Tx0的任何其他可能输出中对其进行标识。Tx1的输入202进一步包括解锁脚本<Sig PA>，该解锁脚本包括爱丽丝的加密签名，该签名由爱丽丝通过将其密钥对中的私钥应用于预定的部分数据(有时在密码学中称为“消息”)创建。爱丽丝需要签名以提供有效签名的数据(或“消息”)可通过锁定脚本、节点协议或其组合进行定义。
当新事务Tx1到达区块链节点104时，该节点应用节点协议。这包括一起运行锁定脚本和解锁脚本，以检查解锁脚本是否满足锁定脚本中定义的条件(其中该条件可包括一个或更多个标准)。在实施例中，这涉及并置两个脚本：
<Sig PA><PA>||[Checksig PA]
其中“||”表示并置，“<…>”表示将数据放在堆栈上，“[…]”表示由锁定脚本组成的函数(在该示例中指基于堆栈的语言)。同样，脚本可以使用公共堆栈一个接一个地运行，而不是并置脚本。无论采用哪种方式，当一起运行时，脚本使用爱丽丝的公钥PA(包括在Tx0的输出的锁定脚本中)，以认证Tx1的输入中的解锁脚本是否包含爱丽丝签名预期部分的数据时的签名。也需要包括预期的部分数据本身(“消息”)，以便执行此认证。在实施例中，签名的数据包括整个Tx1(因此不需要包括一个单独的元素来明文指定签名的部分数据，因为其本身便已存在)。
本领域技术人员将熟悉通过公私密码进行验证的细节。基本上而言，如果爱丽丝已使用其私钥加密签署消息，则给定爱丽丝的公钥和明文中的消息，诸如节点104等其它实体可验证消息必须已经由爱丽丝签名。签署通常包括对消息进行哈希，签署哈希值和将此标记到消息作为签名，从而使公钥的任何持有者能够验证签名。因此，应当注意的是，在实施例中，在本文中对签名特定数据片段或事务部分等的任何引用可以意味着对该数据片段或事务部分的哈希值进行签名。
如果Tx1中的解锁脚本满足Tx0的锁定脚本中指定的一个或多个条件(因此，在所示示例中，如果在Tx1中提供了爱丽丝的签名并进行验证)，则区块链节点104认为Tx1有效。这意味着区块链节点104会将Tx1添加到待定事务有序池154。区块链节点104还会将事务Tx1转发到网络106中的一个或多个其它区块链节点104，以便其会在整个网络106中传播。一旦Tx1有效并包括在区块链150中，这会将UTXO0从Tx0定义为已花费。应当注意的是，Tx1仅在花费未花费事务输出203时才有效。如果其试图花费另一事务152已经花费的输出，则即使满足所有其它条件，Tx1也将无效。因此，区块链节点104还需要检查先前事务Tx0中引用的UTXO是否已经花费(即，其是否已经形成另一有效事务的有效输入)。这是为何区块链150对事务152施加定义的顺序很重要的原因之一。在实践中，给定区块链节点104可维护单独的数据库，标记已花费事务152的UTXO 203，但最终定义UTXO是否已花费取决于是否在区块链150中形成了另一有效事务的有效输入。
如果给定事务152的所有输出203中指定的总数额大于其所有输入202所指向的总数额，则这是大多数事务模型中的另一失效依据。因此，此类事务不会传播或包括在区块151中。
请注意，在基于UTXO的事务模型中，给定UTXO需要作为一个整体使用。不能“留下”UTXO中定义为已花费的一部分数额，而同时又花费另一部分。但UTXO的数额可以在后续事务的多个输出之间分割。例如，Tx0的UTXO0中定义的数额可以在Tx1中的多个UTXO之间分割。因此，如果爱丽丝不想将UTXO0中定义的所有数额都给鲍勃，她可以使用剩余部分在Tx1的第二输出中自己找零，或者支付给另一方。
在实践中，爱丽丝通常还需要包括用于比特币节点104的费用，该比特币节点104在区块151中成功包含爱丽丝的事务104。如果爱丽丝未包括此类费用，则Tx0可能会被区块链节点104拒绝，并且因此尽管在技术上有效，但可能不会传播并且包括在区块链150中(如果区块链节点104不希望接受事务152，节点协议不强迫区块链节点104接受)。在一些协议中，事务费用不需要其自身的单独输出203(即不需要单独的UTXO)。相反，输入202指向的总数额与给定事务152的输出203指定的总数额之间的任何差额都将自动提供给发布事务的区块链节点104。例如，假设指向UTXO0的指针是Tx1的唯一输入，并且Tx1仅具有一个输出UTXO1。如果在UTXO0中指定的数字资产数额大于在UTXO1中指定的数额，则可以由赢得工作证明竞赛以创建包含UTXO1的区块的节点104分配该差值。替代地或附加地，这不一定排除可以在其自身事务152的其中一个UTXO 203中明确指定事务费用。
爱丽丝和鲍勃的数字资产由区块链150中任何位置的任何事务152中的锁定至他们的UTXO组成。因此，通常情况下，给定方103的资产分散在整个区块链150的各种事务152的UTXO中。区块链150中的任何位置均未存储定义给定方103的总余额的一个数字。客户端应用程序105的钱包功能的作用是将锁定至相应方且在其它随后事务中尚未花费的各种UTXO值整理在一起。为实现这一点，其可以查询存储在任何一个比特币节点104处的区块链150的副本。
应当注意的是，脚本代码通常用示意图表示(即使用非精确语言)。例如，可以使用操作码(opcode)来表示特定功能。“OP_...”是指脚本语言的特定操作码。举例来说，OP_RETURN是脚本语言操作码，当在锁定脚本的开始处在操作码前加上OP_FALSE时，操作码创建事务的输出，该输出可以在事务内存储数据，从而将数据不可改变地记录在区块链150中。例如，数据可包括需存储在区块链中的文件。
通常，事务的输入包含对应于公钥PA的数字签名。在实施例中，这基于使用椭圆曲线secp256k1的ECDSA。数字签名对特定的数据段进行签名。在实施例中，对于给定事务，签名将对部分事务输入以及部分或全部事务输出进行签名。对输出的特定部分进行签名取决于SIGHASH标志。SIGHASH标志通常是包含在签名末尾的4字节代码，用于选择签名的输出(并因此在签名时固定)。
锁定脚本有时称为“scriptPubKey”，指其通常包括相应事务被锁定到的当事方的公钥。解锁脚本有时称为“scriptSig”，指其通常提供相应的签名。但是更通俗地说，在区块链150的所有应用中，UTXO赎回的条件并不一定包括对签名进行验证。更通俗地说，脚本语言可用于定义任何一个或多个条件。因此，可以优选更为通用的术语“锁定脚本”和“解锁脚本”。
侧信道
如图1所示，爱丽丝和鲍勃的计算机设备102a、120b中的每个计算机设备上的客户端应用程序都可以包括附加通信功能。此附加功能可使爱丽丝103a建立与鲍勃103b的单独侧信道107(在任何一方或第三方的鼓动下)。侧信道107使得能够脱离区块链网络交换数据。此类通信有时称为“链下”通信。例如，这可用于在爱丽丝与鲍勃之间交换事务152，而不将该事务(尚未)注册到区块链网络106上或将其发布到链150上，直到其中一方选择将其广播到网络106上。以这种方式共享事务有时称为共享“事务模板”。事务模板可能缺少形成完整事务所需的一个或多个输入和/或输出。替代地或附加地，侧信道107可用于交换任何其它事务相关数据，例如密钥、议付数额或条款、数据内容等。
通过与区块链网络106相同的分组交换网络101可建立侧信道107。替代地或附加地，侧信道301可以经由诸如移动蜂窝网络的不同网络或者诸如无线局域网络的局域网建立，甚至经由爱丽丝和鲍勃的设备102a、102b之间的直接有线或无线链路建立。通常，在本文中任何地方所指的侧信道107可以包括经由一项或多项联网技术或通信介质的任何一条或多条链路，这些链路用于“链下”交换数据，即脱离区块链网络106交换数据。在使用多条链路的情况下，链下链路束或集合整体上可以称为侧信道107。因此，应当注意的是，如果说爱丽丝和鲍勃通过侧信道107交换某些信息或数据等，则这不一定意味着所有这些数据都必须通过完全相同的链路或甚至相同类型的网络发送。
客户端软件
图3A示出了用于实现本公开方案的实施例的客户端应用程序105的示例性实施方式。客户端应用程序105包括事务引擎401和用户界面(UI)层402。根据上文讨论的方案以及稍后将进一步详细讨论的内容，事务引擎401被配置为实现客户端105的基础事务相关功能，诸如制定事务152，通过侧信道301接收和/或发送事务和/或其他数据，和/或发送事务至一个或更多个节点104以通过区块链网络106传播。根据本文公开的一些实施例，每个客户端105的事务引擎401可以包括功能403，该功能403被配置为生成通证事务。
该UI层402被配置为通过相应用户的计算机设备102的用户输入/输出(I/O)方式呈现用户界面，包括通过设备102的用户输出方式向相应用户103输出信息，和通过设备102的用户输入方式接收来自相应用户103的输入。例如，用户输出方式可包括提供视觉输出的一个或显示多个屏(触摸或非触摸屏)、提供音频输出的一个或更多个扬声器、和/或提供触觉输出的一个或更多个触觉输出设备等。用户输入方式可包括例如一个或更多个触摸屏的输入阵列(可与用于输出方式的那个/那些相同或不同)；一个或更多个基于光标的设备，诸如鼠标、轨迹板或轨迹球；一个或更多个麦克风和语音或声音识别算法，用于接收语音或声音输入；一个或更多个基于手势的输入设备，用于接收手动或身体手势形式的输入；或者一个或更多个机械按钮、开关或控制杆等。
注：虽然本文中的各种功能可以被描述为集成到同一客户端应用程序105中，但这并不一定构成限制，相反，它们可以在两个或更多个不同应用程序组成的一套程序中实现，例如一个应用程序作为另一个应用程序的插件或经由API(应用程序编程接口)进行接口。比如，事务引擎401的功能可以在单独的应用程序中实现，而不是在UI层402中实现，或者诸如事务引擎401的给定模块的功能可以在多个应用程序之间分割。同时，也不排除部分或全部描述的功能可以在比如操作系统层实现。在本文任何位置引用单个或给定应用程序105或诸如此类的情况下，应当理解的是这只是作为示例，并且更通俗地说，所描述的功能可以在任何形式的软件中实现。
图3B给出了用户界面(UI)500的示例的模型，该UI可由客户端应用程序105a的UI层402在爱丽丝的设备102a上呈现。应当理解的是，类似的UI可以由客户端105b在鲍勃的设备102b或任何其他方的设备上呈现。
通过图示的方式，图3B从爱丽丝的角度示出了UI 500。该UI 500可包括一个或更多个UI元素501、502、503，该一个或更多个UI元素通过用户输出方式呈现为不同的UI元素。
例如，UI元素可包括一个或更多个用户可选择的元素501，这些元素可以是屏幕上的不同按钮、菜单中的不同选项或者诸如此类。用户输入方式被设置成使用户103(在这种情况下为爱丽丝103a)能够选择或以其它方式操作其中一个选项，诸如通过点击或触摸屏幕上的UI元素，或者说出所需选项的名称(注：本文使用的“手动”一词仅用于与自动进行对比，而不一定限于用手执行操作)。
此外/或者，UI元素可包括一个或更多个数据输入字段502。这些数据输入字段通过用户输出方式呈现，例如屏幕上，并且数据可通过用户输入方式输入到字段中，例如键盘或触摸屏。或者，数据可以例如基于语音识别口头地接收。
此外/或者，UI元素可包括向用户输出信息的一个或更多个信息元素503。例如，这/这些可以在屏幕上呈现或可听见。
应当理解的是，呈现各种UI元素、选择选项和输入数据的特定方式并不重要。这些UI元素的功能稍后将进行更详细地讨论。还应当理解的是，图3中示出的UI 500只是一个图示模型，在实践中，它可包括一个或更多个进一步的UI元素，为了简洁起见，未对其进行说明。
区块链作为有向无环图
比特币分类账被广泛称为区块链，其中数据结构被视为区块链。然而，如果将事务作为基本元素(而不是区块)，可以看到，比特币分类账可以视为有向无环图。本节提供了比特币有向无环图(BDAG)的正式定义以及一种特殊类型的BDAG子图。
定义—比特币有向无环图
比特币有向无环图(BDAG)是一种DAG，其中
1.节点是比特币事务；
2.如果从第一节点到第二节点至少分配(花费)一个输出，则从一个节点到另一个节点建立有向边。
应当注意的是，该图是无环图，因为事务的有向循环意味着在其输入中循环引用事务ID，这是不可能的。
根据定义，可以突出以下几个特性：
1.每个节点最多可以有n个外向边，其中n是该节点表示的事务中可花费输出的数量；
2.coinbase节点没有内向边；以及
3.从任何节点开始，沿着边的相反方向，路径应在一个或多个coinbase节点处结束。
图4A示出了BDAG的示例。图4B示出了区块链结构压印到BDAG时的BDAG。
定义—事务路径
BDAG中从节点A到节点B的事务路径是一组节点N0,N1,…,Nt，其中
1.N0是节点A，Nt是节点B；
2.所有i＝0,1,…,t-1都有从Ni到Ni+1的有向边；以及
3.t被定义为路径长度。
定义—事务链
事务链是连接的BDAG的子图。也就是说，对于子图中的任何一对节点，忽略边的方向，两个节点之间都有一条路径。
应当注意的是，BDAG中的所有事务链构成了BDAG的一个分区。
如图4A所示，有两条事务链。第一事务链以两个coinbase事务开始，可以视为两个事务链的合并，而第二事务链以一个coinbase事务开始，结构要简单得多。
应当注意的是，虽然上述示例是指比特币分类账(即，比特币区块链)，但同样的定义也适用于其他UTXO模式的区块链。
核实/认证通证
本发明的实施例涉及核实通证事务。图7示出了可以与本公开的一些实施例一起使用的示例性系统700。然而，本发明不限于仅与该示例性系统一起使用；本发明提供了一种用于认证区块链通证的更通用的解决方案，并且本发明不限于用于生成和/或处理通证的通证化方法或协议的类型。
如图7所示，一种示意性的通证化系统700包括核实实体701、通证发行者702、一个或多个通证用户703a、703b以及区块链网络106。应当注意的是，虽然图7中仅示出了两个通证用户703a、703b，但是系统700通常可以包括任意数量的通证用户703。通证发行者702和一个或多个通证用户703中的每一个可以采取结合图1至图3所述的爱丽丝103a或鲍勃103b的形式。也就是说，通证发行者702和通证用户703中的每一个可以被配置为执行由爱丽丝103a和/或鲍勃103b执行的操作的部分或全部操作。
核实实体701可以采取若干形式中的一种形式，将在下文中详细地讨论。然而，核实实体701通常可以操作包括处理装置的计算机设备，该处理装置包括一个或多个处理器，例如，一个或多个CPU、GPU、其他加速器处理器、特定应用程序处理器和/或FPGA。计算机设备还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。该存储器可以包括一个或多个存储器单元，其采用一个或多个存储器介质，例如诸如硬盘等磁介质、诸如SSD、闪存或EEPROM等电子媒介和/或诸如光盘驱动器等光学介质。计算机设备上的存储器存储软件，其包括被设置为在处理装置上运行的至少一个客户端应用程序的相应实例。应当理解的是，在本文中归因于核实实体701的任何动作均可通过在计算机设备的处理装置上运行的软件执行。核实实体701的计算机设备可以包括至少一个用户终端，例如台式电脑或笔记本电脑、平板电脑、智能手机或诸如智能手表等可穿戴设备。核实实体701的计算机设备还可以包括一个或多个其他网络资源，诸如通过用户终端访问的云计算资源。客户端应用程序最初可通过例如从服务器下载的适当计算机可读存储介质，或通过诸如可移动SSD、闪存密钥、可移动EEPROM、可移动磁盘驱动器、软盘或磁带等可移动存储设备、诸如CD或DVD ROM等光盘或可移动光驱等提供至核实实体701的计算机设备。
核实实体701被配置为核实通证事务。核实实体701可以访问铸造(mint)事务。铸造事务铸造(即，发行)一定数量的通证。铸造事务可以由通证发行者702签名(即，铸造事务可以包括输入，输入包含链接到通证发行者702拥有的发行公钥的签名)，并且包括锁定初始数量的通证的输出。在其他示例中，铸造事务可以包括不同形式的加密数据，例如铸造公钥、由通证发行者签名的消息、由通证发行者加密的消息等。通常，铸造事务包括加密“铸造”数据。加密数据是作为加密方案的一部分使用的数据。铸造数据是已知与通证铸造关联的公共信息。铸造事务可以包括锁定相应初始数量的通证的多个输出。铸造事务记录在区块链150上。核实实体701可以从区块链150访问铸造事务，或者核实实体701可以在本地存储铸造事务。在一些示例中，铸造数据可以是知识证明，例如哈希难题或r难题。知识证明需要知道数据才能求解(即，解锁)。
核实实体701获得“目标通证事务”(即，要由核实实体701核实的通证事务)。目标通证事务可以由通证用户703提交给核实实体701。或者，目标通证事务可以由另一个核实实体701提交给核实实体。也就是说，系统700可以包括多个核实实体，例如图6所示的通证服务器601和通证客户端。目标事务可以某种其他方式获得。
目标通证事务成为有效通证事务的条件是目标通证事务必须是返回铸造事务的事务链的一部分。也就是说，目标事务必须包括引用(即，花费)铸造事务的输出的输入，或者引用作为返回铸造事务的事务链的一部分的先前通证事务的输入。在后一种情况下，先前事务必须包括引用铸造事务的输出的输入，或者引用作为返回铸造事务的事务链的一部分的先前通证事务的输入。换句话说，追踪先前通证事务的引用输出最终一定会通向通证事务。
核实实体701可以被配置为通过执行对引用输出的追踪来验证目标事务的通证。或者，核实实体701可以执行更高效的流程来验证第一条件，如下文所述。
一旦核实，即一旦已经确定目标通证事务中的通证的真实性，核实实体701可以将目标通证事务提交给区块链网络106。也就是说，通证用户703a可以将目标通证事务提交给核实实体以便根据区块链协议进行网络核实，并且在目标通证事务有效形成的条件下，核实实体701将目标通证事务转发给区块链网络106以便包括在分类账上。
核实实体701可以获得目标通证事务是有效区块链事务的确认。例如，核实实体701可以获得目标通证事务已在区块链150上的区块151中发布的确认。核实实体701可以从区块链节点104获得默克尔证明，以验证目标通证事务已在区块151中发布。一旦确信目标通证事务是有效区块链事务，核实实体701可以将目标通证事务记录在有效通证事务列表中。应当注意的是，核实实体701可以在获得目标通证事务是有效区块链事务的确认之前，将目标通证事务记录在有效通证事务列表中。在目标通证事务不是有效区块链事务的情况下，核实实体701可以选择从列表中删除目标通证事务。
在一些示例中，在核实目标通证事务后，核实实体701可以在将目标通证事务提交给区块链网络106之前对其进行签名。例如，目标通证事务可能是不完整的，核实实体701可以通过包含包括核实实体的签名(即，链接到核实实体701拥有的公钥的签名)在内的输入来完成目标通证事务。该签名表示目标通证事务已核实。在一些示例中，该输入可以是费用支付输入，即，支付由在区块151中发布事务的区块链节点104所收取的事务费用的输入。此类输入是“非通证输入”的示例。
目标通证事务可以包括一个或多个非通证输出。例如，非通证输出可以用于将费用支付输入和事务费用之间的差额返回给支付事务费用的实体。非通证输出可以用于其他目的。如果目标通证事务确实包括一个或多个非通证输出，则目标通证事务必须满足第三条件，才能视为有效通证事务。核实实体701被配置为验证目标通证事务的一个或多个通证输出锁定的通证总量不大于目标通证事务的通证输入所引用的输出锁定的通证总量。
在一些示例中，核实实体701还可以核实铸造事务。例如，核实实体701可以验证铸造事务包括链接到与通证发行者702关联的铸造公钥的签名。
核实实体701可以接收请求实体(例如，通证用户703b)的请求，以确认通证事务(例如，目标通证事务)是否是有效通证事务。核实实体701可以验证通证事务是否是有效通证事务，如果通证事务有效，则向请求实体提交告知通证事务是有效通证事务的响应。下面将更详细地讨论该请求和响应过程。
通证服务器
在一些实施例中，核实实体701可以包括“通证服务器”601。也就是说，核实实体701可以采取(或包括)被配置为执行核实实体701的动作的服务器的形式。通证服务器601可以存储有效通证事务(即，先前已核实的通证事务)的记录(例如，数据库)。这些通证事务可能已经由通证服务器601或另一个实体核实。在一些示例中，通证服务器601可以存储所有有效事务的记录。
在这些实施例中，通证服务器601可以通过确定所引用的事务是否存在于有效通证事务的记录中，例如通过执行对引用事务的事务ID的查找，来验证目标通证事务的通证输入引用了先前核实的通证事务的输出。
在一些示例中，通证服务器601可以构建“通证区块”。通证区块与区块链区块151有一些相似之处。通证区块包括通证区块头和有效通证事务列表(或至少有效通证事务的相应标识符)。一旦核实，目标通证事务就可以包括在当前(即，最新的)通证区块中。给定通证区块的通证区块头包括基于该通证区块中的一组通证事务计算的默克尔根。如下文所述，区块头可以包括附加字段。
与区块链区块151类似，通证区块的区块头可以包括指向通证区块序列(即，链)中的先前通证区块的指针。指针可以采取先前通证区块的区块头的哈希(例如，双重哈希)的形式。指针可以追溯到第一(即，第一个创建的)通证区块。
通证服务器601可以为每个区块链区块151构建一个通证区块。也就是说，通证区块可以基于给定通证区块中的事务(特别是通证事务)进行构建。通证区块可以在对应区块链区块151发布之前构建(例如，如果通证服务器601已经将区块链区块151中包含的通证事务发送给网络106)，也可以在区块链区块151发布之后构建(例如，通证服务器601可以扫描区块链区块151以查找通证事务)。
可选地，通证区块中的部分或全部通证区块可以包括一个或多个签名。签名可以包含在通证区块的相应区块头中。例如，通证服务器601可以包括用于确认通证区块确实是由通证服务器601构建的签名。签名消息可以包括通证区块中的部分或全部通证区块。在一些示例中，通证发行者703和/或一个或多个附加实体(例如，审计实体、政府机构或其他官方实体)可以包括相应的签名。
除了保持通证区块的记录外，通证服务器601还可以将一个或多个通证区块传输(例如，定期或根据请求)给请求实体(例如，通证用户703b或通证发行者702)。请求实体可以是通证发行者702、通证用户703或另一个核实实体(例如，下面描述的通证轻量级客户端)。通证服务器601可以传输完整通证区块，或者仅传输通证区块头。
在一些情况下，通证服务器601可以传输通证区块头(以及可选地完整通证区块)作为简化通证验证方法的一部分，以验证有效通证事务的存在和完整性。验证事务的完整性可以确保事务中的数据未被篡改。例如，请求实体(例如，通证用户702b)可能希望验证通证事务是否有效。所讨论的通证事务可以是当前通证事务(例如，目标通证事务)的输入引用的通证事务。为了确认引用的通证事务有效，通证服务器601可以向请求实体提供默克尔证明，以验证通证区块中存在引用的通证事务。默克尔证明对于技术人员来说是已知的。传输到请求实体的默克尔证明包含哈希序列。所引用的通证事务进行哈希处理后，与序列中的第一哈希级联，然后对其结果进行哈希处理。然后，将后续结果与序列中的后续哈希(如果存在)级联，然后对其结果进行哈希处理。序列中的每个哈希都有一个左指示符或右指示符。左或右可以由单个索引确定，该索引可以作为默克尔证明中的第一个数字。重复该过程，直到使用完序列中的每个哈希。如果最终哈希等于通证区块的通证区块头中包含的默克尔根，则所引用的通证事务包含在通证区块中。由于通证区块中只包含有效通证事务，因此所引用的通证事务必须有效，并且所引用的事务中的数据必须未经修改。
通证轻量级客户端
在一些实施例中，核实实体701可以包括“通证轻量级客户端”602a。也就是说，核实实体701可以采取(或包括)被配置为执行核实实体701的动作的客户端应用程序的形式。通证服务器601可以存储有效通证事务(即，先前已核实的通证事务)的记录(例如，数据库)。这些通证事务可能已经由通证轻量级客户端602a或另一个实体核实。
通证轻量级客户端602a维护通证区块头的记录，以及有效通证事务的事务标识符的记录。通证轻量级客户端602a还存储了有效通证事务的每个通证输出的通证值和索引的记录。例如，记录可以包括TxID||index||value形式的多个数据项。例如，根据请求和/或在通证服务器601构建每个通证区块时，可以从通证服务器601获得通证区块头。在一些示例中，通证区块头可以是通证轻量级客户端602a构建的通证区块。
通证轻量级客户端602a可以使用该记录来核实接收的通证事务。例如，通证轻量级客户端602a可以验证目标事务的通证输入所引用的通证输出是否存储在记录中，例如，通证轻量级客户端602a执行对记录中引用的TxID||index||value的查找。如果目标通证事务有效(即，满足有效性的一个或多个条件)，则通证轻量级客户端602a可以在记录中添加目标事务的一个或多个通证输出。在一些示例中，通证轻量级客户端602a可以从记录中删除引用的通证输出。
通证轻量级客户端602a可以从通证用户703接收通证事务，核实通证事务，然后将其提交给区块链网络106和/或通证服务器601。
与通证服务器601一样，通证轻量级客户端602a也可以构建通证区块。这些通证区块可以采取与通证服务器601构建的通证区块相同的形式。例如，通证轻量级客户端602a可以从通证用户703接收通证事务，并基于这些通证事务构建通证区块。通证轻量级客户端602a还可以将通证事务包含在通证区块中，通证事务已发送给通证轻量级客户端602a的不同实例，然后转发到通证轻量级客户端602a或从区块链150获得(在由另一个通证轻量级客户端提交到区块链网络106之后)。与通证服务器601一样，通证轻量级客户端602a可以为区块链150的每个新发布的区块构建通证区块。
在一些示例中，通证轻量级客户端602a可以将其构建的通证区块发送给通证服务器601，例如，以由通证服务器601进行验证。通证服务器601可以将其签名添加到此类通证区块的通证区块头中，并将其返回给通证轻量级客户端602a。在一些示例中，通证轻量级客户端602a可以从通证服务器601接收通证区块。例如，通证轻量级客户端602a可能暂时失去其与区块链网络106的连接，因此在此期间无法构建通证区块。
与通证服务器601一样，在一些情况下，通证轻量级客户端602a可以传输通证区块头(以及可选地完整通证区块)作为简化通证验证方法的一部分，以验证有效通证事务的存在。类似场景也适用，其中通证轻量级客户端602a向请求实体(例如，通证用户703)发送对应通证区块中包含的有效通证事务的区块头和默克尔证明。如果默克尔证明导致默克尔根包含在区块头中，则可以确认通证事务包含在通证区块中，因此是有效通证事务。
通证UTXO客户端
如图6所示，系统可以包括一个或多个通证UTXO客户端602b。这些客户端应用程序也被配置为核实通证事务。也就是说，核实实体701可以采取通证UTXO客户端应用程序602b的形式。通证UTXO客户端保存通证快照(token snapshot)的记录。通证快照包括一组通证UTXO。每个通证UTXO是通证事务的未花费通证输出。每个通证快照在不同的时间点捕获一组通证UTXO。
通证快照中的部分或全部通证快照由通证UTXO客户端602b构建。部分通证快照可以从通证UTXO客户端602b的不同实例接收，或从通证服务器601接收。在一些实例中，通证服务器601可以构建通证快照，并将其发送给通证UTXO客户端602b，例如，响应于通证UTXO客户端602b失去与区块链网络106的连接。通证快照可以通过追踪区块链上的通证UTXO进行构建，即，追踪哪些通证输出尚未被后续区块链事务(通证或非通证)有效地花费。
通证UTXO客户端602b被配置为通过验证目标通证事务的每个通证输入引用先前通证事务(可以是铸造事务)的相应未花费通证输出来核实通证事务(例如，目标通证事务)。通证UTXO客户端602b通过验证引用的通证输出是否存在于最新的通证快照中来实现这一点。
在核实通证事务后，通证UTXO客户端602b可以将通证事务传输到区块链网络106和/或通证服务器601。通证UTXO客户端602b可以构建新的通证快照，其中包括目标事务的一个或多个通证输出，但不包括引用的通证输出。
通证UTXO客户端602b还可以执行简化的通证验证方法来验证有效通证输出的存在。每个通证UTXO快照可以包括基于存储在快照中的通证UTXO计算的默克尔根。为了验证通证输出的存在，通证UTXO客户端602b可以向请求实体(例如，通证用户703)传输将给定通证UTXO链接到当前通证快照的默克尔根的默克尔路径。应当注意的是，可以为其叶采取以下形式中的一种形式的默克尔树构建默克尔根：
1.TxID||index
2.TxID||index||value
3.TxID||index||locking script||value
示例性通证系统
现在将描述示例性通证系统。应当理解的是，通证框架的某些特性是可选的，并且可以基于本发明的实施例的特定实现方式来选择其他变型。根据示例性框架，对区块链事务有尘埃限制(dust limit)，通证的值与原生区块链通证挂钩，并且没有通证特定数据推入锁定脚本。
设置事务
通证发行者702可以发布设置事务。假设通证发行者702想要发行代表国家货币的通证。应当注意的是，这只是通证系统的许多可能的用例中的一个用例。通证发行者702可以选择在设置事务中以不可花费(例如，OP_FALSE OP_RETURN)的有效载荷发布其链上通证的规范(specification)。或者，该规范可以在网站或任何其他适当的公共记录上发布，只要该记录得到用户和公众的普遍信任。这使得通证发行者702能够向公众开放通证链，并使得公众能够证实其通证的规则。每当有争议时，包括通证发行者702在内的通证用户703可以参考该规范解决争议。可以将该规范视为上市公司的条款或通证系统的条款和条件。该规范可以参考ERC-20标准、通证化标准或通证发行者认为合适的任何定制标准。如果通证链是私有链，那么可以在其哈希值中发布该规范，以确保其完整性。
下面给出了设置事务的一个示例：
其中<Specification>可以是
通证 Great Blockland Pound(GBP)
铸造公钥 PKmint
熔化公钥 PKmelt
挂钩比率(通证:聪) 1:1000
储备:发行 1:1
联系人详细信息 Alice@ctsforgbp.com
管辖权 Great Blockland
发行许可证 Great Blockland中央银行
第三方审计 审计公司(PKAudit)
审计日期 每月第一个星期四
通证核实 GBP Token Guide.pdf
额外信息 每人的GBP
通证发行者702使用签名对设置事务进行签名，并且包括发行公钥。该设置事务可以引用通证发行者702拥有的任何未花费事务输出(UTXO)。同样地，设置事务的输出可以锁定到任意公钥，例如，通证发行者702拥有的不同公钥。
应当注意的是，上面给出的规范仅用于说明目的。通证发行者702可以在设置事务中包含关于通证系统的所有详细信息。通常，该规范旨在证明通证系统在技术上稳健，并且符合法律要求。
示例性规范中明确示出了三个公钥。PKmint用于铸造通证，PKmelt用于熔化币，PKAudit用于证实通证系统的合规性。在设置事务的输入中，所有三个公钥均由通证发行者702的签名认证。其他类型的铸造数据可以代替公钥包含在规范中，也可以与公钥一起包含在规范中。
通证发行者702可以添加更多的公钥来提供更复杂的访问控制结构。例如，可能存在用于事务核实者701的公钥，在这种情况下，通证事务可以在发送给区块链网络106之前由核实者701进行核实和签名。随着通证系统的发展，通证发行者702还可以添加主证书公钥来创建认证公钥的分层结构。如下文所述，还可能有专用于支付事务费用的公钥。
在示例性框架中，通证与原生区块链通证挂钩。为简洁起见，本文将使用比特币的示例，但应当理解的是，这并不限于所有实施例。在这种情况下，比特币和通证之间有固定的兑换率。应当注意的是，这不是汇率。这只是通证值的一种方便的表示形式。例如，1000聪(sat)可以表示1GBP。给定输出为10,000sat的通证事务，因此通证输出的通证值为10GBP。值得注意的是，由于尘埃限制(在撰写本文时为546聪)，将挂钩比率定义为1：尘埃限制可能更方便，其中1是通证的最小不可分割单位。
应当注意的是，在该示例中，规范可能包括储备-发行比率。这表明通证发行者702不能发行超过其财务能力的通证。通证发行者702可能还需要获得中央银行的有效许可证，才能发行GBP通证。管辖权字段可以指定通证系统的监管地点，并且可以应用相关法律。这些合规性可以由第三方进行审计，审计结果可能会放在链上以实现透明性。通常，金融实体或通证发行者的所有传统方法都可以集成到示例性通证框架中。任何规则、法规或法律的执行都可以是链上和链下性质的结合。
铸造事务
为了铸造通证，通证发行者702构建铸造事务。下面给出了一个示例：
该示例性事务具有由通证发行者702准备的输入，并且包含可以通过公钥PKmint验证的签名。铸造事务可以包括不同形式的加密数据，例如签名或加密的消息。根据TxIDsetup中的规范，该事务铸造x1个GBP通证，GBP通证被分配给PK1的所有者。
事务费用是铸造输出点值-1000x1，此处假设通证发行者702准备的铸造输出点具有涵盖事务费用和第一输出值的确切数量。有关事务费用的更多讨论，请参见下文。
在下列情况下，区块链事务定义为通证铸造事务：
1.事务中的所有输入均包含一个或多个签名，这些签名可以通过一个或多个铸造公钥进行验证；以及
2.区块链事务是有效区块链事务。
该定义的含义是，比特币使用铸造公钥进行染色。颜色随后在整个事务链(始于一个或多个铸造事务)中得以保留。要检查区块链事务是否是通证事务，可以通过事务链追溯到铸造事务。然而，这会引起技术挑战，因此提供了本公开的实施例以缓解或消除这些问题，如下文所述。
通证发行者702将能够构建多个此类事务来满足通证的需求。在这种情况下，能够铸造的通证数量受到通证发行者702拥有的比特币数量以及规范中的规则的限制。
花费事务
一旦铸造事务在区块链150上发布，拥有铸造事务的通证输出所锁定的公钥的通证用户703就可以花费通证。
考虑下面的事务，TxIDspend，其花费TxIDmint。
该事务没有明确引用公钥PKmint。要将该事务确定为通证事务，需要追溯到输入中引用的事务，即TxIDmint。通过在本地或从区块链网络106获得TxIDmint，可以验证这是有效通证铸造事务，因此，TxIDspent是通证事务。要核实通证事务，需要进行三项主要检查：
1.输入中引用的输出点未花费；
2.输出值不大于输入值；以及
3.签名有效(或脚本核实成功)。
应当注意的是，所有这些检查都与正常的区块链事务核实一致。因此，所有检查都可以委托给区块链节点104。简而言之，通常，通证事务核实只包括两个步骤：
1.检查输入是否可以追溯到通证铸造事务；以及
2.从区块链节点获得通证是区块链有效通证的确认。
然而，本公开的实施例提供了如下文所述的修改。
事务费用
有三种方式可以处理通证费用。
第一种是仅使用通证的方法。为了保持通证事务核实的简单性，同时确保通证事务仅由通证输入和输出组成，可以通过燃烧一小部分通证来支付事务费用。如TxIDspend所示，PK1的所有者将x2GBP通证转移给PK2的所有者。事务费用1000(x1-x2)有效燃烧(x1-x2)通证。对于通证用户来说，这可以视为通证转移费用。对于通证发行者来说，这意味着系统中的通证数量会随着使用而减少。对于自然贬值的某些类型的通证来说，这可能是需要的特性。另一方面，如果这是通证发行者702的问题，则可以不时地铸造新通证来补偿事务费用。
如果区块链节点104可接受零费用事务，那么为通证事务支付费用的问题将被消除。然而，通证发行者702可能必须通过商业合同以法定货币形式在链下向区块链节点104支付。在这种情况下，通证发行者702实际上是在为通证用户703支付事务费用。
第二种是使用公钥的方法。另一种可能性是使用公钥来指示通证事务中输入的目的。在这种情况下，通证发行者702可以在设置事务的规范中引入费用支付公钥或其集合。费用支付公钥可以由通证发行者拥有，并分发给通证钱包。其思路是为每个通证花费事务增加一个输入，以涵盖确切数量的事务费用。下面给出了一个示例。
应当注意的是，费用输出点不是通证输入，因为无法将其追溯到通证铸造事务。然而，由于解锁脚本中的公钥可以确定为由通证发行者702认证的有效公钥，因此费用输出点不会使通证事务无效。为了使其更加灵活，通证发行者可以允许用户注册其费用支付公钥。可以在规范的更新版本中发布认证费用支付公钥列表。
这种方法的优点是通证事务的所有输出均为通证输出。这简化了核实过程。作为通证发行者702，也可能使用费用支付输入作为对通证转移的审批。通证用户703首先构建部分事务。通证发行者702或钱包软件通过添加费用输入来完成事务，从而审批事务。这种额外的审批流程也可以防止用户意外燃烧通证。
相对于仅使用通证的方法，该方法有两个缺点。
1.必须进行几项额外的检查。
a.检查规范中是否包含费用支付公钥。
b.检查输出值是否等于(或不大于)通证输入值。这是为了确保通证用户不会通过从费用支付输入中“借用”一些比特币来夸大通证输出值。在仅使用通证的方法中，输入仅由通证输入组成，因此该检查与检查总输出值是否不大于总输入值相同，并且可以委托给区块链节点104。
2.费用输出点必须包含用于支付事务费用的确切数量。无法收集任何更改，因为不允许非通证输出。这需要通证用户或通证发行者在转移通证之前准备好费用输出点。
在计算方面，1b产生的开销可以忽略不计，而在防止通证意外燃烧方面，其带来的好处相当显著。通过使通证发行者702拥有的费用输出点池或服务器为每个通证事务请求提供适当的费用输出点，也可以减轻第二个缺点。
第三种是SIGHASH_SINGLE方法。该方法的目的在于解决支付事务费用缺乏灵活性的问题，同时区分通证和非通证输出。可以注意到，支付事务费用和收集一些更改只需要通证事务的一个输入和一个输出。可以使用SIGHASH_SINGLE来链接这对输入和输出，以便将该输出与其他输出区分开。
SIGHASH_SINGLE是附加到签名的标志，用于指示使用签名进行签名的消息不包括所有输出(与包含签名的输入具有相同索引的输出除外)。应当注意的是，其他区块链可能出于相同目的使用不同的签名标志，SIGHASH_SINGLE仅用作说明性示例。这意味着，如果签名输出的索引保持不变，则可以在不使签名无效的情况下向事务添加输出或修改输出。由于不包含SIGHASH_NONE，因此无法添加或修改任何输入。
为了构建花费事务，用户向其钱包软件或支付事务费用的实体(可以是用户自己)提交通证输入，例如TxIDmint||0。然后，将未完成的事务构建为：
应当注意的是，签名Sigfee对TxID″spend-incomplete中所示的所有输入和第一输出进行签名。
在接收或构建未完成的事务时，用户703通过添加任意数量的通证输出来完成该事务，并对更新的事务进行签名。
在该事务中，签名Sig1对所有输入和输出进行签名。有以下关于值的等式：
事务费用＝费用输出点值-z
x1＝x2+x3
有几种方法可以区分费用支付输入和通证输入。
1.检查输入是否是通证输出。如果没有可供参考的通证输出点列表，这将非常困难。如果从费用输出点开始追溯，可能需要很长时间才能得出否定的结论。
2.将第一输入始终定义为费用支付输入。这可以作为钱包软件的一部分来实现。
3.使用SIGHASH_SINGLE将输入定义为费用支付输入。这意味着其他通证输入都不能使用SIGHASH_SINGLE。
假设可以区分费用支付输入和通证输入，确定非通证输出只是检查输出的索引是否与费用支付输入的索引相同。
然而，如果假设使用SIGHASH_SINGLE标记费用支付输入(方法3)，则可以直接确定非通证输出，而无需确定费用支付输入。对于每个输出，可以统计用于对该输出进行签名的签名的数量。非通证输出的签名数量最多，因为非通证输出总是至少有一个来自费用支付输入的额外签名。
由于通证输出的这一特性，在输出点级别出现了另一种类型的有向无环图。
输出点签名有向无环图(O-SDAG)
输出点签名有向无环图是一种DAG，其中
1.节点是区块链事务输出点；
2.如果第二节点是由分配(花费)第一节点所需的签名进行签名的消息的一部分，则建立从一个节点到另一节点的有向边。
大体上讲，输出点作为节点，签名作为边。O-SDAG中的所有边都在区块链事务中建立。图5示出了O-S DAG的示例，TxID″spend作为示例。
该SIGHASH_SINGLE方法的优点是提供了支付事务费用的灵活性。
非通证输入的安全性
在通证事务中引入了非通证输入，以支付事务费用。这些非通证输入可能被意外地或恶意地用来夸大通证输出的值。需要执行检查，以确保将这些通证事务视为无效。
假设通证事务的总输入值(以聪为单位)为VItoken+VInon-token，总输出值为VOtoken+VOnon-token，事务费用为Vfee，则
VOtoken+VOnon-token+Vfee＝VItoken+VInon-token。
预计VOtoken＝VItoken。然而，通证用户可以从VOnon-token或Vfee获取一些聪。也就是说，
VO′token+VO′non-token+V′fee＝VOtoken+VOnon-token+Vfee
其中VO′token＞VOtoken，并且VO′non-token+V′fee＜VOnon-token+Vfee。
作为区块链事务，仍然有效。作为通证事务，则视为无效。
下面给出了一对通证事务的一个示例。
/>
第一事务是通证有效事务，因为通证输出具有与通证输入相同的值，并且费用输入和费用输出之间的差额表明事务费用为2000聪。第二事务是通证无效事务，因为通证输出大于通证输入。然而，输入总值和输出总值之间的差额表明事务费用为1000聪。该事务是区块链有效事务，会被区块链节点所接受。因此，如果发布该事务，则1000聪表示的通证值将会丢失。
在仅使用通证的方法以及使用公钥的方法中，必须在通证输入和输出完成后添加费用支付输入。因此，费用支付实体(通证发行者或钱包软件)可以在对通证事务进行签名之前执行检查。
值得注意的是，用户没有动机以这种方式故意夸大通证输出，因为这会燃烧其通证。另一方面，任何意外错误都会永久记录在区块链上。通证用户可以向通证发行者证明意外是真实的，发行者可以选择铸造新通证来补偿用户。然而，避免任何意外错误仍然很重要。
通证事务有效性
已经介绍了如何铸造和花费通证。现在可以对通证事务的有效性给出全面的定义。
定义—通证输出点
如果满足以下条件，则输出点TxID||Index是通证输出点：
1.事务TxID是通证铸造事务；或
2.存在从通证铸造事务到事务TxID的事务路径；以及
3.索引与费用支付输入或非通证输入的索引不对应。
定义—通证事务有效性
如果通证事务是有效通证铸造事务或在以下情况下，该通证事务有效：
1.通证事务是区块链有效事务；
2.其输入中的至少一个输入引用了通证输出点；以及
3.其通证输出的总值小于或等于其通证输入的总值。
根据上面的定义，对于每个区块链事务，需要将其追溯到铸造事务或coinbase事务。如果以铸造事务结束，则该事务是通证事务。如果以coinbase事务结束，而无需确定铸造事务，则该事务不是通证事务。当通证系统扩展时，可能很难确定通证事务并对其进行核实。改善这种情况的一种方法是保存已知有效通证事务的记录。核实者可以停在已知的有效通证事务，而不是一直追溯到铸造事务。此外，如果核实者可以访问一组可信的未花费通证输出点，则可以用检查该组成员的查找操作来代替追溯。
为了解决通证系统的可扩展性，提出了几个选项来优化通证事务核实。首先描述保存所有通证事务记录的通证服务器601。然后提出关于该记录的区块结构，因此需要描述通证系统的轻量级客户端。为了进一步提高效率，可以利用通证客户端，该通证客户端使用通证UTXO快照。
定义—通证服务器
通证服务器601必须满足以下要求：
1.能够核实通证事务；以及
2.连接到区块链网络。
第一个要求意味着通证服务器601必须存储关于通证系统的一些信息，以识别区块链事务的输入是通证输入。有许多方法可以实现这一点。
最直接的方法是将通证设置事务与通证规范和所有后续通证事务一起存储。通证服务器601首先检查输入的公钥和对应签名，从而检查事务是否是通证铸造事务。如果不是，通证服务器601检查区块链事务的输入是否来自一些历史通证事务。如果检查通过，则通证服务器601可以开始核实下面定义的通证事务。
应当注意的是，双重花费检查将由区块链节点进行，对于通证客户端是可选的。如果通证服务器601将对事务有效性的一些检查委托给区块链节点，该区块链节点需要等待来自网络的有效性确认。因此，定义中有第二个要求。
也可以用格式检查来代替签名验证，这样可以更有效地实现。其思路是确保在输入中提供公钥时，也存在对应的签名，并将签名验证委托给区块链节点。如果锁定脚本是标准P2PKH，并且输入中的解锁脚本仅包含一个公钥和一个签名，就可以实现这一点。可能允许其他通用脚本，如果脚本有问题，可以退回到签名核实。
通证区块
关于通证服务器601上存储的数据的结构，可以模拟区块链系统并引入通证区块的概念。因此，能够在下一节中介绍通证轻量级客户端602a的概念。下面给出了通证区块定义的一个示例。
定义—通证区块
通证区块包括区块头和有效通证事务列表。该区块头可以包含以下字段中的部分或全部字段，其中
1.版本指示该区块属于哪个通证系统；
2.先前区块头哈希是先前通证区块头的双重SHA256值，创世通证区块为空；
3.默克尔根是基于该通证区块中的通证事务计算的；
4.比特币区块高度指示所有通证事务来自哪个比特币区块；以及
5.事务计数指示通证区块中包含的通证事务的总数。
可以将数字签名列表添加到每个通证区块，以指示每个签名者已验证该区块的有效性，其中在以下情况下，通证区块有效：
1.所有事务都是通证有效事务；
2.所有事务均来自区块链区块高度指定的区块链区块；
3.包含先前通证区块头的哈希值；
4.正确计算通证事务的默克尔根；以及
5.事务计数正确。
一旦发布新的区块链区块，通证服务器601就会构建通证区块。例如，给定新发布的区块链区块：
区块版本 0x00000001
Prev_Block 000000000000000000123456789912345678fe123456786cc1234123488d3f0c7
Merkle_Root 1234567891234567814159265359143c203141592653598a63814159265359
时间戳 2021-02-04 10:50:50utc
Difficulty_Bits 18027387
Nonce 3141592653
Tx_Count 718281
Txs TxID1,TxID2,…,TxID718281
通证服务器601构建通证区块，如下所示：
版本 爱丽丝的GBP通证
Prev_Block 先前通证区块头的双重SHA256
Merkle_Root MRtoken
Bitcoin_Block_Height 672038
Tx_Count 4
Txs TxID1,TxID2,TxID3,TxID4
签名 <sig><PK>
1.使用版本字段指示该区块属于哪个通证系统。
2.先前区块哈希是先前区块头的哈希值。应当注意的是，此处不需要工作证明。
3.默克尔根是根据通证区块中包含的事务计算的。另一种方法是使用比特币默克尔根。
4.使用名为比特币区块高度的新字段来指示所有通证事务属于哪个比特币区块。
5.事务计数指示通证区块中有多少事务。
6.完整事务列表列在事务字段中。
7.签名字段使实体能够添加对区块头进行签名的数字签名。该签名可以是通证发行者或委托者的签名。只有在成功验证通证区块后，才能添加签名。
应当注意的是，通证区块头包括通证区块中的前5个字段。
每个区块链区块最多只能有一个通证区块，一个通证区块不可能包含来自两个不同区块链区块的一组事务。
通证系统不需要工作证明。然而，由于关于通证系统的所有信息都可以从区块链分类账中获得，因此通证系统的安全性继承自区块链系统。添加到区块中的签名为通证区块核实提供了快捷方式。然而，如果用户不信任签名者，他们仍然可以独立地核实区块。核实通证区块所需的所有信息在区块链分类账上都是公开的。另一方面，如果可以公开验证通证区块，则激励签名者不对无效通证区块进行签名。
共同关注的问题是孤块，这种情况很少发生。通证系统确实像区块链系统一样需要重组。当一个或多个有效区块由于存在另一个具有更多工作证明的较长链而成为孤块时，在所述一个或多个区块中而不在另一个较长链中的所有事务将返回到其未发布状态。这同样适用于通证状态。然而，在许多情况下，诚实的用户和诚实的区块链节点不会受到重组的影响，因为竞争链上的事务完全相同。对于通证发行者来说，需要确保维护其通证系统的通证服务器601连接到网络的大部分，以便对其通证系统有准确的最新看法。
为了优化通证核实，可以尽量减少通证事务的存储，并提高查找效率。作为比特币轻量级客户端的对应客户端，引入了通证轻量级客户端602a。
通证轻量级客户端
通证轻量级客户端602a是保持以下事项的通证客户端：
1.通证设置事务；
2.通证区块头；
3.事务ID中的通证事务；以及
4.每个存储的事务ID的每个输出的通证值和索引。
最后两项可以级联成TxID||index||value形式的字符串。
通证轻量级客户端602a能够进行通证事务核实和通证区块构建。
在将通证事务发送给通证轻量级客户端602a时，执行以下步骤：
1.通过将其输入中的公钥与通证规范中的公钥进行比较，检查通证事务是否为铸造事务。
2.如果不是，对于每个输入，检查引用的输出点是否与本地存储的通证输出点匹配。
3.如果存在匹配，则确定所有通证输出，并检查通证输入的总值是否等于(或大于)通证输出的总值。
如果检查通过，通证轻量级客户端602a将事务保存为其通证输出中的每个通证输出的TxID||index||value||flag。标志指示对应的事务输出(TxID||index)是已花费还是未花费。然后，将通证事务发送给区块链网络进行进一步检查。
当通证轻量级客户端602a从区块链节点获得事务有效或被接受的确认时，通证轻量级客户端602a可以将该事务包含在后续通证区块中。当发布新的区块链区块时，通证轻量级客户端602a可以构建对应的通证区块。应当注意的是，构建通证区块不需要完整的事务数据。只需要事务ID足以。此外，也没有构建区块所需的工作证明。仔细检查所有的计算和记录是否正确可能是明智的。可以通过获得通证发行者的签名来完成通证区块。
通证UTXO客户端
通过观察可能不必存储花费的通证事务或通证输出点，可以进一步改进通证系统。在本节中，在保持如上所述的通证服务器601的同时，引入通证UTXO客户端602b的概念。通证UTXO客户端602b负责追踪所有未花费通证输出点，这将提高通证事务标识和核实的效率。如果出现任何错误，通证系统总是可以退回到通证服务器601。
定义—通证UTXO快照
通证UTXO快照包括快照头和一组输出点。快照头包含5个字段，其中
1.版本指示该快照属于哪个通证链；
2.先前快照头哈希是先前通证快照头的双重SHA256值；
3.默克尔根是基于通证UTXO集中的所有输出点计算的；
4.比特币区块高度指示通证UTXO集导出到哪个比特币区块；
5.输出点计数指示通证UTXO集中的输出点总数。
通证服务器601和/或通证UTXO客户端602b可以构建并保存通证UTXO快照列表。下面给出了一个示例：
版本 爱丽丝的GBP通证
Prev_Block 先前通证快照头的双重SHA256
Merkle_Root MRtoken-UTXO
Bitcoin_Block_Height 672038
UTXO_Count 4
UTXO_set TxID1||0,TxID1||1,TxID2||0,TxID3||1
签名 <sig><PK>
该解决方案的优点在于，作为通证客户端，可以选择仅存储最新的通证UTXO快照，因为其中包含通证客户端验证通证事务和构建后续的通证UTXO快照所需的所有信息。在接收区块链事务时，通证客户端只需要在输入中查找输出点，并检查其是否在最新的通证UTXO集中。如果该输出点在最新的通证UTXO集中，则该输出点是有效通证输入。应当注意的是，通证客户端不检查双重花费情况。该检查由区块链节点完成。这是基于UTXO的通证系统的主要优点之一。
缺点是，如果最新的通证UTXO快照损坏，通证UTXO客户端602b必须检索可用的最后一个通证UTXO快照，后续区块链区块或通证区块随后逐块导出最新的快照。在这种情况下，通证服务器将成为所需信息的可信来源。
为了进一步降低丢失最新UTXO快照的潜在风险，通证发行者可以选择设置多个通证服务器和几个通证UTXO客户端来维护其通证系统。如果一个通证UTXO客户端602b发生故障，其他UTXO客户端可以提供用于快速恢复的信息，同时保持通证系统不间断运行。
图6示出了通证网络的示例。简而言之，通证网络可以包括以下各项的部分或全部：
·通证服务器601，其存储所有通证相关事务并将其构建为区块；
·一个或多个通证轻量级客户端602a，其存储所有通证输出点及其对应值；以及
·一个或多个通证UTXO客户端602b，其存储所有未花费通证输出点及其对应值。
以上各项中的全部都能够核实通证事务并创建检查点(例如，通证区块或通证UTXO快照)，以提高效率。
改进通证验证
如上文所述，要检查区块链事务是否是通证事务，可以通过事务链追踪到铸造事务。然而，当系统达到一定规模时，这可能很难做到，因为随着时间的推移，通证的历史链的长度不断增加，从而导致追踪和比较操作所需的资源增加。以下技术可以作为本文所述“通证区块”和“通证轻量级客户端”方法的附加或(优选地)替代方案使用。
参考图7，本公开的实施例提供了避免需要一直追踪到铸造事务的机制。相反，在该铸造事务之后的某个点，将至少一个通证验证/认证元素插入到通证事务链中，使得验证实体701只需从给定或当前通证事务(例如，上述目标通证事务)追踪到可标识的认证元素。根据一种方法，该链中的每个通证事务可以由发行者进行印记，以认证每个通证事务携带的通证。然而，这可能需要代表发行者702和验证/使用方701、703的大量资源。因此，在一个优选实施例中，使用认证元素周期性地在该链上进行印记，从而减少对将该链遍历回其来源的需求以及对该链中的每个事务进行印记的需求。周期性印记的另一个优点在于，使得能够使用离线通证事务。在互联网和其他网络连接不可用的情况下，这可能是非常有利的。例如，在飞机上或在无法连接的地理位置进行事务和传输。此类离线传输在现有技术方法中是不可能的，在现有技术方法中，发行者需要对每个事务进行印记。
该通证认证元素认证在通证事务中提供的至少一个通证是由发行者702或代表该发行者生成的。在一些实施例中，通证事务包括一个通证，而在其他实施例中，通证事务可以包括多个通证。从这里开始，为了便于参考，使用单数通证。类似地，可以在通证事务中提供一个或多个认证元素，并且一个或多个发行者可以使用一个或多个铸造事务来发行通证、通证事务和/或认证元素。然而，为了方便起见，使用单数通证、通证事务和/或认证元素。
在一些实施例中，响应于请求或指令，在通证事务中提供至少一个通证认证元素。该请求或指令可以源自通证用户703、通证的预期接收者、发行者702或其代表或某个其他一方。附加地或替代地，可以根据至少一个预定规则或标准在通证事务中提供认证元素。规则/标准的执行或评估可以由基于软件的组件来自动处理和执行，该基于软件的组件可以由核实实体701或代表该核实实体执行。例如，该至少一个预定规则或标准可以指定用于标识或选择通证事务链内的事务的阈值、间隔或度量，以便随后可以由发行者702或由该发行者授权执行该操作的实体将认证元素插入其中。
该认证元素包括通证是真实或可信的某种形式的证据，因为它已经由发行者702合法形成。通过这种方式，这使通证事务中的通证合法化，并且该通证存在于事务中在验证过程中用作铸造事务的替代物。因此，该认证元素可以采用履行该角色的任何适当的形式，例如证明发行者已知或与该发行者相关联的秘密和/或加密数据。加密数据可以包括与发行者相关联的，或者与由发行者授权或与发行者相关联的一方相关联的加密密钥、签名、数字签名消息或其他加密元素。实质上，该认证元素提供的证据可以被信任为属于发行者/授权方或仅对发行者/授权方已知的证据。
该认证元素可以在至少一个通证事务中以各种位置和/或格式提供。例如，该认证元素可以在指令或代码之后(例如，在其他OP_RETURN指令之后)的位置插入到事务中。该认证元素可以在脚本中的其他地方提供，和/或作为元数据提供。
随着通证事务链因通证的使用和传输而随时间增长，当新的通证事务被添加到分类账150时，在新的通证事务中提供相同或不同的认证元素。因此，该链可以包括在连续的通证事务中或优选地以间隔提供的多个认证元素。当所认证的通证事务间隔开时，这些通证事务之间的间隔可以由上述规则或标准来定义。例如，可以在分类账150上每隔x个通证事务提供一个认证元素。可以容易地设计和实现用于确定该间隔的其他度量。或者，可以随机地或特定地，或者(如前所述)响应于请求、指令或监控状态等触发事件，将该认证元素插入到该链中。该监控状态可以涉及位于区块链上或区块链外的实体、资源或状况。
该认证元素可以由需要核实或认证给定通证事务中的通证确实由发行者702发行的任何实体或任何方利用。例如，这可以是核实实体701或用户703或通证客户端602b。传统上，此类方需要通过将事务链追踪到铸造事务来确定通证的起源，以验证它确实由发行源生成，但是本公开的实施例使得验证方能够仅将通证事务链从通证事务遍历到包含通证认证元素的先前通证事务。这节省了大量能量、时间和处理资源。
本公开的实施例可以包括与通证的熔化和重新铸造相关的特征。这些特征可以附加于上述核实技术，或者与上述核实技术一起或结合上述核实技术来提供。根据此类实施例，如上所述，该至少一个通证在区块链(150)上的通证事务中提供，并且由发行方702或代表该发行方在原始铸造事务中生成。有利地，熔化和重新铸造该通证。在一些实施例中，这可以在特定随机或伪随机的基础上执行，尽管在一个优选实施例中，这是在已经达到预定阈值、限制或指定值时执行的。根据一种形式的措辞，熔化可以描述为修改通证或通证事务，或者执行某种链下操作，使得通证不再被视为有效或不再由发行者702认证/验证。根据一种形式的措辞，重新铸造可以描述为修改通证或通证事务，或者执行某种链下操作，使得通证保持有效或由发行者702认证/验证，但是修改或其他操作的执行可以验证。通证保持有效并由发行者702批准，但是该通证的有效性以不同的形式重新体现。该通证的先前形式不再有效。
熔化操作可以包括提供标识元素、标记或数据的其他部分以指示通证不再有效。用于熔化和重新铸造的特定机制将取决于所涉及的实现方式，但是在一个示例性实施例中，这可以包括提供标识元素、标记或数据的其他部分以指示通证不再有效。类似地，重新铸造可以各种方式执行，包括提供标识元素、标记或数据的其他部分以指示通证有效但采用修改形式。
标识元素可以采用各种形式，包括标识符和/或加密数据，例如加密密钥、签名、签名消息等。优选地，标识元素与至少一个发行者或由至少一个发行者授权的一方相关联，并且用作发行者的批准或发行。标识元素可以在区块链事务中提供，优选地在通证事务中提供，或者在区块链之外提供的存储资源中提供。
预定阈值、限制或指定值可以由发行者或某个其他方监控，以确定何时已经达到该预定阈值、限制或指定值。这可能涉及将该预定阈值、限制或指定值与所提供的值进行比较。当发行者或其他方确定已经达到或超过阈值时，可以执行熔化和/或重新铸造操作。这具有以下优点：即减少所需资源并提高效率，如上所述。在一些实施例中，该预定阈值、限制或指定值由发行者或核实实体(701)或代表该发行者或核实实体确定。
结论
一旦给出本文的公开内容，所公开技术的其它变体或用例对于本领域技术人员可能变得显而易见。本公开的范围不受所描述的实施例限制，而仅受随附权利要求限制。
例如，上面的一些实施例已经根据比特币网络106、比特币区块链150和比特币节点104进行了描述。然而，应当理解的是，比特币区块链是区块链150的一个特定示例，并且上述描述通常可以应用于任何区块链。也就是说，本发明决不限于比特币区块链。更一般地，以上对比特币网络106、比特币区块链150和比特币节点104的任何引用可以分别参考区块链网络106、区块链150和区块链节点104来替换。区块链、区块链网络和/或区块链节点可以共享如上所述的比特币区块链150、比特币网络106和比特币节点104的部分或全部所述特性。
在本发明的优选实施例中，区块链网络106是比特币网络，并且比特币节点104至少执行对区块链150的区块151进行创建、发布、传播和存储中的所有所述功能。不排除可能存在仅执行这些功能中的一个或部分功能但不是全部功能的其它网络实体(或网络元件)。也就是说，网络实体可以执行传播和/或存储区块的功能，而不创建和发布区块(请记住，这些实体不被认为是优选的比特币网络106的节点)。
在本发明的非优选实施例中，区块链网络106可以不是比特币网络。在这些实施例中，不排除节点可以执行对区块链150的区块151进行创建、发布、传播和存储中的至少一个或部分功能但不是所有功能。例如，在这些其它区块链网络上，“节点”可用于指被配置为创建和发布区块151但不存储和/或传播这些区块151到其它节点的网络实体。
甚至更通俗地说，上面对术语“比特币节点”104的任何引用可以用术语“网络实体”或“网络元件”代替，其中这样的实体/元件被配置为执行对区块进行创建、发布、传播和存储中的一些或全部角色。这种网络实体/元件的功能可以在硬件中实现，方法与上面参照区块链节点104所述的方式相同。
应当理解的是，上述实施例仅通过示例的方式进行描述。更通俗地说，可根据下述任何一个或多个语句提供一种方法、装置或程序。
语句1.一种区块链实现的方法，用于对在通证事务中提供的至少一个通证的真实性进行背书或证实，所述通证事务是通证事务链中的元素，其源自至少一个铸造事务，所述铸造事务由至少一个发行者或代表所述至少一个发行者用来生成所述至少一个通证；
其中，所述方法包括：
在所述通证事务中提供至少一个通证认证元素，所述至少一个通证认证元素认证：所述至少一个通证是由所述至少一个发行者或代表所述至少一个发行者生成的。
语句2.根据语句1所述的方法，其中通过以下方式在所述通证事务中提供所述至少一个通证认证元素：
响应于请求或指令；和/或
根据至少一个预定规则或标准。
语句3.根据语句2所述的方法，其中所述至少一个预定规则或标准指定阈值、间隔或度量，所述阈值、间隔或度量用于标识或选择所述通证事务链内的所述事务。
语句4.根据前述任一项语句所述的方法，其中所述至少一个认证元素由所述至少一个发行者或由所述至少一个发行者授权的一方在所述通证事务中提供。
语句5.根据前述任一项语句所述的方法，其中所述至少一个认证元素包括：
秘密的证明，其被所述至少一个发行者已知或与所述至少一个发行者相关联；和/或
加密数据，优选地，其中所述加密数据是或包括与所述至少一个发行者或由所述至少一个发行者授权的一方相关联的加密密钥、签名、数字签名消息或其他加密元素。
语句6.根据前述任一项语句所述的方法，其中通过以下方式在所述通证事务中提供所述至少一个认证元素：
在使所述通证事务不可花费的指令或代码之后(例如，在一些区块链协议中的OP_RETURN语句)；或者，在所述事务的脚本中，其中所述脚本与所述事务的输出相关联。
语句7.根据前述任一项语句所述的方法，所述方法包括以下步骤：在所述通证事务链中的至少一个其他通证事务中提供相同或不同的认证元素。
语句8.一种区块链实现的方法，用于对在区块链上的通证事务中提供的至少一个通证进行核实，所述通证事务是通证事务链中的元素，其源自至少一个铸造事务，所述铸造事务由发行者或代表所述发行者用来生成所述通证；
其中，所述方法包括：
检查所述通证事务，以确定所述通证事务是否包括至少一个通证认证元素，所述至少一个通证认证元素认证所述通证是由所述发行者生成的或是代表所述发行者生成的；和/或
从所述通证事务开始遍历(traverse)所述区块链上的所述通证事务链，直至在所述链中标识一先前通证事务，其包括至少一个通证认证元素，所述至少一个通证认证元素认证所述通证是由所述发行者或代表所述发行者生成的。
语句9.根据语句8所述的方法，其中当且仅当所述通证事务不包括所述至少一个通证认证元素时，执行所述的遍历所述通证事务链的步骤。
语句10.根据语句8或9所述的方法，其中所述的遍历所述通证事务链的步骤包括：
检查所述链中的通证事务，以确定所述通证事务是否包括所述至少一个通证认证元素。
语句11.根据语句8至10所述的方法，其中所述至少一个认证元素包括：
所述至少一个发行者已知或与所述至少一个发行者相关联的秘密的证明；和/或
加密数据，优选地，其中所述加密数据是或包括与所述至少一个发行者或由所述至少一个发行者授权的一方相关联的加密密钥、签名、数字签名消息或其他加密元素。
语句12.一种区块链实现的方法，用于对在区块链(150)上的通证事务中提供的至少一个通证进行发行，所述方法包括：
在已经达到预定阈值、限制或指定值时，熔化和重新铸造所述通证。
语句13.根据语句12所述的方法，其中：
所述通证事务在所述区块链上能追踪到由至少一个发行者(702)或代表所述至少一个发行者发行的至少一个铸造事务。
语句14.根据语句12或13所述的方法，其中
熔化所述至少一个通证包括提供标识元素、标记或数据的其他部分以指示所述通证不再有效；和/或
重新铸造所述通证包括提供标识元素、标记或数据的其他部分以指示所述通证有效但采用修改形式。
语句15.根据语句14所述的方法，其中所述标识元素符合以下条件：
是标识符和/或加密数据；和/或
与所述至少一个发行者或由所述至少一个发行者授权的一方相关联；和/或
在区块链事务中、在所述通证事务中、或在所述区块链外提供的存储资源中提供。
语句16.根据语句12至15所述的方法，所述方法包括：
通过将所提供的值与所述阈值、限制或指定值进行比较，来评估是否已经达到所述预定阈值、限制或指定值。
语句17.根据语句12至16所述的方法，其中
所述预定阈值、限制或指定值由所述至少一个发行者(702)或由所述至少一个发行者授权的一方、用户(703)或核实实体(701)确定。
语句18.一种计算机设备，所述计算机设备包括：
存储器，所述存储器包括一个或多个存储器单元；以及
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据语句1至17中任一项所述的方法。
语句19.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据语句1至17中任一项所述的方法。

Claims (19)

1.一种区块链实现的方法，用于背书或证实在通证事务中提供的至少一个通证的真实性，所述通证事务是源自由至少一个发行者或代表所述至少一个发行者用来生成所述至少一个通证的至少一个铸造事务的通证事务链中的元素；
其中，所述方法包括：
在所述通证事务中提供至少一个通证认证元素，所述至少一个通证认证元素认证所述至少一个通证是由所述至少一个发行者或代表所述至少一个发行者生成的。
2.根据权利要求1所述的方法，其中通过以下方式在所述通证事务中提供所述至少一个通证认证元素：
响应于请求或指令；和/或
根据至少一个预定规则或标准。
3.根据权利要求2所述的方法，其中所述至少一个预定规则或标准指定用于标识或选择所述通证事务链内的所述事务的阈值、间隔或度量。
4.根据前述任一项权利要求所述的方法，其中所述至少一个认证元素由所述至少一个发行者或由所述至少一个发行者授权的一方在所述通证事务中提供。
5.根据前述任一项权利要求所述的方法，其中所述至少一个认证元素包括：
所述至少一个发行者已知或与所述至少一个发行者相关联的秘密的证明；和/或
加密数据，优选地，其中所述加密数据是或包括与所述至少一个发行者或由所述至少一个发行者授权的一方相关联的加密密钥、签名、数字签名消息或其他加密元素。
6.根据前述任一项权利要求所述的方法，其中通过以下方式在所述通证事务中提供所述至少一个认证元素：
在所述事务的脚本中，其中所述脚本与所述事务的输出相关联；或者
作为输出的脚本中的元数据；或者
在使所述通证事务不可花费的指令或代码之后。
7.根据前述任一项权利要求所述的方法，所述方法包括以下步骤：在所述通证事务链中的至少一个其他通证事务中提供相同或不同的认证元素。
8.一种区块链实现的方法，用于核实在区块链上的通证事务中提供的至少一个通证，所述通证事务是源自由发行者或代表所述发行者用来生成所述通证的至少一个铸造事务的通证事务链中的元素；
其中，所述方法包括：
检查所述通证事务，以确定所述通证事务是否包括至少一个通证认证元素，所述至少一个通证认证元素认证所述通证是由所述发行者或代表所述发行者生成的；和/或
从所述通证事务开始遍历所述区块链上的所述通证事务链，直至在所述链中标识先前通证事务，所述先前通证事务包括至少一个通证认证元素，所述至少一个通证认证元素认证所述通证是由所述发行者或代表所述发行者生成的。
9.根据权利要求8所述的方法，其中当且仅当所述通证事务不包括所述至少一个通证认证元素时，执行所述的遍历所述通证事务链的步骤。
10.根据权利要求8或9所述的方法，其中所述的遍历所述通证事务链的步骤包括：
检查所述链中的通证事务，以确定所述通证事务是否包括所述至少一个通证认证元素。
11.根据权利要求8至10所述的方法，其中所述至少一个认证元素包括：
所述至少一个发行者已知或与所述至少一个发行者相关联的秘密的证明；和/或
加密数据，优选地，其中所述加密数据是或包括与所述至少一个发行者或由所述至少一个发行者授权的一方相关联的加密密钥、签名、数字签名消息或其他加密元素。
12.一种区块链实现的方法，用于发行在区块链(150)上的通证事务中提供的至少一个通证，所述方法包括：
在已经达到预定阈值、限制或指定值时，熔化和重新铸造所述通证。
13.根据权利要求12所述的方法，其中：
所述通证事务在所述区块链上能追踪到由至少一个发行者(702)或代表所述至少一个发行者发行的至少一个铸造事务。
14.根据权利要求12或13所述的方法，其中
熔化所述至少一个通证包括提供标识元素、标记或数据的其他部分以指示所述通证不再有效；和/或
重新铸造所述通证包括提供标识元素、标记或数据的其他部分以指示所述通证有效但采用修改形式。
15.根据权利要求14所述的方法，其中所述标识元素符合以下条件：
是标识符和/或加密数据；和/或
与所述至少一个发行者或由所述至少一个发行者授权的一方相关联；和/或
在区块链事务中、在所述通证事务中、或在所述区块链外提供的存储资源中提供。
16.根据权利要求12至15所述的方法，所述方法包括：
通过将所提供的值与所述阈值、限制或指定值进行比较，来评估是否已经达到所述预定阈值、限制或指定值。
17.根据权利要求12至16所述的方法，其中
所述预定阈值、限制或指定值由所述至少一个发行者(702)或由所述至少一个发行者授权的一方、用户(703)或核实实体(701)确定。
18.一种计算机设备，所述计算机设备包括：
存储器，所述存储器包括一个或多个存储器单元；以及
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据权利要求1至17中任一项所述的方法。
19.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据权利要求1至17中任一项所述的方法。
CN202280040500.0A 2021-06-09 2022-05-09 用于验证区块链上的通证的计算机实现的方法和系统 Pending CN117480758A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2108255.7 2021-06-09
GB2108255.7A GB2607618A (en) 2021-06-09 2021-06-09 Computer-implemented method and system
PCT/EP2022/062395 WO2022258269A1 (en) 2021-06-09 2022-05-09 Computer-implemented method and system for verifying tokens on a blockchain

Publications (1)

Publication Number Publication Date
CN117480758A true CN117480758A (zh) 2024-01-30

Family

ID=76838758

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280040500.0A Pending CN117480758A (zh) 2021-06-09 2022-05-09 用于验证区块链上的通证的计算机实现的方法和系统

Country Status (4)

Country Link
EP (1) EP4352911A1 (zh)
CN (1) CN117480758A (zh)
GB (1) GB2607618A (zh)
WO (1) WO2022258269A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220029814A1 (en) * 2021-06-02 2022-01-27 Fujitsu Limited Non-transitory computer-readable storage medium, information processing method, and information processing apparatus
GB2622358A (en) * 2022-09-08 2024-03-20 Nchain Licensing Ag Blockchain-based token protocol

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2583767A (en) * 2019-05-10 2020-11-11 Nchain Holdings Ltd Methods and devices for public key management using a blockchain
GB202008790D0 (en) * 2020-06-10 2020-07-22 Lee Brendan Computer-implemented methods and systems

Also Published As

Publication number Publication date
GB202108255D0 (en) 2021-07-21
GB2607618A (en) 2022-12-14
WO2022258269A1 (en) 2022-12-15
EP4352911A1 (en) 2024-04-17

Similar Documents

Publication Publication Date Title
CN116210016A (zh) 共生通证系统
CN117480758A (zh) 用于验证区块链上的通证的计算机实现的方法和系统
CN115136543A (zh) 在区块链网络中使用的认证服务
US20230316272A1 (en) Divisible tokens
CN115997229A (zh) 区块链上的协议
CN116157796A (zh) 警报账户
CN116508291A (zh) 默克尔证明实体
CN116097264A (zh) 电子文件签名
CN114531941A (zh) 多标准区块链协议
CN118044151A (zh) 传播锁定脚本
CN117751550A (zh) 分层共识
CN117546167A (zh) 多级区块链
CN116671061A (zh) 节点版本控制
CN117280653A (zh) 多方区块链地址方案
US20230325825A1 (en) Methods and systems for synchronised and atomic tracking
US20230036852A1 (en) Single-use tokens
CN115699676A (zh) 自定义事务脚本
CN116547945A (zh) 默克尔证明实体
CN116745794A (zh) 区块链相关验证方法和系统
CN116057920A (zh) 连接到区块链网络
CN115428400A (zh) 撤销对网络的访问权限
CN117678191A (zh) 消息交换系统
CN116671064A (zh) 多重签名事务
CN116636180A (zh) 事务签名标志
CN117730512A (zh) 对区块链事务强制执行条件

Legal Events

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