Versioning transactions

Abstract

A computer-implemented method of handling a blockchain transaction, where the method is performed by a transaction handler and includes: obtaining a first script from a first blockchain transaction, where the first script includes a version opcode; obtaining a second script from a second block chain transaction, wherein the second block chain transaction comprises a version value; and executing the first script together with the second script, where the execution includes executing the version opcode, and where the execution of the version opcode includes outputting the version value of the second blockchain transaction.

Description

Technical Field

[0001] This disclosure relates to a method for generating and validating blockchain transactions based on versions of spent transactions. Furthermore, it allows for the spending (also translated as expenditure, i.e., allocation or transfer) of outputs in multiple ways. Background Technology

[0002] Some blockchain transactions contain four fields: version number, lock time value, input list, and output list. The serialized byte format of these fields (called the raw format) is used to publish the transaction and broadcast it among network peers. The raw format is then hashed (sha256(sha256(...)...)... raw data A transaction ID is created. Once a transaction is signed, the version number and lock time value cannot be changed. Depending on the chosen sighash flags, the input and output lists may or may not change.

[0003] The version number is a 4-byte field that typically indicates the consensus rules applicable to some blockchain transactions. In some blockchains, a transaction is usually version 1, but transaction version 2 is associated with OP_CHECKSEQUENCEVERIFY support.

[0004] Historically, OP_VER and its associated opcodes OP_VERIF and OP_VERNOTIF were defined as instructions that allowed transactions to be verified in different ways, depending on the blockchain node evaluating them. According to this definition, nodes in a blockchain network would view and verify transactions, for example, using OP_VERIF to select a branch in a locking script, which depended on the version of the node software being executed. In this implementation, OP_VER reads the node protocol version number from a local file (which was previously...). serialize.h The value is converted to a 4-byte number and pushed onto the stack. In addition to pushing the value onto the stack, OP_VERIF and OP_VERNOTIF also compare the value with another value previously pushed onto the stack and push the evaluation result (True or False). Figure 3 Examples are shown of how nodes in a blockchain network would interpret transactions using OP_VERIF according to this definition. When a transaction is published to the blockchain network, each node evaluates the transaction based on its node software version, and only nodes using version 2 accept the transaction.

[0005] These version-specific opcodes are not currently enabled in some blockchain verification engines. Summary of the Invention

[0006] Blockchain transactions were initially used primarily for exchanging value between two or more parties. As blockchain-based applications have expanded, transactions are now used in a wide range of use cases, such as tokenization, authentication, or tracking. For more advanced use cases, when a transaction is created, it is not always obvious when and who will spend it. This introduces additional complexity in transaction creation and can potentially limit some of these use cases.

[0007] According to one aspect disclosed herein, a computer-implemented method for processing blockchain transactions is provided, wherein the method is performed by a transaction processor and includes: obtaining a first script from a first blockchain transaction, wherein the first script includes version opcodes; obtaining a second script from a second blockchain transaction, the second blockchain transaction referencing the first blockchain transaction, wherein the second blockchain transaction includes a version value; and executing the first script together with the second script, wherein the execution includes executing the version opcodes, and wherein executing the version opcodes includes: outputting the version value of the second blockchain transaction.

[0008] According to one aspect disclosed herein, a computer-implemented method for generating blockchain transactions is provided, wherein the method is performed by a first party and includes: generating a first blockchain transaction, the first blockchain transaction including a first script, wherein the first script includes one or more corresponding version opcodes, wherein each corresponding version opcode is configured to, when executed during execution of the first script together with a second script referencing the first blockchain transaction, cause the output of a version value of the second blockchain transaction; and causing the first blockchain transaction to be sent to one or more nodes of a blockchain network, or to be sent to one or more nodes of a blockchain network.

[0009] According to one aspect disclosed herein, a computer implementation method for generating blockchain transactions is provided, wherein the blockchain includes a first blockchain transaction, the first blockchain transaction including a first script, wherein the first script includes one or more corresponding version opcodes, wherein each corresponding version opcode is configured to, when executed during execution of the first script together with a second script referencing the first blockchain transaction, cause a version value of the second blockchain transaction to be output, wherein the method is performed by a second party, and the method includes: generating a second blockchain transaction, the second blockchain transaction including a version value, wherein the second blockchain references the first blockchain transaction and includes a second script to be executed together with the first script of the first blockchain transaction; and causing the second blockchain transaction to be sent to one or more nodes of a blockchain network, or sending it to one or more nodes of a blockchain network.

[0010] According to one aspect disclosed herein, a computer implementation method for facilitating the processing of blockchain transactions is provided, wherein the method is performed by a third party and includes: maintaining a registry, wherein the registry includes a plurality of corresponding version values, each corresponding version value being mapped to a corresponding application and / or a corresponding multicast address.

[0011] As used herein, a second blockchain transaction that references the first blockchain transaction means that the input of the second blockchain transaction (including the second script) references the output of the first blockchain transaction (including the first script).

[0012] This paper discloses a technique for creating "versioned transactions" based on the existing opcode OP_VER, which is currently disabled. This technique improves the flexibility of transaction locking scripts, allowing unlocking in multiple ways depending on the transaction version. The technique is based on a new interpretation of OP_VER and its associated opcodes. OP_VER pushes a version number (e.g., 4 bytes) to the blockchain node script engine. In this implementation, the version number refers to the version of the transaction that spends the output of OP_VER. The version value is included in the spending transaction but is not part of the unlocking script for that spending transaction. Versioned transactions are more flexible because they can be spent in multiple ways, each separated by an OP_VER statement. In other words, users can spend versioned transactions based on different sets of rules that can be selected by specifying the transaction version at the time of spending (i.e., not at the creation time). Furthermore, versioned transactions can be used to efficiently filter transactions and prevent UTXO merging (i.e., keeping two transaction streams separate). This technique can also be used in conjunction with IP multicast addresses to create efficient overlay networks.

[0013] For simplicity, the version opcode is referred to as "OP_VER" herein. However, this disclosure is not limited to opcodes with this specific label, or blockchain protocols utilizing opcodes with this specific label. More generally, while embodiments will be described according to the blockchain scripting language "OP_VER", the same embodiments can be implemented using any opcode that, when called by a script engine (or script interpreter), executes the specific function described herein performed by OP_VER, which causes a transaction processor to obtain and output the transaction version value of the spent transaction. The version opcode may cause the transaction processor to perform one or more additional actions. The version value may take any suitable form, such as numbers, strings, alphanumeric characters, byte sequences, etc.

[0014] Typically, blockchain protocols use scripting languages ​​for transaction processing. A script is essentially a list of elements, which can be data or instructions. These instructions are referred to in the literature as script words, opcodes, commands, or functions. These terms are used interchangeably in this document. An opcode (short for operation code) performs a predefined operation on the data in the script. Attached Figure Description

[0015] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which: Figure 1 This is a schematic block diagram of a system for implementing blockchain. Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain; Figure 3 The diagram illustrates a transaction that spends a locking script containing OP_VER, wherein when the transaction is published to the blockchain network, each node evaluates the transaction according to its software version, and only nodes of version 2 accept the transaction; Figure 4 The illustration schematically depicts a transaction that spends a locking script containing OP_VER (i.e., a versioned transaction), where when the transaction is published to the blockchain network, each node evaluates the transaction according to its version, and all nodes accept the transaction because the transaction version is 2; Figure 5 An example of an application-specific transaction using OP_VER is illustrated, which is spent, broadcast to the blockchain network, and then multicast to the application user; Figure 6 It is a schematic block diagram of some node software used to process transactions. Detailed Implementation

[0016] 1. Versioned transactions The embodiments of this disclosure utilize "version opcodes" to influence the processing of blockchain transactions, which means that transactions are processed according to the transaction version (or simply version) of the transaction.

[0017] Figure 1An exemplary system for implementing the described embodiments is shown. Alice 103a is configured to generate a first transaction having a first script including version opcodes. The first script may be a locking script, which is part of the output of the first transaction. Alice 103a submits the first transaction to blockchain network 106, or to a third party for submission to blockchain network 106. Bob 103b is configured to generate a second transaction having a second script. The second script may be an unlocking script, which is part of the input of the second transaction. The second transaction, for example, uses the transaction identifier of the first transaction to refer to the first transaction. For example, the input of the second transaction may, for example, use the transaction identifier of the first transaction and the output index of the output of the first transaction to refer to the output of the first transaction. The second transaction has a "version field" containing a transaction version number. The transaction version number may be a 4-byte number. The version number may have different sizes depending on the blockchain protocol. Bob 103b submits the first transaction to blockchain network 106, or to a third party for submission to blockchain network 106.

[0018] The transaction processor (e.g., blockchain node 104) is configured to obtain the first and second transactions directly from Alice 103a and / or Bob 103b, from (different) blockchain node 104, or from blockchain 150.

[0019] The transaction processor extracts a first script from a first transaction, a second script from a second transaction, and executes the first script along with the second script. When executing a version opcode from the first script, the transaction processor is configured to obtain (e.g., extract) a transaction version number from the second transaction and output the transaction version number, for example, to memory. The memory can be a stack-based memory. In other words, the version opcode is configured to cause the transaction processor to output the transaction version number. That is, the blockchain protocol can specify that when a version opcode is invoked, the transaction processor will extract and output the transaction version number. Other options for outputting the transaction version number include sending the transaction version number to Alice 103a and / or Bob 103b or a third party, or publishing the transaction version number on blockchain 150 or other publicly accessible resources.

[0020] In some examples, Alice 103a may include a first number as part of a first script. When executing the version opcode of the first script, the transaction processor can be configured to verify that the first number is the same as the transaction version number. Further execution of the first script and / or the second script may depend on the first number matching the transaction version number. For example, the first number and / or the version opcode may be associated with a subscript that can only execute if the first number matches the transaction version number. Any suitable association can be implemented. For example, the subscript may simply follow (or precede) the version opcode.

[0021] Alternatively, when executing the version opcode from the first script, the transaction processor can be configured to verify that the first number is the same as the transaction version number. Further execution of the first and / or second scripts can depend on the first number not being the same as the transaction version number. For example, the first number and / or version opcode can be associated with a subscript that can only execute if the first number does not match the transaction version number.

[0022] Using version opcodes in this way allows the output of a transaction (i.e., allocation, transfer, etc.) to be spent, depending on the version number of the transaction being spent.

[0023] In some examples, one type of version opcode (e.g., OP_VER) might only cause the transaction processor to output the transaction version number, while another type of version opcode (e.g., OP_VERIF or OP_VERNOTIF) might cause the transaction processor to perform the aforementioned verification.

[0024] In some examples, Alice 103a may include multiple version opcodes. One or more version opcodes can simply cause the transaction processor to output a transaction version number. Additionally or alternatively, one or more version opcodes may be associated with corresponding numbers (e.g., a second number associated with a second version opcode, a third number associated with a third version opcode, etc.), and cause the transaction processor to verify whether the transaction version number matches or does not match the corresponding number. As mentioned above, each version opcode may be associated with a subscript that executes only based on the result of the verification. In some examples, each of the corresponding numbers is a different number.

[0025] A transaction processor can process a second transaction as part of verifying the second transaction. Therefore, the verification of the second transaction depends on its version number. If the transaction processor determines that the second transaction is valid after executing the first and second scripts, the transaction processor can publish (or at least attempt to publish) block 151 to the blockchain 150 containing the second transaction. Additionally or alternatively, the transaction processor can send the second transaction to one or more third parties. For example, the transaction processor can propagate the second transaction to one or more blockchain nodes 104.

[0026] In some examples, a registry (also translated as a register, i.e., a table, list, etc.) can be maintained to map transaction version numbers to applications, i.e., mapping to a first number for a first application, a second number for a second application, and so on. Version numbers can be mapped to one or more of the following: the application name, the application identifier, the application owner, and the public key associated with the application. In these examples, the transaction processor can determine whether a second transaction was generated by a party associated with the application and accept (e.g., verify) the transaction only if the second transaction was generated by said party. This determination can be based on whether the second transaction includes a signature corresponding to the public key associated with said party (e.g., the public key mapped to the version number in the registry). The registry can be maintained by one or more blockchain nodes 104 (e.g., the transaction processor). Alternatively, the registry can be maintained by a third party (e.g., a trusted service provider). The third party can provide the registry to the transaction processor, for example, by publishing the registry and / or sending the registry to the transaction processor.

[0027] In some examples, transaction version numbers can be mapped to (i.e., linked to) multicast addresses. Transaction processors can broadcast second transactions to multicast addresses. This mapping of version numbers to multicast addresses can be maintained in the registry (e.g., the same registry as the mapping of version numbers to applications).

[0028] Although the embodiments have been described with respect to Alice 103a generating a first transaction and Bob 103b generating a second transaction, both Alice 103a and Bob 103b can generally be configured to generate a first transaction and / or a second transaction.

[0029] It should be noted that unless the context requires it, "first," "second," etc., are used only as labels and do not necessarily imply a specific order.

[0030] 1.1 Redefining OP_VER To date, the OP_VER opcode has never been formally implemented, but it has been described as an opcode that requires the script engine to read the node protocol version number from a local file and push it onto the stack. In this paper, OP_VER is redefined such that "version" refers to the version of the transaction that spends the UTXO, which includes OP_VER in its locking script. Following this logic, OP_VER can be used to create transactions that can be spent in a variety of predefined ways. The version selected is specified when spending the transaction by choosing a specific transaction version.

[0031] In this scenario, OP_VER does not push the node software version onto the stack; instead, it pushes the transaction version of the cost transaction (e.g., ...). transaction.nVersion While previous interpretations of OP_VER were vulnerable to attacks and could potentially lead to blockchain forks, this new definition is less susceptible to similar attacks. The transaction version is chosen by the user spending the transaction and signed along with other transaction fields. Therefore, all nodes 104 executing the script to verify the transaction obtain the same result. This is because the version is read from the spending transaction, not the node software (node ​​104 can run different software versions), and the version field of the spending transaction cannot be changed once signed.

[0032] The definition of OP_VER and its related opcodes OP_VERIF and OP_VERNOTIF will support transactions that can be spent for a variety of use cases, thereby optimizing transaction management through transaction versioning. Figure 4 An example is shown of how nodes in network 106 would interpret versioned transactions according to this definition. When a transaction is published to network 106, each node 104 evaluates the transaction based on its version; since the transaction version is 2, all nodes 104 accept the transaction.

[0033] From a technical perspective, OP_VER can typically be used to create branches within a locked script. The pseudocode for such a locked script is as follows: OP_FALSE (False if there is no branch to execute) <version 1> OP_VERIF <Locking script 1> OP_ENDIF <version 2> OP_VERIF <Locking script 2> OP_ENDIF … <version n > OP_VERIF <Locking scriptn > OP_ENDIF User 103 can satisfy one of the branches ( <Locking script x The conditions in >) and specify the branch to be selected in the transaction version ( x The lock script must be spent using the specified branch within the transaction version of the transaction being spent. For example, the unlock script for branch 2 must specify transaction version 2 to spend the lock script. Possible valid unlock scripts for the above lock script are: Transaction version (specified in the header): 2 Unlock script:<Unlocking script 2> .

[0034] If a branch requires unlocking a digital signature, the user 103 who signed the transaction explicitly commits to the specific branch, and this commitment is publicly visible to everyone. This can be used to enable new use cases that require user 103 to commit to a specific version or a specific version indicating meaningful content.

[0035] OP_VERIF and OP_VERNOTIF behave similarly: OP_VERIF is equivalent to OP_VER OP_EQUALOP_IF, while OP_VERNOTIF is equivalent to OP_VER OP_EQUAL OP_NOTIF.

[0036] 1.2 Transaction Interpretation and Filtering `OP_VER` allows locking scripts to force their spending transactions to have a specific version number or version number from a given set. When a transaction is serialized, the version number is located at the beginning of the serialization. It allows users to interpret transactions without fully resolving them. For example, version 1 represents Alice 103a, and version 2 represents Bob 103b. Given a valid transaction (after checking its Merkle proof), simply reading the version number at the beginning determines who spent the transaction. This provides a more efficient way to interpret transactions than using any other type of flag within the transaction. `OP_VER` can also be used to filter transactions.

[0037] 1.3 Preventing UTXO merging Another observation is that if Alice 103a sends an output to Charlie using a locking script with version 1 that forces its spending transaction to do so, and Bob 103b sends an output to Charlie using a locking script with version 2 that forces its spending transaction to do so, Charlie will not be able to spend both outputs in a single transaction. This example illustrates the mechanism provided by OP_VER for forcing the spending of outputs in different transactions. This mechanism is powerful because it can be used to prevent the chaining of two or more transactions.

[0038] In the context of horizontal scaling and parallelized transaction verification, independent verification provides a natural way to shard transactions with zero communication overhead between shards. Application providers requiring fast transaction verification are incentivized to enforce isolation of their transactions from other transaction chains by using OP_VER.

[0039] 1.4 Transaction Version Control As mentioned above, using OP_VER in the locking script means that transactions can now be versioned. This makes it possible to create transactions that can be spent in multiple ways (i.e., according to different rules). Applications may require the ability to spend transactions for different use cases and / or different users. They can create versioned transactions and associate versions with each use case or user. Each use case has different rules, which are specified in different branches of the locking script using OP_VER or one of the related codes. Consumers commit specific use cases by selecting a relative transaction version. Depending on the use case, different rules (defined in the locking script) are applied.

[0040] Versioned transactions can also be used in simple use cases where only one possible version is accepted. This is useful when an entity (e.g., a software company) wants its users to spend transactions using a specific transaction version. In this case, the software company can create a versioned transaction with only one OP_VERIF branch and hand it over to users for software-related use. This is useful for classifying and filtering transactions (e.g., transactions with different versions). 123 All transactions are software xyz (Part of it). Because the version number appears at the beginning of the serialized transaction, it can be identified quickly and easily, enabling efficient identification of related transactions.

[0041] 1.5 Mapping The transaction version field is typically 4 bytes, meaning that each application can map a maximum of 2. 32 (4,294,967,296) use cases. In reality, different applications can reuse the same transaction version. In other words, the version number must be unique only within the same application or application ecosystem.

[0042] One way to resolve version conflicts (i.e., two applications using the same transaction version) is to have a global organization (or a group of organizations) use a shared registry to assign version numbers, similar to what IANA (the global harmonization of DNS root, IP addressing, and other Internet Protocol resources) does for IP addresses. This registry is called the Transaction Version Register (TVR). The TVR allows for the reservation of transaction versions for specific applications or use cases: versioned transactions using versions reserved in the TVR are only verified and inserted into blocks when created by an entity that has approved and associated with that version in the shared registry.

[0043] Blockchain node 104 needs to maintain or at least access the TVR. This is a requirement because only they can enforce the rules. If a specific version of a transaction is maintained for the application and that version is agreed upon in the TVR, only transactions generated within that application are considered valid. This means that even if the script engine indicates that the script is officially valid, versioned transactions created by other parties will be automatically considered invalid.

[0044] In several ways, such as by recording a public key in the TVR that can be used to sign transactions, it is possible to link transaction versions to applications authorized in the TVR. If a versioned transaction does not contain a signature created by one of the public keys specified in the shared registry, the transaction will be automatically considered invalid. Alternatively, the authorizing party may require an explicit way to identify the transaction in the TVR (e.g., using PKI).

[0045] Hybrid approaches are also possible, where some transaction versions are reserved for relevant applications (e.g., government or banking applications), while other transaction versions can be used freely for other applications (e.g., private applications).

[0046] 1.7 Using via multicast OP_VER can be linked to an IP multicast address to create an overlay network for a specific application. The overlay network is used to optimize network traffic in the blockchain network 106 (e.g., transaction broadcasting): applications only receive the portion of traffic relevant to their use. This approach significantly reduces the required bandwidth and hardware, thereby improving the scalability of the entire ecosystem.

[0047] Network traffic can be segmented using IP multicast addresses: a multicast address is linked to an application, and all users of that service send and receive transactions through that multicast address. Only blockchain nodes must listen to all multicast addresses to verify transactions. Nodes can send SPV proofs to the application's multicast address to notify relevant parties that a transaction has been published.

[0048] Multicast addresses can be linked to transaction versions. When a transaction is spent with a specified version, it can be broadcast to interested groups. Versioned transactions may belong to different overlay networks at creation time. When spent, a specific overlay network identifies the transaction using the specified version, and the spent transaction is only broadcast to the associated multicast address. Specialized overlay networks only receive transactions with the relevant transaction version, thus significantly reducing network traffic (transmitted transactions). For other multicast overlay networks, node 104 listens on all multicast addresses to verify and publish transactions.

[0049] As mentioned in the previous section, the transaction version field is typically 4 bytes, which means it can map up to 2... 32 (4294967296) IP multicast addresses. Since transaction versions are now linked to multicast addresses, reusing transaction versions for different applications is no longer acceptable. This is because transactions with a specific version are now sent to the multicast address belonging to the application. Therefore, in this case, a shared registry (e.g., TVR) or an equivalent registry may be necessary. This shared registry can be used to assign version numbers to applications, and the same registry can be extended to map version numbers to IP multicast addresses. For example, the association could be: ● The multicast address is linked to the application in an encrypted manner; or ● Third-party allocation of multicast addresses.

[0050] 1.8 Exemplary Use Cases 1.8.1 Bank Banks can use a shared registry to maintain multicast addresses and transaction versions. For example, using a script like the following, they can force all payments to be versioned transactions starting from the maintained transaction version: <bank code> OP_VERIF < locking script > OP_ELSE OP_0 OP_ENDIF.

[0051] <bank code> It may also include a country code to reflect a similar code used for bank transfers.

[0052] Bank users wishing to transfer funds must create a transaction with a specified bank code. The same locking script structure must be enforced across all bank-related transactions (e.g., the banking application might do this automatically). When a bank-related transaction is published, network node 104 sends an SPV certificate to the linked IP multicast address. This creates a bank overlay network in which all bank branches receive notification of each operation.

[0053] 1.8.2 Train Token A travel company issues train tokens valid for multiple train companies. Each company has an associated 4-byte code and a linked IP multicast address. The travel company uses blockchain transactions to issue train tokens. The train token transaction includes a locking script where each authorized company has < train company code >OP_VERIF. Users can purchase train tokens without having to choose which train company they want to use immediately.

[0054] When a user wants to use a train token, they go to a station and spend a transaction, specifying the train company code in the transaction version. Blockchain node 104 publishes the train token transaction and sends an SPV proof to an IP multicast address linked to the train company code. All stations operated by the train company subscribe to the same multicast address and are therefore notified. The station with the valid token retains a copy of the transaction, enabling passage through the arrival station's turnaround gate. It should be noted that this technique is used to enable travel on a selected route, not to send payment (since tickets are prepaid).

[0055] In another configuration, users can pre-claim tickets by creating a transaction, specifying a train company code, and sending a signed transaction to the train company's server. The train company demonstrates acceptance of the train token by publishing the train token transaction to the blockchain and sending confirmation to the user (e.g., in the form of a ticket token transaction). Using the linked multicast address, all relevant parties are aware of the current status of the ticket.

[0056] In both configurations, only the train companies that are interested are involved. The process is transparent to other companies that do not receive any unnecessary transactions.

[0057] 1.8.3 Token Tokens can be issued based on versioned transactions (e.g., central bank digital currency (CBDC) tokens). Versioned transactions linked to multicast addresses can create more efficient communities of token holders. By encoding specific spending conditions or actions that depend on token versions, tokens can be more easily managed and exchanged.

[0058] 1.8.4 Metanet Metanet branches can be created using versioned transactions. Metanet nodes can be created based on different conditions, representing different users or use cases. Users can filter the Metanet tree using the transaction version of a branch.

[0059] 2. Exemplary System Overview A blockchain is a distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely publicized. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Apart from the so-called "coinbase transaction," each transaction points to a previous transaction in a sequence that can span one or more blocks and return to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating new blocks is often called "mining," which involves each of the multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on a defined, ordered, and verified set of pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of a block can be achieved by publishing only the block header.

[0060] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing timestamped entries; and / or sorting index pointers by time. Additional layered functionalities on the blockchain can also be implemented. For example, blockchain protocols can allow the storage of additional user data or data indexes within transactions. There is no pre-specified limit to the maximum data capacity that can be stored in a single transaction, thus allowing increasingly complex data to be incorporated. For example, this can be used to store electronic documents, audio, or video data in the blockchain.

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

[0062] In this model, when a second (target) transaction is sent to the blockchain network for propagation and recording, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the conditions defined in one or more of the locking script of the first transaction. Another condition will be that the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid based on any of these conditions will not propagate the transaction (as a valid transaction, but possibly registering it as invalid) nor include it in a new block to be recorded in the blockchain.

[0063] Another transaction model is the account-based model. In this case, the amount of each transaction is not defined by referring to the UTXO of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes and is continuously updated.

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

[0065] Each blockchain node 104 includes peer computer devices, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, dedicated processors, and / or field-programmable gate arrays (FPGAs), as well as other devices, such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable memory in the form of non-transitory computer-readable media. The memory may include one or more memory cells that employ one or more memory media, such as magnetic media like hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0066] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Rather, blockchain 150 can be pruned as long as each blockchain node 150 stores the block header of each block 151 (discussed below). Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a specific transaction protocol throughout.

[0067] Blockchain node 104 can be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Blockchain node 104 can be configured to create block 151 and store a corresponding copy of the same blockchain 150 in its corresponding memory. Blockchain node 104 can also maintain 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 a “mempool.” In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of transactions that node 104 has accepted as valid, and for that set of transactions, node 104 is forced not to accept any other transactions attempting to spend the same output.

[0068] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring financial assets, although this is certainly a common application. More generally, spending can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when the current transaction 152j is created or even sent to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

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

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

[0071] Any given blockchain node can be configured to perform one or more of the following operations: verifying transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node can be specialized for a particular operation. For example, node 104 can focus on transaction verification and propagation, or it can focus on block mining. In some examples, blockchain node 104 can perform more than one of these operations in parallel. Any reference to blockchain node 104 can refer to the entity configured to perform at least one of these operations.

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

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

[0074] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0076] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the respondent 103 to create, authorize (e.g., sign) transactions 152 and send them to one or more blockchain nodes 104, where they are then propagated through the network of blockchain nodes 104 and included in blockchain 150. The other function is to report to the respondent the amount of digital assets they currently possess. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across blockchain 150.

[0077] Note: While various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented in a suite of two or more different applications, such as through an API interface or as a plugin for one application. More colloquially, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

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

[0079] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the network's nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0080] Some account-based transaction models share similarities with the output-based transaction model described in this paper. For example, as mentioned above, the data fields of an account-based transaction can point to the previous transaction, which is equivalent to the input of an output-based transaction referencing the output point of the previous transaction. Therefore, both models support chaining between transactions. As another example, an account-based transaction includes a "recipient" field (specifying the account's receiving address) and a "value" field (specifying a certain amount of digital assets). The recipient and value fields together are equivalent to the output of an output-based transaction, which can be used to allocate a certain amount of digital assets to a blockchain address. Similarly, account-based transactions have a "signature" field, which includes the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes the transaction's signature. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine if the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contract" refers to a transaction containing a script configured to perform one or more actions (e.g., sending or "releasing" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions. Therefore, in some examples, a smart contract can be viewed as equivalent to a locking script for an output-based transaction (which can be triggered by a subsequent transaction) that checks whether the inputs of the subsequent transaction satisfy one or more conditions defined in the locking script.

[0081] 3. UTXO-based model Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments. It should be noted that while an exemplary UTXO-based protocol has been described, it can also be implemented on other example blockchain networks.

[0082] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO may also contain the transaction ID of its source transaction, as well as other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this 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 original transaction 152 committed to node 104.

[0083] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the middle, Alice's New Affairs 152j is marked as " Tx 1 The new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In the middle, the previous transaction 152i is marked as " Tx 0 ". Tx 0 and Tx 1 It is just an arbitrary marker, which does not necessarily mean Tx 0 The first transaction in Blockchain 151 and Tx 1 Subsequent transactions in pool 154. Tx 1 It can point to any previous (i.e. preceding) transaction that still has an unspent output 203 locked to Alice.

[0084] As used in the context of transaction sequences in this article, the terms "previous" and "subsequent" refer to the order of transactions in the sequence defined by the transaction pointers specified within the transaction (which transaction points to which other transaction, etc.). They can also be replaced with "predecessor" and "successor," "ancestor" and "descendant," or "parent" and "child," etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") that point to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. Children that arrive at blockchain node 104 before their parent are considered orphaned. Depending on the node protocol and / or node behavior, they may be discarded or buffered for a period of time to wait for their parent.

[0085] Previous matters Tx 0 One or more outputs 203 include a specific UTXO, tagged as UTXO 0 Each UTXO includes a value representing the amount of digital assets and a locking script that defines the conditions that the unlocking script in input 202 of a subsequent transaction must meet to make the subsequent transaction valid and thus successfully redeem the UTXO.

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

[0087] Therefore, in the example shown, Tx 0 Output 203 UTXO 0 Including the locking script [Checksig] P A This locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for the purpose of enabling those who attempt to redeem) UTXO 0 (Subsequent transactions are valid). [Checksig P A Contains the public key from Alice's public-private key pair. PA The representation of (i.e., hash). Tx 1 Input 202 includes pointers to Tx 1 pointers (e.g., via their transaction IDs) TxID 0 In the implementation example, this refers to the entire transaction. Tx 0 (hash value). Tx 1 Input 202 includes Tx 0 Chinese logo UTXO 0 The index, in order to Tx 0 It is identified in any other possible output. Tx 1 Input 202 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0088] When new transactions Tx 1 Upon reaching blockchain node 104, the node applies the node protocol. This includes running the locking and unlocking scripts together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria).

[0089] It should be noted that script code is typically represented graphically (i.e., using a non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For instance, OP_RETURN is a scripting language opcode. When OP_FALSE is added before the opcode at the beginning of the locking script, the opcode creates a non-spendable output for the transaction. This output can store data within the transaction, thus immutably recording the data in the blockchain. For example, the data may include files that need to be stored in the blockchain.

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

[0091] Locking scripts are sometimes called "scriptPubKey," referring to the fact that they typically include the public keys of the parties to whom the corresponding transaction is locked. Unlocking scripts are sometimes called "scriptSig," referring to the fact that they typically provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0092] 4. Node software Figure 6 An example of node software 450 running on each blockchain node 104 of network 106 is shown, in examples of UTXO-based or output-based models. It should be noted that another entity can run node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required by node 104. Node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 104 may run node software containing one or more of the following: a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). Consensus module 455C may include a verification module (not shown) configured to verify transactions according to the blockchain protocol. The verification module may also be separate from consensus module 455C. One or more of these modules may operate in parallel. Node 104 may include additional modules. Protocol engine 401 is typically configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a field pointing to another previous transaction 152i is received... Tx m-1 The input of transaction 152j is the output (e.g., UTXO) of the transaction. Tx j When ), the protocol engine 451 identifier Tx j The unlock script is then passed to script engine 452. Protocol engine 451 is also based on... Tx j Pointers in the input are used to identify and retrieve. Tx i . Tx i It can be published on blockchain 150, in which case the protocol engine can retrieve it from the copy of block 151 of blockchain 150 stored at node 104. Tx i .or, Tx i It can also be published on blockchain 150. In this case, protocol engine 451 can retrieve it from the unpublished ordered transaction set 154 maintained by node 104. Tx i Regardless of the method used, script engine 451 will identify... Tx i The locked script is referenced in the output and passed to the script engine 452.

[0093] Therefore, script engine 452 has Tx i The locking script and from Tx j The corresponding input unlock script. For example, in Figure 2 The transaction marker is shown in the image. Tx 0 and Tx 1 However, the same transaction can be applied to any transaction pair. As mentioned earlier, script engine 452 runs two scripts together, which will include placing data onto stack 453 and retrieving data from stack 453 according to the stack-based scripting language used (e.g., script).

[0094] By running the scripts simultaneously, the script engine 452 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 452 returns this determination to the protocol engine 451. If the script engine 452 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0095] In the output-based model, the result "TRUE" from script engine 452 is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by protocol engine 451 must also be met; for example, Tx j The total amount of digital assets specified in the input does not exceed the total amount pointed to in its output, and Tx iThe output pointed to by the transaction has not yet been spent by another valid transaction. Protocol engine 451 evaluates the results from script engine 452 along with one or more protocol-level conditions, and only verifies the transaction if all of them are TRUE. Tx j Valid. Protocol engine 451 outputs an indication of whether the transaction is valid to application-level decision engine 454. Only when... Tx j Under truly effective conditions, the decision engine 454 can choose to simultaneously control the consensus module 455C and the propagation module 455P to execute its intended purpose. Tx j The corresponding blockchain-related functions. This includes consensus module 455C, which adds to the corresponding ordered transaction set 154 of the nodes. Tx j , used to be incorporated into block 151; and propagation module 455P, to Tx j The transaction is forwarded to another blockchain node 104 in network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may only choose to publish a transaction if it is valid and sufficient transaction fees are reserved.

[0096] Furthermore, it should be noted that in this paper, the terms "TRUE" and "FALSE" are not necessarily limited to returning a result represented only as a single binary number (bit), although this is indeed one possible implementation. More colloquially, "TRUE" can refer to any state indicating a successful or affirmative result, while "FALSE" can refer to any state indicating an unsuccessful or uncertain result. For example, in an account-based model, a combination of implicit protocol-level verification of the signature and an additional affirmative output from the smart contract can indicate a result of "TRUE" (the overall result is considered TRUE if both individual results are TRUE).

[0097] 5. Further comments Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.

[0098] It should be understood that the above description can generally be applied to any blockchain.

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

[0100] In other embodiments of the invention, it is not excluded that a node may perform at least one or more, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, on these 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 these blocks 151 to other nodes.

[0101] To put it even more simply, any reference above to the term "blockchain node" 104 can be replaced by the terms "network entity" or "network element," wherein such an entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element can be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0102] Some embodiments have been described based on a blockchain network used to implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is merely one type of consensus mechanism, and in general embodiments, any suitable consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is typically called a validator. Blockchain nodes can lock their tokens for a period of time to have the opportunity to become a validator. Generally, the node that locks the largest amount of tokens for the longest time is most likely to become the next validator.

[0103] It should be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided based on any one or more of the following statements.

[0104] Statement 1. A computer-implemented method for processing blockchain transactions, wherein the method is performed by a transaction processor and includes: Obtain a first script from a first blockchain transaction, wherein the first script includes a version opcode; Obtain a second script from a second blockchain transaction, wherein the second blockchain transaction includes a version value; and, The first script is executed together with the second script, wherein the execution includes executing the version opcode, and wherein executing the version opcode includes outputting the version value of the second blockchain transaction.

[0105] Statement 2. The method described in statement 1, wherein the output includes: outputting the version value to a stack-based memory.

[0106] Statement 3. The method according to statement 1 or 2, wherein the first script includes a first value, and wherein executing the version opcode includes: verifying whether the first value matches the version value.

[0107] Statement 4. The method according to statement 3, wherein the version opcode is associated with a first sub-script of the first script, and wherein executing the version opcode includes executing the first sub-script only if the first value matches the version value.

[0108] Statement 5. The method according to statement 1 or 2, wherein the first script includes a first value, and wherein executing the version opcode includes: verifying whether the first value does not match the version value.

[0109] Statement 6. The method according to statement 5, wherein the version opcode is associated with a first subscript of the first script, wherein executing the version opcode includes: executing the first subscript only if the first value does not match the version value.

[0110] Statement 7. The method according to any of the preceding statements, wherein the first script includes a plurality of corresponding version values, each version value being associated with a corresponding version opcode, and wherein each corresponding version opcode is associated with a corresponding subscript.

[0111] Statement 8. The method according to any of the preceding statements, the method comprising: determining whether the second blockchain transaction is a valid transaction based on the execution of the first script together with the second script.

[0112] Statement 9. The method according to statement 8, the method comprising: upon determining that the second blockchain transaction is a valid transaction, processing a block including the second blockchain transaction, and / or forwarding the second blockchain transaction to one or more parties.

[0113] Statement 10. The method according to any of the preceding statements, wherein the transaction processor includes a blockchain node.

[0114] Statement 11. The method according to any one of statements 8 to 10, wherein a first registry is maintained, wherein corresponding version values ​​are mapped to corresponding applications; and wherein determining whether the second blockchain transaction is a valid transaction comprises: determining, based on the registry, whether the second blockchain transaction has been generated by a party associated with the application (mapped to the version value of the second blockchain transaction).

[0115] Statement 12. The method according to statement 11, the method comprising: maintaining the first registry.

[0116] Statement 13. The method according to any of the preceding statements, wherein the version value of the second blockchain transaction is linked to a multicast address, and wherein the method includes: sending the second blockchain transaction to the multicast address.

[0117] Statement 14. The method according to Statement 13, wherein a second registry is maintained, wherein corresponding version values ​​are mapped to corresponding multicast addresses; and wherein sending the second blockchain transaction to the multicast address comprises: looking up the multicast address in the second registry using the version number of the second blockchain transaction.

[0118] Statement 15. A computer-implemented method for generating blockchain transactions, wherein the method is performed by a first party and includes: Generate a first blockchain transaction, the first blockchain transaction including a first script, wherein the first script includes one or more corresponding version opcodes, wherein each corresponding version opcode is configured to, when executed during the execution of the first script together with a second script of a second blockchain transaction, cause the output of a version value of the second blockchain transaction; and, Send the first blockchain transaction to, or cause the first blockchain transaction to be sent to, one or more nodes in the blockchain network.

[0119] Statement 16. The method according to statement 15, wherein one or more of the plurality of version opcodes are associated with a corresponding value, and wherein the one or more corresponding version opcodes are configured to, when executed, verify whether the corresponding value matches the version value.

[0120] Statement 17. The method according to statement 16, wherein one or more of the plurality of version opcodes are associated with a corresponding subscript of the first script, and wherein the one or more corresponding version opcodes are configured to, when executed, execute the corresponding subscript only if the corresponding value matches the version value.

[0121] Statement 18. The method according to statement 15, wherein one or more of the plurality of version opcodes are associated with a corresponding value, and wherein the one or more corresponding version opcodes are configured to, when executed, verify whether the corresponding value does not match the version value.

[0122] Statement 19. The method according to statement 18, wherein one or more of the plurality of version opcodes are associated with a corresponding subscript of the first script, and wherein the one or more corresponding version opcodes are configured to, when executed, execute the corresponding subscript only if the corresponding value does not match the version value.

[0123] Statement 20. A computer-implemented method for generating blockchain transactions, wherein the blockchain includes a first blockchain transaction, the first blockchain transaction including a first script, wherein the first script includes one or more corresponding version opcodes, wherein each corresponding version opcode is configured to, when executed during the execution of the first script together with a second script of a second blockchain transaction, cause the output of a version value of the second blockchain transaction, wherein the method is performed by a second party, and the method includes: Generate a second blockchain transaction, the second blockchain transaction including a version value, wherein the second blockchain references the first blockchain transaction, and includes a second script to be executed together with the first script of the first blockchain transaction; and, Send the second blockchain transaction to, or cause the second blockchain transaction to be sent to, one or more nodes in the blockchain network.

[0124] Statement 21. A method for facilitating the processing of blockchain transactions using a computer implementation, wherein the method is performed by a third party and includes: Maintain a registry, wherein the registry includes multiple corresponding version values, each corresponding version value being mapped to a corresponding application and / or a corresponding multicast address.

[0125] Statement 22. The method according to statement 21, the method comprising: providing the registry to one or more transaction processors.

[0126] Statement 23. A computer device, said computer device comprising: The memory, comprising one or more memory cells; and, A processing apparatus comprising one or more processing units, wherein the memory stores code set to run on the processing apparatus, the code being configured to execute, when run on the processing apparatus, a method according to any one of statements 1 to 22.

[0127] Statement 24. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of statements 1 to 22 when run on one or more processors.

[0128] According to another aspect disclosed herein, a method may be provided that includes some or all of the actions of the transaction processor, the first party, the second party, and the third party. According to another aspect disclosed herein, a system may be provided that includes some or all of the computer equipment of the transaction processor, the first party, the second party, and the third party.

Claims

1. A computer-implemented method for processing blockchain transactions, wherein the method is performed by a transaction processor and includes: Obtain a first script from a first blockchain transaction, wherein the first script includes a version opcode; A second script is obtained from a second blockchain transaction that references the first blockchain transaction, wherein the second blockchain transaction includes a version value; and The first script is executed together with the second script, wherein the execution includes executing the version opcode, and wherein executing the version opcode includes outputting the version value of the second blockchain transaction.

2. The method according to claim 1, wherein the output includes: The version value is output to a stack-based memory.

3. The method according to claim 1 or 2, wherein the first script includes a first value, and wherein the execution of the version opcode includes: Verify whether the first value matches the version value.

4. The method of claim 3, wherein the version opcode is associated with a first sub-script of the first script, and wherein executing the version opcode comprises: The first sub-script is executed only if the first value matches the version value.

5. The method according to claim 1 or 2, wherein the first script includes a first value, and wherein the execution of the version opcode includes: Verify whether the first value does not match the version value.

6. The method of claim 5, wherein the version opcode is associated with a first sub-script of the first script, wherein executing the version opcode includes: The first sub-script is executed only if the first value does not match the version value.

7. The method according to any one of the preceding claims, wherein the first script comprises a plurality of corresponding version values, each version value being associated with a corresponding version opcode, and wherein each corresponding version opcode is associated with a corresponding subscript.

8. The method according to any one of the preceding claims, wherein the method comprises: Based on the execution of the first script together with the second script, it is determined whether the second blockchain transaction is a valid transaction.

9. The method according to claim 8, wherein the method comprises: When the second blockchain transaction is determined to be a valid transaction, the block containing the second blockchain transaction is processed, and / or the second blockchain transaction is forwarded to one or more parties.

10. The method according to any one of the preceding claims, wherein the transaction processor includes a blockchain node.

11. The method according to any one of claims 8 to 10, wherein, A first registry is maintained to map corresponding version values ​​to corresponding applications; and wherein determining whether the second blockchain transaction is a valid transaction includes: based on the registry, determining whether a party associated with the application mapped to the version value of the second blockchain transaction has generated the second blockchain transaction.

12. The method according to claim 11, wherein the method comprises: Maintain the first registry.

13. The method according to any one of the preceding claims, wherein the version value of the second blockchain transaction is linked to a multicast address, and wherein the method comprises: The second blockchain transaction is sent to the multicast address.

14. The method according to claim 13, wherein, A second registry is maintained to map corresponding version values ​​to corresponding multicast addresses; and wherein sending the second blockchain transaction to the multicast address includes: looking up the multicast address in the second registry using the version number of the second blockchain transaction.

15. A computer-implemented method for generating blockchain transactions, wherein the method is performed by a first party and includes: A first blockchain transaction is generated, the first blockchain transaction including a first script, wherein the first script includes one or more corresponding version opcodes, wherein each corresponding version opcode is configured to cause the version value of the second blockchain transaction to be output when the first script is executed together with a second script of a second blockchain transaction referencing the first blockchain transaction; as well as Send the first blockchain transaction to, or cause the first blockchain transaction to be sent to, one or more nodes in the blockchain network.

16. The method of claim 15, wherein one or more of the plurality of version opcodes are associated with a corresponding value, and wherein the one or more corresponding version opcodes are configured to verify, when executed, whether the corresponding value matches the version value.

17. The method of claim 16, wherein one or more of the plurality of version opcodes are associated with a corresponding subscript of the first script, and wherein the one or more corresponding version opcodes are configured to execute the corresponding subscript only when the corresponding value matches the version value upon execution.

18. The method of claim 15, wherein one or more of the plurality of version opcodes are associated with a corresponding value, and wherein the one or more corresponding version opcodes are configured to, when executed, verify whether the corresponding value does not match the version value.

19. The method of claim 18, wherein one or more of the plurality of version opcodes are associated with a corresponding subscript of the first script, and wherein the one or more corresponding version opcodes are configured to execute the corresponding subscript only when the corresponding value does not match the version value.

20. A computer-implemented method for generating blockchain transactions, wherein the blockchain includes a first blockchain transaction, the first blockchain transaction including a first script, wherein the first script includes one or more corresponding version opcodes, wherein each corresponding version opcode is configured to, when executed during the execution of the first script together with a second script referencing the first blockchain transaction, cause the output of a version value of the second blockchain transaction, wherein... The method is performed by a second party, and the method includes: Generate a second blockchain transaction, the second blockchain transaction including a version value, wherein the second blockchain references the first blockchain transaction, and includes a second script to be executed together with the first script of the first blockchain transaction; and Send the second blockchain transaction to, or cause the second blockchain transaction to be sent to, one or more nodes in the blockchain network.

21. A method for facilitating the processing of blockchain transactions using a computer implementation, wherein the method is performed by a third party and includes: Maintain a registry, wherein the registry includes multiple corresponding version values, each corresponding version value being mapped to a corresponding application and / or a corresponding multicast address.

22. The method according to claim 21, wherein the method comprises: The registry is provided to one or more transaction processors.

23. A computer device, the computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 22 when run on the processing apparatus.

24. A computer program, the computer program being contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 22 when executed on one or more processors.

Images