Messaging Protocol for Compact Script Transactions

Abstract

A computer-implemented method of sending blockchain transactions to nodes of a blockchain network, wherein a compact transaction is a blockchain transaction that i) is at least partially described in a high-level (HL) scripting language and includes one or more HL functions, and / or ii) includes an input that references an output that includes a CS, and the CS is configured to perform an operation equivalent to a deployed script (ES) written in a low-level (LL) scripting language, the method comprising the steps of obtaining a set of compact transactions, sending one or more of the set of compact transactions to at least one other CS-capable node, converting one or more of the set of compact transactions into one or more respective deployed transactions, the step of converting comprising replacing the CS of a given compact transaction with an equivalent ES for that compact transaction, and sending the one or more deployed transactions to at least one CS-incapable node.

Description

Technical Field

[0001] The present disclosure relates to a method for sending blockchain transactions to nodes in a blockchain network.

Background Art

[0002] A blockchain refers to a form of a distributed data structure, and replicated copies of the blockchain are maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and widely publicized. A blockchain comprises a chain of data blocks, and each block comprises one or more transactions. Each transaction other than a so-called "coinbase transaction" refers to a preceding transaction in a sequence that can span one or more blocks that return to one or more coinbase transactions. The coinbase transaction will be further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining", which involves competing for each of a plurality of nodes to perform a "proof-of-work", i.e., solving a cryptographic puzzle based on a defined set representation of the ordered and verified pending transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be removed at some nodes, and the disclosure of a block can be realized only through the disclosure of a mere block header.

[0003] Transactions within a blockchain can be used for one or more of the purposes of transferring digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in chronological order. The blockchain can also be utilized to layer additional functionality on top of the blockchain. For example, the blockchain protocol may be able to store an index of additional user data or data within a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and thus, increasingly complex data can be incorporated. For example, this can be used to store electronic documents on the blockchain or to store audio or video data.

[0004] Nodes in a blockchain network (often referred to as "miners") perform the registration and verification process of distributed transactions, which will be described in detail later. In summary, during this process, the nodes verify the transactions and insert the transactions into a block template that attempts to identify a valid proof-of-work solution. When a valid solution is found, a new block is propagated to other nodes in the network, so that each node can record the new block in the blockchain. To record a transaction in the blockchain, a user (such as a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The node that receives the transaction may compete to find a proof-of-work solution that incorporates the verified transaction into a new block. Each node is configured to enforce the same node protocol that includes one or more conditions for validating the transaction. Invalid transactions are not propagated and are not incorporated into the block. Assuming that a transaction is verified and thereby accepted on the blockchain, the transaction (including user data) is registered and indexed at each of the nodes within the blockchain network as an immutable public record.

[0005] The node that solves the proof-of-work puzzle to create the latest block is usually rewarded with a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., a large number of tokens. The detection and rejection of invalid transactions are enforced by the actions of competing nodes that function as agents of the network and are encouraged to report and block fraudulent behavior. Since information is widely publicized, users can continuously audit the performance of the nodes. By simply publishing the block header, participants can ensure the continuous integrity of the blockchain.

[0006] In an "output-based" model (also called a UTXO-based model), the data structure of a given transaction consists of one or more inputs and one or more outputs. A spendable output comprises an element that specifies the amount of digital assets derived from the sequence of the transaction in progress. A spendable output may also be referred to as a UTXO ("unspent transaction output"). An output may further comprise a lock script that specifies conditions for the exchange of future outputs. A lock script is a predicate that defines the conditions necessary to verify and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a previous transaction and may further comprise an unlocking script to unlock the lock of the indicated output's lock script. Thus, considering a pair of transactions, they are referred to as the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output that specifies the amount of digital assets and a lock script that defines one or more conditions for unlocking the lock of the output. The second target transaction comprises at least one input that comprises a pointer to the output of the first transaction and an unlocking script for unlocking the lock of the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the criteria for validity applied to each node is that the unlock script satisfies all of the one or more conditions defined in the lock script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. A node that determines that the target transaction is invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but for registering an invalid transaction) or include it in a new block for recording on the blockchain.

Prior Art Documents

Patent Documents

[0008]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0009] Blockchains typically use a scripting language to set lock conditions that lock specific outputs of a transaction. Similarly, the corresponding unlock conditions are described in the same scripting language. The scripting language usually consists of data (such as public keys and digital signatures, etc.) and functions that operate on that data. This scripting language may be called a low-level scripting language or a native scripting language. As a specific example, the native scripting language of the Bitcoin blockchain is known as Script. In Script, functions are known as "operation codes" abbreviated as "opcodes".

[0010] Transactions that include a script are transmitted between the generating side (e.g., a user or a machine) and the nodes of the network for transaction verification. Depending on the use case, the transaction can also be sent off-chain, for example, from user to user or from machine to machine. Further, the transaction is propagated throughout the blockchain network by the nodes themselves. Further, at least some nodes need to (or choose to at least) store the transaction as part of the blockchain.

[0011] As the use of blockchain technology continues to increase, it is necessary to reduce the bandwidth and storage requirements for transmitting and storing transactions, respectively. This is generally true for all blockchains. In some blockchains, there are restrictions on the size of the transaction, the size of the script within the transaction, and the size of the block. In contrast, in at least one blockchain (e.g., Bitcoin SV), there is no limit on the script size of the transaction and no limit on the block size. This enables the construction of complex lock scripts (such as smart contracts) that can be quite large. This also allows blockchain nodes to build and publish large blocks that need to be stored. Therefore, when transmitting and storing a transaction as part of this particular blockchain, the need to save bandwidth and storage is even more heightened.

Means for Solving the Problem

[0012] Previously, lock scripts and unlock scripts were written (i.e., expressed or represented) in a low-level, i.e., native, scripting language. Transactions containing these scripts are sent to the blockchain network and, if valid, are stored on the blockchain. Now, instead of writing scripts (lock or unlock) in a low-level scripting language, it is possible to write scripts in a high-level scripting language. Similar to low-level languages, high-level languages have 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 usually require multiple low-level functions. As a result, scripts written in a high-level language are more compact (i.e., smaller in size) compared to equivalent lock scripts written in a low-level language.

[0013] Since scripts written in a high-level language have a compact nature compared to scripts written in a native low-level language, they are called "compact scripts", and the native low-level language is now called the "expanded script". For example, lock scripts and unlock scripts written in a high-level language are called "compact locking scripts" and "compact unlocking scripts", respectively.

[0014] Note that a reference to a script "written" in a particular programming language can be interpreted to mean that the script is "represented" or "expressed" in that programming language. Thus, unless otherwise required by context, the reference "written" may be replaced with "represented" or "expressed".

[0015] Complex locking or unlocking conditions that typically require large deployment scripts (large in the sense of many low-level functions) can now be written as smaller, more compact scripts using high-level languages. Thus, the bandwidth and storage requirements for transactions that include compact scripts are lower than those for transactions that include deployment scripts.

[0016] Take the Bitcoin SV blockchain as a specific example. Since there is no limit on block size, a single block can contain billions of transactions. Since there is no limit on transaction size, each transaction can contain millions of low-level functions (i.e., opcodes). If each opcode is one byte in size, each of those transactions will be on the order of several megabytes. As a result, bandwidth issues occur both when sending transactions to the blockchain network and when propagating transactions and blocks across the network. Nodes also face storage burdens when storing the blockchain. A single high-level function can be configured to perform the same operations as millions of low-level functions. Thus, if each transaction is written using a high-level language, the size of the transaction will be on the order of a few hundred bytes, thus saving significantly on bandwidth and storage. This is also important as blockchain technology continues to expand.

[0017] The following is an example that helps to explain how storage and bandwidth savings can be achieved using the described techniques. A single high-level function Z can perform the same operation as three low-level functions ABC. To send 10 transactions with function ABC to the blockchain, 30 "characters", i.e., the cost of storage units, are required. Using a high-level scripting language, it costs 10 characters to send 10 transactions with the equivalent function Z to the blockchain. Since it costs 5 characters to store the mapping of Z=ABC on the chain, the total is 15 characters. Each transaction can be expanded from Z to ABC using the mapping.

[0018] Native blockchain scripts can be thought of as assembly language. For example, the scripting language has approximately 100 opcodes. Writing programs in assembly language is a laborious task 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 due to their compactness and readability. The resulting code is then converted into assembly language that can be read by the computer. This application recognizes that the same approach can be used for blockchain scripts by utilizing a high-level scripting language. This high-level language may include some or all of the low-level functions of the native scripting language, as well as new high-level functions, or may include only high-level functions completely independent of such functions.

[0019] As described below, transactions that currently use large scripts can now be propagated and stored in a more compact form. Further, when executing blockchain scripts, nodes can choose the most efficient implementation form to execute that achieves the same result as a list of corresponding low-level functions, such as opcodes. The most important thing is that this is achieved without changing the native blockchain protocol.

[0020] 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 is smaller than the corresponding LL function, thus enabling bandwidth and storage savings.

[0021] In some embodiments, the HL language may be an intermediate-level (IL) language between a higher-level language (i.e., a second-layer high-level language) and the LL language. This higher-level language is a user-facing (UF) language, i.e., a language in which a user writes scripts. A user (or another 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. The intermediate language is still a high-level language compared to the LL language. The user-facing language may be a human-readable language, making it user-friendly and enabling the user to more easily write scripts equivalent to complex scripts in the LL language. Java source code (user-facing), Java bytecode (intermediate), and machine-readable code (low-level) can be used to illustrate the user-facing language, intermediate-level language, and low-level language. Java source code is compiled into Java bytecode, which is then deployed into machine-readable code. Similarly, the user-facing language may be compiled into the intermediate-level language, which can then be deployed into the low-level language.

[0022] In some implementations, the highest-level language (or a script written in the highest-level language that is the user-facing language) may be more compact than a script written in the intermediate-level language. The advantage of introducing the intermediate-level language is savings in computational effort when deploying to the low-level language. That is, instead of directly deploying from the highest level to the low level, the blockchain node only needs to deploy from the intermediate-level language to the low-level language. This savings in computational effort further reduces the burden on the blockchain node.

[0023] Examples of protocols for generating and propagating transactions represented in a compact scripting language (i.e., a scripting language that is higher level than a low-level native scripting language) are described in UK Patent No. 2019748.9 (GB2019748.9). UK Patent No. 2019748.9 provides an efficient way to encode native opcodes in a compressed (i.e., compact) form called a compact script. This enables complex lock scripts to be expressed in a user-friendly way while maintaining the security of the blockchain. Blockchain nodes that use the techniques described in UK Patent No. 2019748.9, or equivalent techniques, can gain significant benefits such as improved efficiency in computing and substantial reduction in bandwidth and storage requirements.

[0024] Of course, unless such a protocol is adopted by all blockchain nodes, the blockchain network will consist of some nodes configured to process transactions with compact scripts and some nodes not configured to process such transactions. Further, even if ultimately all nodes adopt the protocol, there will at least be an initial period during which only some, and not all, nodes adopt the protocol and the system is configured to process compact script transactions.

[0025] A transaction having at least one script (i.e., lock or unlock) represented as a compact script is hereinafter referred to as a compact transaction. In some places, it may also be referred to as a transaction in its metascript (MS) form. A transaction comprising a script represented by an opcode (or other low-level function) is called an expanded transaction. This may also be referred to as a transaction in its normal form in some cases. Note that all compact transactions have a corresponding normal form, but normal transactions do not necessarily have a compact form. A compact script (CS) capable blockchain node is a node that can process (e.g., verify) compact transactions. This may also be abbreviated as an MS node. Conversely, a compact script incapable node is a node that cannot process compact transactions. This may also be referred to as a normal node.

[0026] Compact transactions may be rejected (e.g., invalidated) by CS incapable nodes. This is because those nodes cannot process, and thus verify, compact transactions. This propagates through the blockchain network, causing problems as transactions published in blocks need to be verified by other nodes, which is a fundamental requirement of most blockchains. Therefore, if CS incapable nodes cannot verify a transaction, it affects the entire network. Thus, it is necessary to address this issue.

[0027] According to one aspect disclosed in this specification, a computer-implemented method for sending blockchain transactions to nodes of a blockchain network is provided, the blockchain network comprising one or more compact script (CS)-capable nodes and one or more CS-incapable nodes, each CS-capable node being configured to process compact transactions, each CS-incapable node not being configured to process compact transactions, a compact transaction being a blockchain transaction comprising i) a CS that is at least partially described in a high-level (HL) script language and comprises one or more HL functions, and / or ii) an input that references an output comprising a CS, and when executed, each HL function being configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of a LL script language, the CS being configured to perform an operation equivalent to an operation performed by an expanded script (ES) described in the LL script language, the method being implemented by a first CS-capable node and comprising the steps of obtaining a set of compact transactions, sending one or more of the set of compact transactions to at least one other CS-capable node, converting one or more of the set of compact transactions into one or more respective expanded transactions, the step of converting comprising replacing the CS of a given compact transaction with an equivalent ES, and sending the one or more expanded transactions to at least one CS-incapable node.

[0028] According to one aspect disclosed in this specification, a computer-implemented method is provided for receiving a blockchain transaction from a node of a blockchain network, the blockchain network comprising one or more compact script (CS)-capable nodes and one or more CS-incapable nodes, each CS-capable node being configured to process a compact transaction, each CS-incapable node not being configured to process a compact transaction, a compact transaction being a blockchain transaction that i) is at least partially described in a high-level (HL) script language and comprises one or more HL functions and / or ii) comprises an input that references an output that comprises a CS, and when executed, each HL function is configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of a low-level (LL) script language, the CS being configured to perform an operation equivalent to an operation performed by an expanded script (ES) described in the LL script language, the method being implemented by a CS-incapable node and comprising the steps of obtaining a compact transaction, or an indication that the compact transaction is a compact transaction; determining, based on the obtained compact transaction or indication thereof, that the compact transaction cannot be processed by the CS-incapable node; sending a request for an expanded transaction corresponding to the compact transaction to a CS-capable node; and receiving an expanded transaction from the CS-capable node, the expanded transaction comprising an ES equivalent to the CS of the compact transaction.

[0029] A CS-capable node obtains a compact transaction, for example, from an end user. The CS-capable node directly sends some or all of the compact transaction to other CS-capable nodes, that is, in compact form. This saves bandwidth compared to sending the compact transaction in the corresponding expanded form.

[0030] The CS-enabled nodes also convert some or all of the compact transactions into an expanded form. That is, the compact script of a given compact transaction is replaced with the corresponding expanded script, i.e., a script fully described in a low-level scripting language. The expanded transaction is then sent to the CS-disabled nodes, which can then process (e.g., verify) the transaction according to the conventional processing protocol.

[0031] In some embodiments, when a CS-enabled node receives a compact transaction (e.g., from a user or another CS-enabled node), i.e., automatically, it may send the compact transaction and / or the expanded transaction to an appropriate node. Alternatively, the compact transaction and / or the expanded transaction may be sent to an appropriate node upon request. Thereby, the number of transactions transmitted over the blockchain network is reduced because, for example, they are only sent to those nodes that need the transaction because they have not yet confirmed the transactions on the network or have not received the transactions from other nodes.

[0032] To aid in the understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, the accompanying drawings are referred to by way of example only.

Brief Description of the Drawings

[0033]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

[0034] 1. Overview of the Exemplary System FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet switching network 101, typically a wide area internetwork such as the Internet. The packet switching network 101 comprises a plurality of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet switching network 101. Although not shown, the blockchain nodes 104 may be arranged as an almost complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0035] Each blockchain node 104 comprises a peer computer device, and different nodes among the nodes 104 belong to different peers. Each blockchain node 104 comprises a processing device comprising one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs). Each node also comprises a memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory media, such as magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memories, or EEPROMs, and / or optical media such as optical disk drives, using one or more memory units.

[0036] The blockchain 150 comprises a chain of data blocks 151, and a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 within the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block headers (described below) of each block 151. Each block 151 within the chain comprises one or more transactions 152, and in this context, a transaction refers to a certain type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one specific transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing a quantity of digital assets as an asset, and an example is a user 103 whose output is cryptographically locked (unlocking it requires the user's signature or other solution for redemption or use). Each input refers to an output of a preceding transaction 152, thereby linking the transactions.

[0037] Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than the coinbase transaction) includes a pointer back to the previous transaction to define an order into the sequence of transactions (note that the sequence of transactions 152 can branch). The chain of blocks 151 traces back to the genesis block (Gb) 153 that was the first block in the chain. One or more of the initial original transactions 152 in the chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0038] Each of the blockchain nodes 104 is configured to transfer a transaction 152 to other blockchain nodes 104, thereby causing the transaction 152 to propagate across the network 106. Each blockchain node 104 is configured to create a block 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 that are waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "memory pool (mempool)". This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 is obligated to accept as valid and not accept any other transaction that attempts to use the same output.

[0039] In a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, where this output is to be redeemed or "spent" in the current transaction 152j. Generally, the preceding transaction can be any transaction within the ordered set 154 or any block 151. The preceding transaction 152i must exist and be verified for the current transaction to be valid, but it does not necessarily have to exist even at the time the current transaction 152j is created or when it is sent to the network 106. Thus, "preceding" as used herein refers to the predecessor in the logical sequence linked by the pointer and does not necessarily refer to the time of creation or transmission in chronological order, and thus does not necessarily preclude the transactions 152i, 152j from being created or sent out of order (see the following explanation regarding orphan transactions). The preceding transaction 152i can be referred to as the antecedent transaction or the predecessor transaction as well.

[0040] The input of the current transaction 152j also comprises an input authorization, for example, the signature of user 103a whose output of the preceding transaction 152i is locked. Next, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, transaction 152 can have multiple outputs for splitting the input amount among multiple users or entities (one of which can be the original user or entity 103a in order to give change). In some cases, the transaction can also have multiple inputs to consolidate amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0041] According to an output-based transaction protocol such as Bitcoin, when a party 103 such as an individual user or an organization wants to create a new transaction 152j (either manually or by an automated process adopted by the party), the creating party sends the new transaction from its computer terminal 102 to the recipient. The creating party or the recipient will ultimately send this transaction to one or more blockchain nodes 104 of the network 106 (today, typically servers or data centers, but in principle other user terminals may also be used). Also, it cannot be excluded that the party 103 creating the new transaction 152j directly sends the transaction to one or more of the blockchain nodes 104 and in some cases does not send it 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 of the blockchain nodes 104. The blockchain node protocol usually requires the blockchain node 104 to check that the cryptographic signature within the new transaction 152j matches the expected signature that depends on the previous transaction 152i within the sequence of ordered transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other permission of the party 103 included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i assigned by the new transaction, and this condition usually at least includes checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the lock of the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be at least partially defined by a script included in the output of the previous transaction 152i. Alternatively, it may be simply fixed by the blockchain node protocol alone or by a combination of these.In any case, if the new transaction 152j is valid, the blockchain node 104 transfers it to one or more other blockchain nodes 104 within the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and thus transfer the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of blockchain nodes 104.

[0042] In an output-based model, the definition of whether a given output (e.g., UTXO) is assigned (e.g., used) is, according to the blockchain node protocol, whether that output has yet been validly redeemed by the input of another subsequent transaction 152j. Another condition for a transaction to be valid is that the output of the preceding transaction 152i attempting to redeem it has not yet been redeemed by another transaction. Similarly, if not valid, the transaction 152j is not propagated nor recorded on the blockchain 150 (unless flagged as invalid and propagated for warning). This prevents double-spending where a trader attempts to assign the output of the same transaction multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Here too, since the transaction order is defined, the account balance is always in a single defined state.

[0043] In addition to validating transactions, blockchain node 104 also competes to first create a block of transactions in a process generally called mining, which is supported by "proof of work". At blockchain node 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in the blocks 151 recorded on blockchain 150. The blockchain node then competes to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the concatenated and hashed representation of the ordered pool of transactions 154 with the nonce pending, the output of the hash meets a predefined condition. For example, the predefined condition may be that the output of the hash has a predefined number of leading zeros. It should be noted that this is only one specific type of proof of work puzzle and other types are not excluded. The characteristic of a hash function is that it has an output that is unpredictable for its input. Therefore, this search can only be performed by brute force and thus consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0044] The first blockchain node 104 to solve the puzzle publishes it to the network 106 and provides the solution as a proof that can be easily checked by other blockchain nodes 104 within the network. (Given a solution to a hash, it is easy to check whether the output of the hash meets the condition). The first blockchain node 104 propagates the block until a threshold consensus of other nodes that accept the block and enforce the protocol rules. Then, the ordered set of transactions 154 will be recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The significant amount of effort, for example in the form of hashes, required to create a proof-of-work solution signals the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if the same output has been assigned to a previously verified transaction, which is also called double spending. Once created, the block 151 is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106 and cannot be modified. Also, the block pointer 155 imposes a sequential order on the blocks 151. Since the transactions 152 are recorded in the ordered blocks of each blockchain node 104 within the network 106, this provides an immutable public ledger of the transactions.

[0045] The different blockchain nodes 104 that are constantly competing to solve the puzzle may always be acting based on different snapshots of the pool 154 of unpublished transactions, depending on when they started searching for a solution or the order in which the transactions were received. It should be noted that no matter who solves each puzzle first, the current pool 154 of unpublished transactions is updated by first defining which transactions 152 are included in the next new block 151n in what order. Then, the blockchain nodes 104 continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any potential "forks" that may occur, where a fork is when two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate between the nodes 104. That is, the longest growing fork branch becomes the final blockchain 150. It should be noted that this should not affect the users or agents of the network because the same transactions appear in both forks.

[0046] According to the Bitcoin blockchain (and most other blockchains), in contrast to a transaction between agents or users that transfers a certain amount of digital assets from one agent or user to another, a node that successfully constructs a new block 104 is given the ability to newly allocate an additional amount of incoming digital assets in a new special type of transaction that distributes an additional regulated amount of digital assets. This special type of transaction is usually called a "coinbase transaction", but may also be called a "genesis transaction" or a "generation transaction". This usually forms the first transaction of a new block 151n. Proof of work notifies the node constructing the new block of its intention to follow the protocol rules and enables this special transaction to be redeemed later. The rules of the blockchain protocol may require a maturity period, such as 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs in order to give further reward to the blockchain node 104 that created the block 151n in which the transaction was published. This fee is usually called a "transaction fee", which will be explained later.

[0047] Due to the resources involved in verifying and publishing transactions, usually each of at least the blockchain nodes 104 takes the form of a server comprising one or more physical server units or in the form of an entire data center. However, in principle, any given blockchain node 104 can take the form of a networked group of user terminals or user terminals together.

[0048] The memory of each blockchain node 104 stores software configured to perform respective roles according to the blockchain node protocol and to be executed on the processing device of the blockchain node 104 to process the transaction 152. It will be understood that any action attributed to the blockchain node 104 herein may be performed by software executed on the processing device of each computer device. The node software may be implemented in one or more applications in a lower layer such as an application layer, an operating system layer or a protocol layer, or any combination thereof.

[0049] The network 101 is also connected to each computer device 102 of a plurality of parties 103 that play the role of consuming users. These users can interact with the blockchain network 106 but do not participate in transaction verification or block construction. Some of these users or agents 103 may function as senders and receivers in a transaction. Other users can interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may function 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).

[0050] Some or all of the parties 103 may be connected as part of a network that is overlaid on a different network, such as the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 exist and may participate in the system 100, but for the sake of simplicity they are not shown. Each party 103 may be an individual or an organization. By way of pure example, in this specification the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference to Alice or Bob in this specification may be replaced with "first party" and "second party", respectively.

[0051] The computer device 102 of each party 103 includes one or more processors, such as a processor, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs, each processing device. The computer device 102 of each party 103 further includes a memory, i.e., a computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory media, such as magnetic media like hard disks, SSDs, flash memories, or electronic media like EEPROMs, and / or one or more memory units using optical media like optical disk drives. The memory on the computer device 102 of each party 103 stores software that includes respective instances of at least one client application 105 configured to be executed on the processing device. It will be understood that any action attributable to a given party 103 herein may be performed using software executed on the processing device of the respective 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, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via the user terminal.

[0052] The client application 105 may first be provided to the computer device 102 of any party 103 on a suitable computer-readable storage medium, such as downloaded from a server or provided in a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or a removable storage device such as a removable optical drive.

[0053] The client application 105 comprises at least a "wallet" function. This has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign) a transaction 152, send it to one or more Bitcoin nodes 104, and then have it propagated across the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that the party currently owns. In an output-based system, this second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to that party.

[0054] Note: Although the various client functions may be described as integrated into a given client application 105, this is not necessarily limiting, and instead any client function described herein may instead be implemented in a suite of two or more separate applications, e.g., interfacing via an API or one being a plugin to the other. More generally, client functions can be implemented in the application layer, a lower layer such as an operating system, or any combination thereof. What follows is described with respect to the client application 105, but it will be understood that this is not limiting.

[0055] 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 enables the wallet function of the client 105 to send a transaction 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 about transactions for which each party 103 is the recipient (or, in an embodiment, since the blockchain 150 is a public facility that provides trustworthiness in transactions through its partial public visibility, actually inspects the transactions of other parties within the blockchain 150). The wallet function on each computer device 102 is configured to formulate and send a transaction 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to verify a transaction 152 according to a blockchain node protocol and is configured to transfer it to propagate the transaction 152 across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol progresses with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 within the blockchain 150. The same node protocol is used by all nodes 104 within the network 106.

[0056] If a given party 103, e.g., Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice formulates a new transaction according to the relevant transaction protocol (using the wallet function of Alice's client application 105). Then, Alice sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this could be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid", examples of which will be described in detail shortly. In some transaction protocols, the conditions for verification can be set per transaction by the script included in the transaction 152. Alternatively, the conditions may simply be an embedded feature of the node protocol, or defined by a combination of the script and the node protocol.

[0057] Conditioned on passing a test for the newly received transaction 152j to be considered valid (i.e., “validated”), any blockchain node 104 that receives transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Further, any blockchain node 104 that receives transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 within the network 106. Since each blockchain node 104 applies the same protocol, assuming transaction 152j is valid, this means it will quickly be propagated throughout the network 106.

[0058] Upon being admitted to the ordered pool of pending transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins to compete to solve the proof-of-work puzzle in the latest version of each pool 154 that includes the new transaction 152. (Other blockchain nodes 104 may be attempting to solve the puzzle based on different transaction pools 154, but recall that whoever reaches it first may define the set of transactions included in the latest block 151. Ultimately, blockchain node 104 will end up solving the puzzle for a portion of the ordered pool 154 that includes Alice's transaction 152j). When proof-of-work is performed on a pool 154 that includes the new transaction 152j, it invariably becomes part of one of the blocks 151 within the blockchain 150. Since each transaction 152 has a pointer back to the previous transaction, the order of the transactions is also invariably recorded.

[0059] Different blockchain nodes 104 may first receive different instances of a given transaction and thus may have conflicting views as to which instance is "valid" before one instance is published in a new block 151. At that point, all blockchain nodes 104 will 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 is recorded on the blockchain 150, that blockchain node 104 must accept it and discard (i.e., treat as invalid) the first instance it accepted (i.e., the one not published in block 151).

[0060] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referring to the absolute account balance rather than by referring to the UTXOs of preceding transactions in the sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes of the network separate from the blockchain. In such a system, transactions are ordered using the running transaction tally of the account (also called the "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, any data fields in the transaction may also be signed. For example, this data field may refer to a previous transaction if the previous transaction ID is included in the data field.

[0061] 2. UTXO - based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). Below, it will be described with reference to an output-based or "UTXO" - based protocol. However, this is not limited to all possible embodiments. The exemplary UTXO-based protocol is described with reference to Bitcoin, but note that it can be similarly implemented in other exemplary blockchain networks.

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

[0063] Assume that Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j has "Tx" 1」 is labeled. This takes the amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled as "Tx 0 」 in Figure 2. Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily mean that Tx 0 is the first transaction in the blockchain 151 nor that Tx 1 is the very next transaction in the pool 154. Tx 1 can refer to a preceding (i.e., earlier) transaction that still has an unused output 203 locked to Alice.

[0064] The preceding transaction Tx 0 has already been verified and may be included in the block 151 of the blockchain 150 by the time Alice creates the new transaction Tx 1 , or at least by the time Alice sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in a new block 151. Alternatively, Tx 0 and Tx 1 can be created and sent together to the network 106, and if the node protocol permits buffering of "orphan (Tx 0 )" transactions, then Tx 0 to Tx 1It can even be sent after that. As used herein in the context of a transaction sequence, the terms "preceding" and "subsequent" refer to the order of transactions within a sequence as defined by the transaction pointers specified within a transaction (such as which transaction points to which other transaction). These can also be equivalently replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", etc. It does not necessarily imply the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that refers to a preceding transaction (an earlier transaction or "parent") is not verified until the parent transaction is verified and is not verified unless it is verified. A child that arrives at blockchain node 104 before the parent is considered an orphan. Depending on the node protocol and / or the behavior of the node, it may be discarded, buffered, or wait for a specific time for the parent.

[0065] Preceding transaction Tx 0 One of one or more outputs 203 of which is herein referred to as UTXO 0It has specific UTXOs labeled as such. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a lock script, and the lock script defines the conditions that the unlock script within the input 202 of a subsequent transaction must meet for the subsequent transaction to be verified and thus for the UTXO to be properly redeemed. Typically, the lock script locks that amount to a specific party (the beneficiary of the transaction in which it is included). That is, the lock script typically defines an unlock condition that includes the condition that the unlock script within the input of a subsequent transaction contains the cryptographic signature of the party to whom the previous transaction was locked.

[0066] The lock script (commonly known as scriptPubKey) is a portion of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is what is called "Script" (with a capital S) used by the blockchain network. The lock script specifies what information is required to use the transaction output 203, for example, specifying the requirements for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (commonly known as scriptSig) is a portion of code written in a domain-specific language that provides the information necessary to meet the lock script criteria. For example, it may include Bob's signature. The unlock script appears in the input 202 of the transaction.

[0067] That is, in the illustrated example, the UTXO 0 within the output 203 of Tx 0 has a lock script [Checksig P 0 that requires Alice's signature Sig P 0 for the UTXO A to be redeemed (strictly speaking, for the subsequent transaction attempting to redeem the UTXO A to be valid). [Checksig P Ais the public key P from Alice's public - private key pair A and includes the expression (i.e., hash) of Tx 1 The input 202 of Tx 0 is, for example, in an embodiment, its transaction ID, TxID, which is the hash of the entire transaction Tx 0 and is pointed to by Tx 1 The input 202 of Tx 1 is, from among any other possible outputs of Tx 0 equipped with an index to identify the UTXO 0 within Tx 0 to identify the UTXO 0 within Tx 1 The input 202 of Tx A further includes an unlock script <Sig P

[0068] When a new transaction Tx 1 arrives at the blockchain node 104, the node applies the node protocol. This includes executing the lock script and the unlock script together to check whether the unlock script meets the conditions (which may include one or more criteria) defined in the lock script. In an embodiment, this includes concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ​In the above formula, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that compose the unlock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will be executed in the same order as Tx 0 Alice's public key P as contained in the lock script in the output of A Using Tx 1 The unlock script in the input of Tx contains Alice's signature, who signed the expected portion of data. The expected portion of data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data is 1 (i.e., a separate element specifying the signed portion of the plaintext data need not be included since that is already inherently present).

[0069] The details of public-private cryptographic authentication are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that references herein to signing a particular data portion or part of a transaction, etc., can, in embodiments, mean signing a hash of that data portion or part of a transaction.

[0070] Tx 1 The unlock script in 0 If one or more conditions specified in the lock script of are met (i.e., in the illustrated example, Alice’s signature is Tx 1is provided and authenticated), the blockchain node 104 considers Tx 1 to be valid. This means that the blockchain node 104 adds Tx 1 to the ordered pool of transactions 154 that are pending. The blockchain node 104 also transfers the transaction Tx 1 to one or more other blockchain nodes 104 within the network 106, so that the transaction is propagated throughout the network 106. When Tx 1 is verified and included in the blockchain 150, this defines the UTXO 0 from Tx 0 as spent. Note that Tx 1 can only be valid if it uses an unspent transaction output 203. If an output already used by another transaction 152 is attempted to be used, Tx 1 will be invalid even if all other conditions are met. Thus, the blockchain node 104 also needs to check whether the referenced UTXO within a previous transaction Tx 0 is already spent (i.e., has already formed a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose the order defined in the transaction 152. In practice, a given node 104 may maintain a separate database marking which UTXO203 within which transaction 152 has been used, but ultimately, what defines whether a UTXO has been used is whether it has already formed a valid input to another valid transaction within the blockchain 150.

[0071] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount specified by all its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction is not propagated and is not included in block 151.

[0072] Note that in the UTXO-based transaction model, a given UTXO must be used in its entirety. It is not possible to "leave behind" a portion of the amount defined as used in the UTXO and use another portion. However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined in the UTXO 0 within Tx 0 can be split among multiple UTXOs within Tx 1 . Thus, if Alice does not want to give all of the amount defined in UTXO0 to Bob, Alice can use the remainder to give herself the remainder in the second output of Tx 1 or pay it to another party.

[0073] In practice, Alice usually also needs to include a fee for the Bitcoin node 104 that successfully included her transaction 104 in block 151. If Alice does not include such a fee, Tx 0may be rejected by the blockchain node 104 and thus, even if technically valid, may not be propagated and may not be included in the blockchain 150 (the node protocol does not force the blockchain node 104 to accept the transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, the difference between the total amount specified by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, if a pointer to UTXO 0 is the only input to Tx 1 and Tx 1 is the only output UTXO 1 having. If the amount of the digital asset specified in UTXO 0 is greater than the amount specified in UTXO 1 , the difference may be allocated to the node 104 that won the proof-of-work race to create the block containing UTXO 1 . However, alternatively or additionally, it is not necessarily excluded that the transaction fee may be explicitly specified in one of its own UTXOs 203 of the transaction 152.

[0074] The digital assets of Alice and Bob are composed of the UTXOs locked to them in any transaction 152 anywhere within the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across all the UTXOs of various transactions 152 throughout the blockchain 150. Nowhere within the blockchain 150 is the number defining the total balance of a given party 103 stored. The role of the wallet function in the client application 105 is to collate together the values of all the various UTXOs locked to each party and not yet used in another previous transaction. This can be done by querying a copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0075] Note that the script code is often represented schematically (i.e., not using exact language). For example, operation codes (opcodes) may be used to represent certain functions. "OP_..." refers to a particular opcode of the script language. As an example, OP_RETURN is an opcode of the script language that, when OP_FALSE is placed before it at the start of a lock script, can store data within a transaction, thereby immutably recording the data on the blockchain 150, by creating an unusable output of the transaction. For example, the data may comprise a document that it is desired to store on the blockchain.

[0076] Normally, the input of a transaction is the public key P AIt includes a digital signature corresponding thereto. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a portion of specific data. In some embodiments, for a given transaction, the signature signs a part of the transaction input and part or all of the transaction output. The specific part of the signed output depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of the signature to select which output is signed (and thus is fixed at the time of signing).

[0077] The lock script may sometimes be referred to as "scriptPubKey" referring to the fact that it usually contains the public key of the party by which each transaction is locked. The unlock script may sometimes be referred to as "scriptSig" referring to the fact that it supplies the corresponding signature. However, more generally, it is not essential in all applications of the blockchain 150 that the condition for the UTXO to be redeemed includes authenticating the signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

[0078] 3. Side Channel As shown in FIG. 1, the client applications on each of Alice's and Bob's computer devices 102a, 120b may each have additional communication capabilities. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instruction of either party or a third party). The side channel 107 enables the exchange of data separate from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without the transaction yet being registered on the blockchain network 106 or proceeding on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Sharing a transaction in this way is also sometimes referred to as sharing a "transaction template". A transaction template may be missing one or more inputs and / or outputs necessary 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, negotiated amounts or conditions, data content, etc.

[0079] Side channel 107 can be established via the same packet-switched network 101 as blockchain network 106. Alternatively or additionally, side channel 301 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, side channel 107, referred to somewhere herein, can comprise one or more links via one or more networking technologies or communication media for "off-chain", i.e., separate from blockchain network 106, data exchange. If two or more links are used, the bundle or set of off-chain links as a whole can be referred to as side channel 107. Thus, when it is said that Alice and Bob exchange, via side channel 107, a particular portion of information or data, etc., it should be noted that this does not necessarily imply that all of these portions of data must be transmitted on exactly the same link or the same type of network.

[0080] 4. Client Software FIG. 3A shows an exemplary implementation of a client application 105 for implementing an embodiment of the presently disclosed approach. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement transaction-related functions underlying the client 105, such as formulating a transaction 152, receiving and / or transmitting transactions and / or other data via the side channel 301, and / or sending a transaction to one or more nodes 104 to be propagated through the blockchain network 106 according to the approach described above and to be described in more detail shortly. According to the embodiments disclosed herein, the transaction engine 401 of each client 105 includes a function 403 configured to write a lock script in a high-level scripting language and convert between the high-level scripting language and a low-level scripting language. In other words, a lock script written in a high-level language can be mapped to an equivalent lock script written in a low-level language. For example, Alice 103a may construct a compact lock script using a high-level language, and then the transaction engine 401 may generate a corresponding expanded lock script.

[0081] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computer device 102, including outputting information to each user 103 via the user output means of the device 102 and receiving input from each user 103 via the user input means of the device 102. For example, the user output means can include one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output. The user input means can include, for example, an input array of one or more touch screens (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or voice 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.

[0082] Note: Although various functions in this specification may be described as being integrated into the same client application 105, this is not necessarily limiting. Instead, they can be implemented in a suite of two or more separate applications. For example, one can be a plugin for another or connected via an API (Application Programming Interface). For example, the functions of the transaction engine 401 may be implemented in an application separate from the UI layer 402, and the functions of a given module such as the transaction engine 401 may be split among multiple applications. Also, the possibility that some or all of the described functions are implemented, for example, in the operating system layer is not excluded. When anywhere in this specification a single or a given application 105 etc. is mentioned, this is merely an example, and more generally, it will be understood that the described functions can be implemented in any form of software.

[0083] Figure 3B shows a mockup of an example of a user interface (UI) 500 that can be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI can be rendered by the client 105b on Bob's device 102b or by the devices of other parties.

[0084] As an example, Figure 3B shows the UI 500 from Alice's perspective. The UI 500 may comprise one or more UI elements 501, 502, 503 that are rendered as separate UI elements via user output means.

[0085] For example, the UI element may comprise one or more user-selectable elements 501, which may be buttons on different screens or different options within a menu, etc. The user input means is configured such that a user 103 (in this case, Alice 103a) can select or act on one of the options by clicking or touching a UI element on the screen or by speaking the name of the desired option (note: the term "manual" as used in this specification only means in contrast to automatic and is not necessarily limited to the use of one or both hands). This option enables the user (Alice) to select one or more high-level functions of a high-level scripting language, for example, functions configured to perform complex mathematical operations. The option enables the user to convert from a compact lock script to an expanded lock script, for example, to generate a signature based on a version of a transaction that includes the expanded lock script instead of the compact lock script.

[0086] Alternatively or additionally, the UI element may comprise one or more data input fields 502 in which the user can describe one or more high-level functions. These data input fields are rendered, for example, on the screen via the user output means, and data can be input into the fields through the user input means, such as a keyboard or touch screen. Alternatively, the data can also be received orally, for example, based on speech recognition.

[0087] Alternatively or additionally, the UI element may comprise one or more information elements 503 that are output to output information to the user. For example, these can be rendered on the screen or audibly.

[0088] It will be understood that the specific means of rendering various UI elements, selecting options, and entering data are not important. The functions of these UI elements will be described in detail shortly. Also, it will be understood that the UI 500 shown in FIG. 3 is only a schematic mock-up and may in fact include one or more additional UI elements not shown for the sake of simplicity.

[0089] 5. Node Software FIG. 4 shows an example of node software 450 executed on each blockchain node 104 of network 106 in an example of a UTXO or output-based model. Note that another entity may execute node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of a node 104. Node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may execute node software including, but not limited to, all three of 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 recognize different fields of a transaction 152 and process them according to the node protocol. When a transaction 152j (Tx m-1 ) having an input that refers to an output (e.g., a UTXO) of another preceding transaction 152i (Tx j ) is received, the protocol engine 451 identifies the unlock script within Tx j and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Tx j based on the pointer within the input of Tx i . Tx imay be published on the blockchain 150, in which case the protocol engine retrieves Tx from a copy of block 151 of the blockchain 150 stored in node 104 i Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 retrieves Tx i from the ordered set 154 of unpublished transactions maintained by node 104. In any case, the script engine 451 identifies the lock script in the referenced output of Tx i and passes this to the script engine 452.

[0090] Accordingly, the script engine 452 has the lock script of Tx i and the unlock script from the corresponding input of Tx j For example, the transactions labeled Tx 0 and Tx 1 are shown in Figure 2, but the same applies to any pair of transactions. The script engine 452 executes the two scripts together, which involves placing data on the stack 453 and retrieving data from it according to the stack-based scripting language (e.g., Script) being used.

[0091] By executing the scripts together, the script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether the unlock script "unlocks" the output containing the lock script. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0092] In an output-based model, a result of "true" from the script engine 452 is one of the conditions for the validity of a transaction. Typically, for Tx j the total amount of digital assets specified in the output does not exceed the total amount indicated by its input, and for Tx i the indicated output is not already being used by another valid transaction, among other protocol-level conditions that must also be satisfied and are evaluated by the protocol engine 451. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions and verifies the transaction Tx j only if they are all true. The protocol engine 451 outputs an indication to the application-level decision engine 454 as to whether the transaction is valid. Only if Tx j is actually verified, the decision engine 454 may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions with respect to Tx j . This involves the consensus module 455C adding Tx j to each ordered set of the node's transactions 154 for inclusion in block 151, and the propagation module 455P transferring Tx j to another blockchain node 104 within 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 leaves sufficient transaction fees.

[0093] The terms "true" and "false" as used in this specification are not necessarily limited to returning results in the form of only a single binary digit (bit), although it is noted that this is certainly one possible implementation. More generally, "true" can refer to any state indicating success or a positive outcome, and "false" can refer to any state indicating lack of success or a non - positive outcome. For example, in an account - based model, a "true" result can be indicated by a combination of an implicit, protocol - level verification of a signature and an additional positive output of a smart contract (if both individual outcomes are true, the overall result is considered to indicate true).

[0094] 6. High - level scripting language FIG. 5 shows an exemplary system 500 for sending a transaction between a user and a node. System 500 includes one or more generating parties (i.e., parties that generate blockchain transactions). For simplicity, only two generating parties, Alice 103a and Bob 103b, are shown in FIG. 5. Note that the generating parties do not have to be users and could instead be machines. System 500 also includes a verification entity in the form of a blockchain node 104 and one or more nodes of a blockchain network 106.

[0095] A generating party, such as Alice 103a, is configured to generate a first blockchain transaction Tx 1 The first blockchain transaction Tx 1has one or more outputs. The first transaction is a compact transaction. At least one of the outputs (the first output) comprises a compact lock script (CLS), also referred to throughout as a compact script (CS). Note that the first output need not logically appear first within the transaction. Instead, "first" is used only as a label for this particular output. The CLS is written in a high-level (HL) scripting language and comprises one or more high-level (HL) functions. Each high-level function is configured to perform an operation equivalent to one or more low-level (LL) functions (e.g., opcodes) of the low-level (LL) scripting language of the blockchain 150, i.e., the native scripting language. The CLS is configured to perform an operation equivalent to an expanded lock script (ELS), also referred to throughout as an expanded script (ES), written using only the LL scripting language (i.e., define lock conditions). For example, both in the CLS and the ELS, a lock script for finding the modular inverse of a number can be defined. Since the CLS can comprise a single HL function configured to find the modular inverse of a number instead of requiring a number of LL functions to perform the operation, the size of the CLS can be reduced compared to the ELS. Put another way, the CLS written in the HL scripting language can be compiled into the ELS written in the LL language.

[0096] In some examples, there may 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 each be used to perform subtraction, multiplication, and division, respectively. This can save LL functions such as OP_SUB, OP_MUL, OP_DIV used by a particular LL scripting language, Script.

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

[0098] The first transaction Tx 1 may include multiple outputs, such as a second output. The second output may each include a respective CLS. Generally, some or all of the outputs of the first transaction Tx 1 may each include a respective CLS.

[0099] Alice 103a is also configured to make the first transaction Tx 1 available to the blockchain network 106 in the HL language. For example, Alice 103a may send the first transaction directly to the blockchain node 104, or indirectly via a different party, such as Bob 103b. For example, Alice 103a may send the transaction Tx 1 to Bob 103b via the side channel 107. Upon receiving the transaction, Bob 103b may include a signature that signs the transaction Tx 1 . Bob 103b may then send the transaction Tx 1 to the network 106. When sending the first transaction, since the first CLS is smaller than the corresponding first ELS, bandwidth is saved. Alice 103a may store the first transaction Tx 1 in the memory of her computing device 102a.

[0100] In some examples, Alice 103a is the transaction identifier TxID of the first transaction Tx 1 1can be generated. The transaction identifier is typically the hash or double hash of the raw transaction data. Alice 103a first generates a modified version of the first transaction Tx raw that does not include the CLS but instead includes the corresponding ELS. That is, the first output includes the first ELS instead of the first CLS. Similarly, if the first transaction Tx 1 includes multiple CLSs, the modified version includes multiple ELSs instead. Then, a transaction identifier TxID raw is generated based on the modified version of the first transaction Tx raw by obtaining the hash (e.g., SHA-256) or double hash (e.g., double SHA-256) of the modified version of the first transaction Tx 1 . Alice 103a makes the transaction identifier TxID 1 available to the blockchain network 106 by sending it to the blockchain node 104 along with the first transaction Tx 1 .

[0101] In some examples, Alice 103a first generates a version of the first transaction Tx 1 that includes the CLS and then generates a modified version of the first transaction Tx raw . That is, any CLS is replaced with the corresponding ELS. In other words, the function 403 can convert the first CLS to the first ELS by mapping between the HL function of the HL language and the LL function of the LL language, i.e., the first CLS is compiled into the first ELS. Then, a transaction identifier TxID 1 is generated.

[0102] Generating a modified version of the first transaction Tx raw may simply mean replacing the first CLS with the first ELS. Then, a transaction identifier TxID 1After the first CLS is generated, the first transaction Tx including the first CLS 1 The first ELS can be replaced with the first CLS so that the version of 1 can be sent to the blockchain network 106.

[0103] Also, it cannot be excluded that Alice 103a may first generate a modified version of the first transaction Tx raw , that is, the transaction including the first ELS. Thereby, Alice 103a can generate a transaction identifier TxID 1 . Then, Alice 103a can replace the ELS with the corresponding CLS. That is, the function 403 can convert the first ELS into the first CLS by mapping between the LL function in the LL language and the HL function in the HL language.

[0104] Blockchain transactions often include a signature in the input of the transaction to unlock the lock of the referenced output of the previous transaction. If Alice 103a needs to include a signature as part of the input of the first transaction Tx 1 to unlock the lock of the output of the previous transaction, Alice 103a can include the signature as part of the modified version of the first transaction Tx raw . In other words, Alice's signature signs the modified version of the first transaction Tx including the first ELS rather than the first CLS raw . Then, the transaction identifier TxID 1 can be generated based on the modified version including Alice's signature. The version of the transaction submitted to the network 106 also includes Alice's signature. However, when using the first transaction Tx 1 as a message for verification, the signature will not be a valid signature. The signature is only a valid signature when using the modified version of the first transaction Tx raw as a message.

[0105] Note that the replacement of the first ELS with the first CLS may depend on the selection of a signature flag (e.g., SIGHASH flag) selected by Alice 103a. For example, Alice 103a may select a signature flag (e.g., SIGHASH_NONE) such that the signature is not applied to any of the transaction outputs. In that case, Alice 103a does not need to replace the first CLS with the first ELS. As another example, Alice 103a may select a signature flag (e.g., SIGHAHS_SINGLE) such that the signature is applied to only one output. In that case, if the signature is applied to an output that does not include the first CLS (or any other CLS), Alice 103a does not need to replace the first CLS with the first ELS (or the corresponding ELS). Further, in this case, if there is a CLS in an output other than the signed output, Alice 103a does not need to replace that CLS. However, if the first CLS is included in the single output signed by the signature, Alice 103a needs to replace the first CLS with the first ELS. Finally, Alice 103a may select a signature flag (e.g., SIGHASH_ALL) such that the signature signs all the outputs. In that case, Alice 103a must replace the first CLS with the first ELS. The same applies to any other output that includes each CLS.

[0106] In some examples, Alice 103a may generate one or more secondary transaction identifiers. These secondary identifiers are similar to the above-described transaction identifier TxID 1 in that they can be a hash or double-hash of data, but the hashed data is different. For example, the secondary transaction identifier may be the version number of the first transaction Tx 1 , the lock time of the first transaction Tx 1 , one or more inputs of the first transaction Tx 1 , and / or the first transaction Tx 1It can be generated based on one or more of one or more outputs. 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 an output with each CLS.

[0107] The input to a transaction can include the following three parts. 1. A transaction identifier concatenated with an index (indicating which transaction output is used), 2. An unlocking script, and 3. A sequence number.

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

[0109] The secondary transaction identifier can be included in the output of the first transaction Tx 1 for example, an unusable output. The modified version of the first transaction Tx raw can also include the secondary transaction identifier. Therefore, in these examples, the "primary" transaction identifier TxID 1 and the signature are functions of the secondary transaction identifier.

[0110] In some embodiments, the above-described HL script language can be a high-level language compared to the LL script language while being a low-level language compared to an even higher-level script language. That is, the HL language can be an intermediate-level language between the LL language and a second-layer HL language. The second-layer HL language is a user-oriented language. In other words, the user-oriented language can be a script language that can be described by a user (or another party or entity including a device). A script described in the user-oriented language can be compiled (which can mean compressed) into a script described in an intermediate language, such as a first CLS. Next, the script described in the intermediate language can be expanded (e.g., by being mapped) into a script described in the LL language. Also, the possibility that a script described in the user-oriented language is directly converted into a script described in the low-level language is not excluded.

[0111] In other words, in some embodiments, there are only two levels of script languages, a high-level language and a low-level language, while in other embodiments, there are three levels of script languages, a user-oriented (highest) level, an intermediate language level, and a low-level language. In an exemplary implementation, the user-oriented language may be called the SDL language, the intermediate language may be called the meta-script language, and the low-level language may be called a regular (e.g., native) language.

[0112] Returning to the above example, Alice 103a can generate a transaction that includes a lock script described in the user-oriented language, i.e., a user-oriented (UF) lock script. Then, before submitting it to the network 106, the UF lock script is converted (e.g., compiled) into a first CLS described in the intermediate language. Then, a transaction including the first CLS can 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 using the more compact form of the lock script in the CLS.

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

[0114] As shown in FIG. 5, blockchain node 104 obtains a first transaction Tx 1 . The first transaction Tx 1 includes a first CLS (and, optionally, one or more additional CLSs). The first transaction Tx 1 may be obtained directly from Alice 103a or from a different entity, such as Bob 103b. It is not excluded that node 104 obtains the first transaction Tx 1 from a different node 104.

[0115] Node 104 is configured to verify the first transaction Tx 1 . In some embodiments, the first transaction Tx 1 is verified based on its transaction identifier. In these embodiments, node 104 obtains a candidate transaction identifier TxID 1 from, for example, Alice 103a, Bob 103b, or a different entity. The transaction originator, i.e., Alice 103a, is expected to send the candidate transaction identifier TxID 1 along with the first transaction Tx 1 .

[0116] Node 104 replaces the first CLS with a corresponding ELS to process the first transaction Tx rawGenerate a modified version of ', i.e., the first CLS is compiled into the first ELS. In other words, node 104 is configured to convert the first CLS into the first ELS. This can be performed by the node's script engine 452 or by another function 455. The first transaction Tx raw Node 104 that generated the modified version of'performs the first transaction Tx raw Generates a transaction identifier TxID based on the modified version of '. 1 For example, the transaction identifier TxID 1 Can be generated by hashing or double-hashing the modified version of the first transaction Tx raw '.

[0117] For the first transaction Tx 1 To be considered valid, the obtained candidate transaction identifier TxID 1 Must match the generated transaction identifier TxID 1 '. Therefore, node 104 performs a comparison of the transaction identifiers and determines whether they are equal. If the transaction identifiers do not match, the first transaction Tx 1 Is considered invalid and may be ignored.

[0118] If the transaction identifiers match, node 104 may continue to verify the transaction according to the blockchain protocol. This includes executing the input of the first transaction Tx 1 Together with the respective reference outputs of previous transactions.

[0119] If the transaction Tx 1 Is valid according to the blockchain protocol, node 104 sends the transaction Tx 1 To other nodes 104 in the network 106 and / or the first transaction Tx rawIt is possible to attempt to construct a block based on the corrected version. In other words, the block will include the Merkle root of the Merkle tree having the transaction identifier TxID of the corrected transaction Tx raw as one of the leaves (i.e., the (double) hash of the corrected transaction with the first ELS). This may involve storing in memory the corrected version of the first transaction Tx 1 and / or the corrected version of the first transaction Tx 1 and / or the first transaction Tx raw .

[0120] In some examples, the corrected version of the transaction may not include the first CLS. In other examples, the corrected version of the transaction may include both the first ELS and the first CLS. For example, the first output of the corrected transaction may include the first CLS in such a way that it is not executed during verification of the transaction. For example, the first CLS may be the OP_RETURN opcode: <els>OP_RETURN <cls>may follow. In this case, the transaction identifier is based on both the first ELS and the first CLS.

[0121] In some examples, in response to receiving a request, node 104 may send a modified version of the first transaction Tx raw to another node 104. For example, a block 151 including the first transaction Tx 1 may be published on the blockchain 150. The requesting node 104 may not be configured to verify a transaction including a script described in the HL language. Therefore, node 104 sends a modified version of the first transaction Tx raw to the requesting node, enabling the requesting node 104 to verify the first transaction in the same way as it would for a transaction that typically includes only the LL script language.

[0122] So far, the above description of transaction verification has focused on verifying transactions including CLS, but it was not necessarily an input intended to unlock the CLS. For example, the first transaction Tx 1 may include an input that unlocks the output of a previous transaction described using only the LL language.

[0123] Assume that the first transaction Tx 1 is a valid transaction. Then it is published in block 151. Next, a blockchain node 104 (not necessarily the same node 104 that published that block 151, but not excluded) may receive a second transaction Tx 1 that includes an input that references the first output of the first transaction Tx 2 , i.e., the output including the first CLS. The second transaction Tx 2 can be generated by a second party, e.g., Bob 103b. Bob 103b may send the second transaction directly to node 104 or indirectly via a different entity, e.g., Eve, who is a third user.

[0124] Node 104 then proceeds to verify the second transaction Tx 2 To verify the second transaction Tx 2 node 104 must obtain the first transaction from, e.g., memory or blockchain 150. Node 104 then has two options for verifying the second transaction Tx 2 As a first option, node 104 may replace the first CLS with the first ELS (i.e., the first CLS is compiled into the first ELS) and then execute the input of the second transaction against the first ELS. For the second transaction to be valid, the execution must succeed. In other words, the input of the second transaction must successfully unlock the lock of the first ELS. As a second option, node 104 need not replace the first CLS with the first ELS. Instead, node 104 may execute the input of the second transaction Tx 2 against the first CLS. Again, for the second transaction to be valid, the execution must succeed. In other words, the input of the second transaction Tx 2 must successfully unlock the lock of the first CLS.

[0125] Since the first CLS is equivalent to the first ELS, the locks of both the first CLS and the first ELS are unlocked by the same input. As a simple example, if the first ELS is such that the second transaction Tx 2 Assume there are multiple LL functions configured to obtain a numerical value from an input, perform a mathematical operation on that numerical value, and check whether the numerical value matches a numerical value included in a first ELS. The first CLS is configured to perform the same operations but is smaller in size than the first ELS. For example, the first CLS may include a numerical value and a single HL function, while the first ELS may include not only numerical values but also many LL functions. Since the overall operations of the first ELS and the first CLS are the same, the same input leads to the same result, i.e., success or failure of execution.

[0126] Second transaction Tx 2 If it is valid, i.e., the unlock script of the second transaction successfully unlocks the lock of the first ELS or the first CLS and any other conditions of the blockchain protocol are met, node 104 may send the second transaction Tx 2 to other nodes 104 in the blockchain network 106. Node 104 may also store the second transaction Tx 2 in order to construct a block 151 that includes, for example, the second transaction Tx 2

[0127] Second transaction Tx 2 may optionally include one or more outputs that each include a CLS. In that case, as part of the verification of the second transaction Tx 2 , node 104 may perform the same operations as described above when discussing the verification of the first transaction Tx 1 , i.e., obtain a candidate transaction identifier TxID 2 , generate a modified version of the second transaction, generate a transaction identifier TxID 2 ', and perform a comparison between the obtained transaction identifier and the generated transaction identifier. To enhance efficiency, the comparison may be performed before executing the input script and the output script.

[0128] ​ The above description of transaction verification has mainly focused on verifying transactions with compact lock scripts. Node 104 can also verify transactions with (in addition to, or instead of, compact lock scripts) compact unlock scripts. Node 104 can directly execute the compact unlock script during transaction verification, that is, the compact unlock script is directly executed in the HL script language (which can be a user-oriented language or an intermediate language). Alternatively, Node 104 can convert the compact unlock script into an expanded unlock script described in the LL script language before execution.

[0129] The description of generating a modified version of a transaction for the purpose of generating signatures and / or transaction identifiers also applies equally to scenarios where the transaction has a compact unlock script.

[0130] Figure 9 shows the relationship between three types of languages. As shown, the lowest level is the LL language, that is, the native script language of the blockchain (for example, the opcodes of the script language). The higher level is the intermediate language. Above the intermediate language level is the user-oriented language.

[0131] This programming architecture is designed to make blockchain scripts more accessible, more computationally and space-efficient, and more suitable for smart contracts.

[0132] The life cycle of a transaction comprises at least the following stages. 1. Creation - One transaction (the transaction to be created). The script can be a user-oriented, intermediate-level, or low-level script language. 2. Propagation - One transaction (the transaction to be sent). The script can be an intermediate-level language for compactness on the node side and rapid deployment to the LL language (compared to the user-facing language). 3. Storage - One transaction (the transaction to be stored). The script can be an intermediate-level language for compactness. 4. Verification - Two transactions (the transaction used provides a lock script and the spending transaction provides an unlock script). There is no verification during creation, propagation, or storage. At runtime, the transaction can be executed only in a compact form or an expanded form, or in a hybrid manner where not all but some of the compact script is converted to native script before execution.

[0133] In some examples, the function table can be used by different parties (i.e., Alice 103a and node 104) when executing a compact script (lock or unlock). The function table contains a list of HL functions and their corresponding LL functions. In other words, the HL functions are mapped to the corresponding LL functions. The HL functions are compiled (i.e., translated) into the corresponding LL functions and stored in the function table. The function table can be used to convert a compact script to an expanded script or vice versa.

[0134] 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, e.g., one of the nodes 104.

[0135] In an embodiment where a three - layer framework (i.e., user - facing language, intermediate - level language, and low - level language) is utilized, a function table may be used to map from the IL language to the LL language. The function table is the output from compiling the UF language. When a function is described in the UF language, it is compiled (i.e., translated) into the corresponding IL function. The corresponding IL is mapped to one or more other (i.e., different) IL functions and / or one or more LL functions. That is, one IL function (e.g., "reverse" in the following exemplary section) is mapped to a set of low - level functions that together perform an operation equivalent to that of the IL function. Here, "low - level" means a level lower than the user - facing level. The set of low - level functions is associated with the IL function and stored in the function table (in the following exemplary section, "length" is an example of a different IL function).

[0136] Next, the function table may be used to generate and / or execute the IL script. For example, a reference to an IL function or an identifier of an IL function can be included in the IL script, such that at runtime, the set of mapped low - level functions can be executed. In other words, the identifier / reference is used to look up the set of low - level functions. In this example, the reference or identifier itself is an IL function, configured to perform an operation equivalent to one or more LL functions at runtime and, similarly, an operation equivalent to the identified / reference function. The IL script itself can be expanded into the corresponding native script. Again, the set of low - level functions is retrieved from the function table and then can be expanded only into LL (i.e., native) functions. Note that the set of low - level functions that define one IL function itself may include different IL functions or identifiers or references to those different IL functions.

[0137] As described above, there can be multiple different UF languages (e.g., Python and Java) that can be compiled into the same IL language. It is desirable that the same UF functions described in different UF languages (i.e., functions that are configured to perform the same operation but are described in different languages) be compiled into the same set of low-level functions in the function table, but this is not essential as long as the same output is generated when the same input is given.

[0138] Node 104 can generate a larger function table based on several small function tables, e.g., function tables generated by different parties (e.g., users or nodes). The overall table can be stored by a central party, and Node 104 can update those tables at any time by requesting the overall table.

[0139] User-oriented languages are human-readable, easy for developers to use, extensible, and can be compiled into intermediate-level languages. Examples of user-oriented languages are provided below. However, there can be multiple different user-oriented languages that can be compiled into the same intermediate-level language. Existing languages such as Java, JavaScript, or Python can also be adapted to be high-level languages for creating blockchain transactions.

[0140] Intermediate-level languages connect high-level languages to low-level languages (e.g., opcodes) to improve efficiency in bandwidth, storage, and computation. Hereinafter, this general-purpose intermediate-level language is called a metascript. The characteristics of the metascript can be summarized as follows. 1. Space efficiency - more compact in size than high-level and low-level languages, 2. Executable - can be directly executed by a compatible script engine (note that this is optional and in some cases the metascript may not be executable unless it is deployed to a low-level language), 3. Can be deployed to a deployable - low - level language (native script). 4. Deterministic - The same meta - script is always deployed to the same native script.

[0141] Furthermore, when the same input is given and directly executed, the meta - script generates the same output as the output generated by executing the deployed native script from the meta - script.

[0142] Developers can write scripts in a user - oriented language, which are then compiled into intermediate - level language scripts (meta - scripts). Transactions can be sent and stored in meta - script versions. Transactions are verified in a meta - script, native - script, or hybrid manner (i.e., execution of unlock scripts and lock scripts). That is, the meta - script engine of the blockchain node 104 can interact with the native - script engine to obtain more functions and efficiency.

[0143] User - oriented language scripts can be directly converted into low - level language scripts (native scripts). However, by introducing intermediate - level language scripts (meta - scripts), the work of converting user - oriented language scripts of the blockchain node 104 into native scripts is reduced as much as possible. This enables the node 104 to concentrate resources on other more important activities such as block generation (mining). Examples show how user - oriented language scripts, intermediate - level language scripts, and low - level language scripts differ from each other and how to improve blockchain scripts in various aspects.

[0144] Specific examples of some embodiments of the present invention are provided below. Note that although these examples refer to the Bitcoin blockchain, they are generally applicable to other blockchains.

[0145] Note also that in the following example, an architecture with three language levels for users, intermediate, and low levels is described. In these examples, the smart contract is written in a user-oriented language, converted into a meta-script written in an intermediate-level language, and further converted into Bitcoin opcodes (i.e., a low-level language).

[0146] Alice can use a user-oriented level scripting language to create a lock script [High-Level script B]. The lock script is then compiled into a meta-script in an intermediate language and embedded in a transaction.

[0147] [Table 1]

[0148] There are several points to note here. 1. The lock script [High-Level script B] is a script written in a user-oriented scripting language. This is called a user-oriented lock script. 2. The user-oriented lock script is compiled into a meta-script [Meta Script B]. 3. For each meta-script, there is a native Bitcoin opcode and a native lock script equivalent to the meta-script. That is, when the same unlock script is executed, the same result is always generated. This deterministic behavior and its equivalence can be achieved through testable and verifiable calculations. 4. The native lock script can be several megabytes or larger, but its compact form can be reduced to about a few bytes. The large difference in size is beneficial for Bitcoin nodes when propagating and storing transactions. 5. Unsigned transactions are first constructed (Table 1 (Table 2)). When a transaction is signed, the compact lock script is expanded into a low-level language lock script (Table 2 (Table 3)).

[0149]

Table 2

[0150]

Table 3

[0151]

Table 4

[0152] 6. After signing the transaction, while the native block script still exists within the transaction, the transaction is serialized and double-hashed to obtain the transaction ID. That is, TxID 1 is calculated based on the expanded lock script rather than the compact lock script. This achieves forklessness, that is, since the TxID is defined based on the native Bitcoin script, forks in the blockchain are prevented.

[0153]

Table 5

[0154] 7. To facilitate consistency verification in some scenarios, the secondary transaction ID of the compact lock script can be embedded in the transaction before signing. For example, TxID 1-secondary can be defined as a hash value whose preimage has any of the following. a. Version and lock time, b. Input without unlock script, and c. Output with a compact form of lock script.

[0155] This is shown from Table 5 (Table 6) to Table 8 (Table 9).

[0156]

Table 6

[0157]

Table 7

[0158]

Table 8

[0159]

Table 9

[0160] Transactions created by the above Alice 103a are propagated in a compact form (meta-script) to save bandwidth. As described above, compared with the expanded lock script, its compact form is several digits smaller. This is particularly relevant to the Bitcoin SV ecosystem where the size of the script is unlimited and each block can contain billions of transactions (approximately every 10 minutes).

[0161] For now, assume there are two types of nodes 104: HL-enabled Bitcoin nodes configured to execute the HL script language, and HL-disabled Bitcoin nodes. Note that HL-disabled nodes are existing nodes that are not aware of the HL script language and are not configured to use the HL language, as opposed to nodes that recognize the HL language and simply choose to disable the function.

[0162] Depending on the signature flag used to sign the transaction input (see the above description), the HL-inoperable node may consider a transaction containing a CLS to be invalid. That is, when an HL-inoperable node receives a transaction, since there is no mechanism to obtain the original transaction using the unwind lock script, it is considered invalid and discarded. During the signature verification of the unlock script of the spending transaction, since the signed message is assumed to include an ELS (which the HL-inoperable node cannot replicate from the CLS), the transaction is considered invalid. This is the same scenario as when the transaction ID is received but the transaction data is not. However, the lack of acceptance from these nodes can be addressed when a block is found by an HL-capable Bitcoin node. The HL-inoperable node receives a block containing Alice's transaction. Since the HL-inoperable node does not store them, Alice's transactions are considered non-existent. The HL-inoperable node can then request the transaction from an HL-capable node. The HL-capable node sends the complete transaction without using the compact lock script. The HL-inoperable node can then verify the entire transaction. However, if the majority of nodes are HL-capable, since Alice's transaction is accepted by most of the network 106, the HL-capable node can choose to ignore such requests.

[0163] In some cases, if the signature does not sign all transaction outputs, and the output containing CLS is not signed, the HL-inoperable node may consider the HL transaction valid. In that case, the HL-inoperable node can actually verify the transaction using CLS. However, this vulnerability is not specific to the present invention. Generally, any transaction without a signature with a signature flag that signs all outputs, for example, SIGHASH_ALL becomes vulnerable when the output is modified.

[0164] When an HL-operable node receives a transaction, it performs the following processing. 1. Convert the metaroll script to the corresponding native block script and use the library register or reference table to obtain the following.

[0165]

Table 10

[0166] 2. Hash the transaction data to obtain the transaction ID and check whether it is the same as TxID 1 and. 3. If they are the same, proceed to general signature verification or script verification. Note that script verification may be started when the transaction is received instead. 4. If the transaction is valid, the HL-operable node propagates the transaction to the peer in compact form.

[0167] When a node that cannot use HL verifies a block found by a Bitcoin node that can use HL, it requests the complete transaction data of a transaction that uses a compact lock script or that is simply lost from that perspective. In this case, the node that can use HL sends those transactions using the expanded lock script. This enables the node that cannot use HL to verify those transactions. Since each compact lock script is equivalent to the expanded lock script, a transaction that has been successfully verified by a node that can use HL will also be valid for a node that cannot use HL.

[0168] Assume that a user, for example, Bob 103b, is attempting to spend a transaction created by Alice 103a. He creates a spending transaction.

[0169]

Table 11

[0170] input B is assumed to unlock the lock of [Meta Script B], where input B may contain a digital signature from Bob Sig B for the public key PK. B

[0171] As a node that can use HL, to verify the spending transaction, or more precisely, to verify the script "<input B >[Meta Script B]", one of the following options can be selected. 1. Obtain the compiled lock script and use SDL to execute <input B >[Expanded Meta Script B in Bitcoin opcodes] using the native script engine 2. <input B ​Execute [Meta Script B] and use SDL to obtain the same result as Option 1.

[0172] Option 2 provides a computational advantage to HL-enabled nodes over HL-disabled nodes. SE 1 and SE 2 Consider a scenario with two script engines, SE 1. When the same input is given to the engines, both SE 1 and SE 2 generate the same result, and 2. SE 2 is more efficient than SE 1 (it takes less time to generate the result when given the same input).

[0173] As nodes, the switch between SE 1 and SE 2 does not affect the blockchain protocol.

[0174] Considering the above reasons, HL-enabled nodes can switch between the native script engine (as SE 1 ) and the HL engine (as SE 2 ) to optimize the script verification process.

[0175] As HL-enabled nodes, to save space, compact lock scripts can be used to store transactions. Without loss of generality, assume that the transactions exist as in table 10 (Table 12).

[0176]

Table 12

[0177] Alternatively, a secondary identifier can be added to the first output, for example, as follows. [smart contract]OP_FALSE OP_RETURN TxID 1-secondary >.

[0178] When expanded into native opcodes, the lock script [Bitcoin opcodes expanded from the meta-script B] can be several megabytes, but note that in its compact form (meta-script), the lock script can be on the order of several bytes. If there are billions of such transactions in one block (approximately every 10 minutes), the savings in storage space are significant.

[0179] Furthermore, by including a secondary transaction ID protected by a digital signature, assuming the corresponding signer is trusted, the integrity of the compact lock script can be verified without compiling it.

[0180] Figure 6 shows an exemplary flow from the generation to the verification of a transaction. First, the transaction Tx 1 is generated using the HL script language. Next, the HL script language is converted to the LL script language, and Tx raw is generated. Next, based on Tx raw the transaction identifier TxID 1 is generated. The transaction identifier TxID 1 and the HL transaction Tx 1 are sent to the blockchain node 104. The node 104 receives the transaction identifier TxID 1 and the HL transaction Tx 1 The HL script language may be converted to the LL script language, and then the resulting transaction is the transaction identifier TxID 1 It may be used to generate '. In this option flow, the received transaction identifier and the generated transaction identifier are compared. If they match, node 104 continues to verify the transaction, and vice versa. However, it should be noted that the generation and comparison of transaction identifiers are optional and may be skipped. That is, node 104 may proceed directly to verifying the transaction.

[0181] TxID 1 The transmission of serves as an optional error-checking mechanism that enables node 104 to detect a mismatch between the mapping (from CLS to ELS and from ELS to CLS) used by the transaction generator (e.g., Alice 103a) and the transaction verification node 104. However, an alternative error-checking mechanism may also be used. By including TxID 1 Node 104 can still perform transaction mapping and verification while quickly starting the mining operation (e.g., constructing a Merkle tree based on TxID 1 ).

[0182] Figure 7 shows another exemplary flow of a signed transaction from generation to verification. This flow is similar to the flow in Figure 6, but there is an additional step of signing the transaction after converting from the HL script language to the LL script language. The transaction identifier is based on the signed transaction. First, the transaction lock script is generated by the transaction engine function and described in the HL language. This outputs a transaction Tx 1-unsigned that includes the yet unsigned compact lock script. Usually, the unlock script within the transaction requires a signature for the transaction. To sign the transaction, it is necessary to replace the HL function with an equivalent set of LL functions. Tx 1-unsigned is passed to a mapping module that replaces the HL function with a native LL number, for example an opcode. The mapping module receives Tx 1-unsigned and outputs Tx raw-unsigned , which is passed to the signature module. The transaction signature module receives Tx raw-unsigned and outputs the signed transaction Tx raw . Tx raw is used to generate the transaction identifier TxID. Tx raw is passed back to the mapping module, where the LL function is replaced with the HL function. Optionally, the sender then concatenates the TxID and Tx 1 and sends it to the blockchain. Alternatively, the transaction can be sent alone. Optionally, to check that the mapping used by the receiver is the same as the mapping used by the sender, the receiver maps Tx 1 to Tx raw ' and generates a TxID' and checks whether it is equal to the TxID. If they are the same, the receiver can continue with the verification of the transaction. The TxID is used as a parity check in this instantiation. Note also that this verification of the TxID is optional and instead node 104 may proceed directly to the verification of the transaction.

[0183] Figure 8 shows an exemplary flow of data when sending and verifying a transaction. The HL-enabled transaction creator (e.g., Alice 103a) generates a transaction with a compact lock script. At this point, the transaction is not signed. The compact lock script is replaced with an expanded script and then signed. The signed transaction is hashed to generate a transaction identifier. The expanded lock script is replaced with the compact lock script, and both are sent to the blockchain network 106 (as shown in Figure 8, the transaction identifier may be included within the transaction rather than concatenated with the transaction). The HL-enabled transaction validator (e.g., node 104) receives the transaction and the transaction identifier. The compact lock script is replaced with the expanded lock script, and then optionally, the transaction is hashed to generate a candidate transaction identifier. In this option, the candidate transaction identifier is compared with the received transaction identifier, and if they match, the validator proceeds with the verification of the transaction. If they do not match, the validator discards the transaction. As an alternative option, the HL-enabled node may not need to verify the transaction identifier. Also shown is the non-HL-enabled transaction validator. If only the compact version of the transaction is received, the non-HL-enabled transaction validator cannot verify the transaction. On the other hand, if the expanded transaction is received, the non-HL-enabled transaction validator can verify the transaction. When the transaction is published on the blockchain, the non-HL-enabled validator requests the compiled transaction to verify the transaction.

[0184] 7. Messaging Protocol The above description related to FIGS. 5 to 9 describes a protocol for generating a compact transaction and converting the compact transaction into an expanded transaction. Some or all of the functions described with reference to these figures may also be applicable to the embodiments of FIGS. 10 to 13.

[0185] FIG. 10 summarizes the protocol from the perspective of the CS - usable node 104a that receives a transaction. As shown, the CS - usable node 104a receives a blockchain transaction. If the blockchain transaction is a compact transaction, the compact transaction is processed and verified in its compact form. It should be noted that this may include converting the compact transaction into its expanded (canonical) form. A compact transaction is a transaction that has at least one compact output (i.e., an output with a compact script) and / or at least one input that references the compact outputs of different transactions.

[0186] If the blockchain transaction is an expanded transaction (i.e., a transaction described in a native low - level script language), the expanded transaction is processed and verified in its expanded form. Identification can be done by checking whether there is an explicit protocol flag in the transaction or an implicit indicator such as some HL functions (also called meta - opcodes). The explicit flag may be a pre - determined and agreed - upon transaction version number, or the leading bytes of a lock script or unlock script. The implicit indicator may be the format of the lock script. For example, if the lock script starts with a known HL function (e.g., MOP_LIBLOAD), the corresponding transaction can be identified as a compact transaction.

[0187] FIG. 11 shows an exemplary script execution process. The CS-capable node 104a includes a script engine configured to process scripts in their compact script form, which may include expanding the compact script into an expanded script. As shown in FIG. 11, there are two options. One is to execute the script in its compact script form, and the other is to execute the script in its expanded form.

[0188] FIG. 12 schematically shows the compatibility between the CS-capable node 104a and the CS-incapable node 104b. The CS-capable node 104a needs to broadcast compact transactions only to nodes that can process them. The CS-capable node 104a can receive transactions from both other CS-capable nodes 104a and CS-incapable nodes 104b. On the other hand, the CS-incapable node 104b does not have the function of directly processing compact transactions (it needs to be pre-converted into a regular script). When the CS-capable node 104a sends a compact transaction to the CS-incapable node 104b, problems may occur. In fact, the compact script cannot be interpreted by the CS-incapable node 104b. For example, the CS-incapable node may not be able to verify the transaction using the compact script (see below for details) and ultimately reject the compact transaction.

[0189] FIG. 13 schematically shows a system 1300 for implementing an embodiment of the present invention. The system 1300 includes several CS-capable nodes 104a and several CS-incapable nodes 104b. It will be understood that the system 1300 may include any number of CS-capable nodes 104a and CS-incapable nodes 104b. In this example, the system also includes a user, Alice 103a.

[0190] The CS-available node 104a (for convenience, hereinafter referred to as Charlie 104a) 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, such as Bob 103b. Charlie 104a may additionally or alternatively receive one or more transactions from other nodes 104. At least some of the transactions are compact transactions, that is, transactions with compact scripts.

[0191] At some point, Charlie 104a needs to share at least one of the compact transactions with other nodes including other CS-available nodes 104a and CS-unavailable nodes. Depending on the situation, Charlie 104a may need to send two or more (e.g., all) of the compact transactions to other nodes.

[0192] Taking into account that other CS-available nodes 104a can process compact transactions, Charlie 104a sends the compact transactions directly to other CS-available nodes 104a, that is, the compact transactions are sent in compact form. Then, the other CS-available nodes 104a may execute the compact transactions in compact form, or may choose to expand the compact script of the compact transaction into expanded form and then execute the expanded script (see FIG. 12).

[0193] On the one hand, considering that the CS-inaccessible node 104b cannot process the compact transaction in compact form, Charlie 104a needs to convert the compact transaction into expanded form and send the expanded transaction to the CS-inaccessible node. As described above, the expanded transaction is a transaction with the expanded form of the compact script rather than the compact script itself. The expanded script only consists of low-level scripts, i.e., the native scripts of the blockchain.

[0194] Charlie 104a may choose to automatically send the compact transaction to other CS-capable nodes 104a, i.e., without being required to do so. Alternatively, Charlie 104a may send the compact transaction only to the CS-capable node 104a that requested the compact transaction. Additionally or alternatively, Charlie 104a may automatically send the expanded transaction to the CS-inaccessible nodes 104b or in response to requests from those CS-inaccessible nodes.

[0195] The compact transaction obtained by Charlie 104a may not yet be publicly available in block 151 of the blockchain 150. In that case, Charlie 104a may publicly disclose a new block 151 containing the compact transaction to the blockchain 150. Publicly disclosing block 151 to the blockchain may involve propagating block 151 to other nodes 104 for verification. Charlie 104a may send the compact transaction and the expanded transaction to the CS-capable node 104a and the CS-inaccessible node respectively before or after publicly disclosing block 151. In some cases, publicly disclosing block 151 is the same action as sending the compact transaction to the CS-capable node 104a.

[0196] The CS-capable node 104a may request Charlie 104a for some or all of the compact transactions included in block 151. For example, the CS-capable node 104a may have already received one or more of the compact transactions within block 151. Similarly, if a CS-incapable node determines that it cannot process one or more of the compact transactions within block 151, it may send a request for the expanded version of those transactions to Charlie 104a. Charlie 104a then sends the corresponding expanded transaction to the CS-incapable node.

[0197] Each compact transaction is associated with a transaction identifier (TxID). The transaction identifier is based on the expanded version of the compact transaction, i.e., the corresponding expanded transaction. For example, the TxID can be the hash (e.g., double hash) of the expanded transaction. Further discussion of the TxID is provided below. In some embodiments, Charlie 104a may first send the TxID associated with the compact transaction to the CS-capable node and / or the CS-incapable node. Instead of or in addition to sending the TxID to the node, Charlie 104a may publish the TxID. For example, block 151 published by Charlie 104a may include the TxID. In some examples, block 151 published by Charlie 104a may include the TxID of the compact transaction but not the compact transaction itself.

[0198] Rather than sending or publishing the complete TxID, Charlie 104a may send or publish a compact version of the TxID, e.g., the first n bytes of the TxID. This can be, for example, the first 4 leading bytes of the TxID.

[0199] CS-enabled nodes and / or CS-disabled nodes may use the TxID (or a compressed version thereof) associated with a compact transaction to determine whether a compact transaction or a corresponding expanded transaction is required for that node, respectively. If CS-enabled node 104a requires a compact transaction because it has not yet received a compact transaction, 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 requires an expanded version of a compact transaction because it cannot process the compact form, the CS-disabled node requests the expanded form of the compact transaction from Charlie 104a. In response, Charlie 104a sends the requested expanded transaction to the CS-disabled node.

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

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

[0202] As another example, proof-of-work may be embedded in the TxID associated with a compact transaction. That is, a part of the original transaction (e.g., nonce) may be changed until the hash of the transaction becomes a TxID that meets the target difficulty, for example, the minimum number of leading zeros. When a node receives a TxID having a specific number of leading zeros, the node may interpret that the TxID is associated with a compact transaction. The same applies to the compact TxID.

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

[0204] Another option for determining whether a transaction is a compact transaction is through the use of an implicit indicator, as described above with reference to FIG. 11.

[0205] In some embodiments, Charlie 104a may determine whether a node is a CS-capable node 104a or a CS-incapable node during the peer discovery process. The peer discovery process may include a handshake process during which information about the nodes is exchanged. Alternatively, Charlie 104a may obtain information from other sources, such as a publicly available source such as the blockchain itself or a web page.

[0206] FIG. 13 is described mainly from the perspective of the CS-capable node, Charlie 104a. Next, FIG. 13 will be briefly described from the perspective of a CS-incapable node, called Dennis for convenience. Dennis obtains (e.g., receives) a compact transaction from, for example, Charlie 104a, a user, or a published block 151. Alternatively, Dennis may obtain an indicator indicating that the transaction is a compact transaction. The transaction itself may or may not have been obtained. Dennis determines that it cannot process the compact transaction or the transaction associated with the indicator. Accordingly, Dennis sends a request for the expanded version of the compact transaction to Charlie 104a. In some examples, Dennis may first consider the transaction invalid before sending the request. For example, Dennis first attempts to process the transaction, but as a result, Dennis will consider the transaction invalid. Then, Dennis may send the request. Then, Charlie 104a sends the corresponding expanded transaction to Dennis. Then, Dennis may process (e.g., verify) the expanded transaction or store it for later processing of the expanded transaction. As described above, the indicator may be part of the TxID or the compact TxID associated with the compact transaction, or may be a flag associated with the compact transaction.

[0207] Next, more specific examples will be described.

[0208] The CS-unusable nodes can only process regular scripts, while the CS-usable node 104a can process both compact scripts and regular scripts. Therefore, the CS-usable node 104a needs to know whether neighboring nodes can process compact transactions. Blockchain nodes may notify whether they are CS-usable node 104a during the peer discovery process. New node instances and nodes that have been offline for a while need to find other peers in the network. When a node starts up, it connects to one or more known peers (e.g., those provided as a static list). Once the connection is established, these two nodes exchange a list of neighboring nodes using the addr message. Generally, the connection between two nodes may include a handshake procedure that can exchange some identification information. This information may include some or all of nVersion, nLocalServer, nTime, addrYou, addrMe, subver, and BestHeight. In particular, the subver field (4 bytes) indicates the type of node software executed (e.g., v.1.0.6). Therefore, nodes can use this field to also notify whether the reception of CS opcodes is available. For example, if the regular version is v.1.0.6, the CS-usable version may be v.1.0.6cs or v.1.0.6.1. This is effective and easy to implement because it does not require changing the current handshake procedure.

[0209] The CS-usable node 104a may adopt any of five strategies for broadcasting compact transactions that can be set in the node software configuration file. These strategies are as follows. 1. Preventive CS conversion (broadcast to everyone) 2. On-demand CS conversion (broadcast to CS nodes and respond to everyone) 3. No CS conversion (broadcast to CS nodes and respond to CS nodes) 4. Without CS conversion (without broadcast, responding to all) 5. Without CS conversion (without broadcast, responding to CS nodes)

[0210] Generally, the CS-capable node 104a may choose to broadcast only the TxID. If the receiving node does not have the transaction for that TxID, the receiving node may request the necessary transaction data.

[0211] The CS-capable node 104a configured to perform "preventive CS conversion" first sends the compact transaction to other CS-capable nodes (e.g., according to their subver). Then, the compact transaction is converted to its regular form and sent to the regular nodes. This approach is completely transparent to regular nodes that do not recognize compact scripts and continue to exchange transactions with other nodes (from the perspective of regular nodes, they are all regular nodes).

[0212] The CS-capable node 104a configured to send CS transactions "on demand" sends the compact transaction only to other CS-capable nodes 104a (e.g., according to their subver). When the CS-capable node 104a publishes a block containing a compact transaction, the regular nodes may find that some transactions are missing or invalid (except when receiving the regular version from a node using preventive CS conversion or another regular node). At this point, the regular nodes request the missing transactions from the network, and only at this point does the CS-capable node 104a set to on-demand conversion send the regular script. In other words, this type of CS-capable node 104a does not actively propagate the compact transaction to the regular nodes, but converts the compact transaction to a regular transaction on demand after the block is published.

[0213] This approach is not transparent to regular nodes that cannot verify and "mine" compact transactions. However, this configuration improves the efficiency of CS-enabled node 104a by broadcasting only the most efficient version of each transaction and converting them to the regular format only on demand.

[0214] A CS node configured as "no CS conversion" sends compact transactions only to CS-enabled node 104a. It never converts the compact transactions of regular nodes. This solution is designed for small players and nodes with narrow bandwidth (e.g., shops). They still broadcast and receive regular transactions with regular nodes, but may experience a slowdown when they need to propagate blocks because the regular nodes cannot accept the blocks (until another node converts the compact transactions). Eventually, the regular nodes may disconnect from these nodes (because they may send invalid blocks or broadcast invalid transactions). This may reduce the connectivity of this type of node, so it should be used when the connectivity with other CS-enabled nodes 104a that can broadcast blocks instead is high. Note that no problems occur in the network or the receiving node itself if a CS-enabled node 104a intentionally or accidentally sends a compact transaction to a regular node. The regular node simply uses the compact script to calculate the transaction ID and verifies that it does not match what was sent. At this point, the regular node assumes there was an error in the creation or transmission of the transaction and rejects it.

[0215] Since blockchain nodes often have obvious advantages in terms of storage and bandwidth, they can choose to migrate to CS-enabled software. In fact, in the CS-enabled node 104a, the publication and reception of blocks with several compact transactions are accelerated, and a competitive advantage over regular nodes is obtained (the earlier the block is received, the earlier the mining of new blocks can be started). This is especially true for "on-demand conversion" nodes where the conversion is performed after the block is published, and "no CS conversion" nodes that send the published blocks only to other CS-enabled nodes 104a.

[0216] As the block size increases, it becomes advantageous to send the block in the fastest possible time. To achieve this goal, one option is to send only the transaction ID, or even its compressed version (e.g., only the first 6 bytes). In this scenario, it helps to know whether the transaction ID refers to a compact transaction. Since the information being sent is only the ID, this information can be embedded in the ID. One option to achieve this is to modify the transaction ID, for example, by adding PoW to these IDs (changing part of the transaction until a valid ID is found). For example, the compact transaction ID may need to start with "000" (probability 1 / 4,096) or "0000" (probability 1 / 65,536), but additional bits can also be added to the ID instead. Another approach involves grouping compact transactions, which are then broadcast with a special flag. Identifying compact transactions can be useful when it is decided to use a third-party preprocessing service so that regular software does not reject but convert compact transactions.

[0217] 8. Embodiments This section provides a set of three examples that illustrate how the disclosed framework functions. The first set focuses on the practicality and computational efficiency benefits of using a function table when converting from a high-level (user-facing) language to an intermediate-level (meta-script) language. The second set focuses on the compactness of the meta-script language. The third set provides insights into some more complex scripts. The third set also shows how scripts written in a high-level language can be directly converted to a low-level native script language.

[0218] 8.1 Exemplary Set 1: This example shows how a function table can be used to convert a script written in a high-level language to a compact meta-script. The exemplary script reverses the characters of an input string.

[0219] [Table 13]

[0220] Next, the high-level language is compiled into the intermediate-level language, where the function table and variable table are referenced or created. The function table and variable table are decentralized and can be stored locally. In some examples, once created, the variable table is readable and writable, while the function table is only readable. Examples include the following.

[0221] [Table 14]

[0222] This exemplary function table has two functions with function IDs 0 and 1. The first function calculates the size of the input string, and the second function calls the first function and then reverses the string. The description of function 1 is as follows.

[0223] $0 refers to the first input to a script that has not yet been provided. It may become the top item on the stack. 0 MOP_FN_CALL is the syntax to call the function with function ID 0 in the function table. After executing $0 0 MOP_FN_CALL, the length of the input remains at the top of the stack. 1 OP_SUB subtracts 1 from the top value on the stack and leaves the result at the top of the stack. 0 MOP_SET_VAR assigns the topmost element of the stack to the variable at index 0 in the variable table. This variable can be used for the rest of the execution. 0 MOP_GET_VAR pushes the value of the variable at 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_1 OP_SPLIT MOP_END_BLOCK consumes the first value on the stack and loops the commands between MOP_LOOP and MOP_END_BLOCK that number of times. After executing 0 MOP_GET_VAR MOP_LOOP OP_1 OP_SPLIT MOP_END_BLOCK, the string is split into half-width substrings. Similarly, 0 MOP_GET_VAR MOP_LOOP OP_SWAP OP_CAT MOP_END_BLOCK swaps the order of the substrings and concatenates them to form a string that is the reverse of the input string.

[0224] Note that it is not necessary to input a value when creating the variable table. This functions like a placeholder for function execution. This allows values to be stored and passed during execution.

[0225] The same result can be obtained using a "while" loop.

[0226]

Table 15

[0227]

Table 16

[0228] There are two variables here, 1 and COUNTER. It is proposed that COUNTER can be a reserved variable with a default value. That is, COUNTER can be directly called in the meta-script. When called in a "while" loop, the value starts from 0 and increases by 1 for each loop.

[0229] Next, how the "while" loop functions will be explained.

[0230] MOP_LOOP_IF COUNTER 0 MOP_GET_VAR LESSTHAN MOP_END_BLOCK starts the loop when the counter is less than the variable at index 0. The counter is a reserved variable with a default value. That is, COUNTER can be directly called within the meta-script. The executed loop is implicitly counted, starting from 0 and increasing by 1 each time. Execution ends the "while" loop when the counter reaches the maximum value set by the high-level language or the default value, or when the condition is not met. In this case, the variable at index 0 is the length of the input string. Generally, any condition can follow MOP_LOOP_IF, and the condition ends with MOP_END_BLOCK. OP_1 OP_SPLIT is repeatedly executed when the condition is met. Note that this is not included in the function table to indicate that there is an option not to include all words defined in the high-level language. As a general method, if a function is frequently referenced, that function is included in the function table.

[0231] MOP_END_BLOCK indicates the end of the repeated code. After executing MOP_LOOP_IF COUNTER 1 MOP_GET_VAR LESSTHAN MOP_END_BLOCK OP_1 OP_SPLIT MOP_END_BLOCK, the string is split into single-byte substrings.

[0232] Similarly, MOP_LOOP_IF COUNTER 1 MOP_GET_VAR LESSTHAN MOP_END_BLOCK OP_SWAP OP_CAT MOP_END_BLOCK rearranges the order of substrings and concatenates them to form a string that is the reverse of the input string.

[0233] Middle-level language (meta-script) Assume that the string "I am fish" is input to the inverse function. The meta-script would be as follows.

[0234] [Table 17]

[0235] Next, the meta-script is embedded in a transaction (as a lock script). The transaction is sent and stored in meta-script form.

[0236] The meta-script can be executed directly using a meta-script 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 the function. The output is the reverse of the input string.

[0237] The meta-script can also be expanded into native form to generate a transaction ID, verify a signature, or specify a function table for execution in a native script engine.

[0238] When deploying this exemplary script, assume that the input (unlock script) is known to the script creator or that the script creator has set a maximum loop counter to prevent infinite loops.

[0239] Low-level language (e.g., Bitcoin opcodes) When the meta-script is expanded, all loops are resolved and only native opcodes are permitted. As an example, there is the following native script corresponding to the previous exemplary meta-script.

[0240]

Table 18

[0241] Note that the size of the regular script increases linearly with the size of the input string. However, the size of the meta-script is approximately constant and does not depend on the size of the input string. This indicates that the meta-script framework significantly saves storage and bandwidth.

[0242] 8.2 Exemplary Set 2: In this first example, the characters within the input string are also reversed. This example shows how the same function can be implemented without using the function table described. In this example, a high-level inverse function is compiled into the meta-script. For example, the compiler is configured to read the function "reverse()" and compile the corresponding meta-script. As a specific example, the mapping of the high-level function to the meta-script can be stored in the memory accessible to the compiler.

[0243] High-level language (i.e., user-oriented language)

[0244]

Table 19

[0245] (31 bytes if saved as a txt file (source code) Intermediate-level language (meta-script):

[0246]

Table 20

[0247]

Table 21

[0248] As an example, c0 is used for meta_loop, d1 for one_split, and e2 for swap_cat. Note that "76 09" pushes 9 bytes of data to the top of the stack. 2 (push data) + 9 (data) + 6 = 17 bytes in the meta script When compiling from a high-level language, the meta script obtains from the compiler the number of loops required to reverse the string. In this case, the number of loops is the length of the string - 1.

[0249] Low-level language (Bitcoin opcode / native script)

[0250]

Table 22

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

[0252] If the input to a function is not available during compilation, the number of loops may also not be available. In this case, the meta script is designed to obtain information from the unlock script or assume a default maximum value. For example, Lock script (function) in high-level language: reverse() Lock script (function) in meta script: meta_var meta_assignVar meta_var meta_loop one_split meta_var meta_loop swap_cat The unlock script (input to the function) is It can be made 8.

[0253] Before converting to Bitcoin opcodes (native script), "8 meta_var meta_assignVar" assigns the value "8" to a variable named "meta_var". After this assignment, each time "meta_var" appears, it is replaced with "8". Thus, as soon as the input is given, the same metascript as above is created. Note that only two additional bytes are introduced to assign the variable.

[0254] In this example, the function finds the greatest common divisor (GCD) of two integers. High-level language:

[0255] [Table 23]

[0256] 17 bytes Intermediate-level language:

[0257] [Table 24]

[0258] [Table 25]

[0259] 13 bytes Low-level language:

[0260] [Table 26A]

[0261] [Table 26B]

[0262] 49 bytes

[0263] When the number is large, savings become even more important.

[0264] Also, when dealing with complex functions such as point addition and scalar multiplication of elliptic curves, it becomes on the order of 10 bytes in a meta-script (intermediate-level language) and on the order of several megabytes in a native script (low-level language).

[0265] The method of assigning meta-variables in a meta-script was briefly described. In this section, the mechanism for assigning variables in a native script is introduced. High-level language: var = 5 return var + var

[0266] Intermediate-level language 5 var meta_assign var op_add

[0267] Low-level language 5 OP_TOALTSTACK OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_ADD

[0268] When converting to a native script (such as Bitcoin opcodes), "5 var meta_assign" becomes "5 OP_TOALTSTACK", which assigns the value "5" to a variable named "var". After this assignment, each time "var" appears, it is converted to "OP_FROMALTSTACK OP_DUP OP_TOALTSTACK". The alt stack becomes a stack for storing all variables (as an ordered list).

[0269] 8.3 Exemplary Set 3: In the following example, the HL script is directly converted to the LL script, i.e., there are only two levels of the script language, high level and low level.

[0270] GCD is a function that takes two integers a and b as input and outputs GDC(a, b). This is realized using the Euclidean algorithm, which can be described as follows. 1. Let a = x and b = y. 2. When x and y are given, use the division algorithm to write x = yq + r, where 0 ≤ r < |y|. 3. If r = 0, stop and output y. This is the gcd of a and b. 4. If r ≠ 0, replace (x, y) with (y, r). Go to step 2.

[0271] The above algorithm can be easily described and executed using a high-level programming language. However, it is not an easy task to execute the Euclidean algorithm using Bitcoin opcodescript. Since the expanded script does not permit loops, it is necessary to repeatedly use the OP_IF statement to describe each loop.

[0272] The following script obtains the top two digits x and y on the main stack, where y is the topmost, leaves y and r on the stack, and x = yq + r.

[0273] [Table 27]

[0274] The algorithm can be described as follows.

[0275] [Table 28]

[0276] In the above example, when it can be calculated in three loops, find the GCD of two positive integers. If more loops are required for the input, more if statements need to be described. This means that when the input is not known in advance when Alice wants to execute the algorithm, it is necessary to define the maximum number of if statements of sufficient size to handle the input range. Suppose you want to set this to 100 or more. What will happen if very large-scale transactions occur in the compiled script?

[0277] In this example, Alice needs to specify the maximum number of iterations, and the SDL available nodes can generate accurate transactions in the expansion script.

[0278] When the above algorithm is defined as a function / library function / forth word, it is described as follows. Initial state of the stack: Final state of the stack: <r>, Initial state of Altstack: Unused Final state of Altstack: Unused Calculation: a = qb + r, or r = a mod b

[0279] FUNCTION_1-< / r> Receive, is <r> <q>Return, where a = b * q + r Initial state of the stack:< / q> < / r> / / is the top of the stack Final state of the stack: <q> Initial state of Altstack: Unused Final state of Altstack: <d> / / is the start of the altstack OP_TUCK OP_2DUP OP_MOD OP_DUP OP_TOALTSTACK OP_SWAP OP_TOALTSTACK OP_SUB OP_SWAP OP_DIV

[0280] The above can be described as an HL function in the HL language as follows. HL function qr(){TUCK 2DUP MOD DUP TAS SWAP TAS - SWAP / }

[0281] Using the HL script language, HL functions can be defined. Also, OP_CODES can be described in a user - friendly and efficient way. In the above example, TUCK DUP SWAP correspond to OP_TUCK OP_DUP OP_SWAP, FAS and TAS correspond to OP_FROMALTSTACK and OP_TOALTSTACK, and + - * / % correspond to OP_ADD OP_SUB OP_MUL OP_DIV and OP_MOD, etc.

[0282] The HL function qr() retrieves the top two values on the main stack and returns the quotient and the remainder. That is, < / d> < / q> and Obtain, <q>and <r>Calculate, and a = b * q + r.

[0283] FUNCTION_2 - 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 One loop to calculate. This example starts the stack using the initial values s i-2 , t i-2 , s i-1 , t i-1 , q i The algorithm starts at i = 2, and s 0 = 1, t 0 = 0, s 1 = 0, t 1 = 1. Initial state of the stack: <s i-2 ><t i-2 ><s i-1 ><t i-1 ><q i > / / <q i > is the top of the stack Final state of the stack: <s i-1 ><t i-1 ><s i ><t i > Initial state of the Altstack: Unused Final state of the Altstack: Unused OP_DUP 3 OP_PICK OP_MUL 5 OP_ROLL OP_SWAP OP_SUB OP_SWAP 2 OP_PICK OP_MUL 4 OP_ROLL OP_SWAP OP_SUB

[0284] The above can be described in the HL language as follows. HL function st(){DUP 3 PICK * 5 ROLL SWAP - SWAP 2 PICK * 4 ROLL SWAP -} The HL function st() calculates the parameters s and t used in the following calculation of the extended Euclidean algorithm.

[0285] The following example shows a way to implement the extended Euclidean algorithm. This function< / r> < / q> Receive s n and t n Calculate gcd(a, b), where gcd(a, b) = s n a + t n equals b Initial state of the stack: / / is the top of the stack, a > b, and both are +ve integers Final state of the stack: <s n ><t n > gcd(a, b) / / gcd(a, b) at the top of the stack Initial state of the Altstack: unused Final state of the Altstack: … FUNCTION_1 1 0 0 1 4 OP_ROLL FUNCTION_2 OP_FROMALTSTACK OP_FROMALTSTACK OP_DUP OP_IF FUNCTION_1 FUNCTION_2 OP_FROMALTSTACK OP_FROMALTSTACK OP_DUP OP_IF FUNCTION_1 FUNCTION_2 OP_FROMALTSTACK OP_FROMALTSTACK OP_DUP OP_IF FUNCTION_1 FUNCTION_2 … … OP_ENDIF OP_ENDIF OP_ENDIF OP_DROP OP_NIP OP_NIP

[0286] The HL function EEA is the extended Euclidean algorithm. In this example, the words qr() and st() are executed 25 times in a loop. HL function qr(){TUCK 2DUP MOD DUP TAS SWAP TAS - SWAP / } HL function st(){DUP 3 PICK * 5 ROLL SWAP - SWAP 2 PICK * 4 ROLL SWAP-} HL function EEA(a, b){ a b qr() 1 0 0 1 4 ROLL st() FAS FAS let l=25 loop (l) {DUP IF qr() st() FAS ENDIF} DROP NIP NIP} EEA (in1, in2)

[0287] This is an example of HL script language code. A loop is used to repeat the function up to 25 times. This can be set to a greater number of times by simply changing the variable l. For example, l can be set to a number in the hundreds or thousands as needed. The size of the CLS does not change, but the size of the corresponding ELS becomes megabytes.

[0288] 9. Further Considerations Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0289] For example, some of the above embodiments have been described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is a particular example of the blockchain 150 and the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, the above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may each be replaced with references to a blockchain network 106, a blockchain 150, and a blockchain node 104, respectively. A blockchain, a blockchain network, and / or a blockchain node may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

[0290] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 implements at least all of the above-described functions of creating, publishing, propagating, and storing the block 151 of the blockchain 150. The possibility that there are other network entities (or network elements) that implement only one or some, but not all, of these functions is not excluded. That is, a network entity may implement the function of propagating and / or storing a block without creating and publishing the block (it should be remembered that these entities are not considered nodes of the preferred Bitcoin network 106).

[0291] 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 a node may implement at least one or some, but not all, of the functions of creating, publishing, propagating, and storing the block 151 of the blockchain 150. For example, in those other blockchain networks, the term "node" may be used to refer to a network entity configured to create and publish the block 151 but not store and / or propagate those blocks 151 to other nodes.

[0292] Even more generally, the reference to the term "Bitcoin node" 104 above may be replaced with the term "network entity" or "network element", and such an entity / element is configured to perform some or all of the roles of block creation, publication, propagation, and storage. The functions of such network entities / elements can be implemented in hardware in the same way as described above with reference to the blockchain node 104.

[0293] It should be understood that the above embodiments are described merely as examples. More generally, a method, apparatus, or program may be provided in accordance with any one or more of the following statements.

[0294] Statement 1. A computer-implemented method for sending a blockchain transaction to a node of a blockchain network, the blockchain network comprising one or more compact script (CS)-capable nodes and one or more CS-incapable nodes, each CS-capable node being configured to process a compact transaction, each CS-incapable node not being configured to process a compact transaction, the compact transaction being a blockchain transaction comprising i) a CS that is at least partially described in a high-level (HL) script language and comprises one or more HL functions, and / or ii) an input that references an output comprising a CS, and when executed, each HL function being configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of a low-level (LL) script language, the CS being configured to perform an operation equivalent to an operation performed by a deployed script (ES) described in the LL script language, the method being performed by a first CS-capable node, obtaining a set of compact transactions; sending one or more of the set of compact transactions to at least one other CS-capable node; converting one or more of the set of compact transactions into one or more respective deployed transactions, the converting step comprising replacing the CS of a given compact transaction with an equivalent ES for that compact transaction; and sending the one or more deployed transactions to at least one CS-incapable node.

[0295] The LL script language is a native blockchain script language. The CS can be fully described in the HL script language. Alternatively, the CS can be partially described in the HL script language and partially described in another script language, such as the LL script language. One or both of the HL script language and the LL script language can be stack-based script languages.

[0296] Statement 2. The method according to Statement 1, comprising the step of receiving, from at least one CS-incompatible node, a first request for one or more expanded transactions corresponding to one or more compact transactions, and the step of sending the one or more expanded transactions to the at least one CS-incompatible node is performed in response to the receipt of the first request.

[0297] Statement 3. The method according to Statement 1 or 2, comprising the step of receiving, from at least one CS-compatible node, a second request for one or more compact transactions, and the step of sending the one or more compact transactions to the at least one CS-compatible node is performed in response to the receipt of the second request.

[0298] Statement 4. The method according to any one of Statements 1 to 3, comprising the step of publishing a block to the blockchain network, the block comprising a set of compact transactions.

[0299] Statement 5. The method according to Statement 4 when dependent on Statement 2, wherein the step of publishing the block is performed before the step of receiving the first request and the step of sending the one or more expanded transactions.

[0300] Statement 6. The method according to statement 4 when the step of publishing the block is carried out before the step of receiving the second request and the step of sending one or more compact transactions and is subordinate to statement 3.

[0301] Statement 7. The method according to any one of statements 1 to 3, wherein each compact transaction is associated with a respective transaction identifier based on a corresponding deployment transaction, and the method comprises the step of making the respective transaction identifiers of the set of compact transactions available to at least one CS-capable node and / or at least one CS-incapable node.

[0302] Statement 8. The method according to statement 7 when the step of making the respective transaction identifiers available is carried out before the step of receiving the first request and the step of sending one or more deployment transactions and is subordinate to statement 2.

[0303] Statement 9. The method according to statement 7 when the step of making the respective transaction identifiers available is carried out before the step of receiving the second request and the step of sending one or more compact transactions and is subordinate to statement 3.

[0304] Statement 10. The method according to any one of statements 7 to 9, wherein the step of making the respective transaction identifiers available comprises the step of sending the respective transaction identifiers to at least one CS-capable node and / or at least one CS-incapable node.

[0305] Statement 11. The step of making each transaction identifier available comprises the step of publishing a block to the blockchain network, the block comprising each transaction identifier of a set of compact transactions, but not the compact transactions themselves, the method according to any one of Statements 7 to 10.

[0306] Statement 12. The step of making each transaction identifier available comprises the step of making available a respective compressed version of each transaction identifier, the method according to any one of Statements 7 to 11.

[0307] Statement 13. The respective compressed version of each transaction identifier comprises a part of each transaction identifier, but not all of it, the method according to Statement 12.

[0308] Statement 14. Each transaction identifier of a compact transaction comprises an indication that each compact transaction is a compact transaction, the method according to any one of Statements 7 to 13.

[0309] Statement 15. The indication is an additional bit combined with each transaction identifier of each compact transaction, the method according to Statement 14.

[0310] Statement 16. The indication is the minimum amount of proof of work embedded in each transaction identifier by changing a part of each compact transaction, the method according to Statement 15.

[0311] Statement 17. The method according to any one of Statements 1 to 16, wherein one or more compact transactions are sent to at least one other CS-usable node together with a flag indicating that the one or more compact transactions are compact transactions.

[0312] Statement 18. The method according to any one of Statements 1 to 17, comprising the step of receiving, from at least one CS-usable node, an indication that the at least one CS-usable node is a CS-usable node.

[0313] Statement 19. The method according to Statement 18, wherein the step of receiving the indication is during a handshake process.

[0314] Statement 20. The method according to Statement 18, comprising the step of determining that a CS-unusable node is not a CS-usable node based on not receiving an indication that the at least one CS-unusable node is a CS-usable node.

[0315] Statement 21. The method according to any one of Statements 1 to 20, wherein the step of obtaining a set of CS transactions comprises the step of receiving at least one compact transaction from a user and / or receiving at least one compact transaction from a different CS-usable node.

[0316] Statement 22. a memory comprising one or more memory units, a processing device comprising one or more processing units and configured such that the memory stores code configured to be executed on the processing device, and when the code is on the processing device, the code is configured to perform the method according to any one of Statements 1 to 21.

[0317] Statement 23. A computer program embodied on a computer-readable storage and configured to perform the method according to any one of Statements 1 to 21 when executed on one or more processors.

[0318] Statement 24. A computer-implemented method of receiving a blockchain transaction from a node of a blockchain network, the blockchain network comprising one or more compact script (CS)-capable nodes and one or more CS-incapable nodes, each CS-capable node being configured to process a compact transaction, each CS-incapable node not being configured to process a compact transaction, the compact transaction being a blockchain transaction comprising i) a CS that is at least partially described in a high-level (HL) scripting language and comprises one or more HL functions, and / or ii) an input that references an output comprising a CS, and when executed, each HL function being configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of a LL scripting language, the CS being configured to perform an operation equivalent to an operation performed by an expanded script (ES) described in the LL scripting language, the method being performed by a CS-incapable node, obtaining a compact transaction, or an indication that the compact transaction is a compact transaction; determining, based on the obtained compact transaction or indication thereof, that the compact transaction cannot be processed by the CS-incapable node; sending a request for an expanded transaction corresponding to the compact transaction to a CS-capable node; receiving an expanded transaction from the CS-capable node, the expanded transaction comprising an ES equivalent to the CS of the compact transaction.

[0319] The method according to statement 24, comprising the step of executing the ES of the deployment transaction received from the CS available node in statement 25.CS.

[0320] The method according to statement 24 or 25, wherein the compact transaction or its display is directly obtained from the CS available node.

[0321] The method according to any one of statements 24 to 26, wherein the compact transaction or its display is obtained from the publicly available block of the blockchain.

[0322] The method according to any one of statements 24 to 27, wherein the display is a transaction identifier associated with the compact transaction or a flag associated with the compact transaction.

[0323] The method according to statement 28, wherein the step of obtaining the transaction identifier comprises the step of obtaining a compressed version of the transaction identifier.

[0324] Statement 30. A memory comprising one or more memory units, A processing device comprising one or more processing units A computer device comprising a code stored so as to be executed on the processing device, and configured to implement the method according to any one of statements 24 to 29 when the code is on the processing device.

[0325] A computer program embodied on a computer-readable storage and configured to implement the method according to any one of statements 24 to 29 when executed on one or more processors.

Description of Symbols

[0326] 100 System 101 Packet Switching Network 102 Computer Equipment 102a Computing Device 102a Computer Equipment 102b Computer Equipment 103 Party 103 User 103a User 103a Alice 103a The First Party 103b The Second Party 103b Bob 104 Bitcoin Node 104 Blockchain Node 104a CS-Available Node 104a Charlie 104b CS-Unavailable Node 105 Client 105 Client Application 105a Client Application 105b Client 106 Peer-to-Peer (P2P) Network 106 Blockchain Network 106 Bitcoin Network 107 Side Channel 150 Blockchain 151 Data Block 151 New Block 151n-1 Block 152 Transaction 152i Previous Transaction 152j Current Transaction 153 Genesis Block (Gb) 154 Ordered Set (or "Pool") 155 Block Pointer 201 Header 202 Input 202 Input Field 203 Output 203 Output Field 401 Transaction Engine 402 User Interface (UI) Layer 403 Function 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Blockchain Related Functional Module 455 Function 455C Consensus Module 455P Propagation Module 455S Memory Module 500 User Interface (UI) 500 System 501 UI Element 501 User Selectable Element 502 UI Element 502 Data Input Field 503 UI Element 503 Information Element 1300 System < / cls> < / els>

Claims

Claim 1 A computer-implemented method for sending blockchain transactions to nodes of a blockchain network, wherein the blockchain network comprises one or more compact script (CS)-capable nodes and one or more CS-incapable nodes, each CS-capable node being configured to process compact transactions, each CS-incapable node not being configured to process compact transactions, a compact transaction being a blockchain transaction that i) is at least partially described in a high-level (HL) scripting language and comprises one or more HL functions, and / or ii) comprises an input that references an output that comprises a CS, and when executed, each HL function is configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of a LL scripting language, the CS being configured to perform an operation equivalent to an operation performed by an expanded script (ES) described in the LL scripting language, the method being performed by a first CS-capable node, obtaining a set of compact transactions; sending one or more of the set of compact transactions to at least one other CS-capable node; converting one or more of the set of compact transactions into one or more respective expanded transactions, the converting step comprising replacing the CS of a given compact transaction with an equivalent ES for that compact transaction; sending the one or more expanded transactions to at least one CS-incapable node and a computer-implemented method. Claim 2 The method according to claim 1, further comprising receiving, from the at least one CS-incapable node, a first request for the one or more expanded transactions corresponding to the one or more compact transactions, the step of sending the one or more expanded transactions to the at least one CS-incapable node being in response to the receipt of the first request. Claim 3 comprising receiving, from the at least one CS-capable node, a second request for the one or more compact transactions, wherein the step of sending the one or more compact transactions to the at least one CS-capable node is in response to the receipt of the second request, the method according to claim 1 or 2.

4. comprising publishing a block to the blockchain network, the block comprising the set of compact transactions, the method according to any one of claims 1 to 3.

5. The method according to claim 4, when dependent on claim 2, wherein the step of publishing the block is performed before the step of receiving the first request and the step of sending the one or more expanded transactions.

6. The method according to claim 4, when dependent on claim 3, wherein the step of publishing the block is performed before the step of receiving the second request and the step of sending the one or more compact transactions.

7. each compact transaction being associated with a respective transaction identifier based on the corresponding expanded transaction, the method comprising making the respective transaction identifiers of the set of compact transactions available to the at least one CS-capable node and / or the at least one CS-incapable node, the method according to any one of claims 1 to 3.

8. The method according to claim 7, when dependent on claim 2, wherein the step of making the respective transaction identifiers available is performed before the step of receiving the first request and the step of sending the one or more expanded transactions.

9. The method according to claim 7, when dependent on claim 3, wherein the step of making the respective transaction identifiers available is performed before the step of receiving the second request and the step of sending the one or more compact transactions.

10. The step of making the respective transaction identifiers available comprises the step of sending the respective transaction identifiers to the at least one CS-enabled node and / or the at least one CS-disabled node, according to any one of claims 7 to 9.

11. The step of making the respective transaction identifiers available comprises the step of publishing a block to the blockchain network, the block comprising the respective transaction identifiers of the set of compact transactions but not the compact transactions themselves, according to any one of claims 7 to 10.

12. The step of making the respective transaction identifiers available comprises the step of making available a respective compressed version of the respective transaction identifiers, according to any one of claims 7 to 11.

13. A respective compressed version of each transaction identifier comprises a part of the respective transaction identifier but not all of it, according to claim 12.

14. The respective transaction identifiers of the compact transactions comprise an indication that the respective compact transactions are compact transactions, according to any one of claims 7 to 13.

15. The indication is additional bits combined with the respective transaction identifiers of the respective compact transactions, according to claim 14.

16. The indication is the minimum amount of proof of work embedded in the respective transaction identifiers by changing a part of the respective compact transactions, according to claim 15.

17. The one or more compact transactions are sent to the at least one other CS-enabled node together with a flag indicating that the one or more compact transactions are compact transactions, according to any one of claims 1 to 16.

18. The method according to any one of claims 1 to 17, comprising the step of receiving, from the at least one CS-capable node, an indication that the at least one CS-capable node is a CS-capable node.

19. The method according to claim 18, wherein the step of receiving the indication is during a handshake process.

20. The method according to claim 18, comprising the step of determining that the CS-incapable node is not a CS-capable node based on not receiving an indication that the at least one CS-incapable node is a CS-capable node.

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

22. A memory comprising one or more memory units, A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, and when the code is on the processing device, is configured to perform the method according to any one of claims 1 to 21.

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

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)-capable nodes and one or more CS-incapable nodes, each CS-capable node being configured to process a compact transaction, each CS-incapable node not being configured to process a compact transaction, a compact transaction being a blockchain transaction that i) comprises a CS that is at least partially described in a high-level (HL) scripting language and comprises one or more HL functions, and / or ii) comprises an input that references an output that comprises a CS, and when executed, each HL function is configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of a LL scripting language, the CS being configured to perform an operation equivalent to an operation of an expanded script (ES) described in the LL scripting language, the method being performed by a CS-incapable node, obtaining a compact transaction, or an indication that the compact transaction is a compact transaction; determining, based on the obtained compact transaction or indication thereof, that the compact transaction cannot be processed by the CS-incapable node; sending a request for an expanded transaction corresponding to the compact transaction to a CS-capable node; receiving the expanded transaction from the CS-capable node, the expanded transaction comprising an ES equivalent to the CS of the compact transaction; A computer-implemented method comprising. Claim 25 The method according to claim 24, comprising the step of executing the ES of the expanded transaction received from the CS-capable node. Claim 26 The method according to claim 24 or 25, wherein the compact transaction or indication thereof is obtained directly from a CS-capable node. Claim 27 The method according to any one of claims 24 to 26, wherein the compact transaction or indication thereof is obtained from a publicly available block of the blockchain. Claim 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 a flag associated with the compact transaction. **Claim 29** The method according to claim 28, wherein the step of obtaining the transaction identifier comprises obtaining a compressed version of the transaction identifier. **Claim 30** A memory comprising one or more memory units, and A processing device comprising one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured to perform the method according to any one of claims 24 to 29 when on the processing device. **Claim 31** A computer program embodied on a computer-readable storage and configured to perform the method according to any one of claims 24 to 29 when executed on one or more processors.

Images