Protocol for Communicating Compact Scripts

Abstract

A computer-implemented method for sending a compact transaction, the compact transaction being a blockchain transaction comprising a compact script at least partially described in an intermediate-level scripting language, the method comprising: generating a first compact transaction comprising a first CS, the first CS being a first library identifier of a first high-level reference library, the first HL reference library comprising a first set of HL functions described in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a respective set of one or more LL functions; a step comprising a first library identifier of a first high-level reference library, one or more respective function identifiers of the first set of HL functions, and at least one IL function configured to call one or more HL functions during script execution; and sending the first compact transaction to at least one node in which the CS is enabled, each node in which the CS is enabled being configured to verify the compact transaction.

Description

Technical Field

[0001] The present disclosure relates to a method for sending a compact blockchain transaction to a node of a blockchain network and a method for processing a compact blockchain transaction.

Background Art

[0002] A blockchain refers to a form of a distributed data structure, and replicated copies of the blockchain are maintained and widely publicized at each of a plurality of nodes within a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). The blockchain comprises a chain of blocks of data, 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", that is, solving a cryptographic puzzle based on a defined set of representations of 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 through the disclosure of only the 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 putting 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 additional user data or an index of 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 data 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 receiving 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 known as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Usable outputs comprise elements that specify the amount of digital assets derived from the sequence of the transaction's progression. Usable outputs are sometimes referred to as UTXOs ("unspent transaction outputs"). Outputs may further comprise a lock script that specifies conditions for the exchange of future outputs. The 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 preceding 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 transactions. 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 is sometimes 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 containing scripts are sent between the generating side (e.g., user or machine) and the nodes of the network for transaction verification. Depending on the use case, transactions can also be sent off-chain, for example, from user to user or from machine to machine. Further, transactions are propagated throughout the blockchain network by the nodes themselves. Additionally, at least some nodes need to (or at least choose to) store the transactions 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 sending and storing transactions, respectively. This is generally true for all blockchains. In some blockchains, there are limits on the size of transactions, the size of the scripts within the transactions, and the size of the blocks. In contrast, in at least one blockchain (e.g., Bitcoin SV), there is no limit on the script size of transactions 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 they need to store. Therefore, when sending and storing transactions 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 in 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 would normally 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] Scripts written in a high-level language have a compact nature compared to scripts written in a native low-level language and are thus called "compact scripts", while 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 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 and new high-level functions, or may include only high-level functions completely independent of such functions.

[0019] As described below, transactions using large-scale 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 the corresponding list of 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 other type of party or entity) may generate a script in the user-facing language, which is then converted (e.g., compiled) into the intermediate language. 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 analogize the user-facing language, the intermediate-level language, and the 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] Depending on the implementation, the highest-level language (or a script written in the highest-level language that is a 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 the 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 written in a user-friendly way while maintaining the security of the blockchain. A blockchain node using the techniques described in UK Patent No. 2019748.9, or equivalent techniques, can gain significant benefits in terms of improved efficiency in computing and substantial reduction in bandwidth and storage requirements.

[0024] This application discloses techniques for using a library of functions that can be referenced in the lock and / or unlock scripts of blockchain transactions comprising compact scripts, thereby enabling efficient communication of compact scripts between blockchain nodes and lock script creators.

[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. Depending on the location, 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 canonical form. Note that all compact transactions have a corresponding expanded (i.e., canonical) form, but not all canonical transactions necessarily have a compact form. A blockchain node enabled with a compact script (CS) is a node that can process (e.g., verify) compact transactions. This may also be abbreviated as an MS node. Conversely, a node with a compact script disabled is a node that cannot process compact transactions. This may also be referred to as a canonical node.

[0026] According to one aspect disclosed in this specification, a computer-implemented method for sending a compact transaction to a node in a blockchain network is provided. The compact transaction is a blockchain transaction comprising a compact script (CS) that is at least partially described in an intermediate level (IL) script language and includes one or more IL functions. When executed, each IL function is configured to perform an operation equivalent to an operation performed by one or more low level (LL) functions in the LL script language, and the CS is configured to perform an operation equivalent to an operation performed by an expanded script (ES) described in the LL script language. The method is performed by a first party and includes generating a first compact transaction comprising a first CS, where the first CS comprises: i) a first library identifier of a first high level (HL) reference library, the first HL reference library comprising a first set of HL functions described in the HL script language, each HL function being configured to perform an operation equivalent to an operation performed by a respective set of one or more LL functions; ii) one or more respective function identifiers of the first set of HL functions; and iii) at least one IL function configured to call one or more HL functions during script execution; and sending the first compact transaction to at least one node in which the CS is enabled, each node in which the CS is enabled being configured to verify the compact transaction.

[0027] According to one aspect disclosed in this specification, a computer-implemented method for processing a compact transaction is provided. The compact transaction is a blockchain transaction that is at least partially described in an intermediate level (IL) scripting language and includes a compact script (CS) with one or more IL functions. When executed, each IL function is configured to perform an operation equivalent to the operation performed by one or more low-level (LL) functions of the LL scripting language, and the CS is configured to perform an operation equivalent to the operation of the expansion script (ES) described in the LL scripting language. The method is implemented by a node configured to verify the compact transaction and enabled with the CS, and includes the step of obtaining a first compact transaction with a first CS, where the first CS includes: i) a first library identifier of a first high-level (HL) reference library, the first HL reference library including a first set of HL functions described in the HL scripting language, each HL function being configured to perform an operation equivalent to the operation performed by each set of one or more LL functions; ii) one or more function identifiers of the first set of HL functions; and iii) at least one IL function configured to call one or more HL functions during script execution; the step of obtaining the first HL reference library; and the step of processing the first compact transaction, where the step of processing includes the step of generating an expanded version of the first compact transaction by converting the first CS into a first ES, and the converting includes replacing each function identifier with each set of one or more LL functions configured to perform the same operation as the respective HL function.

[0028] A first party (e.g., a user, a machine, a smart contract, etc.) creates a compact transaction with a compact script. For convenience, the first party is called Alice. Alice can access a high-level (HL) reference library, i.e., a set of HL functions described in an HL script language (e.g., the aforementioned user-oriented language, etc.). Note that the reference to the HL script language is a reference to the highest-level script language. The HL functions of a given library may be related in that they are related to the same purpose or interact with other functions to achieve a common goal. However, this is not essential. For example, a given library may comprise a set of HL functions created by a particular party, e.g., Alice. Alice includes in the compact script a reference to the HL reference library or an identifier of the HL reference library. Alice also includes in the compact script the function identifier of each of one or more HL functions stored in the HL reference library.

[0029] Each HL function can be expanded into LL functions (e.g., opcodes). Thus, each HL function is configured to perform an operation equivalent to the operation performed by a group of LL functions. Each HL function is defined in the library using at least its respective set of LL functions. An HL function may be defined using only its respective set of LL functions. This may be the case, for example, for a simple HL function. In other examples, an HL function may be defined using both its respective set of LL functions and one or more additional HL functions. That is, a given HL function may refer to (i.e., require or otherwise utilize) other HL functions. This may be the case for more complex functions. In that case, the reference library may include the definition of each of the other HL functions. The definition of one or more HL functions may also be known to one, some, or the nodes when the CS is enabled. This may be the case for common or standard HL functions defined by a common protocol executed by each node when the CS is enabled.

[0030] The combination of the library reference and the function identifier enables a node with CS enabled and other parties to identify the HL functions used during the processing (e.g., verification) of a compact transaction. That is, a node with CS enabled can identify the library corresponding to the library reference and then identify the required HL functions from that library.

[0031] The compact script also includes one or more IL functions configured to call the identified HL functions. The compact script may include a single "call function" for this purpose, or may include separate call functions for each HL function.

[0032] A node with CS enabled can generate an expanded version of the compact transaction, i.e., an expanded transaction. Specifically, a node with CS enabled can generate an expanded version of the compact script, i.e., an expanded script. The compact script is converted into an equivalent expanded script by replacing each function identifier with a set of LL functions configured to perform the same operations as the HL functions identified by the respective function identifiers. This may include the use of a function table. Thus, the reference library is used to obtain the required LL functions. For example, a node with CS enabled may need to generate the transaction identifier of the compact transaction in expanded form.

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

Brief Description of the Drawings

[0034]

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 13A

Figure 13B

Figure 13C

Figure 14A

Figure 14B

Figure 14C

Figure 15

Figure 16A

Figure 16B

Figure 16C

Figure 16D

Figure 16E

Figure 17A

Figure 17B

Figure 17C

Figure 17D

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

DETAILED DESCRIPTION OF THE INVENTION

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

[0036] 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 having 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 one or more memory units using optical media such as optical disk drives.

[0037] 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 a transaction in this context refers to a certain type of data structure. The nature of the data structure varies depending 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 as an example, there is a user 103 whose output is cryptographically locked (unlocking it and thereby redeeming or using it requires the signature or other solution of that user). Each input refers to an output of a preceding transaction 152, thereby linking the transactions.

[0038] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order to the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer back to a previous transaction to define an order to the sequence of transactions (Note: a sequence of transactions 152 can branch). The chain of blocks 151 traces back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0039] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "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 the node 104 accepts as valid and that the node 104 is obligated not to accept any other transactions that attempt to use the same output.

[0040] In a given current transaction 152j, the input (or each input) comprises a pointer that references an output of a preceding transaction 152i in the sequence of transactions, and 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 the preceding transaction 152i need not necessarily 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 in the same way as an antecedent transaction or a predecessor transaction.

[0041] The input of the current transaction 152j also comprises an input authorization, e.g., 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 for aggregating amounts from multiple outputs of one or more preceding transactions and redistributing them to one or more outputs of the current transaction.

[0042] 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 through an automated process adopted by the party), the creating party sends the new transaction to the recipient from its computer terminal 102. 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 in 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.

[0043] 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 a 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.

[0044] In addition to verifying 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 block 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 representation of the ordered pool of transactions 154 with the nonce pending is concatenated and hashed, 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 particular 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 with respect to 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.

[0045] The first blockchain node 104 that solves the puzzle publishes this 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 for 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 it is assigned the same output as 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 thus 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.

[0046] 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 transactions were received. It should be noted that regardless of 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 network's users or agents because the same transactions appear in both forks.

[0047] 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 received 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 "start 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.

[0048] Due to the resources involved in verifying and publishing transactions, usually, at least each of 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.

[0049] The memory of each blockchain node 104 stores software configured to execute on the processing device of the blockchain node 104 to perform respective roles according to the blockchain node protocol and 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.

[0050] 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).

[0051] 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 the 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 can 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, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that many more such parties 103 and their respective computer devices 102 exist and can participate in the system 100, but for 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.

[0052] The computer device 102 of each party 103 includes a respective processing device having one or more processors, such as a processor, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 further includes a memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may comprise 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 comprising 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 carried out 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 accessible via the user terminal.

[0053] The client application 105 may first be provided to the computer device 102 of any party 103 on a suitable computer-readable storage medium, e.g., 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 removable storage device such as a removable optical drive.

[0054] The client application 105 has 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), and send a transaction 152 to one or more Bitcoin nodes 104, which is then propagated throughout 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 involves reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to the party.

[0055] 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 the operating system, or any combination thereof. Although the following is described with respect to the client application 105, it will be understood that this is not limiting.

[0056] Instances of the client application or software 105 on each computer device 102 are 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 transactions 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 reliability in transactions through its partial public visibility, actually inspect the transactions of other parties within the blockchain 150). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify transactions 152 according to a blockchain node protocol and is configured to transfer them to propagate the transactions 152 across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol proceeds 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.

[0057] If a given party 103, e.g., Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction according to the relevant transaction protocol (using the wallet function of Alice's client application 105). Alice then 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 a 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.

[0058] Conditioned upon passing a test for a 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 network 106. Since each blockchain node 104 applies the same protocol, assuming transaction 152j is valid, this means it will be propagated throughout network 106 immediately.

[0059] Upon being allowed to participate in 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 for the most recent 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 blockchain 150. Since each transaction 152 includes a pointer back to the previous transaction, the order of the transactions is also invariably recorded.

[0060] 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 which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance is recorded in the blockchain 150, that blockchain node 104 must accept this and discard (i.e., treat as invalid) the first instance it accepted (i.e., the one not published in block 151).

[0061] Alternative types of transaction protocols operated by some blockchain networks may be referred to as "account-based" protocols 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 (also called the "position") of the account. 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 be signed. For example, this data field may refer to a previous transaction if the previous transaction ID is included in the data field.

[0062] 2. UTXO - based model FIG. 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 the blockchain 150 (each block 151 contains one or more transactions 152). Hereinafter, it will be described with reference to an output-based or "UTXO" - based protocol. However, this is not limited to all possible embodiments. Although an exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be implemented in the same way in other exemplary blockchain networks.

[0063] 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 digital assets. This represents the set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the original 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. The 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 the node 104.

[0064] Assume that Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j has "Tx" 1is labeled as "」. This takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of this to Bob. The previous 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 previous (i.e., earlier) transaction that still has an unused output 203 locked to Alice.

[0065] The previous 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 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, Tx 0 is Tx 1It can even be sent after. 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 refers 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 the 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 the blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or the behavior of the node, it may be discarded, buffered, or waited for a specific time to wait for the parent.

[0066] Preceding transaction Tx 0 One of one or more outputs 203 of which is herein referred to as a UTXO 0It has specific UTXOs labeled as

[0067] The lock script (commonly known as scriptPubKey) is a part of the 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 part of the 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.

[0068] 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). Ais the public key P from Alice's public - private key pair A and includes an expression (i.e., a 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 provides a pointer to Tx 1 . The input 202 of Tx 1 identifies a UTXO 0 from among any other possible outputs of Tx 0 and includes an index that identifies the UTXO 0 within Tx 0 . The input 202 of Tx 1 further includes an unlock script <Sig P A > that is created by applying Alice's private key from the key pair to a predefined part of the data (which may also be called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

[0069] When a new transaction Tx 1 arrives at the blockchain node 104, the node applies the node protocol. This involves 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 putting data on the stack, and "[...]" is a function composed of unlock scripts (in this example, a stack-based language). Equivalently, the scripts can be executed one after another using a common stack instead of concatenating the scripts. In any case, when executed together, the scripts will, when Tx 0 uses the public key P A of Alice as included in the lock script within the output of Tx 1 to authenticate that the unlock script within the input of Tx 1 contains Alice's signature that has signed the expected part of the data. The expected part of the data itself ("message") also needs to be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx 1 (i.e., since a separate element specifying the signed part of the plaintext data already essentially exists, it does not need to be included).

[0070] Details of authentication by public - private cryptography are well known to those skilled in the art. Basically, when Alice signs a message using her private key, 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, such that any holder of the public key can authenticate the signature. Thus, it should be noted that references herein to signing, such as to a particular data part or a part of a transaction, can, in an embodiment, mean signing the hash of that data part or part of the transaction.

[0071] Tx 1 If the unlock script within Tx 0 satisfies one or more conditions specified within the lock script of 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 that has already been 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 has already been spent (i.e., whether it 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.

[0072] If the total amount specified in all the 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 the block 151.

[0073] Note that in the UTXO-based transaction model, a given UTXO needs to be used in its entirety. It is not possible to "leave behind" a portion of the amount defined as used in the UTXO, while another portion is used. 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 to herself in the second output of Tx 1 or pay it to another party.

[0074] In practice, Alice usually also needs to include a fee for the Bitcoin node 104 that has successfully included her transaction 104 in the 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, a pointer to UTXO 0 is the only input to Tx 1 and Tx 1 has the only output UTXO 1 . Suppose 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 UTXO203 of the transaction 152.

[0075] 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 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 on any of the Bitcoin nodes 104.

[0076] 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 specific opcode of the script language. As an example, OP_RETURN is an opcode of the script language that, when OP_FALSE is placed in front at the start of the lock script, can store data within a transaction, thereby immutably recording the data on the blockchain 150, creating an unusable output of the transaction. For example, the data may comprise a document that is desired to be stored on the blockchain.

[0077] 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).

[0078] 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 whom 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.

[0079] 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 may sometimes be 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 sometimes also referred to as sharing a "transaction template". The 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.

[0080] 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 information or a particular part of data via side channel 107, it should be noted that this does not necessarily imply that all of these parts of data must be transmitted on exactly the same link or the same type of network.

[0081] 4. Client Software Figure 3A shows an exemplary implementation of client application 105 for implementing embodiments of the presently disclosed approach. Client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. Transaction engine 401 is configured to implement transaction-related functions underlying client 105, such as formulating transaction 152, receiving and / or transmitting transactions and / or other data via side channel 301, and / or transmitting a transaction to one or more nodes 104 to be propagated through blockchain network 106 according to the approach described above and to be described in further detail shortly. According to embodiments disclosed herein, the transaction engine 401 of each client 105 comprises a function 403 configured to write lock scripts in a high-level scripting language and convert between the high-level scripting language and a low-level scripting language. In other words, lock scripts written in a high-level language can be mapped to equivalent lock scripts 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 the corresponding expanded lock script.

[0082] 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.

[0083] Note: Although various functions in this specification may be described as 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. Whenever reference is made anywhere in this specification to a single or a given application 105, etc., this is merely an example, and more generally, it will be understood that the described functions can be implemented in any form of software.

[0084] FIG. 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.

[0085] As an example, FIG. 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.

[0086] 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 the 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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 ) 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 it to the script engine 452.

[0091] 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, transactions labeled Tx 0 and Tx 1 are shown in FIG. 2, but the same applies to any pair of transactions. The script engine 452 executes the two scripts together as described above, which involves placing data on and retrieving data from the stack 453 according to the stack-based scripting language (e.g., Script) being used.

[0092] 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. The script engine 452 returns the result "true" if it determines that the unlock script meets one or more criteria specified in the corresponding lock script. Otherwise, it returns the result "false".

[0093] In an output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of a transaction. Typically, Tx j does not exceed the total amount of digital assets specified in the output of Tx i by the total amount indicated by its input, and Tx j There are also one or more additional protocol-level conditions evaluated by the protocol engine 451, such as the indicated output of Tx j not being already used by another valid transaction. 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 the condition that 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 includes the consensus module 455C adding Tx

[0094] j to the respective ordered sets 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.

[0094] The terms "true" and "false" as used herein 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).

[0095] 6. High - level scripting language FIG. 5 shows an exemplary system 500 for sending a compact 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.

[0096] 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 above as a compact script (CS). Note that the first output does not need to appear logically 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 (i.e., define a lock condition) an expanded lock script (ELS) written using only the LL scripting language. The ELS is also referred to above as an expanded script (ES). For example, both the CLS and the ELS can define a lock script that finds the modular inverse of a number. Since the CLS can comprise a single HL function configured to find the modular inverse of a number rather than requiring a number of LL functions to perform the operation, the size of the CLS can be reduced compared to the ELS. In other words, the CLS written in the HL scripting language can be compiled into the ELS written in the LL language.

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

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

[0099] 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.

[0100] 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 may send it 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.

[0101] In some examples, Alice 103a is the transaction identifier TxID of the first transaction Tx 1 1can be generated. The transaction identifier is typically a 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 .

[0102] 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, the transaction identifier TxID 1 is generated.

[0103] Generating a modified version of the first transaction Tx raw may simply mean replacing the first CLS with the first ELS. Then, the 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 can be sent to the blockchain network 106.

[0104] 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 of the LL language and the HL function of the HL language.

[0105] 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 raw including the first ELS instead of the first CLS. 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. It is a valid signature only when using the modified version of the first transaction Tx raw as a message.

[0106] 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 need not 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 need not 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 need not 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.

[0107] 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 can 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 the one or more outputs. As a specific example, the secondary transaction identifier can be based on the version number and the lock time. Additionally or alternatively, the secondary transaction identifier can be based on the output with each CLS.

[0108] 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.

[0109] 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 the index and / or the sequence number, rather than the complete unlocking script.

[0110] 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.

[0111] In some embodiments, the above-described HL script language may 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 may 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 may be a script language that can be described by a user (or other party or entity including a device). A script described in the user-oriented language can be compiled (which may 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.

[0112] 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.

[0113] Returning to the above example, Alice 103a may generate a transaction comprising 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 comprising the first CLS may 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 a more compact form of the lock script in the CLS.

[0114] 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 unwind lock script, Alice's transaction may comprise a compact unlock script. The compact unlock script may be written in an intermediate language or a user-facing language.

[0115] 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.

[0116] 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

[0117] Node 104 replaces the first CLS with the corresponding ELS to thereby process the first transaction Tx raw ​Generate 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 Based on the modified version of ', generate a transaction identifier TxID 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 '.

[0118] 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.

[0119] 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.

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

[0121] In some examples, the modified version of the transaction may not include the first CLS. In other examples, the modified version of the transaction may include both the first ELS and the first CLS. For example, the first output of the modified transaction may include the first CLS 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 this. In this case, the transaction identifier is based on both the first ELS and the first CLS.

[0122] 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, block 151 including the first transaction Tx 1 may be published on 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 so that the requesting node 104 can verify the first transaction in the same manner as it can for a transaction that typically includes only the LL script language.

[0123] So far, the above description regarding transaction verification has focused on the verification of 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.

[0124] Assuming that the first transaction Tx 1 is a valid transaction, it is published in block 151. Then, 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 including an input that references the first output of the first transaction Tx 2 , that is, 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 directly send the second transaction to node 104 or indirectly send it via a different entity, e.g., Eve, who is a third user.

[0125] 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 properly unlock the lock of the first ELS. As a second option, node 104 does not need to 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 properly unlock the lock of the first CLS.

[0126] Since the first CLS is equivalent to the first ELS, the same input unlocks the locks of both the first CLS and the first ELS. As a simple example, 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.

[0127] 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 for constructing a block 151 that includes, for example, the second transaction Tx 2

[0128] Second transaction Tx 2 may optionally include one or more outputs that each include a respective 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 improve efficiency, the comparison may be performed before executing the input script and the output script.

[0129] ​ 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.

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

[0131] 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.

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

[0133] 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, an expanded form, or a hybrid manner where not all but some of the compact script is converted to native script before execution.

[0134] The user-facing language is human-readable, easy for developers to use, extensible, and can be compiled into an intermediate-level language. Examples of user-facing languages are provided below. However, there can be multiple different user-facing 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.

[0135] The intermediate-level language connects 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 (this is optional, note that in some cases the metascript is not executable unless deployed to a low-level language), 3. Expandable - Can be deployed to a low-level language (native script), 4. Deterministic - The same metascript is always deployed to the same native script.

[0136] Furthermore, when the same input is given and directly executed, the metascript produces the same output as the output generated by executing the deployed native script from the metascript.

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

[0138] User - oriented language scripts can be directly converted into low - level language scripts (native scripts). However, by introducing intermediate - level language scripts (metascripts), 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). The example shows 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.

[0139] 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 as well.

[0140] 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 the user-oriented language, converted into a meta-script written in the intermediate-level language, and further converted into Bitcoin opcodes (i.e., the low-level language).

[0141] Alice can use the user-oriented level scripting language to create a lock script [High-Level script B].

[0142] Next, the lock script is compiled into a meta-script in the intermediate language and embedded in the transaction.

[0143] [Table 1]

[0144] There are some points to note here. 1. The lock script [High-Level script B] is a script written in the user-oriented scripting language. This is called the 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)).

[0145]

Table 2

[0146]

Table 3

[0147]

Table 4

[0148] 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.

[0149]

Table 5

[0150] 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.

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

[0152]

Table 6

[0153]

Table 7

[0154]

Table 8

[0155]

Table 9

[0156] Transactions created by the above Alice 103a are propagated in a compact form (meta-script) to save bandwidth. As mentioned 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 script size is unlimited and each block can contain billions of transactions (approximately every 10 minutes).

[0157] For now, assume that there are two types of nodes 104: Bitcoin nodes with HL enabled, configured to execute the HL script language, and Bitcoin nodes with HL disabled. Note that nodes with HL disabled 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.

[0158] Depending on the signature flag used to sign the transaction input (see the above description), a node with HL disabled may consider a transaction containing CLS to be invalid. That is, when a node with HL disabled 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, the signed message is assumed to include ELS (which a node with HL disabled cannot replicate from CLS), so the transaction is considered invalid. This is the same scenario as when a 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 a Bitcoin node with HL enabled. A node with HL disabled receives a block containing Alice's transaction. Since Alice's transactions are considered non-existent because a node with HL disabled does not store them. The node with HL disabled can then request the transaction from a node with HL enabled. The node with HL enabled sends the complete transaction without using the compact lock script. The node with HL disabled can then verify the entire transaction. However, if the majority of nodes have HL enabled, since Alice's transaction will be accepted by most of the network 106, a node with HL enabled can choose to ignore such requests.

[0159] In some cases, if the signature does not sign all transaction outputs, and the output containing the CLS is not signed, a node with HL disabled may be able to consider the HL transaction valid. In that case, the node with HL disabled can actually verify the transaction using the 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.

[0160] When a node with HL enabled receives a transaction, it performs the following processing. 1. Convert the metaroll script to the corresponding native block script and use the library register (see the following section) or the reference table to obtain the following.

[0161]

Table 10

[0162] 2. Hash the transaction data to obtain the transaction ID and check whether it is the same as TxID 1 and the same. 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 node with HL enabled propagates the transaction to the peer in a compact form.

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

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

[0165]

Table 11

[0166] input B is assumed to unlock the lock of [Meta Script B], where input B may include a digital signature from Bob Sig B with respect to the public key PK B .

[0167] As a node with HL enabled, 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.

[0168] Option 2 provides a computational advantage to nodes with HL enabled over nodes with HL disabled. 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).

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

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

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

[0172]

Table 12

[0173] Alternatively, a secondary identifier can be added to the first output, for example, as follows. [Smart contract] OP_FALSE OP_RETURN TxID 1-secondary [[ID=2>]]>

[0174] When expanded into native opcodes, the lock script [Bitcoin opcodes expanded from 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.

[0175] 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.

[0176] Figure 6 shows an exemplary flow from transaction generation to verification. First, transaction Tx 1 is generated using the HL script language. Next, the HL script language is language-converted to generate Tx raw . Then, based on Tx raw , a 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 has a transaction identifier TxID 1 It may be used to generate '. In this option flow, the received transaction identifier is compared with the generated transaction identifier. 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.

[0177] TxID 1 The transmission of is a robust error checking mechanism that allows node 104 to detect mismatches between the mappings (CLS to ELS and ELS to CLS) used by the transaction generator (e.g., Alice 103a) and the transaction verification node 104. However, alternative error checking mechanisms can also be used. TxID 1 By including, node 104 can still perform transaction mapping and verification while quickly starting the mining operation (e.g., building a Merkle tree based on TxID 1 ).

[0178] 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 an 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 ID 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 recipient is the same as the mapping used by the sender, the recipient 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 recipient can continue with the verification of the transaction. The TxID is used as a parity check in this instantiation. It should also be noted that this verification of the TxID is optional and instead node 104 may proceed directly to the verification of the transaction.

[0179] Figure 8 shows an exemplary flow of data when sending and verifying a transaction. The transaction creator with HL enabled (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 can be included within the transaction rather than concatenated with the transaction). The transaction validator with HL enabled (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 verifying the transaction. If they do not match, the validator discards the transaction. As an alternative option, a node with HL enabled may not need to verify the transaction identifier. Also shown are transaction validators with HL disabled. If only the compact version of the transaction is received, a transaction validator with HL disabled cannot verify the transaction. On the other hand, if the expanded transaction is received, a transaction validator with HL disabled can verify the transaction. When the transaction is published on the blockchain, a validator with HL disabled requests the compiled transaction to verify the transaction.

[0180] 7. Compact Script Library Figures 5 to 9 and the above description explain 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 Figures 10 to 25.

[0181] Figure 10 summarizes the protocol from the perspective of node 104a with CS enabled that receives a transaction. As shown, node 104a with CS enabled receives a blockchain transaction. If the blockchain transaction is a compact transaction, the compact transaction is processed and verified in its compact form. Note that this may include converting the compact transaction into its expanded (normal) form. 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 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.

[0182] FIG. 11 shows an exemplary script execution process. The node 104a with CS enabled is equipped with a script engine configured to process the script 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 the expanded form.

[0183] FIG. 12 shows an exemplary system for communicating compact scripts. The system includes one or more users 103 and one or more nodes 104a with CS enabled. For simplicity, only one user, Alice 103a, is shown. Similarly, only two nodes 104a with CS enabled are shown, but generally, a system with CS enabled may include any number of nodes. FIG. 12 also shows a blockchain network 106. Although shown separately from the nodes 104a with CS enabled, it will be understood that the blockchain network 106 includes nodes with CS enabled. The blockchain network 106 may also include one or more nodes with CS disabled.

[0184] Alice 103a generates a compact transaction (compact Tx) and sends it to the node 104 with CS enabled. The node 104a with CS enabled processes the compact Tx and / or transfers the compact Tx to one or more different nodes 104a with CS enabled for processing. The processing of the compact Tx may include verifying the compact Tx. This will be described later.

[0185] Alice 103a can access one or more HL function libraries, each of which contains one or more HL functions. An HL function is a script language that can be converted into a function written in an HL script language, i.e., a function written in an LL script language (see below for further details). An HL function may be specific to an HL reference library, but not necessarily so. An HL reference library may comprise several related HL functions (i.e., functions that at least complement each other and / or are intended to be used together). Additionally or alternatively, an HL reference library may comprise several unrelated HL functions.

[0186] The HL reference library may be stored in the memory of one or more nodes where CS is enabled. Additionally or alternatively, the HL reference library may be stored on a blockchain, for example, in a "library transaction", i.e., a block within a blockchain transaction that comprises the HL reference library in the output of the transaction. As another example, the HL reference library may be stored in an off-chain location, such as a web page, or in the cloud.

[0187] Figure 13A shows an exemplary HL reference library. In this example, the HL functions are preceded by the term "word" indicating that the following terms are HL functions. The HL reference library comprises several HL functions including "counter", "length", and "reverse". As shown, the counter function is configured to increment the current value of the count. The length function is configured to output the length of a value (e.g., a string). The reverse function is configured to reverse the order of a value (e.g., reverse the order of the characters in a string).

[0188] Alice 103a creates a compact transaction. The compact transaction comprises a compact script. The compact script may be a compact lock script or a compact unlock script. The compact script comprises a library identifier (or library reference) of the HL reference library. The library identifier may be, for example, the hash of the source code of the HL reference library, or its trimmed version (for example, the first n leading bytes of the hash). With the library identifier, other parties including the nodes enabled with CS can obtain the necessary HL reference library from, for example, memory.

[0189] In some examples, the library identifier is the transaction identifier (TxID) of a library transaction that comprises the HL reference library. Instead of the TxID, the library identifier may be a pair of block height and position, where the block height indicates the block that comprises the library transaction and the position indicates the position of the library transaction within that block. These library identifiers uniquely identify the library transaction and enable the nodes enabled with CS to obtain the correct reference library. In these examples, the HL reference library may be stored on-chain by Alice 103a or the blockchain node 104 (for example, node 104a enabled with CS, etc.).

[0190] Optionally, if the HL reference library is stored off-chain, the library identifier may include a link to the off-chain resource (for example, a URL). Alternatively, the link may be something other than the library identifier. This may be convenient when several HL function libraries are stored in the same off-chain resource.

[0191] In some examples, the library identifier identifies an HL function created by Alice 103a. That is, Alice 103a creates a compact script that uses one or more HL functions of her own library. In other examples, the library identifier identifies an HL function created by a different entity (e.g., a different user 103, or a node 104a where CS is enabled).

[0192] The compact script also includes one or more function identifiers that identify each HL function stored in the identified HL reference library. For example, the HL functions can be stored in a sequence, and a given function identifier can identify an HL function based on its position within the sequence. Alternatively, the HL functions can be otherwise associated with their respective function identifiers, e.g., the function identifier can be an abbreviation of the function.

[0193] The compact script also includes at least one IL function (a "call function") configured to call the HL functions identified by their respective function identifiers when executed. For example, a single call function can be configured to call each of the identified functions. Alternatively, a separate call function can be included in the compact script for each identified function. In some examples, the call function is also configured to call (i.e., load) the HL reference library. For example, the compact script can take the following form. 12ab.0 MOP_FN_CALL, In the above, 12ab is the library identifier, 0 is the function identifier, and MOP_FN_CALL is configured to call the HL function corresponding to function identifier 0 from reference library 12ab. Alternatively, the compact script can include an IL function (a "library load function") configured to call (i.e., load) the identified reference library when executed. For example, the compact script can take the following form. 12ab MOP_LIB 0 MOP_FN_CALL, As described above, MOP_LIB is a library loading function configured to load reference library 12ab.

[0194] When a compact transaction is created, Alice 103a sends the compact transaction to one or more nodes 104a where CS is enabled. Alice 103a may send the compact transaction to a specific node 104a, for example, a node where Alice 103a knows it can access the required reference library. The compact transaction may be sent to any node 104a where CS is enabled. Alice may send the compact transaction together with the required reference library, or the required reference library may already have been sent to node 104a. If the reference library can be obtained by other means, such as a library transaction, there is no need to send the reference library.

[0195] In some embodiments, Alice 103a needs to generate an expanded version of the compact transaction (i.e., the corresponding expanded transaction) in order to generate a version of the compact transaction that includes a transaction identifier based on the expanded transaction, i.e., the LL functions necessary to perform an operation equivalent to the operation of the identified HL function. Alice 103a inserts the required LL functions (e.g., opcodes) into the expanded transaction. In other words, Alice 103a replaces the function identifier with the required LL functions. The resulting expanded transaction contains only LL functions and data. Then, the expanded transaction is hashed to assign a transaction ID. Next, Alice 103a can insert the transaction identifier into the compact transaction and send the compact transaction (with the transaction identifier) to node 104a where CS is enabled.

[0196] Alice 103a may use an HL function table to generate a deployment transaction. The HL functions are specific to a particular reference library, and each function identifier of the HL functions is stored in that reference library. Each function identifier is stored (i.e., mapped) together with each set of LL functions (and optionally IL functions) necessary to implement the respective HL function. Alice 103a may generate an HL function table, or Alice 103a may load an HL function table from, for example, memory. For example, Alice 103a may have previously used the same reference library and thus may already have created or loaded a function table.

[0197] Alice 103a converts a compact script into a deployment version (deployment script) by replacing a function identifier with each set of LL functions (and optionally IL functions) mapped to that function identifier in the function table. If the function identifier is mapped only to LL functions, the function identifier is simply replaced with those LL functions. If the function identifier is mapped to both LL functions and IL functions, the function identifier is replaced with the LL functions and the IL functions, and then the IL functions are replaced with each set of LL functions necessary to implement that IL function. This may occur in one action, i.e., all the necessary LL functions may be inserted into the deployment script at the same time, or it may occur in two actions, i.e., the IL functions may be inserted and then replaced with the necessary LL functions. The set of LL functions corresponding to an IL function may be defined in advance. In this sense, an IL function is a predefined function that is known to all nodes where CS is enabled and may perform a predefined operation.

[0198] FIG. 13B shows an exemplary function table of the reference library of FIG. 13A. As shown, each function identifier is mapped to a corresponding set of an IL function and an LL function, where the IL function starts with "MOP" and the LL function starts with "OP". This is merely an example for illustrative purposes, and it will be understood that the IL functions and LL functions can be distinguished in different ways. In the example of FIG. 13B, the names of the HL functions are included in the function table. In other examples, the function names may be omitted.

[0199] In the examples of FIGS. 13A and 13B, some HL functions refer to, i.e., use, different HL functions. For example, the inverse function uses the length function. The function table includes the respective function identifiers of the length function as part of the mapping of the inverse function. When converting the compact script to the expanded script, Alice 103a uses the function table to replace the function identifier of the length function with the IL and LL functions required to implement the length function. In other words, the function identifier of the inverse function is replaced with the "implementation form" of the inverse function, and the function identifier of the length function that forms part of that implementation form is replaced with the implementation form of the length function. The implementation form of an HL function refers to the IL and / or LL functions mapped to the function identifier of that HL function.

[0200] In some embodiments, as shown in FIG. 13B, the implementation form of the HL function may include one or more variable identifiers for each variable used by the HL function. Similar to the function identifier, the variable identifier may be based on the position of each variable in the library. In the example of FIG. 13B, a dollar sign $ is prefixed to the variable identifier. Other ways of indicating variable identifiers, such as using the name of the variable, may be used. In these embodiments, the implementation form also includes each IL function (a "variable acquisition function") configured to retrieve the variable identified from memory when called (i.e., executed). A single variable acquisition function may be used for the entire implementation form, or a separate variable acquisition function may be used for each variable identifier of the implementation form. For example, in the example of FIG. 13B, the IL function MOP_GET_VAR follows each variable identifier (e.g., $1). The implementation form may also include an IL function (a "variable setting function") configured to output the identified variable to memory when called.

[0201] The variables required by the HL function of a given reference library may be stored in a variable table, and the variable acquisition function and the variable setting function are configured to retrieve variables from the variable table and output variables to the variable table, respectively. An exemplary variable table of the function table in FIG. 13A is shown in FIG. 13C. The variable table includes each variable identifier and the value of the corresponding variable. If the value of the variable is not known at the time of creating or loading the variable table (e.g., because it depends on currently unknown inputs), a placeholder value (e.g., "Null") may be used. When the compact script is converted to the expanded script, the variable table of the reference library is created or loaded, and the IL function (e.g., the variable acquisition function) associated with the variable identifier forming part of the implementation form of a given HL function is replaced with the value of the identified variable.

[0202] In some examples, variables may be classified as global variables (e.g., in a program). Global variables are interpreted as being available for use throughout the script. That is, any function in the compact script may utilize global variables. Alternatively, variables may be classified as local variables. Local variables are interpreted as being available only to the functions of the reference library to which the local variable belongs.

[0203] In some examples, the variable table may be interpreted as a constant table, and variables can only be read from the constant table and cannot be written to the constant table.

[0204] Although the above description referred to a single reference library, the possibility that a compact script includes a library identifier of a second reference library is not excluded. Generally, a compact script may include library identifiers of any number of different function libraries. Thereby, Alice 103a can use functions from different function libraries to generate a desired compact script (e.g., a desired locking condition, etc.). In these embodiments, Alice 103a may create or load a respective function table for each reference library identified in the compact script. Similarly, Alice 103a may create or load a respective variable table for each reference library identified in the compact script.

[0205] Also note that the reference library can be updated, for example, by Alice 103a. This includes updating the reference library after a compact transaction that references the reference library has been published on the blockchain. For example, if the reference library is stored in a library transaction on the blockchain, Alice 103a (such as a different entity like node 104a where CS is enabled) can submit an updated library transaction to the blockchain that uses the output of the previous library transaction and may include the updated library. Details of library updates are provided further below.

[0206] As described above, Alice 103a sends the compact transaction to node 104a where CS is enabled. Node 104a where CS is enabled processes it by converting the compact transaction into an expanded version (i.e., the corresponding expanded transaction). That is, the compact script is converted into an expanded script. This process is basically the same as the process that Alice 103a performs to generate the expanded transaction. Therefore, any of the above-described embodiments related to the generation of the expanded transaction, including the use of the function table and variable table, can equally apply to node 104a where CS is enabled.

[0207] Each computing device of Alice 103a and node 104a where CS is enabled may each include one or more compilers for converting the compact script into an expanded script. For example, the computing device may include an HL (or SDL) compiler, an IL (or meta-script) compiler, and an LL (or transaction) compiler (such as as part of a script engine), which will be described in more detail below.

[0208] More specifically, the node 104a for which CS is enabled obtains a compact transaction (e.g., received from Alice 103a). The node 104a for which CS is enabled also obtains one or more function libraries identified in the compact script of the compact transaction. This may include one or more of the function libraries taken from any of Alice 103a, different nodes 104a for which CS is enabled, their respective blockchain transactions, off-chain resources (e.g., cloud servers), or the memory of the node 104a for which CS is enabled. In some examples, the library identifier (e.g., the hash of the library) may be used as a search to find the corresponding reference library from among a plurality of function libraries stored in a repository, for example.

[0209] The node 104a for which CS is enabled processes the compact transaction, which includes generating an expanded version of the compact transaction. Similar to Alice 103a, the node for which CS is enabled does this by replacing the HL function identifier with the LL function required to perform the same operation as the identified HL function. The node 104a for which CS is enabled may do this by creating or loading one or more HL function tables in the same way as described above for Alice 103a. The node for which CS is enabled may also create or load one or more HL variable tables in the same way as described above for Alice 103a.

[0210] Node 104a with CS enabled can process a compact transaction to generate a transaction identifier based on the deployment transaction. Node 104a with CS enabled can compare the transaction identifier with the transaction identifier that forms part of the compact transaction, i.e., the transaction identifier included in the compact transaction by Alice 103a. If the two transaction identifiers do not match, the node with CS enabled can reject (i.e., invalidate) the compact transaction. Rejecting the compact transaction includes not including the compact transaction in the new block 151 and not broadcasting the compact transaction to other nodes 104.

[0211] If the compact script is a lock script, processing the compact transaction can include executing the compact script along with the unlock script of the spending transaction, for example, to verify the spending transaction. Conversely, if the compact script is an unlock script, processing the compact transaction can include executing the compact script along with the lock script of the previous transaction, for example, to verify the compact transaction. Note that the compact transaction can be executed in compact form or expanded form depending on whether other transactions are compact transactions.

[0212] To avoid ambiguity, the reference to Alice 103a or Node 104a with CS enabled performing an action means that the action is performed by the respective computing device, e.g., a script engine configured to process the compact script.

[0213] Further examples of the above embodiments are provided below. Although described with respect to the Bitcoin blockchain, the following examples may be implemented on any blockchain having the necessary characteristics.

[0214] 7.1 Library The described protocol enables the use of loops and similar functions such as for, while, and do while. This significantly enhances the compression of scripts and enables applications that were previously impossible. The lock script needs to have a deterministic regular (i.e., low-level) form with Bitcoin opcodes and ideally should be known when the transaction is submitted to the Bitcoin network. Therefore, it is recommended to test the execution of the script before submitting a compact transaction to the Bitcoin network. Libraries are used to reuse tested metascript and enable an efficient way to reference them. Some aspects of the function library are described below.

[0215] 1) Creation and testing of the library. Developer Alice 103a wants to write a smart lock script while leveraging the features of SDL (i.e., the HL script language) and metascript (i.e., the IL script language). Mike is the blockchain node 104a that accepts compact transactions and permits the upload of libraries. Mike provides an interactive interface for Alice 103a to test and upload her library. Alice uses the interactive service to upload her library and compile the uploaded code. Upon successful compilation, Alice 103a is given a library identifier and uses it when referring to the library.

[0216] 2) Use of libraries in creating lock scripts. Alice 103a uses a library identifier in the lock script of a transaction and sends the transaction to Miner 104a for mining. Alice 103a uses another one of Bob's interactive services again to check whether Alice 103a's compact script ("tx - compact") is correctly compiled by Miner 104a. If tx - compact is accepted by Bob, Alice submits the transaction to blockchain 150. Miner 104a uses the library identifier to search for a library during the verification of the transaction and the generation of the TxID. Other nodes where CS is enabled and which accept the compiler results of the miner can obtain the library using the library identifier. Other developers can also use Alice's library by using the library ID.

[0217] 3) Library updates. Libraries can be updated and version - managed. In order to extract the canonical form of historical transactions, it may be necessary to keep all version histories. Library references in compact transactions can be updated at any time as long as the canonical form does not change due to the change. For example, this may be the case when a new version of the library updates a function in the library that is not used by the compact transaction.

[0218] 4) Library dependencies. Libraries can use functions from other libraries.

[0219] 5) Behind-the-scenes of library upload and use. A variable table can be generated during library compilation. Usually, the values of variables are not set at this point. When Alice 103a uses a library in her lock script, it may be necessary to set some variables. The criterion is that the normal form of the lock script needs to be determined at that stage. For example, if a loop is used in the lock script, the number of loops needs to be determined at this stage and should not depend on the unlock script. Therefore, Alice and Mike may have an interactive session to test the use of library functions in the lock script and initialize the required variable table values. The node 104a with CS enabled may agree to a common set of tests and criteria for adding the library to the common repository. This is not essential but can maximize efficiency and improve the robustness and security of the system.

[0220] 6) Reference to external libraries. Using a library allows data and code to be stored and referenced without explicitly including them in the script. The library can be directly hosted or retrieved by a node with CS enabled. Therefore, these libraries do not need to be propagated using MS transactions, saving both storage and bandwidth. A new meta-opcode (i.e., an IL function), MOP_LIB, can be used to reference a library in a meta-script, for example, using hash(library source code) MOP_LIB or lib_ref MOP_LIB. Note that other meta-opcodes, such as MOP_LIBLOAD or MOP_LOADLIB, can be used. The reference to a library can be the hash of its code. Therefore, changes (including updates) to the library invalidate the reference. For this reason, copies of all versions of the library can be stored.

[0221] 7) Library registry. One or more library registries may be used by a node to retrieve the libraries being referenced. These libraries may be stored using a shared common registry maintained by a standards body. The registry may be defined by a consensus mechanism or a deterministic set of rules based on the frequency of use of the libraries in the blockchain. Alternatively, the node may separately publish its own mapping of keys to canonical references, and users may submit their transactions to compatible nodes using the short keys. If the node supports compact scripts and the referenced library is unknown, the library can also be searched in the shared library registry, and other nodes can be queried to check whether the reference is known. If the search is unsuccessful, node 104a can request the complete library source code from the sender of the transaction. Alternatively, if other options fail, the node can request the canonical form from the sender.

[0222] 8) Library checksum. If a compact transaction references the wrong library (e.g., different libraries using the same key), the generated transaction ID will not be valid. This ensures that only the intended library can be used.

[0223] Referring to an external library in a compact transaction implies that an exact copy of this library must be available at any future time. This can lead to problems. If, for some reason, the library being referred to in a transaction is unavailable at a particular point in time, the node cannot verify that transaction, and thus that transaction and all subsequent transactions become invalid. For this reason, users who own satoshis, tokens, or other UTXOs that depend on (or have a dependent parent transaction that depends on) a transaction using an external library may hold a copy of any library used in any dependent public MS transaction. Node 104a or another party may provide this service.

[0224] An alternative approach is to force transactions that use one or more compact transactions to include all necessary libraries as additional outputs (for example, in an unusable (OP_RETURN) output of the transaction). This approach maintains the increased bandwidth obtained by broadcasting a compact transaction that includes a reference to the library and the increased storage when the compact transaction is in the memory pool (mempool). However, when the transaction is inserted into the public block, the required storage increases (since the spending transaction includes the entire library code).

[0225] An alternative, more efficient approach is to use the blockchain itself as storage and store library code in public transactions. A meta opcode (e.g., MOP_LIBTX) can refer to a transaction that contains a library (e.g., a transaction where a set of data and functions follows OP_RETURN). If the referenced transaction does not exist or does not contain an OP_RETURN with a valid (meta)script, a compact transaction using MOP_LIBTX can be considered invalid. A transaction that contains a library can be referenced using its transaction ID (32 bytes), or a compact version thereof (e.g., the first 4 bytes, etc.). When a compact version is used, collisions may occur. In this case, the transaction ID of the compact transaction can be used as a checksum (only the correct library leads to the correct transaction ID). The syntax of MPO_LIBTX can take one of the following forms. TxID library MOP_LIBTX Or, shorten 4-bytes (TxID library) MOP_LIBTX

[0226] Alternatively, instead of the transaction ID, the block height and the position of the transaction within the block can be referenced. The syntax in this case can be as follows. BlockHeight library Position library MOP_LIBTX

[0227] 9) Embedded Library. The blockchain node can provide a set of common functions that can be used by default, creating a virtual library of built-in functions. The node can advertise functions associated with the node's version number that it provides by publishing their descriptions and implementation forms in transactions or websites. Compact transactions can reference these libraries by specifying only the function number without specifying the library. As an example, node_ver OP_VERNOTIF MOP_LIB 12ab specifies that the library needs to be searched and loaded only if node_ver is different from that of the node. With built-in functions, the code can be optimized and the function codebase can be standardized.

[0228] 7.2 Variable Table The variable table can be used to store local and global variables. Local variables are only valid within the scope of a specific library, while global variables are valid throughout the script, i.e., at the transaction input level (i.e., each transaction input has its own global space).

[0229] The variable table enables the use of variables within reusable compact scripts and external libraries, and allows the insertion of placeholders for information that is not known when the code or lock script is written (i.e., information that is only provided when the unlock script is created). In the context of a compact script, a variable is a symbolic index that refers to a pointer to the variable table. When a variable is stored in the variable table using a specific index (a "variable identifier"), the same index can be used to reference it again in the lock script. The variable table maps the index to a relative variable value. In some examples, a variable may be described and read multiple times while the script is being executed (i.e., while a transaction is being verified or used). When the script ends (when the transaction is considered valid or invalid), the variable table allocations are released.

[0230] The meta-opcode used to store a variable can be MOP_SET_VAR prefixed with the value of the variable and the index of the variable table. Similarly, the meta-opcode used to read from the variable table can be MOP_GET_VAR prefixed with the index of the variable table. The index of the variable table may be prefixed with a dollar character (e.g., $0 for index 0). Two types of variable tables can be defined: a global variable table and a library variable table. When MOP_GET_VAR and MOP_SET_VAR are used directly in the lock script, they read from and write to the global variable table. When MOP_GET_VAR and MOP_SET_VAR are used in an external library, they read from and write to the library variable table. Each library loaded into the lock script has its own private library variable table.

[0231] The global variable table is assigned when a transaction ID is generated (when a transaction is created) or when a lock script is loaded for use of a transaction. A user 103 creating a compact transaction can use the global variable table to declare and store variables, for example, when the value is not known at the time of writing a lock script.

[0232] An example of a global variable table with two uninitialized indexes is shown in FIG. 14A. As an example, the compact script 'hello' $0 MOP_SET_VAR sets the row indexed by 0 in the variable table to "hello" (as shown in FIG. 14B), while the compact script $0 MOP_GET_VAR reads the variable at index 0 from the variable table and inserts its value into the lock script (i.e., pushes the value onto the stack).

[0233] When a library is first loaded into the lock script during script execution, a new library variable table is allocated and initialized (the variable table is not re-initialized even if the same library is reloaded within the same script). This table has two main purposes. The first purpose is to store variables that are initialized in the library and thus not directly accessible from the lock script. The second purpose is to store and track function parameters (i.e., the inputs to each function). Each function within the library can have a set of variables with their relative indexes pre-assigned, one for each parameter. When a function is called in the lock script, the input parameters are passed to the function by setting the relative variables within the library variable table. The library variable table can have local variables (within the scope of a function) and library variables (within the scope of the library). Local variables are reserved within the library variable table and have the indexes specified in the function table (see the "Function Table" section below), and they are re-initialized each time the function is called. Library variables share the same index among different functions within the same library. They are initialized only when the function is first loaded into the lock script.

[0234] The global variable table can be separated from the library table because the library variable table may store variables that should not be accessed by users who import libraries in the lock script. For example, a library containing parameters of an elliptic curve (e.g., secp256k1) may store them in the library variable table. It may be beneficial to compensate so that users cannot modify those values from the lock script (e.g., by using MOP_SET_VAR with different values). In some implementations, local variables and global variables within a library can be stored in separate tables, namely the global library variable table and the local library variable table. The global library variable table is initialized when the library is loaded into the lock script and the allocation is released when the execution of the script ends. The local library variable table is initialized each time a function is called and the allocation is released when the function ends.

[0235] The variable table may be dynamically typed or statically typed. In the latter case, the type of the variable is checked by the script engine, and an error occurs if a different type is later assigned to a variable whose type was first assigned. This type of error leads to an invalid script (equivalent to a script that ends with OP_FALSE at the top of the stack). Compact scripts that use a statically typed variable table are generally more complex to write. However, more rigorous and structured error detection at compile time can detect bugs, thus reducing the possibility that a script containing errors is published. These errors can lead to the publication of transactions with unusable lock scripts or transactions that can be used under conditions different from what was intended. When a statically typed variable table is used, as shown in Figure 14C, the type of the variable can be stored along with the index and the variable value.

[0236] MOP_SET_VAR and MOP_GET_VAR are meta-opcodes used to enable variable usage in compact scripts. Note that these are just example labels and other meta-opcodes performing the same operations can be used instead. The variable opcodes can be expanded into regular scripts using the alt stack to store variables. MOP_SET_VAR pushes variable values onto the alt stack according to their indices. MOP_GET_VAR copies variable values from the alt stack according to their indices. An exemplary alt stack showing the positions of variables is shown in Figure 15. The expansion of MOP_SET_VAR and MOP_GET_VAR into their relative regular opcodes is explained in WPxxxx (reference by Wei). Since their expansions are very long, even when the compact script is expanded into regular form, the remaining explanations refer to MOP_SET_VAR and MOP_GET_VAR using the relative meta-opcodes. Alternatively, if the variable values can be calculated at compile time, the variables are replaced with actual values during script compilation or expansion.

[0237] An exemplary compact script is shown in Figure 16A and is converted as follows. Line 1 inserts "hello" into index 0 of the variable table. The state of the variable table is shown in Figure 16B. Line 2 reads "hello" from the variable table and counts the number of characters. The state of the variable table is shown in Figure 16C. Finally, it stores a value in index 1 of the variable table. Line 3 reads variable 1(5) from the variable table, compares it with 5, and writes the result to the top of the stack. The expanded regular script is shown in Figure 16D. The corresponding alt stack is shown in Figure 16E.

[0238] 7.3 Function Table Each time a reference library is called during the execution of a script, a function table can be created or loaded. The function table is created by the script engine and stored in memory (i.e., the memory of Alice 103a or the node 104a where CS is enabled). The function table maps a numerical index ("function identifier") to the header of a function and optionally maps the implementation form in a meta-script or a regular script.

[0239] Functions declared in an external library can be called in a transaction lock script using the meta-opcode MOP_FN_CALL prefixed with the index of the function. For example, the following lock script 012ab MOP_LIB 0 MOP_FN_CALL is converted as follows. Load (or generate) a function table from the library with ID 012ab, and then insert the meta-script or regular script of the function with index 0 in the function table into the lock script. After the function table is loaded, multiple functions can be called. For example, the following lock script 012ab MOP_LIB 0 MOP_FN_CALL 1 MOP_FN_CALL is converted as follows. Load (or generate) a function table from the library with ID 012ab, and then insert the function body of the function with index 0 in the function table and the function with index 1 that follows it into the lock script.

[0240] If multiple libraries need to be used in the same lock script, the required library can be specified each time the referenced library is changed. For example, to call function 0 from library 012ab, then call functions 0 and 1 from library 567cf, and finally call function 1 from library 012ab again, the following structure can be used. 012ab MOP_LIB 0 MOP_FN_CALL 567cd MOP_LIB 0 MOP_FN_CALL 1 MOP_FN_CALL 012ab MOP_LIB 1 MOP_FN_CALL

[0241] Note that MOP_LIB needs to be called only when the referenced library is changed.

[0242] A more compact form may be used. For example, in some implementations (of the script engine), the library ID is directly specified during a function call, and the library ID and function index can be separated by a dot ("."). Following this syntax, the lock script 012ab MOP_LIB 0 MOP_FN_CALL would be as follows. 012ab.0 MOP_FN_CALL Also, an example with two libraries would be as follows. 012ab.0 MOP_FN_CALL 567cd.0 MOP_FN_CALL 1 MOP_FN_CALL 012ab.1 MOP_FN_CALL

[0243] When a compact transaction is used, a canonical form of the lock script is generated, thereby inserting the function body into the script. This enables verification of the transaction ID and functions as a valid checksum that the referenced library is correct. Omitting this step can create a script where the referenced library is different from what was intended (for example, sharing the same short ID, but node 104a might be using the wrong ID), resulting in a lock script with unexpected behavior. This is not harmful to the Bitcoin network 106 because blocks generated using a transaction with the wrong library are rejected by all other nodes 104 (eventually reaching consensus using the correct library), but it causes an economic loss to node 104a that publishes an invalid block.

[0244] Figures 13A, 13B, and 13C are as described above and show examples of a reference library, a function table, and a variable table, respectively. The variable count is assigned to $0 (index 0) in the table and initialized to 0. Each time the function counter is called, the variable count is incremented by 1 for $0, and $0 is updated. The user cannot directly modify the counter from the lock script (cannot access the library variable table), and the only permitted way is to call the counter function. The function length parameter is assigned to $1. When length is called, the input parameter is inserted into $1 and read whenever needed within the function. The same is true for function reversal. In function reversal, a variable len is declared. This variable is assigned to $2 and each time it is modified, the value at $2 is updated in the library variable table (using the value $2 MOP_SET_VAR), and taken from the library variable table each time the variable is used ($2 MOP_GET_VAR). Note that len is re-initialized each time reversal is called.

[0245] Another exemplary reference library is shown in FIG. 17A. When a lock script using an external library is converted to its canonical form, all references to the external library are replaced with the actual code of the calling function, and the meta opcodes are expanded to the canonical version. A function table corresponding to the reference library of FIG. 17A is shown in FIG. 17B. Note that the input count starts at $1 because $0 is used by the global variable global_var of the library.

[0246] The transaction may have the following lock script. 'hello' 12ab.0 MOP_FN_CALL

[0247] To publish a transaction containing this lock script, the first step is to verify the transaction ID. Thus, the meta script is expanded to its canonical form by the script engine. The meta script is first converted as follows. 12ab.$1 MOP_GET_VAR OP_SIZE OP_NIP

[0248] Next, the variable table shown in FIG. 17C is used to expand the script as follows. OP_TOALTSTACK 10 7 OP_ADD OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_ADD

[0249] 8. Exemplary Workflow This section describes an exemplary developer workflow using compact scripts. Since the script size limit was removed in the Bitcoin SV genesis upgrade, applications can now potentially create transactions with long and complex scripts. This presents several problems. 1. The complexity of developing, testing, and using complex scripts in a transaction. 2. The additional bandwidth required to broadcast much larger current transactions. 3. The increased storage requirements for transactions once verified by a transaction processor or a blockchain node.

[0250] To address these issues, Metascript (an exemplary implementation form of a compact script) was introduced. Metascript is an extension of Bitcoin script with additional features including function calls and loops. Metascript does not execute or contribute to Bitcoin's consensus rules such as transaction ID generation or signature hash calculation. A mininode compiles Metascript into regular Bitcoin script at runtime.

[0251] Metascript expands the possibility for developers to build and distribute libraries of functions to miners, and then these functions can be used by Metascript transactions. The workflow of this process will be described later.

[0252] Figure 18 shows a general overview of an exemplary workflow. Figure 18 shows that there are two main users who interact with this system during the workflow stages. A library developer who is responsible for developing and publishing the libraries used by transactions, and a transaction developer who discovers the published libraries and is responsible for using those libraries in transactions.

[0253] Metascript is one of three programming languages that interact with each other: SDL, a high-level language used for the development of the Metascript library; Metascript, an extension of Bitcoin Script that enables function calls and loop construction; and Bitcoin Script, the basic language that is also called a regular script when generated from Metascript. Note that a regular script is a form of script that is hashed to generate a transaction ID.

[0254] 8.1 Metascript Development Tools Figure 19 shows an exemplary overview of the tools used to develop Metascript. Figure 19 shows how the compilers are used. The SDL / Library compiler is used to generate a library function table from SDL, the Metascript compiler refers to the library function table to convert a text-form Metascript into a byte array form, and the Transaction compiler generates a regular script from Metascript (in byte array form) and the function table.

[0255] 8.2 SDL Compiler The SDL compiler takes an input and generates a function table as an output. SDL is a language for developing libraries, and thus SDL provides features for function definition, function calls, immutable variable declarations, for loops, while loops, unit test frameworks, and library documentation generation. These will be described next.

[0256] Functions can be defined as follows. pub fn function_name(arg1 :type) { }

[0257] Both text - based SDL and Metascript use a combination of library_name and function_name to indicate the library function call to be executed. For example, a script might contain the following: use library_name; 1 OP_DUP MOP_FNCALL library_name::function_name

[0258] Note that if two libraries define the same function name, the complete combination of library_name and function_name can be used to prevent name collisions. Libraries can be imported into the script namespace. use library_name::*; 1 OP_DUP MOP_FNCALL function_name

[0259] Specific library functions can be imported into the script namespace. use library_name::{function1, function2}; 1 OP_DUP MOP_FNCALL function1

[0260] Importing into the script namespace checks for name collisions of library functions and will result in an error if a collision occurs.

[0261] Note that immutable variable declarations are based on function definitions. When these functions are transpiled, function calls are replaced with values on the stack. For example, as follows: pub const LARGEST_PRIME_UNDER_100=97;

[0262] If a constant is public, note that the value is replaced with a function definition and called by other libraries or scripts. When these functions are transpiled, function calls are replaced with values on the stack. If the constant is private (without "pub"), as a way to implement this, you can place the constant inside a function as in the public case (if library size is an issue and the constant is large (several bytes in size), this is more efficient), or you can choose to replace the constant at the point where it is used within the library.

[0263] As shown in Figure 20, the SDL compiler can optionally output unit tests. These tests are run to provide evidence that the library is functioning as intended.

[0264] Figure 21 shows an exemplary construction of a library with a function table. Each library may include one or more of the following: entity_name, which is the issuer of this library and may be necessary to assist in the discovery of the library; library_name, which is the text name of the library; library_id, which is a unique id that identifies this library based on the TransactionID; library_version, which is the version of this library that enables transactions to be pinned to a specific library release; dependencies, which is a list of libraries that this library depends on and is identified using library_ids; and functions, which is a list of function table entries (FunctionTableEntry) that describe each function. Note that the library_id is calculated by setting the library_id field to zero and hashing the complete library. A FunctionTableEntry may include one or more of the following: function_name, which is the text name of the library; function_signature, which indicates the arguments expected by the function; Is_private, which is a flag indicating whether the function is private (see the following explanation); and byte_code, which is the Metascript function as a byte array.

[0265] Library functions can be either public or private. Public functions are available for use by scripts or other libraries. Private functions can only be used by the library itself.

[0266] To ensure that private functions remain private, at least two approaches can be used. 1) During the parsing process, private function calls are expanded into public functions (this increases the size of the published library file but reduces the overhead of transpiling the library), or 2) a "is_private" field is used to indicate that the function is private and should not be called by other scripts or libraries. The latter reduces the size of the published library but increases the overhead of transpiling the library. This also increases the risk that the node implementation form will ignore this flag and execute code that should not be executed, potentially creating vulnerabilities.

[0267] As part of the SDL processing, some of the following checks may be performed by the SDL compiler. Do all library fields exist? Does library_name match the generated function table name? Is library_id unique? Has this version number been used before? (Reusing the same version number can cause serious problems.) Are the function names within the library unique? Is the library_index field unique? Are the library dependencies valid and up-to-date? Does each function have a function signature?

[0268] 8.3 Metascript Compiler The following describes the operation of the Metascript compiler for creating metascript transactions. As described above, Metascript is an extension of Bitcoin script and has additional features such as for loops, while loops, and call (library) function definitions including parameter substitution. Note that Metascript loop constructs, while loops and for loops are limited to a defined number of iterations. The purpose of this limitation is to limit the execution time of the transaction, provide evidence that the script has completed, and ensure that Metascript always generates the same regular script. This ensures that the script always generates the same hash digest and thus the same transaction ID.

[0269] The Metascript operation (MOP) is an additional operation with the prefix "MOP_" as opposed to the prefix "OP_" for existing Bitcoin script operations. Loop constructs include the following. · MOP_DO(limit start ---) - Marks the start of the loop and retrieves the start value and the limit value from the stack · MOP_I(---index) - Places the current index on the stack · MOP_LOOP(---) - Marks the end of the loop · MOP_IFLEAVE(condition ---) - If the condition on the stack is True, leave the current (innermost) loop.

[0270] Note that (n ---) indicates that the argument is taken from the stack.

[0271] Additional functions include the following. · MOP_FNCALL<short_id> <arg1> <arg2>-Transfer control to the function identified by -short_id. The function uses the current state of the stack and places the return value on the stack. ·MOP_ARG <n>- This is a placeholder for the nth argument in the function signature. These are placed within the library code, and the passed values are substituted when the code is called. Note that <arg1, arg2> indicates that the arguments are placed after the operations in the operation list.

[0272] Metascript needs to identify the libraries it uses, and for this it uses the MOP_LOADLIB MOP code. · MOP_LOADLIB <n_libs> <lib1> <lib2>The first parameter after the -MOP_LOADLIB operation determines the number of libraries to be loaded, and the next parameter is the library_id of the library.

[0273] Figure 22 shows the format of the developing Metascript in text form and as a byte array after being released as a transaction. The conversion between the two formats is performed by the Metascript compiler. As shown in Figure 22, the developing Metascript includes uses, which is a list of libraries used by the script, and script, which is the Metascript source. Note that when the script references a library function, it does so through the combination of library_name and function_name. This is shown by the StringFunction structure in Figure 21. Figure 21 also shows the byte-form Metascript that includes source_code, which is the script as a byte array.

[0274] As mentioned at the beginning, Metascript does not contribute to the Bitcoin consensus rules that include the generation of transaction IDs. The transaction ID is the hash of the regular script. Therefore, in order to create a Metascript transaction ID, first the transaction needs to be converted to a regular script and this script needs to be hashed. This implies that the Metascript compiler needs to also include the functionality of a transaction compiler. Note that some fields present in Metascript do not exist in Bitcoin script and therefore do not contribute to the hash. However, since transaction verification generates the same hash, this is not a problem.

[0275] 8.4 Script / Transaction Compiler Figure 22 shows that node 104a receives a Metascript transaction and uses a function table to convert it into a regular script. This is the point where parameters are substituted into the called library functions.

[0276] 8.5 Library Publication, Distribution, and Discovery Library developers are responsible for publishing libraries on the blockchain. The library can then be found on the blockchain by its transaction ID. Future versions of the library can be indicated by using the transactions associated with the library on the blockchain. This use can then provide a new version of the library. There may be a central repository that lists the libraries and their associated transaction IDs and makes them retrievable from the blockchain. This enables nodes to quickly discover libraries at startup and preemptively load the libraries before receiving transactions that depend on those libraries.

[0277] 8.6 Node Processing Transactions Node 104a needs to identify whether the script contains Metascript. Since the script may not load a library, it may not be possible to check whether the script starts with MOP_LOADLIB. Therefore, node 104a needs to scan the script to check whether it contains a MOP_ operation. Details of the Metascript transaction compiler process are shown in Figure 24. To process a Metascript transaction, the node needs access to node software that can process Metascript transactions, the source of the Metascript library, and the transactions that contain Metascript.

[0278] The node needs to do the following. 1. Obtain the necessary libraries. Note that the libraries may have dependencies on other libraries and it is necessary to resolve them. 2. Convert the metascript to a regular script. a. MOP_FNCALLS are expanded into the called library code. b. MOP_LOOP is unwound as necessary up to the identified limit (to ensure that the normal form is always the same). 3. Execute the regular script. 4. Verify the script.

[0279] 8.7 Node Verification Transaction Note that since not all nodes understand Metascript, not all nodes can verify transactions that contain Metascript. This is handled by peer-to-peer messaging, ensuring that Metascript transactions are only sent to peer nodes that understand Metascript and are processed and verified. Figure 25 shows an exemplary verification process that uses the same "Transpile Metascript" stage that was used to process the transaction.

[0280] 8.8 Node Relay Transaction When a transaction containing a metascript is accepted and verified by a miner, the transaction needs to be relayed on the network (or at least to the peers it is connected to). The question is what form the script should take. There are two options. a) Expand the metascript into a canonical form and send it according to the current process, or b) Leave it in Metascript form and send it only to miners with Metascript enabled. To realize the potential of the Metascript concept, the second option is the recommended option. In this case, the processing required by the node receiving the transaction is the same as that shown in Figure 24 above, except for checking the ability to understand Metascript. During peer discovery, the node notifies whether it can process Metascript as well as regular scripts.

[0281] 8.9 Node Startup Upon startup, a node with Metascript enabled needs to discover the library. As mentioned above, the library can be stored on the blockchain. The node can maintain a persistent record of the recently used libraries. This list can be used to prioritize the libraries cached locally to speed up transaction processing. A central repository may exist to assist the node in discovering the libraries. This will list the libraries and the transaction IDs associated with them, making them retrievable from the blockchain. This enables the node to actively cache the libraries before receiving transactions that use them.

Example

[0282] 9. Example 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 function tables 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.

[0283] 9.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.

[0284] [Table 13]

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

[0286] [Table 14]

[0287] 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.

[0288] $0 refers to the first input to a script that has not yet been provided. It may become the top item on the stack.

[0289] 0 MOP_FN_CALL is the syntax for calling the function with function ID 0 in the function table.

[0290] After executing $0 0 MOP_FN_CALL, the length of the input remains at the top of the stack.

[0291] 1 OP_SUB subtracts 1 from the top value on the stack and leaves the result at the top of the stack.

[0292] 0 MOP_SET_VAR assigns the top element on the stack to the variable with index 0 in the variable table. This variable can be used for the rest of the execution.

[0293] 0 MOP_GET_VAR pushes the value of the variable with index 0 in the variable table to the top of the stack. This is the syntax for retrieving a variable from the variable table.

[0294] 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.

[0295] After executing 0 MOP_GET_VAR MOP_LOOP OP_1 OP_SPLIT MOP_END_BLOCK, the string is split into single-byte substrings.

[0296] 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.

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

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

[0299]

Table 15

[0300]

Table 16

[0301] 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.

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

[0303] MOP_LOOP_IF COUNTER 0 MOP_GET_VAR LESSTHAN MOP_END_BLOCK starts the loop if 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.

[0304] OP_1 OP_SPLIT is repeatedly executed when the condition is satisfied. Note that this is not included in the function table to indicate that there is an option that does not include all words defined in the high-level language. As a general method, when a function is frequently referenced, that function is included in the function table.

[0305] MOP_END_BLOCK indicates the end of the repeated code.

[0306] 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 half-width substrings.

[0307] Similarly, MOP_LOOP_IF COUNTER 1 MOP_GET_VAR LESSTHAN MOP_END_BLOCK 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.

[0308] Middle-level language (meta-script) Assuming that the string "I am fish" is input to the inverse function, the meta-script is as follows.

[0309]

Table 17

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

[0311] The metascript can be executed directly using the metascript engine, as described in the section of the function table. 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.

[0312] The metascript can also be expanded into native form to generate a transaction ID, verify a signature, or execute it in a native script engine by specifying a function table.

[0313] When expanding 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 an infinite loop.

[0314] Low-level languages (e.g., Bitcoin opcodes) When the metascript is expanded, all loops are unwound and only native opcodes are permitted. As an example, the following native script corresponds to the previous exemplary metascript.

[0315] [Table 18]

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

[0317] 9.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, the high-level inverse function is compiled into a 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.

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

[0319]

Table 19

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

[0321]

Table 20

[0322]

Table 21

[0323] As an example, use c0 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.

[0324] Low-level language (Bitcoin opcodes / native script)

[0325]

Table 22

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

[0327] 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 set to 8.

[0328] 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 by "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.

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

[0330] [Table 23]

[0331] 17 bytes Intermediate-level language:

[0332] [Table 24]

[0333] [Table 25]

[0334] 13 bytes Low-level language:

[0335] [Table 26A]

[0336] [Table 26B]

[0337] 49 bytes

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

[0339] 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).

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

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

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

[0343] 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, every 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).

[0344] 9.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.

[0345] 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.

[0346] 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.

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

[0348] [Table 27]

[0349] The algorithm can be described as follows.

[0350] [Table 28]

[0351] 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 we want to set this to 100 or more. What will happen if very large-scale transactions occur in the compiled script?

[0352] In this example, Alice needs to specify the maximum number of iterations, and the nodes with SDL enabled can generate accurate transactions in the deployment script.

[0353] 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

[0354] 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 top of the altstack OP_TUCK OP_2DUP OP_MOD OP_DUP OP_TOALTSTACK OP_SWAP OP_TOALTSTACK OP_SUB OP_SWAP OP_DIV

[0355] 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 / }

[0356] 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.

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

[0358] 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, 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

[0359] The above can be described in 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.

[0360] The following example shows a way in which the extended Euclidean algorithm can be implemented. This function< / r> < / q> Receive s n , t n Calculate gcd(a, b), where gcd(a, b) = s n a + t n is 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

[0361] 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 let l=25 loop (l) {DUP IF qr() st() FAS ENDIF} DROP NIP NIP} EEA (in1 , in2)

[0362] This is an example of HL script language code. A loop is used to repeat a 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 100s or 1000s as needed. The size of the CLS does not change, but the size of the corresponding ELS becomes megabytes.

[0363] 10. 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.

[0364] 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.

[0365] 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).

[0366] 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 not all, but at least one or some, 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.

[0367] 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 creating, publishing, propagating, and storing blocks. The functions of such a network entity / element can be implemented in hardware in the same way as described above with reference to the blockchain node 104.

[0368] 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.

[0369] Statement 1. A computer-implemented method of sending a compact transaction to a node of a blockchain network, the compact transaction being a blockchain transaction comprising a compact script (CS) that is at least partially described in an intermediate level (IL) scripting language and includes one or more IL functions, wherein when executed, each IL function is configured to perform an operation equivalent to an operation performed by one or more low level (LL) functions of an LL scripting language, and the CS is configured to perform an operation equivalent to an operation performed by a deployment script (ES) described in the LL scripting language, the method being performed by a first party, generating a first compact transaction comprising a first CS, the first CS comprising: i) a first library identifier of a first high level (HL) reference library, the first HL reference library comprising a first set of HL functions described in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a respective set of one or more LL functions; ii) one or more respective function identifiers of the first set of HL functions; and iii) at least one IL function configured to call one or more HL functions during script execution, sending the first compact transaction to at least one node in which the CS is enabled, each node in which the CS is enabled being configured to verify the compact transaction.

[0370] Statement 2. The method according to Statement 1, comprising the step of creating a first HL reference library. Alternatively, the first HL reference library may be created by another party.

[0371] Statement 3. The method according to Statement 1 or 2, comprising the step of making the first HL reference library available to at least one node in which CS is enabled.

[0372] Statement 4. The method according to Statement 3, wherein the step of making the first HL reference library available to at least one node in which CS is enabled comprises the step of transmitting the first HL reference library to at least one node in which CS is enabled.

[0373] Statement 5. The method according to Statement 3, wherein the first HL reference library is stored in a publicly accessible source, and the step of making the first HL reference library available to at least one node in which CS is enabled comprises the step of transmitting a reference to the publicly accessible source to at least one node in which CS is enabled.

[0374] Statement 6. The method according to Statement 5, wherein the publicly accessible source is a library transaction stored in a blockchain, and the first library identifier is a) the transaction identifier of the library transaction, or b) the block height of the block comprising the library transaction and the position of the library transaction within the block.

[0375] Statement 7. The step of creating the library transaction, and the step of transmitting the library transaction to at least one blockchain node and comprising the method according to Statement 6.

[0376] Statement 8. A step of creating an updated library transaction, the step comprising an updated library, and A step of sending the updated library transaction to at least one blockchain node and The method according to statement 6, comprising a step of updating a library by.

[0377] Statement 9. The method according to any one of statements 1 to 8, wherein the first library identifier is a hash value of the first HL reference library.

[0378] Statement 10. The compact transaction comprises a first transaction identifier, and the method is A step of generating an expanded version of the first compact transaction by converting a first CS to a first ES, the converting comprising replacing each function identifier with a respective set of one or more LL functions configured to perform the same operation as the respective HL function, and A step of generating a first transaction identifier based on the expanded version of the first compact transaction and The method according to any one of statements 1 to 9.

[0379] Statement 11. A step of creating or loading a first HL function table for the first HL reference library, the first HL function table comprising i) a respective function identifier of each first HL function and ii) one or more IL functions and / or one or more LL functions for implementing each respective HL function, the step comprising, Converting the first CS to the first ES comprises obtaining each set of one or more LL functions configured to perform the same operation as each HL function, based on the mapping in the first HL function table, the method according to statement 10.

[0380] The function identifier can be an index corresponding to the position of the HL function in the HL reference library. The first HL reference library may comprise a first HL function table.

[0381] Statement 12. The method according to statement 11, wherein at least one HL function uses a different HL function and the first HL function table comprises function identifiers of each of the different HL functions as part of the mapping.

[0382] Statement 13. The method according to any one of statements 1 to 12, wherein the first CS comprises a second library identifier of a second HL reference library, the second HL reference library comprises a second set of HL functions, and the first CS comprises function identifiers of one or more of the second set of HL functions.

[0383] Statement 14. Creating or loading a second HL function table for the second HL reference library, the second HL function table comprising: i) function identifiers of each of the second HL functions and, mapped to each function identifier, ii) one or more IL functions and / or one or more LL functions for implementing each HL function, Converting the first CS to the first ES comprises obtaining each set of one or more LL functions configured to perform the same operation as each HL function, based on the mapping in the first HL function table, the method according to statement 13 when dependent on statement 11 or statement 12.

[0384] The second HL reference library may include a second HL function table.

[0385] Statement 15. The method described in Statement 11 or any statement dependent thereon, wherein the first HL function table includes, as part of the mapping of each HL function, the respective variable identifier of one or more first HL variables used by each HL function and at least one IL function configured to call one or more first HL variables during script execution.

[0386] Statement 16. A step of creating or loading a first HL variable table for the first HL reference library, the first HL variable table comprising i) the respective variable identifier of each first HL variable and ii) the value of each first HL variable, or a placeholder for that first HL variable, to which the respective variable identifier is mapped. The method described in Statement 15, wherein converting the first CS to the first ES comprises using the first HL variable table to replace each respective variable identifier with the value of the respective first HL variable or its placeholder.

[0387] The first HL reference library may include a first HL variable table.

[0388] Statement 17. The method described in Statement 16, wherein the first HL variable includes one or more variable identifiers of each global variable available to the entire first compact script and / or the first HL variable table includes one or more variable identifiers of each local variable available only to the first HL functions of the first HL reference library.

[0389] The first HL variable table may be divided into two separate sub-tables, one for global variables and one for local variables.

[0390] Statement 18. The method according to statement 16 or 17, wherein converting the first CS to the first ES comprises writing each value of the respective first HL variable to the first HL variable table.

[0391] Statement 19. The method according to statement 16 or 17, wherein each first HL variable of the first HL variable table is a constant value that does not change during the processing of the first CS.

[0392] Statement 20. A computer-implemented method for processing a compact transaction, wherein the compact transaction is a blockchain transaction comprising a compact script (CS) that is at least partially described in an intermediate-level (IL) script language and comprises one or more IL functions, and when executed, each IL function is configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of an LL script language, the CS is configured to perform an operation equivalent to an operation of an expansion script (ES) described in the LL script language, and the method is configured to verify the compact transaction, and is performed by a node in which the CS is enabled. Obtaining a first compact transaction comprising a first CS, wherein the first CS comprises: i) a first library identifier of a first high-level (HL) reference library, the first HL reference library comprising a first set of HL functions described in an HL script language, each HL function being configured to perform an operation equivalent to an operation performed by a respective set of one or more LL functions; ii) one or more respective function identifiers of the first set of HL functions; and iii) at least one IL function configured to call one or more HL functions during script execution. Obtaining the first HL reference library. Processing the first compact transaction, wherein the step of processing comprises: A step of generating an expanded version of a first compact transaction by converting a first CS to a first ES, wherein the converting comprises replacing each function identifier with a respective set of one or more LL functions configured to perform the same operation as the respective HL function, the step comprising, the step and A computer-implemented method comprising.

[0393] Statement 21. The compact transaction comprises a first transaction identifier, and the step of processing the first compact transaction Generating a candidate transaction identifier based on the expanded version of the first compact transaction; Determining that the candidate transaction identifier matches the first transaction identifier; Rejecting the first compact transaction if the candidate transaction identifier does not match the first transaction identifier The method according to statement 20, comprising.

[0394] Statement 22. The first CS is a lock script, and the step of processing the first compact transaction comprises executing the first ES together with an unlock script of a second blockchain transaction, the method according to statement 20 or 21.

[0395] Statement 23. The first CS is an unlock script, and the step of processing the first compact transaction comprises executing the first ES together with a lock script of a third blockchain transaction, the method according to statement 20 or 21.

[0396] Statement 24. The method according to any one of Statements 20 to 23, wherein the step of obtaining the first compact transaction comprises receiving the first compact transaction from the first party or another node enabled by the CS.

[0397] Statement 25. The method according to Statement 24, wherein the step of obtaining the first HL reference library comprises receiving the first HL reference library from the first party or another node enabled by the CS.

[0398] Statement 26. The step of obtaining the first HL reference library comprises obtaining a reference to a publicly accessible source in which the first HL reference library is stored, and obtaining the first HL reference library from the publicly accessible source, and the method according to any one of Statements 20 to 25.

[0399] Statement 27. The method according to Statement 26, wherein the publicly accessible source is a storage transaction stored in a blockchain, and the reference to the publicly accessible source is a transaction identifier of the storage transaction.

[0400] Statement 28. The method according to Statement 26, comprising creating the storage transaction and transmitting the storage transaction to at least one blockchain node. Statement 29. The method according to any one of Statements 20 to 24, wherein the step of obtaining the first HL reference library comprises accessing the first HL reference library from memory.

[0401] Statement 30. The method according to any one of Statements 20 to 24, wherein the step of obtaining the first HL reference library comprises accessing the first HL reference library from memory.

[0402] Statement 30. The first library identifier of the first HL reference library is the hash of the first HL reference library, and the step of obtaining the first HL reference library is the method described in any one of Statements 21 to 30 based on the hash.

[0403] Statement 31. The step of creating or loading a first HL function table for the first HL reference library, wherein the first HL function table comprises: i) each function identifier of each first HL function, and ii) one or more IL functions and / or one or more LL functions for implementing each HL function, to which each function identifier is mapped. The method according to any one of Statements 20 to 29, wherein converting the first CS to the first ES comprises obtaining each set of one or more LL functions configured to perform the same operation as each HL function based on the mapping in the first HL function table.

[0404] The function identifier can be an index corresponding to the position of the HL function in the HL reference library.

[0405] Statement 32. The method according to Statement 31, wherein at least one HL function uses a different HL function, and the first HL function table comprises each function identifier of the different HL functions as part of the mapping.

[0406] Statement 33. The first CS comprises a second library identifier of a second HL reference library, the second HL reference library comprises a second set of HL functions, the first CS comprises each function identifier of one or more of the second set of HL functions, and the method comprises the step of obtaining the second HL reference library.

[0407] Statement 34. Creating or loading a second HL function table for a second HL reference library, wherein the second HL function table comprises: i) function identifiers for respective second HL functions, and ii) one or more IL functions and / or one or more LL functions for implementing respective HL functions, each function identifier being mapped thereto. The method according to statement 33, when the converting the first CS to the first ES is dependent on statement 31 or 32, comprising obtaining respective sets of one or more LL functions configured to perform the same operation as respective HL functions based on mappings within a first HL function table.

[0408] Statement 35. The method according to statement 31 or any statement dependent thereon, wherein the first HL function table comprises variable identifiers for respective first HL variables used by respective HL functions, and at least one IL function configured to call one or more first HL variables during script execution, as part of the mapping of respective HL functions.

[0409] Statement 36. Creating or loading a first HL variable table for a first HL reference library, wherein the first HL variable table comprises: i) variable identifiers for respective first HL variables, and ii) values of respective first HL variables, or placeholders therefor, each variable identifier being mapped thereto. The method according to statement 35, wherein the converting the first CS to the first ES uses the first HL variable table to replace respective variable identifiers with values of respective first HL variables or their placeholders.

[0410] Statement 37. The method according to statement 36, wherein the first HL variable comprises one or more variable identifiers of each global variable available to the entire first compact script, and / or the first HL variable table comprises one or more variable identifiers of each local variable available only to the first HL function of the first HL reference library.

[0411] Statement 38. The method according to statement 36 or 37, wherein converting the first CS to the first ES comprises writing the value of each first HL variable to the first HL variable table.

[0412] Statement 39. The method according to statement 36 or 37, wherein each first HL variable of the first HL variable table is a constant value that does not change during the processing of the first CS.

[0413] Statement 40. A memory comprising one or more memory units, A processing device comprising one or more processing units A computer device comprising a memory storing code configured to be executed on the processing device, and the code being configured to implement the method according to any one of statements 1 to 39 when on the processing device.

[0414] Statement 41. A computer program embodied on a computer-readable storage and configured to implement the method according to any one of statements 1 to 39 when executed on one or more processors.

Description of Reference Numerals

[0415] 100 System 101 Packet Switching Network 102 Computer Device 102a Computing Device 102a Computer Device 102b Computer device 103 Party 103 User 103a User 103a Alice 103a First party 103b Second party 103b Bob 104 Bitcoin node 104 Blockchain node 104a Node with CS enabled 104a Blockchain node 104a Mike 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 Node's Script Engine 453 Stack 454 Application-Level Decision Engine 455 Blockchain-Related Functional Module 455 Functions 455C Consensus Module 455P Propagation Module 455S Storage Module 500 User Interface (UI) 500 System 501 UI Elements 501 User-Selectable Elements 502 UI Elements 502 Data Input Fields 503 UI Elements 503 Information Elements < / lib1> < / n> < / arg1> < / cls> < / els>

Claims

**Claim 1** A method implemented on a computer for sending a compact transaction to a node of a blockchain network, wherein the compact transaction is a blockchain transaction comprising a compact script (CS) at least partially described in an intermediate level (IL) scripting language and comprising one or more IL functions, and when executed, each IL function is configured to perform an operation equivalent to an operation performed by one or more low-level (LL) functions of an LL scripting language, and the CS is configured to perform an operation equivalent to an operation of a deployment script (ES) described in the LL scripting language, and the method is performed by a first party, generating a first compact transaction comprising a first CS, wherein the first CS comprises i) a first library identifier of a first high-level (HL) reference library, the first HL reference library comprising a first set of HL functions described in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a respective set of one or more LL functions, ii) one or more respective function identifiers of the first set of HL functions, and iii) at least one IL function configured to call the one or more HL functions during script execution, sending the first compact transaction to at least one node enabled with the CS, each node enabled with the CS being configured to verify the compact transaction, The method comprising: **Claim 2** The method according to claim 1, further comprising creating the first HL reference library. **Claim 3** The method according to claim 1 or 2, further comprising making the first HL reference library available to the at least one node enabled with the CS. **Claim 4** The method according to claim 3, wherein the step of making the first HL reference library available to the at least one node enabled with the CS comprises sending the first HL reference library to the at least one node enabled with the CS. **Claim 5** The method according to claim 3, wherein the first HL reference library is stored in a publicly accessible source, and the step of making the first HL reference library available to the at least one node in which CS is enabled comprises transmitting a reference to the publicly accessible source to the at least one node in which CS is enabled.

6. The method according to claim 5, wherein the publicly accessible source is a library transaction stored in the blockchain, and the first library identifier is a) a transaction identifier of the library transaction, or b) a block height of a block comprising the library transaction and a position of the library transaction within the block.

7. The method according to claim 6, comprising: creating the library transaction; and transmitting the library transaction to at least one blockchain node.

8. The method according to claim 6, wherein the step of creating an updated library transaction comprises: creating the updated library; and transmitting the updated library transaction to at least one blockchain node, thereby updating the library.

9. The method according to any one of claims 1 to 8, wherein the first library identifier is a hash value of the first HL reference library.

10. The compact transaction comprises a first transaction identifier, and the method comprises: generating an expanded version of the first compact transaction by converting the first CS to a first ES, wherein the converting comprises replacing each function identifier with a respective set of one or more LL functions configured to perform the same operation as the respective HL function; and generating the first transaction identifier based on the expanded version of the first compact transaction. The method according to any one of claims 1 to 9.

11. A step of creating or loading a first HL function table for the first HL reference library, wherein the first HL function table includes: i) each respective function identifier of the first HL functions, and ii) one or more IL functions and / or one or more LL functions for implementing each respective HL function, where each respective function identifier is mapped thereto. The method according to claim 10, wherein converting the first CS to the first ES comprises obtaining each respective set of one or more LL functions configured to perform the same operation as each respective HL function based on the mapping in the first HL function table. **Claim 12** The method according to claim 11, wherein at least one HL function uses a different HL function, and the first HL function table includes each respective function identifier of the different HL functions as part of the mapping. **Claim 13** The method according to any one of claims 1 to 12, wherein the first CS includes a second library identifier of a second HL reference library, the second HL reference library includes a second set of HL functions, and the first CS includes each respective function identifier of one or more of the second set of HL functions. **Claim 14** A step of creating or loading a second HL function table for the second HL reference library, wherein the second HL function table includes: i) each respective function identifier of the second HL functions, and ii) one or more IL functions and / or one or more LL functions for implementing each respective HL function, where each respective function identifier is mapped thereto. The method according to claim 13 when dependent on claim 11 or 12, wherein converting the first CS to the first ES comprises obtaining each respective set of one or more LL functions configured to perform the same operation as each respective HL function based on the mapping in the first HL function table. **Claim 15** The method according to claim 11 or any one of the claims dependent thereon, wherein the first HL function table comprises, as part of the mapping of each HL function, each variable identifier of one or more first HL variables used by each of the HL functions, and at least one IL function configured to call the one or more first HL variables during script execution.

16. A step of creating or loading a first HL variable table for the first HL reference library, the first HL variable table comprising: i) each variable identifier of each first HL variable, and ii) a value of each of the first HL variables, or a placeholder for the first HL variable, to which the respective variable identifier is mapped. The method according to claim 15, wherein converting the first CS to the first ES comprises using the first HL variable table to replace each respective variable identifier with the value of the respective first HL variable or its placeholder.

17. The method according to claim 16, wherein the first HL variables comprise one or more variable identifiers of each global variable available to the entire first compact script, and / or the first HL variable table comprises one or more variable identifiers of each local variable available only to the first HL functions of the first HL reference library.

18. The method according to claim 16 or 17, wherein converting the first CS to the first ES comprises writing the value of each first HL variable to the first HL variable table.

19. The method according to claim 16 or 17, wherein each first HL variable of the first HL variable table is a constant value that does not change during the processing of the first CS.

20. A computer-implemented method for processing a compact transaction, wherein the compact transaction is a blockchain transaction comprising a compact script (CS) that is at least partially described in an intermediate level (IL) scripting language and includes one or more IL functions, and when executed, each IL function is configured to perform an operation equivalent to an operation performed by one or more low level (LL) functions of an LL scripting language, and the CS is configured to perform an operation equivalent to an operation of a deployment script (ES) described in the LL scripting language, and the method is configured to verify the compact transaction, and is performed by a node in which the CS is enabled, Obtaining a first compact transaction comprising a first CS, wherein the first CS comprises: i) a first library identifier of a first high level (HL) reference library, the first HL reference library comprising a first set of HL functions described in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a respective set of one or more LL functions; ii) one or more respective function identifiers of the first set of HL functions; and iii) at least one IL function configured to call the one or more HL functions during script execution, Obtaining the first HL reference library, Processing the first compact transaction, the step of processing comprising: Generating an expanded version of the first compact transaction by converting the first CS to a first ES, the converting comprising replacing each function identifier with a respective set of one or more LL functions configured to perform the same operation as the respective HL function, A computer-implemented method. Claim 21 The compact transaction comprises a first transaction identifier, and the step of processing the first compact transaction comprises: generating a candidate transaction identifier based on the expanded version of the first compact transaction; determining that the candidate transaction identifier matches the first transaction identifier; rejecting the first compact transaction if the candidate transaction identifier does not match the first transaction identifier The method according to claim 20, comprising:

22. The method according to claim 20 or 21, wherein the first CS is a lock script, and the step of processing the first compact transaction comprises executing the first ES together with an unlock script of a second blockchain transaction.

23. The method according to claim 20 or 21, wherein the first CS is an unlock script, and the step of processing the first compact transaction comprises executing the first ES together with a lock script of a third blockchain transaction.

24. The method according to any one of claims 20 to 23, wherein the step of obtaining the first compact transaction comprises receiving the first compact transaction from a first party or another node enabled by the CS.

25. The method according to claim 24, wherein the step of obtaining the first HL reference library comprises receiving the first HL reference library from a first party or another node enabled by the CS.

26. The step of obtaining the first HL reference library comprises: obtaining a reference to a publicly accessible source in which the first HL reference library is stored; and obtaining the first HL reference library from the publicly accessible source The method according to any one of claims 20 to 25, comprising:

27. The method according to claim 26, wherein the publicly accessible source is a storage transaction stored in the blockchain, and the reference to the publicly accessible source is a transaction identifier of the storage transaction.

28. creating the storage transaction; sending the storage transaction to at least one blockchain node The method according to claim 26, comprising the above.

29. The method according to any one of claims 20 to 24, wherein the step of obtaining the first HL reference library comprises accessing the first HL reference library from memory.

30. The method according to any one of claims 21 to 30, wherein the first library identifier of the first HL reference library is a hash of the first HL reference library, and the step of obtaining the first HL reference library is based on the hash.

31. creating or loading a first HL function table for the first HL reference library, the first HL function table comprising: i) each respective function identifier of each first HL function, and ii) one or more IL functions and / or one or more LL functions for implementing each respective HL function, wherein the respective function identifiers are mapped; The method according to any one of claims 20 to 29, wherein obtaining each respective set of one or more LL functions configured to perform the same operation as each respective HL function based on the mapping in the first HL function table comprises converting the first CS to the first ES.

32. The method according to claim 31, wherein at least one HL function uses a different HL function, and the first HL function table comprises each respective function identifier of the different HL functions as part of the mapping.

33. The method according to claim 32, wherein the first CS comprises a second library identifier of a second HL reference library, the second HL reference library comprises a second set of HL functions, the first CS comprises each respective function identifier of one or more of the second set of HL functions, and the method comprises obtaining the second HL reference library.

34. The step of creating or loading a second HL function table for the second HL reference library, the second HL function table comprising: i) each respective function identifier of the second HL functions, and ii) one or more IL functions and / or one or more LL functions for implementing each respective HL function, to which each respective function identifier is mapped. The method according to claim 33 when dependent on claim 31 or 32, wherein converting the first CS to the first ES comprises obtaining each respective set of one or more LL functions configured to perform the same operation as each respective HL function based on the mapping in the first HL function table.

35. The method according to claim 31 or any claim dependent thereon, wherein the first HL function table comprises, as part of the mapping of each respective HL function, each respective variable identifier of one or more first HL variables used by each respective HL function, and at least one IL function configured to call the one or more first HL variables during script execution.

36. The step of creating or loading a first HL variable table for the first HL reference library, the first HL variable table comprising: i) each respective variable identifier of the first HL variables, and ii) the value of each respective first HL variable, or a placeholder for that first HL variable, to which each respective variable identifier is mapped. The method according to claim 35, wherein converting the first CS to the first ES comprises using the first HL variable table to replace each respective variable identifier with the value of the respective first HL variable or its placeholder.

37. The method according to claim 36, wherein the first HL variables comprise one or more variable identifiers of each respective global variable available to the entire first compact script, and / or the first HL variable table comprises one or more variable identifiers of each respective local variable available only to the first HL functions of the first HL reference library.

38. The method according to claim 36 or 37, wherein converting the first CS to the first ES comprises writing the respective value of each first HL variable to the first HL variable table.

39. The method according to claim 36 or 37, wherein each first HL variable of the first HL variable table is a constant value that does not change during the processing of the first CS.

40. A memory comprising one or more memory units, A processing device comprising one or more processing units A computer device comprising: the memory storing code configured to be executed on the processing device; and the code being configured to implement the method according to any one of claims 1 to 39 when on the processing device.

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

Images