Generation and verification of blockchain transactions

Abstract

1. A computer-implemented method for generating a blockchain transaction, the method comprising: generating a first blockchain transaction, the first blockchain transaction being executed by a first party; the first blockchain transaction comprising a first compact script (CS), the first CS being written at least in part in a high-level (HL) scripting language and comprising one or more HL functions, wherein, when executed, each HL function is configured to perform operations equivalent to respective operations performed by one or more LL functions in a low-level (LL) scripting language; the first CS being configured to perform operations equivalent to a first deployment script (ES) written in the LL scripting language and comprising a plurality of LL functions, the first CS having a smaller storage size than the first ES; and making the first blockchain transaction available to one or more nodes of a blockchain network and / or a second party.

Description

[Technical Field]

[0001] This disclosure relates to a method for generating blockchain transactions and a method for verifying blockchain transactions. [Background technology]

[0002] Blockchain refers to a form of distributed data structure where duplicate copies of the blockchain are maintained on each of several nodes within a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"), and are widely publicized. A blockchain consists of a chain of blocks of data, and each block contains one or more transactions. Each transaction, other than so-called "coinbase transactions," refers to a sequence of preceding transactions that may span one or more blocks and lead back to one or more coinbase transactions. Coinbase transactions will be explained further below. Transactions submitted to the blockchain network are included in a new block. New blocks are often created by a process called "mining," which involves multiple nodes competing to perform "proof-of-work," that is, solving a cryptographic puzzle based on a defined representation of an ordered and verified pending set of transactions waiting to be included in a new block of the blockchain. Note that a blockchain can be removed from some nodes, and the publication of a block can be achieved simply by publishing the block header.

[0003] Transactions within a blockchain can be used for one or more of the following purposes: to transmit digital assets (i.e., a large number of digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. Blockchains can also be used to overlay additional functionality on top of them. For example, a blockchain protocol may be able to store additional user data or indices of data within transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly complex data can be incorporated. For example, this could be used to store electronic documents on a blockchain, or to store audio or video data.

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

[0005] Nodes that solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction called a "coinbase transaction," which distributes a certain amount of digital assets, i.e., a large number of tokens. The detection and rejection of invalid transactions is enforced by the actions of competing nodes, which act as agents of the network and are prompted to report and block fraudulent activity. Because information is widely publicized, users can continuously audit the performance of nodes. By simply publishing block headers, participants can ensure the continued integrity of the blockchain.

[0006] In the "output-based" model (also called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Available outputs comprise elements that specify the amount of digital assets derived from the transaction's progression sequence. Available outputs are sometimes called UTXOs ("unspent transaction output"). Outputs may further comprise lock scripts that specify the conditions for redeeming future outputs. A lock script is a predicate that defines the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction, and may further comprise an unlock script to unlock the lock script of the indicated output. Thus, given a pair of transactions, we refer to them as the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital assets and a lock script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input containing a pointer to the output of the first transaction, and a lock release script for releasing the lock on the output of the first transaction.

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

[0008] Blockchains typically use a scripting language to set locking conditions that lock specific outputs of a transaction. Similarly, corresponding unlocking conditions are written in the same scripting language. A scripting language usually consists of data (e.g., public keys and digital signatures) and functions that operate on that data. This scripting language is sometimes called a low-level scripting language or native scripting language. As a specific example, the native scripting language of the Bitcoin blockchain is known as Script. In Script, functions are known as "opcodes," which is short for "operation code."

[0009] Transactions, including scripts, are sent between the originator (e.g., a user or machine) and a node in the network for transaction verification. Depending on the use case, transactions can also be sent off-chain, for example, from user to user or from machine to machine. Furthermore, transactions are propagated throughout the blockchain network by the nodes themselves. Additionally, at least some nodes need to (or choose 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 needed to send and store transactions, respectively. This is generally true for all blockchains. Some blockchains have limits on the size of transactions, the size of scripts within transactions, and the size of blocks. In contrast, at least one blockchain (for example, Bitcoin SV) has no limits on the size of transaction scripts and no limits on the size of blocks. This allows for the construction of complex lock scripts (such as smart contracts) that can be quite large. This also allows blockchain nodes to construct and publish large blocks that need to be stored. Therefore, the need to conserve bandwidth and storage becomes even greater when sending and storing transactions as part of this particular blockchain. [Means for solving the problem]

[0011] According to one aspect disclosed herein, a computer implementation method for generating a blockchain transaction is provided, which is performed by a first party and generates a first blockchain transaction, the first blockchain transaction comprising: a first compact script (CS) wherein the first CS is at least partially written in a high-level (HL) scripting language and comprises one or more HL functions, wherein when executed, each HL function is configured to perform an operation equivalent to that performed by one or more LL functions of a low-level (LL) scripting language; the first CS is written in an LL scripting language and is configured to perform an operation equivalent to that of a first expansion script (ES) comprising a plurality of LL functions, wherein the first CS has a smaller storage size than the first ES; and the first blockchain transaction is made available to one or more nodes of a blockchain network and / or a second party.

[0012] In another aspect disclosed herein, a computer implementation method for verifying blockchain transactions is provided, which is executed by a node of a blockchain network, wherein the node is configured to execute a script written in a high-level (HL) scripting language, wherein the blockchain comprises a first blockchain transaction, the first blockchain transaction comprises a first output comprising a first compact lock script (CLS), the first CLS is at least partially written in an HL scripting language and comprises one or more HL functions, which, when executed, each HL function is configured to perform an operation equivalent to the operation performed by one or more LL functions of a low-level (LL) scripting language, the first CLS is configured to perform an operation equivalent to a first unfolding lock script (ELS) written in an LL scripting language and comprising multiple LL functions, and the first CLS However, the storage size is smaller than that of the first ELS, and the method is executed by a blockchain node and comprises the steps of obtaining a second blockchain transaction, wherein the second blockchain transaction comprises a first input comprising a first unlock script, and verifying the second blockchain transaction, wherein the step of verifying the second blockchain transaction comprises the step of obtaining the first blockchain transaction, a) a step of replacing the first CLS with the first ELS, and then executing the first unlock script together with the first ELS, wherein the condition for the second transaction to be valid is that the execution is successful, or b) a step of executing the first unlock script together with the first CLS, wherein the condition for the second transaction to be valid is that the execution is successful.

[0013] Another aspect disclosed herein provides a computer implementation method for verifying blockchain transactions, the method being executed by a node in a blockchain network, the node being configured to execute a script written in a high-level (HL) scripting language, the method being executed by a blockchain node, the steps of obtaining a first blockchain transaction, the first blockchain transaction comprising an input that references the input of a previous blockchain transaction, the first blockchain transaction comprising a first compact script (CS), the first CS being written in an HL scripting language and comprising one or more HL functions, and when executed, each HL function being configured to perform an operation equivalent to the operation performed by one or more LL functions of a low-level (LL) scripting language, the first CS being written in an LL scripting language and comprising a plurality of LL functions The system is configured to perform operations equivalent to an Deployment Script (ES), comprising the steps of: a first CS having a smaller storage size than a first ES; obtaining a first candidate transaction identifier as part of the verification of a second blockchain transaction; generating a modified version of the first blockchain transaction, wherein this modified version of the first blockchain transaction includes a first ES instead of a first CS; generating a first transaction identifier, wherein the first transaction identifier is generated based on the modified version of the first blockchain transaction; and comparing a first candidate transaction identifier with a first transaction identifier, wherein the condition for a first blockchain transaction to be valid is that the first candidate transaction identifier matches the first transaction identifier.

[0014] Another aspect disclosed herein provides a computer implementation method for verifying blockchain transactions, the method being executed by a node in a blockchain network, the node being configured to execute a script written in a high-level (HL) scripting language, the blockchain comprising a first blockchain transaction, the first blockchain transaction comprising a first output, the method obtaining a second blockchain transaction, the second blockchain transaction comprising a first input comprising a first compact unlock script (CUS), the first CUS being written at least partially in an HL scripting language and comprising one or more HL functions, each HL function, when executed, performs the same operation as one or more LL functions in a low-level (LL) scripting language. The first CUS is configured to perform operations such as the first CUS being written in an LL scripting language and comprising several LL functions, and the first CUS having a smaller storage size than the first EUS, and the first CUS is configured to perform operations equivalent to the first Expandable Unlockable Script (EUS), and the first CUS is configured to perform operations equivalent to the first Expandable Unlockable Script (EUS) being written in an LL scripting language and comprising several LL functions, and the first CUS having a smaller storage size than the first EUS, and the first CUS is configured to perform operations equivalent to the first Expandable Unlockable Script (EUS), and the first CUS having a smaller storage size than the first EUS, and the first CUS is configured to perform operations equivalent to the first Expandable Unlockable Script (EUS), and the first CUS having a smaller storage size than the first EUS, and the first CUS is configured to perform operations such as the first CUS being written in an LL scripting language and comprising several LL functions, has a smaller storage size than the first EUS, and the first CUS is configured to perform operations equivalent to the first Expandable Unlockable Script (EUS), and the first CUS has a smaller storage size than the first EUS, and the first CUS is configured to perform operations such as the first CUS being written in an LL scripting language and comprising several LL functions, and the first CUS has a smaller storage size than the first EUS, and the first CUS is configured to perform operations equivalent to the first CUS being written in an LL scripting language and comprising several LL functions, and the first CUS has a smaller storage size than the first EUS, and the first CUS is configured to perform operations equivalent to the first CUS being written in an LL scripting language and

[0015] Previously, lock and unlock scripts were written in low-level, or native, scripting languages. Transactions containing these scripts were sent to the blockchain network and, if valid, stored on the blockchain. Now, instead of writing scripts (lock or unlock) in low-level scripting languages, scripts can be written in high-level scripting languages. Like low-level languages, high-level languages ​​contain data and functions. However, at least some of these "high-level functions" are configured to perform the same action as multiple "low-level functions" when executed together. In other words, one high-level function may perform the same action that would normally require multiple low-level functions. As a result, scripts written in high-level languages ​​are more compact (i.e., smaller in size) than their equivalent lock scripts written in low-level languages.

[0016] Scripts written in high-level languages ​​are called "compact scripts" because they are more compact than scripts written in native low-level languages, while native low-level languages ​​are now called "expanded scripts." For example, lock scripts and unlock scripts written in high-level languages ​​are called "compact locking scripts" and "compact unlocking scripts," respectively.

[0017] Complex lock or unlock conditions, which would normally require large deployment scripts (large in the sense of many low-level functions), can now be written as smaller, more compact scripts using high-level languages. Consequently, the bandwidth and storage requirements of transactions containing compact scripts are lower than those of transactions containing deployment scripts.

[0018] Let's take the Bitcoin SV blockchain as a specific example. Because there is no limit to block size, a single block can contain billions of transactions. Because there is no limit to transaction size, each transaction can contain millions of low-level functions (i.e., opcodes). If the size of each opcode is a few bytes, each of those transactions will be around several megabytes. As a result, bandwidth issues arise both when sending transactions to the blockchain network and when propagating transactions and blocks on the network. Nodes also face storage burdens 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 were written using a high-level language, the size of the transaction would be around a few hundred bytes, thus saving significant bandwidth and storage. This is also important as blockchain technology continues to expand.

[0019] Native blockchain scripts can be thought of as assembly language. For example, a scripting language has approximately 100 opcodes. Writing programs in assembly language is a laborious task for developers, and the resulting code is often long and difficult to understand. High-level languages ​​are commonly used by developers in other technical fields due to their compactness and readability. The resulting code is then translated into assembly language that a computer can read. This application recognizes that the same technique can be used for blockchain scripts by utilizing a high-level scripting language. This high-level language may include some or all of the low-level functions of a native scripting language and new high-level functions, or it may include only high-level functions completely independent of such functions.

[0020] As explained below, transactions using large scripts can now be propagated and stored in a more compact form. Furthermore, when executing blockchain scripts, nodes can choose the most efficient implementation to execute, achieving the same result as the corresponding low-level functions, such as a list of opcodes. Most importantly, this is achieved without changing the native blockchain protocol.

[0021] In some cases, a one-to-one mapping may exist between a single high-level function and a single high-level function (LL). In this case, the size of the HL function is smaller than that of the corresponding LL function, thus saving bandwidth and storage.

[0022] In some embodiments, the HL language may be an intermediate-level language between a higher-level language (i.e., a second-tier high-level language) and the LL language. This higher-level language is a user-facing language, i.e., a language in which the user writes scripts. The user (or other type of party or entity) may generate scripts in the user-facing language, which are then converted (e.g., compiled) into the intermediate language. The intermediate language is still a high-level language compared to the LL language. The user-facing language may be a human-readable language, making it user-friendly and allowing users to more easily write scripts equivalent to complex scripts in the LL language. The user-facing language, intermediate-level language, and low-level language can be made analogous using Java source code (user-facing), Java bytecode (intermediate), and machine-readable code (low-level). Java source code is compiled into Java bytecode, which is then expanded into machine-readable code. Similarly, the user-facing language may be compiled into an intermediate-level language, which can then be expanded into a low-level language.

[0023] Depending on the implementation, the highest-level language (or a script written in the highest-level language, which is the user-facing language) may be more compact than a script written in an intermediate-level language. The advantage of introducing an intermediate-level language is the reduction in computational complexity when expanding to a lower-level language. In other words, instead of directly expanding the highest level to a lower level, blockchain nodes only need to expand from the intermediate-level language to the lower-level language. This reduction in computational complexity further reduces the burden on blockchain nodes.

[0024] The embodiments primarily describe lock scripts that are translated from a high-level language to a low-level language, but the same teachings generally apply to unlock scripts.

[0025] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments are carried out, the accompanying drawings are referenced merely as examples. [Brief explanation of the drawing]

[0026] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates some examples of transactions that can be recorded on a blockchain. [Figure 3A] This is a schematic block diagram of the client application. [Figure 3B] Figure 3A shows a schematic mockup of an exemplary user interface that may be presented by the client application. [Figure 4] This is a schematic block diagram of several node software programs for processing transactions. [Figure 5] This is a schematic block diagram of an exemplary system for sending blockchain transactions. [Figure 6] This flowchart shows an exemplary embodiment of the present invention. [Figure 7] A flowchart shows another exemplary embodiment of the present invention. [Figure 8] This figure schematically illustrates the generation and verification of transactions according to several embodiments of the present invention. [Figure 9] This diagram schematically illustrates an example hierarchy of a scripting language. [Modes for carrying out the invention]

[0027] Overview of the Exemplary System Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, a wide-area internet, typically the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that can 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.

[0028] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with a processing unit comprising one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units using one or more memory media, for example, magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0029] Blockchain 150 comprises a chain of data blocks 151, with each copy of blockchain 150 maintained on each of the multiple blockchain nodes 104 within the distributed blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean completely memorizing blockchain 150. Instead, data can be removed from blockchain 150 as long as each blockchain node 150 remembers the block header (described below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing the quantity of a digital asset as an asset, an example of which is a user 103 whose output is cryptographically locked (requiring the user's signature or other solution to unlock and thereby redeem or use it). Each input points to the output of the preceding transaction 152, thereby linking the transactions.

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

[0031] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool.” This term is not intended to be limited to any particular blockchain, protocol, or model as used herein. It refers to an ordered set of transactions that a node 104 accepts as valid and to which it is obligated not to accept any other transaction that attempts to use the same output.

[0032] In a given current transaction 152j, each input (or each input) contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "spent" in the current transaction 152j. Generally, a preceding transaction can be any transaction or any block 151 in the ordered set 154. A preceding transaction 152i must exist and be validated for the current transaction to be valid, but it does not necessarily have to exist at the time the current transaction 152j is created or even sent to the network 106. Thus, "preceding" as used herein refers to a predecessor in a logical sequence linked by a pointer, and not necessarily to a time of creation or transmission in chronological order, and therefore does not necessarily exclude the possibility that transactions 152i and 152j may be created or sent out of order (see the following explanation of orphan transactions). The preceding transaction 152i can be referred to in the same way as an antecedent transaction or predecessor transaction.

[0033] The input to the current transaction 152j also has input privileges, for example, the signature of user 103a, whose output of the preceding transaction 152i is locked. Then, the output of the current transaction 152j may be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b, as defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs for dividing the input amount among multiple users or entities (one of which may be the original user or entity 103a to give the remainder (change)). In some cases, the transaction may also have multiple inputs for aggregating amounts from multiple outputs of one or more preceding transactions and redistributing them to one or more outputs of the current transaction.

[0034] According to output-based transaction protocols like Bitcoin, if a party 103, such as an individual user or organization, wants to compose a new transaction 152j (either manually or through an automated process adopted by the party), the composer sends the new transaction from their computer terminal 102 to the recipient. The composer or recipient will ultimately send this transaction to one or more blockchain nodes 104 on the network 106 (typically servers or data centers today, but in principle, other user terminals). It is also possible that the party 103 composing the new transaction 152j might send the transaction directly to one or more of the blockchain nodes 104, and possibly not send it to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i within the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i to which the new transaction assigns, the condition typically includes checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding 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 preceding transaction 152i, or it may be simply fixed by the blockchain node protocol alone, or by a combination of these.In any case, if the new transaction 152j is valid, 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 further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

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

[0036] In addition to verifying transactions, blockchain node 104 also competes to be the first to create a block of transactions in a process commonly known as mining, supported by "proof of work." At blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded on blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transaction 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that the output of the hash satisfies a predetermined condition when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed. For example, the predetermined condition may be that the output of the hash has a predetermined number of leading zeros. It should be noted that this is just one particular type of proof of work puzzle, and does not exclude other types. A characteristic of hash functions is that they have an unpredictable output for their input. Therefore, this search can only be performed by brute force, and thus consumes a considerable amount of processing resources on each blockchain node 104 attempting to solve the puzzle.

[0037] The blockchain node 104 that first solves the puzzle publishes it to the network 106, providing the solution as a proof that can be easily checked by other blockchain nodes 104 in the network. (Given a solution for a hash, it is easy to check whether the output of the hash satisfies the conditions.) The first blockchain node 104 propagates the block until a threshold consensus is reached among the other nodes that accept the block and enforce the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in blockchain 150. The block pointer 155 is also assigned to a new block 151n that points to a previously created block 151n-1 in the chain. The considerable amount of effort required to create a proof-of-work solution, for example in the form of a hash, signals the first node 104's intention to adhere to the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it is assigned the same output as a previously verified transaction, which is also called double spending. Block 151, once created, cannot be modified because it is recognized and maintained at each of the blockchain nodes 104 within the blockchain network 106. Furthermore, the block pointer 155 imposes a sequential order on block 151. Since transaction 152 is recorded in the ordered blocks of each blockchain node 104 within the network 106, this provides an immutable public ledger of transactions.

[0038] It should be noted that different blockchain nodes 104, constantly competing to solve the puzzle, may always be operating based on different snapshots of the pool of unpublished transactions 154, depending on when they began searching for the solution or the order in which the transactions were received. Whoever solves each puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to create a block from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any "forks" that may occur, which are when two blockchain nodes 104 solve the puzzle to each other in a very short time, so that conflicting views of the blockchain propagate between the nodes 104. In other words, the branch of the longest-growing fork becomes the final blockchain 150. It should be noted that this should not affect users or agents of the network, as the same transactions will appear in both forks.

[0039] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 (as opposed to inter-agent or inter-user transactions that transfer a certain amount of digital assets from one agent or user to another) is granted the ability to newly allocate an additional amount of digital assets in a new special type of transaction that distributes an additional predetermined amount of digital assets. This special type of transaction is usually called a "coinbase transaction," but is sometimes called an "initiating transaction" or "generating transaction." This usually forms the first transaction of the new block 151n. Proof of work notifies the node constructing the new block of its intention to follow protocol rules and allows this special transaction to be redeemed later. Blockchain protocol rules may require a maturity period, such as 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created block 151n in which the transaction was published. This fee is usually called a "transaction fee" and will be explained later.

[0040] Due to the resources involved in transaction verification and publication, each of the blockchain nodes 104 typically takes the form of a server comprising one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 can take the form of a networked set of user terminals or a group of user terminals.

[0041] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role in accordance with the blockchain node protocol and to process transaction 152. It will be understood herein that any action originating from a blockchain node 104 may be carried out by software running on the processing unit of the respective computer device. Node software may be implemented in one or more applications at lower layers such as the application layer, operating system layer, or protocol layer, or any combination thereof.

[0042] Network 101 is also connected to the computer equipment 102 of several parties 103, each acting as a consumer user. These users can interact with the blockchain network 106, but do not participate in transaction verification or block construction. Some of these users or agents 103 may function as senders and receivers in transactions. Other users may interact with blockchain 150 without necessarily acting as senders or receivers. For example, some parties may function as storage entities that store copies of blockchain 150 (e.g., they obtain a copy of the blockchain from blockchain node 104).

[0043] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the necessary roles for blockchain nodes. Instead, each party 103 can utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. Much more such parties 103 and their respective 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 purely illustrative purposes, this specification refers to the first party 103a as Alice and the second party 103b as Bob, but it should be understood that any reference to Alice or Bob in this specification may be replaced with "first party" and "second party," respectively.

[0044] Each computer device 102 of party 103 comprises one or more processors, for example, processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of party 103 further comprises memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. This memory may comprise one or more memory units using one or more memory media, for example, magnetic media such as hard disks, SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each computer device 102 of party 103 stores software comprising each instance of at least one client application 105 configured to run on the processing unit. It will be understood herein that any action originating from a given party 103 may be performed using software running on the processing unit of each computer device 102. Each computer device 102 of party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

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

[0047] Note: Various client functions may be described as being integrated into a given client application 105, but this is not necessarily limited. Instead, any client function described herein may instead be implemented in a suite of two or more separate applications, for example, by interface via an API or by one being a plug-in to the other. More generally, client functions can be implemented in the application layer, or in a lower layer such as an operating system, or any combination thereof. The following description will be based on client application 105, but it will be understood that this is not limited thereto.

[0048] Each computer device 102 instance of a client application or software 105 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact blockchain node 104 to query blockchain 150 for transactions in which each party 103 is the recipient (or, in embodiments, actually inspect the transactions of other parties within blockchain 150, as blockchain 150 is a public facility that provides credibility in transactions, partly through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 is configured to run software configured to verify transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate it throughout the blockchain network 106. The transaction protocol and node protocol correspond to each other, and a given transaction protocol proceeds with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all 152 transactions within blockchain 150. The same node protocol is used by all 104 nodes within network 106.

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

[0050] Subject to the test that a newly received transaction 152j passes to be considered valid (i.e., is "validated"), any blockchain node 104 receiving transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Furthermore, any blockchain node 104 receiving transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, assuming transaction 152j is valid, this means it will immediately propagate throughout the network 106.

[0051] Once a blockchain node 104 is allowed to join an ordered pool of pending transactions 154 maintained at that node, it begins competing to solve a proof-of-work puzzle on the latest version of each pool 154 containing the new transaction 152. (It should be noted that other blockchain nodes 104 may be attempting to solve the puzzle based on different transaction pools 154, but whoever reaches it first will likely define the set of transactions included in the latest block 151. Ultimately, blockchain node 104 will solve the puzzle on the portion of the ordered pool 154 containing Alice's transaction 152j). Once proof-of-work is performed on the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. The order of the transactions is also immutably recorded, as each transaction 152 has a pointer back to the previous transaction.

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

[0053] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol, as part of an account-based transaction model. In an account-based protocol, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute account balance. The current state of all accounts is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction aggregate (also called "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, any data field in a transaction can also be signed. For example, this data field could point to a previous transaction if the previous transaction ID is included in the data field.

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

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

[0056] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". This takes the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are simply arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, or that Tx1 is the next transaction in pool 154. Tx1 could refer to a preceding (i.e., earlier) transaction that still has the unused output 203 locked in Alice.

[0057] A preceding transaction Tx0 may have already been validated and be included in block 151 of blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice sends it to network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in ordered set 154, in which case it will immediately be included in the new block 151. Alternatively, Tx0 and Tx1 could be created and sent together to network 106, and if the node protocol allows buffering of "orphan (Tx0)" transactions, Tx0 could even be sent after Tx1. The terms "preceding" and "subsequent" as used herein in the context of transaction sequences refer to the order of transactions in a sequence defined by transaction pointers specified within the transactions (such as which transaction points to which other transactions). These can also be replaced with equivalent terms such as “predecessor” and “successor,” or “antecedent” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (later transaction, or “child”) pointing to a preceding transaction (first transaction, or “parent”) will not be validated until the parent transaction is validated, and will not be validated until the parent transaction is validated. A child that arrives at blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a certain amount of time to wait for its parent.

[0058] One of one or more outputs 203 of a preceding transaction Tx0 comprises a specific UTXO, which is labeled herein as UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script, the lock script defining the conditions that the unlock script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the lock script locks that amount to a specific party (the beneficiary of the transaction in which it is contained). That is, the lock script typically defines an unlock condition, which includes the condition that the unlock script in the input of the subsequent transaction contains the cryptographic signature of the party to which the preceding transaction is locked.

[0059] A lock script (commonly 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 “Script” (uppercase S), used by blockchain networks. The lock script specifies what information is needed to use transaction output 203, for example, the requirement for Alice's signature. The unlock script appears in the transaction output. The unlock script (commonly known as scriptSig) is a piece of code written in a domain-specific language that provides the information necessary to satisfy the lock script criteria. For example, it may include Bob's signature. The unlock script appears in transaction input 202.

[0060] In other words, in the illustrated example, the UTXO0 in output 203 of Tx0 is signed by Alice Sig P for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be valid). A Lock script that requires [Checksig P A [Equipped with] [Checksig P Ais the public key P from Alice's public - private key pair A and includes an expression (i.e., a hash) of A . The input 202 of Tx1 comprises a pointer that indicates Tx1 (e.g., in an embodiment, its transaction ID, TxID0 which is the hash of the entire transaction Tx0). The input 202 of Tx1 comprises an index that identifies UTXO0 within Tx0, from among any other possible outputs of Tx0, for the purpose of identifying UTXO0. The input 202 of Tx1 comprises an unlock script <Sig P A > that includes Alice's cryptographic signature created by applying Alice's private key from the key pair to a predefined part of the data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

[0061] When the new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This comprises executing the lock script and the unlock script together to check whether the unlock script meets the conditions (which may comprise one or more criteria) defined in the lock script. In an embodiment, this includes concatenating the two scripts. <Sig P A > <P A >||[Checksig P A In the above formula, "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function composed of the unlock script (in this example, a stack - based language). Equally, the scripts can be executed one after another using a common stack instead of concatenating the scripts. In any case, when executed together, the scripts check that the public key P of Alice, such as that included in the lock script within the output of Tx0 A ​The unlock script in the input of Tx1 authenticates that it contains Alice's signature, which signs the expected portion of the data. The expected portion of the data itself ("the message") must also be included in order to perform this authentication. In this embodiment, the signed data comprises the entirety of Tx1 (i.e., a separate element specifying the signed portion of the plaintext data does not need to be included, as it already exists in essence).

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

[0063] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), blockchain node 104 considers Tx1 to be valid. This means that blockchain node 104 adds Tx1 to the ordered pool of pending transactions 154. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106, so that the transaction is propagated throughout network 106. Once Tx1 is verified and included in blockchain 150, this defines the UTXO0 from Tx0 as used. Note that Tx1 can only be valid if it uses an unused transaction output 203. If it attempts to use an output that has already been used by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been used (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important that blockchain 150 imposes a defined order on transaction 152. In practice, a given node 104 could maintain a separate database marking which UTXO 203 in which transaction 152 has been used, but ultimately, what defines whether a UTXO has been used is whether it has already formed a valid input to another valid transaction in blockchain 150.

[0064] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount specified in all inputs 202, this is another ground for invalidity in most transaction models. Therefore, such a transaction will not propagate and will not be included in block 151.

[0065] In a UTXO-based transaction model, it should be noted that a given UTXO must be used as a whole. A portion of the amount defined as used in the UTXO cannot be "left behind"; another portion will be used. However, amounts from a UTXO can be split across multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 within Tx0 can be split across multiple UTXOs within Tx1. Therefore, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself the remainder in a second output of Tx1, or pay it to another party.

[0066] In practice, Alice would also typically need to include a fee for the Bitcoin node 104 that successfully included her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and therefore, even if technically valid, may not be propagated and included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount specified by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the sole input to Tx1, and Tx1 has a single output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104, which won the proof-of-work race to create the block containing UTXO1. However, it is not necessarily excluded that, alternatively or additionally, a transaction fee may be explicitly specified in one of the UTXO203 of transaction 152.

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

[0068] It should be noted that script code is often expressed in a general way (i.e., does not use an exact language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the start of a lock script, creates an unusable output of a transaction, allowing data to be stored within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of a document that is desired to be stored on the blockchain.

[0069] Typically, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using elliptic curve secp256k1. A digital signature signs a specific portion of data. In some embodiments, for a given transaction, the signature signs a portion of the transaction input and some or all of the transaction output. The specific portion of the signed output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code typically included at the end of the signature to select which output is signed (and therefore fixed at signing).

[0070] A locking script is sometimes referred to as a "scriptPubKey," referring to the fact that each transaction typically contains the public key of the party being locked. An unlocking script is sometimes referred to as a "scriptSig," referring to the fact that it typically supplies the corresponding signature. However, more generally, it is not mandatory in all blockchain applications for a UTXO to be redeemed to include signature authentication. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

[0071] Side channel As shown in Figure 1, the client applications on Alice's and Bob's respective computer devices 102a and 120b may each have additional communication capabilities. This additional capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the direction of either party or a third party). The side channel 107 enables the exchange of data separately from the blockchain network. Such communication is sometimes called “off-chain” communication. For example, this could be used to exchange transaction 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing onto chain 150 until one of the parties chooses to broadcast the transaction to network 106. Sharing a transaction in this manner is sometimes called sharing a “transaction template.” A transaction template may be missing one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, or data content.

[0072] Side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even via a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, side channel 107 as referred to anywhere in this specification may comprise any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. If two or more links are used, the bundle or collection of off-chain links as a whole may be referred to as side channel 107. Therefore, when it is said that Alice and Bob exchange certain parts of information or data etc. via side channel 107, it should be noted that this does not necessarily imply that all of these parts of data must be transmitted over the exact same link or network of the same type.

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

[0074] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computer device 102, which includes outputting information to each user 103 via the user output means of the device 102 and receiving input from each user 103 via the user input means of the device 102. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output. The user input means may include, for example, an input array of one or more touchscreens (same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or voice input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, or joysticks.

[0075] Note: While various functions described herein may be described as being integrated into the same client application 105, this is not necessarily limited to this. Instead, they may be implemented in a suite of two or more separate applications, for example, one being a plug-in to another, or connected via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, and the functionality of a given module such as the transaction engine 401 may be divided among multiple applications. Furthermore, the possibility that some or all of the described functions may be implemented, for example, in the operating system layer is not ruled out. Wherever a single or given application 105 is mentioned anywhere in this specification, this is merely an example, and it should be understood that, more generally, the described functions can be implemented in any form of software.

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

[0077] As an example, Figure 3B shows UI500 from Alice's perspective. UI500 may comprise one or more UI elements 501, 502, 503 which are rendered as separate UI elements via a user output means.

[0078] For example, the UI elements may comprise one or more user-selectable elements 501, which could be buttons on different screens or different options within a menu. User input means are configured to allow user 103 (in this case, Alice 103a) to select or act on one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: The term “manual” as used herein is solely in contrast to “automatic” and is not necessarily limited to the use of one or both hands). This option allows the user (Alice) to select one or more high-level functions of a high-level scripting language, for example, functions configured to perform complex mathematical operations. The option also allows the user to convert from a compact lock script to an expandable lock script in order to generate a signature based on a version of the transaction that includes an expandable lock script instead of a compact lock script.

[0079] Alternatively or additionally, the UI element may include one or more data input fields 502 in which the user can write one or more high-level functions. These data input fields may be rendered, for example, on a screen via user output means, and data may be entered into the fields via user input means, such as a keyboard or touchscreen. Alternatively, data may be received orally, for example, based on speech recognition.

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

[0081] It will be understood that the specific means of rendering various UI elements, selecting options, and entering data are not important. The functionality of these UI elements will be explained in detail shortly. It will also be understood that UI500 shown in Figure 3 is merely a schematic mockup and may actually have one or more additional UI elements that are not shown for the sake of brevity.

[0082] Node Software Figure 4 shows an example of node software 450 running on each blockchain node 104 of network 106 in an example of a UTXO or output-based model. Note that another entity may run node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of a node 104. Node software 450 may include, but are not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software including, but are not limited to, all three: a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize different fields of transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 Transaction 152j(Tx) has an input that points to the output (e.g., UTXO) of ). j When ) is received, protocol engine 451 will j Identify the unlock script within and pass it to script engine 452. Protocol engine 451 also handles Tx j Based on the pointer in the input, Tx i Identify and extract Tx iIt may be published on blockchain 150, in which case the protocol engine will take the transaction from a copy of block 151 of blockchain 150 stored on node 104. i It is possible to extract Tx i It may not yet be publicly available on blockchain 150. In that case, the protocol engine 451 will use the ordered set of unpublished transactions 154 maintained by node 104 to find the Tx i It can extract. In any case, script engine 451 is Tx i Identify the lock script in the referenced output and pass it to script engine 452.

[0083] Therefore, script engine 452 is Tx i The lock script and Tx j It has a lock-unlocking script from the corresponding input. For example, transactions labeled Tx0 and Tx1 are shown in Figure 2, but the same applies to any pair of transactions. The script engine 452 executes the two scripts together as described above, which involves placing data on the stack 453 and retrieving data from there, according to the stack-based scripting language being used (e.g., Script).

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

[0085] In output-based models, the result "true" from script engine 452 is one of the conditions for transaction validity. Typically, Tx j The total value of digital assets specified in the output does not exceed the total value indicated by its input, and Tx i There are also one or more further protocol-level conditions, which must also be satisfied and are evaluated by the protocol engine 451, such as that the output shown has not yet been used by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and only if they are all true does transaction Tx proceed. j The protocol engine 451 verifies whether the transaction is valid. The protocol engine 451 outputs an instruction to the application-level decision engine 454 indicating whether the transaction is valid. j Decision engine 454 will only be able to verify Tx j To perform their respective blockchain-related functions, it is possible to choose to control both the consensus module 455C and the propagation module 455P. This means that the consensus module 455C will be used to incorporate Tx into block 151. j Adding the 154 ordered sets of transactions on each node, and the propagation module 455P Tx j This includes transferring the transaction to another blockchain node 104 within the network 106. Optionally, in the 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 it is valid and leaves sufficient transaction fees.

[0086] It should be noted that the terms “true” and “false” as used herein are not necessarily limited to returning results expressed in the form of a single binary number (bits), although that is certainly one possible implementation. More generally, “true” can refer to any state indicating success or a positive outcome, and “false” can refer to any state indicating failure or a non-positive outcome. For example, in an account-based model, a “true” result may be indicated by a combination of implicit, protocol-level verification of the signature and an additional positive output from the smart contract (the overall result is considered true if both individual outputs are true).

[0087] High-level scripting languages Figure 5 shows an exemplary system 500 for implementing an embodiment of the present invention. System 500 comprises one or more generating parties (i.e., parties that generate blockchain transactions). For simplicity, only two generating parties, Alice 103a and Bob 103b, are shown in Figure 5. Note that the generating parties do not have to be users and may instead be machines. System 500 also comprises a verification entity, shown in the form of a blockchain node 104, and one or more nodes of a blockchain network 106.

[0088] A generating party, e.g., Alice 103a, is configured to generate a first blockchain transaction Tx1. The first blockchain transaction Tx1 has one or more outputs. At least one of the outputs (the first output) has a compact lock script (CLS). Note that the first output does not need to be the first to appear logically within the transaction. Instead, "first" is used only as a label for this particular output. The CLS is written in a high-level (HL) scripting language and has one or more high-level (HL) functions. Each high-level function is configured to perform the equivalent action of one or more low-level (LL) functions (e.g., opcodes) in the low-level (LL) scripting language of blockchain 150, i.e., the native scripting language. The CLS is configured to perform the equivalent action of an expanding lock script (ELS) written using only the LL scripting language (i.e., define a lock condition). For example, both the CLS and ELS could define a lock script that finds the inverse remainder of a number. Instead of requiring numerous LL functions to perform that operation, CLS can have a single HL function configured to find the inverse remainder of a number, thus reducing the size of CLS compared to ELS. In other words, CLS written in an HL scripting language can be compiled into ELS written in an LL language.

[0089] In some cases, a one-to-one mapping can exist between a single high-level function and a single LL function. For example, the HL function "ADD" or "+" may perform the corresponding LL function operation, such as OP_ADD. Similarly, the symbols "-", "*", and " / " may be used to perform subtraction, multiplication, and division, respectively. This allows for the desistency of LL functions such as OP_SUB, OP_MUL, and OP_DIV used by certain LL scripting languages, such as Script.

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

[0091] The first transaction Tx1 may have multiple outputs, for example, a second output. The second output may have its own CLS. In general, some or all of the outputs of the first transaction Tx1 may have their own CLS.

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

[0093] In some examples, Alice 103a may generate the transaction identifier TxID1 for the first transaction Tx1. The transaction identifier is typically a hash or double hash of the raw transaction data. Alice 103a first generates the transaction identifier TxID1 for the first transaction Tx, which does not include the CLS but instead includes the corresponding ELS. rawThis generates a modified version of the first ELS. That is, the first output will contain the first ELS instead of the first CLS. Similarly, if the first transaction Tx1 contains multiple CLSs, the modified version will contain multiple ELSs instead. Then the first transaction Tx raw By obtaining the hash (e.g., SHA-256) or double hash (e.g., double SHA-256) of the modified version of the first transaction Tx raw Based on the modified version, a transaction identifier TxID1 is generated. Alice 103a makes the transaction identifier TxID1 available to the blockchain network 106 by sending it to blockchain node 104 along with the first transaction Tx1.

[0094] In some examples, Alice 103a first generates a version of the first transaction Tx1 containing CLS, and then the first transaction Tx raw This generates a modified version of the CLS, that is, it replaces any CLS with its corresponding ELS. In other words, function 403 can convert a first CLS to a first ELS by mapping between HL functions of the HL language and LL functions of the LL language, i.e., the first CLS is compiled into a first ELS. Then, a transaction identifier TxID1 is generated.

[0095] First transaction Tx raw Generating a modified version may simply mean replacing the first CLS with the first ELS. Then, after the transaction identifier TxID1 is generated, the first ELS can be replaced with the first CLS so that the version of the first transaction Tx1 containing the first CLS can be sent to the blockchain network 106.

[0096] Also, Alice 103a initially initiated the first transaction Tx rawThis does not rule out the possibility of generating a modified version of the transaction that includes the first ELS. This allows Alice 103a to generate the transaction identifier TxID1. Alice 103a can then replace the ELS with the corresponding CLS. That is, function 403 can convert the first ELS to the first CLS by mapping between LL functions of the LL language and HL functions of the HL language.

[0097] Blockchain transactions often include a signature as an input to unlock the referenced output of a previous transaction. If Alice103a needs to include a signature as part of the input to the first transaction Tx1 in order to unlock the output of the previous transaction, then Alice103a will include a signature as part of the input to the first transaction Tx raw The signature may be included as part of the revised version. In other words, Alice's signature is included in the first transaction Tx which contains the first ELS, not the first CLS. raw Sign the modified version. Then, the transaction identifier TxID1 can be generated based on the modified version, which includes Alice's signature. The version of the transaction submitted to network 106 also includes Alice's signature. However, when the first transaction Tx1 is used as a message for verification, the signature is not a valid signature. The first transaction Tx raw This signature is only valid when using a modified version of the message.

[0098] It should be noted that the replacement of the first CLS with the first ELS may depend on the selection of signature flags (e.g., the SIGHASH flag) chosen 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 need 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 applied to only one output. In this case, if the signature is applied to 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 the corresponding ELS). Furthermore, in this case, if a CLS exists in output other than the signed output, Alice 103a does not need to replace that CLS. However, if a single output signed by the signature contains the first CLS, Alice 103a must replace the first CLS with the first ELS. Finally, Alice 103a may choose a signature flag (e.g., SIGHASH_ALL) so that the signature signs all outputs. In that case, Alice 103a must replace the first CLS with the first ELS. The same applies to any other outputs that contain their respective CLSs.

[0099] In some examples, Alice 103a may generate one or more secondary transaction identifiers. These secondary identifiers are similar to the transaction identifier TxID1 described above in that they may be a hash or double hash of the data, but the hashed data is different. For example, a secondary transaction identifier may be generated based on one or more of the following: the version number of the first transaction Tx1, the 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. In a specific example, a secondary transaction identifier may be based on the version number and lock time. Additionally or alternatively, a secondary transaction identifier may be based on an output with its respective CLS.

[0100] The input to a transaction may include the following three parts: 1. Transaction identifiers linked to the index (indicating which transaction output is used), 2. Unlock script, and 3. Sequence number.

[0101] The unlock script may include a digital signature that signs the secondary transaction identifier. Therefore, any portion of the unlock script that contains a digital signature that might sign the secondary transaction should be excluded. If the secondary transaction identifier is based on one or more inputs, some or all of the unlock script for those inputs may be excluded to avoid circular references. In other words, the transaction identifier may only be based on the transaction identifier concatenated with the index and / or sequence number, and not on the complete unlock script.

[0102] The secondary transaction identifier may be included in the output of the first transaction Tx1, for example, in the unavailable output. rawA modified version of this may also include a secondary transaction identifier. Therefore, in these examples, the "primary" transaction identifier TxID1 and signature are functions of the secondary transaction identifier.

[0103] In some embodiments, the HL scripting language described above may be a high-level language compared to an LL scripting language, but a low-level language compared to an even higher-level scripting language. That is, the HL language may be an intermediate-level language between an LL language and a second-tier HL language. A second-tier HL language is a user-facing language. In other words, a user-facing language may be a scripting language that can be written by a user (or another party or entity, including a device). A script written in the user-facing language can be compiled into an intermediate language, for example, a script written in a first CLS (which may mean it is compressed). Then, a script written in the intermediate language can be expanded into a script written in an LL language (for example, by mapping). It is also not ruled out that a script written in the user-facing language may be directly converted into a script written in a low-level language.

[0104] In other words, in some embodiments, there are only two levels of scripting languages: a high-level language and a low-level language, while in other embodiments, there are three levels of scripting languages: a user-facing (highest) level, an intermediate language level, and a low-level language.

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

[0106] The above instruction applies not only to lock scripts but also to unlock scripts. That is, in addition to generating compact lock scripts that are converted into expanded lock scripts, or instead, Alice's transactions may include compact unlock scripts. Compact unlock scripts can be written in an intermediate language or a user-facing language.

[0107] As shown in Figure 5, blockchain node 104 obtains the first transaction Tx1. The first transaction Tx1 includes the first CLS (and possibly one or more additional CLS). The first transaction Tx1 may be obtained directly from Alice 103a or from a different entity, such as Bob 103b. The possibility that node 104 obtains the first transaction Tx1 from a different node 104 is not ruled out.

[0108] Node 104 is configured to validate the first transaction Tx1. In some embodiments, the first transaction Tx1 is validated based on its transaction identifier. In these embodiments, Node 104 obtains a candidate transaction identifier TxID1 from, for example, Alice 103a, Bob 103b, or a different entity. The transaction generating party, namely Alice 103a, is expected to send the candidate transaction identifier TxID1 along with the first transaction Tx1.

[0109] Node 104 replaces the first CLS with the corresponding ELS, thereby completing the first transaction Tx raw This generates a modified version of ', i.e., the first CLS is compiled into the first ELS. In other words, node 104 is configured to convert the first CLS to the first ELS. This can be done by the node's scripting engine 452 or by another function 455. First transaction Tx raw Node 104, which generated the corrected version of ', first transaction Tx raw Generates transaction identifier TxID1 based on the modified version of '. For example, transaction identifier TxID1' is the first transaction Tx raw This can be generated by hashing or double-hashing a modified version of '.

[0110] For the first transaction Tx1 to be considered valid, the retrieved candidate transaction identifier TxID1 must match the generated transaction identifier TxID1'. Therefore, node 104 performs a comparison of transaction identifiers to determine if they are equal. If the transaction identifiers do not match, the first transaction Tx1 may be considered invalid and ignored.

[0111] If the transaction identifiers match, node 104 may proceed with verifying the transaction according to the blockchain protocol. This involves taking the input of the first transaction Tx1 and the respective reference outputs of previous transactions and executing them together.

[0112] If transaction Tx1 is valid according to the blockchain protocol, node 104 sends transaction Tx1 to other nodes 104 in network 106 and / or the first transaction Tx raw It is possible to attempt to build a block based on the corrected version of transaction Tx. raw This will include the Merkle root of the Merkle tree (i.e., the (double) hash of the modified transaction with the first ELS) which has the transaction identifier TxID1 as one of its leaves. raw This may include storing a modified version of it in memory.

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

[0114] In some examples, node 104 responds to the receipt of the request by executing the first transaction Tx raw A modified version of the first transaction Tx1 may be sent to another node 104. For example, block 151 containing the first transaction Tx1 may be published on blockchain 150. The requesting node 104 may not be configured to verify the transaction containing the script written in HL language. Therefore, node 104 may not verify the first transaction Tx raw The modified version is sent to the requesting node so that the requesting node 104 can validate the first transaction, as is typical for transactions that only contain LL scripting language.

[0115] Up to this point, the above explanation of transaction validation has focused on validation of transactions involving CLS, but the inputs were not necessarily intended to release the CLS lock. For example, the first transaction Tx1 may contain an input that releases the lock on the output of a previous transaction written using only a LL language.

[0116] Assuming that the first transaction Tx1 is a valid transaction, it is published in block 151. Blockchain node 104 (which does not necessarily have to be the same node 104 that published block 151, but is not excluded) may then receive a 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 may be generated by a second party, for example, Bob 103b. Bob 103b may send the second transaction directly to node 104, or indirectly through a different entity, for example, a third user named Charlie.

[0117] Next, node 104 proceeds to verify the second transaction Tx2. To verify the second transaction Tx2, node 104 must retrieve the first transaction from, for example, memory or blockchain 150. Then, node 104 has two options for verifying the second transaction Tx2. As a first option, node 104 may replace the first CLS with the first ELS (i.e., the first CLS is compiled into the first ELS) and then execute the input for the second transaction against the first ELS. For the second transaction to be valid, the execution must be successful. In other words, the input for the second transaction must successfully release the lock on the first ELS. As a second option, node 104 does not need to replace the first CLS with the first ELS; instead, node 104 may execute the input for the second transaction Tx2 against the first CLS. Again, for the second transaction to be valid, the execution must be successful. In other words, the input to the second transaction Tx2 requires that the lock on the first CLS be successfully released.

[0118] Since the first CLS is equivalent to the first ELS, the same input unlocks both the first CLS and the first ELS. As a simple example, suppose the first ELS has several LL functions configured to take a number from the input of the second transaction Tx2, perform mathematical operations on that number, and check whether that number matches a number contained in the first ELS. The first CLS is configured to perform the same operation but is smaller in size than the first ELS. For example, the first CLS may contain a number and a single HL function, while the first ELS may contain a number as well as many LL functions. Since the overall operation of the first ELS and the first CLS is the same, the same input leads to the same result, namely success or failure of execution.

[0119] If the second transaction Tx2 is valid, i.e., the second transaction's unlock script successfully unlocks the first ELS or first CLS and any other conditions of the blockchain protocol are met, node 104 may send the second transaction Tx2 to other nodes 104 in the blockchain network 106. Node 104 may also store the second transaction Tx2, for example, to construct block 151 containing the second transaction Tx2.

[0120] The second transaction Tx2 may have one or more outputs, each containing a CLS. In that case, as part of the verification of the second transaction Tx2, node 104 may perform the same actions as described above when discussing the verification of the first transaction Tx1, 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. For efficiency, the comparison may be performed before executing the input and output scripts.

[0121] The above explanation of transaction verification has primarily focused on verifying transactions that have a compact lock script. Node 104 can also verify transactions that have a compact unlock script (in addition to or instead of a compact lock script). Node 104 may directly execute the compact unlock script during transaction verification, i.e., the compact unlock script is executed directly in an HL scripting language (which may be a user-facing language or an intermediate language). Alternatively, Node 104 may convert the compact unlock script into an expandable unlock script written in an LL scripting language before execution.

[0122] The explanation regarding generating a modified version of a transaction for the purpose of generating a signature and / or transaction identifier also applies to scenarios where the transaction has a compact lock release script.

[0123] Figure 9 illustrates the relationships between the three types of languages. As shown, the lowest level is the LL language, i.e., the native scripting language of the blockchain (e.g., the opcodes of the scripting language). A higher level is the intermediate language. Above the intermediate language is the user-facing language.

[0124] This programming architecture is designed to make blockchain scripts more accessible, more computationally and spatially efficient, and better suited to smart contracts.

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

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

[0127] The function table may be created in whole or in part by Alice 103a and distributed to one or more nodes 104, or the function table may be created in whole or in part by another entity, for example, one of the nodes 104.

[0128] In embodiments utilizing a three-tier framework (i.e., user-facing language, intermediate-level language, and low-level language), a function table may be used to map from the UF language to the IL language. When a function is written in the UF language, it is compiled (i.e., translated) into a corresponding IL function. The corresponding IL is mapped to one or more other (i.e., different) IL functions and / or one or more LL functions, i.e., one IL function (for example, "reverse" in the exemplary section below) is mapped to a set of low-level functions that perform the same operation as the IL function together. Here, "low-level" means a level lower than the user-facing level. The set of low-level functions is stored in a function table associated with the IL function (in the exemplary section below, "length" is an example of a different IL function).

[0129] Next, a function table may be used to generate and / or execute an IL script. For example, an IL script may include a reference to an IL function or an identifier of an IL function, thereby allowing a mapped set of low-level functions to be executed at runtime. In other words, the identifier / reference is used to look up a set of low-level functions. In this example, the reference or identifier itself is an IL function, configured to perform the equivalent behavior of one or more LL functions at runtime, and similarly, the equivalent behavior of the identified / referenced function. The IL script itself can be expanded into a corresponding native script. Here again, a set of low-level functions is retrieved from the function table and can be expanded into only LL (i.e., native) functions. Note that the set of low-level functions that defines a single IL function may itself contain different IL functions, or identifiers or references to those different IL functions.

[0130] As mentioned above, there can be multiple different UF languages ​​(e.g., Python and Java) that can compile to the same IL language. It is desirable, but not required, that the same UF function written in different UF languages ​​(i.e., a function written in a different language but configured to perform the same action) compile to the same set of low-level functions in the function table.

[0131] Node 104 may generate a larger function table based on several smaller function tables, for example, function tables generated by different parties (e.g., users or nodes). The overall table may be stored by a central party, and node 104 may update those tables from time to time by requesting the overall table.

[0132] 《User-friendly / highest level language》 A user-facing language (User-Facing Language) is human-readable, easy for developers to use, extensible, and can be compiled into an intermediate-level language. Examples of User-Facing Languages ​​are provided below. However, multiple different User-Facing Languages ​​can exist that can compile into the same intermediate-level language. Existing languages ​​such as Java, JavaScript, or Python can also be adapted to become a high-level language for creating blockchain transactions.

[0133] Intermediate-level language Intermediate-level languages ​​connect high-level languages ​​to low-level languages ​​(e.g., opcodes) to improve efficiency in bandwidth, storage, and computation. Hereafter, this general-purpose intermediate-level language will be referred to as metascript. The characteristics of metascript can be summarized as follows: 1. Space efficiency - more compact in size than high-level and low-level languages. 2. Executable - Can be run directly by a compatible scripting engine. 3. Expandable - Can be expanded into low-level languages ​​(native scripts). 4. Definitive – The same metascript will always be expanded into the same native script.

[0134] Furthermore, given the same input and executed directly, the metascript produces the same output as the output produced by executing the native script that expands from the metascript.

[0135] Developers can write scripts in a user-facing language, which are then compiled into an intermediate-level language script (metascript). Transactions can be sent and stored in the metascript version. Transactions are validated using metascript, native script, or a hybrid method (i.e., execution of unlock and lock scripts). In other words, the metascript engine of blockchain node 104 can interact with the native script engine to gain more functionality and efficiency.

[0136] User-facing language scripts can be directly converted to low-level language scripts (native scripts). However, by introducing intermediate-level language scripts (metascripts), the work involved in converting blockchain node 104's user-facing language scripts to native scripts is reduced as much as possible. This allows node 104 to concentrate its resources on other more important activities such as block generation (mining). The example illustrates how user-facing language scripts, intermediate-level language scripts, and low-level language scripts differ from each other and how they improve blockchain scripts in various ways.

[0137] The following provides specific examples of several embodiments of the present invention. While these examples refer to the Bitcoin blockchain, it should be noted that they are generally applicable to other blockchains as well.

[0138] Note that the following examples describe an architecture with three language levels: user-facing, intermediate-level, and low-level. In these examples, smart contracts are written in the user-facing language, converted to metascripts written in the intermediate-level language, and then converted to Bitcoin opcodes (i.e., the low-level language).

[0139] Creating a Transaction Alice can use a user-friendly level scripting language to create lock scripts [High-Level script B].

[0140] Next, the lock script is compiled into a metascript in an intermediate language and embedded in the transaction. [Table 1]

[0141] There are a few things to keep in mind here. 1. A lock script [High-Level script B] is a compact script written in a user-facing scripting language. This is called a user-facing lock script. 2. The lock script for the user is compiled into a metascript. 3. Each metascript has a native Bitcoin opcode and an equivalent native lock script. That is, executing the same unlock script will always produce the same result. This deterministic behavior and its equivalence can be realized through testable and verifiable computations. 4. Native lock scripts can be several megabytes or more in size, but their compact form can be reduced to just a few bytes. This significant size difference is beneficial for Bitcoin nodes when propagating and storing transactions. 5. An unsigned transaction is initially constructed (Table 1 (Table 2)). When the transaction is signed, the compact lock script is expanded into a low-level language lock script (Table 2 (Table 3)). [Table 2] [Table 3] [Table 4]

[0142] 6. After signing the transaction, while the native lock script still exists within the transaction, the transaction is serialized and double-hashed to obtain the transaction ID. That is, TxID1 is calculated based on the decompression lock script, not the compact lock script. This ensures forklessness, meaning that forks in the blockchain are prevented because the TxID is defined based on the native Bitcoin script. [Table 5]

[0143] 7. To facilitate integrity verification in some scenarios, the secondary transaction ID of the compact lock script can be embedded in the transaction before signing. For example, TxID 1-secondary It can be defined as a hash value where the preimage has one of the following characteristics: a. Version and lock time, b. Input without an unlock script, and c. Output with a compact lock script.

[0144] This is shown in Tables 5 (Table 6) through 8 (Table 9). [Table 6] [Table 7] [Table 8] [Table 9]

[0145] Transaction propagation Transactions created by Alice 103a above are propagated in a compact format (metascript) to save bandwidth. As previously mentioned, this compact format is several orders of magnitude smaller than the expanded lock script. This is particularly relevant to the Bitcoin SV ecosystem, where the script size is unlimited and each block can contain billions of transactions (approximately every 10 minutes).

[0146] For now, let's assume there are two types of nodes: HL-enabled Bitcoin nodes configured to run the HL scripting language, and HL-disabled Bitcoin nodes that are not. Note that HL-disabled nodes are existing nodes that are not aware of the HL scripting language and are not configured to use it, as opposed to nodes that are aware of the HL language and have simply chosen to disable its functionality.

[0147] Depending on the signature flag used to sign the input to a transaction (see explanation above), an HL-unavailable node may consider a transaction containing a CLS to be invalid. That is, when an HL-unavailable node receives a transaction, it considers it invalid and discards it because it has no mechanism to retrieve the original transaction using the unpacking lock script. During signature verification of the unlock script for an expenditure transaction, the transaction is considered invalid because the signed message is assumed to contain an ELS (which the HL-unavailable node cannot replicate from the CLS). This is the same scenario as receiving the transaction ID but not the transaction data. However, the lack of acceptance from these nodes can be addressed if the block is found by an HL-enabled Bitcoin node. An HL-unavailable node receives a block containing Alice's transactions. Alice's transactions are considered non-existent because the HL-unavailable node does not remember them. The HL-unavailable node may then request the transaction from the HL-enabled node. The HL-enabled node sends the complete transaction without using the compact lock script. The HL-unavailable node can then verify the entire transaction. However, if the majority of nodes are HL-enabled, Alice's transactions will be accepted by the majority of network 106, so HL-enabled nodes can choose to ignore such requests.

[0148] In some cases, if the signature does not sign all transaction outputs, and the output including the CLS is not signed, an HL-unavailable node may be able to consider the HL transaction valid. In that case, the HL-unavailable node can actually verify the transaction using the CLS. 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, becomes vulnerable when its output is modified.

[0149] When an HL-enabled node receives a transaction, it performs the following actions: 1. Convert the meta-lock script to the corresponding native lock script and use library registers or reference tables to obtain the following: [Table 10]

[0150] 2. Hash the transaction data to obtain the transaction ID and check if it is the same as TxID1. 3. If they are the same, proceed to general signature verification or script verification. 4. If the transaction is valid, the HL-enabled node propagates the transaction to its peers in compact format.

[0151] When a node that cannot use HL validates a block found by an HL-enabled Bitcoin node, it requests the complete transaction data for the transaction using a compact lock script, or simply the transaction that is lost in that sense. In this case, the HL-enabled node sends those transactions using an expand lock script. This allows the HL-enabled node to validate those transactions. Since each compact lock script is equivalent to an expand lock script, transactions successfully validated by an HL-enabled node are also valid for HL-enabled nodes.

[0152] Transaction Verification Suppose a user, for example Bob 103b, is trying to spend money on a transaction created by Alice 103a. He creates the spend transaction. [Table 11] input B Assuming that [Meta Script B] is unlocked, here input B is a public key primary key B Bob Sig B This may include a digital signature.

[0153] As an HL-enabled node, it can be used to verify spending transactions, or more precisely, to script. <input B To validate "[Meta Script B]", you can choose one of the following options: 1. Obtain the compiled lock script and use the native scripting engine <input B >Use SDL to execute [Expand MetaScript B in Bitcoin Opcodes] 2. <input B >Execute [Meta Script B] and use SDL to obtain the same result as option 1.

[0154] Option 2 offers a computational advantage to nodes with HL enabled over nodes with HL disabled. Consider a scenario with two scripting engines, SE1 and SE2. 1. When the same input is given to the engine, both SE1 and SE2 produce the same result, and 2. SE2 is more efficient than SE1 (given the same input, it takes less time to produce the result).

[0155] As a node, switching between SE1 and SE2 does not affect the blockchain protocol.

[0156] For the reasons mentioned above, HL-enabled nodes can switch between the native scripting engine (as SE1) and the HL engine (as SE2) to optimize the script validation process.

[0157] Transaction memory As an HL-enabled node, to save space, transactions can be stored using compact lock scripts. Without loss of generality, assume that transactions exist as shown in Table 10 (Table 12). [Table 12] Alternatively, a secondary identifier may be added to the first output, for example: [smart contract]OP_FALSE OP_RETURN TxID 1-secondary >.

[0158] Note that while a lock script [Bitcoin opcode expanded from metascript B] can be several megabytes when expanded into native opcode, its compact form (metascript) can be only a few bytes. If there are billions of such transactions in a single block (approximately every 10 minutes), the storage space savings will be substantial.

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

[0160] Figure 6 shows the flow from transaction creation to verification. First, transaction Tx1 is created using the HL scripting language. Next, the HL scripting language is translated, and Tx raw This is generated. Then, Tx raw A transaction identifier TxID1 is generated based on this. The transaction identifier TxID1 and HL transaction Tx1 are sent to blockchain node 104. Node 104 receives the transaction identifier TxID1 and HL transaction Tx1. The HL script language is converted to the LL script language, and the resulting transaction is used to generate the transaction identifier TxID1'. The received transaction identifier and the generated transaction identifier are compared. If they match, node 104 continues verifying the transaction, and vice versa.

[0161] Sending TxID1 serves as a robust error checking mechanism, allowing node 104 to detect inconsistencies between the transaction generator (e.g., Alice 103a) and the mappings used by the transaction verification node 104 (CLS to ELS and ELS to CLS). However, alternative error checking mechanisms can also be used. Including TxID1 also allows node 104 to quickly initiate mining operations (e.g., building a Merkle tree based on TxID1) while still performing transaction mapping and verification.

[0162] Figure 7 shows the flow of a signed transaction from generation to verification. This flow is similar to the flow in Figure 6, but with the additional step of signing the transaction after conversion from HL script language to LL script language. The transaction identifier is based on the signed transaction. First, a transaction lock script is generated by the transaction engine function and written in HL language. This then identifies the transaction Tx, which contains a compact lock script that has not yet been signed. 1-unsigned The following is output. Typically, unlock scripts within a transaction require a transaction signature. To sign a transaction, HL functions must be replaced with an equivalent set of LL functions. Tx 1-unsigned This is passed to a mapping module that replaces the HL function with a native LL number, such as an opcode. The mapping module is Tx 1-unsigned Received, Tx raw-unsigned It outputs this, which is passed to the signing module. The transaction signing module Tx raw-unsigned Upon receiving the signed transaction Tx raw Outputs Tx raw This is used to generate the transaction ID (TxID). raw It is passed back to the mapping module, where the LL function is replaced with the HL function. The sender then concatenates TxID and Tx1 and sends it to the blockchain. To check that the mapping used by the receiver is the same as the mapping used by the sender, the receiver uses Tx1 to Tx raw It maps to ' and generates a 'TxID', then checks if it is equal to the TxID. If they are the same, the recipient can proceed with validating the transaction. The TxID is used as a parity check in this instantiation.

[0163] Figure 8 shows the data flow in several embodiments. An HL-enabled transaction creator (e.g., Alice 103a) generates a transaction with a compact lock script. At this point, the transaction is not signed. The compact lock script is replaced with an expansion script and then signed. The signed transaction is hashed to generate a transaction identifier. The expansion lock script is replaced with a compact lock script, and both are sent to the blockchain network 106. An HL-enabled transaction validator (e.g., node 104) receives the transaction and transaction identifier. The compact lock script is replaced with an expansion lock script, and then the transaction is hashed to generate a candidate transaction identifier. The candidate transaction identifier is compared with the received transaction identifier, and if they match, the validator proceeds to verify the transaction. If they do not match, the validator discards the transaction. An HL-unavailable transaction validator is also shown. If only the compact version of the transaction is received, the HL-unavailable transaction validator cannot verify the transaction. On the other hand, if the expansion transaction is received, the HL-unavailable transaction validator can verify the transaction. Once the transaction is published on the blockchain, the HL-unavailable validator requests the compiled transaction to verify the transaction.

[0164] Examples This section provides three sets of examples demonstrating how the disclosed framework works. The first set focuses on the practical and computational efficiency benefits of using function tables when translating from a high-level (user-facing) language to an intermediate-level (metascript) language. The second set focuses on the compactness of the metascript language. The third set provides insights into several more complex scripts. The third set also demonstrates how scripts written in a high-level language can be directly translated to a low-level native scripting language.

[0165] 《Example Set 1》 This example demonstrates how a function table can be used to convert a script written in a top-level language into a compact metascript. The example script reverses the characters of an input string. [Table 13] Next, the highest-level language is compiled into an intermediate-level language, where the function table and variable table are referenced or created. The function table and variable table are distributed and can be stored locally. In some examples, once created, the variable table is read-and-write, while the function table is read-only. Examples include the following: [Table 14] This example function table contains two functions with function IDs 0 and 1. The first function calculates the size of the input string, and the second function calls the first function and then reverses the string.

[0166] The explanation for Function 1 is as follows:

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

[0168] $0 refers to the first input to the script, which has not yet been provided. This could be the top item in the stack.

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

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

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

[0172] 0 MOP_SET_VAR assigns the top element of the stack to the variable at index 0 in the variable table. This variable can then be used for the remainder of the execution.

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

[0174] MOP_LOOP OP_1 OP_SPLIT MOP_END_BLOCK consumes the first value on the stack and loops the command between MOP_LOOP and MOP_END_BLOCK that many times.

[0175] After executing MOP_GET_VAR, MOP_LOOP, OP_SPLIT, and MOP_END_BLOCK, the string is split into single-byte substrings.

[0176] Similarly, 0 MOP_GET_VAR MOP_LOOP OP_SWAP OP_CAT MOP_END_BLOCK swaps the order of substrings and concatenates them to form a string that is the reverse of the input string.

[0177] Note that you don't need to enter values ​​when creating the variable table. It acts like a placeholder for function execution, allowing you to store values ​​and pass them during execution.

[0178] The same result can be obtained using a "while" loop. [Table 15] [Table 16] Here we have two variables, 1 and COUNTER. I suggest that COUNTER can be a reserved variable with a default value. That is, COUNTER can be called directly in metascript. When called in a "while" loop, the value starts at 0 and increases by 1 with each loop.

[0179] Next, let's explain how the "while" loop works.

[0180] The MOP_LOOP_IF COUNTER 0 MOP_GET_VAR LESSTHAN MOP_END_BLOCK statement starts a loop if the counter is less than the variable at index 0. The counter is a reserved variable with a default value; that is, you can call COUNTER directly within metascript. It implicitly counts the number of loops executed, starting at 0 and increasing by 1 each time. Execution terminates the "while" loop when the counter reaches the maximum value set by the higher-level language or default value, or when the condition is not met. In this case, the variable at index 0 is the length of the input string. In general, any condition can follow MOP_LOOP_IF, and the condition terminates with MOP_END_BLOCK.

[0181] OP_1 OP_SPLIT is executed repeatedly if the condition is met. Note that this was not included in the function table to demonstrate that there is an option not to include all words defined in the high-level language. As a general rule, if a function is frequently referenced, include that function in the function table.

[0182] MOP_END_BLOCK indicates the end of a repeating block of code.

[0183] After executing MOP_LOOP_IF COUNTER 1 MOP_GET_VAR LESSTHAN MOP_END_BLOCK OP_1 OP_SPLIT MOP_END_BLOCK, the string is split into single-byte substrings.

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

[0185] Intermediate-level language (metascript) Assuming the string "I am fish" is entered into the inverse function, the metascript would look like this: [Table 17]

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

[0187] 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 the function. The output is the reverse of the input string.

[0188] Metascripts can also be expanded into native format to generate transaction IDs, verify signatures, and execute them in a native scripting engine by specifying a function table.

[0189] When expanding this example script, we assume that the input (the unlock script) is known to the script's creator, or that the script's creator has set a maximum loop counter to prevent infinite loops.

[0190] Low-level languages ​​(e.g., Bitcoin opcodes) Expanding the metascript breaks all loops, allowing only native opcodes. As an example, the following native script corresponds to the previous example metascript. [Table 18] Note that the size of a regular script increases linearly with the size of the input string. However, the size of a metascript is almost constant and does not depend on the size of the input string. This indicates that the metascript framework saves a significant amount of storage and bandwidth.

[0191] Example Set 2 Reverse the string In this first example, the characters in the input string are also reversed. This example shows how the same function can be implemented without using the function table described. In this example, the high-level inverse function is compiled into a metascript. For example, the compiler is configured to read the function "reverse()" and compile the corresponding metascript. In a specific example, the mapping of high-level functions to metascripts may be stored in memory accessible to the compiler.

[0192] High-level language (i.e., user-facing language) [Table 19] If saved as a .txt file (source code), it takes up 31 bytes. Intermediate-level language (metascript): [Table 20] [Table 21] For example, use c0 for meta_loop, d1 for one_split, and e2 for swap_cat. Note that "76 09" pushes 9 bytes of data to the top of the stack. 2 (push data) + 9 (data) + 6 = 17 bytes in metascript When compiling from a high-level language, the metascript obtains the number of loops needed to reverse the string from the compiler. In this case, the number of loops will be the length of the string minus 1.

[0193] Low-level languages ​​(Bitcoin opcode / native script) [Table 22] 2 (op_pushdata and data size) + 9 (data) + 32 = 43 bytes

[0194] If input to a function is unavailable at compile time, the loop count may also be unavailable. In this case, the metascript is designed to either retrieve information from the unlock script or assume a default maximum value. For example, Lock scripts (functions) in high-level languages: reverse() Lock scripts (functions) within metascripts: meta_var meta_assignVar meta_var meta_loop one_split meta_var meta_loop swap_cat The unlock script (input to the function) is It can be set to 8.

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

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

Table 23

[0197] Intermediate-level language:

Table 24

Table 25

[0198] Low-level language:

Table 26

[0199] When there are many numbers, savings become even more important.

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

[0201] [[ID=
58]]《Variable Assignment》 This section briefly explains how to assign meta-variables in meta-scripts. This section introduces the mechanism for assigning variables in native scripts. High-level languages: var=5 return var+var

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

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

[0204] When converted to native scripts (such as Bitcoin opcodes), "5 var meta_assign" becomes "5 OP_TOALTSTACK," assigning the value "5" to a variable named "var." After this assignment, each subsequent occurrence of "var" is converted to "OP_FROMALTSTACK OP_DUP OP_TOALTSTACK." The alt stack becomes a stack for storing all variables (as an ordered list).

[0205] 《Example Set 3》 In the following example, the HL script is directly converted to the LL script, meaning there are only two levels of scripting languages: high-level and low-level.

[0206] Greatest Common Divisor (GCD) GCD is a function that takes two integers a and b as input and outputs GDC(a, b). This is implemented using a Euclidean algorithm, which can be described as follows: 1. Let a = x and b = y. 2. Given x and y, use the division algorithm to write x = yq + r and 0 ≤ r < |y|. 3. If r=0, the program stops and outputs y. This is the GCD of a and b. 4. If r≠0, replace (x, y) with (y, r). Proceed to Step 2.

[0207] The algorithm described above can be easily written and executed using a high-level programming language. However, executing the Euclidean algorithm using Bitcoin opcode scripts is not an easy task. Since the expanded script does not allow loops, each loop must be written using repeated OP_IF statements.

[0208] The following script retrieves the two most significant digits x and y from the main stack, and if y is the most significant digit, then y and r remain on the stack, and x = yq + r. [Table 27] The algorithm can be written as follows: [Table 28]

[0209] In the example above, we find the Global Decimal CD (GCD) of two positive integers if it can be calculated in three loops. If the input requires more loops, we need to write more if statements. This means that if Alice doesn't know the input beforehand when she wants to run the algorithm, we need to define a maximum number of if statements large enough to accommodate a range of inputs. What if we want to set this to more than 100, and that results in very large transactions in the compiled script?

[0210] In this example, Alice needs to specify the maximum number of iterations, and the SDL-enabled node can generate the correct transaction in the deployment script.

[0211] If the above algorithm is defined as a function / library function / forth word, it would be written as follows: Initial state of the stack: Final state of the stack: <r>, Initial state of Altstack: Unused Final state of Altstack: Unused Calculation: a = qb + r, or r = a mod b

[0212] FUNCTION_1-< / r> Received, teeth <r> <q>It returns a = b*q + r. Initial state of the stack:< / q> < / r> / / This is the top of the stack. Final state of the stack: <q> Altstack initial state: Unused Final state of Altstack: <d> / / This is the head of the altstack. OP_TUCK OP_2DUP OP_MOD OP_DUP OP_TOALTSTACK OP_SWAP OP_TOALTSTACK OP_SUB OP_SWAP OP_DIV

[0213] The above can be written in HL language as an HL function as follows: HL function qr(){TUCK 2DUP MOD DUP TAS SWAP TAS-SWAP / }

[0214] The HL scripting language allows you to define HL functions and write OP_CODES in a user-friendly and efficient way. In the example above, TUCK DUP SWAP corresponds to OP_TUCK OP_DUP OP_SWAP, FAS and TAS correspond to OP_FROMALTSTACK and OP_TOALTSTACK, and + - * / % corresponds to OP_ADD OP_SUB OP_MUL OP_DIV and OP_MOD, etc.

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

[0216] FUNCTION_2 - Parameter s of the extended Euclidean algorithm i = s i-2 - s i-1 q i and t i = t i-2 - t i-1 q i One loop for calculation. This example starts the stack using the initial values s i-2 , t i-2 , s i-1 , t i-1 , q i The algorithm starts with i = 2, s0 = 1, t0 = 0, s1 = 0, t1 = 1. Initial state of the stack: <s i-2 ><t i-2 ><s i-1 ><t i-1 ><q i > / / <q i > is the top of the stack Final state of the stack: <s i-1 ><t i-1 ><s i ><t i > Initial state of the Altstack: Unused Final state of the Altstack: Unused OP_DUP 3 OP_PICK OP_MUL 5 OP_ROLL OP_SWAP OP_SUB OP_SWAP 2 OP_PICK OP_MUL 4 OP_ROLL OP_SWAP OP_SUB

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

[0218] Extended Euclidean Algorithm This function< / r> < / q> Received, s n t n Calculate gcd(a,b) = gcd(a,b) = s n a+t n b is Initial state of the stack: / / is the top of the stack, a > b, and both are +ve integers Final state of the stack: <s n ><t n > gcd(a, b) / / gcd(a, b) at the top of the stack Initial state of the Altstack: unused Final state of the Altstack:... FUNCTION_1 1 0 0 1 4 OP_ROLL FUNCTION_2 OP_FROMALTSTACK OP_FROMALTSTACK OP_DUP OP_IF FUNCTION_1 FUNCTION_2 OP_FROMALTSTACK OP_FROMALTSTACK OP_DUP OP_IF FUNCTION_1 FUNCTION_2 OP_FROMALTSTACK OP_FROMALTSTACK OP_DUP OP_IF FUNCTION_1 FUNCTION_2 ... ... OP_ENDIF OP_ENDIF OP_ENDIF OP_DROP OP_NIP OP_NIP

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

[0220] This is an example of HL scripting language code. A loop is used to repeat the function up to 25 times. This can be set to many more times by simply changing the variable l. For example, l can be set to a number in the hundreds or thousands as needed. The size of the CLS remains unchanged, but the size of the corresponding ELS becomes megabytes.

[0221] 《Conclusion》 Other variations or uses of the disclosed techniques may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is not limited by the embodiments described herein, but only by the appended claims.

[0222] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is a specific example of blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, the above references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 can be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0223] 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 above functions of creating, publishing, propagating, and storing block 151 of blockchain 150. The possibility of other network entities (or network elements) performing only one or some of these functions, rather than all of them, is not ruled out. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (it should be noted that these entities are not considered nodes of the preferred Bitcoin network 106).

[0224] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. These embodiments do not preclude a node from performing at least one or more functions, if not all, of creating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, in those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or propagate those blocks 151 to other nodes.

[0225] More generally, the above reference to the term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element,” such entities / elements are configured to perform some or all of the roles of block creation, publication, propagation, and storage. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain node 104.

[0226] It will be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs may be provided in accordance with one or more of the following statements.

[0227] Statement 1. A computer implementation method for generating blockchain transactions, which is performed by a first party, A step of generating a first blockchain transaction, wherein the first blockchain transaction comprises a first compact script (CS), the first CS being at least partially written in a high-level (HL) scripting language and comprising one or more HL functions, each HL function configured to perform an action equivalent to that performed by one or more LL functions of a low-level (LL) scripting language when executed, the first CS being configured to perform an action equivalent to that of a first expansion script (ES) being written in an LL scripting language and comprising multiple LL functions, and the first CS having a smaller storage size than the first ES, The steps include making the first blockchain transaction available to one or more nodes and / or a second party of the blockchain network, and A computer implementation method comprising the above.

[0228] LL Scripting Language is a native blockchain scripting language.

[0229] The second party may sign the first transaction before returning the transaction to the first party or before sending the first transaction to the blockchain network.

[0230] The first scripting language (CS) can be written entirely in the HL scripting language. Alternatively, the first CS may be written partially in the HL scripting language and partially in another scripting language, such as the LL scripting language.

[0231] One or both of HL scripting languages ​​and LL scripting languages ​​can be stack-based scripting languages.

[0232] Statement 2. The method according to Statement 1, wherein the HL scripting language is an intermediate-level (IL) scripting language between the user-facing (UF) scripting language and the LL scripting language, and the HL functions are IL functions.

[0233] In other words, the UF scripting language is a top-level scripting language. The UF scripting language may also be a stack-based scripting language.

[0234] Statement 3. The step of generating the first blockchain transaction is, A step of generating a first UF script (UFS), wherein the first UFS is at least partially written in the UF scripting language and comprises one or more UF functions, and is configured such that, when executed, each UF function performs an action equivalent to the action performed by one or more IL functions. The step of converting the first UFS to the first CS and The method described in Statement 2, comprising:

[0235] The first UFS may have a smaller storage size than the first CS and / or the first ES.

[0236] The first UFS may be written entirely in the UF scripting language. Alternatively, the first UFS may be written partially in the UF scripting language and partially in another scripting language, such as the IL scripting language and / or the LL scripting language.

[0237] The step of converting a first UFS to a first CS comprises the step of compiling the first UFS into a first CS.

[0238] Statement 4. The method of Statement 3, wherein a function table comprises a list of function mappings, each function mapping comprises an IL function mapped to one or more other IL functions and / or a set of one or more LL functions, and the step of converting from a first UFS to a first CS is based on the function mappings listed in the function table.

[0239] Statement 5. The method according to Statement 4, wherein a function table comprises one or more function identifiers, each identifying a respective IL function, and a first CS comprises one or more first data pairs, each first data pair comprising a respective IL function identifier and a calling function, and when executed, the calling function is configured to execute one or more other IL functions and / or one or more LL functions mapped to the IL functions identified by their respective IL function identifiers.

[0240] Statement 6. The method according to Statement 5, wherein at least a portion of the function table is created by a first party, and the method comprises the step of making at least a portion of the function table available to one or more nodes of a blockchain network and / or a second party.

[0241] Statement 7. A method of which, according to either Statement 4 or one of the statements that references Statement 4, wherein at least a portion of the function table is prepared by a party other than the first party, and the method comprises the step of obtaining the said at least portion of the function table.

[0242] Statement 8. The method according to Statement 7, wherein the step of obtaining the function table comprises the step of receiving the function table from the blockchain node, wherein the step of obtaining the function table comprises the step of obtaining the function table from the blockchain node.

[0243] Statement 9. A method according to either Statement 3 or any statement referencing Statement 3, wherein a variable table comprises one or more variable identifiers and is configured to store variables associated with each variable identifier, and a first CS comprises one or more second data pairs, each second data pair comprising a respective variable identifier and either a read function or a write function, wherein when executed, the read function is configured to read a variable from the variable table stored associated with each variable identifier, and when executed, the write function is configured to write a variable generated during the execution of the first CS to the variable table for storage associated with each variable identifier.

[0244] For example, a write function may write the variable currently at the top of the stack to the variable table. Similarly, a read function may push the variable stored in the variable table to the top of the stack.

[0245] The function table may be created by the first party and made available to one or more nodes on the blockchain network and / or the second party. Alternatively, the variable table may be created by another party and sent to the first party.

[0246] Statement 10. A step of generating a first transaction identifier, wherein the first transaction identifier is generated based on a modified version of a first blockchain transaction, and this modified version of the first blockchain transaction comprises a first ES instead of a first CS. The steps include making the transaction identifier available to one or more nodes on the blockchain network, and A method according to any one of statements 1 through 9, comprising:

[0247] A first transaction identifier can be generated by first serializing a modified version of a first blockchain transaction, and then calculating a hash or double hash of that serialized modified version.

[0248] Statement 11. The step of generating a first transaction identifier, The first step is to generate a blockchain transaction, To generate a modified version of the first blockchain transaction for generating the first transaction identifier, the steps are to replace the first CS with the first ES and The method described in statement 10, comprising:

[0249] In other words, the first CS is transformed (i.e., expanded) into the first ES.

[0250] Statement 12. The method according to Statement 11, further comprising the step of replacing a first ES with a first CS before the step of making a first blockchain transaction available to one or more nodes of the blockchain network.

[0251] Statement 13. The step of generating the first blockchain transaction is, The steps include generating a modified version of the first blockchain transaction, The first step is to generate a first blockchain transaction by replacing the first ES with the first CS. The method described in statement 3, comprising:

[0252] Statement 14. A method by which a first blockchain transaction becomes available on one or more nodes of the blockchain network, along with a first transaction identifier, as described in Statement 10 or one of any statements that references Statement 10.

[0253] For example, the first blockchain transaction can be concatenated with the first transaction identifier.

[0254] Statement 15. The method according to any one of Statements 1 through 14, wherein the first blockchain transaction comprises a first input, and the first input comprises a signature generated based on a modified version of the first blockchain transaction.

[0255] More specifically, the signature is generated based on a modified version of the first blockchain transaction, which has the first ES rather than the first CS.

[0256] Statement 16. The first blockchain transaction is in the following fields: The version number of the first blockchain transaction, The lock time for the first blockchain transaction, One or more inputs of the first blockchain transaction, One or more inputs of a first blockchain transaction that does not have an unlock script, One or more outputs of the first blockchain transaction, each with its own CS A method of any one of statements 1 to 15, comprising a secondary transaction identifier based on one or more of the following.

[0257] For example, a secondary identifier may be generated based on one or more hashes (e.g., a double hash) of those fields.

[0258] Statement 17. The method described in Statements 11 and 12, wherein the modified version of the first blockchain transaction on which the signature is based has an output that includes a secondary transaction identifier.

[0259] Statement 18. A method according to any one of Statements 1 to 17, comprising the step of making available a first blockchain transaction to one or more blockchain client applications.

[0260] Statement 19. A method according to any one of Statements 1 to 18, comprising the step of storing a first blockchain transaction in the memory of a computing device operated by the first party.

[0261] Please note that memory can be a hard drive.

[0262] Statement 20. A method of any one of statements 1 through 19 in which an operation performed by at least one of the HL functions is equivalent to an operation performed by multiple LL functions.

[0263] In some embodiments, each operation performed by at least some of the HL functions may be equivalent to an operation performed by each of the multiple LL functions.

[0264] Statement 21. The method according to any one of statements 1 through 20, wherein the first CS is the first compact lock script (CLS) and the first ES is the first expansion lock script (ELS).

[0265] Statement 22. The method according to statements 2 and 21, wherein the first UF script is the first User-Directed Lock Script (UFLS).

[0266] Statement 23. The method according to any one of statements 1 through 20, wherein the first CS is the first compact unlock script (CLS) and the first ES is the first expansion unlock script (ELS).

[0267] Statement 24. The method according to statements 2 and 23, wherein the first UF script is the first User Unlock Script (UFLS).

[0268] Statement 25. A computer implementation method for verifying blockchain transactions, wherein the method is implemented by a node of a blockchain network, the node is configured to execute a script written in a high-level (HL) scripting language, the blockchain comprises a first blockchain transaction, the first blockchain transaction comprises a first output comprising a first compact lock script (CLS), the first CLS is at least partially written in an HL scripting language and comprises one or more HL functions, each HL function configured to perform an action equivalent to the action performed by one or more LL functions of a low-level (LL) scripting language when executed, the first CLS is written in an LL scripting language and is configured to perform an action equivalent to a first unfolding lock script (ELS) comprising multiple LL functions, the first CLS has a smaller storage size than the first ELS, and the method is implemented by a blockchain node. A step of obtaining a second blockchain transaction, wherein the second blockchain transaction comprises a first input having a first unlock script, The second step is to verify the blockchain transaction. The step of verifying a second blockchain transaction, comprising: The process includes a step of obtaining the first blockchain transaction, a) A step of replacing a first CLS with a first ELS, and then executing a first unlock script together with the first ELS, wherein the condition for a second transaction to be valid is that the execution is successful, or b) A computer implementation method comprising the step of executing a first unlock script together with a first CLS, wherein the condition for a second transaction to be valid is that the execution is successful.

[0269] The step of replacing the first CLS with an ES comprises converting (e.g., expanding) the first CLS into the first ES.

[0270] Statement 26. The method according to Statement 25, further comprising the steps of sending a second blockchain transaction to one or more other nodes of the blockchain network, and / or storing a first blockchain transaction in the node's memory, provided that the second blockchain transaction is valid.

[0271] Statement 27. The method according to Statement 25 or 26, wherein a second blockchain transaction is generated by a second party, and the step of obtaining a second blockchain transaction comprises the step of receiving a second blockchain transaction from a second party.

[0272] Statement 28. A method according to any one of statements 24 to 26, comprising the step of retrieving a first blockchain transaction from the node's memory.

[0273] Statement 29. The second blockchain transaction has a second output having a second CLS, the second CLS is written in the HL scripting language, and the second CLS is configured to perform the same operations as a second ELS written in the LL scripting language, the second CLS has a smaller storage size than the second ELS, and the step of verifying the second blockchain transaction is, The steps include obtaining a second candidate transaction identifier, A step of generating a modified version of the second blockchain transaction, wherein in this modified version of the second blockchain transaction, the second output comprises a second ES instead of a second CS, A step of generating a second transaction identifier, wherein the second transaction identifier is generated based on a modified version of the second blockchain transaction. A step of comparing a second candidate transaction identifier with a second transaction identifier, wherein the condition for a second blockchain transaction to be valid is that the second candidate transaction identifier matches the second transaction identifier. A method according to any one of statements 25 to 28, comprising:

[0274] Statement 30. The method according to Statement 29, further comprising the step of performing the comparison between a second candidate transaction identifier and a second transaction identifier before the step of executing the first unlock script together with a first CLS or a first ELS.

[0275] Statement 31. The HL scripting language is an intermediate-level (IL) scripting language between the user-facing (UF) scripting language and the LL scripting language, where HL functions are IL functions, and the function table comprises a list of function mappings, each function mapping comprising the respective IL functions mapped to one or more other IL functions and / or a set of one or more LL functions. a) The step of replacing the first CLS with the first ELS is based on a function mapping listed in the function table, or b) The method according to any one of statements 25 to 30, wherein the step of executing a first unlock script together with a first CLS is based on a function mapping listed in a function table.

[0276] Statement 32. A method according to either Statement 25 or any statement referencing Statement 25, wherein a function table comprises one or more function identifiers, each identifying a respective IL function, and a first CS comprises one or more first data pairs, each first data pair comprising a respective IL function identifier and a calling function, and is configured such that, when executed, the calling function executes one or more other IL functions and / or one or more LL functions mapped to the IL functions identified by their respective IL function identifiers.

[0277] Statement 33. The method according to Statement 31 or 32, wherein at least a portion of the function table is created by a first party, and the method comprises the step of receiving at least a portion of the function table from a first party.

[0278] Statement 34. A method of either Statement 31 or a statement that references the description of Statement 31, comprising the step of receiving different parts of a function table from different parties.

[0279] Statement 35. A method of either statement 31 or a statement that references the description of statement 31, comprising the step of creating at least a portion of a function table.

[0280] Statement 36. A method according to either statement 25 or any statement referencing statement 25, wherein a variable table comprises one or more variable identifiers and is configured to store variables associated with each variable identifier, and a first CS comprises one or more second data pairs, each second data pair comprising a respective variable identifier and either a read function or a write function, wherein when executed, the read function is configured to read a variable from the variable table stored associated with each variable identifier, and when executed, the write function is configured to write a variable generated during the execution of the first CS to the variable table for storage associated with each variable identifier.

[0281] Statement 37. A computer implementation method for verifying blockchain transactions, wherein the method is performed by a node of a blockchain network, and the node is configured to execute a script written in a high-level (HL) scripting language, and the method is performed by a blockchain node. A step of obtaining a first blockchain transaction, wherein the first blockchain transaction comprises an input that references the input of a previous blockchain transaction, the first blockchain transaction comprises a first compact script (CS), the first CS is written in an HL scripting language and comprises one or more HL functions, and when executed, each HL function is configured to perform an action equivalent to the action performed by one or more LL functions of a low-level (LL) scripting language, the first CS is written in an LL scripting language and is configured to perform an action equivalent to a first expansion script (ES) comprising multiple LL functions, and the first CS has a smaller storage size than the first ES, As part of the verification of the second blockchain transaction, The steps include obtaining a first candidate transaction identifier, A step of generating a modified version of a first blockchain transaction, wherein this modified version of the first blockchain transaction comprises a first ES instead of a first CS, A step of generating a first transaction identifier, wherein the first transaction identifier is generated based on a modified version of a first blockchain transaction. A step of comparing a first candidate transaction identifier with a first transaction identifier, wherein the condition for a first blockchain transaction to be valid is that the first candidate transaction identifier matches the first transaction identifier. A computer implementation method comprising the above.

[0282] Statement 38. The method of Statement 37, further comprising the step of proceeding to verify a first blockchain transaction in accordance with a blockchain protocol operated by a node, provided that a first candidate transaction identifier matches a first transaction identifier.

[0283] Statement 39. The method according to Statement 38, comprising the steps of sending a first blockchain transaction to one or more other nodes of the blockchain network and / or storing the first blockchain transaction in the node's memory, provided that the first blockchain transaction is valid in accordance with the blockchain protocol.

[0284] Statement 40. The steps include receiving a request for a first blockchain transaction from one or more nodes of a blockchain network that are not configured to execute scripts written in the HL scripting language, The steps include sending a modified version of the first blockchain transaction to one or more of those nodes and The method described in statement 39, comprising:

[0285] Statement 41. The method according to any one of statements 37 to 40, wherein the step of generating a modified version of the first blockchain transaction comprises the step of replacing the first CS with the first ES.

[0286] In other words, the first CS is transformed (i.e., expanded) into the first ES.

[0287] Statement 42. The method according to any one of Statements 37 to 41, wherein a first blockchain transaction is generated by a first party, and the step of obtaining a first blockchain transaction comprises the step of receiving a first blockchain transaction from a first party.

[0288] Statement 43. The method of Statement 42, wherein the step of obtaining a first candidate transaction identifier comprises the step of receiving a first candidate transaction identifier from a first party.

[0289] Statement 44. A computer implementation method for verifying blockchain transactions, wherein the method is performed by a node of a blockchain network, the node is configured to execute a script written in a high-level (HL) scripting language, the blockchain comprises a first blockchain transaction, the first blockchain transaction comprises a first output, and the method A step of obtaining a second blockchain transaction, wherein the second blockchain transaction comprises a first input comprising a first compact unlock script (CUS), the first CUS being at least partially written in an HL scripting language and comprising one or more HL functions, each HL function configured to perform an action equivalent to the action performed by one or more LL functions of a low-level (LL) scripting language when executed, the first CUS being written in an LL scripting language and configured to perform an action equivalent to a first expandable unlock script (EUS) comprising multiple LL functions, the first CUS having a smaller storage size than the first EUS, and The second step is to verify the blockchain transaction. The step of verifying a second blockchain transaction, comprising: The process includes a step of obtaining the first blockchain transaction, a) A step of replacing a first CUS with a first EUS, and then executing the first EUS with a first output, wherein the condition for a second transaction to be valid is that the execution is successful, or b) A step in which a first CUS is executed with a first output, wherein the condition for a second transaction to be valid is that the execution is successful. A computer implementation method comprising the above.

[0290] Statement 45. The HL scripting language is an intermediate-level (IL) scripting language between the user-facing (UF) scripting language and the LL scripting language, where HL functions are IL functions, and the function table comprises a list of function mappings, each function mapping comprises an IL function mapped to one or more other IL functions and / or a set of one or more LL functions. a) The step of replacing the first CUS with the first EUS is based on a function mapping listed in the function table, or b) The method of statement 44 wherein the step of performing a first CUS with a first output is based on a function mapping listed in a function table.

[0291] A function table may comprise one or more function identifiers, each identifying a respective IL function; a first CS comprises one or more first data pairs, each first data pair comprising a respective IL function identifier and a calling function, which, when executed, is configured to execute one or more other IL functions and / or one or more LL functions mapped to the IL functions identified by their respective IL function identifiers.

[0292] A variable table may comprise one or more variable identifiers and is configured to store variables associated with each variable identifier; a first CS comprises one or more second data pairs, each second data pair comprising a respective variable identifier and either a read function or a write function, wherein when executed, the read function is configured to read a variable from the variable table stored associated with each variable identifier; and when executed, the write function is configured to write variables generated during the execution of the first CS to the variable table for storage associated with each variable identifier.

[0293] Statement 46. A memory comprising one or more memory units, A processing apparatus comprising one or more processing units A computer device comprising a memory that stores code configured to be executed on a processing unit, and the code is configured to perform any one of the methods described in statements 1 to 24 when it is on the processing unit.

[0294] Statement 47. A computer program that is materialized on computer-readable storage and, when executed on one or more processors, is configured to perform a method described in any one of statements 1 through 24.

[0295] Statement 48. A memory comprising one or more memory units, A processing apparatus comprising one or more processing units A computer device comprising a memory that stores code configured to be executed on a processing unit, and the code is configured to perform any one of the methods described in statements 25 to 45 when it is on the processing unit.

[0296] Statement 49. A computer program that is materialized on computer-readable storage and, when executed on one or more processors, is configured to perform a method described in any one of statements 25 through 45.

[0297] According to another aspect disclosed herein, a method comprising the actions of a first party and a node may be provided.

[0298] In another aspect disclosed herein, a system comprising the computer equipment and nodes of the first party may be provided. [Explanation of Symbols]

[0299] 100 Systems 101 Packet-switched network 102 Computer equipment 102a Computing devices 102a Computer equipment 102b Computer equipment 103 Parties 103a User 103a Alice 103a First party 103b The second party 103b Bob 104 Bitcoin nodes 104 Blockchain Nodes 105 clients 105 Client Applications 106 Peer-to-peer (P2P) network 106 Blockchain Networks 107 Side Channel 150 Blockchains 151 data blocks 151 New Blocks 151n-1 block 152 transactions 152i Preceding Transactions 152j Current Transaction 153 Genesis Block (Gb) 154. Ordered sets (or "pools") 155 Block pointers 201 Header 202 inputs 202 Input Fields 203 Output 203 Output Fields 401 Transaction Engine 402 User Interface (UI) Layer 403 Function 450 node software 451 Protocol Engine 452-node scripting engine 453 stacks 454 Application Level Determination Engine 455 Blockchain-related functional modules 455 Functions 455C Consensus Module 455P propagation module 455S Memory Module 500 User Interfaces (UI) 500 Systems 501 UI elements 501 User-selectable elements 502 UI elements 502 Data Entry Fields 503 UI elements 503 Information Element < / cls> < / els>

Claims

1. A computer implementation method for generating blockchain transactions, which is performed by a first party, A step of generating a first blockchain transaction, wherein the first blockchain transaction comprises a first compact script (CS), the first CS being at least partially written in a high-level (HL) scripting language and comprising one or more HL functions, each HL function configured to perform an operation equivalent to that performed by one or more LL functions of a low-level (LL) scripting language when executed, the first CS being configured to perform an operation equivalent to that of a first expansion script (ES), the first ES being written in the LL scripting language and comprising a plurality of LL functions, and the first CS having a smaller storage size than the first ES, The steps include making the first blockchain transaction available to one or more nodes and / or a second party of the blockchain network, and A computer implementation method comprising the above.

2. The method according to claim 1, wherein the HL scripting language is an intermediate-level (IL) scripting language between a user-facing (UF) scripting language and the LL scripting language, and the HL function is an IL function.

3. The step of generating the first blockchain transaction is, A step of generating a first UF script (UFS), wherein the first UFS is at least partially written in the UF scripting language and comprises one or more UF functions, and when executed, each UF function is configured to perform an operation equivalent to the operation performed by one or more IL functions. The steps of converting the first UFS to the first CS and The method according to claim 2, comprising:

4. The method according to claim 3, wherein the function table comprises a list of function mappings, each function mapping comprises an IL function mapped to one or more other IL functions and / or a set of one or more LL functions, and the step of converting from the first UFS to the first CS is based on the function mappings listed in the function table.

5. The method according to claim 4, wherein the function table comprises one or more function identifiers, each identifying a respective IL function, and the first CS comprises one or more first data pairs, each first data pair comprising a respective IL function identifier and a calling function, and when executed, the calling function is configured to execute the set of one or more other IL functions and / or one or more LL functions mapped to the IL functions identified by the respective IL function identifiers.

6. The method according to claim 5, wherein at least a portion of the function table is created by the first party, and the method comprises the step of making the at least portion of the function table available to one or more nodes of the blockchain network and / or the second party.

7. The method according to any one of claims 4 to 6, wherein at least a portion of the function table is created by a party other than the first party, and the method comprises the step of obtaining the at least portion of the function table.

8. The method according to claim 7, wherein at least a portion of the function table is created by a blockchain node, and the step of obtaining the function table comprises the step of receiving at least a portion of the function table from the blockchain node.

9. The method according to any one of claims 3 to 8, wherein a variable table comprises one or more variable identifiers and is configured to store variables associated with each variable identifier, the first CS comprises one or more second data pairs, each second data pair comprising a respective variable identifier and either a read function or a write function, wherein when executed, the read function is configured to read a variable from the variable table stored associated with each of the respective variable identifiers, and when executed, the write function is configured to write a variable generated during the execution of the first CS to the variable table for storage associated with each of the respective variable identifiers.

10. A step of generating a first transaction identifier, wherein the first transaction identifier is generated based on a modified version of the first blockchain transaction, and this modified version of the first blockchain transaction comprises the first ES instead of the first CS, The steps include making the transaction identifier available to one or more nodes of the blockchain network. The method according to any one of claims 1 to 9, comprising:

11. The step of generating the first transaction identifier is, The steps of generating the first blockchain transaction and A step of replacing the first CS with the first ES in order to generate the modified version of the first blockchain transaction for generating the first transaction identifier, The method according to claim 10, comprising:

12. The method according to claim 11, further comprising the step of replacing the first ES with the first CS before the step of making the first blockchain transaction available to one or more nodes of the blockchain network.

13. The step of generating the first blockchain transaction is, The steps include generating the modified version of the first blockchain transaction, The steps include: generating the first blockchain transaction by replacing the first ES with the first CS; The method according to claim 11, comprising:

14. The method according to any one of claims 10 to 13, wherein the first blockchain transaction, together with the first transaction identifier, becomes available to one or more nodes of the blockchain network.

15. The method according to claim 11, wherein the first blockchain transaction comprises a first input, the first input comprising a signature generated based on the modified version of the first blockchain transaction.

16. The aforementioned first blockchain transaction includes the following fields: The version number of the first blockchain transaction, The lock time for the first blockchain transaction described above, One or more inputs of the aforementioned first blockchain transaction, One or more inputs of the first blockchain transaction that does not include an unlock script, One or more outputs of the first blockchain transaction, each having its own CS The method according to any one of claims 1 to 15, comprising a secondary transaction identifier based on one or more of the following.

17. The method according to claim 11 or 12, wherein the modified version of the first blockchain transaction underlying the signature comprises an output having a secondary transaction identifier.

18. The method according to any one of claims 1 to 17, further comprising the step of enabling one or more blockchain client applications to take advantage of the first blockchain transaction.

19. The method according to any one of claims 1 to 18, further comprising the step of storing the first blockchain transaction in the memory of a computing device operated by the first party.

20. The method according to any one of claims 1 to 19, wherein the operation performed by at least one of the HL functions is equivalent to the operation performed by a plurality of the LL functions.

21. The method according to any one of claims 1 to 20, wherein the first CS is a first compact lock script (CLS) and the first ES is a first unfolding lock script (ELS).

22. The method according to claim 2 or 21, wherein the first UF script is a first user-facing lock script (UFLS).

23. The method according to any one of claims 1 to 20, wherein the first CS is a first compact unlock script (CLS) and the first ES is a first unfold unlock script (ELS).

24. The method according to claim 2 or 23, wherein the first UF script is a first user unlock script (UFLS).

25. A computer implementation method, A computer implementation method for verifying blockchain transactions, wherein the method is executed by a node in a blockchain network, the node is configured to execute a script written in a high-level (HL) scripting language, the blockchain comprises a first blockchain transaction, the first blockchain transaction comprises a first output comprising a first compact lock script (CLS), the first CLS is at least partially written in the HL scripting language and comprises one or more HL functions, each HL function configured to perform an operation equivalent to the operation performed by one or more LL functions of a low-level (LL) scripting language when executed, the first CLS is configured to perform an operation equivalent to a first decompression lock script (ELS), the first ELS is written in the LL scripting language and comprises a plurality of LL functions, the first CLS has a smaller storage size than the first ELS, and the method is executed by a blockchain node. A step of obtaining a second blockchain transaction, wherein the second blockchain transaction comprises a first input having a first unlock script, The second step of verifying the blockchain transaction described above and The step of verifying the second blockchain transaction includes, The process includes the step of obtaining the aforementioned first blockchain transaction, a) A step of replacing the first CLS with the first ELS, and then executing the first unlock script together with the first ELS, wherein the condition for the second transaction to be valid is that the execution is successful, or b) A computer implementation method comprising the step of executing the first unlock script together with the first CLS, wherein the condition for the second transaction to be valid is that the execution is successful.

26. The method according to claim 25, further comprising the steps of transmitting the second blockchain transaction to one or more other nodes of the blockchain network, and / or storing the first blockchain transaction in the memory of the node, provided that the second blockchain transaction is valid.

27. The method according to claim 25 or 26, wherein the second blockchain transaction is generated by a second party, and the step of obtaining the second blockchain transaction comprises the step of receiving the second blockchain transaction from the second party.

28. The method according to any one of claims 24 to 26, further comprising the step of obtaining the first blockchain transaction from the memory of the node.

29. The second blockchain transaction has a second output comprising a second CLS, the second CLS is written in the HL scripting language, the second CLS is configured to perform the same operations as a second ELS written in the LL scripting language, the second CLS has a smaller storage size than the second ELS, and the step of verifying the second blockchain transaction is: The steps include obtaining a second candidate transaction identifier, A step of generating a modified version of the second blockchain transaction, wherein in this modified version of the second blockchain transaction, the second output comprises the second ES instead of the second CS, A step of generating a second transaction identifier, wherein the second transaction identifier is generated based on the modified version of the second blockchain transaction, A step of comparing the aforementioned second candidate transaction identifier with the aforementioned second transaction identifier, wherein the condition for the aforementioned second blockchain transaction to be valid is that the aforementioned second candidate transaction identifier matches the aforementioned second transaction identifier. The method according to any one of claims 25 to 28, comprising:

30. The method according to claim 29, further comprising the step of performing the comparison between the second candidate transaction identifier and the second transaction identifier before the step of performing the first unlock script together with the first CLS or the first ELS.

31. The HL scripting language is an intermediate-level (IL) scripting language between the user-facing (UF) scripting language and the LL scripting language, the HL functions are IL functions, the function table comprises a list of function mappings, each function mapping comprises an IL function mapped to one or more other IL functions and / or a set of one or more LL functions. a) The step of replacing the first CLS with the first ELS is based on the function mapping listed in the function table, or b) The method according to any one of claims 25 to 30, wherein the step of executing the first unlock script together with the first CLS is based on the function mapping listed in the function table.

32. The method according to any one of claims 25 to 31, wherein a function table comprises one or more function identifiers, each identifying a respective IL function, and the first CS comprises one or more first data pairs, each first data pair comprising a respective IL function identifier and a calling function, and when executed, the calling function is configured to execute one or more other IL functions and / or the one or more LL functions mapped to the IL functions identified by the respective IL function identifiers.

33. The method according to claim 31 or 32, wherein at least a portion of the function table is created by a first party, and the method comprises the step of receiving the at least portion of the function table from the first party.

34. The method according to any one of claims 31 to 33, comprising the step of receiving different portions of the function table from different parties.

35. The method according to claim 31 or any one of claims 31 to 34, comprising the step of creating at least a portion of the function table.

36. The method according to any one of claims 25 to 35, wherein a variable table comprises one or more variable identifiers and is configured to store variables associated with each variable identifier, the first CS comprises one or more second data pairs, each second data pair comprising a respective variable identifier and either a read function or a write function, wherein when executed, the read function is configured to read a variable from the variable table stored associated with each of the respective variable identifiers, and when executed, the write function is configured to write a variable generated during the execution of the first CS to the variable table for storage associated with each of the respective variable identifiers.

37. A computer implementation method for verifying blockchain transactions, wherein the method is executed by a node of a blockchain network, the node is configured to execute a script written in a high-level (HL) scripting language, and the method is executed by a blockchain node. A step of obtaining a first blockchain transaction, wherein the first blockchain transaction comprises an input that references the input of a previous blockchain transaction, the first blockchain transaction comprises a first compact script (CS), the first CS is written in the HL scripting language and comprises one or more HL functions, each HL function configured to perform an operation equivalent to the operation performed by one or more LL functions of the low-level (LL) scripting language when executed, the first CS is configured to perform an operation equivalent to a first expansion script (ES), the first ES is written in the LL scripting language and comprises a plurality of LL functions, and the first CS has a smaller storage size than the first ES, As part of the verification of the second blockchain transaction, The steps include obtaining a first candidate transaction identifier, A step of generating a modified version of the first blockchain transaction, wherein this modified version of the first blockchain transaction comprises the first ES instead of the first CS, A step of generating a first transaction identifier, wherein the first transaction identifier is generated based on the modified version of the first blockchain transaction, A step of comparing the first candidate transaction identifier with the first transaction identifier, wherein the condition for the first blockchain transaction to be valid is that the first candidate transaction identifier matches the first transaction identifier. A computer implementation method comprising the above.

38. The method according to claim 37, further comprising the step of proceeding with verification of the first blockchain transaction in accordance with a blockchain protocol operated by the node, provided that the first candidate transaction identifier matches the first transaction identifier.

39. The method according to claim 38, further comprising the steps of transmitting the first blockchain transaction to one or more other nodes of the blockchain network and / or storing the first blockchain transaction in the memory of the node, provided that the first blockchain transaction is valid in accordance with the blockchain protocol.

40. The steps include receiving a request for the first blockchain transaction from one or more nodes of the blockchain network that are not configured to execute a script written in the HL scripting language, The steps include sending the modified version of the first blockchain transaction to one or more of those nodes. The method according to claim 39, comprising:

41. The method according to any one of claims 37 to 40, wherein the step of generating the modified version of the first blockchain transaction comprises the step of replacing the first CS with the first ES.

42. The method according to any one of claims 37 to 41, wherein the first blockchain transaction is generated by a first party, and the step of obtaining the first blockchain transaction comprises the step of receiving the first blockchain transaction from the first party.

43. The method according to claim 42, wherein the step of obtaining the first candidate transaction identifier comprises the step of receiving the first candidate transaction identifier from the first party.

44. A computer implementation method for verifying blockchain transactions, wherein the method is executed by a node of a blockchain network, the node is configured to execute a script written in a high-level (HL) scripting language, the blockchain comprises a first blockchain transaction, the first blockchain transaction comprises a first output, and the method A step of obtaining a second blockchain transaction, wherein the second blockchain transaction comprises a first input comprising a first compact unlock script (CUS), the first CUS being at least partially written in the HL scripting language and comprising one or more HL functions, each HL function configured to perform an operation equivalent to that performed by one or more LL functions of a low-level (LL) scripting language when executed, the first CUS being configured to perform an operation equivalent to that of a first expandable unlock script (EUS), the first EUS being written in the LL scripting language and comprising multiple LL functions, and the first CUS having a smaller storage size than the first EUS, The second step of verifying the blockchain transaction described above and The step of verifying the second blockchain transaction includes, The process includes the step of obtaining the aforementioned first blockchain transaction, a) A step of replacing the first CUS with the first EUS, and then executing the first EUS with the first output, wherein the condition for the second transaction to be valid is that the execution is successful, or b) A step of executing the first CUS together with the first output, wherein the condition for the second transaction to be valid is that the execution is successful. A computer implementation method comprising the above.

45. The HL scripting language is an intermediate-level (IL) scripting language between the user-facing (UF) scripting language and the LL scripting language, the HL functions are IL functions, the function table comprises a list of function mappings, each function mapping comprises an IL function mapped to one or more other IL functions and / or a set of one or more LL functions. a) The step of replacing the first CUS with the first EUS is based on the function mapping listed in the function table, or b) The method of claim 44, wherein the step of performing the first CUS with the first output is based on the function mapping listed in the function table.

46. A memory comprising one or more memory units, A processing apparatus comprising one or more processing units A computer device comprising, wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to any one of claims 1 to 24 when it is on the processing device.

47. A computer program, which is embodied on computer-readable storage and, when executed on one or more processors, is configured to perform the method described in any one of claims 1 to 24.

48. A memory comprising one or more memory units, A processing apparatus comprising one or more processing units A computer device comprising, wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to any one of claims 25 to 45 when it is on the processing device.

49. A computer program, which is embodied on computer-readable storage and, when executed on one or more processors, is configured to perform the method described in any one of claims 25 to 45.

Images