Determining system status using block

Abstract

A computer-implemented method for determining a state of a system using one or more blockchain transactions, where each blockchain transaction comprises one or more outputs, and where the method is performed by a first party and comprises: determining a respective state of one or more respective outputs of the one or more blockchain transactions; and determining the state of the system based on the respective states of the one or more respective outputs.

Description

Technical Field

[0001] This disclosure relates to a method of using blockchain to determine the state of a system, and in some embodiments, to use blockchain to influence the state of a system. Background Technology

[0002] In output-based blockchain models (such as Bitcoin) (sometimes called UTXO-based models), the data structure for a given transaction 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 sequence of transactions in progress. Spendable outputs are sometimes called UTXOs (“unspent transaction outputs”). Outputs may also include locking scripts that specify the future redemption conditions of the output. Locking scripts are predicates that define the conditions necessary to verify and transfer digital tokens or assets. Summary of the Invention

[0003] According to one aspect disclosed herein, a computer-implemented method is provided for determining the state of a system using one or more blockchain transactions, wherein each blockchain transaction includes one or more outputs, and wherein the method is performed by a first party and includes: determining a corresponding state of one or more corresponding outputs of the one or more blockchain transactions; and determining the state of the system based on the corresponding state of the one or more corresponding outputs.

[0004] Bitcoin was invented not only for electronic cash (“currency”) but also for information (“bits”). This disclosure literally utilizes the “bit” information from the Bitcoin system (and other UTXO-based blockchains). More specifically, a set of UTXOs can be used as a source of this information, where the state of each transaction output point represents a single bit (0 or 1), depending on whether the output point is in the UTXO set.

[0005] Some embodiments use the spending (also translated as expenditure) status of blockchain transaction outputs to represent binary values, and use multiple said binary values ​​to represent binary strings, wherein said binary values ​​or said binary strings are interpreted as the state of the system. Some embodiments allow the state of the system to be changed by spending transaction outputs. Some embodiments use public keys to represent values ​​that can be interpreted according to pre-agreed policies or rules, and use the status of the corresponding transaction outputs to indicate whether said value is up-to-date.

[0006] Generally, embodiments of this disclosure utilize (e.g., a public) blockchain as a single source of information about the system's state, which can be accessed anytime, anywhere. Furthermore, by recording state transitions and the entities responsible for those transitions on the blockchain, an immutable system log is provided for auditing, data analysis, or investigations.

[0007] Some embodiments can be used to perform validity checks on systems (e.g., systems in identity management systems and access control systems). In some embodiments, the system has a non-binary state, and therefore multiple output points can be used to represent the state of the system. That is, n output points can be used to reflect any of the 2^n states of the system.

[0008] As an illustrative use case, vending machines can be authorized to change their inventory status. Anyone can monitor the inventory of these vending machines from the blockchain. For example, if a student knows that the vending machine downstairs has their favorite snacks in stock, they can choose to simply leave their dorm room; the snack provider can monitor the inventory levels on the blockchain and replenish as needed; the administrator can monitor the sales of different flavors and adjust the supply as required. All data is in one location and can be accessed anytime, anywhere in the world.

[0009] The implementation can also be used to manage IoT devices, for example, to view and control the status of said devices. Users can monitor the blockchain to control home appliances, such as washing machines or ovens.

[0010] As another example, the implementation can be used as part of an aircraft takeoff procedure. Each UTXO in the UTXO list can be associated with a task to be completed. When the task is completed, the UTXO is spent, and the aircraft can only take off when each UTXO has been spent. Attached Figure Description

[0011] 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:

[0012] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0013] Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain;

[0014] Figure 3 An exemplary system for using blockchain to determine the state of a system is illustrated schematically. Detailed Implementation

[0015] 1. Status determined

[0016] Figure 3An exemplary system 300 is shown that can be used to determine and influence the state of system 301 using blockchain 150. The exemplary system 300 includes a first party and a second party. For convenience, the first party is referred to as Alice 103a and the second party as Bob 103b; however, typically, each of the first and second parties operates a corresponding computing device 102 and can be configured to perform actions as described in the following references. Figure 1 and Figure 2 Any action described that is performed by Alice 103a and / or Bob 103b.

[0017] System 301 can take any form. It can be a physical system composed of one or more physical components (e.g., computing devices). As an illustrative example, system 301 may include physical entry components, such as doors, gates, barriers, etc. System 301 may include user identification components, such as physical ID cards, fingerprint scanners, retinal scanners, etc. System 301 can be a virtual system with which Alice 103a and / or Bob 103b can interact. System 301 may include both physical and virtual components.

[0018] like Figure 3 As shown, each of Alice 103a, Bob 103b, and system 301 itself can interact with blockchain 150. This can include sending one or more transactions to blockchain node 104 of blockchain network 106 for recording on blockchain 150. Additionally or alternatively, this can include, for example, retrieving data from blockchain 150 via one or more blockchain nodes 104.

[0019] In some embodiments, system 301 is associated with one or more UTXOs. The state of these one or more UTXOs represents the state of system 301. One or more of these UTXOs may be controlled by Alice 103a and / or Bob 103b, for example, some controlled by Alice 103a and some by Bob 103b. One or more of these UTXOs may be arbitrarily selected, for example, to introduce randomness into system 301. In some examples, the UTXOs associated with system 301 are those that include a specific public key or a public key from a specific set of public keys.

[0020] Alice 103a can determine the state of system 301 based on UTXOs. That is, Alice 103a determines the corresponding state (i.e., spent or unspent) of one or more UTXOs associated with system 301. Then, the state of system 301 is determined based on the corresponding state of one or more UTXOs.

[0021] In some examples, Alice 103a maps the state of each UTXO to a value. Each UTXO can be in (i.e., have, be associated with, etc.) a first state (e.g., spent) or a second state (e.g., unspent). Each output in the first state is assigned a value (e.g., 1), and each output in the second state is assigned a different value (e.g., 0). Alice 103a can then determine the state of system 301 based on the values ​​mapped to the UTXOs. As a specific example, Alice 103a can generate a binary string based on these values, where the binary string determines the state of system 301. For example, each UTXO can be mapped to a position in the string, e.g., the first UTXO is mapped to the first position in the string, the second UTXO is mapped to the second position in the string, and so on. Therefore, the corresponding state of a particular UTXO determines the bit at the corresponding position in the string.

[0022] In some examples, Alice 103a can determine the state of system 301 at the first moment, and then determine the state of the system at one or more future times.

[0023] In the example where Alice 103a controls one or more of these UTXOs, Alice 103a can change the state of system 301 by spending (or consuming) one or more UTXOs. System 301 can perform an action in response to the spending of one or more UTXOs.

[0024] In some embodiments, system 301 is associated with one or more UTXOs, each UTXO including a public key (or its hash). Each public key is associated with a state. Alice 103a determines the state of the system based on the state associated with each public key. As in the embodiments described above, one or more of these UTXOs may be controlled by Alice 103a and / or Bob 103b.

[0025] Alice 103a can determine the state of system 301 based on both one or more public keys and the state of one or more outputs including one or more public keys. That is, Alice 103a determines the corresponding state (i.e., spent or unspent) of one or more UTXOs associated with system 301. Each UTXO can have a first state (e.g., unspent) or a second state (e.g., spent). If a UTXO has a first state, Alice 103a determines that the public key included in that UTXO represents the current state. Conversely, if a UTXO has a second state, Alice 103a determines that the public key included in that UTXO does not represent the current state. Alice 103a can determine the state of system 301 based on the public key representing the current state of system 301.

[0026] Alice 103a can identify the transaction (“spending transaction”) referencing the UTXO in response to determining that the UTXO has a second state (e.g., spent). The state of system 301 is then determined at least in part based on one or more UTXOs of the spending transaction. More specifically, the state of system 301 is determined based on one or more corresponding public keys included in one or more corresponding outputs of the spending transaction. This process can be repeated for each UTXO having a second state.

[0027] When a corresponding UTXO is referenced by a corresponding spending transaction, Alice 103a can verify that the spending transaction contains a signature associated with the public key of the UTXO. Alice 103a may choose to determine the state of system 301 only if the spending transaction does indeed contain a valid signature.

[0028] It should be noted that one or more public keys from subsequent UTXOs (i.e., UTXOs discovered in a spending transaction) may be the same as one or more public keys from previous UTXOs, and therefore represent the same state. This allows the state (or at least part of the state) of system 301 to revert to a previous state.

[0029] System 301 may have an initial (i.e., start) state. Alice 103a may determine the initial state of system 301 by identifying an "initial transaction" and determining that initial state based on one or more corresponding states, or more precisely, one or more outputs, represented by one or more public keys included in the initial transaction. Alice 103a may identify the initial transaction based on its transaction identifier or based on a specific public key included in the initial transaction. That is, the transaction identifier or public key may be known to be associated with the initial transaction. The public key may be included in the input or output of the initial transaction.

[0030] Similarly, Alice 103a can determine the final state of system 301 by identifying a “final transaction” and determining that final state based on one or more corresponding states, or more precisely, one or more outputs, represented by one or more public keys included in the initial transaction. In some examples, the final transaction includes public keys known to be associated with the final state of system 301.

[0031] As described in the embodiments above, Alice 103a can map each public key (or the state represented by that public key) to a value and generate a string (e.g., a binary string) based on these values. The state of system 301 can be determined based on this string.

[0032] Alice 103a and / or Bob 103b can change the state of System 301 by altering the state of one or more outputs of one or more transactions associated with System 301 (e.g., by spending an output with a public key representing the state of System 301). This may involve generating a signature using a private key corresponding to that public key.

[0033] In some embodiments, system 301 may have an initial state represented by one or more "initial public keys". That is, each initial public key represents at least a portion of the state of system 301. Alice 103a determines the initial state of system 301 based on the initial public keys. For example, each initial public key may be mapped to a value, and one or more values ​​mapped to one or more initial public keys may form a string (e.g., a binary string). This string may represent the state of system 301. In these embodiments, blockchain 150 includes one or more outputs, each of which includes a corresponding initial public key. These outputs may be locked to the initial public key. These outputs may be distributed across multiple initial transactions (e.g., one per transaction) or all included in a single initial transaction. In some examples, one or more outputs are controlled by Alice 103a and / or Bob 103b.

[0034] Alice 103a identifies one or more final transactions. Each final transaction includes a corresponding reference to a corresponding output of an initial transaction; for example, each final transaction includes at least one corresponding input that consumes a corresponding output of the initial transaction. A final transaction may include multiple references to multiple corresponding outputs of the same initial transaction or different initial transactions. Each final transaction includes at least one output containing a final public key, for example, the output may be locked to that final public key. Each final public key represents at least a portion of the state of system 301. Alice 103a determines the final state of system 301 based on the final public key. For example, each final public key may be mapped to a value, and one or more values ​​mapped to one or more final public keys may form a string (e.g., a binary string). This string may represent the final state of system 301. One or more final transactions can be identified by recognizing a transaction having at least one signature corresponding to at least one of the initial public keys. Alice 103a and / or Bob 103b may be responsible for creating one or more final transactions and thus changing the state of system 301.

[0035] Alice 103a may wait until each of the outputs of one or more initial transactions has been spent by the corresponding input of one or more final transactions before determining the final state of system 301. Alternatively, Alice 103a may determine the final state after a predetermined period of time (e.g., starting from one or more initial transactions recorded on the blockchain, or starting from a specific point in time) or at a predetermined time (e.g., on a specific date).

[0036] In some examples, Alice 103a can determine the final state of the system based on certain final public keys in the final public key set (e.g., those public keys belonging to a predetermined set of public keys). That is, the state of system 301 is only allowed to be changed when a specific public key is used (e.g., those public keys representing a specific state).

[0037] 1.1 Blockchain as a Binary Encoder

[0038] This section provides further illustrative examples of the embodiments described above. It should be understood that some features are optional and not required in all embodiments.

[0039] 1.1 One-way state

[0040] In this example, the system's state is mapped to a binary string. Each bit of this string is represented by a transaction output. The spending status of this output (i.e., whether it's in the UTXO set) indicates the value of that bit. Locking scripts in each output can be used to implement access control. Locking scripts and their unlocking scripts can be used to provide authenticity. Typically, any UTXO can be used. In some examples, UTXOs controlled by a specific party are used, where the ability to spend a UTXO implies the ability to control the system. For example, the system could include one or more lights in a building, where only the occupants of the building can turn these lights on and off.

[0041] For example, a system with four states can be represented by two transaction outputs: TXID0||0 and TXID0||1. When neither is spent, the state is "11". By spending TXID0||0 or TXID0||1, the state changes to "01" or "10" respectively. By spending both outputs, the state becomes "00". Since spent outputs cannot be spent again, "00" will be the final state of the system.

[0042] Another exemplary use case is a two-factor authentication system, or a two-party authentication system for accessing the system. The initial state is "11," indicating the system is locked to the user. Once one factor or party passes authentication (spending one output), the state changes to "01" or "10," indicating the system is partially unlocked. When the other factor or party passes authentication (spending another output), the state changes to "00," indicating the system is fully unlocked. (A lawyer observes the state changing to "00" and begins following a series of instructions from the client.)

[0043] 1.1.2 Bidirectional State

[0044] In the previous example, when "1" was changed to "0", it could not be changed back. To address this limitation in certain use cases, a public key can be used in addition to the transaction's expenditure status. Assuming a public key... The authorization to change the i-th position of a string from "0" to "1" applies similarly to... It has the authority to change from "1" to "0". Authenticated private public key PK init It can be used to initialize the system state, and another private public key PK fin This is used to indicate that state changes are no longer permitted. This can be illustrated using the following four transactions as examples.

[0045]

[0046] Transaction TXID0 initializes the state of the four-state system to "11". To read or verify the state, follow these guidelines.

[0047] 1. Unlock the public key PK in the script init This means that the state is being initialized. There is no need to read the previous state.

[0048] 2. Both public keys in the lock script indicate the value "1".

[0049] 3. Neither transaction output was costly. Therefore, we can conclude that the current state is "11".

[0050]

[0051] Transaction TXID1 changes the first bit from "1" to "0", resulting in a status of "01". To read or verify the status, follow these guidelines.

[0052] 1. Given TXID0, we can see that the initial state is "11".

[0053] 2. Given TXID1, we can see that relative to A valid signature was provided, and As expected, it's included in the locking script.

[0054] 3. Since neither TXID1||0 nor TXID0||1 has been spent, we can conclude that the current state is “01”.

[0055] In short, while providing an access control framework, it also uses public keys to represent state and uses the corresponding output cost state to indicate whether the state is up-to-date.

[0056]

[0057] To change it back from "0" to "1", you can use a certified public key. As shown in TXID2, another input-output pair is included to indicate the change of the second bit from "1" to "0". As mentioned before, to read or verify the state, the public key is used to extract the value, and the spent state is used to check if the value is up-to-date. In this case, it can be concluded that the latest state value is "10".

[0058]

[0059] Finally, the two outputs in TXID2 can be used to spend PK. fin This leads to the conclusion of the state change, as shown in TXID3. Based on the system design, the final state of the system can be considered the final state of the system, or it can have a specific state, such as "00" as the default final state.

[0060] 1.1.3 Public Key Interpretation

[0061] The interpretation of public keys can be further summarized. Taking election voting as an example, voters receive certified public keys to vote. This initializes the voting system with a state of "11…1", indicating that every voter is ready to vote. Each voter spends their output on a set of public keys, each representing an election candidate. Voting ends after a given date or when the state reaches "00…0". If a voter does not spend an output, it can be automatically spent using the transaction's locking time. Public keys can be set up in ways that protect voter privacy, for example, using zero-knowledge proofs or Diffie-Helman style key derivation. When the underlying blockchain is public, everyone can know how many voters have cast their ballots and how many votes each candidate has, but that's all. Outputs not spent on the correct set of public keys are considered invalid votes. This results in a robust voting system with both transparency and privacy.

[0062] 2. Exemplary System Overview

[0063] 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 this copy is widely publicized. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Apart from so-called "coinbase transactions," 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.

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

[0065] Each input to a transaction (other than the coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and may also include an unlock script used to unlock the lock script pointing to that output. Therefore, 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 an amount of digital assets, and includes a lock script defining one or more conditions for unlocking that output. The second (target) transaction includes at least one input and an unlock script, the at least one input including a pointer to the output of the first transaction; this unlock script is used to unlock the output of the first transaction.

[0066] 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 one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not 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.

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

[0068] 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 (typically referred to as “miners”), which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0070] 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 fully storing blockchain 150. 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.

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

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

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

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

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

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

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

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

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

[0080] 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 Bitcoin nodes 104, which then propagate through the network of blockchain nodes 104, thus being 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.

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

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

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

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

[0085] 3. UTXO-based model

[0086] Figure 2An 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 is described with reference to Bitcoin, it can also be implemented on other example blockchain networks.

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

[0088] 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 sequence, Alice's new transaction 152j is marked "Tx1". This 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 this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to a subsequent transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has an unspent output 203 locked to Alice.

[0089] 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") are not valid unless the parent transaction is valid. Children that arrive at blockchain node 104 before their parents 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 parents.

[0090] One of the outputs 203 of a previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of a subsequent transaction must meet for the subsequent transaction to be valid and thus successfully redeem the UTXO.

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

[0092] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P). A This is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A [Contains the public key P in Alice's public-private key pair] A The representation (i.e., hash) of Tx1. Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash value of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P AThe 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.

[0093] When a new transaction Tx1 arrives at blockchain node 104, that node applies the node protocol. This includes running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria).

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

[0095] 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 to select the output to be signed (and is therefore fixed at the time of signing).

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

[0097] 4. Further comments

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

[0099] For example, some of the embodiments described above have been based on Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104. However, it should 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, any references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 above 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 characteristics described above for Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104.

[0100] In a preferred embodiment of the invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing blocks 151 of the 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 (please remember that these entities are not considered nodes of the preferred Bitcoin network 106).

[0101] In other embodiments of the invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that nodes 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" can 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.

[0102] To put it even more colloquially, any reference above to the term "Bitcoin node" 104 can be replaced by the terms "network entity" or "network element," where 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.

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

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

[0105] Statement 1. A computer-implemented method for determining the state of a system using one or more blockchain transactions, wherein each blockchain transaction includes one or more outputs, and wherein the method is performed by a first party and includes:

[0106] Determine the corresponding state of one or more corresponding outputs of one or more blockchain transactions; and,

[0107] The state of the system is determined based on the corresponding state of the one or more corresponding outputs.

[0108] Statement 2. The method according to statement 1, wherein determining the state of the system includes:

[0109] Mapping the corresponding states of the one or more corresponding outputs to corresponding values, wherein each corresponding output can have a first state or a second state, and wherein the first state is mapped to a first value and the second state is mapped to a second value; and,

[0110] The state of the system is determined based on the corresponding value of the corresponding state mapped to the one or more corresponding outputs.

[0111] Statement 3. The method described according to statement 1 or 2, wherein one or more of the corresponding outputs are controlled by the pre-defined party.

[0112] Statement 4. The method described in statement 3, wherein the pre-determining party is the first party or a (different) second party.

[0113] Statement 5. The method according to any of the preceding statements, wherein one or more of the corresponding outputs includes a predetermined public key.

[0114] Statement 6. The method according to any of the preceding statements, wherein determining the corresponding state of the one or more corresponding outputs includes determining whether the corresponding output is included in the set of unspent transaction outputs.

[0115] Statement 7. The method according to Statement 2 or any of its dependent statements, the method comprising: generating a binary string based on a corresponding value mapped to a corresponding state of the one or more corresponding outputs, wherein the determination of the state of the system is based on the binary string.

[0116] Statement 8. The method described according to any of the preceding statements, the method comprising:

[0117] The state of the system is changed by altering the state of one or more of the corresponding outputs.

[0118] Statement 9. The method described according to any of the preceding statements, wherein the corresponding state is a spending state.

[0119] Statement 10. The method according to statements 8 and 9, wherein changing the corresponding state of one or more of the corresponding outputs comprises: spending one or more of the corresponding outputs.

[0120] Statement 11. The method according to any of the preceding statements, wherein the one or more corresponding outputs include a plurality of corresponding outputs.

[0121] Statement 12. The method described according to any of the preceding statements, wherein the system is a physical system.

[0122] Statement 13. The method described according to any of the preceding statements, the method comprising:

[0123] In response to determining that the state of at least one of the one or more corresponding outputs has been changed, the updated state of the system is determined based on the change in the state of the at least one of the one or more corresponding outputs.

[0124] Statement 14. The method according to statement 13, wherein the determination of the updated state of the system includes:

[0125] Mapping the state of at least one of the one or more corresponding outputs to a corresponding value; and,

[0126] The updated state of the system is determined based on the corresponding value of the corresponding state of at least one of the one or more corresponding outputs mapped to.

[0127] Statement 15. A computer device, the computer device comprising:

[0128] The memory, comprising one or more memory cells; and,

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

[0130] Statement 16. 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 statements 1 to 14 when run on one or more processors.

Claims

1. A computer-implemented method for determining the state of a system using one or more blockchain transactions, wherein each blockchain transaction includes one or more outputs, and wherein the method is performed by a first party and includes: Determine the corresponding state of one or more corresponding outputs of one or more blockchain transactions; as well as The state of the system is determined based on the corresponding state of the one or more corresponding outputs.

2. The method of claim 1, wherein determining the state of the system comprises: Mapping the corresponding state of one or more corresponding outputs to a corresponding value, wherein each corresponding output may have a first state or a second state, and wherein the first state is mapped to a first value and the second state is mapped to a second value; as well as The state of the system is determined based on the corresponding value of the corresponding state mapped to the one or more corresponding outputs.

3. The method according to claim 1 or 2, wherein one or more of the one or more corresponding outputs are controlled by a predetermined party.

4. The method of claim 3, wherein the predetermined party is the first party or a different second party.

5. The method according to any one of the preceding claims, wherein one or more of the one or more corresponding outputs include a predetermined public key.

6. The method according to any of the preceding claims, wherein determining the corresponding state of the one or more corresponding outputs includes determining whether the corresponding output is included in the set of unspent transaction outputs.

7. The method according to claim 2 or any dependent claim thereof, wherein the method comprises: A binary string is generated based on the corresponding value of the corresponding state mapped to the one or more corresponding outputs, wherein the determination of the state of the system is based on the binary string.

8. The method according to any one of the preceding claims, wherein the method comprises: The state of the system is changed by altering the state of one or more of the corresponding outputs.

9. The method according to any one of the preceding claims, wherein the corresponding state is a spent state.

10. The method of claims 8 and 9, wherein changing the corresponding state of one or more of the corresponding outputs comprises: Spend one or more of the corresponding outputs.

11. The method according to any one of the preceding claims, wherein the one or more corresponding outputs comprise a plurality of corresponding outputs.

12. The method according to any one of the preceding claims, wherein the system is a physical system.

13. The method according to any one of the preceding claims, wherein the method comprises: In response to determining that the state of at least one of the one or more corresponding outputs has been changed, the updated state of the system is determined based on the change in the state of the at least one of the one or more corresponding outputs.

14. The method of claim 13, wherein determining the updated state of the system comprises: Map the state of at least one of the one or more corresponding outputs to a corresponding value; as well as The updated state of the system is determined based on the corresponding value of the corresponding state of at least one of the one or more corresponding outputs mapped to.

15. 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 14 when run on the processing apparatus.

16. 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 14 when run on one or more processors.

Images