CN116210016A - 共生通证系统 - Google Patents

共生通证系统 Download PDF

Info

Publication number
CN116210016A
CN116210016A CN202180064305.7A CN202180064305A CN116210016A CN 116210016 A CN116210016 A CN 116210016A CN 202180064305 A CN202180064305 A CN 202180064305A CN 116210016 A CN116210016 A CN 116210016A
Authority
CN
China
Prior art keywords
transaction
certification
target
blockchain
output
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
CN202180064305.7A
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 CN116210016A publication Critical patent/CN116210016A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/3825—Use of electronic 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/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
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • 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/389—Keeping log of transactions for guaranteeing non-repudiation of a 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • 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

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

Abstract

一种核实通证事务的计算机实现的方法，其中核实实体有权访问通证铸造事务和/或通证设置事务，其中所述通证铸造事务包括加密的铸造数据，并且铸造初始数量的通证，其中所述通证设置事务包括由通证发行者认证的铸造数据，其中所述方法由核实实体执行并且包括：获得目标通证事务，所述目标通证事务包括一个或多个通证输入以及一个或多个通证输出；以及，核实所述目标通证事务，其中所述核实所述目标通证事务包括：验证所述目标通证事务的每个通证输入包括所述铸造数据，和/或验证所述目标通证事务的每个通证输入引用所述通证铸造事务或能够追溯到所述通证铸造事务的先前核实的通证事务的相应通证输出。

Description

共生通证系统
技术领域
本公开涉及一种核实通证事务的方法。通证事务是包括一个或多个通证输出的区块链事务。
背景技术
区块链是指一种分布式数据结构，其中在分布式对等(P2P)网络(以下称为“区块链网络”)中的多个节点中的每个节点处维护区块链的副本，并且广泛公开该副本。区块链包括一系列数据区块，其中每个区块包括一个或多个事务(transaction)。除所谓的“coinbase事务”外，每个事务都指向序列中的先前事务，该序列可以跨越一个或多个区块，回到一个或多个coinbase事务。coinbase事务将在下文进一步讨论。提交给区块链网络的事务包括在新区块中。新区块的创建过程通常称为“挖掘”，该过程涉及多个节点中的每个节点争相执行“工作量证明”，即，基于等待被包括在区块链的新区块中的一组定义的有序且核实有效的未决事务的表示解决加密难题。应当注意的是，区块链可以在一些节点处被修剪(prune)，并且区块的发布可以通过仅发布区块头来实现。
区块链中的事务可用于以下目的中的一个或多个：传送数字资产(即，一定数量的数字通证)；对虚拟化分类账或注册表中的一组条目进行排序；接收和处理时间戳条目；和/或对索引指针按时间排序。也可利用区块链实现区块链上的层级附加功能。例如，区块链协议可允许在事务中存储附加的用户数据或数据索引。能够存储在单个事务中的最大数据容量没有预先指定的限制，因此可以并入越来越复杂的数据。例如，这可用于在区块链中存储电子文档、音频或视频数据。
区块链网络的节点(通常称为“矿工”)执行分布式事务注册和验证过程，这将后续更详细地描述。总之，在该过程中，节点核实事务并将这些事务插入到区块模板中，这些事务尝试为该区块模板标识有效的工作量证明解。一旦找到有效的解，新区块便会被传播到网络的其它节点，从而使得每个节点能够在区块链上记录新区块。为了将事务记录在区块链中，用户(例如，区块链客户端应用程序)将该事务发送到网络中的节点中的一个节点进行传播。接收该事务的节点可以争相寻找将核实有效的事务并入新区块的工作量证明解。每个节点被配置为执行相同的节点协议，该协议将包括用于确认事务有效的一个或多个条件。无效事务将不会传播或并入到区块中。假定事务已经核实有效，从而在区块链上被接受，则该事务(包括任何用户数据)将因此在区块链网络中的每个节点上作为不可改变的公共记录进行注册和索引。
成功解决工作量证明难题可创建最新区块的节点通常被奖励一个称为“coinbase事务”的新事务，该事务分发数字资产数额，即通证数量。无效事务的检测和拒绝是通过竞争节点的行动来执行的，这些竞争节点充当网络的代理并且通过激励报告和阻止不正当行为。信息的广泛发布使得用户可以连续地审计节点的性能。仅发布区块头使得参与者可以确保区块链具有持续完整性。
在“基于输出的”模型(有时称为基于UTXO的模型)中，给定事务的数据结构包括一个或多个输入和一个或多个输出。任何可花费输出包括指定数字资产数额的元素，该元素可从进行中的事务序列导出。可花费输出有时称为UTXO(“未花费事务输出”)。输出还可以包括锁定脚本，该锁定脚本指定输出的未来赎回条件。锁定脚本是限定核实和传送数字通证或资产所必需的条件的谓词。事务(除coinbase事务之外)的每个输入包括指向先前事务中的此类输出的指针(即引用)，并且还可以包括解锁脚本，用于解锁指向输出的锁定脚本。因此，考虑一对事务，将其称为第一事务和第二事务(或“目标”事务)。第一事务包括指定数字资产数额的至少一个输出，并且包括定义解锁该输出的一个或多个条件的锁定脚本。第二目标事务包括至少一个输入和解锁脚本，该至少一个输入包括指向第一事务的输出的指针；该解锁脚本用于解锁第一事务的输出。
在此类模型中，当第二目标事务被发送到区块链网络以在区块链中传播和记录时，在每个节点处应用的有效性条件之一将是解锁脚本满足在第一事务的锁定脚本中定义的一个或多个条件中的所有条件。另一条件将是第一事务的输出尚未被另一早期有效事务赎回。根据这些条件中的任何一个条件发现目标事务无效的任何节点都不会传播该事务(作为有效事务，但可能注册无效事务)，也不将该事务包括在要记录在区块链中的新区块中。
发明内容
使用区块链发行和花费通证本身并不新奇。以前的通证是通过使用不可花费的事务输出来发行的。为了实现该系统，需要构建专用通证引擎来解释不可花费输出中的数据有效载荷，而数据本身对区块链系统没有意义。在存储方面，这对区块链节点提出了挑战，因为区块链节点可能需要将数据与可花费输出分开。
另一种方法是基于UTXO的方法，其中通证与事务输出点(outpoint)耦合。基于UTXO的通证系统与原生区块链系统更加一致，除了安全性外，还具有区块链系统的一些有利特性，例如通证的脚本内智能合约。该系统还使得通证发行者能够将其通证值与原生区块链通证值进行挂钩。
需要在区块链上实现通证系统，从而可以快速有效地核实通证(例如，不需要专门构建的通证引擎来解释通证数据)，并且不会对区块链节点的区块链存储产生负面影响(例如，不会使所述区块链因通证有效载荷数据而膨胀)。
根据本文公开的一个方面，提供了一种核实通证事务的计算机实现的方法，其中通证事务是包括一个或多个通证输出的区块链事务，每个通证输出锁定相应数量的通证，其中核实实体有权访问通证铸造事务和/或通证设置事务，其中所述通证铸造事务包括加密的铸造数据，并且铸造初始数量的通证，其中所述通证设置事务包括由通证发行者认证的铸造数据，其中所述方法由核实实体执行并且包括：获得目标通证事务，所述目标通证事务包括一个或多个通证输入以及一个或多个通证输出；以及，核实所述目标通证事务，其中所述核实所述目标通证事务包括：验证所述目标通证事务的每个通证输入包括所述铸造数据，和/或验证所述目标通证事务的每个通证输入引用所述通证铸造事务或能够追溯到所述通证铸造事务的先前核实的通证事务的相应通证输出。
应当理解的是，区块链可以视为包括多个事务链的有向无环图(DAG)。每个事务链以一个或多个coinbase事务开始。通过使一个事务具有来自不同事务链的多个输入，可以合并两个或多个事务链。通过使用所述区块链的这种解释，可以开发许多特性。本发明的实施例能够开发通证系统，本文中称为“共生通证系统commensal token system”。
共生是两个物种之间的共栖关系，其中一个物种的成员受益，而另一个物种的成员既不受益也不受伤害。本发明的共生通证系统因其防止双重花费、数据完整性等安全特性而受益于所述区块链系统，而所述区块链系统不受所述通证系统的影响。这是通过将通证值与原生区块链通证值挂钩来实现的。
通证事务是包括一个或多个“通证输出”的区块链事务。通证输出是锁定相应通证数量的区块链事务的可花费输出。换句话说，通证值与原生区块链通证(例如，比特币)挂钩。因此，区块链节点无需处理额外的通证特定工作或通证数据。此外，由于挂钩，所述区块链系统的安全性自然由所述通证系统继承。也就是说，所述通证系统受益于所述区块链系统，而不会对比特币系统造成任何额外负担。由于每个通证事务将由区块链节点根据区块链协议进行核实，为了使核实实体核实通证事务，所述核实实体只需验证正在核实的通证事务(本文中称为目标通证事务)包含可追溯到通证铸造事务的通证输入。也就是说，所述通证输入引用所述通证铸造事务的通证输出，或者所述通证输入引用先前通证事务的通证输出，所述先前通证事务是返回所述通证铸造事务的事务链的一部分。这提高了核实通证事务的效率。
在一些实施例中，所述核实实体可以构建数据结构，以进一步提高核实通证事务的效率。例如，所述核实实体可以构建类似于区块链区块的通证区块。每个通证区块包含一组有效通证事务(或一组有效通证事务的相应事务标识符)。所述核实实体只需检查所述通证输入是否引用了存储在通证区块中的有效通证事务，而不是一直追溯到所述通证铸造事务。
根据本文公开的另一方面，提供了一种核实通证事务的计算机实现的方法，其中通证事务是包括一个或多个通证输出的区块链事务，每个通证输出锁定相应数量的通证，其中所述方法由核实实体执行并且包括：获得目标通证事务，所述目标通证事务包括一个或多个通证输入以及一个或多个通证输出；以及，核实所述目标通证事务，其中核实所述目标通证事务包括：验证所述目标通证事务的每个通证输入引用存储在当前通证快照中的相应通证输出，其中所述当前通证快照包括一组通证未花费事务输出(UTXO)，其中每个通证UTXO是相应通证事务尚未花费的通证输出。
附图说明
为了帮助理解本公开的实施例并示出如何实施此类实施例，现将仅通过举例的方式参考附图进行说明，其中：
图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。如图所示，系统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被配置为验证每个通证输入是返回铸造事务的事务链的一部分。应当注意的是，通证发行者702可以发行多个铸造事务。在这种情况下，给定的通证输入可以追溯到多个铸造事务。同样地，所述目标通证事务的不同通证输入可以追溯到不同的铸造事务。
在一些示例中，所述目标通证事务必须满足附加条件才能视为有效。下面将描述这些附加条件。
一旦核实，即一旦所述第一条件和任何其他可选条件得到验证，核实实体701可以将所述目标通证事务提交给区块链网络106。也就是说，通证用户703a可以将所述目标通证事务提交给核实实体进行核实，并且在所述目标通证事务有效的条件下，核实实体701将所述目标通证事务转发给区块链网络106。
核实实体701可以获得所述目标通证事务是有效区块链事务的确认。例如，核实实体701可以获得所述目标通证事务已在区块链150上的区块151中发布的确认。核实实体701可以从区块链节点104获得默克尔证明，以验证所述目标通证事务已在区块151中发布。一旦确信所述目标通证事务是有效区块链事务，核实实体701可以将所述目标通证事务记录在有效通证事务列表中。应当注意的是，核实实体701可以在获得所述目标通证事务是有效区块链事务的确认之前，将所述目标通证事务记录在有效通证事务列表中。在所述目标通证事务不是有效区块链事务的情况下，核实实体701可以选择从所述列表中删除所述目标通证事务。
在一些示例中，在核实所述目标通证事务后，核实实体701可以在将所述目标通证事务提交给区块链网络106之前对其进行签名。例如，所述目标通证事务可能是不完整的，核实实体701可以通过包含包括所述核实实体的签名(即，链接到核实实体701拥有的公钥的签名)在内的输入来完成所述目标通证事务。该签名表示所述目标通证事务已核实。在一些示例中，所述输入可以是费用支付输入，即，支付由在区块151中发布事务的区块链节点104所收取的事务费用的输入。此类输入是“非通证输入”的示例。
所述目标通证事务可以包括一个或多个非通证输入，例如，在核实实体701根据需要添加非通证输入之前。核实实体701不需要检查所述非通证输入是否满足所述第一条件，即，所述非通证输入是返回铸造事务的事务链的一部分。然而，核实实体701确实需要区分通证输入和非通证输入，以便确定哪些输入必须满足所述第一条件。在最简单的示例中，所述输入可以基于其在所述目标事务中的索引进行区分。例如，第一输入可以定义为通证输入，第二输入可以定义为非通证输入，反之亦然。
在其他示例中，可以通过确定包含在所述非通证输入中的公钥来确定非通证输入。也就是说，核实实体701可以确定输入是否包括一组预定义公钥中的一个预定义公钥，例如一组费用支付公钥中的一个费用支付公钥。如果所述输入确实包含所述一组预定义公钥中的一个预定义公钥，则核实实体701认为该输入是非通证输入。
作为另一选项，核实实体701可以将非通证输入确定为使用特定签名标志进行签名的输入。例如，非通证输入可以定义为使用SIGHASH_SINGLE签名标志进行签名的输入。
如果所述目标通证事务确实包括一个或多个非通证输入，则所述目标通证事务必须满足第二条件，才能视为有效通证事务。核实实体701被配置为验证所述目标通证事务的一个或多个通证输出锁定的通证总量不大于所述目标通证事务的通证输入所引用的输出锁定的通证总量。换句话说，所述目标通证事务在其通证输出中分配的通证不能大于所述目标通证事务的所述通证输入所花费的通证。
所述目标通证事务可以包括一个或多个非通证输出。例如，所述非通证输出可以用于将费用支付输入和事务费用之间的差额返回给支付事务费用的实体。非通证输出可以用于其他目的。如果所述目标通证事务确实包括一个或多个非通证输出，则所述目标通证事务必须满足第三条件，才能视为有效通证事务。核实实体701被配置为验证所述目标通证事务的一个或多个通证输出锁定的通证总量不大于所述目标通证事务的通证输入所引用的输出锁定的通证总量。
为了验证所述第三条件，核实实体701需要区分通证输出和非通证输出。在最简单的情况下，输出的索引可能足以区分通证输出和非通证输出，例如，非通证输出在事务中位于第一位。作为另一选项，非通证输出可以确定为与对应的非通证输入具有相同索引的输出。或者，在非通证输入定义为使用特定签名标志进行签名的输入的情况下，非通证输出是使用比通证输出更多的签名进行签名的输出。
作为另一可选条件，核实实体401可以验证所述目标通证事务没有试图双重花费区块链事务的输出。也就是说，所述核实实体可以验证所述目标通证事务的输入(非通证输出和通证输出)所引用的输出是未花费事务输出(UTXO)。在提交给区块链网络106时，该检查将由区块链节点104执行，但核实实体701可能也想执行该检查，例如，防止向区块链网络106发送无效的区块链事务。
在一些示例中，核实实体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
示例性通证系统
现在将描述示例性通证系统。应当理解的是，通证框架的某些特性是可选的，并且可以基于本发明的实施例的特定实现方式来选择其他变型。根据示例性框架，对区块链事务有灰尘限制，通证的值与原生区块链通证挂钩，并且没有通证特定数据推入锁定脚本。
设置事务
通证发行者702可以发布设置事务。假设通证发行者702想要发行代表国家货币的通证。应当注意的是，这只是所述通证系统的许多可能的用例中的一个用例。通证发行者702可以选择在设置事务中以不可花费(例如，OP_FALSE OP_RETURN)的有效载荷发布其链上通证的规范(specification)。或者，该规范可以在网站或任何其他适当的公共记录上发布，只要该记录得到用户和公众的普遍信任。这使得通证发行者702能够向公众开放通证链，并使得公众能够证实其通证的规则。每当有争议时，包括通证发行者702在内的通证用户703可以参考该规范解决所述争议。可以将该规范视为上市公司的条款或所述通证系统的条款和条件。该规范可以参考ERC-20标准、通证化标准或通证发行者认为合适的任何定制标准。如果通证链是私有链，那么可以在其哈希值中发布该规范，以确保其完整性。
下面给出了设置事务的一个示例：
Figure BDA0004134566980000241
其中<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构建铸造事务。下面给出了一个示例：
Figure BDA0004134566980000261
该示例性事务具有由通证发行者702准备的输入，并且包含可以通过公钥PKmint验证的签名。所述铸造事务可以包括不同形式的加密数据，例如签名或加密的消息。根据TxIDsetup中的规范，该事务铸造x1个GBP通证，所述GBP通证被分配给PK1的所有者。
事务费用是铸造输出点值-1000x1，此处假设通证发行者702准备的铸造输出点具有涵盖事务费用和第一输出值的确切数量。有关事务费用的更多讨论，请参见下文。
在下列情况下，区块链事务定义为通证铸造事务：
1.事务中的所有输入均包含一个或多个签名，这些签名可以通过一个或多个铸造公钥进行验证；以及
2.区块链事务是有效区块链事务。
该定义的含义是，比特币使用铸造公钥进行染色。颜色随后在整个事务链(始于一个或多个铸造事务)中得以保留。要检查区块链事务是否是通证事务，可以通过事务链追溯到铸造事务。当系统达到一定规模时，这可能很难做到。然而，可以使用通证区块和通证UTXO快照优化该过程。
通证发行者702将能够构建多个此类事务来满足通证的需求。在这种情况下，可以铸造的通证数量受到通证发行者702拥有的比特币数量以及规范中的规则的限制。
花费事务
一旦所述铸造事务在区块链150上发布，拥有所述铸造事务的通证输出所锁定的公钥的通证用户703就可以花费通证。
考虑下面的事务，TxIDspend，其花费TxIDmint。
Figure BDA0004134566980000271
该事务没有明确引用公钥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可以在设置事务的规范中引入费用支付公钥或其集合。所述费用支付公钥可以由通证发行者拥有，并分发给通证钱包。其思路是为每个通证花费事务增加一个输入，以涵盖确切数量的事务费用。下面给出了一个示例。
第28/43页
Figure BDA0004134566980000281
应当注意的是，费用输出点不是通证输入，因为无法将其追溯到通证铸造事务。然而，由于解锁脚本中的公钥可以确定为由通证发行者702认证的有效公钥，因此费用输出点不会使通证事务无效。为了使其更加灵活，通证发行者可以允许用户注册其费用支付公钥。可以在规范的更新版本中发布认证费用支付公钥列表。
这种方法的优点是通证事务的所有输出均为通证输出。这简化了核实过程。作为通证发行者702，也可能使用费用支付输入作为对通证转移的审批。通证用户703首先构建部分事务。通证发行者702或钱包软件通过添加费用输入来完成事务，从而审批事务。这种额外的审批流程也可以防止用户意外燃烧通证。
相对于仅使用通证的方法，该方法有两个缺点。
1.必须进行几项额外的检查。
a.检查规范中是否包含费用支付公钥。
b.检查输出值是否等于(或不大于)通证输入值。这是为了确保通证用户不会通过从费用支付输入中“借用”一些比特币来夸大通证输出值。
在仅使用通证的方法中，输入仅由通证输入组成，因此所述检查与检查总输出值是否不大于总输入值相同，并且可以委托给区块链节点104。
2.费用输出点必须包含用于支付事务费用的确切数量。无法收集任何更改，因为不允许非通证输出。这需要通证用户或通证发行者在转移通证之前准备好费用输出点。
在计算方面，1b产生的开销可以忽略不计，而在防止通证意外燃烧方面，其带来的好处相当显著。通过使通证发行者702拥有的费用输出点池或服务器为每个通证事务请求提供适当的费用输出点，也可以减轻第二个缺点。
第三种是SIGHASH_SINGLE方法。该方法的目的在于解决支付事务费用缺乏灵活性的问题，同时区分通证和非通证输出。可以注意到，支付事务费用和收集一些更改只需要通证事务的一个输入和一个输出。可以使用SIGHASH_SINGLE来链接这对输入和输出，以便将所述输出与其他输出区分开。
SIGHASH_SINGLE是附加到签名的标志，用于指示使用所述签名进行签名的消息不包括所有输出(与包含所述签名的输入具有相同索引的输出除外)。应当注意的是，其他区块链可能出于相同目的使用不同的签名标志，SIGHASH_SINGLE仅用作说明性示例。这意味着，如果签名输出的索引保持不变，则可以在不使签名无效的情况下向事务添加输出或修改输出。由于不包含SIGHASH_NONE，因此无法添加或修改任何输入。
为了构建花费事务，用户向其钱包软件或支付事务费用的实体(可以是用户自己)提交通证输入，例如TxIDmint||0。然后，将未完成的事务构建为：
Figure BDA0004134566980000291
应当注意的是，签名Sigfee对TxID″spend-incomplete中所示的所有输入和第一输出进行签名。
在接收或构建所述未完成的事务时，用户703通过添加任意数量的通证输出来完成该事务，并对更新的事务进行签名。
Figure BDA0004134566980000292
在该事务中，签名Sig1对所有输入和输出进行签名。有以下关于值的等式：
事务费用＝费用输出点值-z
x1＝x2+x3
有几种方法可以区分费用支付输入和通证输入。
1.检查输入是否是通证输出。如果没有可供参考的通证输出点列表，这将非常困难。如果从费用输出点开始追溯，可能需要很长时间才能得出否定的结论。
2.将第一输入始终定义为费用支付输入。这可以作为钱包软件的一部分来实现。
3.使用SIGHASH_SINGLE将输入定义为费用支付输入。这意味着其他通证输入都不能使用SIGHASH_SINGLE。
假设可以区分费用支付输入和通证输入，确定非通证输出只是检查输出的索引是否与所述费用支付输入的索引相同。
然而，如果假设使用SIGHASH_SINGLE标记费用支付输入(方法3)，则可以直接确定非通证输出，而无需确定费用支付输入。对于每个输出，可以统计用于对该输出进行签名的签名的数量。非通证输出的签名数量最多，因为非通证输出总是至少有一个来自费用支付输入的额外签名。
由于通证输出的这一特性，在输出点级别出现了另一种类型的有向无环图。
输出点签名有向无环图(O-S DAG)
输出点签名有向无环图是一种DAG，其中
1.节点是区块链事务输出点；
2.如果第二节点是由分配(花费)第一节点所需的签名进行签名的消息的一部分，则建立从一个节点到另一节点的有向边。
大体上讲，输出点作为节点，签名作为边。O-S DAG中的所有边都在区块链事务中建立。图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。
作为区块链事务，仍然有效。作为通证事务，则视为无效。
下面给出了一对通证事务的一个示例。
Figure BDA0004134566980000311
Figure BDA0004134566980000312
第一事务是通证有效事务，因为通证输出具有与通证输入相同的值，并且费用输入和费用输出之间的差额表明事务费用为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
Timestamp 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,IxID3||1
签名 <sig><PK>
该解决方案的优点在于，作为通证客户端，可以选择仅存储最新的通证UTXO快照，因为其中包含通证客户端验证通证事务和构建后续的通证UTXO快照所需的所有信息。在接收区块链事务时，通证客户端只需要在输入中查找输出点，并检查其是否在最新的通证UTXO集中。如果所述输出点在最新的通证UTXO集中，则所述输出点是有效通证输入。应当注意的是，通证客户端不检查双重花费情况。该检查由区块链节点完成。这是基于UTXO的通证系统的主要优点之一。
缺点是，如果最新的通证UTXO快照损坏，通证UTXO客户端602b必须检索可用的最后一个通证UTXO快照，后续区块链区块或通证区块随后逐块导出最新的快照。在这种情况下，通证服务器将成为所需信息的可信来源。
为了进一步降低丢失最新UTXO快照的潜在风险，通证发行者可以选择设置多个通证服务器和几个通证UTXO客户端来维护其通证系统。如果一个通证UTXO客户端602b发生故障，其他UTXO客户端可以提供用于快速恢复的信息，同时保持通证系统不间断运行。
图6示出了通证网络的示例。简而言之，所述通证网络可以包括以下各项的部分或全部：
·通证服务器601，其存储所有通证相关事务并将其构建为区块；
·一个或多个通证轻量级客户端602a，其存储所有通证输出点及其对应值；以及
·一个或多个通证UTXO客户端602b，其存储所有未花费通证输出点及其对应值。
以上各项中的全部都能够核实通证事务并创建检查点(例如，通证区块或通证UTXO快照)，以提高效率。
比特币有效和通证无效
与许多其他通证系统一样，共生通证系统所产生的事务可能是区块链有效而通证无效的事务，这会导致通证丢失。通过在增加事务费用以完成通证事务之前引入验证步骤，可以缓解该问题。该验证步骤可以由通证钱包、通证客户端或通证服务器完成。
通证和非通证
设计通证系统的一个主要挑战是避免将通证与非通证或其他通证混合。当必须在通证事务中包含事务费用时，挑战变得更加困难。提出了一种使用公钥的方法和一种sighash-single方法来解决该问题。在这两种情况下，都会引入一种机制来确保代表通证的比特币不会与支付事务费用的比特币混在一起。
由于将通证值与比特币值挂钩，并引入这些机制来防止通证和非通证混在一起，这意味着在通证发行时，通证系统中的比特币总量便已存在。这些通证或染色比特币可以转移、分割，甚至燃烧，但绝不会与未染色比特币混在一起。
由此出现另一用例，“环保比特币”。为了促进环保挖矿，可以使用认证公钥或矿工ID为使用可再生能源挖矿的比特币染色，并称其为环保比特币。通过采用所述使用公钥的方法或所述sighash-single方法，环保比特币永远不会与非环保比特币混在一起。由于用户倾向于获得环保比特币，因此将激励更多的比特币节点转向可再生能源和铸造环保币。
可替换性
由于挂钩的性质，共生通证系统主要用于同质化通证。然而，如果只是抽象出使用公钥对比特币进行染色的想法，那么就可以创建非同质化通证。目前认为非同质化通证不在本白皮书的范围内。
可扩展性
按照设计，共生通证系统依赖于区块链系统，并且尽可能多地再利用区块链系统的工作。共生通证系统不需要检查双重花费。因此，不需要临时保存未发布通证事务(内存池)或通证UTXO集的内存。随着区块链系统的扩展，共生通证系统也随之扩展。
结论
一旦给出本文的公开内容，所公开技术的其它变体或用例对于本领域技术人员可能变得显而易见。本公开的范围不受所描述的实施例限制，而仅受随附权利要求限制。
例如，上面的一些实施例已经根据比特币网络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.一种核实通证事务的计算机实现的方法，其中通证事务是包括一个或多个通证输出的区块链事务，每个通证输出锁定相应数量的通证，其中核实实体有权访问通证铸造事务(token mint transaction)和/或通证设置事务(token setup transaction)，其中所述通证铸造事务包括加密的铸造数据，并且铸造初始数量的通证，其中所述通证设置事务包括由通证发行者认证的铸造数据，其中所述方法由所述核实实体执行并且包括：获得目标通证事务，所述目标通证事务包括一个或多个通证输入以及一个或多个通证输出；以及，核实所述目标通证事务，其中所述核实所述目标通证事务包括：验证所述目标通证事务的每个通证输入包括所述铸造数据，和/或验证所述目标通证事务的每个通证输入引用所述通证铸造事务或能够追溯到所述通证铸造事务的先前核实的通证事务的相应通证输出。
换句话说，如果所述目标通证事务的输入中包含所述铸造公钥(以及对应于所述铸造公钥的签名)，则所述目标通证事务是有效铸造事务。
加密数据是作为加密方案的一部分使用的数据，即，在加密设置中使用的数据。
语句2.根据语句1所述的方法，所述方法包括：在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务传输到区块链网络。
语句3.根据语句2所述的方法，所述方法包括：从所述区块链网络获得所述目标通证事务是有效区块链事务的确认。
在获得所述确认后，所述核实实体可以将所述目标通证事务存储在有效通证事务列表中。
语句4.根据语句3所述的方法，其中获得所述确认包括：验证所述目标通证事务已记录在区块链上。
语句5.根据前述任一项语句所述的方法，其中所述铸造数据是以下数据项中的一项：
-与所述通证发行者关联的铸造公钥；
-由所述通证发行者生成的知识证明；
-由所述通证发行者签名的对称签名消息；
-由所述通证发行者加密的消息。
语句6.根据前述任一项语句所述的方法，所述方法包括：
从第一请求实体接收用于确认所述目标通证事务是有效通证事务的请求；以及，
在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务是有效通证事务的确认传输给所述第一请求实体。
语句7.根据语句2或其任何从属语句所述的方法，所述方法包括：
在所述目标通证事务是有效通证事务的条件下、并且在将所述目标通证事务传输到所述区块链网络之前，用链接到与所述核实实体关联的核实公钥的签名对所述目标通证事务进行签名。
语句8.根据前述任一项语句所述的方法，其中所述目标通证事务包括一个或多个非通证输入(non-token input)，所述非通证输入引用先前区块链事务的相应输出，其中所述方法包括：将所述一个或多个非通证输入确定为包括预定的一组公钥中的一个或多个公钥的输入。
例如，费用支付公钥。
语句9.根据语句8所述的方法，其中核实所述目标通证事务包括：验证由所述目标通证事务的所述一个或多个通证输出锁定的通证总量不大于由所述目标通证事务的所述一个或多个通证输入引用的所述一个或多个相应通证输出锁定的数量。
10.根据前述任一项语句所述的方法，其中所述目标通证事务包括一个或多个非通证输入以及一个或多个非通证输出，并且其中核实所述目标通证事务包括：验证由所述目标通证事务的所述一个或多个通证输出锁定的通证总量不大于由所述一个或多个通证输入引用的所述通证输出锁定的数量。
语句11.根据语句8至10中任一项所述的方法，所述方法包括：将所述非通证输入确定为使用具有预定签名标志的签名进行签名的输入。
例如，sighash_single签名标志。
语句12.根据语句11所述的方法，所述方法包括：将所述非通证输出确定为使用较大数量的签名进行签名的输出。
语句13.根据前述任一项语句所述的方法，其中核实所述目标通证事务包括：验证所述先前核实的通证事务的所述通证输出是未花费事务输出。
语句14.根据语句1至12中任一项所述的方法，其中核实所述目标通证事务不包括：验证所述先前核实的通证事务的所述通证输出是未花费事务输出。
换句话说，验证所述先前核实的通证事务的所述通证输出是委托给所述区块链网络的未花费事务输出。
语句15.根据前述任一项语句所述的方法，所述方法包括：
核实所述通证铸造事务，其中核实所述通证铸造事务包括：验证所述通证铸造事务包括与所述通证发行者关联的铸造公钥。
语句16.根据前述任一项语句所述的方法，其中所述核实实体存储先前核实的通证事务的记录，并且其中验证所述目标通证事务的相应通证输入引用先前核实的通证事务的相应通证输出包括：确定所被引用的通证输出是否存在于先前核实的通证事务的所述记录中。
语句17.根据前述任一项语句所述的方法，所述方法包括：
构建当前通证区块，其中所述当前通证区块包括通证区块头以及一组有效通证事务和/或其标识符，其包含所述目标通证事务，其中所述通证区块头包括默克尔根，所述默克尔根是基于所述通证区块中的所述一组有效通证事务计算的。
语句18.根据语句17所述的方法，其中所述核实实体维护先前构建的通证区块的序列，其中所述当前通证区块的所述区块头包括所述序列中紧接在所述当前通证区块之前的通证区块的相应区块头的哈希。
除了要构建的第一通证区块外，每个通证区块都包括先前的区块头哈希，即，所述序列中该通证区块前面的通证区块的区块头哈希。
先前核实的通证事务的所述记录可以是通证区块的记录。
语句19.根据语句17或18所述的方法，所述方法包括：为所述区块链的每个新发布的区块构建相应通证区块。
相应通证区块的通证区块头包括所述相应区块链区块的相应区块高度。
语句20.根据语句17至19中任一项所述的方法，其中所述当前通证区块的所述区块头包括所述通证发行者、所述核实实体、审计实体、和/或政府实体中的一些或全部生成的相应签名。
语句21.根据语句17至20中任一项所述的方法，所述方法包括：将一个或多个通证区块和/或其相应区块头传输给第二请求实体。
语句22.根据语句6和21所述的方法，其中所述将所述确认传输给所述第一请求实体包括：传输默克尔路径，所述默克尔路径将所述目标通证事务链接到存储在所述当前通证区块的所述区块头中的所述默克尔根。
所述当前通证区块可以是最新的通证区块，也可以不是最新的通证区块。
语句23.根据前述任一项语句所述的方法，其中所述核实实体包括通证服务器。
语句24.根据语句23所述的方法，其中所述第一请求实体和/或所述第二请求实体包括通证客户端应用程序，和/或其中获得所述目标通证事务包括：从通证客户端应用程序接收所述目标通证事务。
语句25.根据语句1至13中任一项所述的方法，其中所述核实实体存储：
相应通证区块的一组通证区块头，其中每个通证区块头包括基于存储在所述相应通证区块中的一组相应有效事务计算的相应默克尔根；以及，
一组通证事务标识符；以及，
一组通证输出，其中每个通证输出包括所述一组通证事务标识符中的一个通证事务标识符的相应输出索引、相应通证数量。
语句26.根据语句25所述的方法，其中验证所述目标通证事务的每个通证输入引用先前核实的通证事务的相应通证输出包括：确定所被引用的通证输出是否存在于所述一组通证输出中。
语句27.根据语句26所述的方法，所述方法包括：
在所述目标通证事务是有效通证事务的条件下，将所述目标事务的所述事务标识符以及所述目标事务的所述一个或多个通证输出分别存储在所述一组通证事务标识符和所述一组通证输出中。
语句28.根据语句27所述的方法，所述方法包括：
构建当前通证区块，其中所述当前通证区块包括通证区块头以及包括所述目标通证事务在内的有效通证事务的一组事务标识符，其中所述通证区块头包括基于所述一组事务标识符计算的默克尔根。
语句29.根据语句28所述的方法，所述方法包括：为所述区块链的每个新发布的区块构建相应通证区块。
语句30.根据语句25至29中任一项所述的方法，其中所述核实实体包括通证客户端应用程序。
语句31.根据语句30所述的方法，其中获得所述目标通证事务包括：接收所述目标通证事务作为用户的输入。
语句32.根据语句30或31所述的方法，所述方法包括：在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务传输到通证服务器。
语句33.根据语句30至32中任一项所述的方法，所述方法包括：从所述通证服务器接收一个或多个通证区块和/或其相应区块头。
例如，响应于暂时失去与所述区块链网络的连接。
语句34.根据语句30至33中任一项所述的方法，所述方法包括：将一个或多个通证区块传输到所述通证服务器进行验证。
语句35.根据前述任一项语句所述的方法，其中所述加密的铸造数据包括已知与通证铸造关联的公共信息。
语句36.一种核实通证事务的计算机实现的方法，其中通证事务是包括一个或多个通证输出的区块链事务，每个通证输出锁定相应数量的通证，其中所述方法由核实实体执行并且包括：
获得目标通证事务，所述目标通证事务包括一个或多个通证输入以及一个或多个通证输出；以及，
核实所述目标通证事务，其中核实所述目标通证事务包括：验证所述目标通证事务的每个通证输入引用存储在当前通证快照中的相应通证输出，其中所述当前通证快照包括一组通证未花费事务输出(UTXO)，其中每个通证UTXO是相应通证事务尚未花费的通证输出。
语句37.根据语句36所述的方法，所述方法包括：构建所述当前通证快照。
语句38.根据语句37所述的方法，其中构建所述当前通证快照包括：追踪区块链上的通证UTXO。
语句39.根据语句36所述的方法，所述方法包括：从通证服务器接收所述当前通证快照。
语句40.根据语句36至39中任一项所述的方法，所述方法包括：在所述目标事务是有效通证事务的条件下，构建更新通证快照，其中所述更新通证快照包含所述目标事务的一个或多个通证输出，但不包含所述目标通证事务的所述一个或多个通证输入引用的所述一个或多个通证输出。
语句41.根据语句36至40中任一项所述的方法，所述方法包括：在所述目标事务是有效通证事务的条件下，将所述目标通证事务传输到所述通证服务器和/或区块链网络。
语句42.根据语句36至41中任一项所述的方法，所述方法包括：
从第一请求实体接收用于确认所述目标通证事务是有效通证事务的请求；以及，
在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务是有效通证事务的确认传输给所述第一请求实体。
语句43.根据语句42所述的方法，其中所述当前快照包括基于所述一组相应通证UTXO计算的默克尔根，其中所述将所述确认传输给所述第一请求包括：传输默克尔路径，所述默克尔路径将所述引用的通证输出链接到存储在所述当前快照的所述区块头中的所述默克尔根。
语句44.一种计算机设备，所述计算机设备包括：
存储器，所述存储器包括一个或多个存储器单元；以及，
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据语句1至35中任一项所述的方法。
语句45.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据语句1至35中任一项所述的方法。
语句46.一种计算机设备，所述计算机设备包括：
存储器，所述存储器包括一个或多个存储器单元；以及，
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据语句36至43中任一项所述的方法。
语句47.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据语句36至43中任一项所述的方法。
根据本文公开的另一方面，可以提供一种方法，所述方法包括所述通证服务器、所述通证UTXO客户端和所述通证轻量级客户端中的部分或全部的动作。
根据本文公开的另一方面，可以提供一种系统，所述系统包括所述通证服务器、所述通证UTXO客户端和所述通证轻量级客户端的计算机设备。

Claims (47)

1.一种核实通证事务的计算机实现的方法，其中通证事务是包括一个或多个通证输出的区块链事务，每个通证输出锁定相应数量的通证，其中核实实体有权访问通证铸造事务和/或通证设置事务，其中所述通证铸造事务包括加密的铸造数据，并且铸造初始数量的通证，其中所述通证设置事务包括由通证发行者认证的铸造数据，其中所述方法由所述核实实体执行并且包括：
获得目标通证事务，所述目标通证事务包括一个或多个通证输入以及一个或多个通证输出；以及
核实所述目标通证事务，其中所述核实所述目标通证事务包括：
验证所述目标通证事务的每个通证输入包括所述铸造数据，和/或
验证所述目标通证事务的每个通证输入引用所述通证铸造事务或能够追溯到所述通证铸造事务的先前核实的通证事务的相应通证输出。
2.根据权利要求1所述的方法，所述方法包括：在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务传输到区块链网络。
3.根据权利要求2所述的方法，所述方法包括：从所述区块链网络获得所述目标通证事务是有效区块链事务的确认。
4.根据权利要求3所述的方法，其中获得所述确认包括：验证所述目标通证事务已记录在区块链上。
5.根据前述任一项权利要求所述的方法，其中所述铸造数据是以下数据项中的一项：
-与所述通证发行者关联的铸造公钥；
-由所述通证发行者生成的知识证明；
-由所述通证发行者签名的对称签名消息；
-由所述通证发行者加密的消息。
6.根据前述任一项权利要求所述的方法，所述方法包括：
从第一请求实体接收用于确认所述目标通证事务是有效通证事务的请求；以及
在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务是有效通证事务的确认传输给所述第一请求实体。
7.根据权利要求2或其任何从属权利要求所述的方法，所述方法包括：
在所述目标通证事务是有效通证事务的条件下、并且在将所述目标通证事务传输到所述区块链网络之前，用链接到与所述核实实体关联的核实公钥的签名对所述目标通证事务进行签名。
8.根据前述任一项权利要求所述的方法，其中所述目标通证事务包括一个或多个非通证输入，所述非通证输入引用先前区块链事务的相应输出，其中所述方法包括：将所述一个或多个非通证输入确定为包括预定的一组公钥中的一个或多个公钥的输入。
9.根据权利要求8所述的方法，其中核实所述目标通证事务包括：验证由所述目标通证事务的所述一个或多个通证输出锁定的通证总量不大于由所述目标通证事务的所述一个或多个通证输入引用的所述一个或多个相应通证输出锁定的数量。
10.根据前述任一项权利要求所述的方法，其中所述目标通证事务包括一个或多个非通证输入以及一个或多个非通证输出，并且其中核实所述目标通证事务包括：验证由所述目标通证事务的所述一个或多个通证输出锁定的通证总量不大于由所述一个或多个通证输入引用的所述通证输出锁定的数量。
11.根据权利要求8至10中任一项所述的方法，所述方法包括：将所述非通证输入确定为使用具有预定签名标志的签名进行签名的输入。
12.根据权利要求11所述的方法，所述方法包括：将所述非通证输出确定为使用较大数量的签名进行签名的输出。
13.根据前述任一项权利要求所述的方法，其中核实所述目标通证事务包括：验证所述先前核实的通证事务的所述通证输出是未花费事务输出。
14.根据权利要求1至12中任一项所述的方法，其中核实所述目标通证事务不包括：验证所述先前核实的通证事务的所述通证输出是未花费事务输出。
15.根据前述任一项权利要求所述的方法，所述方法包括：
核实所述通证铸造事务，其中核实所述通证铸造事务包括：验证所述通证铸造事务包括与所述通证发行者关联的铸造公钥。
16.根据前述任一项权利要求所述的方法，其中所述核实实体存储先前核实的通证事务的记录，并且其中验证所述目标通证事务的相应通证输入引用先前核实的通证事务的相应通证输出包括：确定所被引用的通证输出是否存在于先前核实的通证事务的所述记录中。
17.根据前述任一项权利要求所述的方法，所述方法包括：
构建当前通证区块，其中所述当前通证区块包括通证区块头以及包括所述目标通证事务在内的一组有效通证事务和/或其标识符，其中所述通证区块头包括基于所述通证区块中的所述一组有效通证事务计算的默克尔根。
18.根据权利要求17所述的方法，其中所述核实实体维护先前构建的通证区块的序列，其中所述当前通证区块的所述区块头包括所述序列中紧接在所述当前通证区块之前的通证区块的相应区块头的哈希。
19.根据权利要求17或18所述的方法，所述方法包括：为所述区块链的每个新发布的区块构建相应通证区块。
20.根据权利要求17至19中任一项所述的方法，其中所述当前通证区块的所述区块头包括所述通证发行者、所述核实实体、审计实体、和/或政府实体中的一些或全部生成的相应签名。
21.根据权利要求17至20中任一项所述的方法，所述方法包括：将一个或多个通证区块和/或其相应区块头传输给第二请求实体。
22.根据权利要求6和21所述的方法，其中所述将所述确认传输给所述第一请求实体包括：传输将所述目标通证事务链接到存储在所述当前通证区块的所述区块头中的所述默克尔根的默克尔路径。
23.根据前述任一项权利要求所述的方法，其中所述核实实体包括通证服务器。
24.根据权利要求23所述的方法，其中所述第一请求实体和/或所述第二请求实体包括通证客户端应用程序，和/或其中获得所述目标通证事务包括：从通证客户端应用程序接收所述目标通证事务。
25.根据权利要求1至13中任一项所述的方法，其中所述核实实体存储：
相应通证区块的一组通证区块头，其中每个通证区块头包括基于存储在所述相应通证区块中的一组相应有效事务计算的相应默克尔根；以及
一组通证事务标识符；以及
一组通证输出，其中每个通证输出包括所述一组通证事务标识符中的一个通证事务标识符的相应输出索引、相应通证数量。
26.根据权利要求25所述的方法，其中验证所述目标通证事务的每个通证输入引用先前核实的通证事务的相应通证输出包括：确定所被引用的通证输出是否存在于所述一组通证输出中。
27.根据权利要求26所述的方法，所述方法包括：
在所述目标通证事务是有效通证事务的条件下，将所述目标事务的所述事务标识符以及所述目标事务的所述一个或多个通证输出分别存储在所述一组通证事务标识符和所述一组通证输出中。
28.根据权利要求27所述的方法，所述方法包括：
构建当前通证区块，其中所述当前通证区块包括通证区块头以及包括所述目标通证事务在内的有效通证事务的一组事务标识符，其中所述通证区块头包括基于所述一组事务标识符计算的默克尔根。
29.根据权利要求28所述的方法，所述方法包括：为所述区块链的每个新发布的区块构建相应通证区块。
30.根据权利要求25至29中任一项所述的方法，其中所述核实实体包括通证客户端应用程序。
31.根据权利要求30所述的方法，其中获得所述目标通证事务包括：接收所述目标通证事务作为用户的输入。
32.根据权利要求30或31所述的方法，所述方法包括：在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务传输到通证服务器。
33.根据权利要求30至32中任一项所述的方法，所述方法包括：从所述通证服务器接收一个或多个通证区块和/或其相应区块头。
34.根据权利要求30至33中任一项所述的方法，所述方法包括：将一个或多个通证区块传输到所述通证服务器进行验证。
35.根据前述任一项权利要求所述的方法，其中所述加密的铸造数据包括已知与通证铸造关联的公共信息。
36.一种核实通证事务的计算机实现的方法，其中通证事务是包括一个或多个通证输出的区块链事务，每个通证输出锁定相应数量的通证，其中所述方法由核实实体执行并且包括：
获得目标通证事务，所述目标通证事务包括一个或多个通证输入以及一个或多个通证输出；以及
核实所述目标通证事务，其中核实所述目标通证事务包括：验证所述目标通证事务的每个通证输入引用存储在当前通证快照中的相应通证输出，其中所述当前通证快照包括一组通证未花费事务输出UTXO，其中每个通证UTXO是相应通证事务尚未花费的通证输出。
37.根据权利要求36所述的方法，所述方法包括：构建所述当前通证快照。
38.根据权利要求37所述的方法，其中构建所述当前通证快照包括：追踪区块链上的通证UTXO。
39.根据权利要求36所述的方法，所述方法包括：从通证服务器接收所述当前通证快照。
40.根据权利要求36至39中任一项所述的方法，所述方法包括：在所述目标事务是有效通证事务的条件下，构建更新通证快照，其中所述更新通证快照包含所述目标事务的一个或多个通证输出，但不包含所述目标通证事务的所述一个或多个通证输入引用的所述一个或多个通证输出。
41.根据权利要求36至40中任一项所述的方法，所述方法包括：在所述目标事务是有效通证事务的条件下，将所述目标通证事务传输到所述通证服务器和/或区块链网络。
42.根据权利要求36至41中任一项所述的方法，所述方法包括：
从第一请求实体接收用于确认所述目标通证事务是有效通证事务的请求；以及
在所述目标通证事务是有效通证事务的条件下，将所述目标通证事务是有效通证事务的确认传输给所述第一请求实体。
43.根据权利要求42所述的方法，其中所述当前快照包括基于所述一组相应通证UTXO计算的默克尔根，其中所述将所述确认传输给所述第一请求包括：传输将所被引用的通证输出链接到存储在所述当前快照的所述区块头中的所述默克尔根的默克尔路径。
44.一种计算机设备，所述计算机设备包括：
存储器，所述存储器包括一个或多个存储器单元；以及
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据权利要求1至35中任一项所述的方法。
45.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据权利要求1至35中任一项所述的方法。
46.一种计算机设备，所述计算机设备包括：
存储器，所述存储器包括一个或多个存储器单元；以及
处理装置，所述处理装置包括一个或多个处理单元，其中所述存储器存储被设置在所述处理装置上运行的代码，所述代码被配置为当在所述处理装置上运行时，执行根据权利要求36至43中任一项所述的方法。
47.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据权利要求36至43中任一项所述的方法。
CN202180064305.7A 2020-09-21 2021-08-26 共生通证系统 Pending CN116210016A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2014838.3A GB2598945A (en) 2020-09-21 2020-09-21 Commensal token system
GB2014838.3 2020-09-21
PCT/EP2021/073621 WO2022058134A1 (en) 2020-09-21 2021-08-26 Commensal token system

Publications (1)

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

Family

ID=73196907

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180064305.7A Pending CN116210016A (zh) 2020-09-21 2021-08-26 共生通证系统

Country Status (6)

Country Link
US (1) US20230342761A1 (zh)
EP (1) EP4182868A1 (zh)
JP (1) JP2023543728A (zh)
CN (1) CN116210016A (zh)
GB (1) GB2598945A (zh)
WO (1) WO2022058134A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116401260A (zh) * 2023-06-09 2023-07-07 深圳前海环融联易信息科技服务有限公司 物品的nft信息树构建方法、装置、计算机设备及存储介质

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2622359A (en) * 2022-09-08 2024-03-20 Nchain Licensing Ag Blockchain-based token protocol
GB2622358A (en) * 2022-09-08 2024-03-20 Nchain Licensing Ag Blockchain-based token protocol
GB2625325A (en) * 2022-12-14 2024-06-19 Nchain Licensing Ag Computer-implemented method and systems

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3019275A1 (en) * 2016-04-11 2017-10-19 nChain Holdings Limited Computer-implemented methods and systems for validating tokens for blockchain-based cryptocurrencies
US20190354518A1 (en) * 2018-05-01 2019-11-21 Michael Zochowski Chain mesh network for decentralized transaction systems
JP2020030611A (ja) * 2018-08-22 2020-02-27 ブロックチェーンロック株式会社 仮想通貨流通システム
KR102037848B1 (ko) * 2019-03-27 2019-10-29 주식회사 푸시풀시스템 가상 블록체인을 갖는 듀얼 블록체인 기반의 디지털 전자기기 운용 방법

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116401260A (zh) * 2023-06-09 2023-07-07 深圳前海环融联易信息科技服务有限公司 物品的nft信息树构建方法、装置、计算机设备及存储介质
CN116401260B (zh) * 2023-06-09 2023-09-01 深圳前海环融联易信息科技服务有限公司 物品的nft信息树构建方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
US20230342761A1 (en) 2023-10-26
WO2022058134A1 (en) 2022-03-24
GB202014838D0 (en) 2020-11-04
EP4182868A1 (en) 2023-05-24
GB2598945A (en) 2022-03-23
JP2023543728A (ja) 2023-10-18

Similar Documents

Publication Publication Date Title
CN116210016A (zh) 共生通证系统
CN117480758A (zh) 用于验证区块链上的通证的计算机实现的方法和系统
CN115136543A (zh) 在区块链网络中使用的认证服务
CN115997229A (zh) 区块链上的协议
CN116508291A (zh) 默克尔证明实体
CN113994628A (zh) 通过侧信道流式传输部分数据
CN116157796A (zh) 警报账户
CN116097264A (zh) 电子文件签名
CN114531941A (zh) 多标准区块链协议
CN118044151A (zh) 传播锁定脚本
CN117751550A (zh) 分层共识
CN117546167A (zh) 多级区块链
CN117795516A (zh) 一种计算机实现的方法和系统
CN117280653A (zh) 多方区块链地址方案
CN116671061A (zh) 节点版本控制
US20230036852A1 (en) Single-use tokens
CN116745794A (zh) 区块链相关验证方法和系统
CN115699676A (zh) 自定义事务脚本
CN116547945A (zh) 默克尔证明实体
CN116057920A (zh) 连接到区块链网络
CN115053241A (zh) 一次性通证
CN116671064A (zh) 多重签名事务
CN117678191A (zh) 消息交换系统
CN116636180A (zh) 事务签名标志
CN117280349A (zh) 多方区块链地址方案

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