A computer-implemented system and method for determining the state of a machine-executable contract implemented using a blockchain

Abstract

To provide computer-implemented systems and methods for establishing information on states of a machine-executable contract, in the context of unspent transaction outputs (UTXOs), blockchain and deterministic finite automaton (DFA) implementation of contracts, and determination of states within those.SOLUTION: A method includes: determining information of interest, and codes or tags identifying the information; constructing metadata associated with the codes or tags; and combining it with a public key for an agent associated with the information.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present invention generally relates to systems such as computer-implemented systems and methods, and more particularly to computer-implemented systems and methods for establishing information regarding a state. The present invention is particularly suitable for use in blockchains, and in the deterministic finite automaton (DFA) implementation of contracts, and in the determination of states therein.

Background Art

[0002] As used herein, the term "blockchain" is used to include any form of electronic, computer-based, distributed ledger. These include, but are not limited to, blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Bitcoin is mentioned herein for convenience and illustrative purposes only, and it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is an electronic ledger based on consensus, implemented as a computer-based decentralized distributed system composed of blocks. Also, a block is composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants within a blockchain system, and includes at least one input and at least one output. Each block contains the hash of the previous block, and the blocks together form a chain, generating a permanent and immutable record of all the transactions written to the blockchain from its inception. Transactions contain a small program known as a script embedded in their inputs and outputs. The script specifies how and by whom the outputs of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "verified". Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. The software client installed on the node performs this verification work on unspent transactions (UTXOs) by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and the transaction is written to the blockchain. Therefore, for a transaction to be written to the blockchain, the transaction must: i) be verified by the first node that receives the transaction, and if the transaction is verified, the node relays the transaction to other nodes within the network; ii) be added to a new block constructed by the miner; and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] Blockchain technology is most widely known for its use in cryptocurrency implementations, but digital entrepreneurs are beginning to explore the use of both Bitcoin-based cryptocurrency security systems and data storable on the blockchain to implement new systems. If the blockchain can be used for automated tasks and processes not limited to the cryptocurrency realm, it would be highly advantageous. Such solutions can utilize the advantages of the blockchain (e.g., permanent, tamper-resistant records of events, distributed processes, etc.) while being more diverse in their applications.

[0006] One area of current research is the use of the blockchain for the implementation of "smart contracts." These are computer programs designed to automate the execution of machine-readable transactions or the terms of an agreement. Unlike traditional transactions that can be described in natural language, smart contracts are machine-executable programs that contain rules for processing inputs to produce results and can execute actions depending on those results.

[0007] Another area of interest related to the blockchain is the use of "tokens" (or "colored coins") for the representation and transfer of real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that have no identifiable meaning or value. Thus, tokens function as identifiers that allow real-world items to be referenced from the blockchain.

[0008] One problem associated with blockchain technology is that relevant information can be discoverable on the blockchain. A number of prior art documents disclose methods for discovering relevant information on the blockchain. Examples of such prior methods are briefly described below.

[0009] The presentation "OpenBazaar - Ratings, reviews and reputation" by Chris Pacia discloses a blockchain - based rating system. When a buy transaction occurs, money is exchanged between the buyer and the seller. The buyer can also leave a visible review of the service provided by others. Data such as vendor GUID (Globally Unique Identifier), consecutive evaluations, and contract hash are added to OP_RETURN. The slide discloses a function for the user to search for reviews left by users by querying the OP_RETURN output of the tagged blockchain by the vendor.

[0010] US2016292672 discloses a trading system that utilizes a blockchain storage system. It is disclosed that the trading system queries the blockchain system to check whether the trading party owns the stocks to be traded before conducting a transaction. This is achieved by determining whether there is an unused transaction owned by the trader corresponding to the stocks to be traded.

[0011] US2017005804 discloses a system in which the blockchain is searched for assets owned by a specific person who wishes to conduct a financial transaction. This verification is achieved by accessing the blockchain and determining that the source participant is associated with an unused output blockchain transaction linked to a sufficient amount of the target asset. This process may include summing a plurality of different blockchain transactions associated with the source participant to determine the total amount of assets "owned" by the source participant. Summary of the Invention

[0012] The problems associated with existing systems and methods are that the extraction of certain types of information, such as the state of machine-executable contracts implemented on a blockchain, is not possible, or at least difficult to achieve in an efficient manner. This makes it more difficult to implement machine-executable contracts, for example, through the use of a deterministic finite automaton (DFA).

[0013] Therefore, it is desirable to provide a solution that enables the extraction of information despite significant changes over time in the information broadcast to the blockchain.

[0014] Such an improved solution has been devised. The present invention is defined in the appended claims and / or the description of the present invention and / or the features, options, and possibilities described herein.

[0015] According to a first aspect, the present invention provides a method for searching information included in unspent outputs (UTXOs) of a blockchain. The method includes (a) determining the information of interest and obtaining a key related to the information of interest; (b) constructing a search term related to the key; and (c) searching the blockchain for unspent outputs (UTXOs) that match the search term.

[0016] The method may provide a method for searching the state of a machine-executable smart contract. The method may provide a method for searching the state of a machine-executable smart contract implemented with a DFA. For example, a method for determining the state of a machine-executable contract implemented on a blockchain may be provided. The method includes (a) determining the information of interest and generating a cryptographic key related to the information of interest; (b) constructing a search term related to the cryptographic key; and (c) Searching the blockchain for unused outputs (UTXOs) that match the search term, and the information of interest is the state of a machine-executable smart contract, and the method (d) Extracting information from the unused outputs (UTXOs) that match the search term, and (e) Determining the state of the machine-executable smart contract from the extracted information, and the machine-executable smart contract may be implemented using a deterministic finite automaton, and the step of determining the state of the machine-executable smart contract may include determining the state of the deterministic finite automaton.

[0017] The method may provide that the key is obtained by processing the information of interest through one or more stages. The one or more stages for obtaining the key may include a specification stage, a metadata configuration stage, an agent association stage, a combination stage, and a value acquisition stage. The key may be the output from the value acquisition stage.

[0018] The method may provide that the key is obtained by applying a reproducible process to the information of interest, and the same reproducible process generates the information included in the unused outputs (UTXOs) of the blockchain being searched.

[0019] The method may provide that the search term is composed from the key, for example, through an address derivation stage.

[0020] The method may provide that the step of searching is provided by a search and collation stage.

[0021] The method may provide that the unused outputs (UTXOs) that match the search term are paired with the key and / or the information of interest. Pairing may be provided in a database and / or a database stage.

[0022] The method may include one or more of a specifying stage, a metadata configuration stage, an agent association stage, a combining stage, a value acquisition stage, a database formation stage, an address derivation stage, a wallet formation stage, a search and verification stage.

[0023] The possibilities of each of the above stages are detailed below.

[0024] The first aspect of the present invention may include any of the features, options, and possibilities described elsewhere in this specification.

[0025] According to a second aspect, the present invention provides a system, preferably a computer-implemented system, including a system configured to implement the method of the first aspect of the present invention and configured to perform any of the functions, options, and possibilities described elsewhere in this specification, if any.

[0026] The system may further include at least one computing agent configured to implement a DFA via a blockchain, and a blockchain platform.

[0027] The second aspect of the present invention may include any of the features, options, and possibilities described elsewhere in this specification.

[0028] Accordingly, according to the present invention, options, possibilities, and features may be provided or further provided from among the following.

[0029] The method and / or system may include a specifying stage. The specifying stage may include a step of selecting information of interest. The specifying stage may include or be an identifier specifying stage. The specifying stage may include or be a code or tag specifying stage.

[0030] The relevant information may be a selection from the information set. The relevant information may be a state, preferably a state of a deterministic finite automaton, most preferably a state of a machine-executable smart contract. The information set may be limited to, for example, the limited possible states of a DFA.

[0031] The relevant information may be selected by the user. The relevant information may be selected by a DFA. The relevant information may be selected by one or more agents within the network.

[0032] One or more identifiers of the relevant information may be determined. The identifier may be a code. The identifier may be a tag. The code may indicate only one piece of relevant information, such as one state. The tag may indicate only one piece of relevant information, such as one state.

[0033] The method and / or system may include a metadata configuration stage. The relevant information, more preferably the code or tag, may thus be converted into metadata. The relevant information, more preferably the code or tag, may thus be processed by a cryptographic hash. Ideally, two such cryptographic hashes are applied in series. The metadata, especially the hash metadata, may be formatted later. The relevant information, more preferably the code or tag, may thus, more preferably its metadata, be incorporated into a public key. The public key may be designated as an information public key.

[0034] The method and / or system may include an agent association stage. The agent association stage may select one or more agents, preferably UTXOs, such as UTXOs from a machine-executable smart contract, preferably one or more agents configured to execute those implemented by a DFA. One or more or all of the selected agents may provide a public key. One or more public keys may be designated agent public keys.

[0035] The method and / or system may provide a combining step, desirably a public key combining step. The combining step may combine an information public key with one or more agent public keys. The combining step may generate a multi-signature Redeem script, such as a P2SH multi-signature Redeem script. The combining step may desirably provide a lock script, ideally from the information public key and the one or more agent public keys. The combining step may generate a hash of the lock script. The hash of the lock script may be specified as the scriptPubKey.

[0036] The method and / or system may include a value acquisition step for acquiring a value. The method and / or system may include a lock script value acquisition step for acquiring a value such as a lock script value. The method and / or system may include a scriptPubKey value acquisition step for acquiring a value such as, for example, a lock script value or a scriptpubKey value. The value acquisition step may acquire the value of the lock script or, more desirably, the hash of the lock script, and even more desirably, the value of the scriptPubKey.

[0037] The method and / or system may include a database formation step for providing, for example, the configuration of a database.

[0038] The database may be external to the blockchain. The database may be centralized. The database may be distributed, for example, within a network, in some cases like a distributed hash table. The database formation may be performed using a Python dictionary. The database may desirably be accessible to each node within a network, such as a distributed network. One or more or all of the nodes may be provided with computing agents.

[0039] The database creation stage may include the step of mapping with the information of interest as a key. The key may be a value from the value acquisition stage, such as the value of the lock script, more preferably the value of scriptPubKey. The key may be linked to a single value. The key may be linked to a single code or tag. The key may be linked to a single piece of information of interest. The step of mapping the information to the key may provide half of the mapping of the key for the combination. The other half of the combination may be mapped to the key in the search and matching stage. The database creation stage and / or the mapping may be implemented as a hash table.

[0040] The method and / or system may include an address derivation stage, such as a script hash address derivation stage. The address may be derived from the information public key and the agent public key, preferably from the lock script, more preferably from the hash of the lock script, and ideally from scriptPubKey. The address may be a script hash address such as a P2SH address.

[0041] The method and / or system may include a wallet formation stage. The wallet formation stage may include the step of adding one or more or all of the addresses, such as the script hash address, to the wallet, preferably to an account or folder within the wallet.

[0042] The method and / or system may include a search and matching stage. The search and matching stage may be implemented by an algorithm. The search and matching stage may include the step of searching within the blockchain for one or more matches with the address, such as the script hash address. The search and matching stage may obtain the address, such as the script hash address, from the wallet, preferably from the wallet of the wallet formation stage. The search and matching stage may obtain the details of the UTXO within the blockchain that match the address used in the search.

[0043] The method and / or system may optionally include, within and / or during the searching and matching stage and / or within the database creation stage, a step of mapping the obtained details of the UTXO that matches the address, using the key. As described above, the key resulting from such mapping may be linked to a single value, or a single code or tag, or a single item of interest. As a result, the half-mapping of the binding to the key is provided in the searching and matching stage.

[0044] Upon obtaining a match, the method and / or system may be considered to have clearly determined which items of interest, such as tags or status, are present within the UTXO.

[0045] The method and / or system may search for matches with more than one item of interest simultaneously.

[0046] Accordingly, for example, in the context of unspent transaction outputs (UTXOs), blockchain, and deterministic finite automaton (DFA) implementations of contracts, and the determination of states therein, computer-implemented systems and methods for establishing information regarding the state of machine-executable contracts are detailed. The steps may include determining the information of interest and the code or tag that identifies the information, constructing metadata associated with the code or tag, and associating this with the public key of the agent associated with the information. The scriptPubKey value of each script may be used to provide a key for use when constructing an external database, and more specifically, when mapping keys from scriptPubKey values linked to information of interest. There is a derivation of a script hash address from the scriptPubKey value used to fund a digital wallet to obtain the other half of the association. Search and matching algorithms are then used to find UTXOs that match the script hash address on the blockchain. These are then deposited into the aforementioned database, with UTXOs that match the script hash address and thus the key for completing the association. The match indicates the state in the most reliable way.

Brief Description of the Drawings

[0047] The above and other aspects of the invention will be apparent from and taught with reference to the embodiments described herein. Embodiments of the invention are described below by way of example only with reference to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

DETAILED DESCRIPTION OF THE INVENTION

[0048] Unspent transaction outputs (UTXOs) are a fundamental feature of blockchains. A very wide variety of transactions for a very wide variety of assets are possible through the blockchain. The number of UTXOs is huge, and they are present in each full-node Bitcoin client and as a whole known as the UTXO set or UTXO pool.

[0049] UTXOs are in the form of Bitcoin amounts and, typically, a lock script or encumbrance associated with a particular user address. For the diversity of many transactions, a data portion for incorporating information into blockchain transactions also exists within the UTXO. The data portion may be in the form of code, tags, or metadata. The ability to discover specific code, tags, or metadata and / or to systematically discover and extract information stored in the general blockchain is not currently feasible and is in particular a potential problem that the present invention seeks to solve.

[0050] The present invention seeks to solve this and provide access to the information by extracting the possible information from the blockchain.

[0051] The difficulty in discovering code, tags, or metadata and even more so in extracting information is apparent from considering how the content of UTXOs and their data portions arise.

[0052] Generally, the format of blockchain transactions enforces that the information stored therein results in a long byte chain. This information must be filtered and processed before it becomes useful. Further, for security, privacy, and technical reasons, the chain is actually some form of (multiple) hashes, making it impossible to reconstruct the original information, such as a meaningful message from these byte chains. For example, a Bitcoin address is multiple hashes of a public key, which are then further formatted. A similar situation applies to signature scripts or blockchain transaction puzzles obtained by similar processes. This requires them to be accessible by the network, for example, in the form of cryptographic public keys, etc.

[0053] The specific embodiments used hereinafter to illustrate the implementation of the present invention are deterministic finite automata (DFAs) based on blockchains, in relation to which the information of interest is the state of the DFA. In a specific example, it is assumed that the UTXO of interest is of the P2SH (pay-to-script-hash) type. It is further contemplated that one agent is assigned to execute (use) the transaction associated with a specific state of the state machine.

[0054] In the first step of this specific embodiment, the information (a tag or code identifying the state of the DFA) is first hashed to form a metadata field included in the public key. The metadata field in the form of the public key is combined with the public key of the agent responsible (for providing the obligation). The result is placed in one of two multi-signature Redeem scripts of P2SH. This Redeem script is also hashed and combined with other bytes carrying additional information to derive the lock script (scriptPubKey) that is ultimately placed as part of the byte chain forming the blockchain transaction.

[0055] Going through these steps and restoring the original information from what is stored in the network should, at this point in this particular embodiment, be made clear to be rather an undesirable operation, as is the case with more general situations.

[0056] Details of the present invention and its particular embodiments are discussed below. An overview of the operation of the present invention is provided at this stage. The operation provides the following general steps. 1. Determine the information of interest and specify a code or tag that identifies the information. In the DFA embodiment discussed in detail below, this may be a particular state of a particular contract embodied as a DFA based on a blockchain. 2. Configure the metadata associated with the code or tag. In the DFA embodiment, this may be a code or tag specific to a particular state of interest and, in some cases, a particular contract type of interest. 3. Determine which agent (or set of agents) is associated with the information. Again, in the DFA embodiment, this may be the agent assigned to use the UTXO corresponding to the particular state of interest. 4. Combine the public key containing the metadata associated with these codes or tags with the public key of the relevant agent to give a script. In the DFA embodiment, this may be the public key with metadata and the public key from the agent, which is then combined into a P2SH multisignature Redeem script. 5. Derive the scriptPubKey of each script to provide a key for use in an external database relevant to the collation. In the DFA embodiment, this may be a value represented as a key that links to the code and thus the state of interest. 6. Configure a database where the key from the scriptPubKey value is mapped and can be linked to the information of interest having the other half of the combination for a later stage. In the DFA embodiment, the key will eventually be discovered, collated, and mapped with the UTXO that is added, thus mapping to the code and hence the state of interest. Derive the script hash address from the scriptPubKey value. In embodiments of the DFA, this also applies as follows; Fund digital wallets having these script hash addresses. In embodiments of the DFA, this also applies as follows; Use a search and matching algorithm to find UTXOs by matching the script hash addresses on the blockchain. In embodiments of the DFA, this also applies as follows; Load into the aforementioned database UTXOs that match the script hash address and thus the key for completing the binding. In embodiments of the DFA, this means that when the algorithm discovers the script hash address of a matching UTXO, the system clearly determines which state tags are present within the UTXO. That is, substantially, the state has been detected.

[0057] Although the complete restoration of information from the information within the blockchain is a hopeless task, it should be noted that for pre-known information, it is still possible to determine whether a specific tag exists within the cryptocurrency's UTXO. This applies to the state indicating the tag within the DFA system. Thus, it is possible to detect based on this whether the DFA machine is in one of its permitted states.

[0058] Here, it is worth mentioning that due to the structure, the DFA can only exist in one of a finite set of states at a time. However, the detector is equally suitable for detecting any number of tags or other types of known information.

[0059] The initial stage transitions from the information to the metadata incorporated into the lock script, reflecting the stages outlined above in general terms.

[0060] Therefore, at the code specification stage, which is the initial step, the information of interest is selected. This information may be a state of interest. Next, these codes or tags that identify the information to be searched (such as a specific state) are specified. These may be codes or tags selected from the complete set of codes or tags for all the states detailed in the state transition table. Therefore, the code specification stage is a notation step and is immediately implementable.

[0061] These codes or tags form the input to the metadata configuration stage, which is the second step. In this step, the double hash of the code or tag converts the code or tag into a metadata format that reflects them. This metadata is then formatted and placed within the information public key.

[0062] Regarding the possible agents associated with a particular state of the contract, further selection is made: the agent association stage. One or more agents are the parties assigned to execute (use) the UTXO. The associated agents provide one or more agent public keys. One or more agents may be state-dependent in the context of the DFA. One or more agents may be a subset of all the agents: a listing. One or more agents are different from the computing agents used to interface with the DFA, as will be described later. Therefore, the agent association stage is an assignment step and is immediately implementable.

[0063] The information public key with metadata therein, which is the output from the metadata configuration stage, and the agent public keys from the agent association stage are used in the next stage, the combination stage. In the combination stage, the two public keys (and thus the metadata within the information public key) are combined within the P2SH multisignature Redeem script. The public keys are used to generate the lock script. The lock script is then, in turn, replaced by the scriptPubKey, which is the hash of the lock script.

[0064] In the next stage, the scriptPubKey value acquisition stage, the scriptPubKey values of one or more hashed lock scripts from the combination stage are established. FIG. 1 shows the configuration of the scriptPubKey from which values can be directly obtained in the context of a P2SH transaction. These scriptPubKey values then operate as keys for the combinations that are ultimately mapped. At this stage, the keys have known relationships to the respective codes or tags of interest. The other parts of the combination that are ultimately mapped are discovered in the search and matching stages described later.

[0065] The mapping of the combination is configured in a search term database: the database formation stage. The search term database is external to the blockchain. As a result, a dictionary is provided by mapping the keys representing the values from the scriptPubKey with the respective codes or tags of interest. A dictionary, which is a structure capable of mapping a set of keys to values, is more naturally implemented as a hash table.

[0066] It should be noted that the specific form of the database used is not essential to the present invention and should not limit the scope of the present invention.

[0067] If the system in question is decentralized in the case of the DFA implementation of FIG. 4, each node of the network can access the search term database (locally or remotely), or it can also be implemented in a distributed manner as a standard distributed hash table.

[0068] The database formation stage 510 can be executed using a Python dictionary, a built-in data type that implements the concept of a hash table.

[0069] In the script hash address derivation stage, which is the next step, the script hash address is derived from the scriptPubKey value (step 512). In an exemplary approach, for P2SH, when generating the script hash address, HASH160 is used (which means applying SHA256 first and then RIPEMD160). To the result of these operations, a "version byte" value indicating that network 1 is being used (mainnet, testnet, etc.) is added (at the beginning of the string). Next, there is the calculation of the "checksum". This is the overall HASH256. Next, the process concatenates both strings and encodes the result in base 58. This is the P2SH address. If a different method is used for the script, all of these will change. Therefore, this is not the essence of the present invention and does not limit the scope of the present invention.

[0070] The description of the steps at the technical level gives a simplified script of (pseudo) code. The language used in these scripts is Python3, but usually, this should not mean a limitation of the scope of the present invention or its development method. Figure 2 presents the configuration of the metadata, the combination of the metadata having the public key of the agent into the P2SH Redeem script, and the pseudo code of the scriptPubKey and the address. In fact, it is the above-mentioned metadata configuration stage, combination stage, scripPubKey value acquisition stage, and script hash address derivation stage.

[0071] Once the script hash address is obtained, the process proceeds to add the address to the wallet: the wallet formation stage. It is desirable for the address to be added to a specific contract account within the wallet being used.

[0072] The search and matching algorithms utilized can then be initiated from the wallet to search for UTXOs that match these addresses: the search and matching stage. The matching reflects not only the matching agents but also the matching contract states. The search and matching stage can be achieved by standard Bitcoin Core client commands. Many search and matching algorithms are suitable for this purpose. For example, all UTXOs can be searched using a loop.

[0073] When the algorithm discovers a script hash address within the UTXO set that matches the script hash address being searched, the scriptPubKey within the UTXO set of interest is discovered. This can be extracted and then mapped to the external database described above. The UTXO is mapped to a key by its own scriptPubKey and thus back to the code or tag and thus the original information of interest, representing a particular state in a preferred embodiment.

[0074] The matching in this final stage provides the system with a clear determination of which state tags are present within the UTXO. That is, substantially, the state is detected. The matching process is repeated for all UTXOs that have a matching script hash address and thus a key and thus a state tag.

[0075] An explanation of this mapping of the actually known information, i.e., the values (contracts and state tags in our example) to the keys stored in the blockchain UTXO, which are in fact pointers to the values, is given in Figure 3. Note that if the structure used for the database is a hash table, additional hashing of the keys occurs before accessing the values of the desired information. This represents the general case and is not illustrated.

[0076] Also in this case, since the mapping is in effect a dictionary generation process, this can be implemented using the Python dictionary, a built-in data type that implements the concept of a hash table.

[0077] Search wallet change If non-conventional / special software is avoided in the implementation of the state transition detector or, more generally, in information retrieval, it is advantageous in terms of overall simplicity and ease of implementation. Of course, such software can be provided as an alternative.

[0078] In this context, it is important to note that only UTXOs accessible through the Bitcoin Core client (a standard user interface suitable for use) are associated with the addresses included in the user's Bitcoin wallet. In the search process, the keys being sought do not necessarily meet that criterion. To address this, before the wallet becomes available to search the UTXO database for keys that are also included in an external database, it is necessary to construct the Bitcoin addresses associated with the corresponding scriptPubKey values. This is achieved by the hashing and formatting processes described above. Once they are constructed, they then need to be added to the search user's Bitcoin wallet.

[0079] In the case of our example of a blockchain-based DFA that implements a specific contract, it is furthermore natural and convenient to associate the addresses related to the contract, on the one hand, with a specific account, a subset of the wallet. However, this last step is not strictly necessary and can be incorporated as a specific feature of our design that provides additional effects and structure. Thus, this does not mean limiting the scope of the present invention.

[0080] Context of use of the present invention The ability to extract known information is desirable in many contexts. Such contexts can include situations where metadata is incorporated into a blockchain. Examples can include tokenization or "colored coins" used to represent other assets such as stocks, securities, coupons, ownership rights, commodities, tokens, data, etc.

[0081] One particular context where the ability to discover and extract information is important is a blockchain-based DFA where the information can be the state of a machine.

[0082] Further details of the use of DFA in the implementation of smart contracts are given in the next chapter.

[0083] Use of DFA This chapter is provided with reference to a DFA implementing a smart contract to provide background on how useful a DFA can be.

[0084] In the context of this description, a definition of a DFA that models a process or task such as a contract is given. The DFA interacts with an associated system of computing resources, which may be referred to as computing agents or "bots". These computing agents are configured to generate transactions and submit them to the blockchain. This embodiment of the DFA relates to a contract, but the use of the DFA is not limited to contracts.

[0085] Referring to FIG. 4, the present invention provides the realization of a process as an abstract DFA embodied on a computing platform - blockchain - that includes hardware and software components.

[0086] Figure 4 provides an overview of a system configured in accordance with an embodiment for the description of the present invention. The system has a computing agent 3 that can interact with other entities 4 (e.g., humans or other computers) to receive instructions. These instructions can be, for example, which smart contracts to generate and execute. Thus, the computing agent 3 interacts with the physical world and, outside of themselves, in the "real world", by responding to and causing events, implements the present invention.

[0087] The specification of the contract itself can be provided in any machine-executable format, such as xBRL, and stored in a secure and decentralized manner, for example, within a distributed hash table (DHT) 5 on a torrent network. From the contract specification, the computing agent constructs the DFA 2. The DFA 2 is later instantiated on the blockchain 1 by one or more agents.

[0088] The DFA 2 itself is specified as a finite set {S, I, t, s0, F}. Here, S is the (finite) set of possible states in which the contract / DFA can exist, and I is the (finite) set of inputs (also known as the alphabet) that can occur in the context of this specification in relation to the contract, for example, payment is made, the maturity of a security is reached, the counterparty defaults on its debt, etc. In the mechanism of the present application, these input signals are received / generated by one or more agents, which then determine the next state of the system (possibly the same state).

[0089] The third component of the DFA is the transition function t: S × I → S. The term "deterministic" in "DFA" represents the uniqueness of determination: given a state and an input, there exists a unique new state (possibly the same state). Thus, given an initial state (S0) and an input history, the result of the computation (contract) is a unique one among the set of all possible final results (F ⊆ S). When all these elements are established, the DFA is completely defined by a transition table, specifying the future state for all possible current states and input signals. The states of the DFA are themselves associated with unused transaction outputs (UTXOs) on the blockchain. As is conventionally known, the Bitcoin network constantly tracks all available UTXOs. According to an embodiment, the mechanism by which the DFA transitions from one state to another is embodied (implemented) according to the present invention by a blockchain transaction. In fact, a transaction on the blockchain uses a UTXO associated with a certain state (the input of the previous transaction) and generates a UTXO associated with the next state (the output).

[0090] <Example: Discount (Zero - Coupon) Bond> For illustration purposes, consider below a discount (zero - coupon) bond, which is typically a simple bond that is purchased at a price (usually at a discount to its face value) and then held for a specific period until its principal is repaid at maturity. The possible states to consider are S = {s0, f0, f1}, representing the holding state (s0), the normal termination of the contract (lucky path) or a happy ending (f0), and the state of failure, e.g., litigation (f1), respectively. The final states of the system are thus F = {f0, f1}. The alphabet to consider is I = {r, d, e}, representing the repayment of the principal at (or before) maturity (r), the issuer's default at (or before) maturity (d), and the termination of the contract without repayment (e), respectively. The transition matrix for this simple contract is shown in Table 1.

[0091] [Table 1] Transition Table of DFA Representing Zero-Coupon Bonds

[0092] [Table 1] Note that the final states represent the completion of the contract, and thus no further states need to be specified from them (currently shown as '-' in the transition table, but these lines can be omitted). In principle, more states and / or inputs (as well as actions) can be defined for this security, but this is not done in this specification for simplicity and clarity in order to explain the basic novel aspects of the present invention, rather than inserting distracting details related to the complexity of the contract.

[0093] Figure 5 represents an embodiment of a zero-coupon bond DFA on the (Bitcoin) blockchain. States are represented by circles, and Bitcoin transactions that transfer the machine from one state to another are represented by blue triangles. Inputs received by the agent are omitted in Figure 5, but in each state, one or other transitions should occur according to these inputs, which is reflected in the figure by the composition of one or other Bitcoin transactions (e.g., t0 or t1 in state s0), noting that no transaction is required for transitions that do not change the state, and thus they are omitted. In addition to the transition transactions (t i ), an initial generation transaction (o), and a transaction corresponding to the completion of the contract (c i ) are considered.

[0094] Attention is now directed to the flow of funds in a transaction (occurrence, transition, and completion). Importantly, due to the finiteness of the DFA and (financial) contracts, one notices that the process completes after a number of transitions. This does not necessarily mean that the maximum costs of contract establishment and execution are combined and can be determined in advance, e.g., at the time of establishing the DFA (assuming some finite fees for the computing agents and Bitcoin miners involved). This is given by the total amount of funds required to execute a contract following the longest possible path. This, of course, rules out the possibility of an infinite loop during execution, but note that this is not related to current (financial) contracts, and that even contracts like perpetual bonds, despite their name, are bonds that should complete at a specific future point in time, e.g., when the entity with the liability ceases to exist or when inflation makes the payment negligible.

[0095] It should be noted that the above-described embodiments do not limit the present invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs enclosed in parentheses shall not be construed as limiting the claims. The terms "comprising" or "comprises" etc. do not exclude the presence of elements or steps other than those listed in any claim as a whole and in the specification. In the present specification, "comprises" means "includes" or "consists of", and "comprising" means "including" or "including of". The reference to a single element does not exclude the presence of a plurality of such elements, and vice versa. The present invention can be implemented by hardware having a plurality of distinct elements or by a computer appropriately programmed. In a claim of an apparatus listing a plurality of means, these plurality of means can be implemented by one and the same hardware element. The fact that specific amounts are recited in mutually different dependent claims does not indicate that a combination of these amounts cannot be used advantageously.

Claims

1. 1. A computer-implemented method for establishing information about a plurality of states of a machine-executable contract implemented on a blockchain, the method comprising: determining information of interest and a number of codes or tags identifying said information of interest; configuring metadata associated with the plurality of codes or tags; determining one or more agents to be associated with the interest information; incorporating the metadata associated with the plurality of codes or tags into a public key; combining the public key with a multi-signature Redeem script to generate one or more hashed lock scripts, the one or more agent public keys being provided by one or more agents, the hash of each lock script being designated a scriptPubKey; obtaining a scriptPubKey value linked to the interest information for the one or more hashed lock scripts to provide one or more keys; constructing a database capable of mapping one or more of said scriptPubKey values ​​to said one or more keys; deriving one or more addresses from the one or more scriptPubKey values; searching the blockchain for one or more matches with the one or more addresses to obtain details of unspent outputs (UTXOs) in the blockchain that match the one or more addresses; determining information of interest present in said unspent output (UTXO) if one or more matches are found; The method includes:

2. establishing a digital wallet with the one or more addresses; 2. The method of claim 1 , wherein searching the blockchain for one or more matches with the one or more addresses comprises searching the blockchain for one or more matches with the one or more addresses from the digital wallet.

3. The method of claim 2 , wherein the step of configuring the digital wallet with the one or more addresses comprises the step of configuring an account or folder within the digital wallet with the one or more addresses.

4. The method of any of claims 1 to 3, wherein the machine executable contract is implemented using a deterministic finite automaton.

5. The method of any of claims 1 to 4, wherein the one or more agents are configured to execute at least one unspent output (UTXO) from the machine-executable contract.

6. The method according to any one of claims 1 to 5, wherein the public key is designated an information public key.

7. The method according to any one of claims 1 to 6, wherein the multi-signature Redeem script is a P2SH multi-signature Redeem script.

8. The method of any one of claims 1 to 7, wherein the database is external to the blockchain.

9. The method according to any one of claims 1 to 8, wherein the database is implemented as a hash table.

10. The method according to any one of claims 1 to 9, wherein the one or more addresses are script hash addresses.

11. A computer-implemented system configured to perform the method according to any of claims 1 to 10.

12. At least one computing agent configured to perform the DFA via a blockchain; Blockchain platform and The system of claim 11 further comprising:

Images