CN117693923A - 对区块链事务强制执行条件 - Google Patents

对区块链事务强制执行条件 Download PDF

Info

Publication number
CN117693923A
CN117693923A CN202280050569.1A CN202280050569A CN117693923A CN 117693923 A CN117693923 A CN 117693923A CN 202280050569 A CN202280050569 A CN 202280050569A CN 117693923 A CN117693923 A CN 117693923A
Authority
CN
China
Prior art keywords
transaction
script
message
signature
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
CN202280050569.1A
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 CN117693923A publication Critical patent/CN117693923A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/223Payment schemes or models based on the use of peer-to-peer networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment 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/3678Payment 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4016Transaction verification involving fraud or risk level assessment in transaction processing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Algebra (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

一种计算机实现的方法,用于使用第一区块链事务对第二区块链事务强制执行条件,其中所述条件中的第一条件是,当所述第二事务的第一解锁脚本被与所述第一事务的第一锁定脚本一起执行时,将所述第二事务的表示输出到存储器,其中所述表示基于所述第二事务的多个字段和所述第一事务的第一输出,并且其中所述方法包括:生成所述第一事务,其中所述第一事务包括第一输出,其中所述第一输出包括所述第一锁定脚本,并且其中所述第一锁定脚本包括:消息子脚本;签名子脚本;公钥,其与私钥对应;和验证子脚本。

Description

对区块链事务强制执行条件
技术领域
本公开涉及一种对区块链事务强制执行(enforce)条件的方法。更具体地,第一区块链事务用于对不同的第二区块链事务强制执行一个或多个条件。
背景技术
区块链是指一种分布式数据结构,其中在分布式对等(P2P)网络(以下称为“区块链网络”)中的多个节点中的每个节点处维护区块链的副本,并且广泛公开该副本。区块链包括一系列数据区块,其中每个区块包括一个或多个事务(transaction)。除所谓的“coinbase事务”外,每个事务都指向序列中的先前事务,该序列可以跨越一个或多个区块,回到一个或多个coinbase事务。coinbase事务将在下文进一步讨论。提交给区块链网络的事务包括在新区块中。新区块的创建过程通常称为“挖掘”,该过程涉及多个节点中的每个节点争相执行“工作证明”,即,基于等待被包括在区块链的新区块中的一组定义的有序且核实有效的未决事务的表示解决加密难题。应当注意的是,区块链可以在一些节点处被修剪(prune),并且区块的发布可以通过仅发布区块头来实现。
区块链中的事务可用于以下目的中的一个或多个:传送数字资产(即,一定数量的数字通证);对虚拟化分类账或注册表中的一组条目进行排序;接收和处理时间戳条目;和/或对索引指针按时间排序。也可利用区块链实现区块链上的层级附加功能。例如,区块链协议可允许在事务中存储附加的用户数据或数据索引。能够存储在单个事务中的最大数据容量没有预先指定的限制,因此可以并入越来越复杂的数据。例如,这可用于在区块链中存储电子文档、音频或视频数据。
区块链网络的节点(通常称为“矿工”)执行分布式事务注册和验证过程,这将后续更详细地描述。总之,在该过程中,节点核实事务并将这些事务插入到区块模板中,这些事务尝试为该区块模板标识有效的工作证明解。一旦找到有效的解,新区块便会被传播到网络的其它节点,从而使得每个节点能够在区块链上记录新区块。为了将事务记录在区块链中,用户(例如,区块链客户端应用程序)将该事务发送到网络中的节点中的一个节点进行传播。接收该事务的节点可以争相寻找将核实有效的事务并入新区块的工作证明解。每个节点被配置为执行相同的节点协议,该协议将包括用于确认事务有效的一个或多个条件。无效事务将不会传播或并入到区块中。假定事务已经核实有效,从而在区块链上被接受,则该事务(包括任何用户数据)将因此在区块链网络中的每个节点上作为不可改变的公共记录进行注册和索引。
成功解决工作证明难题可创建最新区块的节点通常被奖励一个称为“coinbase事务”的新事务,该事务分发数字资产数额,即通证数量。无效事务的检测和拒绝是通过竞争节点的行动来执行的,这些竞争节点充当网络的代理并且通过激励报告和阻止不正当行为。信息的广泛发布使得用户可以连续地审计节点的性能。仅发布区块头使得参与者可以确保区块链具有持续完整性。
在“基于输出的”模型(有时称为基于UTXO的模型)中,给定事务的数据结构包括一个或多个输入和一个或多个输出。任何可花费输出包括指定数字资产数额的元素,该元素可从进行中的事务序列导出。可花费输出有时称为UTXO(“未花费事务输出”)。输出还可以包括锁定脚本,该锁定脚本指定输出的未来赎回条件。锁定脚本是限定核实和传送数字通证或资产所必需的条件的谓词。事务(除coinbase事务之外)的每个输入包括指向先前事务中的此类输出的指针(即引用),并且还可以包括解锁脚本,用于解锁指向输出的锁定脚本。因此,考虑一对事务,将其称为第一事务和第二事务(或“目标”事务)。第一事务包括指定数字资产数额的至少一个输出,并且包括定义解锁该输出的一个或多个条件的锁定脚本。第二目标事务包括至少一个输入和解锁脚本,该至少一个输入包括指向第一事务的输出的指针;该解锁脚本用于解锁第一事务的输出。
在此类模型中,当第二目标事务被发送到区块链网络以在区块链中传播和记录时,在每个节点处应用的有效性条件之一将是解锁脚本满足在第一事务的锁定脚本中定义的一个或多个条件中的所有条件。另一条件将是第一事务的输出尚未被另一早期有效事务赎回。根据这些条件中的任何一个条件发现目标事务无效的任何节点都不会传播该事务(作为有效事务,但可能注册无效事务),也不将该事务包括在要记录在区块链中的新区块中。
另一种事务模型是基于账户的模型。在这种情况下,每个事务均不通过参考过去事务序列中先前事务的UTXO来定义转移的数额,而是通过参考绝对账户余额进行定义。所有账户的当前状态由节点单独存储到区块链中,并不断更新。
发明内容
存在用于使用另一事务对区块链事务强制执行条件的现有技术。例如,可以对试图解锁较早事务的输出的未来事务的输入和/或输出强制执行条件,由此所述较早事务的所述输出至少部分负责强制执行这些条件。例如,所述条件可以包括所述未来事务的输入和/或输出包括特定数据或采用特定格式。
一种用于对未来事务强制执行条件的技术通常称为“PUSHTX”或“OP_PUSHTX”。PUSHTX是伪操作码(pseudo-opcode),即它不是区块链脚本语言(例如,Script)的单个操作码,而是操作码(或更一般的函数)集合,这些操作码一起被配置为在被执行时执行对应的操作集合。PUSHTX技术首先在国际专利申请PCT/IB2018/053335、PCT/IB2018/053337、PCT/IB2018/053339、PCT/IB2018/053336、PCT/IB2018/056430、PCT/IB2018/056432和PCT/IB2018/056431中公开。PUSHTX的核心思想是在堆栈上的数据元素上生成脚本内签名,并调用OP_CHECKSIG来验证所述签名。如果通过,则意味着由OP_CHECKSIG构建的消息与推送到所述堆栈的所述数据元素相同。因此,实现了将当前花费事务(即,对较早事务的输出进行解锁的所述未来事务)推送到所述堆栈的效果。例如,通过检查某些字段(例如,输入、输出、锁定时间等)是否包括某些数据、值、操作码、脚本等,将当前事务推送到所述堆栈使得能够强制执行条件。
本公开提供了对所述PUSHTX技术的若干优化。然而,应当理解的是,存在用于将事务推送到所述堆栈的其他类似技术,本领域技术人员将熟悉这些技术,并且本公开的实施例可能通常适用于这些技术中的任何技术,而不仅仅是PUSHTX。
根据本文公开的一个方面,提供了一种计算机实现的方法,用于使用第一区块链事务对第二区块链事务强制执行条件,其中所述条件中的第一条件是,当与所述第一事务的第一锁定脚本一起执行所述第二事务的第一解锁脚本时,将所述第二事务的表示输出到存储器,其中所述表示基于所述第二事务的多个字段和所述第一事务的第一输出,并且其中所述方法包括:生成所述第一事务,其中所述第一事务包括第一输出,其中所述第一输出包括所述第一锁定脚本,并且其中所述第一锁定脚本包括:消息子脚本,其被配置为在被执行时将表示所述第二事务的候选消息输出到存储器,其中所述候选消息基于所述第一事务和所述第二事务的多个候选字段,其中所述候选字段中的一个或多个候选字段包括在所述第二事务的所述第一解锁脚本中,并且其中所述消息子脚本被配置为:基于相应一组所述候选字段来生成所述候选消息的一个或多个相应部分,以及重新使用相应多组候选字段中的至少一个作为所述候选消息的不同相应部分;签名子脚本,其被配置为在被执行时生成签名,其中所述签名是至少所述候选消息、私钥和临时私钥的函数;与所述私钥对应的公钥;以及,验证子脚本,其被配置为在被执行时i)构建表示所述第二事务的目标消息,其中所述目标消息基于所述第二事务的多个字段和所述第一事务的所述第一输出,和ii)使用所述公钥来验证所述签名对所述目标消息有效,其中验证所述签名对所述目标消息有效,验证所述目标消息与所述候选消息匹配,从而强制执行以下条件:输出到存储器的所述候选消息是所述第二事务的所述表示。
所述第一事务的所述锁定脚本和所述第二事务的所述解锁脚本将在所述第二事务的核实期间执行。所述第一事务的所述锁定脚本包括一系列子脚本,每个子脚本被配置为执行一个或多个操作。子脚本仅仅是一组特定函数(例如,操作码)的标签,并且可选地是一组数据项(例如,公钥或公钥哈希)的标签。
消息子脚本被配置为将候选消息输出到存储器(例如,堆栈)。所述消息是“候选消息”,因此如果所述消息已经正确构建,则所述消息与另一消息(在本文中称为“目标消息”)匹配。所述候选消息基于所述第二事务的候选多个字段(例如,一个或多个输入、一个或多个输出等)(例如,所述第二事务的所有字段)和所述第一事务的候选第一输出(即,包含所述第一锁定脚本的所述输出)。这里,所述字段和所述输出是“候选项”,因此它们作为数据项包括在内(包括在所述第一事务的所述锁定脚本或所述第二事务的所述解锁脚本中)并且声称是所述第一事务和所述第二事务的正确字段。例如,所述锁定脚本的候选长度可以包括在所述第二事务的所述解锁脚本中。
签名子脚本被配置为基于所述候选消息、私钥和临时私钥来生成数字签名(例如,ECDSA签名)。在一些实施例中,所述临时私钥可以被固定为等于1。传统上,临时私钥是一个很大的数字,并且考虑到在签名生成期间通常需要多次使用所述临时私钥,将所述临时私钥固定为1可以减小所述锁定脚本的存储大小并简化签名生成过程。由于涉及所述临时私钥的任何数学运算变得微不足道,因此所述签名生成过程被简化。通过将所述私钥和所述临时私钥两者固定为等于1,可以进一步优化所述签名子脚本。这进一步减小了所述锁定脚本的所述存储大小,并降低了所述签名生成过程的计算复杂性。在附加或替代实施例中,所述临时私钥和所述私钥在所述锁定脚本中被固定为等于相同的值(不一定是值1,尽管这当然是已经提到的选项)。出于类似原因,这些实施例提供了显著的节省。如稍后将描述的,本公开的发明人已经认识到,在不损害所述第一事务或所述第二事务的安全性的情况下,可能实现这些节省。
签名验证子脚本(在一些情况下可以是单个函数,例如操作码)被配置为基于所述第一事务和所述第二事务的实际字段(例如,所述第一事务的实际第一输出、所述第二事务的实际输出等)来构建目标消息。所述签名验证子脚本还验证由所述签名子脚本生成的所述签名对所述目标消息有效。如果所述签名有效,则所述候选消息必须与所述目标消息相同。因此,输出到存储器的所述候选消息是所述目标消息,所述目标消息是所述第二事务的表示。换句话说,只有当这两个消息相同时才可能通过签名检查,因此验证所述签名会验证所述候选消息和所述目标消息是否相等。
在将所述第二事务输出到存储器(例如,所述堆栈)之后,可以进行进一步的检查,以便强制执行进一步的条件。例如,本公开的实施例可以用于构建永久强制执行锁定脚本(perpetually enforcing locking script,PELS),其中PELS是锁定脚本,所述锁定脚本对源自包含所述锁定脚本的所述输出的事务链中的所有未来事务强制执行某个或某些条件。例如,PELS可以用于迫使所述花费事务中的所述锁定脚本与其自身相同。PELS对于发送者(即,包含所述PELS的第一实例的事务的创建者)特别有用,因为它们可以确保所有未来花费事务遵循它们在所述锁定脚本中设定的规则。任何违反所述规则的行为都会使事务核实在脚本执行方面无效。有效地,所述发送者可以通过将核实工作委托给区块链节点来退出所有未来事务。
本公开认识到,可以重新使用表示所述候选消息的一部分的一组或多组候选字段,以便构建所述候选消息的不同部分。这可以显著节省空间,因为所述一组或多组候选字段只需要包括在所述第一事务的所述锁定脚本或所述第二事务的所述解锁脚本中一次,而不是多次。重新使用所述一组或多组候选字段的另一个效果是,可以对所述第二事务强制执行进一步的条件。例如,如上所述,所述候选消息基于所述第一事务的所述输出(包括强制执行锁定脚本的条件)。所述解锁脚本可以包括表示所述第一事务的所述输出的一组候选字段(例如,值和锁定脚本)。所述消息子脚本可以复制所述一组候选字段,以便构建所述第二事务的输出。如果所述签名验证通过,则所述候选消息必须与所述目标消息相同,因此所述第二事务必须包括与所述第一事务的所述输出匹配的输出。换句话说,所述第一事务的所述输出必须包括在所述第二事务的所述输出中,以便所述第二事务被视为有效。相同的技术可以适用于包括所述第二事务的相同一组候选(或实际)字段或基于所述第二事务的相同一组候选(或实际)字段生成的所述候选消息(以及目标消息)的任何部分。
附图说明
为了帮助理解本公开的实施例并示出如何实施此类实施例,现将仅通过举例的方式参考附图进行说明,其中:
图1是一种用于实现区块链的系统的示意性框图;
图2示意性地示出了可记录在区块链中的事务的一些示例;
图3A示出了客户端应用程序的示意性框图;
图3B示出了可由图3A的客户端应用程序表示的示例性用户界面的示意性模型;
图4示出了用于处理事务的一些节点软件的示意性框图;
图5示出了用于实现本公开的实施例的示例性系统的示意性框图;
图6示出了被配置为对第二事务强制执行条件的第一事务的示例;
图7示出了第二事务的示例;
图8示出了第二事务的示例,其中第一事务被优化以从候选消息的一部分生成另一部分。
具体实施方式
1.示例性系统概述
图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,该数据字段可指向先前事务。
2.基于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赎回的条件并不一定包括对签名进行验证。更通俗地说,脚本语言可用于定义任何一个或多个条件。因此,可以优选更为通用的术语“锁定脚本”和“解锁脚本”。
3.侧信道
如图1所示,爱丽丝和鲍勃的计算机设备102a、120b中的每个计算机设备上的客户端应用程序都可以包括附加通信功能。此附加功能可使爱丽丝103a建立与鲍勃103b的单独侧信道107(在任何一方或第三方的鼓动下)。侧信道107使得能够脱离区块链网络交换数据。此类通信有时称为“链下”通信。例如,这可用于在爱丽丝与鲍勃之间交换事务152,而不将该事务(尚未)注册到区块链网络106上或将其发布到链150上,直到其中一方选择将其广播到网络106上。以这种方式共享事务有时称为共享“事务模板”。事务模板可能缺少形成完整事务所需的一个或多个输入和/或输出。替代地或附加地,侧信道107可用于交换任何其它事务相关数据,例如密钥、议付数额或条款、数据内容等。
通过与区块链网络106相同的分组交换网络101可建立侧信道107。替代地或附加地,侧信道301可以经由诸如移动蜂窝网络的不同网络或者诸如无线局域网络的局域网建立,甚至经由爱丽丝和鲍勃的设备102a、102b之间的直接有线或无线链路建立。通常,在本文中任何地方所指的侧信道107可以包括经由一项或多项联网技术或通信介质的任何一条或多条链路,这些链路用于“链下”交换数据,即脱离区块链网络106交换数据。在使用多条链路的情况下,链下链路束或集合整体上可以称为侧信道107。因此,应当注意的是,如果说爱丽丝和鲍勃通过侧信道107交换某些信息或数据等,则这不一定意味着所有这些数据都必须通过完全相同的链路或甚至相同类型的网络发送。
4.客户端软件
图3A示出了用于实现本公开方案的实施例的客户端应用程序105的示例性实施方式。客户端应用程序105包括事务引擎401和用户界面(UI)层402。根据上文讨论的方案以及稍后将进一步详细讨论的内容,事务引擎401被配置为实现客户端105的基础事务相关功能,诸如制定事务152,通过侧信道301接收和/或发送事务和/或其他数据,和/或发送事务至一个或更多个节点104以通过区块链网络106传播。
该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元素,为了简洁起见,未对其进行说明。
5.节点软件
图4示出了在基于UTXO或基于输出的模型的示例中,在网络106的每个区块链节点104上运行的节点软件450的示例。应当注意的是,另一实体可以运行节点软件450,而不被分类为网络106上的节点104,即,不执行节点104所需的动作。节点软件450可以包含但不限于协议引擎451、脚本引擎452、堆栈453、应用级决策引擎454以及一个或多个区块链相关功能模块455的集合。每个节点104可以运行节点软件,该节点软件包含但不限于以下所有三个:共识模块455C(例如,工作证明)、传播模块455P和存储模块455S(例如,数据库)。协议引擎401通常被配置为识别事务152的不同字段,并根据节点协议处理此类字段。当接收到具有指向另一先前事务152i(Txm-1)的输出(例如,UTXO)的输入的事务152j(Txj)时,协议引擎451标识Txj中的解锁脚本并将其传递给脚本引擎452。协议引擎451还基于Txj的输入中的指针来标识和检索Txi。Txi可以在区块链150上发布,在这种情况下,协议引擎可以从存储在节点104处的区块链150的区块151的副本中检索Txi。或者,Txi还可以在区块链150上发布。在这种情况下,协议引擎451可以从节点104维护的未发布有序事务集154中检索Txi。无论采用哪种方式,脚本引擎451都会标识Txi的引用输出中的锁定脚本,并将其传递给脚本引擎452。
因此,脚本引擎452具有Txi的锁定脚本和来自Txj的相应输入的解锁脚本。例如,在图2中示出了事务标记的Tx0和Tx1,但是同样的事务也可以应用于任何事务对。如前所述,脚本引擎452一起运行两个脚本,这将包括根据所使用的基于堆栈的脚本语言(例如脚本)将数据放置到堆栈453上和从堆栈453检索数据。
通过同时运行脚本,脚本引擎452确定解锁脚本是否满足锁定脚本中定义的一个或多个标准,即解锁脚本是否对包括锁定脚本的输出进行解锁?脚本引擎452将该确定的结果返回给协议引擎451。如果脚本引擎452确定解锁脚本确实满足在相应的锁定脚本中指定的一个或多个标准,则返回结果“TRUE”。否则,返回结果“FALSE”。
在基于输出的模型中,来自脚本引擎452的结果“TRUE”是事务有效性的条件之一。通常,还必须满足由协议引擎451评估的一个或多个进一步协议级条件;例如,Txj的输入中所指定的数字资产的总数额不超过其输出中指向的总数额,并且Txi的指向输出尚未被另一有效事务花费。协议引擎451评估来自脚本引擎452的结果以及一个或多个协议级条件,并且只有当它们都为TRUE时,协议引擎才核实事务Txj有效。协议引擎451将事务是否有效的指示输出到应用级决策引擎454。只有在Txj确实有效的条件下,决策引擎454才可以选择同时控制共识模块455C和传播模块455P,以执行其就Txj.的相应区块链相关功能。这包括共识模块455C,向节点的相应有序事务集154添加Txj,用于并入区块151中;以及传播模块455P,将Txj转发到网络106中的另一个区块链节点104。可选地,在实施例中,应用级决策引擎454可以在触发这些函数中的一个或两个函数之前应用一个或多个附加条件。例如,决策引擎可以只选择在事务有效且预留足够事务费用的条件下发布事务。
此外,还应当注意的是,在本文中,术语“TRUE”和“FALSE”不一定限于返回仅以单个二进制数(位)形式表示的结果,尽管这确实是一种可能的实现方式。更通俗地说,“TRUE”可以指指示成功或肯定结果的任何状态,而“FALSE”可以指指示不成功或不肯定结果的任何状态。例如,在基于账户的模型中,可以对签名的隐式协议级核实和智能合约的附加肯定输出的组合来指示结果为“TRUE”(如果两个单独的结果均为TRUE,则认为总体结果为TRUE)。
6.对区块链事务强制执行条件
本公开的实施例使得一个事务能够对另一个事务强制执行(即,强加)条件。强制执行条件的事务称为“第一事务”,而被强制执行条件的事务称为“第二事务”。强制执行条件,因此除非满足条件,否则在事务核实期间,区块链节点104不会成功地核实第二事务。图5示出了用于实现所述实施例的示例性系统。如图所示,该系统包括被配置为生成第一事务的第一方、被配置为生成第二事务的第二方和区块链网络106的一个或多个区块链节点。为方便起见,第一方称为爱丽丝103a,第二方称为鲍勃103b。通常,第一方和第二方两者可以被配置为执行上述由爱丽丝103a和/或鲍勃103b执行的任何动作。该系统可以包括其他实体(未示出),例如附加用户。
如上所述,爱丽丝103a被配置为生成第一事务。第一事务包括第一输出。第一输出不一定必须在逻辑上首先出现在第一事务的输出列表中,尽管这是一种可能。第一输出包括锁定脚本,该锁定脚本称为“第一锁定脚本”。第一锁定脚本被配置为对试图解锁第一输出的任何事务强制执行一个或多个条件,在该示例性场景中,该第一输出是第二事务。这些条件中的至少一个条件是,在第二事务的执行(例如,核实)期间,第二事务的表示被输出到存储器。也就是说,第一事务(具体地,第一事务的第一锁定脚本)具有确保当第二事务的解锁脚本与第一锁定脚本一起执行时第二事务的表示被输出到存储器的效果。为方便起见,与第一事务的第一锁定脚本一起执行的第二事务的解锁脚本称为“第一解锁脚本”,该第一解锁脚本包括在第二事务的第一输入中。第一输入不一定必须在逻辑上首先出现在第二事务的输入列表中,尽管这是一种可能。
第二事务的表示可以根据事务构成其一部分的特定区块链而变化。通常,第二事务的表示基于第二事务的多个字段和第一事务的第一输出。换句话说,当前事务的表示基于当前事务和正被解锁(即,花费、分配、转移等)的先前事务的输出两者。如下面将进一步讨论的,将第二事务的表示输出到存储器允许对第二事务的部分或全部执行检查,并且因此可以通过以下方式来强制执行进一步的条件:例如,检查是否已经满足那些条件,并且如果不满足那些条件,则使事务执行失败。
第一锁定脚本包括子脚本,它们一起被配置为确保输出到存储器的表示确实是第二事务的准确表示。
这些子脚本中的第一子脚本称为“消息子脚本”。消息子脚本可以在逻辑上首先出现在第一锁定脚本中,或者可以存在其他子脚本,该其他子脚本包括在第一锁定脚本中并且出现在第一锁定脚本之前。消息子脚本被配置为将候选消息输出到存储器。候选消息基于第二事务的若干“候选字段”以及第一事务的“候选第一输出”。候选消息是“候选项”,因此在将候选消息输出到存储器时,还不知道(或者至少还没有在脚本内验证)候选消息是基于第二事务的实际字段和第一事务的实际第一输出来构建的。候选字段和候选第一输出是类似意义上的候选项,即,在脚本内验证之前,不知道它们是否正确。
这些候选字段中的至少一些候选字段包括在第二事务的第一解锁脚本中。每个候选字段可以是单独的数据项,或者数据项可以包括多于一个候选字段。候选第一输出的部分或全部(例如,分配给第一输出的值、第一输出的第一锁定脚本、第一输出的第一锁定脚本的长度)也可以包括在第一解锁脚本中。在一些实施例中,第二事务的候选字段中的一个或多个候选字段可以包括在第一事务的第一锁定脚本中。如下所述,第一锁定脚本中包括的候选消息所基于的任何候选字段必须包括在第二事务中。因此,可以强制执行以下条件,即第二事务必须包括那些候选字段。例如,第一锁定脚本可以通过包括候选消息所基于的候选锁定时间来固定第二事务的锁定时间。可选地,候选第一输出的部分(但不是全部)可以包括在第一事务的第一输出中。
消息子脚本被配置为构建候选消息的部分或全部。例如,消息子脚本可以组合(例如,串联)第一锁定脚本和/或第一解锁脚本中包括的一个或多个数据项,其中每个数据项包括一个或多个候选字段和或候选第一输出(的一部分)。更具体地,消息子脚本被配置为基于一个或多个候选字段来构建候选消息的一部分,并且重新使用这些一个或多个候选字段中的至少一些候选字段作为候选消息的不同部分。例如,一个或多个候选字段可以被复制、用于构建候选消息的一部分,然后用作消息的不同部分(或用于构建消息的不同部分)。作为示例,一组候选字段(例如,候选输出值和候选锁定脚本)可以用作表示第二事务的候选先前输出(即,第一事务的第一输出)的候选消息的一部分,并且重新用作第二事务的候选输出。在该示例中,候选消息可以包括第二事务的输出的候选哈希,并且因此消息子脚本可以对重新使用的一组候选字段进行哈希处理。消息子脚本可以被配置为重新使用单组候选字段或重新使用多组候选字段,具体取决于消息的格式。
第一锁定脚本还包括签名子脚本,该签名子脚本被配置为基于候选消息来生成签名。该签名也是基于私钥和临时私钥生成的,这两者由第一锁定脚本固定(例如,作为第一锁定脚本的一部分包括在内)。该签名可以是ECDSA签名。应当注意的是,私钥和临时私钥不一定需要包括在第一锁定脚本中才能由第一锁定脚本“固定”。例如,第一锁定脚本可以包括基于私钥和/或临时私钥的值,该值因此固定该私钥和/或临时私钥。该临时私钥可以是任意的数。例如,该临时私钥可以被固定为等于1。与通常为256位整数的传统临时私钥相比,这可以显著节省空间。此外,该私钥一般可以是任意的数,该私钥也可以被固定为等于1,从而进一步节省空间(私钥通常也为256位整数)。作为私钥和临时私钥两者被固定为等于1的替代方案,私钥和临时私钥可以被固定为彼此相等,例如,两者可以取值2或另一个小数字。由于两个密钥使用相同的值,因此简化了签名生成过程。
第一锁定脚本还包括验证子脚本。该验证子脚本被配置为构建表示第二事务的目标消息。该目标消息基于第二事务的多个字段。该目标消息基于第二事务的实际字段,即取自第二事务本身或基于第二事务本身生成。该目标消息基于与候选消息相同的第二事务的一组字段。例如,候选消息和目标消息可以基于第二事务的一个或多个输入。该目标消息还基于第一事务的实际第一输出,即取自第一事务本身。
该验证子脚本还被配置为验证已由签名子脚本生成的签名是目标消息的有效签名。使用与私钥对应的公钥来核实签名。该公钥包括在第一锁定脚本中,例如作为验证子脚本的一部分。如果(基于候选消息生成的)签名是目标消息的有效签名,则结果是候选消息和目标消息是相同的消息,因此候选消息基于第二事务的实际字段和第一事务的实际第一输出。因此,由消息子脚本输出到存储器的候选消息是第二事务的表示,并且满足以下条件,即在脚本执行期间第二事务的表示被输出到存储器。相反,如果签名验证失败,则候选消息和目标消息不同,因此不是第二事务的所需表示。
简而言之,爱丽丝103a创建具有锁定脚本的事务,由此为了解锁该锁定脚本,必须在执行期间将花费事务的表示输出到存储器(例如,堆栈)。在存储器是基于堆栈的示例中,验证子脚本可以包括OP_CHECKSIG或OP_CHECKSIGVERIFY操作码,该操作码被配置为验证签名对目标消息有效。根据签名是有效的(1)还是无效的(0),OP_CHECKSIG向堆栈输出1或0。0表示签名无效。OP_CHECKSIGVERIFY消耗输出,并且在输出为0的情况下导致执行失败。
可以看出,为了使第二事务有效,由验证子脚本构建的目标消息必须与由消息子脚本构建的候选消息匹配。因此,如果重新用于构建(或用作)候选消息的不同部分的一组候选字段是第一事务的字段,则它们也必须是第二事务的字段。这是因为目标消息基于第二事务的实际字段。因此,本公开可以用于确保第一事务的该部分(例如,锁定脚本、值、输出等)也作为第二事务的相同部分出现。换句话说,第二事务的一部分必须与第一事务的一部分相同。通常,可以迫使第二事务的一个或多个部分与第一事务的一个或多个部分相同。
如上所述,该签名可以包括ECDSA签名。本领域技术人员将熟悉ECDSA签名本身。签名的形式可以是s=k-1(z+ra)mod n,其中k是临时私钥,a是私钥,z是候选消息的哈希,n是椭圆曲线生成点G的整数阶,并且r是临时公钥模数n的x坐标。如上所述,可以将临时私钥k设置为1以优化签名生成。为了进一步优化签名生成,还可以将私钥a设置为1。
将私钥和临时私钥两者固定为1允许签名采用形式s=z+Gxmod n,其中Gx是椭圆曲线生成点G的x坐标。这具有G同时充当临时公钥和公钥的效果。第一锁定脚本(例如,签名子脚本)可以包括Gx和n的相应值,并且可以被配置为基于这些值来生成签名。
在一些示例中,签名子脚本可以被配置为使用Gx和n的值多于一次。在存储器是基于堆栈的示例中,为了节省空间,第一锁定脚本(例如,签名子脚本)可以被配置为向替代堆栈(即,不同于第一锁定脚本首先放置在其上的主堆栈之外的堆栈)输出Gx和n的值,并且在需要时从替代堆栈检索Gx和n的值,而不是多次在第一锁定脚本中包括Gx和n。
当私钥和临时私钥两者被固定为相同的值时,即使该值不是1,也可以实现节省。这是因为当签名采用ECDSA签名或等效方案的形式时,基于临时私钥和私钥的逆来计算签名。因此,将这两个密钥固定为相同的值具有取消乘法的效果,从而从该过程中去除两个数学运算。因此,简化了在脚本内计算签名。此外,由于压缩的公钥Gx与签名中的r相同,并且因此相同的值可以使用两次(例如,通过利用如下所述的ALT堆栈),因此还可以通过“a=k”实现节省。
根据区块链网络106的特定区块链协议,由签名子脚本生成的签名可能需要进一步处理,例如由验证子脚本进行验证。例如,验证子脚本可以包括要求签名采用特定格式的签名验证函数(例如,操作码)。例如,签名可能需要根据可辨别编码规则(distinguishedencoding rules,DER)来格式化。在这些示例中,第一锁定脚本可以包括DER子脚本,该子脚本被配置为将由签名子脚本生成的签名转换为DER格式的签名。DER子脚本可以是签名子脚本的一部分。验证子脚本可以被配置为使用公钥(如上所述,在一些示例中可以是生成点G)来验证DER格式的签名。
在一些示例中,签名子脚本可以包括签名标志,并且签名子脚本可以被配置为将所生成的签名与签名标志相关联(例如,级联)。签名标志在本领域中有时称为“sighash标志”。签名标志指示事务的哪些部分是通过该签名进行签名的。例如,签名标志可以指示只有某些输入和/或输出通过该签名进行签名,或者整个事务通过该签名进行签名。在这些示例中,验证子脚本被配置为基于签名标志来构建目标消息。也就是说,验证子脚本被配置为根据签名子脚本中包括的签名标志,基于第二事务的某些部分来构建目标消息。为了被签名子脚本视为有效签名,第二事务的第一解锁脚本(以及可选地,第一事务的第一锁定脚本)中包括的候选字段必须产生与目标消息匹配的候选消息。换句话说,候选消息必须基于与目标消息相同的第二事务的部分,其中这些部分由签名标志指示。
例如,签名标志可以指示目标消息基于第二事务的每个输入和每个输出。在这种情况下,签名标志(例如,sighash标志)可以是ALL。又如,签名标志可以指示目标消息仅基于包括第一解锁脚本的第二事务的输入和第二事务的对应输出。在这种情况下,签名标志(例如,sighash标志)可以是SINGLE|ANYONECANPAY。
下表提供了候选(和目标)消息的示例性格式。候选(和目标)消息可以是表中各项的级联。这些项可以基于表中的对应编号按顺序出现,例如,候选(和目标)消息可以版本号开始,并以sighash标志结束。应当注意的是,这仅仅是示例,而不旨在限制所有示例。例如,这些项可以按不同的顺序级联,或者候选(和目标)消息可以包括以下各项中的部分但不是全部项。
在该示例中,“先前”锁定脚本是指第一事务的第一锁定脚本。所有其他项取自第二事务本身或基于第二事务本身。该表还示出了项目是否可以固定在第一锁定脚本中。例如,不可能将先前(即,第一)锁定脚本固定在第一锁定脚本本身中。第一锁定脚本可以包括可能固定在锁定脚本中的上述各项中的任何一项。应当注意的是,一些数据项是第一事务或第二事务的字段(例如,“锁定时间”是第二事务的字段),而一些数据项基于第一事务或第二事务的一个或多个字段(例如,“输出的哈希”基于第二事务的输出,其中每个输出是第二事务的字段)。
如上所述,第一锁定脚本被配置为基于第二事务的第一解锁脚本中包括的候选字段中的一个或多个候选字段来构建候选消息的一部分(例如,上表中的各项中的一项)。也就是说,第一解锁脚本包括一组候选字段,并且第一锁定脚本可以对该组候选字段进行处理(其可以包括组合、级联或哈希处理等中的一个或多个)以产生候选消息的一部分,同时重新使用该组候选字段作为候选消息的不同部分。例如,第二事务的第一解锁脚本可以包括表示第二事务的候选输出的数据项作为候选字段,并且第一事务的第一锁定脚本可以使用候选输出作为上表中的第5项、第6项和第7项(表示第一事务的第一输出),并且还可以构建上表中的第9项(表示第二事务的输出的哈希)。为此,第一锁定脚本(或者更确切地说,消息子脚本)可以对第5项、第6项和第7项进行组合和哈希处理以生成第9项。这强制执行以下条件,即第一事务的第一输出与第二事务的输出完全相同。
应当注意的是,这通常适用于候选消息中可能基于相同一组字段的任何部分。例如,消息子脚本可以被配置为重新使用候选锁定脚本作为先前锁定脚本(第7项),并生成一个或多个输出的哈希(第9项),而不重新使用先前锁定脚本的候选值。这强制执行以下条件,即第二事务必须包括输出,该输出包括第一事务的第一锁定脚本,但是该输出的值可以随意选择(在区块链协议的规则内)。
7.示例性实现方式
下面将描述所述实施例的示例性实现方式。
7.1生成脚本内签名
第一事务的第一锁定脚本的一个功能是为给定消息m生成签名。以下脚本段是第一锁定脚本的一部分,并且输入数据可以在未来事务的解锁脚本中,也可以硬编码在第一锁定脚本中。
[sign]:=OP_HASH256k-1OP_MULk-1ra OP_ADD n OP_MOD r[toDER]SIGHASH_FLAGOP_SWAP OP_CAT
输入数据:m
作为锁定脚本的一部分的脚本段[sign](上面称为“签名子脚本”)可以固定临时密钥k和私钥a两者。尽管任何人都可以使用[sign]来生成有效签名,但是侧重于输入m。要求在于,对于任何给定的花费事务,只有m的一个值可以通过OP_CHECKSIG。如果私钥或公钥不是固定的,则事务不安全。细节也可以在第8节中找到。如果临时密钥k不是固定的,则任何人都可以使用不同的k来创建具有不同事务ID的有效事务,这在一些用例中是不可取的。
签名中s的值可以计算为k-1(z+ra)mod n。由于不使用签名来实现真实性,因此私钥a和临时密钥k可以随意选择并公开示出。在这种轻松的情况下,可以预先计算k-1mod n和k-1ra mod n,并将它们包括在锁定脚本中,以进一步简化签名生成。此外,可以为k和a等选择很小的值(例如,1),并且它们每次可以是相同的。应当注意的是,如果k=a=1,则s=z+Gxmod n,其中Gx是生成点G的x坐标。压缩的公钥也将为Gx。[sign]的定义可以改写为
[sign]:=OP_HASH256 Gx OP_ADD n OP_MOD Gx[toDER]SIGHASH_FLAG OP_SWAPOP_CAT
脚本段[toDER]用于将该对(r,s)转换为OP_CHECKSIG接受的标准DER格式。这迫使s在0和n/2之间的范围内,以避免事务ID的延展性。
应当注意的是,[sign]中的SIGHASH_FLAG用于指定应将花费事务的哪一部分推送到堆栈。标志ALL要求在消息m中包括所有输入和输出,而SINGLE|ANYONECANPAY要求在m中包括与该锁定脚本对应的输入及其配对的输出。
在使用输入m执行脚本段OP_DUP[sign]<PK>之后,堆栈从下到上类似于[m,Sig,PK]。调用OP_CEHCKSIGVERIFY会消耗签名和公钥,使m保留在堆栈顶部。如果验证成功,则可以确信保留在堆栈上的消息m是花费事务的准确表示。
7.2构建脚本内消息
采用序列化格式的签名消息不同于序列化事务,后者提供有关事务的所有信息,而签名消息无意地在哈希值中隐藏有关事务的一些信息,并提供有关正在花费的输出的一些信息,即其值和其锁定脚本。
消息m不能完全嵌入到锁定脚本中,因为它包含锁定脚本本身和有关未来花费事务的一些未知信息。只有这些字段中的一些字段(例如,版本、序列号或锁定时间)可以在锁定脚本中显式地强制执行。消息m整体在解锁脚本中提供,或者在脚本中使用来自解锁脚本的一些输入和来自锁定脚本的指令来构建。这里侧重于后者,因为从花费事务的角度来看,后者更具限制性。第6节中的上表捕获了消息中的所有数据字段,以及它们是否应该或可以固定在锁定脚本中。
从现在开始,表中的数据字段称为第1项、第2项、第3项等。当可以在锁定脚本中包括某项时,是在锁定脚本中还是在解锁脚本中该项提供取决于用例。一般规则是,如果数据在创建锁定脚本时可用或已知,则可以将其包括在锁定脚本中。要考虑的另一方面是事务大小和其花费事务。通过在锁定脚本与解锁脚本之间转移数据,可以在两个事务的发送者之间转移一些事务费用成本。
应当注意的是,当表达由于循环引用而不可行时,在日期字段设置粒度。例如,如果需要,可以在锁定脚本中固定部分锁定脚本甚至部分事务ID(例如,固定前两个字节并允许通过随机数字段迭代)。
虽然侧重于构建消息m,但是目标是使用m对当前事务中的不同字段强制执行值。为了强制执行哈希值后面的数据(即第9项),应将锁定脚本设计为请求原像,在脚本中对它们进行哈希处理,然后构建要在脚本中进行签名的消息。以第9项为例,要强制执行当前事务中的输出,可以通过以下方式:
[outputsRequest]:=OP_DUP OP_HASH256 OP_ROT OP_SWAP OP_CAT<item 10and11>OP_CAT
输入数据:<item 1to 8><serialised outputs in current transaction>
脚本段[outputsRequest](可以是“消息子脚本”的一部分)取第1项至第8项以及堆栈上的序列化输出来构建第9项,并与第10项和第11项级联以获取脚本内消息m。通过在[outputsRequest]之后调用[sign]<Gx>OP_CHECKSIGVERIFY并通过验证,可以确信保留在堆栈顶部的序列化输出是当前事务中输出的真实表示。
将<item 1to 7>的副本保留在堆栈上进行比较也是非常有用的。这可以通过如下所示修改脚本段来实现
[outputsRequest]:=OP_2DUP OP_HASH256 OP_SWAP<item 8>OP_CAT OP_SWAPOP_CAT<item 10and 11>OP_CAT
输入数据:<item 1to 7><serialised outputs in current transaction>
在对输入数据执行所修改的[outputsRequest]之后,可以调用[sign]<Gx>OP_CHECKSIGVERIFY来消耗消息。堆栈顶部将显示当前序列化输出,当前序列化输出后跟<item1to 7>。
如果将连续项分组在一起(如<item 1to 7>中一样),则会更简单。它们要么全部位于解锁脚本中,要么全部固定在锁定脚本中。然而,有一种更细粒度的方法可用,但是潜在的代价是脚本更复杂。
应当注意的是,当前输出的序列化格式如下
a.输出的值(8字节小端);
b.锁定脚本的长度;
c.锁定脚本;以及
d.按顺序级联序列化输出(如果存在多个输出)。
签名消息中先前输出(第5项至第7项)的序列化格式如下
a.锁定脚本的长度;
b.锁定脚本;以及
c.输出的值(8字节小端)。
在以下示例中,将先前输出与当前花费事务中的输出进行比较并迫使它们相同。这两种格式对于设计用于比较的锁定脚本非常有用。
7.3永久强制执行锁定脚本
假设爱丽丝是根认证中心(CA),而鲍勃是从属CA。爱丽丝将一些工作委托给鲍勃,这要求鲍勃在链上发布事务作为证书证明。爱丽丝不希望鲍勃将输出花费在其他任何事情上。因此,爱丽丝将强制所有后续花费事务具有固定的[P2PKH Bob]锁定脚本和固定的输出值。鲍勃可以花费输出,因为他可以生成有效签名,但是除了向自己发送相同数量之外,他不能选择任何输出。
爱丽丝构建初始事务,如图6所示。
脚本段定义如下:
[outputsRequest]:=OP_2DUP OP_HASH256 OP_SWAP<item 8>OP_CAT OP_SWAPOP_CAT<item 10and 11>OP_CAT
[sign]:=OP_HASH256 Gx OP_ADD n OP_MOD[toDER]SIGHASH_FLAG OP_SWAP OP_CAT Gcompressed
[toDER]:=[toCanonical][concatenations]
[toCanonical]:=OP_DUP n/2 OP_GREATERTHAN OP_IF n OP_SWAP OP_SUB OP_ENDIF
[concatenations]:=OP_SIZE OP_DUP<0x24>OP_ADD<0x30>OP_SWAP OP_CAT<0220||Gx>OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
锁定脚本的长度为(7+12),这是通过+(6+32+32+33)+(6+32+32)+(11)+(15+34)+(14+20)=286=0x011e得出的。
应当注意的是,第8项可以是0xFFFFFFFF,第10项可以是0x00000000,第11项可以是0x41000000。
为了花费事务,鲍勃创建花费事务,如图7所示。参考图7,输入中的Data1表示第1项至第7项,并且可以写为:
010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 TxID000000000011e{[outputsRequest][sign]OP_CHECKSIGVERIFY OP_SWAP<0x68>OP_SPLITOP_NIP OP_8OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160<H(PK_B)>OP_EQUALVERIFY OP_CHECKSIG}e803000000000000
Data2表示TxID1中的输出(值||锁定脚本长度||锁定脚本)并且可以写为:
e803000000000000011e{[outputsRequest][sign]OP_CHECKSIGVERIFY OP_SWAP<0x68>OP_SPLIT OP_NIP OP_8OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160<H(PK_B)>OP_EQUALVERIFY OP_CHECKSIG}
在TxID1核实期间要执行的完整脚本如下
<SigB><PKB><Data1><Data2>[outputsRequest][sign]OP_CHECKSIGVERIFY OP_SWAP<0x68>OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUPOP_HASH160<H(PK_B)>OP_EQUALVERIFY OP_CHECKSIG
在第一个OP_CHECKSIGVERIFY之后,在堆栈上(顶部最右侧)保留<SigB><PKB><Data1><Data2>。
TxID1的大小为verion+locktime+input+output=4+4+(36+72+33+104+287+8+287+8+4)+(8+287)=1142字节。
在给定当前设置的情况下,鲍勃可以添加自己的输入来支付事务费用。如果爱丽丝在脚本段[sign]中使用SIGHASH_SINGLE|ANYONECANPAY,则鲍勃可以添加另一输出来收集零钱。这有效地使来自爱丽丝的锁定脚本的强制执行永久化。可以认为这是爱丽丝与鲍勃之间订立的智能合约。
锁定脚本还可以考虑事务费用。在步骤3之后,堆栈上的顶部元素是来自先前输出的值。通过在步骤4中的级联之前添加<TxFee>OP_SUB,这允许鲍勃从先前输出支付事务费用。这导致输出相对于花费的值递减,这可以作为所需特征,因为这设置了鲍勃有权获得的花费总数。
7.4优化
由于Data1包含Data2,因此可以从Data1构建Data2。换句话说,假设当前输出与先前输出相同,并使用先前输出来构建消息。如果通过OP_CHECKSIG,则这两个输出必须相同。[outputsRequest]的脚本段可以改写为
[outputsRequest]:=OP_2DUP OP_CAT OP_TOALTSTACK OP_SWAP OP_CAT OP_HASH256<item 8>OP_SWAP OP_CAT OP_FROMALTSTACK OP_SWAP OP_CAT OP_CAT<item10and 11>OP_CAT
输入数据:<item 1to 4><item 5and 6><item 7>
使用这个新的[outputsRequest],可以将TxID0和TxID1中的锁定脚本更新为
[outputsRequest][sign]OP_CHECKSIGVERIFY OP_DUP OP_HASH160<H(PK_B)>OP_EQUALVERIFY OP_CHECKSIG
并将解锁脚本为<SigB><PKB><Data1><Data2><Data3>,其中Data1是第1项至第4项:
010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044TxID000000000
Data2是第5项和第6项:
011b{[outputsRequest][sign]OP_CHECKSIGVERIFY OP_SWAP<0x68>OP_SPLITOP_NIP OP_8OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160<H(PK_B)>OP_EQUALVERIFY OP_CHECKSIG}
Data3是第7项:e803000000000000。
TxID1的大小为941字节。下面给出了逐步执行,其中步骤1至步骤5来自[outputsRequest]。
通过使用ALT堆栈来存储Gx和n,可以实现进一步改进。它们中的每一个的大小为32字节。由于Gcompress是Gx并且可以从n导出,因此可以使用若干操作码从ALT堆栈中引用这些操作码。
之前:
[sign]:=OP_HASH256 Gx OP_ADD n OP_MOD[toDER]SIGHASH_FLAG OP_SWAP OP_CAT Gx
[toDER]:=[toCanonical][concatenations]
[toCanonical]:=OP_DUPn/2 OP_GREATERTHAN OP_IF n OP_SWAP OP_SUB OP_ENDIF
[concatenations]:=OP_SIZE OP_DUP<0x24>OP_ADD<0x30>OP_SWAP OP_CAT<0220||G_x>OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
之后:
[sign]:=OP_HASH256 Gx OP_DUP OP_TOALTSTACK OP_ADD n OP_DUP OP_TOALTSTACK OP_MOD[toDER]SIGHASH_FLAG OP_SWAP OP_CAT OP_FROMALTSTACK
[toDER]:=[toCanonical][concatenations]
[toCanonical]:=OP_DUP OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_2 OP_DIV OP_GREATERTHAN OP_IF OP_FROMALTSTACK OP_SWAP OP_SUB OP_ENDIF
[concatenations]:=OP_SIZE OP_DUP<0x24>OP_ADD<0x30>OP_SWAP OP_CAT<0220>OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_CAT OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
添加了15个操作码,并删除了Gx的两个实例和n的两个实例。总节省为(32×2+32×2)-15=113字节。因此,花费事务TxID1的大小可以进一步减小到828字节。
图8示出了花费事务的优化版本。
8.安全分析
断言1:如果(r,s)是相对于消息m和m′上的公钥P的有效签名,则m=m′。
证明:假设z=hash(m),并且z′=hash(m′)。
假设=zs-1mod n、u′=z′s-1mod n,并且v=rs-1mod n。
因此,得到[uG+vP]x=[u′G+vP]x=r mod n。
uG=u′G
u=u′mod n
z=z′mod n
m=m′。
断言2:公钥P必须固定在锁定脚本中。
推理:
假设P不是固定的,并且(r,s)是相对于m上的P的有效签名。
假设z′=hash(m′)。u′=z′s-1,并且v=rs-1
希望求出P′,使得u′G+vP′=R。
P′=v-1(R-u′G)
现在,(r,s)相对于m′上的P′有效。
因此,P必须固定在锁定脚本中。
断言3:k应该固定在锁定脚本中。
推理:
假设(r,s)是在锁定脚本中生成的相对于m上的P的有效签名。
假设k不是固定在锁定脚本中,而是在解锁脚本中提供。
然后,攻击者可以:
1.拦截花费事务;以及
2.在解锁脚本中将k替换为k′。
然后,在锁定脚本中生成的(r′,s′)是相对于m上的P的有效签名。
事务仍然有效,但是事务ID更改。
断言4:sighash标志应该固定在锁定脚本中。
推理:
假设(r,s)是在锁定脚本中生成的相对于m上的P的有效签名。
假设sighash标志不是固定在锁定脚本中,而是在解锁脚本中提供。
1.拦截花费事务;
2.更改sighash标志;
3.将消息m相应地更新为m′。
在某些用例中,这将使事务无效。例如,锁定脚本需要多个输入和输出,sighash标志为“All”;将标志更改为其他任何内容会使脚本执行无效。
在其他情况下,这会更改事务ID,而不会使事务无效。例如,锁定脚本仅对其花费事务的输出强制执行条件;添加或删除“ANYONECANPAY”不会使事务无效,但会更改事务ID。
9.示例性脚本
测试表明,可以实现大小为1415字节的花费事务。开销主要来自反转字节序。32字节的字符串需要124字节的操作码来反转其字节序,并且在一些示例中,需要反转锁定脚本中的两个字符串的字节序。锁定脚本同时出现在解锁脚本和输出中。因此,在本公开的实现方式中,来自字节序的总开销超过500字节。为了简单起见,在当前实现方式中,没有使用ALT堆栈来存储Gx和n。这总共节省200字节。
9.1锁定脚本1(LS1)—generateSig和checkSig
"aa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac"
输入:序列化事务消息,用于进行签名,如第6节中的表所示。
锁定脚本接收消息m;以及
1.对m执行双重SHA256以得到z;
2.反转z的字节序;
3.添加0x00以确保z不会被解释为负数;
4.调用OP_BIN2NUM以对z执行最小编码(当步骤3引入冗余时,需要注意这种情况);
5.计算s=z+Gxmod n;
6.将s转换为n-s(如果s>n/2);
7.获取s的长度;
8.反转s的字节序(32字节);
9.再反转一个字节(如果s的长度大于32);
10.计算DER签名的总长度(0x24+length of s);
11.添加DER前缀0x30;
12.级联r=Gx
13.级联s;
14.级联sighash标志“ALL”;
15.推送压缩的公钥Gx;以及
16.调用OP_CHECKSIG。
9.2锁定脚本2(LS2)—constructMsg+LS1+P2PKH
"6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac"
输入:<Sig><PK><Item 1to 4><Item 5and 6><Item 7>
锁定脚本在三个PUSHDATA操作中取一对签名和公钥以及第6节中的表中的第1项至第7项;以及
1.取先前值并计算出新的输出值(减去固定事务费用);
2.将先前锁定脚本作为新输出的新锁定脚本;
3.将新输出值和新锁定脚本级联以获取新输出;
4.对新输出执行双重SHA256以获取输出的哈希(第9项);
5.推送序列号(第8项);
6.级联以获取消息字符串(第1项至第9项);
7.推送锁定时间和sigahash标志(第10项和第11项);
8.级联以获取要签名的消息m;
9.使用OP_CHECKSIGVERIFY来调用LS1;以及
10.调用P2PKH以相对于PK检查Sig。
9.3事务0-创世事务
/>
/>
9.4事务1-花费事务
/>
/>
/>
/>
10.结论
一旦给出本文的公开内容,所公开技术的其它变体或用例对于本领域技术人员可能变得显而易见。本公开的范围不受所描述的实施例限制,而仅受随附权利要求限制。
例如,上面的一些实施例已经根据比特币网络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.一种计算机实现的方法,用于使用第一区块链事务对第二区块链事务强制执行条件,其中所述条件中的第一条件是,当所述第二事务的第一解锁脚本被与所述第一事务的第一锁定脚本一起执行时,将所述第二事务的表示输出到存储器,其中所述表示基于所述第二事务的多个字段和所述第一事务的第一输出,并且其中所述方法包括:
生成所述第一事务,其中所述第一事务包括第一输出,其中所述第一输出包括所述第一锁定脚本,并且其中所述第一锁定脚本包括:
消息子脚本,其被配置为在被执行时将表示所述第二事务的候选消息输出到存储器,其中所述候选消息基于所述第一事务和所述第二事务的多个候选字段,其中所述候选字段中的一个或多个候选字段包括在所述第二事务的所述第一解锁脚本中,并且其中所述消息子脚本被配置为:基于相应一组所述候选字段来生成所述候选消息的一个或多个相应部分,以及重新使用相应多组候选字段中的至少一个作为所述候选消息的不同相应部分;
签名子脚本,其被配置为在被执行时生成签名,其中所述签名是至少所述候选消息、私钥和临时私钥的函数;
与所述私钥对应的公钥;以及,
验证子脚本,其被配置为在被执行时i)构建表示所述第二事务的目标消息,其中所述目标消息基于所述第二事务的多个字段和所述第一事务的所述第一输出,和ii)使用所述公钥来验证所述签名对所述目标消息有效,其中验证所述签名对所述目标消息有效,验证所述目标消息与所述候选消息匹配,从而强制执行以下条件:输出到存储器的所述候选消息是所述第二事务的所述表示。
验证所述目标消息与所述候选消息匹配,并且所述候选消息是所述第二事务的所述表示是所述签名对所述目标消息有效的结果。
语句2.根据语句1所述的方法,
其中所述候选消息的所述相应部分中的一个相应部分包括所述第二事务的一个或多个输出的哈希;
其中第一相应一组所述候选字段包括a)所述第一事务的所述第一锁定脚本的相应长度,和b)所述第一事务的所述第一锁定脚本;以及,
其中所述消息子脚本被配置为在被执行时基于候选字段a)和b)来生成所述一个或多个输出的所述哈希,从而强制执行以下条件,即所述第二事务的第一输出包括所述第一事务的所述第一锁定脚本。
语句3.根据语句2所述的方法,
其中所述第一相应一组候选字段包括c)由所述第一事务的所述第一锁定脚本锁定的相应值;以及,
其中所述消息子脚本被配置为在被执行时基于候选字段a)、b)和c)来生成所述一个或多个输出的所述哈希,从而强制执行以下条件,即所述第二事务的第一输出包括所述第一事务的所述第一输出。
语句4.根据前述任一项语句所述的方法,其中所述消息子脚本被配置为将所述候选消息的所述一个或多个相应部分中的至少一个相应部分输出到所述存储器。
语句5.根据前述任一项语句所述的方法,其中所述消息子脚本被配置为在被执行时复制所述相应多组候选字段中的所述至少一个候选字段作为所述候选消息的一部分,以重新用作所述候选消息的所述不同相应部分。
语句6.根据前述任一项语句所述的方法,其中所述第一锁定脚本包括可辨别编码规则DER子脚本,其被配置为在被执行时将所述签名转换为DER格式的签名,并且其中使用所述公钥来验证所述签名对所述目标消息有效包括:使用所述公钥来验证所述DER格式的签名对所述消息有效。
语句7.根据前述任一项语句所述的方法,其中所述签名子脚本包括签名标志,所述签名标志指定所述第二事务的所述多个字段中的哪些字段将形成所述目标消息的基础,并且其中所述验证子脚本被配置为基于所述签名标志来构建所述目标消息。
语句8.根据语句7所述的方法,其中所述签名标志指定所述第二事务的每个输入和每个输出将形成所述目标消息的基础。
语句9.根据语句7所述的方法,其中所述签名标志指定a)包括所述第二事务的所述第一解锁脚本的第一输入,和b)与所述第一输入配对的所述第二的第一输出,将形成所述目标消息的基础。
语句10.根据前述任一项语句所述的方法,其中将所述候选字段中的一个或多个候选字段包括在所述第一事务的所述第一锁定脚本中。
语句11.根据语句10所述的方法,其中将以下候选字段中的一个或多个候选字段包括在所述第一事务的所述第一锁定脚本中:
-所述第二事务的版本号;
-所述第一事务的所述第一锁定脚本的长度;
-所述第一事务的所述第一锁定脚本的值;
-所述第二事务的所述第一个输入的序列号;
-所述第二事务的锁定时间;
-所述第二事务的所述第一解锁脚本的签名标志。
语句12.根据前述任一项语句所述的方法,其中表示所述第二事务的所述候选消息包括一个或多个相应数据项,所述一个或多个相应数据项基于所述第二事务的相应一组一个或多个相应候选字段。
语句13.根据语句12所述的方法,其中所述一个或多个相应数据项包括以下各项中的一项或多项:
-所述第二事务的输入序列号的哈希;
-所述第二事务的组合输出的哈希。
语句14.根据前述任一项语句所述的方法,其中所述存储器是堆栈式存储器。
语句15.根据语句14所述的方法,其中所述签名验证子脚本包括OP_CHECKSIGVERIFY操作码和OP_CHECKSIG操作码中的至少一个。
语句16.根据前述任一项语句所述的方法,所述方法包括:将所述第一事务提供给区块链网络的一个或多个节点。
语句17.根据前述任一项语句所述的方法,所述方法包括:将所述第一事务提供给一方,以供用于生成所述第二事务。
语句18.根据前述任一项语句所述的方法,其中所述临时私钥由所述第一锁定脚本固定为等于一,和/或其中所述临时私钥固定为等于所述私钥。
语句19.根据语句18所述的方法,其中所述私钥由所述第一锁定脚本固定为等于一。
语句20.根据语句18或19所述的方法,其中所述签名的形式为s=k-1(z+ra)mod n,其中k是所述临时私钥,a是所述私钥,z是所述候选消息的哈希,n是椭圆曲线生成点G的整数阶,并且r是临时公钥模数n的x坐标。
语句21.根据语句18或其任何从属语句所述的方法,其中所述签名的形式为s=z+Gxmod n,其中Gx是所述椭圆曲线生成点G的x坐标,其中是G所述临时公钥和所述公钥两者。
语句22.根据语句21所述的方法,其中所述签名子脚本包括Gx和n的相应值,并且其中所述签名是基于Gx和n的所述相应值生成的。
语句23.根据语句21和22所述的方法,其中所述堆栈式存储器包括主堆栈和替代堆栈,其中所述第一锁定脚本被配置为使用Gx和n的所述相应值多于一次,并且其中所述第一锁定脚本被配置为在被执行时将Gx和n的所述相应值输出到所述替代堆栈,并且在除了初始时间之外的每次需要Gx和n的所述相应值时,从所述替代堆栈获取Gx和n的所述相应值。
语句24.一种计算机设备,所述计算机设备包括:
存储器,所述存储器包括一个或多个存储器单元;以及,
处理装置,所述处理装置包括一个或多个处理单元,其中所述存储器存储被设置在所述处理装置上运行的代码,所述代码被配置为当在所述处理装置上运行时,执行根据语句1至23中任一项所述的方法。
语句25.一种计算机程序,所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时,执行根据语句1至23中任一项所述的方法。

Claims (25)

1.一种计算机实现的方法,用于使用第一区块链事务对第二区块链事务强制执行条件,其中所述条件中的第一条件是,当所述第二事务的第一解锁脚本被与所述第一事务的第一锁定脚本一起执行时,将所述第二事务的表示输出到存储器,其中所述表示基于所述第二事务的多个字段和所述第一事务的第一输出,并且其中所述方法包括:
生成所述第一事务,其中所述第一事务包括第一输出,其中所述第一输出包括所述第一锁定脚本,并且其中所述第一锁定脚本包括:
消息子脚本,其被配置为在被执行时将表示所述第二事务的候选消息输出到存储器,其中所述候选消息基于所述第一事务和所述第二事务的多个候选字段,其中所述候选字段中的一个或多个候选字段包括在所述第二事务的所述第一解锁脚本中,并且其中所述消息子脚本被配置为:基于相应一组所述候选字段来生成所述候选消息的一个或多个相应部分,以及重新使用相应多组候选字段中的至少一个作为所述候选消息的不同相应部分;
签名子脚本,其被配置为在被执行时生成签名,其中所述签名是至少所述候选消息、私钥和临时私钥的函数;
与所述私钥对应的公钥;以及
验证子脚本,其被配置为在被执行时i)构建表示所述第二事务的目标消息,其中所述目标消息基于所述第二事务的多个字段和所述第一事务的所述第一输出,和ii)使用所述公钥来验证所述签名对所述目标消息有效,其中验证所述签名对所述目标消息有效,验证所述目标消息与所述候选消息匹配,从而强制执行以下条件:输出到存储器的所述候选消息是所述第二事务的所述表示。
2.根据权利要求1所述的方法,
其中所述候选消息的所述相应部分中的一个相应部分包括所述第二事务的一个或多个输出的哈希;
其中第一相应一组所述候选字段包括a)所述第一事务的所述第一锁定脚本的相应长度,和b)所述第一事务的所述第一锁定脚本;以及
其中所述消息子脚本被配置为在被执行时基于候选字段a)和b)来生成所述一个或多个输出的所述哈希,从而强制执行以下条件,即所述第二事务的第一输出包括所述第一事务的所述第一锁定脚本。
3.根据权利要求2所述的方法,
其中所述第一相应一组候选字段包括c)由所述第一事务的所述第一锁定脚本锁定的相应值;以及
其中所述消息子脚本被配置为在被执行时基于候选字段a)、b)和c)来生成所述一个或多个输出的所述哈希,从而强制执行以下条件,即所述第二事务的第一输出包括所述第一事务的所述第一输出。
4.根据前述任一项权利要求所述的方法,其中所述消息子脚本被配置为将所述候选消息的所述一个或多个相应部分中的至少一个相应部分输出到所述存储器。
5.根据前述任一项权利要求所述的方法,其中所述消息子脚本被配置为在被执行时复制所述相应多组候选字段中的所述至少一个候选字段作为所述候选消息的一部分,以重新用作所述候选消息的所述不同相应部分。
6.根据前述任一项权利要求所述的方法,其中所述第一锁定脚本包括可辨别编码规则DER子脚本,其被配置为在被执行时将所述签名转换为DER格式的签名,并且其中使用所述公钥来验证所述签名对所述目标消息有效包括:使用所述公钥来验证所述DER格式的签名对所述消息有效。
7.根据前述任一项权利要求所述的方法,其中所述签名子脚本包括签名标志,所述签名标志指定所述第二事务的所述多个字段中的哪些字段将形成所述目标消息的基础,并且其中所述验证子脚本被配置为基于所述签名标志来构建所述目标消息。
8.根据权利要求7所述的方法,其中所述签名标志指定所述第二事务的每个输入和每个输出将形成所述目标消息的基础。
9.根据权利要求7所述的方法,其中所述签名标志指定a)包括所述第二事务的所述第一解锁脚本的第一输入,和b)与所述第一输入配对的所述第二的第一输出,将形成所述目标消息的基础。
10.根据前述任一项权利要求所述的方法,其中将所述候选字段中的一个或多个候选字段包括在所述第一事务的所述第一锁定脚本中。
11.根据权利要求10所述的方法,其中将以下候选字段中的一个或多个候选字段包括在所述第一事务的所述第一锁定脚本中:
-所述第二事务的版本号;
-所述第一事务的所述第一锁定脚本的长度;
-所述第一事务的所述第一锁定脚本的值;
-所述第二事务的所述第一个输入的序列号;
-所述第二事务的锁定时间;
-所述第二事务的所述第一解锁脚本的签名标志。
12.根据前述任一项权利要求所述的方法,其中表示所述第二事务的所述候选消息包括一个或多个相应数据项,所述一个或多个相应数据项基于所述第二事务的相应一组一个或多个相应候选字段。
13.根据权利要求12所述的方法,其中所述一个或多个相应数据项包括以下各项中的一项或多项:
-所述第二事务的输入序列号的哈希;
-所述第二事务的组合输出的哈希。
14.根据前述任一项权利要求所述的方法,其中所述存储器是堆栈式存储器。
15.根据权利要求14所述的方法,其中所述签名验证子脚本包括OP_CHECKSIGVERIFY操作码和OP_CHECKSIG操作码中的至少一个。
16.根据前述任一项权利要求所述的方法,所述方法包括:将所述第一事务提供给区块链网络的一个或多个节点。
17.根据前述任一项权利要求所述的方法,所述方法包括:将所述第一事务提供给一方,以供用于生成所述第二事务。
18.根据前述任一项权利要求所述的方法,其中所述临时私钥由所述第一锁定脚本固定为等于一,和/或其中所述临时私钥固定为等于所述私钥。
19.根据权利要求18所述的方法,其中所述私钥由所述第一锁定脚本固定为等于一。
20.根据权利要求18或19所述的方法,其中所述签名的形式为s=k-1(z+ra)mod n,其中k是所述临时私钥,a是所述私钥,z是所述候选消息的哈希,n是椭圆曲线生成点G的整数阶,并且r是临时公钥模数n的x坐标。
21.根据权利要求18或其任何从属权利要求所述的方法,其中所述签名的形式为s=z+Gxmod n,其中Gx是所述椭圆曲线生成点G的x坐标,其中是G所述临时公钥和所述公钥两者。
22.根据权利要求21所述的方法,其中所述签名子脚本包括Gx和n的相应值,并且其中所述签名是基于Gx和n的所述相应值生成的。
23.根据权利要求21和22所述的方法,其中所述堆栈式存储器包括主堆栈和替代堆栈,其中所述第一锁定脚本被配置为使用Gx和n的所述相应值多于一次,并且其中所述第一锁定脚本被配置为在被执行时将Gx和n的所述相应值输出到所述替代堆栈,并且在除了初始时间之外的每次需要Gx和n的所述相应值时,从所述替代堆栈获取Gx和n的所述相应值。
24.一种计算机设备,所述计算机设备包括:
存储器,所述存储器包括一个或多个存储器单元;以及
处理装置,所述处理装置包括一个或多个处理单元,其中所述存储器存储被设置在所述处理装置上运行的代码,所述代码被配置为当在所述处理装置上运行时,执行根据权利要求1至23中任一项所述的方法。
25.一种计算机程序,所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时,执行根据权利要求1至23中任一项所述的方法。
CN202280050569.1A 2021-07-19 2022-06-20 对区块链事务强制执行条件 Pending CN117693923A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2110348.6A GB2609194A (en) 2021-07-19 2021-07-19 Enforcing conditions on blockchain transactions
GB2110348.6 2021-07-19
PCT/EP2022/066649 WO2023001461A1 (en) 2021-07-19 2022-06-20 Enforcing conditions on blockchain transactions

Publications (1)

Publication Number Publication Date
CN117693923A true CN117693923A (zh) 2024-03-12

Family

ID=77443449

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280050569.1A Pending CN117693923A (zh) 2021-07-19 2022-06-20 对区块链事务强制执行条件

Country Status (6)

Country Link
EP (1) EP4374535A1 (zh)
KR (1) KR20240034793A (zh)
CN (1) CN117693923A (zh)
GB (1) GB2609194A (zh)
TW (1) TW202318444A (zh)
WO (1) WO2023001461A1 (zh)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10569088B2 (en) 2016-09-16 2020-02-25 Medtronic, Inc. Dorsal spinal column characterization with evoked potentials
US10327154B2 (en) 2016-09-16 2019-06-18 Qualcomm Incorporated Beam switching
US20190105344A1 (en) 2016-09-16 2019-04-11 Jack Kessler Oral molecular iodine composition and method
WO2018053337A1 (en) 2016-09-16 2018-03-22 Oracle International Corporation Dynamic policy injection and access visualization for threat detection
US11555221B2 (en) 2016-09-23 2023-01-17 Dna Chip Research Inc. Method for detecting mood disorders
WO2018056432A1 (ja) 2016-09-26 2018-03-29 東レ株式会社 血液検体の溶血を検出する方法及び溶血検出用チップ
JP6913956B2 (ja) 2016-09-26 2021-08-04 池田食研株式会社 L−キヌレニンの測定方法及び測定キット
CN110709872B (zh) * 2017-05-22 2024-06-07 区块链控股有限公司 解锁交易字节码的约束注入
WO2018215951A1 (en) * 2017-05-26 2018-11-29 nChain Holdings Limited Script based blockchain interaction
GB2592338A (en) * 2019-07-25 2021-09-01 Nchain Holdings Ltd Digital contracts using blockchain transactions
US20240013213A1 (en) * 2020-12-02 2024-01-11 Stanislav TROCK Blockchain

Also Published As

Publication number Publication date
TW202318444A (zh) 2023-05-01
GB202110348D0 (en) 2021-09-01
KR20240034793A (ko) 2024-03-14
GB2609194A (en) 2023-02-01
WO2023001461A1 (en) 2023-01-26
EP4374535A1 (en) 2024-05-29

Similar Documents

Publication Publication Date Title
CN115997369A (zh) 用于在区块链网络中验证数据的方法和装置
CN116508291A (zh) 默克尔证明实体
CN116210016A (zh) 共生通证系统
CN117480758A (zh) 用于验证区块链上的通证的计算机实现的方法和系统
CN116830085A (zh) 生成区块链事务以及核实区块链事务
CN117044161A (zh) 阻止敏感数据
CN117751550A (zh) 分层共识
CN117280653A (zh) 多方区块链地址方案
CN117546167A (zh) 多级区块链
CN118044151A (zh) 传播锁定脚本
CN117795516A (zh) 一种计算机实现的方法和系统
CN116671061A (zh) 节点版本控制
CN116547945A (zh) 默克尔证明实体
CN117693923A (zh) 对区块链事务强制执行条件
CN117730512A (zh) 对区块链事务强制执行条件
CN117280349A (zh) 多方区块链地址方案
CN117337436A (zh) 多方区块链地址方案
CN117678193A (zh) 区块链区块和存在证明
CN117693926A (zh) 区块链区块和存在证明
CN117652124A (zh) 区块链区块和存在证明
CN116671064A (zh) 多重签名事务
CN116636180A (zh) 事务签名标志
CN117121434A (zh) 区块链实现的散列函数
TW202329668A (zh) 證明及驗證有序事件序列之技術
CN118202614A (zh) 分片的默克尔树

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication