Determining the system state using blockchain

Abstract

A computer implementation method for determining the state of a system using one or more blockchain transactions, wherein each blockchain transaction includes one or more outputs, and the method is performed by a first party and includes the steps of determining the respective status of one or more respective outputs of one or more blockchain transactions, and determining the state of the system based on the respective status of one or more respective outputs.

Description

[Technical Field]

[0001] This disclosure relates to methods for determining the state of a system using blockchain, and, in some embodiments, for influencing the state of a system using blockchain. [Background technology]

[0002] In "output-based" blockchain models such as Bitcoin (sometimes called UTXO-based models), the data structure of a given transaction includes one or more inputs and one or more outputs. Any available output includes an element that specifies the amount of digital assets that can be derived from the preceding sequence of transactions. Available outputs are sometimes called UTXOs ("unused transaction outputs"). Outputs may further include lock scripts that specify the conditions for redeeming the output in the future. A lock script is a predicate that defines the conditions required to validate and transfer digital tokens or assets. [Overview of the project]

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

[0004] Bitcoin was invented not only for electronic cash ("coins") but also for information ("bits"). This disclosure literally takes advantage of "bit" information from the Bitcoin system (and other UTXO-based blockchains). More specifically, a set of UTXOs may be used as a source of information, and the status of each transaction outpoint represents one bit, i.e., 0 or 1, depending on whether the outpoint is in a set of UTXOs.

[0005] Some embodiments use the usage status of blockchain transaction outputs to represent binary values, and multiple of them to represent binary columns, where the binary values ​​or binary columns are interpreted as the state of the system. Some embodiments allow the state of the system to be changed by expenditure transaction outputs. Some embodiments use public keys to represent values ​​that can be interpreted according to a pre-agreed policy or rule, and use the status of the corresponding transaction output to indicate whether the value is up-to-date.

[0006] Generally speaking, embodiments of this disclosure utilize a (e.g., public) blockchain as a single source of information for the state of a system that is accessible anytime, anywhere. Furthermore, by recording not only state transitions but also the entities responsible for those transitions on the blockchain, an immutable system log is provided for purposes such as auditing, data analysis, or investigation.

[0007] Some embodiments may be used to perform validity checks on a system, such as those in identity management systems and access control systems. In some embodiments, the system has non-binary states and therefore may use multiple outpoints to represent the state of the system; that is, n outpoints may be used to reflect any of 2^n states of the system.

[0008] As an exemplary use case, a vending machine could be given the authority to change its inventory status. Anyone can monitor the vending machine's inventory from the blockchain. For example, a student could choose to leave their dorm room only if they know their favorite snack is in stock at the vending machine downstairs, a snack supplier could monitor inventory levels on the blockchain and replenish as needed, and an administrator could monitor sales of different flavors and adjust supply as necessary. All data is in one place and accessible from anywhere in the world at any time.

[0009] The embodiment may also be used to manage IoT devices, for example, to view and control the status of the devices. Users may monitor the blockchain to control household devices such as washing machines or ovens.

[0010] As another example, the embodiment may be used as part of an aircraft takeoff procedure. Each of the UTXOs in the list may be associated with a task to be completed. The UTXO is used when the task is completed, and the aircraft can only take off when each UTXO has been used. [Brief explanation of the drawing]

[0011] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the accompanying drawings are referenced merely as examples. [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] Here are some schematic examples of transactions that can be recorded on the blockchain. [Figure 3] This provides a schematic overview of an exemplary system for determining the state of a system using blockchain technology. [Modes for carrying out the invention]

[0012] 1. State determination Figure 3 shows an exemplary system 300 that may 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, but generally, each of the first and second parties may operate their respective computing device 102 and perform any of the actions described below as being performed by Alice 103a and / or Bob 103b with reference to Figures 1 and 2.

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

[0014] As shown in Figure 3, Alice 103a, Bob 103b, and System 301 itself can each interact with Blockchain 150. This may include sending one or more transactions to Blockchain Nodes 104 of Blockchain Network 106 so that they are recorded on Blockchain 150. Additionally or alternatively, this may include retrieving data from Blockchain 150, for example, via one or more Blockchain Nodes 104.

[0015] In some embodiments, system 301 is associated with one or more UTXOs. The status of one or more UTXOs represents the state of system 301. One or more of the UTXOs may be controlled by Alice 103a and / or Bob 103b, for example, some may be controlled by Alice 103a and some by Bob 103b. One or more of the UTXOs may be arbitrarily selected, for example, to introduce randomness into system 301. In some examples, the UTXO associated with system 301 contains a particular public key, or a public key from a particular set of public keys.

[0016] Alice 103a can determine the state of system 301 based on the UTXOs. That is, Alice 103a determines the status (i.e., used or unused) of one or more UTXOs associated with system 301. Then, the state of system 301 is determined based on the status of each UTXO(s).

[0017] In some examples, Alice 103a maps the status of each UTXO to a value. Each UTXO can have either a first status (e.g., used) or a second status (e.g., unused) (i.e., it can have, can be associated with, etc.). Each output with the first status is assigned a single value (e.g., 1), and each output with the second status 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. In a specific example, Alice 103a may generate a binary column based on the values, and the binary column determines the state of system 301. For example, each UTXO may be mapped to a position in the column, e.g., the first UTXO is mapped to the first digit in the column, the second UTXO is mapped to the second digit in the column, and so on. Thus, each status of a particular UTXO determines the digit at the corresponding position in the column.

[0018] In some examples, Alice 103a may determine the status of system 301 at a first time and then at one or more future times.

[0019] In an example where Alice 103a controls one or more of the UTXOs, Alice 103a may change the state of system 301 by using one or more of the UTXOs. System 301 may perform an action in response to the use of one or more of the UTXOs.

[0020] In some embodiments, system 301 is associated with one or more UTXOs, and each UTXO includes a public key (or a hash thereof). 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 the UTXOs may be controlled by Alice 103a and / or Bob 103b.

[0021] Alice 103a may determine the state of system 301 based on both the public key(s) and the status of the output(s) that include the public key(s). That is, Alice 103a determines the status (i.e., used or unused) of each of one or more UTXOs associated with system 301. Each UTXO may have a first status (e.g., unused) or a second status (e.g., used). When a UTXO has the first status, Alice 103a determines that the public key included in that UTXO represents the current state. Conversely, when a UTXO has the second status, Alice 103a determines that the public key included in that UTXO does not represent the current state. Alice 103a may determine the state of system 301 based on the public key that represents the current state of system 301.

[0022] In response to determining that the UTXO has a second status (e.g., spent), Alice 103a may identify a transaction that references the UTXO (a "spending transaction"). Thereafter, the state of system 301 is determined based at least in part on one or more UTXOs of the spending transaction. More specifically, the state of system 301 is determined based on one or more respective public keys included in one or more respective outputs of the spending transaction. This process may be repeated for each UTXO having the second status.

[0023] If each UTXO is referenced by a respective spending transaction, Alice 103a may verify that the spending transaction includes 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 includes a valid signature.

[0024] Note that one or more public keys from later UTXOs (i.e., the UTXOs found in the spending transaction) may be the same as one or more public keys from previous UTXOs and thus may represent the same state. Thereby, the state of system 301 (or at least a part of the state) can be returned to a previous state.

[0025] System 301 may have an initial state (i.e., an initial state). Alice 103a may determine the initial state of System 301 by identifying an "initial transaction" and determining the initial state based on each state(s) represented by the public key(s) contained in the initial transaction, or rather, its output(s). Alice 103a may identify an initial transaction based on its transaction identifier or on a specific public key contained in the initial transaction. That is, the transaction identifier or public key may be known to be associated with an initial transaction. The public key may be contained in the input or output of the initial transaction.

[0026] Similarly, Alice 103a may determine the final state of system 301 by identifying the “final transaction” and determining the final state based on each state(s) represented by the public key(s) contained in the initial transaction, or rather, its output(s). In some examples, the final transaction contains a public key known to be associated with the final state of system 301.

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

[0028] Alice 103a and / or Bob 103b may change the state of system 301 by changing the status of one or more outputs of one or more transactions among the transactions associated with system 301, for example by using an output that has a public key representing the state of system 301. This may include generating a signature using the private key corresponding to the public key.

[0029] 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 column (e.g., a binary column). This column may represent the state of system 301. In these embodiments, blockchain 150 includes one or more outputs, each containing an initial public key. The outputs may be locked to an initial public key. The outputs may be distributed across multiple initial transactions (e.g., one per transaction), or all may be contained within a single initial transaction. In some examples, one or more outputs are controlled by Alice 103a and / or Bob 103b.

[0030] Alice 103a identifies one or more final transactions. Each final transaction includes a reference to each output of an initial transaction; for example, each final transaction includes at least one input that uses each output of an initial transaction. A final transaction may include multiple references to multiple outputs of the same 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 the 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 column (e.g., a binary column). This column may represent the final state of system 301. A final transaction(s) can be identified by identifying a transaction that has 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 modifying the state of system 301.

[0031] Alice 103a may wait until each of the outputs of the initial transaction(s) has been used by each of the inputs of the final transaction(s) before determining the final state of system 301. Alternatively, Alice 103a may determine the final state after a predetermined period of time, or at a predetermined time, for example, on a specific date, (e.g., from the initial transaction(s) recorded on the blockchain, or from a specific point in time).

[0032] In some examples, Alice 103a may determine the final state of the system based on a specific final public key, for example, one belonging to a given set of public keys. That is, the state of system 301 may only be permitted to be changed if a specific public key, for example, a public key representing a specific state, is used. 1.1 Blockchain as a Binary Encoder

[0033] This section provides further exemplary examples of the embodiments described above. It will be understood that some features are optional and not required in all embodiments. 1.1 Unidirectional state

[0034] In this example, the system state is mapped to a binary column. Each bit in this column is represented by a transaction output. The usage status of the output (i.e., whether it is in a UTXO set) is represented by the value of the bit. A lock script in each output may be used to enforce access control. The lock script and its unlock script may be used to provide authenticity. In general, any UTXO can be used. In some examples, UTXOs controlled by specific parties are used, and the ability to use a UTXO means the ability to control the system. For example, the system may have one or more lights in a building, and only the occupants of the building can turn the lights on and off.

[0035] For example, a system with four states can be represented by two transaction outputs, TXID0||0 and TXID0||1. When both are unused, the state is "11". Using TXID0||0 or TXID0||1 transitions the state to "01" or "10", respectively. Using both outputs results in a state of "00". Since used outputs can never become unused again, "00" is the final state of the system.

[0036] Another exemplary use case is a two-factor authentication system, or two-party authentication system, used to access a system. The initial state is "11," which indicates that the system is locked to the user. When one factor or one party passes verification (using one of the outputs), the state becomes "01" or "10," which indicates that the system is partially unlocked. When the other factor or the other party passes verification (using the other output), the state becomes "00," which indicates that the system is fully unlocked. (Upon confirming that the state is "00," the lawyer begins following the list of instructions outlined in the client's will.) 1.1.2 Bidirectional state

[0037] In the previous example, once "1" is changed to "0", it cannot be undone. To address this limitation in some use cases, the public key may be used in addition to the usage status in the transaction output.

number

number

[0038] Transaction TXID0 initializes the state of the 4-state system to "11". Follow the guidance below to read or verify the state. 1. Public key PK in the unlock script init This means that this is a state initialization. There is no need to read the previous state. 2. Both public keys in the lock script show a value of "1". 3. Both transaction outputs are unused. Therefore, we can conclude that the current state is "11". [Table 2]

[0039] Transaction TXID1 changes the value of the first bit from "1" to "0", resulting in a state of "01". Follow the guidance below to read or verify the state.

number

[0040] In short, while providing an access control framework, the public key is also used to represent state, and the usage status of the corresponding output is used to indicate whether the state is up-to-date. [Table 3]

[0041] To return from "0" to "1", the authenticated public key

number

[0042] Finally, as shown in TXID3, by using both outputs in TXID2, PK fin It can be concluded that the state has changed. Depending on the system design, the last state of the system may be considered the final state of the system, or it may have a specific state, for example, "00", as the default final state. 1.1.3 Public Key Interpretation

[0043] Further generalizations can be made regarding the interpretation of public keys. Taking election voting as an example, voters can be given authenticated public keys to vote. This initializes the voting system to the state "11...1", indicating that each voter is ready to vote. Each voter will use the output for a set of public keys, each representing an election candidate. Voting ends after a predetermined date or when the state reaches "00...0". If an output is not used by a voter, it can be used automatically using a transaction lock time. Public keys can be configured to protect voter privacy, for example, using zero-knowledge proofs or Diffie-Helman key derivations. When the underlying blockchain is public, anyone can know how many voters have voted and how many votes each candidate received, but nothing else. Outputs not used for the correct set of public keys are considered invalid votes. This results in a robust voting system with transparency and privacy. 2. Overview of the Exemplary System

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

[0045] Transactions within a blockchain can be used for one or more purposes, including transmitting digital assets (i.e., several digital tokens), ordering a set of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or chronologically arranging index pointers. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indices to data within transactions. There are no predetermined limits on the maximum amount of data that can be stored within a single transaction, and therefore more complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0046] Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction, and may further include an unlock script to unlock the lock script of the pointed-to output. For this reason, when considering pairs of transactions, we refer to them as the first transaction and the second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of the digital asset and includes a lock script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction, and an unlock script to unlock the output of the first transaction.

[0047] In such a model, when a second target transaction is sent to the blockchain network, propagated, and recorded on the blockchain, one of the validity criteria applied at each node is that the unlock script satisfies all of one or more conditions defined in the lock script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by another valid transaction. A node that discovers a target transaction is invalid according to any of these conditions will neither propagate it (as a valid transaction, but potentially propagate it to register an invalid transaction) nor include it in a new block to be recorded on the blockchain.

[0048] Another type of transaction model is the account-based model. In this case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes, separate from the blockchain.

[0049] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may consist of a packet-switched network 101, which is typically a wide-area internetnet such as the internet. The packet-switched network 101 may contain multiple blockchain nodes 104 (often referred to as "minors") that 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 may be configured as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0050] Each blockchain node 104 includes the computer equipment of its peers, and different nodes 104 belong to different peers. Each blockchain node 104 comprises processing equipment including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disc drives.

[0051] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained at each of the multiple blockchain nodes 104 within a decentralized or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean completely memorizing blockchain 150. Instead, blockchain 150 can be pruned, as long as each blockchain node 150 remembers the block header (described later) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0052] A blockchain node 104 may be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. A blockchain node 104 may be configured to create a block 151 and store each copy of the same blockchain 150 in their respective memories. A blockchain node 104 may 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”. This term, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as valid, to which the node 104 is obligated not to accept other transactions attempting to use the same output.

[0053] In a given current transaction 152j, its input (or each input) contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. Using or redeeming does not necessarily mean the transfer of a financial asset, but it is certainly one common use. More generally, using can be described as consuming the output or allocating it to one or more outputs in another subsequent (onward) transaction. Generally, a preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i must exist and be validated for the current transaction to be valid, but it does not necessarily need to exist when the current transaction 152j is created or sent to network 106. Therefore, "preceding" as used herein refers to a preceding transaction in a logical sequence linked by pointers, and not necessarily to a time sequence of creation or transmission, and thus does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted out of order (see the following explanation of orphan transactions). The preceding transaction 152i is also referred to as the antecedent transaction or predecessor transaction.

[0054] Due to the resources involved in transaction validation and publication, typically, at least each of the blockchain nodes 104 takes the form of a server consisting of 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 user terminal or a group of user terminals networked together.

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

[0056] Any given blockchain node can be configured to perform one or more of the following operations: validating 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 specialize in a particular operation. For example, node 104 may focus on transaction validation and propagation, or on block mining. In some examples, blockchain node 104 may perform two or more of these operations in parallel. Any reference to blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0057] 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 transaction validation or block construction. Some of these users or agents 103 may act as senders and receivers of transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., they have obtained a copy of the blockchain from a blockchain node 104).

[0058] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) can be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the role required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106 and thereby be able to utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. There are many more such parties 103 and their respective computer devices 102 that could participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to herein as Alice, and the second party 103b as Bob; however, this is not restrictive, and it should be understood that any reference to Alice or Bob herein may be replaced with “the first party” and “the second party,” respectively.

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

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

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

[0062] Various client functions may be described as being integrated into a given client application 105, but are not necessarily limited to this. Instead, it should be noted that any client function described herein may be implemented, for example, in a set of two or more separate applications that interface via an API or where one is a plug-in to the other. More generally, client functions may be implemented in the application layer, a lower layer such as the operating system, or any combination thereof. The following description will focus on client application 105, but will not be limited to it.

[0063] Each computer device 102 instance of a client application or software 105 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact blockchain node 104 to query blockchain 150 for any transaction in which each party 103 is the recipient (or, in embodiments, actually inspect the transactions of other parties in blockchain 150, since blockchain 150 is a public facility that provides trust in transactions through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and forward transaction 152 to propagate them throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol follows (goes with) a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all 152 transactions in blockchain 150. The same node protocol is used by all 104 nodes in network 106.

[0064] Alternative transaction protocols operated by several blockchain networks can be called “account-based” protocols as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account’s running transaction tally (also called “position” or “nonce”). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field in the transaction may also be signed. This data field may point to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0065] Several account-based transaction models share some similarities with the output-based transaction models described herein. For example, as mentioned above, the data fields of an account-based transaction may point to a previous transaction, which is equivalent to the input of an output-based transaction that references the output point of the previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction includes a “Recipient” field (where the recipient's address in the account is specified) and a “Value” field (where the amount of the digital asset may be specified). Both the recipient and value fields are equivalent to the outputs of an output-based transaction that can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction has a “Signature” field that contains the signature of the transaction. The signature is generated using the sender’s private key and confirms that the sender authorized this transaction. This is typically equivalent to the input / unlock script of an output-based transaction that contains the signature of the transaction. Once both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and recordable on the blockchain. On an account-based blockchain, a “smart contact” refers to a transaction containing a script configured to perform one or more actions (e.g., sending or “releasing” a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) that satisfy one or more conditions defined by the smart contact’s script. A smart contract exists as a transaction on the blockchain and can be invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to an output-based transaction lock script that can be triggered by a subsequent transaction, checking whether one or more conditions defined by the lock script are met by the input of the subsequent transaction. 3. UTXO-based models

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

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

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

[0069] In the context of transaction sequences, the terms “predecessor” and “successor” as used herein refer to the order of transactions in a sequence defined by transaction pointers specified within the transaction (such as which transaction points to which other transaction). These can similarly be replaced with “predecessor” and “successor,” or “antecedent” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order of their creation, transmission to network 106, or arrival at any given blockchain node 104. Nevertheless, a succeeding transaction (a later transaction or “child”) pointing to a predecessor transaction (a later transaction or “parent”) will not be validated until the parent transaction has been validated. A child arriving at blockchain node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for its parent or discarded, depending on the node protocol and / or node behavior.

[0070] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO labeled herein as UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a lock script, the lock script defining the conditions that the unlock script in the subsequent transaction's input 202 must satisfy in order for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed.

[0071] The lock script (commonly scriptPubKey) is a part of the code written in a domain-specific language recognized by the node protocol. A specific example of such a language is what is called "Script" (capital S) used by the blockchain network. The lock script specifies what information is required to use the transaction output 203, for example the need for Alice's signature. The lock script appears in the output of the transaction. The unlock script (commonly scriptSig) is a part of the code written in the main native language that provides the information necessary to meet the lock script criteria. For example, it may include Bob's signature. The unlock script appears in the input 202 of the transaction.

[0072] That is, in the illustrated example, the UTXO0 within the output 203 of Tx0 requires Alice's signature Sig P A for the lock script [Checksig P A to be satisfied in order for the UTXO0 to be redeemed (strictly speaking, for the subsequent transaction attempting to redeem the UTXO0 to be valid). [Checksig P A includes the representation (i.e., hash) of the public key P A of Alice's public key - private key pair. The input 202 of Tx1 includes a pointer indicating Tx1 (e.g., in an embodiment, its transaction ID, TxID0 which is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 within Tx0 to identify UTXO0 from among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlock script <Sig P A > containing Alice's cryptographic signature created by applying Alice's private key of the key pair to a predetermined part of the data (sometimes called "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

[0073] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves running the lock script and unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (these conditions may include one or more criteria).

[0074] It should be noted that script code is often expressed conceptually (i.e., without using the exact language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For example, OP_RETURN is a scripting language opcode that creates an unusable output of a transaction, which can store data within the transaction and thereby immutably record the data within the blockchain, when preceded by OP_FALSE at the beginning of the lock script. For example, the data may include documents that are desired to be stored on the blockchain.

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

[0076] A lock script is sometimes referred to as a "scriptPubKey," typically because it contains the public keys of the parties whose transactions are being locked. An unlock script is sometimes referred to as a "scriptSig," typically because it supplies the corresponding signature. However, more generally, it is not mandatory in all blockchain applications for a UTXO to be redeemed to include the authentication of a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred. 4. Further notes

[0077] Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art once the disclosure herein is given. The scope of this disclosure is not limited by the embodiments described, but only by the appended claims.

[0078] For example, some of the embodiments described above relate to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104. However, it will be understood that Bitcoin Blockchain is one specific example of Blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not limited to Bitcoin Blockchain. More generally, any above references to Bitcoin Network 106, Bitcoin Blockchain 150, and Bitcoin Node 104 may be replaced with references to Blockchain Network 106, Blockchain 150, and Blockchain Node 104, respectively. Blockchains, Blockchain Networks, and / or Blockchain Nodes may share some or all of the described properties of Bitcoin Blockchain 150, Bitcoin Network 106, and Bitcoin Node 104 as described above.

[0079] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, issuing, propagating, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of propagating and / or storing blocks without creating and issuing blocks (it should be recalled that these entities are not considered nodes of the preferred Bitcoin network 106).

[0080] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform some, but not all, of the functions of creating, issuing, propagating, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and issue blocks 151 but not to store and / or propagate those blocks 151 to other nodes.

[0081] More generally, any reference to the term “Bitcoin node” 104 above shall be replaced with the term “network entity” or “network element,” such entity / element configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0082] Several embodiments have been described in relation to blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-ruptured time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock their tokens for a certain period of time in order to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

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

[0084] <Statement 1> A computer implementation method for determining the state of a system using one or more blockchain transactions, wherein each blockchain transaction includes one or more outputs, and the method is performed by a first party. A step of determining the status of each of the outputs of one or more blockchain transactions, A step of determining the system state based on the status of one or more outputs, and A method that includes this.

[0085] <Statement 2> The step of determining the system state is: A step of mapping the respective status of one or more outputs to a respective value, wherein each output may have a first status or a second status, the first status is mapped to a first value, and the second status is mapped to a second value. The steps include determining the system state based on the respective values ​​mapped to the respective status of one or more outputs, and The method described in Statement 1, including the method described in Statement 1.

[0086] <Statement3> The method according to statement 1 or statement 2, wherein one or more outputs of each of the one or more outputs are controlled by a predetermined party.

[0087] <Statement 4> The method described in Statement 3, wherein the specified party is either the first party or a different second party.

[0088] <Statement 5> One or more outputs of each of the one or more outputs include a given public key, as described in one of the preceding statements.

[0089] <Statement 6> The method of any of the preceding statements, wherein the step of determining the status of each of one or more outputs includes the step of determining whether each output is included in the unused transaction output set.

[0090] <Statement 7> A method by which a binary column is generated based on the binary column, comprising the step of generating a binary column based on the respective values ​​mapped to the respective status of one or more respective outputs, and determining the state of the system, in the manner of statement 2 or any statement subordinate thereto.

[0091] <Statement 8> A step to change the state of the system by changing the status of one or more outputs among the outputs. A method of any of the preceding statements, including the method described in any of the preceding statements.

[0092] <Statement 9> Each status is the usage status, as described in one of the preceding statements.

[0093] <Statement 10> The method described in statements 8 and 9, which includes the step of changing the status of one or more outputs from each set of outputs, and the step of using one or more outputs from each set of outputs.

[0094] <Statement 11> Each of the one or more outputs is a method of any of the preceding statements, including multiple outputs.

[0095] <Statement 12> The system is a physical system, as described in any of the preceding statements.

[0096] <Statement 13> Steps to determine the updated state of the system based on the status change of at least one of the outputs, in response to determining that the status of each of the outputs has changed among the one or more outputs: A method of any of the preceding statements, including the method described in any of the preceding statements.

[0097] <Statement 14> The step of determining the updated state of the system is: The steps include mapping the status of at least one output of one or more outputs to their respective values, The steps include determining the updated state of the system based on the respective values ​​mapped to the status of each of at least one of the outputs of one or more outputs, and The method described in Statement 13.

[0098] <Statement 15> Computer equipment, Memory including one or more memory units, Apparatus including one or more processing units A computer device comprising: memory for storing code configured to run on a processing unit; and code configured to perform any of the methods described in statements 1 to 14 when on the processing unit.

[0099] <Statement 16> A computer program that is implemented on computer-readable storage and, when executed on one or more processors, is configured to execute one of the methods of statements 1 through 14.

Claims

1. A computer implementation method for determining the state of a system using one or more blockchain transactions, wherein each blockchain transaction includes one or more outputs, and the method is performed by a first party. A step of determining the status of each of the outputs of one or more blockchain transactions, A step of determining the state of the system based on the respective status of each of the one or more outputs. A method that includes this.

2. The step of determining the state of the system is: A step of mapping the respective status of one or more outputs to respective values, wherein each output may have a first status or a second status, the first status is mapped to a first value, and the second status is mapped to a second value. A step of determining the state of the system based on the respective values ​​mapped to the respective status of each of the one or more outputs; The method according to claim 1, including the method described in claim 1.

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

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

5. The method according to claim 1, wherein one or more of the one or more outputs include a predetermined public key.

6. The method according to claim 1, wherein the step of determining the status of each of the one or more outputs includes the step of determining whether each of the outputs is included in the unused transaction output set.

7. The method of claim 2, comprising the step of generating a binary sequence based on the respective values ​​mapped to the respective status of the one or more respective outputs, wherein the step of determining the state of the system is based on the binary sequence.

8. A step of changing the state of the system by changing the status of one or more of the respective outputs. The method according to claim 1, including the method described in claim 1.

9. The method according to claim 1, wherein each of the aforementioned statuses is a usage status.

10. The method according to claim 8, wherein each of the aforementioned statuses is a usage status, and the step of changing the respective status of one or more of the aforementioned outputs includes the step of using one or more of the aforementioned outputs.

11. The method according to claim 1, wherein each of the one or more outputs includes each of a plurality of outputs.

12. The method according to claim 1, wherein the system is a physical system.

13. Steps to determine the updated state of the system based on the change in the status of at least one of the one or more outputs, in response to determining that the status of each of the at least one of the one or more outputs has changed. The method according to claim 1, including the method described in claim 1.

14. The step of determining the updated state of the system is: The steps include mapping the respective status of at least one of the one or more outputs to their respective values, A step of determining the updated state of the system based on the respective values ​​mapped to the respective status of each of the one or more outputs, at least one of the outputs; The method according to claim 13, including the method described in claim 13.

15. Computer equipment, A memory containing one or more memory units, Apparatus including one or more processing units A computer device comprising, wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to claim 1 when it is on the processing device.

16. A computer program that is implemented on computer-readable storage and configured to perform the method described in claim 1 when executed on one or more processors.

Images