System and method for implementing deterministic finite automaton (DFAs) via blockchain

Abstract

The invention relates to a technique for implementing, controlling and automating tasks or processes on a blockchain. The present invention is particularly suited for, but not limited to, automated execution of contracts, such as smart contracts of financial protocols. However, other types of tasks and non-financial contracts may be implemented. The present invention can be regarded as implementation or embodiment of a state machine or DFA on a blockchain by using unspent outputs of blockchain transactions to represent the state of a machine and taking these output costs as transitions of the machine from one state to another. Technical implementations and implementations of a computational mathematical model envisaged as an abstract machine that can be in one of a finite set of states and can change from one state to another (transition) when a trigger event of the finite set (referred to as an input) occurs. The present invention includes coding and coding techniques for DFA implementation.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201780066408.0, application date October 27, 2017, and name “System and method for implementing deterministic finite automata (DFAs) via blockchain”. Technical Field

[0002] The present invention generally relates to systems and protocols for automating the execution of computer-based process computer protocols, and more particularly to the verification, enforcement and / or execution of conditional control processes (such as, for example, those related to contracts). However, the present invention is not limited to use in connection with contracts. The present invention also relates to blockchain technology and can be used to benefit from smart contracts. Background Art

[0003] It has long been desirable to use computers to automate and control the execution of tasks and processes. This is particularly true, for example, in the execution of agreements between parties (e.g., parties involved in financial agreements). Smart contracts have been a topic of academic research and practical significance since it was recognized that the electronic version of the essence of the contract can be better defined by a computer and then executed and enforced. A key problem with modern contract management is that it is often ad-hoc, where local storage and copies of contracts are maintained manually. These copies may be out of sync with each other and require their own storage and maintenance. This is inefficient and can cause problems related to security and cost. These problems can be solved at least in part by automating the execution of machine-readable and executable files (sometimes referred to as "smart contracts" in the art). This automated solution also helps to minimize possible ambiguities and interpretations caused by natural language and legal terms. Therefore, if the contract is automated, it can be executed in a more efficient and reliable manner at a lower cost.

[0004] Among the different approaches that have been proposed in the literature, it has been shown that deterministic finite automata (DFA), also known as deterministic finite state machines, have a sufficiently rich structure to represent a large range (if not all 2 / 33) of conceivable financial agreements as well as other types of contracts. The concepts of finite state machines and DFAs are well known in computing science. A DFA is a computational mathematical model conceived as an abstract machine that can be in one of a finite set of states and can change from one state to another (transition) when a triggering event or condition occurs. Its computational power is higher than that of combinatorial logic, but lower than that of a stack machine.

[0005] Automated execution of contracts has also recently been studied with respect to blockchain technology. One example is CN 105893042A, which discusses the use of blockchain as a secure storage facility for data related to state changes that occur during the execution of smart contracts. However, blockchain technology, transaction outputs, and their associated scripts can be used in more sophisticated and technically complex ways to provide more intelligent behavior, as discussed herein.

[0006] Blockchain is a computer-implemented, decentralized, distributed peer-to-peer computer system that consists of immutable blocks, which in turn consist of transactions. It involves a consensus-based protocol. Each block contains a hash of the previous block, so that blocks are linked together to create a tamper-proof and permanent record of all transactions that have been written to the blockchain since its inception. These blocks can be viewed publicly, but once they become part of the blockchain they cannot be changed or deleted because changes will cause the hash to change.

[0007] Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. Each unspent transaction (called a UTXO) can be spent as an input to a new transaction, so the chain grows over time. Each output has an associated amount of currency that can be spent to an address on the network as long as it meets the requirements specified in the output's locking script. An address is the public key of a cryptographic asymmetric key pair. Some outputs (such as pay-to-public-key-hash (P2PKH) outputs) are outputs that pay their value directly to an address (public key), while outputs in some transactions (such as pay-to-script-hash (P2SH) transactions) are associated with a public-key script (also called an unlocking script) containing the hash of a second script, which is the redemption script that the recipient must provide in a subsequent transaction along with his signature in order to spend the output.

[0008] It should be noted that the present invention is not limited to use with a particular blockchain, and alternative blockchain implementations also fall within the scope of the present invention.

[0009] Computer protocols known as “smart contracts” have begun to attract attention because they can partially or fully automate the enforcement or execution of contracts. Blockchain-implemented smart contracts can provide 3 / 33

[0010] Many benefits are offered, such as enhanced security, a tamper-proof and permanent public record of events, and reduced transaction costs.

[0011] It would therefore be desirable to provide a solution that provides the benefits of automation of processes (e.g., contracts) and the benefits of using blockchain for that automation. Summary of the invention

[0012] This improved solution has now been devised.The invention is defined by the appended claims.

[0013] According to the present invention, a blockchain-implemented method / system may be provided. This may be described as a method / system for automating the execution and control of a technical process. The present invention may provide a technical innovation that facilitates the automated execution of a process via the implementation or actual embodiment of a finite state machine or DFA on a blockchain infrastructure. The state of the machine may be defined and determined. The conditions or triggers for each state transition may be stored. While the process is being executed, the state of the execution may be recorded on a permanent blockchain ledger.

[0014] Blockchain transactions can have the function of agents or participants moving machines from one state to another. Each state transition can represent or correspond to a step in a process. When DFA defines a contract, the present invention can provide a mechanism for automatically executing and enforcing the commitments of different parties and other terms and regulations.

[0015] Additionally or alternatively, the invention may be described as a method / solution of using blockchain to control a computer-implemented process that is being executed outside the blockchain. It may therefore include interactions based on computer systems that are very different in their architecture and protocols. One or more of the above features may be used in accordance with this aspect of the invention.

[0016] One or more embodiments of the present invention may provide a method for implementing (embodying or realizing) a DFA on or with a blockchain. The DFA may be a software-based DFA. Additionally or alternatively, it may be a method arranged to be able to determine the state of a DFA implemented by a blockchain. This may be the current state. The method may enable dynamic (at runtime) determination of the state of a DFA. Therefore, one or more aspects of the present invention may provide a mechanism for implementing a DFA on a blockchain in a more accurate, sophisticated, and intelligent manner, rather than simply serving as a secure storage facility for recording data about events that have occurred.

[0017] It can include the following steps: 4 / 33 of the unspent output (UTXO1) of the blockchain transaction (Tx1)

[0018] A portion of the locking script is associated with a given state of the DFA. The portion of the locking script may be a portion of data within the locking script. It may be a portion of metadata. It may be an identifier, a label, or a tag. The aforementioned given state of the DFA may be the state that the DFA has been and / or is currently at a given point in execution.

[0019] Thus, the present invention may use unspent transaction outputs (UTXOs) on the blockchain to record and identify the state that a DFA has been and / or is currently in at a given point in execution.

[0020] The method may include the following steps:

[0021] Another transaction (Tx2) is used to cause the DFA to transition from the state to another state by spending the output (UTXO1) of the transaction (Tx1). The other state may be associated with a portion of the data provided in the locking script of the unspent output (UTXO2) of the other transaction. Thus, spending UTXO may cause the change in the state of the DFA to be recorded or reflected in the blockchain.

[0022] The method may include the following steps:

[0023] A portion of code is used to implement or represent at least one state transition trigger condition (trigger), which, when executed, causes another transaction (Tx2) to spend the output (UTXO1) of the transaction (Tx1) and thereby move the DFA to another state.

[0024] The portion of code may include a machine testable condition that provides a Boolean result based on an input signal. The input signal may be determined at runtime and may be used by the portion of code to determine whether the unspent output (UTXO1) should be spent in order to move the DFA to another state.

[0025] The partial data in the unspent output (UTXO1) may be provided in a locking script.

[0026] The portion of data may be a tag, an identifier, a label, or a portion of metadata.

[0027] DFA can be a model for machine-executable smart contracts.

[0028] The unspent output (UTXO1) may include a locking script comprising a puzzle hash whose solution must be provided by an input of another transaction in order to spend the output (UTXO1) and transition the DFA to another state.

[0029] The unspent output (UTXO1) may include a locking script that includes a redemption script hash that must be provided by an input of another transaction in order to spend the output (UTXO1) and transition the DFA to another state. The redemption script may include an encryption key.

[0030] 5 / 33

[0031] The method may include the step of using one or more computing agents to perform any of the features described above or below.

[0032] The present invention also provides a system for implementing the method of any of the above embodiments. The system may include:

[0033] Blockchain platform;

[0034] At least one computing agent for implementing the DFA via the blockchain.

[0035] Additionally or alternatively, the method may comprise the following steps:

[0036] At least one condition is executed using at least one input signal, and an action is executed according to a state transition table of the DFA based on a result of the execution of the condition.

[0037] The execution of the action is identifiable or detectable from the state of the blockchain ledger. This can be done by viewing /

[0038] This is accomplished by analyzing the output of one or more blockchain transactions. If a transaction involves a DFA and / or a contract to which the DFA refers, the output can be checked to determine whether the output has been spent. The state of the DFA can be discerned from the fact that the output remains unspent. This can be seen by consulting a state transition table that has been designed for the DFA. It can be designed prior to executing the method / system.

[0039] An action can be performed using a transaction (Tx) on the blockchain. The action can be identified from the output and / or input of at least one transaction on the blockchain.

[0040] The method may include the steps of analyzing the state of the blockchain to determine the current state of the DFA based on whether an action has been performed.

[0041] DFA can represent or simulate the execution of a contract. The contract can be a machine-executable smart contract.

[0042] The at least one input signal may be a signal or value generated and / or provided by a human or non-human source. For example, it may be generated by the computer on which the method is executed, such as a time or date derived from a system clock. It may be received from a source external to the computer, such as from a remote sensor or remote computing resource.

[0043] The at least one input signal may provide a trigger condition for the DFA to transition from one state to another, or may cause the trigger condition to "fire" or become activated, thereby causing subsequent actions.

[0044] The method may include the following steps: determining a state transition table for the DFA. The state transition table may be encoded in software. The software may include instructions related to given input signals and the state transitions and / or machine executable actions they trigger.

[0045] 6 / 33

[0046] The method may include the steps of associating a portion of (the data in) a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA. The method may include the steps of using another transaction (Tx2) to cause the DFA to transition from the state to another state by spending the output (UTXO1) of the transaction (Tx1). The another state may be associated with a portion of the data provided within the locking script of the unspent output (UTXO2) of the other transaction.

[0047] The method may include the steps of implementing or representing at least one state transition triggering condition using a portion of code including the at least one computer executable condition, which, when executed, causes another transaction (Tx2) to spend an output (UTXO1) of a transaction (Tx1) and thereby move the DFA to another state. The portion of code may include a condition that provides a Boolean result based on an input signal.

[0048] The method may include the following steps: Maintaining a record of the number of times a particular state has been occupied by the DFA. The record may be maintained using an index that is incremented within a loop or iteration structure. The loop or iteration structure may terminate when a predetermined condition is met.

[0049] A software-implemented DFA may be implemented and / or executed using a distributed architecture or system.The present invention may also provide a system for implementing any embodiment of the method described above or below.

[0050] The present invention may provide a software-implemented DFA comprising software for:

[0051] At least one condition is executed using at least one input signal, and an action is executed according to a state transition table of a DFA based on the execution result of the condition; wherein the execution of the action is identifiable from the state of the blockchain ledger.

[0052] The present invention may provide a method comprising the steps of associating a portion of a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of a DFA. The portion of the locking script may be a portion of data within the locking script. It may be a portion of metadata. It may be an identifier, a tag, or a label. Thus, the present invention may use an unspent transaction output (UTXO) on a blockchain to record and identify the state that a DFA has been and / or is currently at a given point in execution.

[0053] The method may include the following steps: using another transaction (Tx2) to cause the DFA to transition from the state to another state by spending the output (UTXO1) of the transaction (Tx1). The other state may be associated with a portion of data provided in a locking script of an unspent output (UTXO2) of the other transaction.

[0054] Therefore, spending UTXO may cause changes in the state of the DFA to be recorded or reflected in the blockchain.

[0055] 7 / 33

[0056] The invention may be substantially as described below in relation to the "Coding Technology" section of the specification, but may also incorporate features from other parts of the document and incorporating any features described herein.

[0057] Additionally or alternatively, the present invention may include the steps of executing a program for monitoring and / or receiving an input signal and, in response to the input signal, generating a blockchain transaction Tx2 that includes an unspent output (UTXO) and spends the output of a previous transaction Tx1.

[0058] The output of the previous transaction Tx1 may include a locking script including an identifier associated with the first state of the DFA; the unspent output (UTXO) of transaction Tx2 includes a locking script including another identifier associated with another state of the DFA. The identifier may be a tag, label, or method in any form or format for identifying a state. It may include a portion of data, such as metadata or an encryption key.

[0059] The program may include an identifier associated with a first state of the DFA. The program may be used to generate and / or execute another program, the other program including another identifier associated with another state of the DFA and included in the UTXO of another transaction Tx2.

[0060] DFA can simulate or represent the execution of a (machine-executable) smart contract. Smart contracts can be generated by computer-based resources by filling in template contracts with parameters. Therefore, contract generation can be automated.

[0061] The method may include the steps of determining a state transition table for the DFA and storing the state transition table in a computer-based storage resource.

[0062] The program may be used to generate a blockchain transaction Tx2 in response to an input signal in the following manner:

[0063] Use the identifier in the locking script of blockchain transaction Tx1 to determine the current state of the DFA;

[0064] Based on the current state and the input signal, another state and its associated identifier is determined using the state transition table of the DFA.

[0065] The method may include the following steps: submitting the blockchain transaction Tx2 and / or the previous transaction Tx1 to the blockchain network.

[0066] Multiple programs can be generated and executed, each program including an identifier for uniquely identifying a state of the DFA. Thus, a contract can be executed using a series of programs (scripts), each script having a lifespan that substantially corresponds to the duration of the state (i.e., how long the DFA is or may be in that given state).

[0067] 8 / 33

[0068] An unspent output (UTXO) of a transaction (Tx2) and / or an output of a previous transaction (Tx1) may include a locking script comprising a puzzle hash whose solution must be provided by an input of another blockchain transaction in order to spend the output and transition the DFA to another state.

[0069] The unspent output (UTXO) of a transaction (Tx2) and / or the output of a previous transaction (Tx1) may include a locking script that includes a redemption script hash that must be provided by an input of another transaction in order to spend the output (UTXO) and transition the DFA to another state. The redemption script may include a cryptographic key.

[0070] The state of a DFA can be represented by unspent outputs (UTXOs) in transactions on the blockchain. Spending a given UTXO can represent a transition to a different state. States, actions, conditions, and triggers can be provided in a transition table of the DFA and / or encoded in software.

[0071] The present invention can provide a method for implementing a deterministic finite automaton DFA on a blockchain, comprising the following steps: storing a state transition table for the DFA in a storage resource off the blockchain; using the unspent transaction output (UTXO1) on the blockchain to identify the state that the DFA has been or is currently in by associating the unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA in the state transition table; and / or using another transaction (Tx2) to cause the DFA to transition from a current state to another state in the state transition table by spending the unspent output (UTXO1) of the transaction (Tx1), and causing the change in the DFA state to be recorded in the blockchain.

[0072] The present invention can provide a method for implementing a deterministic finite automaton DFA on a blockchain, comprising the following steps: associating an identifier in a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state in a state transition table for the DFA; and, using another transaction (Tx2) to transition the given state of the state transition table of the DFA to another state in the state transition table of the DFA by spending the output (UTXO1) of the blockchain transaction (Tx1); wherein the other state is associated with another identifier provided in the locking script of an unspent output (UTXO2) of another transaction.

[0073] The present invention may provide a method for implementing a DFA using at least one computational agent in conjunction with a blockchain, wherein the DFA is defined by a state transition table that specifies all state transitions for the DFA.

[0074] possible future states of the current state and triggering events, the method comprising the steps of:

[0075] A computational agent that uses at least one input signal to determine whether at least one triggering event has occurred, the at least one triggering event being associated with a current state and a new state from which the DFA will move after the triggering event occurs, the new state being the state in which the DFA will be after the transition initiated by the triggering event; and, based on the result of the determination, performing an action according to the state transition table of the DFA. Wherein: i) the state of the DFA is represented by an unspent output in a transaction on a blockchain; ii) the triggering event results in the spending of an unspent output of at least one transaction on the blockchain, wherein the unspent output is associated with a given state of the DFA; iii) the spending of an unspent output of at least one transaction on the blockchain represents: transitioning to a different state by creating an output associated with a next state.

[0076] The present invention may provide a method for implementing a deterministic finite automaton DFA on a blockchain, comprising the following steps: associating a portion of data in a locking script of an unspent output of a blockchain transaction with a given state of a state transition table for the DFA, wherein the portion of data includes at least an identifier; generating another transaction in response to an input signal in the following manner: using the identifier in the locking script of the blockchain transaction to determine a current state of the DFA, wherein the identifier identifies the current state; and, based on the current state and the input signal, using the state transition table of the DFA to determine another state and its associated identifier; and, using another transaction to cause the DFA to transition from the state to another state by spending the output of the transaction; wherein the other state is associated with another portion of data provided in the locking script of the unspent output of the other transaction; wherein the other portion of data is an encryption key, a portion of metadata, a label, an identifier, or a tag associated with the other state of the state transition table for the DFA.

[0077] The present invention may provide a method for implementing DFA on a blockchain, comprising the following steps: associating a portion of data in a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA.

[0078] The present invention can provide a method for implementing DFA on a blockchain, comprising the following steps: associating a portion of data in a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA; wherein the DFA is associated with a debt note held for a certain period of time.

[0079] The present invention can provide a method for implementing DFA on a blockchain, the method comprising the following steps: using at least one input signal to execute at least one condition, and based on the result of executing the condition: executing an action according to a state transition table of the DFA, the input signal corresponding to at least one state transition; wherein, by analyzing the output of one or more blockchain transactions, the execution of the action can be identified from the state of the blockchain ledger.

[0080] The present invention can provide a method for implementing DFA on a blockchain, which is executed by a processing resource and includes the following steps: determining a state transition table of the DFA and storing the state transition table of the DFA in a computer-based storage resource; consulting the state transition table of the DFA and using an unspent transaction output (UTXO1) on the blockchain to identify the current state of the DFA; and using another transaction (Tx2) to transition to another state by spending the unspent transaction output (UTXO1).

[0081] The present invention can also provide a method for implementing a deterministic finite automaton DFA on a blockchain, comprising the following steps: storing a state transition table for the DFA in a storage resource outside the blockchain; using the unspent transaction output (UTXO1) to identify the state that the DFA has been or is currently in by associating the unspent transaction output (UTXO1) of a blockchain transaction (Tx1) on the blockchain with a given state of the DFA in the state transition table; and / or using another transaction (Tx2) to cause the DFA to transition from a current state to another state in the state transition table by spending the unspent transaction output (UTXO1) of the transaction (Tx1), and causing the change in the DFA state to be recorded in the blockchain.

[0082] Optionally, the unspent transaction output (UTXO1) comprises a locking script comprising an identifier associated with a given state of the DFA. Optionally, the unspent transaction output (UTXO2) of the other transaction (Tx2) comprises a locking script comprising another identifier associated with the other state of the DFA.

[0083] Optionally, the method further includes: in response to an input signal, generating the other transaction (Tx2) by: determining a current state of the DFA using an identifier in a locking script of the blockchain transaction (Tx1); and, based on the current state and the input signal, determining the other state and another identifier associated with the other state using the state transition table.

[0084] Optionally, the input signal provides a trigger condition for the DFA to transition from one state to another state.

[0085] Optionally, the method further includes: submitting the other transaction (Tx2) and / or the blockchain transaction (Tx1) to the blockchain network.

[0086] Optionally, the unspent transaction output (UTXO1) includes a locking script, the locking script including a puzzle hash, a solution of which must be provided by an input of another transaction in order to spend the unspent transaction output (UTXO1) and transition the DFA to another state.

[0087] Optionally, the unspent transaction output (UTXO1) includes a locking script, which includes a redemption script hash that must be provided by an input of another transaction in order to spend the unspent transaction output (UTXO1) and transition the DFA to another state.

[0088] Optionally, the redemption script includes an encryption key.

[0089] The present invention may also provide a method for implementing a deterministic finite automaton DFA on a blockchain, comprising the following steps: associating a portion of the data in a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA; wherein the DFA is associated with a debt note held for a certain period of time.

[0090] Optionally, the portion of the data is a tag, an identifier, a label or a portion of metadata.

[0091] Optionally, the DFA is a model of a machine-executable smart contract associated with the debt instrument.

[0092] Optionally, the method further includes: determining a state corresponding to a smart contract associated with the debt note as the state of the DFA.

[0093] Optionally, the method further includes: determining an event corresponding to a smart contract associated with the debt instrument as a trigger condition for transitioning the DFA from one state to another.

[0094] The present invention may provide a system for implementing, realizing or embodying a software-based DFA. It may do so via a blockchain. It may include:

[0095] Blockchain;

[0096] One or more computing agents for generating and / or executing at least one program according to any of the method steps described above or below;

[0097] and a storage resource for storing a state transition table of the DFA; this may be, for example, a hash table or a distributed hash table; and / or

[0098] At least one template for a blockchain transaction and / or at least one template for a smart contract.

[0099] The invention may be substantially as described below in the section entitled "Compiling and Executing a Software-Implemented DFA", although features from other sections of the specification may apply equally.

[0100] The system can be used to implement or realize a state machine on a blockchain execution in order to perform automated execution of (smart) contracts.

[0101] Any feature mentioned in relation to the system of the invention may also apply to the corresponding method of the invention, and vice versa.Any feature mentioned herein in relation to one aspect or embodiment of the invention may also apply to any other embodiment or aspect.

[0102] The blockchain-based DFA of the present invention includes at least the following key features:

[0103] ● Providing a blockchain-based implementation of a computational mathematical model conceived as an abstract machine that can be in one of a finite set of states and can change (transition) from one state to another when a finite set of triggering events (called inputs) occur

[0104] ●Because Deterministic Finite Automata (DFA) are embodied in the computing and storage structure on the blockchain platform, a new technology for establishing and automatically executing contracts is provided based on the technical implementation of the commitments of all parties.

[0105] ●Can use existing blockchain infrastructure and protocols

[0106] ● Implement and promote the automated generation, control and execution of smart contracts

[0107] ●Can be automatically executed and enforced by computers.

[0108] ●Permanent, immutable record of contracts, their execution and outcomes.

[0109] The present invention provides and exploits at least the following benefits inherent to blockchain protocols and platforms:

[0110] ●Inherent security by design (e.g., some blockchain protocols do not require trusted parties).

[0111] ●Distributed, thus avoiding large single points of failure and being less vulnerable to attack.

[0112] ●Easy to manage and maintain (e.g., some blockchain networks are easy to use)

[0113] ● Cheap (e.g., under some blockchain protocols, it is often expected that only very small transaction fees will be incurred)

[0114] ● No geographical restrictions or limitations - anyone with internet access can use it anywhere, anytime

[0115] ● Transparent, once data has been written to the blockchain, anyone can see it.

[0116] ●Immutable, once data has been written to the blockchain, no one can change it.

[0117] ●Maintain privacy and do not involve personally identifiable information. BRIEF DESCRIPTION OF THE DRAWINGS

[0118] These and other aspects of the invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0119] Figure 1 An overview of a system arranged according to one embodiment of the invention is shown.

[0120] Figure 2 An illustrative embodiment of the present invention is shown, in which a smart contract is executed as a DFA implemented on a blockchain using transactions to represent the various state transitions that are triggered; wherein each of the transactions may contain an output whose value is paid directly to an address (a public key of a cryptographic asymmetric key pair). For example, the transaction may be a P2PKH transaction.

[0121] Figure 3 A blockchain-based DFA is shown according to the examples discussed below.

[0122] Figure 4 is a state diagram of a bond of Example 1 of a codification technique that can be used according to one embodiment of the present invention. It shows states (blobs) and transitions (connecting lines) associated with indicated inputs.

[0123] Figure 5 A state diagram for a coupon bond of Example 2 with a recurrent state is shown.

[0124] Figure 6 Shown with Figure 5 An internal state diagram of the recurring states associated with an instance of .

[0125] Figure 7A state diagram for the European Call Option example from the "Compile and Execute" section of this application is shown, showing the states (blobs) and blockchain transactions (triangles) to be committed: Initiate (o), Transition (t), and Complete (c). DETAILED DESCRIPTION

[0126] In this document, we use the term "blockchain" to include all forms of consensus-based electronic, computer-based distributed ledgers, including but not limited to blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variants. It should be noted that the present invention is not limited to use with a specific blockchain, and alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0127] An illustrative embodiment of the present invention includes the definition of a DFA that models a process or task (e.g., a contract), and an associated system of computing resources that may be referred to as agents or "bots." The agents are used to generate transactions and submit them to the blockchain. However, the present invention is not limited to use in connection with contracts.

[0128] Go to Figure 1 , the present invention provides an implementation of a process based on an abstract DFA embodied on a computing platform (blockchain) including hardware and software components. Figure 1 An overview of a system arranged according to an illustrative embodiment of the present invention is provided. The system includes a computing agent 3 capable of interacting with other entities 4 (e.g., humans or other computers) to receive instructions. For example, these instructions may be smart contracts to be created and executed. Thus, the computing agent 3 interacts with the physical world to implement the present invention by responding to and causing events outside of itself in the "real world".

[0129] The specification of the contract itself can be provided in any machine executable format (e.g., xBRL) and stored in a secure and decentralized manner, such as in a distributed hash table (DHT) 5 on a torrent network. Based on the specification of the contract, the computing agent constructs a DFA 2, which is then embodied on the blockchain 1 by one or more agents.

[0130] The DFA 2 itself is specified as a finite set {S,I,t,s0,F}, where S represents the (finite) set of possible states that the contract / DFA can be in; I is the (finite) set of inputs (also known as the alphabet), which in context represents any contract-related events or conditions that may occur, such as a payment being made, a bill maturity date being reached, a counterparty defaulting, etc.; and in our mechanism, these input signals are received / produced by one or more agents, which then determine the next state of the system (which may be the same state).

[0131] The third component of a DFA is the transition function t:S×I→S. The term “deterministic” in “DFA” refers to the uniqueness of the decision: if the state and input are known, there is only one new state (which may be the same state). Therefore, if the initial state (s0) and the input history are known, the calculation result (contract) is unique and is one of the set of all possible final results. Once all these elements are established, the DFA is completely defined by a transition table, which specifies future states for all possible current states and input signals. The states of the DFA are themselves associated with unspent transaction outputs (UTXOs) on the blockchain. According to the present invention, the mechanism by which the DFA moves from one state to another is embodied (implemented) according to the present invention through blockchain transactions. In fact, transactions on the blockchain spend the UTXO associated with one state (the input of the previous transaction) and create a UTXO associated with the next state (output).

[0132] Simple DFA Example: Discount (Zero Coupon) Bonds

[0133] For illustration purposes, we now consider a discount (zero coupon) bond, which is a simple debt instrument that is typically purchased at a price (usually at a discount to its face value) and then held for a period of time until its principal is returned at maturity. A coupon bond is thus a debt obligation for which the holder receives regular interest payments (coupons) from the issuance of the contract until its maturity date, at which time the principal of the bond is paid off in addition to the final coupon.

[0134] The possible states we will consider are S = {s0, f0, f1}, indicating the holding state (s0), the normal end of the contract (if it follows a happy path) or a perfect end (f0), and the state where things go wrong (f1), such as litigation. Therefore, the final state of the system is F = {f0, f1}. The alphabet we will consider is I = {r, d, e}, indicating that the principal is repaid at (or before) maturity (r), the issuer defaults at (or before) maturity (d), and the contract expires without being repaid (e). The transition matrix for this simple contract is shown in Table 1.

[0135] t r d e <![CDATA[s0]]> <![CDATA[f0]]> <![CDATA[f1]]> <![CDATA[f1]]>

[0136] Table 1 - Conversion table showing the DFA for a zero coupon bond.

[0137] It should be noted that the final states represent the completion of the contract, so no further states need to be specified from them (currently marked as "-" in the transition table, but these lines can be omitted). In principle, more states and / or inputs (and actions) can be defined for the ticket, but for the sake of simplicity and clarity, this is not done in this document to illustrate the basic inventive aspects of the invention without instilling distracting details related to the complexity of the contract.

[0138] Figure 3 Represents an embodiment of a zero-coupon bond DFA on a blockchain. States are represented by circles, and transactions that move a machine from one state to another are represented by blue triangles. Note that Figure 3 The inputs received by the agent are omitted in , but in each state one or the other transition should be made depending on these inputs, which is reflected in the diagram by constructing one or the other transaction (e.g., t0 or t1 in state s0); transitions that do not change the state do not require transactions, so they are omitted. i ), the initial initiating transaction (o) and the transaction corresponding to the contract completion (c i ).

[0139] We now turn our attention to the flow of money in a transaction (initiation, transformation, and completion). An important observation is that, due to the finite nature of DFAs and (financial) contracts, the process described will be completed after a number of transformations. This necessarily implies that (assuming some finite cost for the computational agents involved) there must be a maximum cost of establishing and executing a contract, and that it can be determined in advance, e.g., when the DFA is established. It is given by the amount of money required to execute the contract following the longest conceivable path. Of course, this excludes the possibility of infinite loops in execution, but note that this is irrelevant for current (financial) contracts, which, even perpetual annuities, must be completed at some point in the future, regardless of their name; e.g., when the obligating entity no longer exists or when the payments become negligible due to inflation.

[0140] The specific allocation of fees, i.e. the fees each agent receives for its work, while having practical significance, is not a critical element of the present invention. In our very simple example, all paths are of equal length. Therefore, the final cost of a contract must coincide with its maximum cost. This need not be the case in general. This is in lieu of the final unused funds at completion (i.e. the maximum funds and used funds are different).

[0141] We will assume that the funds to establish and execute the contract are initially provided by some source of funds called the "Originator". In principle, it is also possible to include additional inputs and outputs of funds in the transaction, such as the price paid for a zero-coupon bond, the repayment of principal, or any other conceivable transfer of funds. While this may have practical significance, it only obscures the basic elements of the invention at this point. For the sake of clarity, these details are not included in the examples below. However, it should be noted that the structure described is completely general and does not exclude this possibility.

[0142] Illustrative Implementation of Technical Solution - DFA System and Method

[0143] The skilled person will readily appreciate that the system may be implemented in a variety of ways, wherein such variations still fall within the scope of the invention. For example, the configuration and architecture of the agent system 3 may vary, e.g., if the specific agents involved are known in advance. For ease of illustration, we will consider two technical design options in the text.

[0144] 1. If participation in the contract remains relatively open so that individual computing agents can participate, then a structure based on standard blockchain transactions of the “transaction puzzle” type is possible.

[0145] 2. Instead, if transactions per state can be pre-assigned to a specific proxy (or group of proxies), then transactions can be used; the transactions are associated with a script (also called an unlocking script) containing the hash of a second script, which is the redemption script that the recipient must provide along with its signature in a subsequent transaction in order to spend the output. For example, if transactions per state can be pre-assigned to a specific proxy (or group of proxies), then Pay to Script Hash (P2SH) transactions can be used.

[0146] Blockchain transactions based on puzzles are known in the field of blockchain technology. It is also known in the field of blockchain technology to have transactions associated with a script (also called an unlocking script) containing a hash of a second script, which is a redemption script that the recipient must provide in a subsequent transaction along with its signature in order to spend the output. For example, P2SH transactions are known in the field of blockchain technology. The skilled person will also understand that there may be a variety of possibilities in addition to or as an alternative to the two options described above. For example, an embodiment may use multiple proxies that change over time, and / or multiple proxies at one level, etc. The possibilities are numerous, but we will only describe two options herein, from which the skilled person will easily derive other possible variations and implementation options.

[0147] However, it should be noted that the type of blockchain transaction used in one embodiment is not essential to the present invention, as the party (issuer, purchaser, payee, etc.) providing / receiving funds in a transaction is not fundamental to the present invention. Rather, the key element of the present invention is to define the state of a task / contract at any point in time within the blockchain, and it provides a mechanism (regardless of its detailed specific implementation) that enables the automated generation of contracts, their execution on the blockchain, and the enforcement of appropriate results based on the sequence of events that occurred. Note that since the entire mechanism is implemented on the blockchain, it inherently provides a permanent, immutable record of the history and results of the contract, as well as many other advantages, etc.

[0148] Implementation Option 1: Transaction-Puzzle Approach

[0149] In one possible embodiment of the invention, the agent system 3 is used for an open network of computers, where anyone with some internet connection processing power can join and can provide some processing power to the system (e.g., a provider of blockchain-based DFA contract creation and execution) and be paid for their resources. In this case, it is not possible to know in advance which specific agent will submit the transaction to the blockchain, i.e., it is not possible to use any specific information about the agent (e.g., its public key). However, the transaction-puzzle type is suitable for use in this case. The general lock / unlock mechanism for this type of transaction is:

[0150] Locking script: OP_HASH256 <state s i puzzle>OP_EQUAL

[0151] Unlock script: <puzzle s i solution>

[0152] in <state s i puzzle>=HASH( <state s i puzzle solution>) and the puzzle solution itself can include any desired information, including the contract's code, a marker for the state, and any other desired information, such as some salt for added security:

[0153] <state s i puzzle solution>=HASH( <contract code;state s i ;other data;salt>)

[0154] The concept of "salt value" is known in the prior art and will be easily understood by those skilled in the art in the context of the present invention. Figure 1 and 2 , the sequence of actions is as follows. First, the agent system (3, step 101) creates a DFA structure 2.

[0155] The transition table specifies and includes triggering events that move the DFA from one state to another. The transition table includes at least one triggering event or condition for each possible state transition. Thus, the triggering condition is associated with the current state (i.e., the state from which the DFA will move after the triggering event) and the new state (i.e., the state the DFA will be in after the transition initiated by the triggering condition).

[0156] exist Figure 2 In step 102, a puzzle for each possible state of the DFA may be created by a computational agent. The transition table for each transition and its associated puzzle is stored externally. This may be in some kind of database or DHT. The puzzles are securely distributed to the agents that are allowed to participate in the execution of the contract. There are many possibilities for how this distribution can be achieved. In a preferred embodiment, these steps are performed by the computational agent in an automated manner without human intervention.

[0157] At step 104, the proxy creates an initiation transaction to state s0. At this stage, the contract is embodied as a structure on the blockchain and is in its first state s0, i.e., there is a UTXO associated with state s0 of the particular contract on the blockchain.

[0158] The contract is originally funded by a transaction (e.g. a P2PKH type transaction) containing an output that pays its value directly to an address (the public key of a cryptographic asymmetric key pair) (from the "originator" in the example); output 0 (based on the puzzle) can be unlocked by any agent who has the solution to the puzzle; output 1 (which pays its value to an address that is the public key of a cryptographic asymmetric key pair, e.g. a P2PKH) pays the required fee to agent 3 who has successfully placed the transaction on the blockchain.

[0159] The continuous transformations when executing the contract are performed by automated agents 3. The agents are used to obtain, generate or receive the puzzle solution corresponding to the current state (s0). They also interact with one or more entities (e.g., some other computer in the agent system, or some data / signal source) to receive appropriate inputs, read the transformation table (or just the part corresponding to the current state), and obtain the solution corresponding to the appropriate next state (f f ) puzzle. The agent can then submit the transaction to the blockchain. If the transaction is verified by the blockchain network, the agent will receive the associated fee and the DFA will be in state f f .

[0160] The structure of the last possible transaction, that is, the transaction that completes the contract execution (c f ), the input part follows the same transaction puzzle logic as before, while output 0 returns the unspent funds payment to the initiator, and output 1 pays the agent a fee.

[0161] Implementation Option 2: A transaction associated with an unlocking script containing a hash of a redeem script that receives The recipient must provide a redemption script along with his signature in a subsequent transaction in order to spend the output (e.g., a P2SH-based trade)

[0162] The puzzle-based approach described in option one is suitable for situations where there are a large number of a priori unknown participants. However, in other cases, a limited number or an acceptably small number of endorsing computing agents 3 may be specified for use in conjunction with the present invention. In such cases, the following transactions may be more suitable for use: transactions associated with an unlocking script containing a hash of a redemption script, where the redemption script is a redemption script that the recipient must provide along with its signature in a subsequent transaction in order to spend the output, as they can be configured to include the public key of a known agent 3, thereby providing an additional layer of security. For example, the transaction can be a P2SH type transaction. In the case of a single endorsing agent, a feasible locking / unlocking mechanism for the transaction is:

[0163] Locking script: OP_HASH160 <state s i redeem script hash>OP_EQUAL

[0164] Unlock script: OP_0 <agent signature><state s i redeem script>

[0165] Redemption script: OP_1 <state s i metadata><agent public key> OP_2

[0166] OP_CHECKMULTISIG

[0167] It should be noted that this can be extended to a larger number of endorsing agents by also including their signatures. As before, the state s i The metadata can include any desired information, such as:

[0168] <state s i metadata>=HASH( <contract code;state s i ;other data>)

[0169] The sequence of actions is similar to the puzzle-based approach in the previous example. First, the agent system 3 creates a DFA structure, storing the transition table externally (e.g., in a DHT). It then determines which agents will process the transaction and retrieves / generates their public keys, which are then included in the redemption script for each possible state of the DFA. It should be noted that these scripts can be stored externally (outside the blockchain) and do not need to be transmitted securely. Next, the computation agent creates an initiation transaction.

[0170] At this stage, the contract is embodied as a structure on the blockchain and is in its first state s0. The only change in the transaction is output 0, which is now a transaction of the type associated with an unlocking script containing the hash of a redeem script that the recipient must provide in a subsequent transaction along with its signature in order to spend the output, and the transaction includes the public key of the endorsing agent as discussed above. For example, this transaction can be a P2SH type transaction.

[0171] The changes are similar. The flow of funds is the same as before. A transaction associated with an unlocking script containing the hash of a redeem script is used for the DFA state, where the redemption script is the redemption script that the recipient must provide along with its signature in a subsequent transaction in order to spend the output. For example, a P2SH transaction type can be used for the DFA state.

[0172] New compilation technique for computer-implemented DFA

[0173] Having described blockchain-based DFAs above, we now turn our attention to a particularly advantageous and novel aspect of the present invention. In this section, we describe a novel inventive technique for encoding the state of a DFA into a computer-readable and executable form.

[0174] In the traditional way of thinking about such machines, states are statically (a priori) defined and represent a certain configuration of the system or have a certain meaning. For example, they can be given a set of names, associated with a set of tags, or associated with a set of unspent transaction outputs (UTXOs), as explained above for blockchain-based DFAs. This is enough to make the system work, because the computation itself (the output) is determined by how the system moves between states when it accepts a chain of inputs.

[0175] In this sense, a DFA (i.e., a set of states, transitions, etc.) is not unique, and two DFAs can be equivalent, i.e., produce the same output for any given chain of inputs, even though the a priori conceived interpretation of the states may be very different. Consider, for example, the case where they are deployed on different physical machines or are conceived to solve different problems. This also leads naturally to the concept of DFA minimization (see https: / / en.wikipedia.org / wiki / DFA_minimization ).

[0176] While static determination of state (tagging) is sufficient for the abstract functionality of the state machine itself and for many problems related only to computational outputs, there are cases where the meaning of the state itself is of practical importance and cannot be inferred from the state's label. This may be because it is intentionally hidden for privacy or confidentiality reasons, for example. An example can also be found in cases where the computation is distributed and performed by computational agents that (intentionally) do not have full information about the system. In these cases, the state of the system needs to be determined dynamically at runtime.

[0177] One advantageous aspect of the invention described herein is a codification technique that allows the state of a DFA to be determined dynamically (on the fly, at runtime). Such a DFA may include those associated with the distributed execution of a contract as described above, but is not limited thereto, and the invention is not limited to the purposes of the DFA or its specific implementation for use with the inventive technique. Since the traditional approach is to predefine the state in a static manner, the dynamic determination of the present invention is contrary to the traditional approach and provides a completely different technical solution from that known in the art. It is not just using a blockchain to store data about events that have occurred.

[0178] For the description and illustration of the codification technique of the present invention, we will use coupon bonds and perpetual annuities as examples, but the present invention is by no means limited to these exemplary uses or applications. It is equally applicable to non-financial applications and environments. The properties of coupon bonds have been explained above. A perpetual annuity is a stream of payments that has no termination, i.e., the coupon payments continue forever in principle. However, in practice, due to the effect of positive interest compounding, at a certain point, the amount of the coupon is of no practical significance, making the discounted value of the contract practically limited.

[0179] Example 1 of the editing technology of the present invention - simple scenario

[0180] As already explained, a DFA consists of a finite set {S, I, t, s0, F}, representing possible states (S), inputs (I), transitions (t), initial states (S0), and final states (F) (also called receiving states). In addition, a set of actions (a) can be defined, which represent the side effects of the execution and do not determine the output of the computation.

[0181] For the description and illustration of the present invention, we will consider a 3-period coupon bond. The elements (and notation) of the DFA we will consider for this contract can be statically defined as given in Tables 2 to 4. Note that the initial state is designated by S in our notation, and the accepting states are F0 and F1.

[0182] Table 2: Coupon bond contract status list:

[0183] state describe S The contract is established and signed, but execution has not started. <![CDATA[T1]]> Execution starts, waiting for the first coupon payment date. <![CDATA[C1]]> The first coupon payment is due and awaiting payment. <![CDATA[T2]]> Second period, waiting for the second coupon payment date. <![CDATA[C2]]> The second coupon payment is due and awaiting payment. <![CDATA[T3]]> In the third period, wait for the second coupon payment date. <![CDATA[C3]]> The third coupon payment is due and awaiting payment. P Principal repayment is due and awaiting payment. <![CDATA[F0]]> End (accept) state, perfect ending. <![CDATA[F1]]> End (accept) state, a breach occurs.

[0184] Table 3: Contract input list for coupon bonds (event alphabet).

[0185] enter describe t Clock signal: The next payment date has been reached. p Payment has been made. d A default has occurred (no payment has been made).

[0186] All of these inputs can be detected and determined by a computer in an automated manner. In the above example of Table 3, the computer can check whether a certain date / time has been reached, or whether a certain payment has been made via a blockchain transaction. The blockchain can be traversed to check whether there is a transaction on the ledger that made the payment. Since the blockchain provides a permanent, public, and tamper-proof record, this verification can be performed by a computing agent without human intervention.

[0187] Table 4: List of contract actions for coupon bonds.

[0188] action describe <![CDATA[a0]]> Send payment notification. <![CDATA[a1]]> Send a breach notice (e.g., to a lawyer). <![CDATA[a2]]> Send contract completion notification.

[0189] Once these elements are defined, the functionality of the system can be fully specified by a state transition table, where the current (initial / from-) state of the system (rows) together with the appropriate inputs (columns) determine the next (final / to-) state of the system and the actions executed in parallel with the transitions. For our example, this is given in Table 5. Note that execution is understood to start with an initial state (S) and that the only possible final (accepting) states are F0 and F1. Since these states mark the finality of execution, i.e., there are no transitions associated with them, they can be omitted from the rows of the table. An alternative format for the transition table is given in Table 5.

[0190] Table 5: State transition table for a coupon bond. When the system is in a particular state (rows) and a particular input occurs (columns), it transitions to the indicated state and performs the indicated action (state / action); a hyphen indicates that the input is not relevant to a given state, i.e., it is not applicable to the state in question.

[0191] t p d S <![CDATA[T1]]> - - <![CDATA[T1]]> <![CDATA[C1]]> - - <![CDATA[C1]]> - <![CDATA[T2 / a0]]> <![CDATA[F1 / a1]]> <![CDATA[T2]]> <![CDATA[C2]]> - - <![CDATA[C2]]> - <![CDATA[T3 / a0]]> <![CDATA[F1 / a1]]> <![CDATA[T3]]> <![CDATA[C3]]> - - <![CDATA[C3]]> - <![CDATA[P / a0]]> <![CDATA[F1 / a1]]> P - <![CDATA[F0 / a2]]> <![CDATA[F1 / a2]]>

[0192] Another equivalent way to specify the functionality of a state machine is the so-called state diagram, where the states of the system are represented by blocks, inputs and actions are given by attached labels, and transitions are represented by connecting arrows; for our example, it is in Figure 4 . Note that, by convention, the final (accepting) states F0 and F1 are indicated by a blob of double lines. For simplicity, these actions are omitted from this diagram since they are not relevant to the execution of the system. The meaning of the dashed boxes (recurring states) will be clarified below.

[0193] As stated above, although the functionality of a DFA is not strictly necessary, it may be practically necessary to dynamically determine human and computer readable system states and constitute an aspect of the invention described herein. Each state is characterized as a unique set of conditions that occur or do not occur or are unrelated to a particular state. Each condition must be clear and (machine) testable. In other words, there must be a clear computational way to tell whether the condition occurs. In this way, an embodiment of the present invention can interact with the physical world or at least with the world outside the computer on which the software is executed, and can receive values ​​or inputs for testing from one or more external sources. For example, once a date is reached, or a temperature threshold is exceeded as indicated by a sensor, or a notification is received from another computer, etc. These conditions can be tested by the above-mentioned computing agent.

[0194] In our example, this can be achieved with the set of conditions given in Table 6, where the states to be tested are given in the rows and the conditions we define are given in the columns. Each t condition indicates whether a particular date has been reached. For example, the condition denoted t0 means t>t0), and each ci (or p) condition indicates whether the corresponding payment has been made. Note that the payment of coupons (or principal) that have not yet matured is independent of states that occurred before the corresponding maturity date has been reached.

[0195] Of course, it is irrelevant whether to use this condition set or an equivalent condition set, as long as they uniquely determine all possible states, i.e., the chain of true, false or irrelevant values ​​for each state is unique. It should also be noted that, although in this example, we only considered binary (true or false) or irrelevant conditions, these conditions can in principle take multiple values. In addition, in addition to the atomic conditions considered here, each condition can also represent a combined condition, which in turn is composed of several (sub) conditions. All these changes are obvious to the technician and fall within the scope of the present invention.

[0196] The last point to make is Figure 4 Although the diagram is perfectly valid as it stands and should correctly describe the dynamics of the coupon bond, note that state T i and state C i There is an interesting similarity between ; because their meanings are very similar, differing only in the number of time periods or coupons (i) they refer to. Therefore, they can also be represented by a common repeating or recurring state plus additional information indicating the coupons / periods they refer to. This can be naturally extended to states that repeat indefinitely, opening up the possibility of codifying perpetual annuities. The definition of codification schemes with such recurring states is discussed in the next section below.

[0197] Table 6: State definition table. For a particular state, each condition can be true (T), false (F), or don't care (-), and is therefore defined by the set of dynamically testable values.

[0198] state t0 t1 c1 t2 c2 t3 c3 P S F F - F - F - - <![CDATA[T1]]> T F F F - F - - <![CDATA[C1]]> T T F F - F - - <![CDATA[T2]]> T T T F F F - - <![CDATA[C2]]> T T T T F F - - <![CDATA[T3]]> T T T T T F F - <![CDATA[C3]]> T T T T T T F - P T T T T T T T F

[0199] Example 2 of the editing technology of the present invention - Reproduction state

[0200] As mentioned above, some subset of states or coupon bonds (T i and D i states) correspond to very similar interpretations of the state machine states, except that they differ in the number of time periods or coupons (i) they involve; that is, in a sense, they can be viewed as states that are repeated multiple times (e.g., from i=1 to a given imax, where imax=3 in our case). In view of this, it makes sense to simplify the representation of the DFA by including all those states in the recurring states (R) for separate treatment. With this simplification, we present below the contract state list (Table 7), state transition table (Table 8), and equivalent state diagram (Table 9) for our exemplary coupon bond. Figure 5 ) and the state definition table of DFA (Table 9); please note that the other elements of DFA (input and action) have not changed compared to the previous part.

[0201] Table 7: List of contract states for a coupon bond with recurring state.

[0202] state describe S The contract is established and signed, but execution has not started. R Dynamics of recurring status, coupon maturities and payments. P Principal repayment is due and awaiting payment. <![CDATA[F0]]> End (accept) state, perfect ending. <![CDATA[F1]]> End (accept) state, a breach occurs.

[0203] Table 8: State transition table for a coupon bond with recurring states

[0204] t p d S R - - R - <![CDATA[P / a0]]> <![CDATA[F1 / a2]]> P - <![CDATA[F0 / a2]]> <![CDATA[F1 / a2]]>

[0205] Table 9: State definition table. For a particular state, each condition can be true (T), false (F) or don't care (-), and is therefore defined by the value set, with each condition corresponding to one value (not to mention that a condition can in turn have multiple components).

[0206] state t r p S F F - R T F - P T T F

[0207] Of course, all of this simply hides the complexity of the bond dynamics within the recurring state, which must be specified separately. However, in the case of complex state machines, this simplification can be important. An obvious analogy is the introduction of loops in a programming language. The recurring state itself is also defined as a state machine, but note that in this context, the initial and accepting states are replaced by entry and exit points, since the execution of the abstract computation does not represent a start or completion within the recurring state. We present below the contract state list (Table 10), state transition table (Table 11), and state diagram ( Figure 6 ).

[0208] Table 10: List of contract sub-states for the recurring state:

[0209] state describe T The cycle begins, waiting for the next payment date. C Coupon payments are due and waiting to be paid.

[0210] Table 11: Internal state transition table of the reproduction state:

[0211] t p,i<imax p,i=imax d T C - - - C - T / a0,i=i+1 <![CDATA[Exit p / a0]]> <![CDATA[Exit F1 / a2]]>

[0212] The novelty of this approach is the introduction of an index (i) that keeps track of the number of times a state has been occupied. The increment of this index and similar quantities (e.g., the total amount paid) can be computed externally (as below for the codification scheme), or implemented by additional DFA actions, as indicated for state C in Table 11. Note also that the input (alphabet) to the internal state of this recurring state can potentially depend on the internal index (i) and / or similar quantities. As explained before, the potential accepting states of the system have been replaced by exit points. The corresponding equivalent state diagram is in Figure 6 Presented in.

[0213] This codification scheme for recurring states, after expansion, looks very similar to the relevant part of Table 5. However, since the spirit of this approach is not to expand and process each internal (sub)state separately, it seems more natural to not be explicitly presented in a table. Instead, the pseudocode of the algorithm is presented below, which assigns the correct value (true or false) to the variables associated with the state machine codification conditions. Of course, variables associated with irrelevant conditions do not need to be assigned any values. As shown in Table 5 above, each ti condition indicates whether a particular date has arrived (i.e., ti=T means t≥ti), and each ci condition indicates whether the corresponding (i-th) coupon has been paid.

[0214] Below, we provide a pseudocode for an algorithm that assigns appropriate values ​​to variables associated with the conditions of the codification scheme of the internal state of the reproduced state.

[0215]

[0216] The last point to be addressed is the need for a termination point, represented by the exponent imax. While ordinary coupon bonds do have a finite maturity date, perpetual annuities are similar notes that, in principle, exist forever. Using our codification technique of recurring states, this can be achieved with a simple modification of the pseudocode presented below. Note that in this case, although the loop will end when it encounters the first cycle where maturity has not yet been reached, the variables are of course irrelevant and at this point all states are uniquely defined by the codification technique, i.e. there is a combination of true and false values ​​that is unique for each state. The following pseudocode is for a perpetual annuity.

[0217]

[0218] Table 11: Alternative format for the coupon bond state transition table in Table 5:

[0219] from arrive Input / Action S <![CDATA[T1]]> t / - <![CDATA[T1]]> <![CDATA[C1]]> t / - <![CDATA[C1]]> <![CDATA[T2]]> <![CDATA[p / a0]]> <![CDATA[C1]]> <![CDATA[F1]]> <![CDATA[d / a1]]> <![CDATA[T2]]> <![CDATA[C2]]> t / - <![CDATA[C2]]> <![CDATA[T3]]> <![CDATA[p / a0]]> <![CDATA[C2]]> <![CDATA[F1]]> <![CDATA[d / a1]]> <![CDATA[T3]]> <![CDATA[C3]]> t / - <![CDATA[C3]]> P <![CDATA[p / a0]]> <![CDATA[C3]]> <![CDATA[F1]]> <![CDATA[d / a1]]> P <![CDATA[F0]]> <![CDATA[p / a2]]> P <![CDATA[F1]]> <![CDATA[d / a2]]>

[0220] Compile and execute computer-implemented DFA

[0221] In this paper, we describe a new technique for establishing (compiling) and executing contractual agreements based on implementing the commitments of the parties (as well as other terms and provisions) as computational structures (modeled as state machines).

[0222] In this section, we describe one advantageous technical aspect of the system regarding the establishment and execution of such smart contracts via a blockchain. This involves the flow of information between different (computer) agents that will effectively implement the contract. Typically, we refer to this system as a "botnet" (a collection of computing agents), usually without specifying which agent actually performs the described operations. The skilled person will appreciate that there are many ways to make these implementation details effective.

[0223] As mentioned above, we will use the contract of a European call option as an example to illustrate this aspect of the invention. A European call option is an agreement that gives an investor the right, but not the obligation, to buy a stock, bond, commodity, or other asset at a specified price (the strike price) on a specified date (the exercise date). The option writer (seller) promises to sell the asset to the holder (buyer) at that price on that date, if the buyer decides to exercise the option, which would (reasonably) happen if the price of the asset on that date is higher than the strike price. In light of this, we assume that the contract can alternatively be settled by paying the holder an amount equal to the market price of the asset on the exercise date minus the strike price, otherwise no payment is required and the option expires unexercised.

[0224] The standard way to establish and enforce (financial) contracts is to sign a legal document, and for humans to interpret and enforce its provisions, and sometimes to generate disputes. These contracts can be viewed as consisting of a text that defines the terms, and a set of parameter values ​​that are specific to the contract (e.g., exercise date, writer, public key, etc.). These different elements are separated in our system, where the essence of the contract text is converted into an abstract machine DFA, and the set of parameter values ​​for a specific instance of the contract is provided independently, as described above.

[0225] Turning to our example, the DFA computation system consists of a finite set {S, I, t, s0, F}, which represent possible states (S), inputs (I), transitions (t), initial states (s0), and final states (F) (also called receiving states). In addition, the DFA structure itself is not essential, and we consider here the set of actions (a) that require the agent to execute in parallel with the submission transaction. In the following, by convention, the current time (date) will be denoted by t, the expiration date by T, and the price of the asset on the expiration date by S. T Represented by , the execution price is represented by K.

[0226] The main focus in this section of the application is the establishment of computer agents associated with the DFA machine state. These are implemented as computing resources including scripts. It should be noted that the term "script" in this context should not be confused with the script of a blockchain transaction (e.g., an unlocking or locking script). Here, the term "script" is used in a more general computing sense. The technician will easily understand this and interpret the meaning of the term according to the context.

[0227] Agents (scripts) are able to change states, implement transitions, and in parallel, detach other sets of scripts associated with subsequent states. Dynamic (i.e., runtime) identification of DFA states by computer scripts with appropriate capabilities is the main inventive element of this aspect of the invention. For our simplified example, the possible states of a contract and the sufficient conditions for their definition are given in Table 12, where the (XML) markup of the states and the natural (human) language description of the states are also given.

[0228] Note that not all conceivable states are considered in the contract, such as what would happen in the event of bankruptcy, death of the holder, internet shutdown, etc. However, since our current focus in this section is on the analysis of the compilation and execution of the contract, rather than the analysis of the complexity of the DFA itself, our examples are appropriately simple and not too elaborate.

[0229] Table 12 shows the state definition table for this example. For a particular state, each condition can be true (T), false (F), or don't care (-), and is therefore defined by the value set, with each condition corresponding to a value. Note that a condition can in turn have multiple components:

[0230]

[0231] Continuing with the description of the different elements of the abstract DFA, we now turn to the list of inputs. This is also known as the event alphabet. This is a list of events that may occur in relation to the contract, such as reaching an expiration date, receiving a payment, etc. These inputs, together with the set of current states of the DFA, determine the transactions to be submitted to the blockchain and the parallel actions to be performed by the agent; but note that although technically the transition function is an S×I→S mapping, not all inputs are relevant to all states. In our simplified example, these and the (XML) markup and natural language description of the events are given in Table 13.

[0232] Table 13: Contract input list (event alphabet):

[0233] enter Label Natural language description <![CDATA[i0]]> <immature> < / immature> The contract is established and exists and has not yet reached its expiration date. <![CDATA[i1]]> <out of the money> <![CDATA[Reach the maturity date, S T ≤K (no payment required).]]> <![CDATA[i2]]> <in the money> <![CDATA[Reach the maturity date, S T >K.]]> <![CDATA[i3]]> <signature received> Payment transactions are signed by the writer. <![CDATA[i4]]> <signature refused> The deed writer refuses to sign the payment transaction.

[0234] Computationally, events can also be viewed as changes in conditions that define states, although as mentioned above, some events are not relevant to some (or all) states and do not result in state transitions. In the same spirit, a list of possible actions can be specified in Table 14, not all of which are relevant to all states.

[0235] Table 14: Contract action list:

[0236] enter Label Natural language description <![CDATA[a0]]> <no action> No action required <![CDATA[a1]]> <notification> < / notification> Notify all parties of contract completion. <![CDATA[a2]]> <request signature> Create a payment transaction and request the writer’s signature. <![CDATA[a3]]> <litigation triggered> Notify attorney of payment denial.

[0237] All these elements converge in a state transition table, where the current (initial) state of the system (rows) together with the appropriate inputs (columns) determine the next (final) state of the system and the actions to be performed in parallel with the transition. Note that in our DFA, in addition to transition transactions, we also consider completion transactions, which do not put the system in a subsequent state, but rather put it in the accepting state (f), a virtual (e.g., not represented on the blockchain and not associated with any script) state that represents the termination of contract execution. An example of our European call option is given in Table 15, where the initial state is associated with the rows, the inputs are associated with the columns, and each cell contains the subsequent state / action field.

[0238] Table 15: Contract state transition table:

[0239]

[0240] Furthermore, we usually represent the abstract DFA of our instance using a state diagram, such as Figure 7 Note that there is a correspondence between this graph and a (computationally useful) state transition table, so the graph itself contains no additional information. Figure 7A state diagram for a European call option is shown, showing states (blobs) and blockchain transactions (triangles) to be committed: originate (o), transition (t), and complete (c).

[0241] Technical Description

[0242] The DFA compilation mechanism consists of different elements and files, which will be discussed in turn. The computational structure embedded in these files, how the scripts associated with different states generate not only blockchain transactions but also subsequent scripts that fully execute the contract, is the main focus of this part of the application. First, the system uses two source files; in our example:

[0243] DFAEuropean call option-parameters.xml

[0244] DFA European call option-script.py

[0245] Here, we assume, in particular, that the primary language to be used to generate subsequent files and execute contracts is Python 3.5, and that the parameters are provided in XML 1.0 files. Of course, these implementation details are not essential to the present invention, and the skilled person will understand that the use of other standards is equally acceptable.

[0246] The XML file contains a list of parameter fields (specified by XML tags) and their values ​​for the particular contract at hand (i.e. a particular European call option). In our example, it is written manually, but it can also be created automatically, i.e. by a computing resource or agent, or by a person entering the appropriate values ​​via a graphical user interface (GUI), which can also be created in Python.

[0247] The main file of the technical specification of the system is the (Python) main script. This file contains or inserts, when executed, a hard-coded version of the abstract state transition table (possible states, inputs and actions) and hard-coded functions that specify the DFA inputs and actions to be considered (e.g. how to check stock prices, clocks, etc.). If relevant (i.e. for a blockchain-based DFA implementation), it may contain a hard-coded template of the transaction to be submitted to the network by the script.

[0248] As explained above, the state transition table completely determines the DFA at the abstraction level and is the only element required for its functionality. Note, however, that there is a correspondence between the legal text and the DFA state transition table. In addition to these necessary elements, the script may optionally contain / generate different human-readable documents, such as state diagrams, alphabets, etc.

[0249] To compile and execute a blockchain-based DFA contract, a user (human or computer) needs to fill in parameter values ​​and run the main script. Using this hard-coded information about the script and the parameter values, when executed, the script will establish the contract (e.g., place it on the blockchain) and generate one or more computer programs (other scripts) that will be run continuously by the system of computing agents that execute the contract. A possible sequence of instructions that can achieve this is as follows:

[0250] 1. Read parameter values ​​(or enter values ​​directly from the GUI). This loads the parameter values ​​into memory, e.g. in a hash table (HT) structure (called a dictionary in Python) or in a distributed hash table (DHT), e.g. the bitTorrent network (if this offers some advantage)

[0251] 2. Generate a legal contract using the parameters and hard-coded contract template. This document needs to be (digitally) signed by the writer of the option.

[0252] 3. (Optional) Create human-readable documentation for the contract.

[0253] 4. Use parameters and hard-coded input and action functions to generate instances of these functions with appropriate parameter values.

[0254] 5. Load the state transition table in memory (HT or DHT).

[0255] 6. If relevant, create an initiation transaction as specified and submit it to the blockchain network. This can be performed using the Pybitcointools library. As mentioned above, this creates a UTXO in the blockchain that is associated with a specific contract state on the blockchain.

[0256] 7. Create a Python script associated with the initiating state (s0) and run it (on the same or another computer). This agent (or set of agents) will receive / generate appropriate inputs, perform appropriate actions (actions compatible with the state), and ultimately complete the execution of the contract or generate a transition transaction to another state, as well as spin off subsequent scripts that control these states.

[0257] 8. Terminate compilation (main script).

[0258] After the compilation phase is over, the system will thus be up and running. According to one embodiment of the invention, there will be a UTXO associated with the initial state of the contract on the blockchain, as well as one or more agents (Python scripts running on the botnet agents) that will monitor the inputs, prepare to take actions, and generate appropriate transitions that will change the state of the DFA to another state or terminate it.

[0259] The instruction sequence for the conversion is:

[0260] 1. Monitor or generate DFA inputs - function calls, such as checking the clock, receiving messages, etc.

[0261] 2. Once the input is determined, read the transition table for the current state, which will determine the next state and possibly the action to be taken.

[0262] 3. Actions, if any, may be taken on the subprocess or function call, depending on complexity.

[0263] 4. When relevant, create a conversion transaction based on the blockchain and submit it to the blockchain.

[0264] 5. Create and run the Python script associated with the next state.

[0265] 6. Terminate the current script.

[0266] The sequence of instructions to complete the contract is:

[0267] 1. Monitor or generate DFA inputs; these can be subroutines or function calls, such as checking a clock, receiving a message, etc.

[0268] 2. Once the inputs are determined, read the transition table for the current state, which will determine the contract to be completed and possibly the action to be taken.

[0269] 3. Possibly take action on the function call, if any, depending on complexity.

[0270] 4. If relevant, create a completion transaction against the blockchain and submit it to the blockchain; this will spend the last UTXO associated with the contract.

[0271] 5. Terminate the current (and last) script.

[0272] Thus, a DFA is executed by a collection of independent agents (scripts) which in turn receive enough information from previous agents to get back to the original master script and parameter file.

[0273] Thus, according to one embodiment of the invention, contracts are executed by a set of agents (implemented as scripts) and are dynamically generated as the system moves from one state to another. These agents need to access the current state of the system (e.g., as embodied by UTXO on the blockchain), receive or generate appropriate inputs based on events that occur in the real world, take appropriate actions, and execute appropriate transactions. All of this can be implemented in a (e.g., Python) script using appropriately defined functions and existing libraries. For example, in our case of a European call option, it should have access to a clock to check if the contract's expiration date has been reached, and access to the current price of the asset. Given this information, it can decide which is the appropriate input to consider based on the parameters. Given this, and the actions specified in the transition matrix, the agent can decide which blockchain transaction should be generated to put the system in the next state (only one in our case), or to properly complete the execution of the contract.

[0274] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The word "comprising / comprises, etc." does not exclude the presence of elements or steps other than those listed as a whole in any claim or specification. In this specification, "comprises" means "includes / including or consists of / consisting of". The singular reference of an element does not exclude the plural reference of these elements, and vice versa. The present invention may be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be implemented by the same hardware. The mere fact that certain measures are stated in mutually different dependent claims does not indicate that the combination of these measures cannot be used to benefit.

Claims

1. A method for implementing a deterministic finite automaton (DFA) on a blockchain, comprising the following steps: Storing a state transition table for the DFA in a storage resource outside the blockchain; Using an unspent transaction output (UTXO1) on the blockchain to identify the state that the DFA has been or is currently in by associating an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA in the state transition table; and / or Another transaction (Tx2) is used to transition the DFA from a current state to another state in the state transition table by spending the unspent output (UTXO1) of the transaction (Tx1), and the change of the DFA state is recorded in the blockchain.

2. A method for implementing a deterministic finite automaton (DFA) on a blockchain, comprising the following steps: Associating an identifier in a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state in a state transition table for the DFA; and using another transaction (Tx2) to transition the given state of the state transition table of the DFA to another state in the state transition table of the DFA by spending the output (UTXO1) of the blockchain transaction (Tx1); Wherein, the other state is associated with another identifier provided in a locking script of an unspent output (UTXO2) of another transaction.

3. A method for implementing a DFA with a blockchain using at least one computational agent, the DFA being defined by a state transition table that specifies future states and triggering events for all possible current states of the DFA, the method comprising the following steps: determining, by the at least one computational agent, using at least one input signal, whether at least one triggering event has occurred, the at least one triggering event being associated with a current state from which the DFA will move upon occurrence of the triggering event and a new state in which the DFA will be after a transition initiated by the triggering event; as well as Based on the result of the determination, executing an action according to the state transition table of the DFA; in: i) The state of the DFA is represented by the unspent outputs in transactions on the blockchain; ii) the triggering event causes the spending of an unspent output of at least one transaction on the blockchain, wherein the unspent output is associated with a given state of the DFA; iii) Spending an unspent output of at least one transaction on the blockchain represents a transition to a different state by creating an output associated with the next state.

4. A method for implementing a deterministic finite automaton (DFA) on a blockchain, comprising the following steps: Associating a portion of data in a locking script of an unspent output of a blockchain transaction with a given state of a state transition table for the DFA, wherein the portion of data includes at least an identifier; generating another transaction in response to an input signal by: determining a current state of the DFA using an identifier in a locking script of a blockchain transaction, wherein the identifier identifies the current state; and, based on the current state and the input signal, determining another state and its associated identifier using a state transition table of the DFA; as well as Using another transaction to transition the DFA from the state to another state by spending the output of the transaction; wherein the other state is associated with another portion of data provided within a locking script of an unspent output of the other transaction; wherein the other portion of data is an encryption key, a portion of metadata, a label, an identifier, or a tag associated with the other state of the state transition table for the DFA.

5. A method for implementing DFA on a blockchain, comprising the following steps: A portion of data in the locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) is associated with a given state of the DFA.

6. A method for implementing DFA on a blockchain, comprising the following steps: Associating a portion of data in a locking script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA; The DFA is associated with a debt instrument held for a certain period of time.

7. A method for implementing DFA on a blockchain, the method comprising the following steps: executing at least one condition using at least one input signal, based on a result of executing the condition: An action is executed according to a state transition table of the DFA, and the input signal corresponds to at least one state transition; wherein the execution of the action can be identified from the state of the blockchain ledger by analyzing the output of one or more blockchain transactions.

8. A method for implementing a DFA on a blockchain, the method being performed by a processing resource and comprising the following steps: determining a state transition table of a DFA, and storing the state transition table of the DFA in a computer-based storage resource; Consulting the state transition table of the DFA and using an unspent transaction output (UTXO1) on the blockchain to identify the current state of the DFA; and Another transaction (Tx2) is used to transition to another state by spending the unspent transaction output (UTXO1).

9. A system for implementing the method according to any one of claims 1 to 8.

10. The system of claim 9, wherein the system comprises: Blockchain platform; At least one computing agent for implementing the DFA via the blockchain.

Images