Message transport protocol for compact script transactions

Abstract

A computer-implemented method for transferring a blockchain transaction to a node of a blockchain network, where a compact transaction is a blockchain transaction comprising i) a CS written at least in part in a high-level (HL) scripting language, where the CS is configured to perform an operation equivalent to an Extension Script (ES) written in the LL scripting language, where the CS is configured to perform an operation equivalent to the ES; the method comprises the following steps: obtaining a compact transaction set; transmitting one or more compact transactions in the set of compact transactions to at least one other CS-enabled node; converting one or more compact transactions in the set of compact transactions into one or more corresponding extended transactions, where the converting comprises, for a given compact transaction, replacing the CS of that compact transaction with an equivalent ES; and transmitting the one or more extension transactions to at least one CS disabled node.

Description

Technical Field

[0001] The present disclosure relates to a method of transmitting a blockchain transaction to a node of a blockchain network. Background Art

[0002] Blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely disclosed. The blockchain includes a series of data blocks, each of which includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in a sequence, which can span one or more blocks back to one or more coinbase transactions. The coinbase transaction will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating a new block is generally referred to as "mining", which involves each of a plurality of nodes competing to perform "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of blocks can be achieved by publishing only the block header.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing time-stamped entries; and / or sorting index pointers by time. Blockchains can also be used to implement hierarchical additional functions on blockchains. For example, a blockchain protocol may allow additional user data or data indexes to be stored in a transaction. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in a blockchain.

[0004] The nodes of the blockchain network (commonly referred to as "miners") perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, in this process, nodes verify transactions and insert them into block templates, which attempt to identify a valid proof-of-work solution for the block template. Once a valid solution is found, the new block is propagated to other nodes of the network, so that each node can record the new block on the blockchain. In order to record a transaction in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The nodes receiving the transaction can compete to find a proof-of-work solution that incorporates the verified valid transaction into the new block. Each node is configured to execute the same node protocol, which will include one or more conditions for confirming that the transaction is valid. Invalid transactions will not be propagated or incorporated into the block. Assuming that the transaction has been verified to be valid and thus accepted on the blockchain, the transaction (including any user data) will therefore be registered and indexed as an immutable public record on each node in the blockchain network.

[0005] The node that successfully solves the proof-of-work puzzle to create the latest block is usually rewarded with a new transaction called a "coinbase transaction" that distributes the amount of digital assets, i.e. the number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, which act as agents of the network and are incentivized to report and prevent improper behavior. The widespread publication of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the continued integrity of the blockchain.

[0006] In the "output-based" model (sometimes referred to as the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies future redemption conditions for the output. A locking script is a predicate that defines the conditions necessary to verify and transfer a digital token or asset. Each input of a transaction (except for a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and may also include an unlocking script for unlocking the locking script pointing to the output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset, and includes a locking script that defines one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, the at least one input including a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0007] In such a model, when the second (target) transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but may register an invalid transaction) nor include the transaction in a new block to be recorded in the blockchain. Summary of the invention

[0008] Blockchains typically use scripting languages ​​to set locking conditions that lock specific outputs of transactions. Likewise, corresponding unlocking conditions are written in the same scripting language. Scripting languages ​​typically consist of data (e.g., public keys and digital signatures) and functions that perform operations (or operations) on the data. The scripting language may be referred to as a low-level scripting language or a native scripting language. As a specific example, the native scripting language of the Bitcoin blockchain is called Script. In Script, the function is called an "opcode," which is short for "operation code."

[0009] Transactions containing scripts are transmitted between generating parties (e.g., users or machines) to nodes of the network to verify the transactions. Depending on the use case, transactions can also be transmitted off-chain (e.g., user-to-user or machine-to-machine). In addition, transactions are also propagated throughout the blockchain network by the nodes themselves. In addition, at least some nodes are required (or at least selected) to store transactions as part of the blockchain.

[0010] As the use of blockchain technology continues to increase, there is a need to reduce the bandwidth and storage requirements for transmitting and storing transactions, respectively. This applies generally to all blockchains. Some blockchains impose limits on the size of transactions, the size of scripts within transactions, and the size of blocks. In contrast, at least one blockchain (e.g., Bitcoin SV) allows transactions to have unlimited script size and does not impose limits on block size. This enables the construction of complex locking scripts (e.g., smart contracts), which can be of considerable size. Furthermore, this also allows blockchain nodes to build and publish large blocks, which then need to be stored. Therefore, there is a greater need to save bandwidth and storage space when transmitting and storing transactions as part of this particular blockchain.

[0011] Until now, locking scripts and unlocking scripts have been written (i.e., expressed or represented) in a low-level (i.e., native) scripting language. Transactions containing these scripts are then submitted to the blockchain network and, if valid, stored on the blockchain. Now, instead of writing scripts (locking scripts or unlocking scripts) in the low-level scripting language, scripts can be written in a high-level scripting language. Like the low-level language, the high-level language consists of data and functions. However, at least some of these "high-level functions" are configured to perform the same operations as those performed by multiple "low-level functions" when executed together. In other words, one high-level function can perform the same operations that would normally require multiple low-level functions. This results in scripts written in the high-level language being more compact (i.e., reduced in size) than equivalent locking scripts written in the low-level language.

[0012] Since scripts written in the high-level language are more compact than scripts written in the native low-level language (now called "extended scripts"), scripts written in the high-level language are called "compact scripts". For example, a locking script and an unlocking script written in the high-level language are called "compact locking script" and "compact unlocking script", respectively.

[0013] It should be noted that any reference to a script being "written" in a particular programming language may be taken to mean that the script is "represented" or "expressed" in the programming language. Thus, any reference to "written" may be replaced with "represented" or "expressed" unless the context requires otherwise.

[0014] Complex locking or unlocking conditions that would normally require a large extended script (large in the sense of many low-level functions) can now be written as a smaller compact script using the high-level language. As a result, the bandwidth and storage requirements of a transaction containing a compact script are lower than those of a transaction containing an extended script.

[0015] Take the Bitcoin SV blockchain as a specific example. Since there is no limit on block size, a block can contain billions of transactions. Since transaction size is not limited, each transaction can contain millions of low-level functions (i.e., opcodes). If the size of each opcode is one byte, each of these transactions will be on the order of several megabytes. This causes bandwidth issues both when transmitting transactions to the blockchain network and when propagating transactions and blocks on the network. Nodes also face a storage burden when storing the blockchain. A single high-level function can be configured to perform the same operation as millions of low-level functions. Therefore, if each transaction is written in the high-level language, the size of the transaction is on the order of hundreds of bytes, resulting in significant savings in bandwidth and storage space. This is also critical if blockchain technology is to continue to grow.

[0016] The following is an illustrative example of how the described techniques can be used to achieve storage and bandwidth savings. A single high-level function Z can perform the same operations as three low-level functions ABC. Ten transactions transmitted to the blockchain including the function ABC will cost 30 "characters" (i.e., storage units). Using the high-level scripting language, ten transactions transmitted to the blockchain (including the equivalent function Z) will cost 10 characters. Storing the mapping Z = ABC on the chain will cost 5 characters, for a total of 15 characters. Each transaction can be extended from Z to ABC using the mapping.

[0017] The native blockchain script can be considered as an assembly language. For example, the Script language includes about 100 opcodes. Writing programs in assembly language is a hard job for developers, and the resulting code is often long and difficult to understand. High-level languages ​​are often used by developers in other technical fields because of their compactness and readability. The resulting code is then converted into a computer-readable assembly language. The present application recognizes that the same approach can be used for blockchain scripts by using a high-level scripting language. The high-level language can include some or all of the low-level functions of the native scripting language as well as new high-level functions, or the high-level language can be completely independent of such functions and include only the high-level functions.

[0018] As described below, transactions with larger scripts can now be propagated and stored in a more compact form. Furthermore, when executing a blockchain script, a node can choose the most efficient implementation to run that achieves the same results as the corresponding list of low-level functions (e.g., opcodes). Most importantly, this is achieved without changing the native blockchain protocol.

[0019] In some examples, there may be a one-to-one mapping between a single high-level (HL) function and a single low-level (LL) function. In this case, the size of the HL function may still be smaller than the size of the corresponding LL function, and thus bandwidth and storage space may still be saved.

[0020] In some embodiments, the HL language may be an intermediate-level (IL) language between a higher-level language (i.e., a second-level high-level language) and the LL language. The higher-level language is a user-facing (UF) language, i.e., a language in which a user writes a script. A user (or other type of party or entity) may generate a script in the user-facing language, which is then converted (e.g., compiled) into the intermediate language. Compared to the LL language, the intermediate language is still a high-level language. The user-facing language may be a human-readable language, making it user-friendly and enabling the user to more easily write a script equivalent to a complex script in the LL language. An analogy may be made between user-facing languages, intermediate languages, and low-level languages ​​using Java source code (user-facing), Java byte code (intermediate), and machine-readable code (low-level). Java source code is compiled into Java byte code, which is then expanded into machine-readable code. Equivalently, the user-facing language may be compiled into the intermediate language, which is then expanded into the low-level language.

[0021] Depending on the implementation, the highest level language (or more precisely, the script written in the highest level language, i.e., the user-oriented language) can be more compact than the script written in the intermediate language. The advantage of introducing the intermediate language is that it can save computational effort when expanding to the low-level language. That is, the blockchain node only needs to expand from the intermediate language to the low-level language, rather than directly from the highest level language to the low-level language. This computational effort saving can further reduce the burden on blockchain nodes.

[0022] GB2019748.9 describes an exemplary protocol for generating and propagating transactions expressed in a compact scripting language (i.e., a scripting language higher than a low-level native scripting language). GB2019748.9 provides an efficient method for encoding native opcodes into a compressed (i.e., compact) form (called a compact script). This enables complex locking scripts to be expressed in a user-friendly manner while maintaining the security of the blockchain. Blockchain nodes using the techniques described in GB2019748.9 or equivalent techniques will benefit significantly from increased efficiency in computing and significant reductions in bandwidth and storage requirements.

[0023] Of course, unless all blockchain nodes adopt such a protocol, the blockchain network will include some nodes that are configured to process transactions including compact scripts and some nodes that are not configured to process such transactions. Moreover, even if all nodes do eventually adopt the protocol, there will be at least an initial period during which some but not all nodes have adopted the protocol and configured their systems to process compact script transactions.

[0024] A transaction with at least one script (i.e., locking or unlocking) expressed in a compact script will be referred to as a compact transaction hereinafter. In some places, it may also be referred to as a transaction in the form of a metascript (MS). A transaction that includes a script expressed in an opcode (or other low-level function) is called an extended transaction. It is also referred to as a transaction in canonical form. It should be noted that all compact transactions will have a corresponding canonical form, while canonical transactions may not necessarily have a compact form. A blockchain node with a compact script (CS) enabled is a node that can process compact transactions (e.g., verifying whether a compact transaction is valid). It is also referred to as an MS node. In contrast, a node with a compact script disabled is a node that cannot process compact transactions. It is also referred to as a canonical node.

[0025] Compact transactions may be rejected (e.g., verified as invalid) by nodes with CS disabled, because these nodes cannot process compact transactions and therefore cannot verify that compact transactions are valid. This causes problems because transactions that propagate on the blockchain network and are published in blocks must be verified as valid by other nodes. This is a basic requirement for most blockchains. Therefore, if nodes with CS disabled cannot verify that transactions are valid, the entire network will be affected. Therefore, there is a need to solve this problem.

[0026] According to one aspect disclosed herein, there is provided a computer-implemented method of transmitting a blockchain transaction to a node of a blockchain network, wherein the blockchain network includes one or more compact script (CS) enabled nodes and one or more CS disabled nodes, wherein each CS-enabled node is configured to process a compact transaction, and each CS-disabled node is not configured to process a compact transaction, wherein a compact transaction is a blockchain transaction, the blockchain transaction comprising: i) a CS written at least in part in a high-level (HL) scripting language, and which includes one or more HL functions; and / or ii) an input, the input referencing an output, the output including the CS, wherein when executed, each HL function is configured to perform the same operation as that performed by a low-level (HL) scripting language. The method is configured to perform an operation equivalent to an operation performed by one or more LL functions of a CS-based scripting language, wherein the CS is configured to perform an operation equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a first CS-enabled node and comprises: obtaining a compact transaction set (also referred to as a group of compact transactions); transmitting one or more compact transactions in the compact transaction set to at least one other CS-enabled node; converting one or more compact transactions in the compact transaction set to one or more corresponding extended transactions, wherein for a given compact transaction, the conversion comprises replacing the CS of the compact transaction with an equivalent ES; and transmitting the one or more extended transactions to at least one CS-disabled node.

[0027] According to one aspect disclosed herein, there is provided a computer-implemented method of receiving a blockchain transaction from a node of a blockchain network, wherein the blockchain network includes one or more compact script (CS) enabled nodes and one or more CS disabled nodes, wherein each CS enabled node is configured to process a compact transaction, and each CS disabled node is not configured to process a compact transaction, wherein a compact transaction is i) a blockchain transaction that includes a CS written at least in part in a high level (HL) scripting language and that includes one or more HL functions; and / or ii) an input that references an output of the CS, wherein when executed, each HL function is configured to perform the same operation as that performed by a low level (HL) scripting language. The method is configured to perform operations equivalent to operations performed by one or more LL functions of a CS-enabled node, wherein the CS is configured to perform operations equivalent to operations performed by an extended script (ES) written in the LL scripting language, and wherein the method is performed by a CS-disabled node and includes: obtaining a compact transaction or an indication, the indication being used to indicate that a compact transaction is a compact transaction; determining, based on the obtained compact transaction or the indication thereof, that the CS-disabled node cannot process the compact transaction; transmitting a request for an extended transaction corresponding to the compact transaction to a CS-enabled node; and receiving the extended transaction from the CS-enabled node, wherein the extended transaction includes an ES, the ES being equivalent to the CS of the compact transaction.

[0028] For example, a CS-enabled node obtains the compact transactions from an end user. The CS-enabled node sends some or all of the compact transactions directly to other CS-enabled nodes, i.e., in a compact form of the compact transactions. This saves bandwidth compared to transmitting the compact transactions in a corresponding extended form of the compact transactions.

[0029] The CS-enabled node also converts some or all of the compact transactions into their extended forms. That is, the compact script of a given compact transaction is replaced with the corresponding extended script (i.e., a script written entirely in the low-level scripting language). The extended transaction is then sent to the CS-disabled node, thereby allowing the CS-disabled node to process the transaction according to the conventional processing protocol (e.g., verify that the transaction is valid).

[0030] In some embodiments, the CS-enabled node may send the compact transaction and / or the extended transaction (i.e., automatically) to the appropriate node after receiving the compact transaction (e.g., from a user or other CS-enabled node). Alternatively, the compact transaction and / or the extended transaction may be sent to the appropriate node upon request. This reduces the number of transactions sent through the blockchain network because the transactions are only sent to the nodes that need them, for example, because these nodes have not yet seen the transaction on the network or received the transaction from other nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0032] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0033] Figure 2 Some examples of transactions that may be recorded in a blockchain are schematically shown;

[0034] Figure 3A A schematic block diagram of a client application is shown;

[0035] Figure 3B It shows that Figure 3A a schematic model of an exemplary user interface represented by a client application of

[0036] Figure 4 A schematic block diagram of some node software for processing transactions is shown;

[0037] Figure 5 is a schematic block diagram of an exemplary system for transmitting blockchain transactions;

[0038] Figure 6 is a flow chart illustrating an exemplary method for sending and verifying a blockchain transaction;

[0039] Figure 7 is a flow chart illustrating another exemplary method for sending and verifying a blockchain transaction;

[0040] Figure 8 Another exemplary method for sending and verifying a blockchain transaction is schematically illustrated;

[0041] Fig. 9 Schematically illustrates an exemplary hierarchical structure of a scripting language;

[0042] Fig.10 schematically illustrates a compact script enabled node receiving a transaction;

[0043] Fig.11 schematically illustrates an exemplary script execution of a compact spend transaction;

[0044] Fig.12 Schematically illustrating the compatibility between a compact script enabled node and a compact script disabled node;

[0045] Fig.13 An exemplary system according to some embodiments of the invention is schematically illustrated. DETAILED DESCRIPTION

[0046] 1. Exemplary System Overview

[0047] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switched network 101, typically a wide area internet such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0048] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special processors and / or field programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0049] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output that is cryptographically locked to a user 103 (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0050] Each block 151 also includes a block pointer 155, which points to a previously created block 151 in the blockchain to define the order of blocks 151. Each transaction 152 (except for the coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can branch). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transaction.

[0051] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, so that transactions 152 are propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. Ordered pools 154 are often referred to as "memory pools". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid, and for which the node 104 is forced to not accept any other transaction that attempts to spend the same output.

[0052] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, the previous transaction 152i does not have to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in the logical sequence linked by the pointer, and not necessarily the creation time or sending time in the time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of orphan transactions below). The previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0053] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0054] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i assigned by the new transaction, wherein the condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0055] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether it is validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for the transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not been redeemed by another transaction. Similarly, if invalid, the transaction 152j will not be propagated (unless marked as invalid and propagated for reminder) or recorded in the blockchain 150. This prevents double spending, that is, the transaction processor allocates the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at any time.

[0056] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0057] The first blockchain node 104 that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the first node 104's intention to follow the blockchain protocol. These rules include not accepting a transaction as valid if it allocates the same output as a previously verified valid transaction, otherwise it is called a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0058] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool of unpublished transactions 154. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 104. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0059] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction", but may also be called a "starting transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that constructs the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is often called a "transaction fee" and is discussed below.

[0060] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may take the form of a user terminal or a group of user terminals networked together.

[0061] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role according to the blockchain node protocol and process transactions 152. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0062] Computer devices 102 of each of the parties 103 acting as consuming users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without acting as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from the blockchain node 104).

[0063] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced with "first party" and "second party" respectively.

[0064] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0065] The client application 105 may initially be provided to the computer device 102 of any given party 103 via a suitable computer-readable storage medium downloaded from a server, for example, or via a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable disk drive, floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0066] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

[0067] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and rather, any client function described herein may be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0068] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This can enable a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions to which the corresponding party 103 is a recipient (or indeed to check other parties' transactions in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0069] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She will then send the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that Alice's computer 102 is best connected to. When any given blockchain node 104 receives the new transaction 152j, it will process it according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets certain conditions for becoming "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions may be configurable on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by a combination of script and node protocol.

[0070] If the newly received transaction 152j passes the validity test (i.e., under the “valid” condition), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the network 106.

[0071] Once in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 will begin racing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (keep in mind that other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, whoever solves the puzzle first will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j). Once the pool 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0072] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is “valid” before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

[0073] Another type of transaction protocol operated by some blockchain networks as part of the account-based transaction model can be called an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of a previous transaction in the past sequence of transactions, but by reference to an absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes of the network and is continuously updated. In such systems, transactions are ordered using an account's running transaction record (also called a "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, a data field can point to a previous transaction if it contains the ID of the previous transaction.

[0074] 2. UTXO-based model

[0075] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx" for short) is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other exemplary blockchain networks.

[0076] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not been redeemed). The UTXO includes a value that specifies the amount of a digital asset. This represents a set of tokens on a distributed ledger. The UTXO may also include a transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include an indicator of the size of the input field 202 and the output field 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0077] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In , Alice's new transaction 152j is labeled "Tx1". This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. Figure 2, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels that do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to a subsequent transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0078] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 may already be valid and included in block 151 of the blockchain 150. The transaction may have been included in one of the blocks 151 at this time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 soon. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together; or, if the node protocol allows buffering of "orphan" transactions, Tx0 may even be sent after Tx1. The terms "previous" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may equally be replaced by "predecessors" and "successors", "predecessors" and "descendants", or "parents" and "children", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") pointing to a previous transaction (predecessor transaction or "parent transaction") will not be valid unless the parent transaction is valid. A child transaction that arrives at the blockchain node 104 before the parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0079] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking condition, which typically includes the following conditions: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the previous transaction was locked.

[0080] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "Script" (with a capital S), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0081] Thus in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , in order to redeem UTXO0 (strictly speaking, to make subsequent transactions that attempt to redeem UTXO0 valid). A ] contains Alice's public key P from her public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in the embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A >, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0082] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing two scripts:

[0083] <Sig PA> <pa>||[Checksig PA]

[0084] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (included in the locking script of the output of Tx0) to verify that the unlocking script in the input of Tx1 contains Alice's signature when signing the expected portion of the data. The expected partial data itself (the "message") also needs to be included in order to perform this verification. In an embodiment, the signed data includes the entire Tx1 (so there is no need to include a separate element to plaintext specify the signed partial data, as it is already present).

[0085] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Basically, if Alice has signed a message using her private key cryptographically, then given Alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this to the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a particular data fragment or transaction portion, etc., may mean signing the hash value of that data fragment or transaction portion.

[0086] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the example shown, if Alice's signature is provided and authenticated in Tx1), then the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the pending transaction ordered pool 154. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that it will propagate throughout the network 106. Once Tx1 is valid and included in the blockchain 150, this will define UTXO0 from Tx0 as spent. It should be noted that Tx1 is only valid if it spends unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (that is, whether it has formed a valid input for another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of a transaction 152 as having been spent, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

[0087] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for failure in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0088] Note that in the UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave behind" a portion of the amount defined in a UTXO as spent while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split between multiple UTXOs in Tx1. Therefore, if Alice does not want to give all of the amount defined in UTXO0 to Bob, she can use the remaining portion to make change for herself in the second output of Tx1, or to pay another party.

[0089] In practice, Alice will also typically need to include a fee for the Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104, and therefore, although technically valid, may not be propagated and included in the blockchain 150 (if the blockchain node 104 does not want to accept transaction 152, the node protocol does not force the blockchain node 104 to accept). In some protocols, the transaction fee does not require its own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 that issued the transaction. For example, assume that a pointer to UTXO0 is the only input of Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference can be distributed by the node 104 that wins the proof-of-work competition to create a block containing UTXO1. Alternatively or additionally, this does not necessarily preclude that a transaction fee may be explicitly specified in one of the UTXOs 203 in the transaction 152 itself.

[0090] Alice and Bob's digital assets consist of the UTXO locked to them in any transaction 152 anywhere in the blockchain 150. Therefore, in general, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate the various UTXO values ​​locked to the respective parties and not yet spent in other subsequent transactions. To achieve this, it can query a copy of the blockchain 150 stored at any one Bitcoin node 104.

[0091] It should be noted that script code is often represented schematically (i.e., using an imprecise language). For example, an opcode (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode of the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a file to be stored in the blockchain.

[0092] Typically, the inputs to a transaction contain a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at the time of signing).

[0093] The locking script is sometimes referred to as "scriptPubKey", which means that it usually includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", which means that it usually provides the corresponding signature. However, more generally speaking, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily include verification of the signature. More generally speaking, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0094] 3. Side Channels

[0095] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b can include additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of any party or third party). The side channel 107 enables data to be exchanged away from the blockchain network. Such communications are sometimes referred to as "off-chain" communications. For example, this can be used to exchange transactions 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way is sometimes referred to as sharing "transaction templates". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0096] The side channel 107 may be established via the same packet switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links via one or more networking technologies or communication media that are used to exchange data "off-chain", i.e., off-chain. The bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Therefore, it should be noted that if Alice and Bob are said to exchange certain information or data, etc., via a side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0097] 4. Client software

[0098] Figure 3A An exemplary implementation of a client application 105 for implementing an embodiment of the disclosed solution is shown. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. According to the solution discussed above and the content to be discussed in further detail later, the transaction engine 401 is configured to implement the basic transaction-related functions of the client 105, such as formulating transactions 152, receiving and / or sending transactions and / or other data through the side channel 301, and / or sending transactions to one or more nodes 104 to propagate through the blockchain network 106. According to the embodiments disclosed herein, the transaction engine 401 of each client 105 includes a function 403, which is configured to write a locking script in a high-level scripting language and convert between the high-level scripting language and the low-level scripting language. In other words, a locking script written in a high-level language can be mapped to an equivalent locking script written in a low-level language. For example, Alice 103a can use a high-level language to build a compact locking script, and then the transaction engine 401 can generate a corresponding extended locking script.

[0099] The UI layer 402 is configured to present a user interface through a user input / output (I / O) mode of the corresponding user's computer device 102, including outputting information to the corresponding user 103 through the user output mode of the device 102, and receiving input from the corresponding user 103 through the user input mode of the device 102. For example, the user output mode may include one or more screens (touch or non-touch screen) that provide visual output, one or more speakers that provide audio output, and / or one or more tactile output devices that provide tactile output, etc. The user input mode may include, for example, an input array of one or more touch screens (which may be the same or different from that / those used for the output mode); one or more cursor-based devices such as a mouse, trackpad, or trackball; one or more microphones and voice or sound recognition algorithms for receiving voice or sound input; one or more gesture-based input devices for receiving input in the form of manual or physical gestures; or one or more mechanical buttons, switches, or joysticks, etc.

[0100] Note: Although various functions in this document may be described as being integrated into the same client application 105, this does not necessarily constitute a limitation. Instead, they can be implemented in a suite of two or more different applications, such as one application as a plug-in to another application or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 can be implemented in a separate application rather than in the UI layer 402, or the functionality of a given module such as the transaction engine 401 can be split between multiple applications. At the same time, it is not excluded that some or all of the described functions can be implemented, for example, at the operating system level. Where a single or given application 105 or the like is referenced anywhere in this document, it should be understood that this is only by way of example, and more generally, the described functions can be implemented in any form of software.

[0101] Figure 3B A model is given of an example of a user interface (UI) 500 that may be presented by the UI layer 402 of the client application 105a on Alice's device 102a. It should be understood that a similar UI may be presented by the client 105b on Bob's device 102b or any other party's device.

[0102] By means of diagrams, Figure 3B The UI 500 is shown from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 503, which are presented as different UI elements through user output.

[0103] For example, the UI element may include one or more user-selectable elements 501, which may be different buttons on a screen, different options in a menu, or the like. The user input mode is configured to enable the user 103 (in this case, Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the UI element on the screen, or speaking the name of the desired option (Note: the term "manual" as used herein is only used to contrast with automatic, and is not necessarily limited to performing operations by hand). These options enable the user (Alice) to select one or more high-level functions of the high-level scripting language, such as functions configured to perform complex mathematical operations. The options may also enable the user to convert from a compact locking script to an extended locking script, such as generating a signature based on a transaction containing an extended locking script instead of a version of the compact locking script.

[0104] Alternatively or additionally, the UI element may include one or more data input fields 502 through which a user may write one or more advanced functions. These data input fields are presented via a user output method, such as on a screen, and data may be entered into the fields via a user input method, such as a keyboard or touch screen. Alternatively, data may be received verbally based on speech recognition or the like.

[0105] Alternatively or additionally, the UI element may include one or more information elements 503 that output information to the user. For example, this / these may be presented on a screen or audibly.

[0106] It should be understood that the specific manner in which various UI elements, selection options, and input data are presented is not important. The functions of these UI elements will be discussed in more detail later. It should also be understood that the UI 500 shown in Figure 3 is only a diagram model, and in practice, it may include one or more further UI elements, which are not described for the sake of brevity.

[0107] 5.Node software

[0108] Figure 4 An example of node software 450 running on each blockchain node 104 of the network 106 in an example of a UTXO-based or output-based model is shown. It should be noted that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., not performing the actions required of the node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes, but is not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to identify different fields of a transaction 152 and process such fields according to the node protocol. When a transaction 152i (Tx m-1 )’s output (e.g., UTXO) is an input transaction 152j (Tx j ), the protocol engine 451 identifies Tx j The unlocking script in and passes it to the script engine 452. The protocol engine 451 also j The pointer in the input to identify and retrieve Tx i .Tx i may be published on blockchain 150, in which case the protocol engine may retrieve Tx from the copy of block 151 of blockchain 150 stored at node 104 i . Or, Tx i It can also be published on blockchain 150. In this case, protocol engine 451 can retrieve Tx from unpublished ordered transaction set 154 maintained by node 104. i Regardless of the method used, the script engine 451 will identify Tx i The locked script in the reference output is passed to the script engine 452.

[0109] Therefore, the script engine 452 has Tx i The locking script and the j The unlocking script for the corresponding input. For example, Figure 2 Transaction labels Tx0 and Tx1 are shown in FIG, but the same transaction can also be applied to any transaction pair. As previously described, the script engine 452 runs two scripts together, which will include placing data on and retrieving data from the stack 453 according to the stack-based scripting language used (e.g., script).

[0110] By running the scripts simultaneously, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the unlocking script unlocks the output including the locking script? The script engine 452 returns the result of the determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet one or more criteria specified in the corresponding locking script, the result "TRUE" is returned. Otherwise, the result "FALSE" is returned.

[0111] In the output-based model, the result "TRUE" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, one or more further protocol-level conditions evaluated by the protocol engine 451 must also be satisfied; for example, Tx j The total amount of digital assets specified in the inputs of tx does not exceed the total amount pointed to in its outputs, and tx i The pointed output of has not been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 and one or more protocol-level conditions, and only if they are all TRUE, the protocol engine verifies the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Under the condition that it is indeed effective, the decision engine 454 can choose to control the consensus module 455C and the propagation module 455P at the same time to execute its Tx j . This includes the consensus module 455C, adding Tx to the corresponding ordered transaction set 154 of the node j , for incorporation into block 151; and propagation module 455P, Tx j Forwarded to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees are reserved.

[0112] In addition, it should be noted that in this article, the terms "TRUE" and "FALSE" are not necessarily limited to returning results that are expressed only in the form of a single binary number (bit), although this is indeed a possible implementation. More generally, "TRUE" can refer to any state indicating a successful or positive result, while "FALSE" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model, the combination of implicit protocol-level verification of signatures and additional positive outputs of smart contracts can be used to indicate that the result is "TRUE" (if both individual results are TRUE, the overall result is considered to be TRUE).

[0113] 6. Advanced scripting language

[0114] Figure 5 An exemplary system 500 for sending transactions between users and nodes is shown. The system 500 includes one or more generators (i.e., parties that generate blockchain transactions). For simplicity, Figure 5 Only two generating parties are shown, namely Alice 103a and Bob 103b. It should be noted that the generating party does not have to be a user, but can be a machine. The system 500 also includes a verification entity (shown in the form of blockchain node 104) and one or more nodes of the blockchain network 106.

[0115] A generator (e.g., Alice 103a) is configured to generate a first blockchain transaction Tx1. The first blockchain transaction Tx1 includes one or more outputs. The first transaction is a compact transaction. At least one of these outputs (the first output) includes a compact locking script (CLS), also referred to as a compact script (CS) throughout the text. It should be noted that the first output does not need to appear first in the transaction logically. Instead, "first" is used only as a label for this particular output. The CLS is written in a high-level (HL) scripting language and includes one or more high-level (HL) functions. Each high-level function is configured to perform an operation (also referred to as an operation) equivalent to one or more low-level (LL) functions (e.g., opcodes) of a low-level (LL) scripting language (i.e., a native scripting language) of the blockchain 150. The CLS is configured to perform an operation equivalent to an extended locking script (ELS) written only in the LL scripting language (i.e., defining a locking condition). The ELS is also referred to as an extended script (ES, expanded script) throughout the text. For example, both CLS and ELS can define a locking script to find the modular inverse of a number. Instead of requiring a large number of LL functions to perform the operation, CLS can include a single HL function configured to find the modular inverse of the number, thereby reducing the size of CLS compared to ELS. In other words, a CLS written in the HL scripting language can be compiled into an ELS written in the LL language.

[0116] In some examples, there can be a one-to-one mapping between a single high-level function and a single LL function. For example, the HL function "ADD" or "+" can perform the operation of the corresponding LL function (e.g., OP_ADD). Similarly, the symbols "-", "*", and " / " can be used to perform subtraction, multiplication, and division, respectively. This can achieve savings compared to LL functions such as OP_SUB, OP_MUL, and OP_DIV used by a specific LL scripting language Script.

[0117] In some examples, at least some of the HL functions map to multiple LL functions. For example, a single HL function can perform multiple sequential operations on a data item (see example below). In some examples, each HL function maps to multiple LL functions.

[0118] The first transaction Tx1 may include multiple outputs, such as a second output. The second output may also include a corresponding CLS. Generally, some or all of the outputs of the first transaction Tx1 may include a corresponding CLS.

[0119] Alice 103a is also configured to provide the first transaction Tx1 to the blockchain network 106 in the HL language. For example, Alice 103a can send the first transaction directly or indirectly via a different party (e.g., Bob 103b) to the blockchain node 104. For example, Alice 103a can send the transaction Tx1 to Bob 103b through the side channel 107. After receiving the transaction, Bob 103b can include a signature to sign the transaction Tx1. Bob 103b can then send the transaction Tx1 to the network 106. Since the first CLS is less than the corresponding first ELS, bandwidth can be saved when transmitting the first transaction. Alice 103a can store the first transaction Tx1 in the memory of her computing device 102a.

[0120] In some examples, Alice 103a can generate a transaction identifier TxID1 for the first transaction Tx1. The transaction identifier is typically a hash or double hash of the original transaction data. Alice 103a first generates a modified version of the first transaction Tx raw , the modified version does not contain any CLS, but contains the corresponding ELS. That is, the first output contains the first ELS instead of the first CLS. Similarly, if the first transaction Tx1 contains multiple CLSs, the modified version contains multiple ELSs. Then, based on the modified version Tx1 of the first transaction raw To generate a transaction identifier TxID1, for example, by taking a modified version of the first transaction Tx raw Alice 103a provides the transaction identifier TxID1 to the blockchain network 106, for example by sending it to the blockchain node 104 together with the first transaction Tx1.

[0121] In some examples, Alice 103a first generates a first transaction Tx1 containing a version of CLS, and then generates a modified version of the first transaction Tx raw , that is, by replacing any CLS with the corresponding ELS. In other words, function 403 can convert the first CLS into the first ELS by mapping between the HL function of the HL language and the LL function of the LL language, that is, compile the first CLS into the first ELS. Then, a transaction identifier TxID1 is generated.

[0122] Generate the first transaction Tx of the modified version raw This may simply mean replacing the first CLS with the first ELS. Then, after generating the transaction identifier TxID1, the first ELS may be replaced with the first CLS, so that the first transaction Tx1 containing the version of the first CLS may be sent to the blockchain network 106.

[0123] It is also possible that Alice 103a may generate a modified version of the first transaction Tx in the first instance. raw , i.e., a transaction containing the first ELS. This enables Alice 103a to generate a transaction identifier TxID1. Alice 103a can then replace the ELS with the corresponding CLS. That is, function 403 can convert the first ELS into the first CLS by mapping between the LL function of the LL language and the HL function of the HL language.

[0124] Blockchain transactions typically include a signature for unlocking the referenced output of the previous transaction in the input of the transaction. If Alice 130a needs to include a signature as part of the input of the first transaction Tx1 to unlock the output of the previous transaction, Alice 103a can include the signature as a modified version of the first transaction Tx raw In other words, Alice’s signature on the first transaction Tx contains a modified version of the first ELS instead of the first CLS raw Then, a transaction identifier TxID1 may be generated based on the modified version including Alice's signature. This version of the transaction submitted to the network 106 also includes Alice's signature. However, when the first transaction Tx1 is used as the message for verification, this signature will not be a valid signature. raw This signature is a valid signature only when it is used as a message.

[0125] It should be noted that replacing the first CLS with the first ELS may depend on the selection of the signature flag (e.g., SIGHASH flag) selected by Alice 103a. For example, Alice 103a may select a signature flag (e.g., SIGHASH_NONE) so that the signature is not applied to any transaction output. In this case, Alice 103a does not have to replace the first CLS with the first ELS. As another example, Alice 103a may select a signature flag (e.g., SIGHAHS_SINGLE) so that the signature is only applied to one output. In this case, if the signature is applied to an output that does not contain the first CLS (or any other CLS), Alice 103a does not need to replace the first CLS with the first ELS (or a corresponding ELS). In addition, in this case, if the CLS exists in an output that is not signed using the signature, Alice 103a does not need to replace the CLS. However, if a single output signed using the signature does contain the first CLS, Alice 103a must replace the first CLS with the first ELS. Finally, Alice 103a can select the signature flag (e.g., SIGHASH_ALL) so that the signature signs all outputs. In this case, Alice 130a must replace the first CLS with the first ELS. The same applies to any other outputs that contain a corresponding CLS.

[0126] In some examples, Alice 103a can generate one or more secondary transaction identifiers. These secondary identifiers are similar to the transaction identifier TxID1 described above, in that these secondary identifiers can be hashes or double hashes of data, but the hashed data is different. For example, the secondary transaction identifier can be generated based on one or more of the following: a version number of the first transaction Tx1, a lock time of the first transaction Tx1, one or more inputs of the first transaction Tx1, and / or one or more outputs of the first transaction Tx1. As a specific example, the secondary transaction identifier can be based on a version number and a lock time. Additionally or alternatively, the secondary transaction identifier can be based on one or more outputs including a corresponding CLS.

[0127] The input of a transaction can consist of three parts:

[0128] 1. A transaction identifier concatenated with an index (indicating which transaction output is to be spent);

[0129] 2. Unlocking script; and

[0130] 3. Serial number.

[0131] The unlocking script may contain a digital signature that signs the secondary transaction identifier. Therefore, a portion of the unlocking script that contains a digital signature that may sign the secondary transaction should be excluded. When the secondary transaction identifier is based on one or more inputs, part or all of the unlocking script of the input may be excluded in order to avoid circular references. In other words, the transaction identifier may be based only on the transaction identifier and / or sequence number concatenated with an index, rather than the complete unlocking script.

[0132] One or more secondary transaction identifiers may be included in an output (e.g., an unspendable output) of the first transaction Tx1. raw One or more secondary transaction identifiers may also be included. Thus, in these examples, the "primary" transaction identifier TxID1 and the signature are a function of one or more secondary transaction identifiers.

[0133] In some embodiments, although the HL scripting language is a higher-level language compared to the LL scripting language, the HL scripting language may also be a lower-level language compared to the higher-level scripting language. That is, the HL language may be an intermediate language between the LL language and the second-layer HL language. The second-layer HL language is a user-oriented language. In other words, the user-oriented language may be a scripting language that can be written by a user (or other party or entity, including a device). A script written in a user-oriented language may be compiled (which may mean compressed) into a script written in an intermediate language, such as a first CLS. Furthermore, a script written in an intermediate language may be expanded (e.g., by mapping) into a script written in an LL language. It is also not excluded that a script written in a user-oriented language may be directly converted into a script written in a low-level language.

[0134] In other words, in some embodiments, there are only two levels of scripting languages: high-level languages ​​and low-level languages, while in other embodiments, there are three levels of scripting languages: user-oriented (highest level), intermediate-level languages, and low-level languages. In one exemplary implementation, the user-oriented language may be referred to as an SDF language, the intermediate language may be referred to as a metascripting language, and the low-level language may be referred to as a canonical (e.g., native) language.

[0135] Returning to the above example, Alice 103a may generate a transaction including a locking script written in a user-oriented language (i.e., a user-oriented (UF) locking script). The UF locking script is then converted (e.g., compiled) into a first CLS written in an intermediate language before being submitted to the network 106. The transaction including the first CLS may then be submitted to the network 106. In other words, in these examples, the user-oriented language is only used by Alice 103a when initially generating the transaction. The transaction is submitted together with the locking script in a more compact form of the CLS.

[0136] The above teachings apply not only to locking scripts, but also to unlocking scripts. That is, in addition to or instead of generating a compact locking script that is converted into an extended locking script, Alice's transaction may include a compact unlocking script. The compact unlocking script may be written in an intermediate language or a user-oriented language.

[0137] like Figure 5 As shown, blockchain node 104 obtains a first transaction Tx1. The first transaction Tx1 includes a first CLS (and may include one or more additional CLSs). The first transaction Tx1 may be obtained directly from Alice 103a or from a different entity (e.g., Bob 103b). It is not excluded that node 104 may obtain the first transaction Tx1 from a different node 104.

[0138] Node 104 is configured to verify the first transaction Tx1. In some embodiments, the first transaction is verified to be valid based on the transaction identifier of the first transaction Tx1. In these embodiments, node 104 obtains the candidate transaction identifier TxID1 from Alice 103a, Bob 103b, or a different entity, etc. It is expected that the transaction generator (i.e., Alice 103a) will send the candidate transaction identifier TxID1 together with the first transaction Tx1.

[0139] Node 104 generates a modified version of the first transaction Tx by replacing the first CLS with the corresponding ELS raw ', that is, compile the first CLS into the first ELS. In other words, the node 104 is configured to convert the first CLS into the first ELS. This can be performed by the script engine 452 of the node or by a different function 455. raw 'After that, node 104 based on the modified version of the first transaction Tx raw ' to generate a transaction identifier TxID1'. For example, the first transaction Tx raw 'Hash or double-hash to generate a transaction identifier TxID1'.

[0140] In order for the first transaction Tx1 to be considered valid, the obtained candidate transaction identifier TxID1 must match the generated transaction identifier TxID1′. Therefore, the node 104 performs a comparison of the transaction identifiers and determines whether they are the same. If the transaction identifiers do not match, the first transaction Tx1 is considered invalid and may be ignored.

[0141] If the transaction identifiers do match, node 104 can proceed to verify the transaction according to the blockchain protocol. This includes executing the inputs of the first transaction Tx1 and the corresponding reference outputs of the previous transaction of these inputs.

[0142] If the transaction Tx1 is valid according to the blockchain protocol, the node 104 may send the transaction Tx1 to other nodes 104 of the network 106 and / or attempt to modify the transaction Tx1 based on the modified version of the first transaction Tx2. raw In other words, the block will include the Merkle root of the Merkle tree with the modified transaction Tx raw This may include including the first transaction Tx1 and / or the modified version of the first transaction TxID1 as one of its leaves (i.e., including the (double) hash of the modified transaction of the first ELS). raw Stored in memory.

[0143] In some examples, the modified version of the transaction may not include the first CLS. In other examples, the modified version of the transaction may include both the first ELS and the first CLS. For example, the first output of the modified transaction may include the first CLS so that the first CLS is not executed during transaction verification. For example, the first CLS may follow the OP_RETURN opcode: <els>OP_RETURN <cls>In this case, the transaction identifier is based on both the first ELS and the first CLS.

[0144] In some examples, node 104 may, in response to receiving the request, send a modified version of the first transaction Tx raw 104. For example, a block 151 containing a first transaction Tx1 may be published on the blockchain 150. The requesting node 104 may not be configured to verify that a transaction containing a script written in the HL language is valid. Therefore, the node 104 sends a modified version of the first transaction Tx raw is sent to the requesting node so that the requesting node 104 can verify that the first transaction is valid as it normally would for transactions containing only the LL scripting language.

[0145] So far, the above description of verifying transactions has focused on verifying transactions that contain CLS but not necessarily inputs intended to unlock CLS. For example, a first transaction Tx1 may include inputs that unlock outputs of a previous transaction written only in LL language.

[0146] Assuming that the first transaction Tx1 is a valid transaction, it will be published in block 151. Then, the blockchain node 104 (not necessarily the same as the node 104 that published the block 151, although this is not excluded) can receive the second transaction Tx2, which includes an input that references the first output of the first transaction Tx1, i.e., the output containing the first CLS. The second transaction Tx2 can be generated by a second party such as Bob 103b. Bob 103b can send the second transaction to the node 104 directly or indirectly via a different entity (e.g., a third user Eve).

[0147] Then, the node 104 proceeds to verify the second transaction Tx2. In order to verify whether the second transaction Tx2 is valid, the node 104 must obtain the first transaction from the memory or from the blockchain 150, etc. Then, the node 104 has two options for verifying that the second transaction Tx2 is valid. As a first option, the node 104 can replace the first CLS with the first ELS (i.e., compile the first CLS into the first ELS), and then execute the input of the second transaction against the first ELS. The execution must be successful for the second transaction to be valid. In other words, the input of the second transaction must successfully unlock the first ELS. As a second option, the node 104 does not need to replace the first CLS with the first ELS; instead, the node 104 can execute the input of the second transaction Tx2 against the first CLS. Similarly, the execution must be successful for the second transaction to be valid. In other words, the input of the second transaction Tx2 must successfully unlock the first CLS.

[0148] Since the first CLS is equivalent to the first ELS, the same input will unlock both the first CLS and the first ELS. As a simple example, assume that the first ELS includes multiple LL functions that are configured to take a number from the input of the second transaction Tx2, perform mathematical operations on the number, and check whether the number matches the number included in the first ELS. The first CLS is configured to perform the same operation, but its size is smaller than the first ELS. For example, the first CLS may include the number and a single HL function, while the first ELS may include the number and multiple LL functions. Since the overall operation of the first ELS and the first CLS is the same, the same input will result in the same result, i.e., successful or unsuccessful execution.

[0149] If the second transaction Tx2 is valid, that is, if the unlocking script of the second transaction successfully unlocks the first ELS or the first CLS, and any other conditions of the blockchain protocol are met, the node 104 may send the second transaction Tx2 to other nodes 104 of the blockchain network 106. The node 104 may also store the second transaction Tx2, for example, in order to construct a block 151 containing the second transaction Tx2.

[0150] The second transaction Tx2 may include one or more outputs, which include corresponding CLSs. In this case, as part of verifying that the second transaction Tx2 is valid, the node 104 may perform the same operations described above when discussing verifying that the first transaction Tx1 is valid, namely: obtaining a candidate transaction identifier TxID2; generating a modified version of the second transaction; generating a transaction identifier TxID2′; and performing a comparison between the obtained transaction identifier and the generated transaction identifier. To ensure efficiency, the comparison may be performed before executing the input and output scripts.

[0151] The above discussion on verifying transactions mainly focuses on verifying whether transactions including compact locking scripts are valid. Node 104 can also verify that transactions including compact unlocking scripts (as a supplement or replacement for compact locking scripts) are valid. Node 104 can directly execute the compact unlocking script during the verification of transaction validity, that is, directly execute the compact unlocking script in the HL scripting language (which can be a user-oriented language or an intermediate language). Alternatively, node 104 can convert the compact unlocking script into an extended unlocking script written in the LL scripting language before execution.

[0152] The description regarding generating a modified version of a transaction for the purpose of generating a signature and / or a transaction identifier applies equally to the case where the transaction includes a compact unlocking script.

[0153] Fig. 9 The relationship between these three languages ​​is shown. As shown in the figure, the lowest level language is the LL language, which is the native scripting language of the blockchain (e.g., the operation code of the Script language); the higher level language is the intermediate language; the language above the intermediate language is the user-oriented language.

[0154] The programming architecture is designed to make blockchain scripts more accessible, more efficient in terms of computation and space, and more friendly to smart contracts.

[0155] The life cycle of a transaction includes at least the following stages:

[0156] 1. Create – a transaction (the transaction created); the script can be in a user-oriented scripting language, a mid-level scripting language, or a low-level scripting language.

[0157] 2. Propagation – a transaction (transmitted transaction); scripts can be in a mid-level language for compact processing on the node side (compared to user-facing languages) and quickly expand to LL languages.

[0158] 3. Storage – a transaction (stored transaction); scripts can be written in a mid-level language for compact processing.

[0159] 4. Verification - Two transactions (the spent transaction provides the locking script, the spent transaction provides the unlocking script). Verification is not performed during creation, propagation, or storage. At execution time, the transaction can be executed exclusively in its compact form or in its expanded form, or in a hybrid manner where some but not all of the compact script is converted to native script before execution.

[0160] In some examples, when executing a compact script (locking script or unlocking script), a function table can be used by different parties (i.e., Alice 103a and node 104). The function table contains a list of HL functions and corresponding LL functions. In other words, the HL functions are mapped to corresponding LL functions. The HL functions are compiled (i.e., translated) into corresponding LL functions and stored in the function table. The function table enables the conversion of compact scripts into extended scripts and vice versa.

[0161] The function table may be created in whole or in part by Alice 103a and distributed to one or more nodes 104; or, the function table may be created in whole or in part by another entity (eg, one of the nodes 104).

[0162] In an embodiment utilizing a three-tier framework (i.e., a user-oriented language, an intermediate language, and a low-level language), a function table may be used to map from an IL language to a LL language. The function table is the output of compiling a UF language. When a function is written in a UF language, the function is compiled (i.e., translated) into a corresponding IL function. The corresponding IL function is mapped to one or more other (i.e., different) IL functions and / or one or more LL functions, i.e., an IL function (e.g., "reverse" in the exemplary section below) is mapped to a group of lower-level functions that together perform operations equivalent to the IL function. In this article, "lower-level" refers to a level lower than the user-oriented level. The group of lower-level functions is stored in the function table in association with the IL function (in the exemplary section below, "length" is an example of a different IL function).

[0163] The function table can then be used to generate and / or execute an IL script. For example, a reference to an IL function or an identifier of an IL function can be included in the IL script so that when executed, a mapped set of lower-level functions can be executed. In other words, the identifier / reference is used to find the set of lower-level functions. In this example, the reference or identifier itself is an IL function, which is configured to perform operations equivalent to one or more LL functions when executed, and equivalently, performs operations equivalent to the identified / referenced functions. The IL script itself can be expanded into a corresponding native script. Similarly, the set of lower-level functions can be obtained from the function table and then expanded to only LL (i.e., native) functions. It should be noted that the set of lower-level functions that define an IL function itself can include different IL functions or identifiers or references of the different IL functions.

[0164] As mentioned above, there can be multiple different UF languages ​​(e.g., Python and Java) that can compile to the same IL language. Preferably, the same UF function written in different UF languages ​​(i.e., functions configured to perform the same operation but written in different languages) compiles to the same set of lower-level functions of the function table, but this is not required, as long as they produce the same output when given the same input.

[0165] Nodes 104 may generate a larger function table based on several smaller function tables, e.g., function tables generated by different parties (e.g., users or nodes). An overall table may be stored by a centralized party, and nodes 104 may update their tables from time to time by requesting the overall table.

[0166] A user-facing language is a human-readable, developer-friendly, extensible language that compiles to a mid-level language. An example of a user-facing language is provided below. However, there can be multiple different user-facing languages ​​that compile to the same mid-level language. Existing languages ​​such as Java, JavaScript, or Python can also be adapted into a high-level language for creating blockchain transactions.

[0167] The middle-level language connects the higher-level language to the lower-level language (e.g., opcodes) to achieve efficiency gains in bandwidth, storage, and computation. Hereinafter, this general-purpose middle-level language will be referred to as a metascript. The characteristics of a metascript can be summarized as follows:

[0168] 1. Space efficient – ​​more compact in size than both high-level and low-level languages;

[0169] 2. Executable – can be directly executed by a compatible scripting engine (it should be noted that this is optional and in some cases metascripts are not executable unless extended to a low-level language);

[0170] 3. Extensible – can be extended to low-level languages ​​(native scripts); and

[0171] 4. Determinism – the same metascript will always expand to the same native script.

[0172] Furthermore, when given the same input and executed directly, a metascript will produce the same output as would be produced by executing a native script extended from the metascript.

[0173] Developers can write scripts in a user-oriented language and then compile the scripts into intermediate language scripts (metascripts). Transactions can be transmitted and stored as metascript versions of transactions. Transactions can be verified in metascripts or native scripts or in a hybrid manner (i.e., executing unlocking scripts and locking scripts). That is, the metascript engine of blockchain node 104 can interact with the native script engine to obtain more functions and improve efficiency.

[0174] The user-oriented language script can be directly converted into a low-level language script (native script). However, by introducing an intermediate language script (metascript), the workload of converting the user-oriented language script into the native script can be reduced as much as possible for the blockchain node 104. This enables the node 104 to focus its resources on other more important activities, such as generating blocks (mining). The differences between the user-oriented language script, the intermediate language script and the low-level language script are shown by way of example, and the blockchain script is improved in various aspects.

[0175] Specific examples of some embodiments of the present invention are provided below. These examples refer to the Bitcoin blockchain, but it should be noted that these examples are generally applicable to other blockchains as well.

[0176] It should also be noted that the following examples describe an architecture with three language levels: a user-facing language, a mid-level language, and a low-level language. In these examples, smart contracts are written in a user-facing language, which is converted to a metascript written in a mid-level language, which in turn is converted to Bitcoin opcodes (i.e., a low-level language).

[0177] Alice can use a user-level scripting language to create a locking script [High-Level scriptB]. The locking script is then compiled into an intermediate language metascript and embedded in the transaction.

[0178]

[0179] Here are a few notes.

[0180] 1. The locking script [High-Level script B] is a script written in a user-oriented scripting language and is called a user-oriented locking script.

[0181] 2. Compile the user-facing locking script into a meta script [Meta Script B].

[0182] 3. For each metascript, there exists a native locking script that includes native (Bitcoin) opcodes and is equivalent to the metascript. That is, given the same unlocking script, the unlocking script always produces the same result when executed. This deterministic behavior and its equivalence can be achieved through testing and verifiable computation.

[0183] 4. The native locking script can be several megabytes or even larger, while its compact form can be as small as a few bytes. The significant difference in size is advantageous (to Bitcoin nodes) when propagating and storing transactions.

[0184] 5. First, an unsigned transaction is constructed (Table 1). When signing this transaction, the compact locking script is expanded into a low-level language locking script (Table 2).

[0185]

[0186] Table 1: Unsigned transactions in the metascript

[0187]

[0188] Table 2: Unsigned extended transaction

[0189]

[0190] Table 3: Signed extended transaction

[0191] 6. After signing the transaction, while the native locking script is still present in the transaction, the transaction is serialized and double-hashed to obtain its transaction ID. That is, TxID1 is calculated based on the extended locking script instead of the compact locking script. Since TxID is defined as being based on the native (Bitcoin) script, this allows forklessness in the blockchain, i.e., preventing forks.

[0192]

[0193] Table 4: Signed extended transaction with calculated transaction ID

[0194] 7. To facilitate integrity verification in some cases, the secondary transaction ID of the compact locking script can be embedded in the transaction before signing the transaction. For example, TxID 1-secondary Defined as a hash value whose preimage consists of one of the following:

[0195] a. Version and lock time;

[0196] b. Input, excluding the unlocking script; and

[0197] c. Output, including the locking script in compact form.

[0198] This is shown in Tables 5 to 8.

[0199]

[0200] Table 5: Embedding the secondary transaction ID when creating an unsigned compact transaction

[0201]

[0202] Table 6: Signing the extended transaction and secondary transaction ID

[0203]

[0204] Table 7: Calculation of native transaction ID for extended transactions including secondary transaction ID

[0205]

[0206] Table 8: Replace extended scripts with compact scripts

[0207] The transaction created by Alice 103a above will be propagated in a compact form of the transaction (metascript) to save bandwidth. As mentioned earlier, the compact form of the transaction can be orders of magnitude smaller than the extended locking script. This is particularly relevant to the Bitcoin SV ecosystem, where script size is not limited and each block can contain billions of transactions (approximately every 10 minutes).

[0208] Currently, it is assumed that there are two types of nodes 104, namely, HL-enabled Bitcoin nodes that are configured to execute the HL scripting language and HL-disabled Bitcoin nodes that are not configured to execute the HL scripting language. It should be noted that HL-disabled nodes are existing nodes that are not affected by the HL scripting language and are not configured to use the HL language, rather than nodes that are aware of the HL language and simply choose to disable this feature.

[0209] Depending on the signature flags used to sign the transaction's inputs (see discussion above), HL-disabled nodes may treat transactions containing CLS as invalid. That is, when HL-disabled nodes receive the transaction, these nodes will treat the transaction as invalid and discard it because these nodes have no mechanism to retrieve the original transaction with the extended locking script. The transaction is considered invalid because during the signature verification of the unlocking script of the spending transaction, the signature message is considered to include ELS (HL-disabled nodes cannot reproduce ELS from CLS). This is the same as the case where these nodes receive the transaction ID but not the transaction data. However, when HL-enabled Bitcoin nodes discover the block, the problem of these nodes not accepting it can be solved. The HL-disabled node receives the block containing Alice's transaction. Her transaction is considered non-existent because the HL-disabled node does not store her transaction. The HL-disabled node can then request the transaction from the HL-enabled node. The HL-enabled node sends the full transaction, excluding the compact locking script. The HL-disabled node can then verify that the full transaction is valid. However, if the majority of nodes are HL-enabled nodes, the HL-enabled nodes may choose to ignore such requests as Alice's transaction will be accepted by the majority of the network 106.

[0210] In some examples, if the signature does not sign all transaction outputs, a node with HL disabled may be able to treat an HL transaction as valid if one or more outputs containing a CLS are not signed. In this case, the node with HL disabled can actually use the transaction's CLS to verify that the transaction is valid. However, this vulnerability is not unique to the present invention, and in general, any transaction that does not have a signature (with a signature flag that signs all outputs, such as SIGHASH_ALL) is susceptible to output modification.

[0211] When a HL-enabled node receives this transaction, it will perform the following actions:

[0212] 1. Use the library registry or reference table to convert the meta-locking script to the corresponding native locking script to obtain the following:

[0213]

[0214] 2. Hash the transaction data to get its transaction ID and check if it is the same as TxID1.

[0215] 3. If the same, then usually proceed to signature verification or script verification. It should be noted that script verification can start after receiving the transaction.

[0216] 4. If the transaction is valid, the HL-enabled nodes will propagate the transaction to the peers of these nodes in a compact form of the transaction.

[0217] When HL-disabled nodes validate blocks discovered by HL-enabled Bitcoin nodes, they will request full transaction data for transactions with compact locking scripts, or only missing transactions from their perspective. In this case, HL-enabled nodes will send those transactions with extended locking scripts. This will allow HL-disabled nodes to validate these transactions. Since each compact locking script is equivalent to an extended locking script, transactions successfully verified by HL-enabled nodes are also valid for HL-disabled nodes.

[0218] Assume that a user (e.g., Bob 103b) wants to spend a transaction created by Alice 103a. The user creates a spend transaction:

[0219]

[0220] Assume input B Unlock [Meta Script B], where input B Can contain the public key PK from Bob B Digital signature Sig B .

[0221] As HL-enabled nodes, they can choose one of the following options to verify the spend transaction, or more precisely, to verify the script" <input B >[Meta Script B]”:

[0222] 1. Use SDL to get the compiled locking script and run it using the native scripting engine <input B >[Expanded Meta Script B in Bitcoin opcodes]

[0223] 2. Run using SDL <input B >[Meta Script B] and get the same results as option 1.

[0224] Option 2 provides a computational advantage for HL-enabled nodes over HL-disabled nodes. Consider the case where there are two scripting engines SE1 and SE2, where

[0225] 1. Given the same input to the engine, both SE1 and SE2 produce the same results; and

[0226] 2. SE2 is more efficient than SE1 (given the same input, it takes less time to produce the result).

[0227] As a node, switching between SE1 and SE2 will not have any impact on the blockchain protocol.

[0228] Given the above reasons, a HL-enabled node may switch between a native script engine (eg, SE1) and a HL engine (eg, SE2) to optimize its script verification process.

[0229] As HL-enabled nodes, they can store transactions with compact lock scripts to save space. Without loss of generality, assume that the transaction is as shown in Table 10.

[0230]

[0231] Table 10: Storing compact transactions with secondary transaction IDs

[0232] Alternatively, a secondary identifier may be appended to the first output, e.g.

[0233] [smart contract]OP_FALSE OP_RETURN TxID 1-secondary >.

[0234] It should be noted that when expanded to native opcodes, a lock script [Bitcoin opcodes expandedfrom Meta Script B] can be several megabytes, while in its compact form (metascript), the lock script can be as small as a few bytes. When there are billions of such transactions in a block (roughly every 10 minutes), the storage space savings become significant.

[0235] Furthermore, by including a secondary transaction ID whose integrity is protected by a digital signature, the integrity of the compact locking script can be verified without compilation, assuming the corresponding signer is trustworthy.

[0236] Figure 6 The exemplary process of transaction generation and verification is shown. First, the transaction Tx1 is generated using the HL scripting language. Then, the HL scripting language is converted into the LL scripting language to generate Tx raw Then, based on Tx raw To generate a transaction identifier TxID1. The transaction identifier TxID1 and the HL transaction Tx1 are sent to the blockchain node 104. The node 104 receives the transaction identifier TxID1 and the HL transaction Tx1. The HL scripting language can be converted into the LL scripting language, and then the resulting transaction can be used to generate a transaction identifier TxID1′. In this optional process, the received transaction identifier and the generated transaction identifier are compared. If the two match, the node 104 continues to verify the transaction, and vice versa. However, it should be noted that the generation and comparison of the transaction identifier is optional and can be skipped. That is, the node 104 can directly perform transaction verification.

[0237] Sending TxID1 serves as an optional error checking mechanism that enables the node 104 to detect any discrepancies between the mapping (from CLS to ELS / from ELS to CLS) used by the transaction generator (e.g., Alice 103a) and the transaction verification node 104. However, alternative error checking mechanisms may also be used. Including TxID1 also allows the node 104 to quickly start mining operations (e.g., building a Merkle tree based on TxID1) while still running transaction mapping and verification.

[0238] Figure 7 Another exemplary process from generation to verification of a signature transaction is shown. This process is similar to Figure 6 The process is similar to the HL scripting language, but the process also includes an additional step: signing the transaction after converting the HL scripting language to the LL scripting language. The transaction identifier is based on the signed transaction. First, the transaction locking script is generated by the transaction engine function and written in the HL language. This outputs a transaction Tx with a compact locking script. 1-unsigned , the transaction has not yet been signed. Normally, the unlocking script in a transaction needs to sign the transaction. For a transaction to be signed, the HL function must be replaced with an equivalent set of LL functions. Tx 1-unsigned will be passed to the mapping module, which will replace the HL functions with native LL functions (e.g., opcodes). The mapping module receives Tx 1-unsignes And output Tx row-unsigned , which is passed to the signature module. The transaction signature module receives Tx raw-unsigned And output the signature transaction Tx raw .Tx raw Use to generate the transaction identifier TxID. raw Passed to the mapping module, which replaces the LL function with the HL function. Optionally, the sender then concatenates TxID with Tx1 and sends it to the blockchain. Conversely, this transaction can be sent on its own. Optionally, to check whether the mapping used by the receiver is the same as the one used by the sender, the receiver maps Tx1 to Tx raw ', generates TxID', and checks whether it is the same as TxID. If they are the same, the recipient can proceed to transaction verification. In this example, TxID is used as a parity check. It should also be noted that this verification of TxID is optional, and node 104 can directly perform transaction verification.

[0239] Figure 8 An exemplary flow of data when sending and verifying a transaction is shown. An HL-enabled transaction creator (e.g., Alice 103a) generates a transaction with a compact locking script. At this point, the transaction is not signed. The compact locking script is replaced with the extended script and then signed. The signed transaction is hashed to generate a transaction identifier. The extended locking script is replaced with the compact locking script and both are sent to the blockchain network 106 (the transaction identifier can be included in the transaction instead of as Figure 8 Cascading with transactions as described in ). A HL-enabled transaction verifier (e.g., node 104) receives the transaction and the transaction identifier. The compact locking script is replaced with the extended locking script, and the transaction is then optionally hashed to generate a candidate transaction identifier. In this option, the candidate transaction identifier is compared with the received transaction identifier; if they match, the verifier proceeds to verify whether the transaction is valid; if they do not match, the verifier discards the transaction. As an alternative, it may not be necessary for the HL-enabled node to verify that the transaction identifier is valid. In addition, the figure also shows a HL-disabled transaction verifier. If only a compact version of the transaction is received, the HL-disabled transaction verifier cannot verify the transaction. On the other hand, if an extended transaction is received, the HL-disabled transaction verifier can verify the transaction. After the transaction is posted on the blockchain, the HL-disabled verifier needs the compiled transaction to verify whether the transaction is valid.

[0240] 7. Messaging Protocol

[0241] Above about Figures 5 to 9 The description of the drawings describes a protocol for generating compact transactions and converting compact transactions into extended transactions. Some or all of the features described in conjunction with these drawings may be applied to Figures 10 to 13 Embodiment of the invention.

[0242] Fig.10 The protocol is summarized from the perspective of a CS-enabled node 104a receiving a transaction. As shown, the CS-enabled node 104a receives a blockchain transaction. If the blockchain transaction is a compact transaction, the compact transaction is processed in its compact form and verified to be valid. It should be noted that this may include converting the compact transaction to its extended (canonical) form. A compact transaction is a transaction with at least one compact output (i.e., an output that includes a compact script) and / or at least one input that references a compact output of a different transaction.

[0243] If the blockchain transaction is an extended transaction (i.e., written in a native low-level scripting language), the extended transaction is processed in its extended form and verified to be valid. This can be identified by checking whether there are explicit protocol flags or any implicit indicators (e.g., some HL functions (also known as meta-opcodes)) in the transaction. The explicit flag can be a predetermined, agreed transaction version number or a byte at the beginning of the locking script or unlocking script. The implicit indicator can be the format of the locking script. For example, if the locking script starts with a known HL function (e.g., MOP_LIBLOAD), the corresponding transaction can be identified as a compact transaction.

[0244] Fig.11 An exemplary script execution process is shown. The CS-enabled node 104a includes a script engine configured to process the script in a compact script form, which may involve expanding the compact script into an extended script. Fig.11 As shown, there are two options. One option is to execute the script in its compact script form, and the other option is to execute the script in its expanded script form.

[0245] Fig.12 Schematically illustrates the compatibility between the node 104a of enabling CS and the node 104b of disabling CS. The node 104a of enabling CS should only broadcast compact transactions to nodes that can handle compact transactions. The node 104a of enabling CS can receive transactions from both other nodes 104a of enabling CS and the node 104b of disabling CS. On the other hand, the node 104b of disabling CS does not have the ability to directly handle compact transactions (they need to be pre-converted into a standard script). When the node 104a of enabling CS sends a compact transaction to the node 104b of disabling CS, problems may occur. In fact, the node 104b of disabling CS cannot interpret the compact script. For example, the node disabling CS may not be able to use the compact script to verify that the transaction is valid (see below for more details), and finally reject the compact transaction.

[0246] Fig.13 Schematically illustrates a system 1300 for implementing an embodiment of the present invention. The system 1300 includes several CS-enabled nodes 104a and several CS-disabled nodes 104b. It should be understood that the system 1300 may include any number of CS-enabled nodes 104a and CS-disabled nodes 104b. In this example, the system also includes user Alice 103a.

[0247] A CS-enabled node 104a (hereinafter referred to as Charlie 104a for convenience) obtains a set of blockchain transactions. For example, one or more transactions may be sent from Alice 103a to Charlie 104a. Charlie 104a may receive one or more transactions from another user (e.g., Bob 103b). Additionally or alternatively, Charlie 104a may receive one or more transactions from other nodes 104. At least some of these transactions are compact transactions, i.e., transactions that include compact scripts.

[0248] At some point in time, Charlie 104a needs to share at least one of these compact transactions with other nodes, including other CS-enabled nodes 104a and CS-disabled nodes. Depending on the situation, Charlie 104a may need to send multiple (e.g., all) compact transactions with other nodes.

[0249] Given that the other CS-enabled nodes 104a can process the compact transaction, Charlie 104a transmits the compact transaction directly to the other CS-enabled nodes 104a, i.e., the compact transaction is sent in its compact form. The other CS-enabled nodes 104a may then execute the compact transaction in its compact form, or choose to expand the compact script of the compact transaction into an extended form of the compact transaction and then execute the extended script (e.g., see Fig.12 ).

[0250] On the other hand, given that the CS-disabled node 104b cannot process the compact transaction in its compact form, Charlie 104a must convert the compact transaction into its extended form and send the extended transaction to the CS-disabled node. As mentioned above, an extended transaction is a transaction that includes an extended form of a compact script instead of a compact script. An extended script only includes a low-level script, i.e., a native script of the blockchain.

[0251] Charlie 104a may choose to automatically send compact transactions to other CS-enabled nodes 104a, i.e., without being required to do so. Alternatively, Charlie 104a may only send compact transactions to CS-enabled nodes 104a that have requested compact transactions. Additionally or alternatively, Charlie 104a may automatically or in response to requests from those CS-disabled nodes send extended transactions to CS-disabled nodes 104b.

[0252] The compact transaction obtained by Charlie 104a may not have been published in block 151 of blockchain 150. In this case, Charlie 104a may publish a new block 151 including the compact transaction to blockchain 150. Publishing block 151 to the blockchain may include propagating block 151 to other nodes 104 for verification. Charlie 104a may send the compact transaction and the extended transaction to CS-enabled node 104a and CS-disabled node respectively before or after publishing block 151. In some cases, publishing block 151 is the same action as sending the compact transaction to CS-enabled node 104a.

[0253] The CS-enabled node 104a may request from Charlie 104a some or all of the compact transactions included in the block 151. For example, the CS-enabled node 104a may have received one or more of the compact transactions in the block 151. Similarly, after determining that it cannot process one or more of the compact transactions in the block 151, the CS-disabled node may send a request to Charlie 104a for extended versions of these transactions. Charlie 104a then sends the corresponding extended transactions to the CS-disabled node.

[0254] Each compact transaction is associated with a transaction identifier (TxID). The transaction identifier is based on an extended version of the compact transaction, i.e., the corresponding extended transaction. For example, the TxID can be a hash (e.g., a double hash) of the extended transaction. A discussion of TxIDs is provided further below. In some embodiments, Charlie 104a may first send the TxID associated with the compact transaction to a CS-enabled node and / or a CS-disabled node. Charlie 104a may publish the TxIDs instead of or in addition to sending them to the nodes. For example, the block 151 published by Charlie 104a may include the TxID. In some examples, the block 151 published by Charlie 104a may include the TxID of the compact transaction, but not the compact transaction itself.

[0255] Instead of sending or publishing the full TxID, Charlie 104a may send or publish a compact version of the TxID (e.g., the first n bytes of the TxID). For example, this may be the first four leading bytes of the TxID.

[0256] CS-enabled and / or CS-disabled nodes can use the TxID (or compact version) associated with a compact transaction to determine whether the node needs a compact transaction or a corresponding extended transaction, respectively. If a CS-enabled node 104a needs a compact transaction because it has not yet received a compact transaction, the CS-enabled node 104a requests a compact transaction from Charlie 104a. In response, Charlie 104a sends the requested compact transaction to the CS-enabled node. Similarly, if a CS-disabled node needs an extended form of a compact transaction because it cannot handle the compact form, the CS-disabled node requests an extended form of a compact transaction from Charlie 104a. In response, Charlie 104a sends the requested extended transaction to the CS-disabled node.

[0257] In some examples, a TxID or a compact version of a TxID ("Compact TxID") associated with a compact transaction may include an indication that the associated transaction is a compact transaction. This enables other nodes to quickly determine whether they need to request a compact version or an extended version of a transaction.

[0258] The indication may be an additional bit combined with the original TxID. That is, each TxID may have the same predetermined length (e.g., 256 bits). If a node receives a TxID with an additional bit (e.g., 257 bits in length), the node may interpret the TxID as being associated with a compact transaction. The same applies to compact TxIDs.

[0259] As another example, a TxID associated with a compact transaction can be embedded with a proof of work. That is, a portion of the original transaction (e.g., a random number) can be changed until the hash of the transaction produces a TxID that meets the target difficulty (e.g., a minimum number of leading zeros). If a node receives a TxID with a certain number of leading zeros, the node can interpret the TxID as being associated with a compact transaction. The same applies to compact TxIDs.

[0260] Instead of using TxID or compactTxID to indicate whether a transaction is a compact transaction, Charlie 104a can send a compact transaction to other nodes with a flag indicating that the transaction is a compact transaction. For example, several compact transactions can be grouped together and sent together with a flag.

[0261] Another option for determining whether a transaction is a compact transaction is by using an implicit indicator, as described above. Fig.11 discussed.

[0262] In some embodiments, Charlie 104a may determine during a peer discovery process whether a node is a CS-enabled node 104a or a CS-disabled node. The peer discovery process may involve a handshake process during which information about the node is exchanged. Alternatively, Charlie 104a may obtain the information from elsewhere (e.g., the blockchain itself or a publicly available source such as a web page).

[0263] Describes the main point of view of Charlie 104a, a CS-enabled node Fig.13 We will now briefly describe the process from the perspective of a node with CS disabled (called Denise for convenience). Fig.13 . For example, Denise obtains (e.g., receives) a compact transaction from Charlie 104a, a user, or from published block 151. Alternatively, Denise may obtain an indicator indicating that the transaction is a compact transaction. The transaction itself may or may not have been obtained. Denise determines that she cannot process the compact transaction or the transaction associated with the indicator. In response, Denise sends a request to Charlie 104a to obtain an extended version of the compact transaction. In some examples, Denise may first consider the transaction invalid before sending the request. For example, Denise may first attempt to process the transaction, which will cause Denise to consider the transaction invalid. Denise may then send the request. Charlie 104a then sends the corresponding extended transaction to Denise. Denise may then process the extended transaction (e.g., verify that the extended transaction is invalid), or store the extended transaction for later processing. As described above, the indicator may be a TxID associated with the compact transaction or part of the compact TxID, or a flag associated with the compact transaction.

[0264] Now for more specific examples.

[0265] Nodes that disable CS can only process specification scripts, while nodes 104a that enable CS can process both compact and specification scripts. Therefore, nodes 104a that enable CS need to know whether their neighbors are able to process compact transactions. Blockchain nodes can signal whether they are CS-enabled nodes 104a during the peer discovery process. New node instances and nodes that have been offline for a period of time must find other peers in the network. When a node starts, it connects to one or more known peers (e.g., provided as a static list). After the connection is created, the two nodes will use addr messages to exchange their neighbor lists. Typically, a connection between two nodes may involve a handshake process in which the two nodes can exchange some identification information. This information may include some or all of the following: nVersion, nLocalServer, nTime, addrYou, addrMe, subvert, and BestHeight. Specifically, the subver field (4 bytes) indicates the type of node software executed (e.g., v.1.0.6). Therefore, a node can also use this field to signal whether it is enabled to receive CS opcodes. For example, if the specification version is v1.0.6, a CS-enabled node can be v1.0.6cs or v1.0.6.1. This is efficient and easy to implement as it does not require any changes to the current handshake process.

[0266] A CS-enabled node 104a may adopt one of five strategies to broadcast compact transactions that can be set in the node software configuration file. These strategies are as follows:

[0267] 1. Preventive CS conversion (broadcast to everyone)

[0268] 2. On-demand CS conversion (broadcast to CS nodes, respond to everyone)

[0269] 3. No CS conversion (broadcast to CS nodes, respond to CS nodes)

[0270] 4. No CS conversion (no broadcast, respond to everyone)

[0271] 5. No CS conversion (no broadcast, respond to CS node)

[0272] Typically, the CS-enabled node 104a may choose to broadcast only the TxID, and if the receiving node does not have a transaction for that TxID, the receiving node may request the desired transaction data.

[0273] A CS-enabled node 104a configured to perform "preventive MS conversion" first transmits the compact transaction to other CS-enabled nodes (e.g., according to its subver). The compact transaction is then converted to its canonical form and transmitted to the canonical nodes. This approach is completely transparent to the canonical nodes, which never see the compact script and continue to exchange transactions with other nodes (which are all canonical nodes from their perspective).

[0274] A CS-enabled node 104a that is configured to transmit MS transactions "on demand" only transmits compact transactions to other CS-enabled nodes 104a (e.g., according to its subvert). When a CS-enabled node 104a publishes a block containing compact transactions, canonical nodes may find some transactions missing or invalid for them (unless they received the canonical version from a node using preventive CS conversion or from another canonical node). At this point, the canonical node requests the missing transactions from the network, and only at this point will the CS-enabled node 104a that is set to convert on demand transmit the canonical script. In other words, this type of CS-enabled node 104a will not actively propagate compact transactions to canonical nodes, but it will convert them to canonical transactions on demand after publishing a block.

[0275] This approach is not transparent to canonical nodes that cannot verify that compact transactions are valid and "mine" compact transactions. However, this configuration improves the efficiency of CS-enabled nodes 104a, which only broadcast the most valid version of each transaction and convert them to canonical form only as needed.

[0276] MS nodes configured for "no CS conversion" only transmit compact transactions to CS-enabled nodes 104a. They never convert compact transactions for canonical nodes. This scheme is designed for small players and low-bandwidth nodes (e.g., stores). They still broadcast canonical transactions to and from canonical nodes, but they may be slow when they have to propagate blocks because the canonical nodes will not be able to accept them (until another node converts the compact transaction for them). Eventually, canonical nodes may be disconnected from these nodes (because they appear to transmit invalid blocks or broadcast invalid transactions). This may reduce the connectivity of this type of node, so this type of node should be used when there is high connectivity with other CS-enabled nodes 104a that can broadcast blocks on its behalf. It is worth noting that if a CS-enabled node 104a deliberately or mistakenly sends a compact transaction to a canonical node, it will not cause any problems for the network or the receiving node itself. The canonical node will simply use the compact script to calculate the transaction ID and verify that it does not match the transmitted transaction ID. At this point, the canonical node will assume that there is an error in the creation or transmission of the transaction and will reject the transaction.

[0277] Blockchain nodes may choose to migrate to CS-enabled software because it offers clear advantages in terms of storage and bandwidth. In fact, it is faster for CS-enabled nodes 104a to publish and receive blocks with several compact transactions, which gives them a competitive advantage over canonical nodes (the sooner a block is received, the sooner mining of new blocks can begin). This is especially true for "on-demand conversion" nodes that perform conversions after a block is published, and "no CS conversion" nodes that simply transmit published blocks to other CS-enabled nodes 104a.

[0278] As block sizes increase, it is advantageous to transmit blocks in the fastest possible time. To this end, one option is to transmit only the transaction ID or even a compact version of it (e.g., only the first 6 bytes). In this case, it is very useful to know whether a transaction ID refers to a compact transaction. Since the only information being transmitted is the ID, this information may be embedded in it. One option to achieve this is to modify the transaction IDs, which can be achieved, for example, by adding PoW to these IDs (changing part of the transaction until a valid ID is found). For example, a compact transaction ID may have to start with "000" (with probability 1 / 4,096) or "0000" (with probability 1 / 65,536), or extra bits can be added to the ID. Another approach involves grouping compact transactions and then broadcasting the group using a special flag.

[0279] Identifying compact transactions may be useful because the specification software may decide to use a third-party preprocessing service to transform the compact transaction, rather than rejecting the compact transaction.

[0280] 8. Examples

[0281] This section provides three sets of examples that illustrate how the disclosed framework might work. The first set focuses on the practical and computational efficiency advantages of using function tables when converting from a highest-level (user-facing) language to a mid-level (meta-scripting) language. The second set focuses on the compactness of the meta-scripting language. The third set provides insight into some more complex scripts. The third set also illustrates how scripts written in a high-level language can be directly converted to a low-level native scripting language.

[0282] 8.1 Group 1 Examples:

[0283] This example shows how to convert a script written in a top-level language into a compact metascript using a function table. This example script reverses the characters of an input string.

[0284] Highest level language

[0285]

[0286] The highest level language is then compiled into a mid-level language, in which a function table and a variable table are referenced or created. The function table and the variable table are distributed and can be stored locally. In some examples, once created, the variable table is readable and writable, while the function table is only readable. As examples, the following items are provided:

[0287]

[0288]

[0289] There are two functions in this exemplary function table, with function IDs 0 and 1. The first function calculates the size of the input string, while the second function calls the first function and then reverses the string. The description of function 1 is as follows:

[0290] $0 refers to the first input to the script that has not yet been provided, which can be the item on the top of the stack. 0MOP_FN_CALL is the syntax for calling a function with function ID 0 in the function table. After $0 0MOP_FN_CALL is executed, the length of the input will remain on the top of the stack. 1OP_SUB subtracts 1 from the value on the top of the stack and leaves the result on the top of the stack. 0MOP_SET_VAR assigns the element on the top of the stack to the variable with index 0 in the variable table. The variable will be available for the rest of the execution. 0MOP_GET_VAR pushes the value of the variable with index 0 in the variable table to the top of the stack. This is the syntax for retrieving a variable from the variable table. MOP_LOOP OP_1OP_SPLIT MOP_END_BLOCK consumes the first value on the stack and loops the command multiple times between MOP_LOOP and MOP_END_BLOCK. After 0MOP_GET_VAR MOP_LOOP OP_1OP_SPLIT MOP_END_BLOCK is executed, the string will be split into one-byte substrings. Similarly, 0MOP_GET_VAR MOP_LOOP OP_SWAP OP_CAT MOP_END_BLOCK will swap the order of the substrings and concatenate them to form a string that is the reverse of the input string.

[0291] It should be noted that the variable table does not have to be filled with values ​​when it is created. The variable table acts as a placeholder for the function execution and can store and pass values ​​during execution.

[0292] The same result can be achieved using a "while" loop.

[0293]

[0294] There are two variables here, l and COUNTER. It is recommended that COUNTER can be a reserved variable with its default value. That is, COUNTER can be called directly in the metascript. When called in a "while" loop, the variable starts with a value of 0 and is incremented by 1 after each loop.

[0295] Now let's describe how the "while" loop works:

[0296] MOP_LOOP_IF COUNTER 0 MOP_GET_VARLESSTHAN MOP_END_BLOCK starts the loop if counter is less than the variable at index 0. counter is a reserved variable with its default value. That is, COUNTER can be called directly in the metascript. The variable implicitly counts the number of loops that have been executed and starts at 0 and increments by 1 each time. The execution exits the "while" loop when counter reaches the default value or the maximum value set by the high-level language, or when the condition is not met. In this case, the variable at index 0 is the length of the input string. In general, MOP_LOOP_IF can be followed by any condition and the condition ends with MOP_END_BLOCK. If the condition is met, OP_1OP_SPLIT is repeated. It should be noted that it is not included in the function table to indicate that there is an option here not to include every word defined in the high-level language. It is probably common practice to include it in the function table if a function is to be frequently referenced. MOP_END_BLOCK marks the end of the code to be repeated. After executing MOP_LOOP_IF COUNTER 1MOP_GET_VARLESSTHAN MOP_END_BLOCK OP_1OP_SPLIT MOP_END_BLOCK, the string will be split into one-byte substrings. Similarly, MOP_LOOP_IF COUNTER 1MOP_GET_VAR LESSTHAN MOP_END_BLOCK OP_SWAP OP_CAT MOP_END_BLOCK will swap the order of the substrings and concatenate them to form a string that is the reverse of the input string.

[0297] Intermediate language (metascript)

[0298] Assuming the string "I am fish" is fed into the reverse function, the metascript will look like this:

[0299] 'I am fish'1MOP_FN_CALL

[0300] The metascript is then embedded in the transaction (as a locking script). The transaction is transmitted and stored in the form of its metascript.

[0301] Metascripts can be executed directly using the metascript engine, as described in the function table section. MOP_FN_CALL 1 calls function 1 in the function table. "I am fish" is the input to this function. The output will be the reverse of the input string.

[0302] Additionally, the metascript can be extended to its native form to generate transaction IDs, verify signatures, or be executed using a native scripting engine given a table of functions.

[0303] When expanding this example script, it is assumed that the creator of the script knows the input (unlocking the script), or that the creator of the script sets a maximum counter for the loop in order to prevent an infinite loop.

[0304] Low-level languages ​​(e.g., Bitcoin opcodes)

[0305] When the metascript is expanded, all loops are unrolled and only native opcodes are allowed. As an example, there is the following native script corresponding to the aforementioned exemplary metascript.

[0306]

[0307] It should be noted that the size of the canonical script increases linearly with the size of the input string. However, the size of the metascript is almost constant and independent of the size of the input string. This proves that the metascript framework can significantly save storage space and bandwidth.

[0308] 8.2 Group 2 Examples:

[0309] The first example here also reverses the characters in the input string. This example shows how to implement the same function without using the described function table. In this example, the high-level reversal function is compiled into a metascript. For example, the compiler is configured to read the function "reverse()" and compile the corresponding metascript. As a specific example, the mapping of high-level functions to metascripts can be stored in a memory accessible to the compiler.

[0310] High-level languages ​​(i.e., user-oriented languages):

[0311]

[0312] 31 bytes when saved as a txt file (source code)

[0313] Intermediate Language (Metascript):

[0314] 8meta_loop one_split 8meta_loop swap_cat

[0315] 76 09 49 20 61 6d 20 66 69 73 68 08 c0 d1 8 c0 e2

[0316] For example, use c0 for meta_loop, d1 for one_split, and e2 for swap_cat.

[0317] It should be noted that "76 09" pushes 9 bytes of data to the top of the stack.

[0318] In the meta script, 2 (push data) + 9 (data) + 6 = 17 bytes

[0319] When compiled from a high-level language, the metascript gets from the compiler the number of loops needed to reverse the string. In this case, the number of loops is length of string - 1.

[0320] Low-level languages ​​(Bitcoin opcodes / native scripts):

[0321]

[0322] 2 (op_pushdata and data size) + 9 (data) + 32 = 43 bytes

[0323] If the function's inputs are not available at compile time, the loop count may also not be available. In this case, design the metascript to get the information from the unlocking script or assume a default maximum value. For example:

[0324] Locking script (function) in high-level language: reverse()

[0325] Locking scripts in meta scripts (functions): meta_var meta_assignVar meta_var meta_loopone_split meta_var meta_loop swap_cat

[0326] The unlocking script (the input to the function) can be 8.

[0327] "8meta_var meta_assignVar" assigns the value "8" to a variable named "meta_var" before being converted to Bitcoin opcodes (native script). After that assignment, whenever "meta_var" appears, the variable is replaced with "8". Thus, once the input is given, we have the same metascript as above. It should be noted that only 2 extra bytes are introduced for assigning the value to the variable.

[0328] In this example, the function finds the greatest common divisor (GCD) of two integers.

[0329] High-level languages:

[0330]

[0331] 17 bytes

[0332] Intermediate Language:

[0333]

[0334] 11 2a f0 78 c7 97 06 fa 7c 78 97 fb f1

[0335] 13 bytes

[0336] Low-level languages:

[0337]

[0338]

[0339] 49 bytes

[0340] With larger quantities, the savings become more significant.

[0341] Furthermore, when having complex functions like elliptic curve point addition and scalar multiplication, the size of the metascript (mid-level language) will be 10 bytes, while the size of the native script (low-level language) will be megabytes.

[0342] A brief description of how to assign values ​​to meta variables in a metascript is given. This section describes a mechanism for assigning values ​​to variables in a native script.

[0343] High-level languages:

[0344] var=5

[0345] return var+var

[0346] Intermediate Language:

[0347] 5var meta_assign var var op_add

[0348] Low-level languages:

[0349] 5OP_TOALTSTACK OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_FROMALTSTACKOP_DUP OP_TOALTSTACK OP_ADD

[0350] When converted to native script (e.g., Bitcoin opcodes), "5var meta_assign" becomes "5OP_TOALTSTACK" and assigns the value "5" to a variable named "var". After that assignment, whenever "var" appears, the variable is converted to "OP_FROMALTSTACK OP_DUP OP_TOALTSTACK". The ALT stack becomes a stack for storing all variables (as an ordered list).

[0351] 8.3 Group 3 Examples:

[0352] In the following example, an HL script is converted directly into an LL script, i.e. a scripting language with only two levels: high-level and low-level.

[0353] GCD is a function that takes two integers a and b as input and outputs GDC(a,b). This is implemented using the Euclidean algorithm, which is described as follows:

[0354] 1. Let a=x and b=y.

[0355] 2. Given x and y, use the division algorithm to write x=yq+r, 0≤r<|y|.

[0356] 3. If r = 0, stop and output y; this is the GCD of a and b.

[0357] 4. If r ≠ 0, replace (x,y) with (y,r). Go to step 2.

[0358] The above algorithm can be easily written and executed using a high-level programming language. However, it is not easy to run the Euclidean algorithm using Bitcoin opcode scripts. Since extended scripts do not allow loops, each loop must be written using repeated OP_IF statements.

[0359] The following script takes the top two numbers x, y in the main stack, where y is the top and leaves y, r in the stack, where x=yq+r.

[0360] OP_IFDUP OP_IF OP_TUCK OP_MOD OP_ENDIF

[0361] The algorithm can be written as

[0362]

[0363] The above example will find the GCD if the GCD of two positive integers can be calculated in 3 loops. If the input requires more loops, more IF statements must be written. This means that if Alice wants to run the algorithm, and she does not know the input in advance, she must define a maximum number of IF statements that is large enough to accommodate her input range. If she wants to set this maximum number to 100 or more, this will produce very large transactions in the compiled script.

[0364] In this example, Alice needs to specify the maximum number of iterations, and the SDL-enabled node will be able to generate her exact transaction in the extended script.

[0365] If the above algorithm is defined as a function / library function / the fourth word describes the following:

[0366] Initial state of the stack:

[0367] The final state of the stack: <r>,

[0368] ALT stack initial state: not used

[0369] ALT stack final status: unused

[0370] Calculation: a = qb + r, or r = a mod b

[0371] FUNCTION_1 - Get< / r> 、 ,return <r> <q>, where a=b*q+r

[0372] Initial state of the stack:< / q> < / r> / / At the top of the stack

[0373] The final state of the stack: <q>

[0374] ALT stack initial state: not used

[0375] ALT stack final state: <d> / / At the top of the ALT stack

[0376] OP_TUCK OP_2DUP OP_MOD OP_DUP OP_TOALTSTACK OP_SWAP OP_TOALTSTACK OP_SUB

[0377] OP_SWAP OP_DIV

[0378] The above can be written as an HL function in HL language as follows:

[0379] HL function qr(){TUCK 2DUP MOD DUP TAS SWAP TAS-SWAP / }

[0380] The HL scripting language can define HL functions and also write OP_CODES in a user-friendly and efficient way. In the above example, TUCK DUP SWAP is equivalent to OP_TUCK OP_DUP OP_SWAP, FAS and TAS are equivalent to OP_FROMALTSTACK and OP_TOALTSTACK, +-* / % is equivalent to OP_ADD OP_SUB OP_MUL OP_DIV and OP_MOD, and so on.

[0381] HL function qr() takes the first two values ​​on the main stack and returns the quotient and remainder, i.e. < / d> < / q> and And calculate <q>and <r>, where a=b*q+r* / .

[0382] FUNCTION_2 - a loop to calculate the parameter s of the extended Euclidean algorithm i =s i-2 -s i-1 q i and t i =t i-2 -t i-1 q i This example uses the initial value s i-2 ,t i-2 、s i-1 ,t i-1 ,q i Start stack. The algorithm starts with i=2, where s0=1, t0=0, s1=0, t1=1

[0383] Initial state of the stack: i-2 > <t i-2 > i-1 > <t i-1 > i > / / i > at the top of the stack

[0384] The final state of the stack: i-1 > <t i-1 > i > <t i >

[0385] ALT stack initial state: not used

[0386] ALT stack final status: unused

[0387] OP_DUP 3OP_PICK OP_MUL 5OP_ROLL OP_SWAP OP_SUB OP_SWAP

[0388] 2OP_PICK OP_MUL 4OP_ROLL OP_SWAP OP_SUB

[0389] The above content can be written in HL language as:

[0390] HL function st(){DUP 3PICK*5ROLL SWAP-SWAP 2PICK*4ROLL SWAP-}

[0391] The HL function st() computes the parameters s and t used in computing the extended Euclidean algorithm below.

[0392] ​​​​​​The following example shows how to implement the extended Euclidean algorithm.

[0393] This function takes< / r> < / q> , and calculate s n ,t n , gcd(a,b), where gcd(a,b)=s n a+t n b

[0394] Initial state of the stack: / / At the top of the stack, a>b, both are positive integers

[0395] The final state of the stack: n > <t n >gcd(a,b) / / gcd(a,b) is at the top of the stack

[0396] ALT stack initial state: not used

[0397] ALT stack final state:…

[0398]

[0399]

[0400] The HL function EEA is the Extended Euclidean Algorithm. In this example, the function runs the words qr() and st() 25 times in a loop:

[0401]

[0402] This is an example of HL script language code where a loop is used to repeat the function up to 25 times. The variable l can be set to more times simply by changing it. For example, l can be set to 100 times or 1000 times as required. The CLS size will not change, while the size of the corresponding ELS will be in megabytes.

[0403] 9. Further comments

[0404] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

[0405] For example, some of the embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of a blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 above can be replaced with reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes can share some or all of the characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 described above.

[0406] ​In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the functions described in creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0407] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that the node can perform at least one or part of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150, but not all of the functions. For example, on these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0408] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0409] It should be understood that the above embodiments are described by way of example only. In more general terms, a method, apparatus or program may be provided according to any one or more of the following statements.

[0410] Statement 1. A computer-implemented method for transmitting a blockchain transaction to a node of a blockchain network, wherein the blockchain network comprises one or more Compact Script (CS)-enabled nodes and one or more CS-disabled nodes, wherein each CS-enabled node is configured to process a compact transaction and each CS-disabled node is not configured to process a compact transaction, wherein a compact transaction is a blockchain transaction comprising: i) a CS written at least in part in a high-level (HL) scripting language and comprising one or more HL functions; and / or ii) inputs, the inputs referencing outputs comprising the CS, wherein when executed, each HL function is configured to perform operations equivalent to operations performed by one or more LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform operations equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a first CS-enabled node and comprises:

[0411] Get a compact transaction set (also known as a group of compact transactions);

[0412] transmitting one or more compact transactions in the set of compact transactions to at least one other CS-enabled node;

[0413] converting one or more compact transactions in the set of compact transactions into one or more corresponding extended transactions, wherein the converting comprises, for a given compact transaction, replacing the CS of the compact transaction with an equivalent ES; and,

[0414] The one or more extended transactions are transmitted to at least one CS-disabled node.

[0415] The LL scripting language is a native blockchain scripting language. CS can be written entirely in the HL scripting language. Alternatively, CS can be written partially in the HL scripting language and partially in another scripting language (e.g., the LL scripting language). One or both of the HL scripting language and the LL scripting language can be stack-based scripting languages.

[0416] Statement 2. The method according to statement 1 comprises: receiving a first request for one or more extended transactions corresponding to the one or more compact transactions from the at least one CS-disabled node, and wherein transmitting the one or more extended transactions to the at least one CS-disabled node is in response to: receiving the first request.

[0417] Statement 3. The method according to statement 1 or 2 includes: receiving a second request for the one or more compact transactions from the at least one CS-enabled node, and wherein transmitting the one or more compact transactions to the at least one CS-enabled node is in response to: receiving the second request.

[0418] Statement 4. The method according to any of the preceding statements, the method comprising: publishing a block to the blockchain network, wherein the block includes the compact transaction set.

[0419] Statement 5. The method of statement 4 as defined in statement 2, wherein said publishing of said block is performed prior to said receiving of said first request and said transmitting of said one or more extended transactions.

[0420] Statement 6. The method of statement 4 as defined by statement 3, wherein said publishing of said block is performed prior to said receiving of said second request and transmitting of said one or more compact transactions.

[0421] Statement 7. A method according to any one of statements 1 to 3, wherein each compact transaction is associated with a corresponding transaction identifier based on the corresponding extended transaction, and wherein the method includes: providing the corresponding transaction identifiers of the compact transaction set to the at least one CS-enabled node and / or the at least one CS-disabled node.

[0422] Statement 8. The method of statement 7 as defined in statement 2, wherein said providing said corresponding transaction identifier is performed prior to said receiving said first request and transmitting said one or more extended transactions.

[0423] Statement 9. The method of statement 7 as defined in statement 3, wherein said providing said corresponding transaction identifier is performed prior to said receiving said second request and transmitting said one or more compact transactions.

[0424] Statement 10. A method according to any one of statements 7 to 9, wherein providing the corresponding transaction identifier includes transmitting the corresponding transaction identifier to the at least one CS-enabled node and / or the at least one CS-disabled node.

[0425] Statement 11. A method according to any one of statements 7 to 10, wherein providing the corresponding transaction identifier includes publishing a block to the blockchain network, wherein the block includes the corresponding transaction identifiers of the compact transaction set, but does not include the compact transaction itself.

[0426] Statement 12. A method according to any one of Statements 7 to 11, wherein providing the corresponding transaction identifier includes providing a corresponding compact version of the corresponding transaction identifier.

[0427] Statement 13. The method of statement 12, wherein the corresponding compact version of the corresponding transaction identifier includes part but not all of the corresponding transaction identifier.

[0428] Statement 14. The method of any one of Statements 7 to 13, wherein the corresponding transaction identifier of the compact transaction includes an indication that the corresponding compact transaction is a compact transaction.

[0429] Statement 15. The method of statement 14, wherein the indication is an additional bit combined with the respective transaction identifier of the respective compact transaction.

[0430] Statement 16. The method of statement 15, wherein the indication is a minimum amount of proof of work embedded in the corresponding transaction identifier by changing a portion of the corresponding compact transaction.

[0431] Statement 17. The method of any preceding statement, wherein the one or more compact transactions are transmitted to the at least one other CS-enabled node along with a flag indicating that the one or more compact transactions are compact transactions.

[0432] Statement 18. The method of any preceding statement, the method comprising: receiving an indication from the at least one CS-enabled node that the at least one CS-enabled node is a CS-enabled node.

[0433] Statement 19. The method of statement 18, wherein said receiving said indication is performed during a handshake process.

[0434] Statement 20. The method of statement 18, comprising determining that the CS-disabled node is not a CS-enabled node based on not receiving an indication that the at least one CS-disabled node is a CS-enabled node.

[0435] Statement 21. A method according to any of the preceding statements, wherein obtaining the CS transaction set includes receiving at least one compact transaction from a user and / or receiving at least one compact transaction from different CS-enabled nodes.

[0436] Statement 22. A computer device, the computer device comprising:

[0437] a memory, the memory comprising one or more memory cells; and,

[0438] A processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to execute a method according to any one of statements 1 to 21 when executed on the processing device.

[0439] Statement 23. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 21.

[0440] Statement 24. A computer-implemented method for receiving a blockchain transaction from a node of a blockchain network, wherein the blockchain network comprises one or more compact script (CS)-enabled nodes and one or more CS-disabled nodes, wherein each CS-enabled node is configured to process compact transactions and each CS-disabled node is not configured to process compact transactions, wherein a compact transaction is i) a blockchain transaction comprising a CS, the CS being written at least in part in a high-level (HL) scripting language and comprising one or more HL functions; and / or ii) an input, the input referencing an output comprising the CS, wherein when executed, each HL function is configured to perform operations equivalent to operations performed by one or more low-level (LL) scripting languages, wherein the CS is configured to perform operations equivalent to extended scripts (ES) written in the LL scripting language, and wherein the method is performed by a CS-disabled node and comprises:

[0441] Obtaining a compact transaction, or an indication that a compact transaction is a compact transaction;

[0442] Determining, based on the acquired compact transaction or an indication thereof, that the CS-disabled node cannot process the compact transaction;

[0443] transmitting, to a CS-enabled node, a request for an extended transaction corresponding to the compact transaction; and,

[0444] The extended transaction is received from the CS-enabled node, wherein the extended transaction includes an ES of the CS equivalent to the compact transaction.

[0445] Statement 25. The method of statement 24, comprising: executing the ES of the extended transaction received from the CS-enabled node.

[0446] Statement 26. The method of statement 24 or 25, wherein the compact transaction or an indication thereof is obtained directly from the CS-enabled node.

[0447] Statement 27. A method according to any one of statements 24 to 26, wherein the compact transaction or an indication thereof is obtained from a published block of the blockchain.

[0448] Statement 28. A method according to any one of statements 24 to 27, wherein the indication is a transaction identifier associated with the compact transaction and may also be a flag associated with the compact transaction.

[0449] Statement 29. The method of statement 28, wherein obtaining the transaction identifier comprises obtaining a compact version of the transaction identifier.

[0450] Statement 30. A computer device, the computer device comprising:

[0451] a memory, the memory comprising one or more memory cells; and,

[0452] A processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to execute a method according to any one of statements 24 to 29 when executed on the processing device.

[0453] Clause 31. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform the method of any one of clauses 24 to 29. < / cls> < / els> < / pa>

Claims

1. A computer-implemented method for transmitting a blockchain transaction to a node of a blockchain network, wherein the blockchain network comprises one or more compact script (CS) enabled nodes and one or more CS disabled nodes, wherein each CS enabled node is configured to process a compact transaction and each CS disabled node is not configured to process a compact transaction, wherein a compact transaction is a blockchain transaction comprising: i) a CS written at least in part in a high-level (HL) scripting language and comprising one or more HL functions; and / or ii) inputs, the input references comprising outputs of the CS, wherein when executed, each HL function is configured to perform operations equivalent to operations performed by one or more LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform operations equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a first CS-enabled node and comprises: Get a compact transaction set; transmitting one or more compact transactions in the set of compact transactions to at least one other CS-enabled node; converting one or more compact transactions in the set of compact transactions into one or more corresponding extended transactions, wherein the converting comprises, for a given compact transaction, replacing the CS of the compact transaction with an equivalent ES; and The one or more extended transactions are transmitted to at least one CS-disabled node.

2. The method according to claim 1, comprising: A first request for the one or more extended transactions corresponding to the one or more compact transactions is received from the at least one CS-disabled node, and wherein the transmitting the one or more extended transactions to the at least one CS-disabled node is responsive to receiving the first request.

3. The method according to claim 1 or 2, comprising: A second request for the one or more compact transactions is received from the at least one CS-enabled node, and wherein transmitting the one or more compact transactions to the at least one CS-enabled node is responsive to receiving the second request.

4. A method according to any preceding claim, comprising: Publishing a block to the blockchain network, wherein the block includes the compact set of transactions.

5. The method of claim 4 as appended to claim 2, wherein said publishing of said block is performed before said receiving of said first request and transmitting said one or more extended transactions.

6. A method according to claim 4 as appended to claim 3, wherein said publishing of said block is performed before said receiving of said second request and transmitting said one or more compact transactions.

7. The method according to any one of claims 1 to 3, wherein each compact transaction is associated with a respective transaction identifier based on the corresponding extended transaction, and wherein the method comprises: The respective transaction identifiers of the compact set of transactions are provided to the at least one CS-enabled node and / or the at least one CS-disabled node.

8. A method according to claim 7 when appended to claim 2, wherein said providing said corresponding transaction identifier is performed before said receiving said first request and transmitting said one or more extended transactions.

9. A method according to claim 7 as appended to claim 3, wherein said providing said corresponding transaction identifier is performed before said receiving said second request and transmitting said one or more compact transactions.

10. The method according to any one of claims 7 to 9, wherein said providing said corresponding transaction identifier comprises transmitting said corresponding transaction identifier to said at least one CS-enabled node and / or said at least one CS-disabled node.

11. A method according to any one of claims 7 to 10, wherein providing the corresponding transaction identifier comprises publishing a block to the blockchain network, wherein the block includes the corresponding transaction identifiers of the compact transaction set but does not include the compact transaction itself.

12. The method according to any one of claims 7 to 11, wherein said providing said corresponding transaction identifier comprises providing a corresponding compact version of said corresponding transaction identifier.

13. The method of claim 12, wherein the respective compact version of the respective transaction identifier comprises part but not all of the respective transaction identifier.

14. The method according to any one of claims 7 to 13, wherein the respective transaction identifier of the compact transaction comprises an indication that the respective compact transaction is a compact transaction.

15. The method of claim 14, wherein the indication is an additional bit combined with the respective transaction identifier of the respective compact transaction.

16. The method of claim 15, wherein the indication is a minimum amount of proof of work embedded in the corresponding transaction identifier by changing a portion of the corresponding compact transaction.

17. A method according to any preceding claim, wherein the one or more compact transactions are transmitted to the at least one other CS-enabled node together with a flag indicating that the one or more compact transactions are compact transactions.

18. A method according to any preceding claim, comprising: An indication is received from the at least one CS enabled node that the at least one CS enabled node is a CS enabled node.

19. The method of claim 18, wherein said receiving said indication is performed during a handshake procedure.

20. The method according to claim 18, comprising: It is determined that the CS-disabled node is not a CS-enabled node based on not receiving an indication that the at least one CS-disabled node is a CS-enabled node.

21. The method according to any of the preceding claims, wherein said obtaining said set of CS transactions comprises receiving at least one compact transaction from a user and / or receiving at least one compact transaction from a different CS-enabled node.

22. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores a code configured to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 21 when executed on the processing device.

23. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 21.

24. A computer-implemented method for receiving a blockchain transaction from a node of a blockchain network, wherein the blockchain network comprises one or more compact script (CS) enabled nodes and one or more CS disabled nodes, wherein each CS enabled node is configured to process a compact transaction and each CS disabled node is not configured to process a compact transaction, wherein a compact transaction is i) a blockchain transaction comprising a CS written at least in part in a high level (HL) scripting language and comprising one or more HL functions; and / or ii) inputs, the input references comprising outputs of the CS, wherein when executed, each HL function is configured to perform operations equivalent to operations performed by one or more LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform operations equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a node with the CS disabled and comprises: Obtaining a compact transaction, or an indication that a compact transaction is a compact transaction; Determining, based on the acquired compact transaction or an indication thereof, that the CS-disabled node cannot process the compact transaction; transmitting, to a CS-enabled node, a request for an extended transaction corresponding to the compact transaction; and The extended transaction is received from the CS-enabled node, wherein the extended transaction includes an ES of the CS equivalent to the compact transaction.

25. The method according to claim 24, comprising: The ES executes the extended transaction received from the CS-enabled node.

26. A method according to claim 24 or 25, wherein the compact transaction or an indication thereof is obtained directly from the CS-enabled node.

27. A method according to any one of claims 24 to 26, wherein the compact transaction or an indication thereof is obtained from a published block of the blockchain.

28. The method according to any one of claims 24 to 27, wherein the indication is a transaction identifier associated with the compact transaction, or may be a flag associated with the compact transaction.

29. The method of claim 28, wherein said obtaining the transaction identifier comprises obtaining a compact version of the transaction identifier.

30. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, and the code is configured to execute the method according to any one of claims 24 to 29 when executed on the processing device.

31. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method of any one of claims 24 to 29.

Images