Protocol for communicating compact scripts

Abstract

A computer-implemented method for transmitting a compact transaction, where the compact transaction is a blockchain transaction comprising a compact script written at least in part in an intermediate script language, the method comprising: generating a first compact transaction, the first compact transaction comprising a first CS, wherein the first CS comprises: a first library identifier of a first high-level reference library, the first HL reference library comprising a first set of HL functions written in an HL scripting language, each HL function configured to perform an operation equivalent to an operation performed by a respective set of one or more LL functions; corresponding function identifiers of one or more HL functions in the first set of HL functions; and, at least one IL function, the at least one IL function configured to invoke the one or more HL functions during execution of the script; and transmitting the first compact transaction to at least one CS-enabled node, where each CS-enabled node is configured to verify a compact transaction.

Description

Technical Field

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0023] The present application discloses techniques for using a function library that can be referenced in a locking script and / or unlocking script of a blockchain transaction that includes a compact script, thereby allowing blockchain nodes and locking script creators to efficiently communicate compact scripts.

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

[0025] According to one aspect disclosed herein, there is provided a computer-implemented method of transmitting a compact transaction to a node of a blockchain network, wherein the compact transaction is a blockchain transaction, the blockchain transaction comprising a compact script (CS) written at least in part in an intermediate-level (IL) scripting language, and comprising 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 LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform an operation equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a first party and comprises: generating a first compact transaction, the first compact transaction comprising a first CS, wherein the first CS comprises: i) a first high-level (HL) scripting language; ) a first library identifier of a reference library, the first HL reference library including a first set of HL functions (or referred to as a first set of HL functions, a first group of HL functions) written in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a corresponding set of one or more LL functions (or referred to as a corresponding set of one or more LL functions, a corresponding group of one or more LL functions), ii) corresponding function identifiers of one or more HL functions in the first set of HL functions, and iii) at least one IL function, the at least one IL function being configured to call the one or more HL functions during script execution; and, transmitting the first compact transaction to at least one CS-enabled node, wherein each CS-enabled node is configured to verify the compact transaction.

[0026] According to one aspect disclosed herein, there is provided a computer-implemented method for processing a compact transaction, wherein the compact transaction is a blockchain transaction, the blockchain transaction includes a compact script (CS) written at least in part in an intermediate-level (IL) scripting language, and it includes one or more IL functions, wherein when executed, each IL function is configured to perform operations equivalent to operations performed by one or more LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform operations equivalent to extended scripts (ES) written in the LL scripting language, and wherein the method is performed by a CS-enabled node, the CS-enabled node is configured to verify whether the compact transaction is valid, and the method includes: obtaining a first compact transaction, the first compact transaction including a first CS, wherein 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 HL reference library written in the HL scripting language; a set of HL functions (or referred to as a first set of HL functions, a first group of HL functions), each HL function being configured to perform an operation equivalent to an operation performed by a corresponding set of one or more LL functions (also referred to as a corresponding set of one or more LL functions, a corresponding group of one or more LL functions), ii) corresponding function identifiers of one or more HL functions in the first set of HL functions, and iii) at least one IL function, the at least one IL function being configured to call the one or more HL functions during script execution; obtaining the first HL reference library; and processing the first compact transaction, wherein the processing comprises: generating an extended version of the first compact transaction by converting the first CS into a first ES, the conversion comprising: replacing each function identifier with a corresponding set of one or more LL functions, the corresponding set of one or more LL functions being configured to perform the same operation as the corresponding HL function.

[0027] The first party (e.g., a user, a machine, a smart contract, etc.) creates a compact transaction including a compact script. For convenience, the first party is referred to as Alice. Alice has access to a high-level (HL) reference library, i.e., a collection of HL functions written in the HL scripting language (e.g., the user-oriented language described above). It should be noted that references to the HL scripting language refer to the highest-level scripting language. The HL functions of a given library may be related in a sense because they relate to the same purpose and may also interact with other libraries to achieve a common goal. However, this is not required. For example, a given library may include a collection of HL functions created by a specific party (e.g., Alice). Alice includes a reference to the HL reference library or an identifier of the HL reference library in the compact script. Alice also includes in the compact script the corresponding function identifiers of one or more HL functions stored in the HL reference library.

[0028] Each HL function can be extended to an LL function (e.g., an opcode). Therefore, each HL function is configured to perform an operation equivalent to an operation performed by a group of LL functions (also referred to as a group of LL functions). Each HL function is defined in the library using at least a corresponding set of LL functions (also referred to as a corresponding set of LL functions). HL functions can be defined using only the corresponding set of LL functions. For example, this may be the case for simple HL functions. In other examples, HL functions can be defined using both the corresponding 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 this case, the reference library may include corresponding definitions of the other HL functions. In addition, it may also be the case that one, some or each CS-enabled node knows the definition of one or more HL functions. This may be the case for public or standard HL functions, which can be defined by a public protocol run by each CS-enabled node.

[0029] The combination of the library reference and the function identifier allows CS-enabled nodes and other parties to identify which HL functions will be used during the processing (e.g., verification) of a compact transaction. That is, a CS-enabled node can identify the library corresponding to the library reference and then identify the required HL function from the library.

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

[0031] The CS-enabled node is capable of generating an extended version of the compact transaction (i.e., an extended transaction). Specifically, the CS-enabled node is capable of generating an extended version of the compact script (i.e., an extended script). The compact script is converted to an equivalent extended script by replacing each function identifier with the set of LL functions, the set of LL functions being configured to perform the same operation as the HL function identified by the corresponding function identifier. This may involve the use of a function table. Thus, the reference library is used to obtain the required LL function. For example, the CS-enabled node may be required to generate a transaction identifier of the compact transaction in an extended form. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

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

[0041] Figure 8 An exemplary method for generating and verifying a compact transaction is schematically illustrated;

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

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

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

[0045] Fig.12 An exemplary system for sending a compact transaction referencing a reference library is schematically illustrated;

[0046] FIG. 13A to FIG. 13C Schematically showing an exemplary reference library, function table and variable table, respectively;

[0047] FIG. 14A to FIG. 14C Schematically shows a variable table being populated;

[0048] Fig.15 A memory stack is schematically shown;

[0049] FIG. 16A to FIG. 16E Schematically shows the expansion of an IL script to an LL script;

[0050] 17A to 17D Schematically showing an exemplary reference library, function table and variable table, respectively;

[0051] Fig.18 An exemplary overview of the workflow for creating, sending, and verifying a compact script is schematically shown;

[0052] Fig.19 An exemplary tool for developing compact transactions is schematically illustrated;

[0053] Fig. 20 Schematically showing the compilation of a reference library into a function table;

[0054] Fig.21 schematically illustrates an exemplary reference library including a function table with parameters;

[0055] Fig. 22 schematically illustrates an example format of a compact script during development in text form, and in byte array format after publication as a transaction;

[0056] Fig.23 Schematically illustrating a node that receives a compact transaction and converts it into an extended transaction;

[0057] Fig.24 schematically illustrates an exemplary process performed by a node receiving a compact transaction;

[0058] Fig.25 Another exemplary process performed by a node receiving a compact transaction is schematically illustrated. DETAILED DESCRIPTION

[0059] 1. Exemplary System Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0087] 2. UTXO-based model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0107] 3. Side Channels

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

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

[0110] 4. Client software

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

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

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

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

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

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

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

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

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

[0120] 5.Node software

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

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

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

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

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

[0126] 6. Advanced scripting language

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0142] 2. Unlocking script; and

[0143] 3. Serial number.

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

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

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

[0147] In other words, in some embodiments, there are only two levels of scripting language: high-level language and low-level language; while in other embodiments, there are three levels of scripting language: user-oriented (highest level), mid-level language, and low-level language.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0185]

[0186] Here are a few notes.

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

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

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

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

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

[0192]

[0193] Table 1: Unsigned transactions in the metascript

[0194]

[0195] Table 2: Unsigned extended transaction

[0196]

[0197] Table 3: Signed extended transaction

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

[0199]

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

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

[0202] a. Version and lock time;

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

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

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

[0206]

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

[0208]

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

[0210]

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

[0212]

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

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

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

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

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

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

[0219] 1. Use the library registry (see the following section) or reference table to convert the meta lock script to the corresponding native lock script to obtain the following:

[0220]

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

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

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

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

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

[0226]

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

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

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

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

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

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

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

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

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

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

[0237]

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

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

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

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

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

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

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

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

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

[0247] 7. Compact Script Library

[0248] Figures 5 to 9 The above description describes a protocol for generating a compact transaction and converting a compact transaction into an extended transaction. Some or all of the features described in conjunction with these figures may be applied to Figures 10 to 25 Embodiment of the invention.

[0249] Fig.10 The protocol is summarized from the perspective of a CS-enabled node 104a receiving a transaction. As shown, the CS-enabled node 104a receives a blockchain transaction. If the blockchain transaction is a compact transaction, the compact transaction is processed in its compact form and verified. It should be noted that this may include converting the compact transaction to its extended (canonical) form. If the blockchain transaction is an extended transaction (i.e., written in a native low-level scripting language), the extended transaction is processed in its extended form and verified. Identification can be performed by checking whether there are explicit protocol flags or any implicit indicators (e.g., some HL functions (also known as meta-opcodes)) in the transaction. The explicit flag can be a predetermined, agreed transaction version number, or it can be a byte at the beginning of a locking script or unlocking script. The implicit indicator can be the format of the locking script. For example, if the locking script starts with a known HL function (e.g., MOP_LIBLOAD), the corresponding transaction can be identified as a compact transaction.

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

[0251] Fig.12 An exemplary system for communicating compact scripts is shown. The system includes one or more users 103 and one or more CS-enabled nodes 104a. For simplicity, only one user, Alice 103a, is shown. Similarly, only two CS-enabled nodes 104a are shown, but in general, the system can include any number of CS-enabled nodes. Fig.12 Also shown is a blockchain network 106. Although shown distinct from the CS-enabled node 104a, it should be understood that the blockchain network 106 includes CS-enabled nodes. The blockchain network 106 may also include one or more CS-disabled nodes.

[0252] Alice 103a generates a compact transaction (compact Tx) and sends it to the CS-enabled node 104. The CS-enabled node 104a processes the compact Tx and / or forwards the compact Tx to one or more different CS-enabled nodes 104a for processing. Processing the compact Tx may include verifying the compact Tx. This will be discussed below.

[0253] Alice 103a has access to one or more HL function libraries, each of which contains one or more HL functions. HL functions are functions written in the HL scripting language (i.e., a scripting language that can be converted into functions written in the LL scripting language) (see below for further details). HL functions may be unique to an HL reference library, but not necessarily. An HL reference library may include some related HL functions (i.e., functions that are at least intended to complement and / or be used together). Additionally or alternatively, an HL reference library may include some unrelated HL functions.

[0254] The HL reference library may be stored in the memory of one or more CS-enabled nodes. Additionally or alternatively, the HL reference library may be stored in a "library transaction" (i.e., a blockchain transaction that includes the HL reference library) on the blockchain, such as 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.

[0255] Fig.13A An exemplary HL reference library is shown. In this example, the HL function is preceded by the term "word", indicating that the next term is an HL function. The HL reference library includes several HL functions, including "counter", "length", and "reverse". As shown, the counter function is configured to increase the current value of the counter. 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 alphabetical order of a string).

[0256] Alice 103a creates a compact transaction. The compact transaction includes a compact script. The compact script can be a compact lock script or a compact unlock script. The compact script includes a library identifier (or library reference) of the HL reference library. For example, the library identifier can be a hash of the source code of the HL reference library, or a pruned version thereof (e.g., the first n leading bytes of the hash). The library identifier enables other parties (including CS-enabled nodes) to obtain the required HL reference library, for example, from memory.

[0257] In some examples, the library identifier is a transaction identifier (TxID) of a library transaction that includes a HL reference library. The library identifier can be a block height and position pair instead of a TxID, the block height indicating the block including the library transaction, and the position indicating the position of the library transaction in the block. These library identifiers uniquely identify library transactions and enable CS-enabled nodes to obtain the correct reference library. In these examples, the HL reference library can be stored on-chain by Alice 103a or a blockchain node 104 (e.g., a CS-enabled node 104a).

[0258] As an option, if the HL reference library is stored off-chain, the library identifier may include a link (e.g., a URL) to the off-chain resource. Alternatively, Alice 103a may have the link separate from the library identifier. This may be useful if several HL function libraries are stored in the same off-chain resource.

[0259] In some examples, the library identifier identifies the 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 the HL function created by a different entity (e.g., a different user 103 or a CS-enabled node 104a).

[0260] The compact script also includes one or more function identifiers that identify corresponding HL functions stored in the identified HL reference library. For example, the HL functions may be stored in a sequence, and a given function identifier may identify the HL function based on its position in the sequence. Alternatively, the HL function may be associated with its corresponding function identifier in other ways, for example, the function identifier may be an abbreviation of the function.

[0261] The compact script also includes at least one IL function ("call function"), which, when executed, is configured to call the HL function identified by the corresponding function identifier. 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) an HL reference library. For example, the compact script can take the following form:

[0262] 12ab.0MOP_FN_CALL,

[0263] Where 12ab is a library identifier, 0 is a function identifier, and MOP_FN_CALL is configured to call the HL function corresponding to the function identifier 0 from the reference library 12ab. Alternatively, the compact script may include an IL function ("library loading function") that, when executed, is configured to call (i.e., load) the identified reference library. For example, the compact script may take the following form:

[0264] 12ab MOP_LIB 0MOP_FN_CALL,

[0265] Among them, MOP_LIB is a library loading function configured to load the reference library 12ab.

[0266] After creating the compact transaction, Alice 103a sends the compact transaction to one or more CS-enabled nodes 104a. Alice 103a may send the compact transaction to a specific node 104a, for example, a node that she knows has access to the required reference library. The compact transaction may be sent to any CS-enabled node 104a. Alice may send the compact transaction along with the required reference library, or she may have already sent the required reference library to the node 104a. If the reference library can be obtained in other ways (e.g., from a library transaction), then it does not need to be sent.

[0267] In some embodiments, Alice 103a is required to generate an extended version of the compact transaction (i.e., the corresponding extended transaction) in order to generate a transaction identifier based on the extended transaction (i.e., a version of the compact transaction that includes performing an LL function equivalent to the operation of the identified HL function). Alice 103a inserts the required LL function (e.g., opcode) into the extended transaction. In other words, she replaces the function identifier with the required LL function. The resulting extended transaction contains only the LL function and the data. The extended transaction is then hashed to give a transaction identifier. Alice 103a is then able to insert the transaction identifier into the compact transaction and send the compact transaction (including the transaction identifier) ​​to the CS-enabled node 104a.

[0268] Alice 103a may generate an extended transaction using the HL function table. HL functions are specific to a particular reference library, and the corresponding function identifiers of the HL functions are stored in the reference library. Each function identifier is stored together with (i.e., mapped to) a corresponding set of LL functions (and optionally IL functions) required to implement the corresponding HL function. Alice 103a may generate the HL function table, or she may load the function table, for example, from a memory. For example, Alice 103a may have previously used the same reference library and therefore have already created or loaded the function table.

[0269] Alice 103a converts the compact script into an extended version (extended script) by replacing the function identifier with a corresponding set of LL functions (and optionally IL functions) that map to the corresponding function identifiers in the function table. If the function identifier maps only to LL functions, then only the function identifier is replaced with these LL functions. If the function identifier maps to both LL functions and IL functions, then the function identifier is replaced with the LL function and the IL function, and then the IL function is replaced with the corresponding set of LL functions required to implement the IL function. This may occur in one action, that is, all required LL functions are inserted into the extended script at the same time; it may also occur in two actions, that is, the IL function is inserted and then replaced with the required LL function. A set of LL functions corresponding to the IL function can be predefined. In this sense, IL functions are predefined functions that may be known to all CS-enabled nodes and perform predefined operations.

[0270] Fig. 13B Shows Fig.13A An exemplary function table of a reference library. As shown in the figure, each function identifier is mapped to a corresponding set of IL functions and LL functions, where IL functions begin with "MOP" and LL functions begin with "OP". It should be understood that this is only an illustrative example, and IL functions and LL functions can be distinguished in different ways. Fig. 13B In the example of , the name of the HL function is included in the function table. In other examples, the function name can be omitted.

[0271] exist Fig.13A and Fig. 13B In the example of , some HL functions reference (i.e., use) different HL functions. For example, the reverse function uses the length function. The function table includes the corresponding function identifier of the length function as part of the mapping of the reverse function. When converting the compact script to the extended script, Alice 103a uses the function table to replace the function identifier of the length function with the IL function and LL function required to implement the length function. In other words, the function identifier of the reverse function is replaced with the "implementation" of the reverse function, and the function identifier of the length function that constitutes part of the implementation is replaced with the implementation of the length function. The implementation of the HL function involves the IL function and / or LL function mapped to the function identifier of the HL function.

[0272] In some embodiments, Fig. 13B As shown, the implementation of the HL function may include one or more variable identifiers of the corresponding variables to be used by the HL function. Similar to the function identifier, the variable identifier may be based on the location of the corresponding variable in the library. Fig. 13B In the examples of , variable identifiers begin with a dollar sign $. Other ways of indicating variable identifiers may be used, such as using the name of the variable. In these embodiments, the implementation also includes a corresponding IL function ("get variable function") that, when called (i.e., executed), is configured to retrieve the identified variable from memory. A single get variable function may be used for the entire implementation, or a separate get variable function may be used for each variable identifier of the implementation. For example, the IL function MOP_GET_VAR follows Fig. 13B Each variable identifier (e.g., $1) in the example of . The implementation may also include an IL function ("set variable function") that is configured to output the identified variable to memory when called.

[0273] Variables required by the HL function of a given reference library may be stored in a variable table, and the Get Variable function and the Set Variable function are configured to obtain variables from the variable table and output variables to the variable table, respectively. Fig.13A An exemplary variable table of the function table is as follows Fig. 13C As shown. The variable table includes the corresponding variable identifiers and the values ​​of the corresponding variables. If the value of a variable is unknown when the variable table is created or loaded (for example, because the variable table depends on currently unknown inputs), a placeholder value (for example, "empty") can be used. When converting a compact script to an extended script, a variable table of the referenced library is created or loaded, and the variable identifiers and associated IL functions (for example, get variable functions) that form part of the implementation of a given HL function are replaced with the values ​​of the identified variables.

[0274] In some examples, a variable can be classified (e.g., programmed) as a global variable. A global variable is interpreted as available to the entire script. That is, any function of the compact script can utilize the global variable. Alternatively, a variable can be classified as a local variable. A local variable is interpreted as available only to the function of the reference library to which the local variable belongs.

[0275] In some examples, a variable table may be interpreted as a constant table, and variables may only be read from the constant table but not written to the constant table.

[0276] Although the above description relates to a single reference library, it is not excluded that the compact script may include a library identifier of a second reference library. Typically, a compact script may include corresponding library identifiers for any number of different function libraries. This allows Alice 103a to generate a desired compact script (e.g., a desired locking condition) using functions from different function libraries. In these embodiments, Alice 103a may create or load a corresponding function table for each reference library identified in the compact script. Similarly, Alice 103a may create or load a corresponding variable table for each reference library identified in the compact script.

[0277] It should also be noted that a reference library may be updated, for example, by Alice 103a. This includes updating the reference library after publishing a compact transaction on the blockchain that references the reference library. For example, if the reference library is stored in a library transaction on the blockchain, Alice 103a (from a different entity, such as CS-enabled node 104a) may submit an updated library transaction to the blockchain and include the updated library, the updated library transaction spending the output of the previous library transaction. More details on updating a library are provided further below.

[0278] As described above, Alice 103a sends the compact transaction to the CS-enabled node 104a. The CS-enabled node 104a processes the compact transaction by converting the compact transaction into an extended version (i.e., the corresponding extended transaction). That is, the compact script is converted into an extended script. This process is substantially the same as the process Alice 103a performs to generate an extended transaction. Therefore, any of the above embodiments involving generating an extended transaction (including the use of a function table and a variable table) can be equally applicable to the CS-enabled node 104a.

[0279] The corresponding computing devices of Alice 103a and CS-enabled node 104a may each include one or more compilers for converting compact scripts into extended scripts. For example, these computing devices may include (e.g., as part of a scripting engine) an HL (or SDL) compiler, an IL (or metascript) compiler, and an LL (or transaction) compiler, which will be discussed in more detail below.

[0280] In more detail, the CS-enabled node 104a obtains (e.g., receives from Alice 103a) a compact transaction. The CS-enabled node 104a also obtains one or more function libraries identified in the compact script of the compact transaction. This may involve retrieving one or more of these function libraries from any of the following: Alice 103a, a different CS-enabled node 104a, a corresponding blockchain transaction, an off-chain resource (e.g., a cloud server), or a memory of the CS-enabled node 104a. In some examples, a library identifier (e.g., a hash of a library) can be used as a lookup to find a corresponding reference library from a plurality of function libraries stored, for example, in a repository.

[0281] The CS-enabled node 104a processes compact transactions, including generating extended versions of compact transactions. Similar to Alice 103a, the CS-enabled node does this by replacing HL function identifiers with LL functions required to perform the same operations as the identified HL functions. The CS-enabled node 104a may do this by creating or loading one or more HL function tables in the same manner as described above for Alice 103a. The CS-enabled node may also create or load one or more HL variable tables in the same manner as described above for Alice 103a.

[0282] The CS-enabled node 104a may process the compact transaction to generate a transaction identifier based on the extended transaction. The CS-enabled node 104a may compare the transaction identifier with a transaction identifier that forms part of the compact transaction (i.e., the transaction identifier that Alice 103a included in the compact transaction). If the two transaction identifiers do not match, the CS-enabled node may reject the compact transaction (i.e., verify that the compact transaction is invalid). Rejecting the compact transaction includes not including the compact transaction in the new block 151, and may also include not broadcasting the compact transaction to other nodes 104.

[0283] In the case where the compact script is a locking script, processing the compact transaction may include executing the compact script and the unlocking script of the spending transaction, for example, to verify that the spending transaction is valid. Conversely, if the compact script is an unlocking script, processing the compact transaction may include executing the compact script and the locking script of the previous transaction, for example, to verify that the compact transaction is valid. It should be noted that a compact transaction may be executed in a compact form or an expanded form, depending on whether the other transaction is a compact transaction.

[0284] For the avoidance of doubt, any reference to Alice 103a or the CS-enabled node 104a performing an action means that the action is performed by its corresponding computing device (eg, a scripting engine configured to process compact scripts).

[0285] Further examples of the above embodiments are provided below. Although described in terms of the Bitcoin blockchain, the following examples may be implemented on any blockchain with the required capabilities.

[0286] 7.1 Library

[0287] The described protocol allows the use of loops and similar functions such as for, while, and do while. This significantly enhances script compression and allows the implementation of applications that were previously impossible. Any locking script must have a deterministic specification (i.e., low-level) form that includes Bitcoin opcodes, and ideally should be known when the transaction is submitted to the Bitcoin network. Therefore, it is recommended to test script execution before submitting compact transactions to the Bitcoin network. The library is used to enable reuse of tested metascripts and allow efficient reference to tested metascripts. Several aspects of the function library are described below.

[0288] 1) Library creation and testing. Developer Alice 103a wants to write a smart lock script that leverages both SDL features (i.e., HL scripting language) and metascripts (i.e., IL scripting language). Mike is a blockchain node 104a that accepts compact transactions and allows library uploads. He 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. If the compilation is successful, Alice 103a is provided with a library identifier that she will use when referencing the library.

[0289] 2) Use the library when creating the locking script. Alice 103a uses the library identifier in the transaction's locking script and sends the transaction to Mike 104a for mining. Alice 103a again uses another interactive service in Bob's interactive services to check whether her compact script ("tx-compact") is compiled correctly by Mike 104a. If Bob accepts tx-compact, Alice submits the transaction to the blockchain 150. During transaction verification and TxID generation, Mike 104a uses the library identifier to locate the library. Other nodes that enable CS and accept Mike's compiler results will be able to use the library identifier to obtain the library. Other developers can also use Alice's library by using the library ID.

[0290] 3) Library updates. Libraries can be updated and versioned. It may be necessary to keep all version history to retrieve the canonical form of historical transactions. Library references in compact transactions can be updated at any time if the changes do not result in a different canonical form. This may be correct, for example, if a new version of a library updates a function in the library that is not used by the compact transaction.

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

[0292] 5) Behind the scenes of library upload and use. During library compilation, a variable table can be generated. Typically, the values ​​of the variables are not set at this time. When Alice 103a uses the library in her locking script, some variables may need to be set. The standard is that the canonical form of the locking script should be determined at this stage. For example, if loops are used in the locking script, the number of loops should be determined at this stage and must not depend on the unlocking script. Therefore, Alice and Mike can have an interactive session to test the use of library functions in the locking script and initiate the required variable table values. The CS-enabled node 104a can agree on a set of common tests and standards for adding libraries to the public repository. Although not mandatory, this can maximize efficiency and improve the robustness and security of the system.

[0293] 6) Referencing external libraries. Using libraries allows data and code to be stored and referenced without being explicitly included in the script. These libraries can be directly hosted or retrieved by CS-enabled nodes, so these libraries do not need to be propagated with MS transactions, saving storage space and bandwidth. The new meta-opcode (i.e., IL function) MOP_LIB can be used to reference libraries in meta-scripts, for example, using hash (source code of the library) MOP_LIB or lib_ref ​​MOP_LIB. It should be noted that other meta-opcodes such as MOP_LIBLOAD or MOP_LOADLIB can be used. The reference to a library can be a hash of the code of the library. Therefore, any changes to the library (including updates) will invalidate the reference. Therefore, copies of all versions of the library can be stored.

[0294] 7) Library Registry. Nodes can use one or more library registries to retrieve referenced libraries. These libraries can be stored using a shared public registry maintained by a standards body. The registry can be defined by a consensus mechanism or a deterministic set of rules based on the frequency of use of the library in the blockchain. Alternatively, nodes can each publish their own mapping of keys to canonical references, and users can submit their transactions to compatible nodes using short keys. If a node supports compact scripts but does not know the referenced library, it can search for the library in the shared library registry, or it can query other nodes to check if they know the reference. If the exploration 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.

[0295] 8) Repository checksum. If a compact transaction references an incorrect repository (e.g., a different repository using the same key), the generated transaction ID will be invalid. This ensures that only the intended repository can be used.

[0296] Referencing an external library in a compact transaction means that an exact copy of that library must be available at all times in the future. This can cause problems: if for any reason a library referenced in a transaction is unavailable at some point, the node will be unable to validate the transaction, so that transaction and all subsequent transactions become invalid. Therefore, users who have satoshis, tokens, or other UTXOs that depend on (or have a parent transaction that depends on) a transaction that uses an external library can keep a copy of any library used in any dependent published MS transactions. Node 104a or other parties can provide this service.

[0297] An alternative approach is to force transactions that spend one or more compact transactions to add all required libraries as additional outputs (e.g., in the transaction's unspendable (OP_RETURN) outputs). This approach preserves the bandwidth and storage gains obtained by broadcasting compact transactions that include references to libraries when the compact transaction is in the mempool. However, when the transaction is inserted into a published block, the required storage space increases (because the spending transaction includes the entire library code).

[0298] A more efficient alternative is to store the library code in published transactions, using the blockchain itself as storage. A meta-opcode (e.g., MOP_LIBTX) can reference a transaction that includes a library (e.g., a transaction with an OP_RETURN followed by a set of data and functions). A compact transaction using MOP_LIBTX may be considered invalid if the referenced transaction does not exist or does not contain an OP_RETURN with a valid (meta) script. A transaction that includes a library can be referenced using its transaction ID (32 bytes) or its compact version (e.g., the first 4 bytes). When the compact version is used, conflicts may occur. In this case, the transaction ID of the compact transaction can be used as a checksum (only the correct library will produce a correct transaction ID). The syntax of MPO_LIBTX can take one of the following forms:

[0299] TxID library MOP_LIBTX

[0300] or

[0301] shorten 4-bytes (TxID library) MOP_LIBTX

[0302] Alternatively, instead of a transaction ID, one can reference the block height and transaction position within the block. In this case, the syntax could be:

[0303] BlockHeight library Position library MOP_LIBTX

[0304] 9) Built-in libraries. Blockchain nodes can provide a set of commonly used functions that are available by default, creating a de facto built-in function library. Nodes can advertise the functions they provide by publishing a description and implementation associated with their node version number in a transaction or on a website. Compact transactions can reference these libraries without specifying the library, just the function number. For example:

[0305] node_ver OP_VERNOTIF

[0306] MOP_LIB 12ab

[0307] Specifies that the library must be searched and loaded only if node_ver is different from the version number of node. Having built-in functions may optimize code and standardize the function code base.

[0308] 7.2 Variable table

[0309] The variable table can be used to store local variables and global variables. Local variables are only valid within the scope of a specific library, while global variables are valid for the entire script, that is, at the transaction input level (that is, each transaction input has its own global space).

[0310] The variable table enables the use of variables in reusable compact scripts and external libraries, allowing placeholders for information that is unknown when writing the code or locking the script (i.e., information that is only provided when creating the unlocking script) to be inserted. In the context of compact scripts, a variable is a symbolic index that references a pointer to a variable table. Once a variable is stored in a variable table using a specific index ("variable identifier"), the variable can be referenced again in a locking script using the same index. The variable table maps indexes with relative variable values. In some examples, variables can be written and read multiple times when executing a script (i.e., when verifying a transaction or spending a transaction). When the script terminates (when a transaction is deemed valid or invalid), the variable table is de-allocated.

[0311] The meta-opcode for storing a variable might be MOP_SET_VAR, preceded by the value of the variable and an index into the variable table. Similarly, the meta-opcode for reading from the variable table might be MOP_GET_VAR, preceded by an index into the variable table. The index into the variable table might be preceded by a dollar character (e.g., $0 for index 0).

[0312] Two types of variable tables can be defined: global variable tables and library variable tables. When MOP_GET_VAR and MOP_SET_VAR are used directly in a locking script, they can read from and write to the global variable table. When MOP_GET_VAR and MOP_SET_VAR are used in an external library, they can read from and write to the library variable table. Each library loaded in a locking script has its own private library variable table.

[0313] The global variable table is allocated when the locking script is loaded, and is used to generate a transaction ID (when creating a transaction) or for spending transactions. A user 103 creating a compact transaction can use the global variable table to declare and store variables, for example when the value is unknown when the locking script is written.

[0314] An example of a global variable table with two uninitialized indexes is Fig.14A For example, the compact script

[0315] 'hello'$0MOP_SET_VAR

[0316] Set the row with index 0 in the variable table to 'hello' (e.g. Fig. 14B ), while the compact script

[0317] $0MOP_GET_VAR

[0318] Read the variable at index 0 from the variable table and insert its value into the locking script (i.e., push the value onto the stack).

[0319] When a library is loaded in a locking script for the first time during script execution, a new library variable table is allocated and initialized (reloading the same library within the same script does not reinitialize its variable table). This table has two main purposes: The first purpose is to store variables that are initialized in the library and therefore cannot be accessed directly from the locking script. The second purpose is to store and track function parameters (i.e., the inputs to each function). Each function in a library can have a set of variables (pre-assigned with their relative indexes), one variable per parameter. When a function is called in a locking script, the input parameters are passed to the function by setting the relative variables in the library variable table. The library variable table can have local variables (within the scope of the function) and library variables (within the scope of the library). Local variables have an index reserved for them in the library variable table and specified in the function table (see the "Function Table" section below). These local variables are reinitialized each time a function is called. Library variables share the same index between different functions in the same library. These variables are initialized only when a function is loaded in a locking script for the first time.

[0320] The global variable table can be separate from the library table because the library variable table can store variables that should not be accessible to users who import the library in the locking script. For example, a library containing parameters for elliptic curves (e.g., secp256k1) can store these parameters in the library variable table. It may be beneficial to ensure that users cannot modify these values ​​from the locking script (e.g., using MOP_SET_VAR with different values). In some implementations, local variables and global variables within a library can be stored in separate tables (global library variable table and local library variable table). When the library is loaded in the locking script, the global library variable table is initialized; when the script execution ends, the global library variable table is de-allocated. Each time a function is called, the local library variable table is initialized; when the function ends, the local library variable table is de-allocated.

[0321] Variable tables can be either dynamically typed or statically typed. In the latter case, the script engine checks variable types and raises an error if a variable that was initially assigned one variable type is later assigned a different type. Such an error results in an invalid script (equivalent to a script ending with OP_FALSE at the top of the stack). Compact scripts using statically typed variable tables are generally more complex to write. However, stricter, structured error checking at compile time enables errors to be detected, reducing the likelihood of publishing scripts that contain errors. These errors may result in publishing a transaction with an unspendable locking script, or publishing a spendable transaction with conditions that differ from those expected. If statically typed variable tables are used, the variable type can be stored together with the index and the variable value, such as Fig. 14C shown.

[0322] MOP_SET_VAR and MOP_GET_VAR are meta-opcodes used to enable the use of variables in compact scripts. It should be noted that these are just exemplary labels and other meta-opcodes that perform the same operation can be used instead. The variable opcodes can be expanded into canonical scripts that use the alt stack to store variables. MOP_SET_VAR pushes a variable value to the alt stack based on its index. MOP_GET_VAR copies a variable value from the alt stack based on its index. Fig.15 An exemplary alt stack showing the location of variables is shown. The expansion of MOP_SET_VAR and MOP_GET_VAR to their relative canonical opcodes is described in WPxxxx (referenced by Wei). Because their expansions are very long, the remaining description concerns MOP_SET_VAR and MOP_GET_VAR using their relative meta-opcodes even when the compact script is expanded to its canonical form. Alternatively, if the value of a variable can be calculated at compile time, the variable is replaced with its actual value during script compilation or expansion.

[0323] An example compact script is Fig.16A , and the transformation is as follows: Line 1 results in the insertion of 'hello' at index 0 in the variable table. The state of the variable table is Fig. 16B Line 2 causes the string 'hello' to be read from the variable table and the number of characters to be counted. The state of the variable table is as follows: Fig. 16C Finally, the value is stored at index 1 in the variable table. Line 3 causes variable 1 (i.e., 5) to be read from the variable table and compared with 5, writing the result on the top of the stack. The expanded specification script is as follows Fig.16D The corresponding alt stack is as shown. Fig.16E shown.

[0324] 7.3 Function Table

[0325] Each time a reference library is called during script execution, a function table may be created or loaded. The function table is created by the script engine and stored in memory (i.e., Alice 103a or CS-enabled node 104a). The function table maps a numerical index ("function identifier") to the header of the function and optionally the implementation of the function in a metascript or specification script.

[0326] Functions declared in external libraries can be called from a transactional locking script using the meta-opcode MOP_FN_CALL followed by the index of the function. For example, the following locking script:

[0327] 012ab MOP_LIB 0 MOP_FN_CALL

[0328] Translates to: load (or generate) a function table from library ID 012ab, then insert a metascript or specification script for the function at index 0 in the function table into the locking script. After the function table is loaded, multiple functions can be called. For example, replace the following locking script:

[0329] 012ab MOP_LIB 0 MOP_FN_CALL 1 MOP_FN_CALL

[0330] Translates to: load (or generate) the function table from library with ID 012ab, then insert the body of the function at index 0 in the function table (followed by the function at index 1) into the locking script.

[0331] When you need to use multiple libraries in the same locking script, you can specify the required library when the referenced library changes. For example, to call function 0 from library 012ab, then call function 0 and function 1 from library 567cf, and finally call function 1 from library 012ab, you can use the following structure:

[0332] 012ab MOP_LIB 0 MOP_FN_CALL 567cd MOP_LIB 0 MOP_FN_CALL 1 MOP_FN_CALL012ab MOP_LIB 1 MOP_FN_CALL

[0333] It is worth noting that MOP_LIB must be called only when the referenced library changes.

[0334] A more compact form may be used. For example, in some implementations (of script engines), the library ID may be specified directly during a function call, with a dot (".") separating the library ID from the function index. Following this syntax, a locking script:

[0335] 012ab MOP_LIB 0 MOP_FN_CALL

[0336] become:

[0337] 012ab.0 MOP_FN_CALL

[0338] The example with 2 libraries becomes:

[0339] 012ab.0MOP_FN_CALL 567cd.0 MOP_FN_CALL 1 MOP_FN_CALL

[0340] 012ab.1 MOP_FN_CALL

[0341] When a compact transaction is spent, a canonical form of the locking script is generated, inserting the function body into the script. This enables verification of the transaction ID, and acts as a valid checksum indicating that the referenced library is correct. Omitting this step may allow scripts to be created where the referenced library is different than the expected library (e.g., they may share the same short ID, and node 104a may use the wrong short ID), resulting in unexpected behavior of the locking script. This is harmless to the Bitcoin network 106, as blocks generated using transactions with the wrong library will be rejected by all other nodes 104 (who will eventually reach consensus using the correct library), however it will result in financial losses for node 104a that published the invalid block.

[0342] The above describes Fig.13A , Fig. 13B and Fig. 13C , and examples of referencing the library, function table, and variable table are shown respectively. The variable count is assigned $0 (index 0) in the table and initialized to 0. Each time the function counter is called, $0 is incremented by 1 and $0 is updated. The user cannot modify counter directly from the locked script (the library variable table cannot be accessed), and the only allowed method is to call the function counter. The parameter of the function length is assigned $1. When length is called, the input parameter is inserted into $1 and read each time it is needed inside the function. In this respect, the function reverse is similar. In the function reverse, the variable len is declared. The variable is assigned $2, and the value in $2 is updated in the library variable table each time it is modified (using value$2MOP_SET_VAR), and the variable is retrieved from the library variable table each time it is used (using $2MOP_GET_VAR). It should be noted that len ​​is reinitialized each time reverse is called.

[0343] Fig.17A Another exemplary reference library is shown. When converting a locking script that uses an external library to canonical form, all references to the external library are replaced with the actual code of the function being called, and the meta-opcodes are expanded to the canonical versions. Fig.17A The function table corresponding to the reference library is as follows Fig. 17B It should be noted that the input count starts with $1 because the library global variable global_var uses $0.

[0344] A transaction can have the following locking scripts:

[0345] 'hello'12ab.0MOP_FN_CALL

[0346] In order to issue a transaction containing this locking script, the first step is to verify the transaction ID. Therefore, the script engine expands the metascript into its canonical form. First, it is converted into:

[0347] 12ab.$1 MOP_GET_VAR OP_SIZE OP_NIP

[0348] Then, use the variable table (such as Fig. 17C ) expand the script to:

[0349] OP_TOALTSTACK 10 7 OP_ADD OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_ADD

[0350] 8. Example Workflow

[0351] This section describes an example developer workflow using compact scripts. With the removal of the script size limit in Bitcoin SV’s Genesis upgrade, it is now possible for applications to create transactions using long and complex scripts. This poses a few problems:

[0352] 1. Developing, testing, and using complex scripts in transactions introduces complexity.

[0353] 2. Broadcasting the now much larger transactions requires additional bandwidth.

[0354] 3. Once a transaction processor or blockchain node verifies, the storage requirements of the transaction increase.

[0355] To address these issues, metascripts (an exemplary implementation of compact scripts) were introduced. Metascripts are extensions of Bitcoin scripts with additional functionality, including function calls and loops. Metascripts neither execute nor contribute to Bitcoin's consensus rules, i.e. transaction ID generation or signature hash calculations. Miner nodes compile metascripts into canonical Bitcoin scripts when executing them.

[0356] Metascripts offer the possibility for developers to build libraries of functions and distribute them to miners, which can then be used by metascript transactions. The workflow of this process is described below.

[0357] Fig.18 A brief overview of an exemplary workflow is provided. Fig.18 Two key users who interact with the system during the workflow phase are shown: library developers who are responsible for developing and publishing libraries used by transactions; and transaction developers who are responsible for discovering the published libraries and using them in their transactions.

[0358] Metascript is one of three interacting programming languages: SDL - a high-level language used to develop metascript libraries; Metascript - an extension of Bitcoin Script that enables function calls and loop constructs; and Bitcoin Script - a base language, also called a specification script when generated from a metascript. It should be noted that the specification script takes the form of a script that is hashed for the purpose of generating a transaction ID.

[0359] 8.1 Metascript Development Tools

[0360] Fig.19 An exemplary overview of tools for developing metascripts is shown. Fig.19 It shows how to use the compiler: SDL / compiler is used to generate a library function table from SDL; the metascript compiler converts the metascript in text form into a byte array form by referencing the library function table; the transaction compiler generates a specification script from the metascript (in byte array form) and the function table.

[0361] 8.2 SDL Compiler

[0362] The SDL compiler takes a function table as input and generates a function table as output. Since SDL is a language for developing libraries, SDL provides the following features: function definition; function call; immutable variable declaration; for loop; while loop; unit test framework; and library documentation generation. These features will now be described.

[0363] The function can be defined as follows:

[0364] pub fn function_name(arg1:type){

[0365] }

[0366] Both SDL and textual metascripts use a combination of library_name and function_name to indicate the library function calls they wish to make. For example, a script could contain:

[0367] use library_name;

[0368] 1 OP_DUP MOP_FNCALL library_name::function_name

[0369] It should be noted that in the case where two libraries define the same function name, the full library_name and function_name combination can be used to prevent name conflicts. The library can be imported into the script namespace:

[0370] use library_name::*;

[0371] 1 OP_DUP MOP_FNCALL function_name

[0372] Specific library functions can be imported into the script namespace:

[0373] use library_name::{function1,function2};

[0374] 1 OP_DUP MOP_FNCALL function1

[0375] Importing the script namespace will check for library function name conflicts and raise an error if a conflict occurs.

[0376] It should be noted that immutable variable declarations are based on function definitions, and when these functions are translated, function calls are replaced with values ​​on the stack, e.g.

[0377] pub const LARGEST_PRIME_UNDER_100=97;

[0378] It should be noted that if the constant is a public constant, the value is replaced with the function definition, which will be called by other libraries or scripts. When these functions are translated, the function call is replaced with the value on the stack. If the constant is a private constant (not a "public" constant), you can choose how to achieve this: put the constant in the function, just like in the public constant case (this may be more efficient if library size is a concern and the constant is large (many bytes in size)); or replace the constant used in the library.

[0379] like Fig. 20 Optionally, the SDL compiler can output unit tests as shown. These tests are executed to provide evidence that the library behaves as expected.

[0380] Fig.21 An exemplary construction of a library including a function table is shown. Each library may include one or more of the following: entity_name - the publisher of the library, which may be needed to help discover the library; library_name - the textual name of the library; library_id - a unique ID that identifies the library based on the transaction ID; library_version - the version of the library, enabling transactions to be pinned to a specific library version; dependencies - a list of libraries that the library depends on, identified using library_id; and functions - a list of function table entries (FunctionTableEntry) describing each function. It should be noted that library_id is calculated by hashing the complete library with the library_id field set to zero. FunctionTableEntry includes one or more of the following: function_name - the textual name of the library; function_signature - indicates the parameters expected by the function; Is_private - a flag indicating whether the function is a private function, see discussion below; and byte_code - a metascript function used as a byte array.

[0381] Library functions can be public or private. Public functions can be used by scripts or other libraries. Private functions are only used by the library itself.

[0382] To ensure that private functions remain private, at least two approaches can be used: 1) during parsing, private function calls are expanded to public functions (this increases the size of the published library file, but reduces the overhead incurred by the transpiled library); or 2) use an "is_private" field to indicate that a 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 incurred by the transpiled library. This also increases the risk that node implementations may ignore the flag and execute code they should not, potentially creating vulnerabilities.

[0383] As part of processing SDL, the SDL compiler may perform some of the following checks: Do all library fields exist? ; Does library_name match the generated function table name? ; Is library_id unique? ; Has that version number been used before? (reusing the same version number can cause serious problems); Are function names unique within the library? ; Is the library_index field unique? ; Are library dependencies valid and up to date? ; Does every function have a function signature?

[0384] 8.3 Metascript Compiler

[0385] The operation of the metascript compiler to create a metascript transaction is described below. As previously described, metascript is an extension of Bitcoin Script with the following additional features: for loops; while loops; and calls to (library) function definitions - including parameter substitution. It should be noted that metascript loop constructs (while loops and for loops) are limited to a defined number of iterations. The purpose of this restriction is to limit the runtime of the transaction and provide evidence that the script will complete, while ensuring that the metascript always generates the same canonical script. This ensures that the script always generates the same hash digest, and therefore the same transaction ID.

[0386] Metascript operations (MOPs) are additional operations prefixed with "MOP_", while existing Bitcoin script operations are prefixed with "OP_". Loop constructs include:

[0387] MOP_DO(limit start ---) - marks the start of the loop, getting the start and limit values ​​from the stack

[0388] MOP_DO(limit start ---) - Place the current index on the stack

[0389] ●MOP_DO(limit start---)-marks the end of the loop

[0390] MOP_IFLEAVE(condition ---) - Leaves the current (innermost) loop if the condition on the stack is True.

[0391] It should be noted that (n---)- indicates that the parameters are retrieved from the stack.

[0392] Additional functions include:

[0393] ●MOP_FNCALL<short_id> <arg1> <arg2>- Transfers control to the function identified by short_id. The function uses the stack in its current state and places the return value on the stack.

[0394] MOP_ARG <n>- This is a placeholder for the nth parameter in the function signature, which is placed in the library code and replaced with the passed value when the code is called. It should be noted that<arg1,arg2> Indicates that the parameter is placed after the action in the action list.

[0395] The metascript needs to identify the libraries it uses, to do this it uses the MOP_LOADLIB MOP code:

[0396] MOP_LOADLIB<n_libs> <lib1> <lib2>- The first parameter following the MOP_LOADLIB operation determines the number of the library to be loaded, and subsequent parameters are the library_id of the library.

[0397] Fig. 22 shows the format of a metascript during development in text form, and after it is published as a transaction as a byte array. The conversion between these two formats is performed by the metascript compiler. Fig. 22 As shown, the development metascript contains: uses - a list of libraries used by the script; and script - the source of the metascript. It should be noted that when the script references a library function, it is executed through the combination of library_name and function_name, such as Fig.21 As shown in the StringFunction structure. Fig.21 Also shown is the metascript in bytes form, which contains the source_code script as a byte array.

[0398] As mentioned in the introduction, metascripts do not contribute to Bitcoin's consensus rules, including transaction ID generation. A transaction ID is a hash of the canonical script. Therefore, to create a metascript transaction ID, the transaction must first be converted to the canonical script and that script hashed. This means that the metascript compiler must also include the functionality of a transaction compiler. It should be noted that many fields exist in metascripts that do not exist in Bitcoin scripts and therefore do not contribute to the hash. However, since verifying that a transaction is valid will generate the same hash, this is not a problem.

[0399] 8.4 Script / Transaction Compiler

[0400] Fig. 22 It is shown that node 104a receives the meta-transaction and converts it into a canonical script using the function table.At this point the parameters are substituted into the called library function.

[0401] 8.5 Library Publishing, Distribution, and Discovery

[0402] The library developer is responsible for publishing the library 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 spending a transaction associated with the library on the blockchain. New versions of the library can then be made available. There could be a central repository that lists libraries and their associated transaction IDs so that the library can be retrieved from the blockchain. This would enable nodes to quickly discover libraries on startup and pre-load libraries before receiving transactions that depend on the library.

[0403] 8.6 Node Processing Transactions

[0404] Node 104a needs to identify the script as containing a metascript. It may not be possible to check whether the script begins with MOP_LOADLIB, because the script may not load a library. Therefore, node 104a must scan the script to see if it contains any MOP_operations. Fig.24 The details of the metascript transaction compiler process are shown in In order to process a metascript transaction, a node needs access to node software capable of processing metascript transactions, the source of the metascript library, and the transaction containing the metascript.

[0405] The node will need to:

[0406] 1. Get the required libraries. It should be noted that these libraries may in turn depend on other libraries that also need to be resolved.

[0407] 2. Convert the meta script to a canonical script.

[0408] a.MOP_FNCALLS will be expanded to the called library code.

[0409] b. MOP_LOOP will be expanded to its identified limit if necessary (to ensure that the canonical form is always the same).

[0410] 3. Execute the specification script.

[0411] 4. Verify the script.

[0412] 8.7 Node Verification Transactions

[0413] It should be noted that not all nodes can understand metascripts, and therefore not all nodes can verify transactions containing metascripts. This is handled through peer messaging to ensure that only peer nodes that understand metascripts are sent metascript transactions for processing and verification. Fig.25 An exemplary verification process is shown that uses the same "transfer metascript" stage as processing a transaction.

[0414] 8.8 Node forwarding transactions

[0415] Once a transaction containing a metascript is accepted and verified as valid by a miner, it must be forwarded on the network (or at least forwarded to the peers to which the transaction is connected). The question is what form the script should take. There are two options: a) expand the metascript to a canonical form and transmit it as currently done, or b) keep it in metascript form and transmit it only to miners that have enabled metascripts. To realize the potential of the metascript concept, the second option is preferred. In this case, the processing required by the node receiving the transaction is the same as above. Fig.24 Same as shown in , except that the ability to understand the metascript is checked. During peer discovery, a node will signal whether it is able to process both the metascript and the canonical script.

[0416] 8.9 Node startup

[0417] On startup, a metascript-enabled node needs to discover libraries. As mentioned earlier, these libraries can be stored on the blockchain. The node can keep a persistent record of the libraries it has recently used. This list can be used to prioritize locally cached libraries to speed up transaction processing. To help nodes discover libraries, there may be a central repository. This central repository would list the libraries and their associated transaction IDs so that the libraries can be retrieved from the blockchain. This would enable nodes to proactively cache these libraries before receiving a transaction that utilizes the libraries.

[0418] 9. Examples

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

[0420] 9.1 Group 1 Examples:

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

[0422] Highest level language

[0423]

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

[0425]

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

[0427] $0 refers to the first input to the script that has not yet been provided, which can be the item on the top of the stack. 0 MOP_FN_CALL is the syntax for calling a function with function ID 0 in the function table. After the execution of $0 0 MOP_FN_CALL, the length of the input will remain on the top of the stack. 1 OP_SUB subtracts 1 from the value on the top of the stack and leaves the result on the top of the stack. 0 MOP_SET_VAR assigns the element on the top of the stack to the variable with index 0 in the variable table. The variable will be available for the rest of the execution. 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. 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 multiple times. After the execution of 0 MOP_GET_VAR MOP_LOOP OP_1 OP_SPLITMOP_END_BLOCK, the string will be split into one-byte substrings. Likewise, 0 MOP_GET_VAR MOP_LOOPOP_SWAP OP_CAT MOP_END_BLOCK will swap the order of the substrings and concatenate them to form a string that is the reverse of the input string.

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

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

[0430]

[0431]

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

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

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

[0435] Intermediate language (metascript)

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

[0437] 'I am fish'1 MOP_FN_CALL

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

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

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

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

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

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

[0444]

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

[0446] 9.2 Group 2 Examples:

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

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

[0449]

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

[0451] Intermediate Language (Metascript):

[0452] 8 meta_loop one_split 8 meta_loop swap_cat

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

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

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

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

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

[0458] Low-level languages ​​(Bitcoin opcodes / Native Script):

[0459]

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

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

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

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

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

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

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

[0467] High-level languages:

[0468]

[0469] 17 bytes

[0470] Intermediate Language:

[0471]

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

[0473] 13 bytes

[0474] Low-level languages:

[0475]

[0476]

[0477] 49 bytes

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

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

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

[0481] High-level languages:

[0482] var=5

[0483] return var+var

[0484] Intermediate Language:

[0485] 5 var meta_assign var var op_add

[0486] Low-level languages:

[0487] 5 OP_TOALTSTACK OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_FROMALTSTACKOP_DUP OP_TOALTSTACK OP_ADD

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

[0489] 9.3 Group 3 Examples:

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

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

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

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

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

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

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

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

[0498] OP_IFDUP OP_IF OP_TUCK OP_MOD OP_ENDIF

[0499] The algorithm can be written as

[0500]

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

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

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

[0504] Initial state of the stack:

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

[0506] ALT stack initial state: not used

[0507] ALT stack final status: unused

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

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

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

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

[0512] ALT stack initial state: not used

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

[0514] OP_TUCK OP_2DUP OP_MOD OP_DUP OP_TOALTSTACK OP_SWAP OP_TOALTSTACK OP_SUB

[0515] OP_SWAP OP_DIV

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

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

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

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

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

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

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

[0523] ALT stack initial state: not used

[0524] ALT stack final status: unused

[0525] OP_DUP 3 OP_PICK OP_MUL 5 OP_ROLL OP_SWAP OP_SUB OP_SWAP 2 OP_PICKOP_MUL 4 OP_ROLL OP_SWAP OP_SUB

[0526] The above content can be written in HL language as: HL function st(){DUP 3 PICK*5 ROLL SWAP-SWAP2 PICK*4 ROLLSWAP-}

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

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

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

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

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

[0532] ALT stack initial state: not used

[0533] ALT stack final state:…

[0534]

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

[0536]

[0537]

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

[0539] 10. Further comments

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

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

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

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

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

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

[0546] Statement 1. A computer-implemented method for transmitting a compact transaction to a node of a blockchain network, wherein the compact transaction is a blockchain transaction comprising a compact script (CS) written at least in part in an intermediate-level (IL) scripting language and comprising one or more IL functions, wherein when executed, each IL function is configured to perform operations equivalent to operations performed by one or more LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform operations equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a first party and comprises:

[0547] Generate a first compact transaction, the first compact transaction includes a first CS, wherein the first CS includes: i) a first library identifier of a first high-level (HL) reference library, the first HL reference library includes a first set of HL functions (or referred to as a first set of HL functions, a first group of HL functions) written in an HL scripting language, each HL function is configured to perform an operation equivalent to an operation performed by a corresponding set of one or more LL functions; ii) corresponding function identifiers of one or more HL functions in the first set of HL functions; and iii) at least one IL function, the at least one IL function is configured to call the one or more HL functions during script execution; and,

[0548] The first compact transaction is transmitted to at least one CS-enabled node, wherein each CS-enabled node is configured to verify the compact transaction.

[0549] Statement 2. The method of statement 1, comprising: creating the first HL reference library. Alternatively, the first HL reference library may be created by a different party.

[0550] Statement 3. The method of statement 1 or 2, comprising providing the first HL reference library to the at least one CS-enabled node.

[0551] Statement 4. The method according to statement 3, wherein providing the first HL reference library to the at least one CS-enabled node includes: sending the first HL reference library to the at least one CS-enabled node.

[0552] Statement 5. A method according to statement 3, wherein the first HL reference library is stored at a publicly accessible source, and wherein providing the first HL reference library to the at least one CS-enabled node includes: sending a reference to the publicly accessible source to the at least one CS-enabled node.

[0553] Statement 6. The method of statement 5, wherein the publicly accessible source is a library transaction stored on a blockchain, and wherein the first library identifier is: a) a transaction identifier of the library transaction; or b) a block height of a block containing the library transaction and a position of the library transaction in the block.

[0554] Statement 7. The method of statement 6, comprising:

[0555] creating the library transaction; and,

[0556] The repository transaction is transmitted to at least one blockchain node.

[0557] Statement 8. The method of statement 6, comprising: updating the library by:

[0558] creating an updated repository transaction, the updated repository transaction including the updated repository; and,

[0559] The updated repository transaction is transmitted to at least one blockchain node.

[0560] Statement 9. A method according to any of the preceding statements, wherein the first library identifier is a hash value of the first HL reference library.

[0561] Statement 10. The method of any preceding statement, wherein the compact transaction comprises a first transaction identifier, and wherein the method comprises:

[0562] generating an extended version of the first compact transaction by converting the first CS into a first ES, the conversion comprising: replacing each function identifier with a set of corresponding one or more LL functions (or referred to as a corresponding set of one or more LL functions, a corresponding group of one or more LL functions), the set of corresponding one or more LL functions being configured to perform the same operation as a corresponding HL function; and,

[0563] The first transaction identifier is generated based on the extended version of the first compact transaction.

[0564] Statement 11. The method of statement 10, comprising:

[0565] creating or loading a first HL function table for the first HL reference library, wherein the first HL function table includes i) the corresponding function identifier of each first HL function, which is mapped to ii) one or more IL functions and / or one or more LL functions to implement the corresponding HL function; and,

[0566] The converting of the first CS into the first ES includes: obtaining the corresponding set of one or more LL functions based on the mapping in the first HL function table, and the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

[0567] The function identifier may be an index corresponding to the position of the HL function in the HL reference library. The first HL reference library may include the first HL function table.

[0568] Statement 12. The method of statement 11, wherein at least one HL function uses a different HL function, and wherein the first HL function table includes the corresponding function identifiers of the different HL functions as part of the mapping.

[0569] Statement 13. A method according to any of the preceding statements, wherein the first CS includes a second library identifier of a second HL reference library, the second HL reference library includes a second HL function set (also referred to as a second group of HL functions), and wherein the first CS includes corresponding function identifiers of one or more HL functions in the second HL function set.

[0570] Statement 14. The method of statement 13 as dependent upon statement 11 or 12, the method comprising:

[0571] creating or loading a second HL function table for the second HL reference library, wherein the second HL function table includes i) the corresponding function identifier of each second HL function, which is mapped to ii) one or more IL functions and / or one or more LL functions for implementing the corresponding HL function; and,

[0572] The converting of the first CS into the first ES includes: obtaining the corresponding set of one or more LL functions based on the mapping in the first HL function table, and the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

[0573] The second HL reference library may include the second HL function table.

[0574] Statement 15. The method of statement 11 or any of its dependent statements, wherein the first HL function table includes corresponding variable identifiers of one or more first HL variables used by the corresponding HL functions as part of the mapping of the corresponding HL functions and at least one IL function, wherein the at least one IL function is configured to call the one or more first HL variables during script execution.

[0575] Statement 16. The method of statement 15, comprising:

[0576] creating or loading a first HL variable table for the first HL reference library, wherein the first HL variable table includes i) the corresponding variable identifier for each first HL variable, which maps to ii) the value of the corresponding first HL variable or a placeholder for the first HL variable; and,

[0577] The converting of the first CS into the first ES includes: using the first HL variable table to replace each corresponding variable identifier with the value of the corresponding first HL variable or the placeholder of the first HL variable.

[0578] The first HL reference library may include the first HL variable table.

[0579] Statement 17. A method according to statement 16, wherein the first HL variable includes one or more variable identifiers of corresponding global variables available to the entire first compact script, and / or wherein the first HL variable table includes one or more variable identifiers of corresponding local variables available only to the first HL function of the first HL reference library.

[0580] The first HL variable table can be divided into two independent sub-tables, one sub-table for global variables and the other sub-table for local variables.

[0581] Statement 18. The method according to statement 16 or 17, wherein the converting of the first CS to the first ES comprises: writing the corresponding value of the corresponding first HL variable into the first HL variable table.

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

[0583] Statement 20. A computer-implemented method for processing a compact transaction, wherein a compact transaction is a blockchain transaction comprising a compact script (CS) written at least in part in an intermediate-level (IL) scripting language and comprising one or more IL functions, wherein when executed, each IL function is configured to perform operations equivalent to operations performed by one or more LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform operations equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a CS-enabled node configured to verify the compact transaction, and the method comprises:

[0584] Obtaining a first compact transaction, the 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 written in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a corresponding set of one or more LL functions; ii) corresponding function identifiers of one or more HL functions in the first set of HL functions; and iii) at least one IL function, the at least one IL function being configured to call the one or more HL functions during script execution;

[0585] obtaining the first HL reference library; and,

[0586] Processing the first compact transaction, wherein the processing comprises:

[0587] An extended version of the first compact transaction is generated by converting the first CS into a first ES, the conversion comprising replacing each function identifier with a corresponding set of one or more LL functions, wherein the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

[0588] Statement 21. The method of statement 20, wherein the compact transaction includes a first transaction identifier, and wherein processing the first compact transaction includes:

[0589] generating a candidate transaction identifier based on the extended version of the first compact transaction;

[0590] determining that the candidate transaction identifier matches the first transaction identifier; and,

[0591] The first compact transaction is rejected if the candidate transaction identifier does not match the first transaction identifier.

[0592] Statement 22. The method of statement 20 or 21, wherein the first CS is a locking script, and wherein processing the first compact transaction comprises: executing the first ES together with an unlocking script of a second blockchain transaction.

[0593] Statement 23. The method of statement 20 or 21, wherein the first CS is an unlocking script, and wherein processing the first compact transaction comprises: executing the first ES together with the locking script of a third blockchain transaction.

[0594] Statement 24. The method of any one of Statements 20 to 23, wherein obtaining the first compact transaction comprises receiving the first compact transaction from a first party or other CS-enabled node.

[0595] Statement 25. The method according to statement 24, wherein the obtaining the first HL reference library includes: receiving the first HL reference library from the first party or the other CS-enabled node.

[0596] Statement 26. The method of any one of statements 20 to 25, wherein obtaining the first HL reference library comprises:

[0597] obtaining a reference to a publicly accessible source storing said first HL reference library; and,

[0598] The first HL reference library is obtained from the publicly accessible source.

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

[0600] Statement 28. The method of statement 26, comprising:

[0601] creating the storage transaction; and,

[0602] The storage transaction is transmitted to at least one blockchain node.

[0603] Statement 29. The method according to any one of statements 20 to 24, wherein obtaining the first HL reference library comprises: accessing the first HL reference library from a memory.

[0604] Statement 30. The method of any one of statements 21 to 30, wherein the first library identifier of the first HL reference library is a hash of the first HL reference library, and wherein obtaining the first HL reference library is based on the hash.

[0605] Statement 31. The method of any one of statements 20 to 29, comprising:

[0606] creating or loading a first HL function table for the first HL reference library, wherein the first HL function table comprises i) the corresponding function identifier of each first HL function, which is mapped to ii) one or more IL functions and / or one or more LL functions for implementing the corresponding HL function; and,

[0607] The converting of the first CS into the first ES includes: obtaining the corresponding set of one or more LL functions based on the mapping in the first HL function table, and the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

[0608] The function identifier may be an index corresponding to the location of the HL function in the HL reference library.

[0609] Statement 32. The method of statement 31, wherein at least one HL function uses a different HL function, and wherein the first HL function table includes the corresponding function identifiers of the different HL functions as part of the mapping.

[0610] Statement 33. A method according to statement 32, wherein the first CS includes a second library identifier of a second HL reference library, the second HL reference library includes a second HL function set, wherein the first CS includes corresponding function identifiers of one or more HL functions in the second HL function set, and wherein the method includes: obtaining the second HL reference library.

[0611] Statement 34. The method of statement 33 as dependent upon statement 31 or 32, the method comprising:

[0612] creating or loading a second HL function table for the second HL reference library, wherein the second HL function table includes i) the corresponding function identifier of each second HL function, which is mapped to ii) one or more IL functions and / or one or more LL functions for implementing the corresponding HL function; and,

[0613] The converting of the first CS into the first ES includes: obtaining the corresponding set of one or more LL functions based on the mapping in the first HL function table, and the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

[0614] Statement 35. A method according to statement 31 or any of its subordinate statements, wherein the first HL function table includes corresponding variable identifiers of one or more first HL variables used by the corresponding HL functions as part of the mapping of the corresponding HL functions and at least one IL function, wherein the at least one IL function is configured to call the one or more first HL variables during script execution.

[0615] Statement 36. The method of statement 35, comprising:

[0616] creating or loading a first HL variable table for the first HL reference library, wherein the first HL variable table includes i) the corresponding variable identifier for each first HL variable, which maps to ii) the value of the corresponding first HL variable or a placeholder for the first HL variable; and,

[0617] The converting of the first CS into the first ES includes: using the first HL variable table to replace each corresponding variable identifier with the value of the corresponding first HL variable or the placeholder of the first HL variable.

[0618] Statement 37. A method according to statement 36, wherein the first HL variable includes one or more variable identifiers of corresponding global variables available to the entire first compact script, and / or wherein the first HL variable table includes one or more variable identifiers of corresponding local variables available only to the first HL function of the first HL reference library.

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

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

[0621] Statement 40. A computer device, the computer device comprising:

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

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

[0624] Statement 41. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 39. < / lib1> < / n> < / arg1> < / cls> < / els> < / pa>

Claims

1. A computer-implemented method for transmitting a compact transaction to a node of a blockchain network, wherein a compact transaction is a blockchain transaction comprising a compact script (CS) written at least in part in an intermediate-level (IL) scripting language and comprising one or more IL functions, wherein when executed, each IL function is configured to perform operations equivalent to operations performed by one or more LL functions of a low-level (LL) scripting language, wherein the CS is configured to perform operations equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a first party and comprises: generating a first compact transaction, the 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 written in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a corresponding set of one or more LL functions; ii) corresponding function identifiers of one or more HL functions in the first set of HL functions; and iii) at least one IL function, the at least one IL function being configured to call the one or more HL functions during script execution; and The first compact transaction is transmitted to at least one CS-enabled node, wherein each CS-enabled node is configured to verify the compact transaction.

2. The method according to claim 1, comprising: Create the first HL reference library.

3. The method according to claim 1 or 2, comprising: The first HL reference library is provided to the at least one CS-enabled node.

4. The method of claim 3, wherein providing the first HL reference library to the at least one CS-enabled node comprises: The first HL reference library is sent to the at least one CS-enabled node.

5. The method of claim 3, wherein the first HL reference library is stored at a publicly accessible source, and wherein providing the first HL reference library to the at least one CS-enabled node comprises: A reference to the publicly accessible source is sent to the at least one CS-enabled node.

6. The method of claim 5, wherein the publicly accessible source is a repository transaction stored on a blockchain, and wherein the first repository identifier is: a) a transaction identifier of the repository transaction; or b) a block height of a block containing the repository transaction and a position of the repository transaction in the block.

7. The method according to claim 6, comprising: Creating the library transaction; as well as The repository transaction is transmitted to at least one blockchain node.

8. The method according to claim 6, comprising: Update said library by: creating an updated repository transaction, the updated repository transaction including the updated repository; as well as The updated repository transaction is transmitted to at least one blockchain node.

9. A method according to any preceding claim, wherein the first library identifier is a hash value of the first HL reference library.

10. A method according to any preceding claim, wherein the compact transaction comprises a first transaction identifier, and wherein the method comprises: generating an extended version of the first compact transaction by converting the first CS into a first ES, the converting comprising: replacing each function identifier with a set of corresponding one or more LL functions, the set of corresponding one or more LL functions being configured to perform the same operation as a corresponding HL function; and The first transaction identifier is generated based on the extended version of the first compact transaction.

11. The method according to claim 10, comprising: creating or loading a first HL function table for the first HL reference library, wherein the first HL function table comprises i) the corresponding function identifier of each first HL function, which is mapped to ii) one or more IL functions and / or one or more LL functions for implementing the corresponding HL function; and The converting of the first CS into the first ES includes: obtaining the corresponding set of one or more LL functions based on the mapping in the first HL function table, and the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

12. The method of claim 11, wherein at least one HL function uses a different HL function, and wherein the first HL function table includes the corresponding function identifiers of the different HL functions as part of the mapping.

13. A method according to any of the preceding claims, wherein the first CS includes a second library identifier of a second HL reference library, the second HL reference library includes a second HL function set, and wherein the first CS includes corresponding function identifiers of one or more HL functions in the second HL function set.

14. A method according to claim 13 as appended to claim 11 or 12, comprising: creating or loading a second HL function table for the second HL reference library, wherein the second HL function table comprises i) the corresponding function identifier of each second HL function, which is mapped to ii) one or more IL functions and / or one or more LL functions for implementing the corresponding HL function; and The converting of the first CS into the first ES includes: obtaining the corresponding set of one or more LL functions based on the mapping in the first HL function table, and the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

15. A method according to claim 11 or any dependent claim thereof, wherein the first HL function table includes corresponding variable identifiers of one or more first HL variables used by the corresponding HL function as part of the mapping of the corresponding HL function and at least one IL function, wherein the at least one IL function is configured to call the one or more first HL variables during script execution.

16. The method according to claim 15, comprising: creating or loading a first HL variable table for the first HL reference library, wherein the first HL variable table includes i) the corresponding variable identifier for each first HL variable, which maps to ii) a value of the corresponding first HL variable or a placeholder for the first HL variable; and The converting of the first CS into the first ES includes: using the first HL variable table to replace each corresponding variable identifier with the value of the corresponding first HL variable or the placeholder of the first HL variable.

17. A method according to claim 16, wherein the first HL variable includes one or more variable identifiers of corresponding global variables available for use by the entire first compact script, and / or wherein the first HL variable table includes one or more variable identifiers of corresponding local variables available only to the first HL function 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: The corresponding values ​​of the corresponding first HL variables are written into the first HL variable table.

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

20. A computer-implemented method for processing a compact transaction, wherein a compact transaction is a blockchain transaction comprising a compact script (CS) written at least in part in an intermediate-level (IL) scripting language and comprising one or more IL functions, wherein when executed, each IL function is configured to perform operations equivalent to operations performed by one or more low-level (LL) scripting language functions, wherein the CS is configured to perform operations equivalent to an extended script (ES) written in the LL scripting language, and wherein the method is performed by a CS-enabled node configured to verify the compact transaction, and the method comprises: Obtaining a first compact transaction, the 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 written in an HL scripting language, each HL function being configured to perform an operation equivalent to an operation performed by a corresponding set of one or more LL functions; ii) corresponding function identifiers of one or more HL functions in the first set of HL functions; and iii) at least one IL function, the at least one IL function being configured to call the one or more HL functions during script execution; obtaining the first HL reference library; and Processing the first compact transaction, wherein the processing comprises: An extended version of the first compact transaction is generated by converting the first CS into a first ES, the conversion comprising replacing each function identifier with a corresponding set of one or more LL functions, wherein the corresponding set of one or more LL functions is configured to perform the same operation as the corresponding HL function.

21. The method of claim 20, wherein the compact transaction comprises a first transaction identifier, and wherein processing the first compact transaction comprises: generating a candidate transaction identifier based on the extended version of the first compact transaction; determining that the candidate transaction identifier matches the first transaction identifier; as well as The first compact transaction is rejected if the candidate transaction identifier does not match the first transaction identifier.

22. The method of claim 20 or 21, wherein the first CS is a locking script, and wherein processing the first compact transaction comprises: The first ES is executed together with the unlocking script of the second blockchain transaction.

23. The method of claim 20 or 21, wherein the first CS is an unlocking script, and wherein processing the first compact transaction comprises: The first ES is executed together with the locking script of the third blockchain transaction.

24. The method according to any one of claims 20 to 23, wherein obtaining the first compact transaction comprises: The first compact transaction is received from a first party or other CS-enabled node.

25. The method according to claim 24, wherein the obtaining the first HL reference library comprises: The first HL reference library is received from the first party or the other CS-enabled node.

26. The method according to any one of claims 20 to 25, wherein obtaining the first HL reference library comprises: obtaining a reference to a publicly accessible source storing the first HL reference library; as well as The first HL reference library is obtained from the publicly accessible source.

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

28. The method according to claim 26, comprising: Creating the storage transaction; as well as The storage transaction is transmitted to at least one blockchain node.

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

30. The method of 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 wherein obtaining the first HL reference library is based on the hash.

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

32. The method of claim 31, wherein at least one HL function uses a different HL function, and wherein the first HL function table includes the corresponding function identifiers of the different HL functions as part of the mapping.

33. The method of claim 32, wherein the first CS comprises a second library identifier of a second HL reference library, the second HL reference library comprising a second set of HL functions, wherein the first CS comprises respective function identifiers of one or more HL functions in the second set of HL functions, and wherein the method comprises: Obtain the second HL reference library.

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

35. A method according to claim 31 or any dependent claim thereof, wherein the first HL function table includes corresponding variable identifiers of one or more first HL variables used by the corresponding HL function as part of the mapping of the corresponding HL function and at least one IL function, wherein the at least one IL function is configured to call the one or more first HL variables during script execution.

36. The method of claim 35, comprising: creating or loading a first HL variable table for the first HL reference library, wherein the first HL variable table includes i) the corresponding variable identifier for each first HL variable, which maps to ii) a value of the corresponding first HL variable or a placeholder for the first HL variable; and The converting of the first CS into the first ES includes: using the first HL variable table to replace each corresponding variable identifier with the value of the corresponding first HL variable or the placeholder of the first HL variable.

37. A method according to claim 36, wherein the first HL variable includes one or more variable identifiers of corresponding global variables available for use by the entire first compact script, and / or wherein the first HL variable table includes one or more variable identifiers of corresponding local variables available only to the first HL function 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: The corresponding values ​​of the corresponding first HL variables are written into the first HL variable table.

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

40. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to perform the method according to any preceding claim when executed on the processing device.

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

Images