System and method for performing deterministic finite automaton (DFA) via block chain

Abstract

To provide a method and a system for performing, controlling, and automating tasks or processes on a block chain, such as, but not limited to, the Bitcoin block chain.SOLUTION: A system for providing the implementation of a process as an abstract DFA embodied on a computing platform-block chain including hardware and software components, has computing agents 3 that can interact with other entities 4 (for example, humans or other computers) to receive instructions. The instructions indicate which smart contract to create and execute. The computing agents 3 interact with the physical world to respond to and cause events in the outside of themselves (the real world).SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to systems and protocols for the automated execution of computer protocols for computer-based processes, and more particularly to the verification, enforcement, and / or execution of condition-controlled processes, such as those related to contracts. The present invention is not, however, limited to use in connection with contracts. The present invention also relates to blockchain technology, such as, but not limited to, the Bitcoin blockchain, and may be used to benefit smart contracts. [Background technology]

[0002] The use of computers to automate and control the execution of tasks and processes has long been desirable. This is particularly true with respect to the execution of agreements between parties, such as financial contracts. Smart contracts are a subject of academic research and practical interest because electronic versions of contractual content can be better defined and, as a result, executed and enforced by computers. One of the main problems with modern contract management is that it tends to be ad hoc, involving manually maintained local stores and copies of contracts. These copies can become out of sync with one another and require their own storage and maintenance. This creates inefficiencies and security- and cost-related issues. These problems can be at least partially solved by automating the execution of machine-readable and executable documents (sometimes conventionally referred to as "smart contracts"). Such automated solutions also help minimize potential ambiguities and interpretations arising from natural language and legal terminology. As a result, contracts, when automated, can be executed at less cost, yet in a more efficient and reliable manner.

[0003] Among the different approaches proposed in the literature, deterministic finite automata (DFA), also known as deterministic finite state machines, have been shown to have a structure rich enough to represent a wide range of (if not all) possible financial contracts. The concepts of finite state machines and DFAs are well known within computing science. A DFA is a mathematical model of computation thought of as an abstract machine that can be in one state among a finite set of states and can change (transition) from one state to another when a triggering event or condition occurs. Its computational power is greater than that of combinatorial logic but less than that of stack machines.

[0004] Automated contract execution has also been explored recently in conjunction with blockchain technology. One example of this is CN105893042A, 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 much more sophisticated and technically complex ways to provide more intelligent behavior, as discussed herein.

[0005] A blockchain is a decentralized, distributed, peer-to-peer computer system implemented by computers that consists of immutable blocks, which in turn consist of transactions. It is associated with a consensus-based protocol. Each block contains a hash of the previous block, and blocks chain together to create a tamper-resistant, permanent record of all transactions that have been written to the blockchain since its inception. Once these blocks are part of the blockchain, they can be publicly inspected but cannot be altered or deleted, as tampering could cause the hash to change.

[0006] Transactions contain small programs known as scripts that are embedded in their inputs and outputs. The script specifies how and by whom a transaction's outputs can be accessed. Each unspent transaction (referred to as a UTXO) can be used as input to a new transaction. Thus, the chain grows over time. Each output has an associated currency amount that can be spent on an address on the network, as long as it adheres to the requirements specified in the output's locking script. An address is the public key of a cryptographic asymmetric key pair. A P2PKH (pay to public key hash) output is an output that pays its value directly to an address (public key). On the other hand, in a P2SH (pay to script hash) transaction, the output is associated with a pubkey script (also known as an unlock script) that contains a hash of the second script, and a Redeem script that the recipient must provide along with their signature in a later transaction to use the output.

[0007] The most widely known application of blockchain technology is the Bitcoin distributed ledger, although other blockchain implementations have been proposed and developed. While Bitcoin is referred to herein for convenience and purposes of explanation, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations are within the scope of the present invention.

[0008] Blockchain technology is known for its use in implementing cryptocurrencies. However, more recently, digital entrepreneurs have begun to explore the use of both the cryptocurrency security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. As a result, computer protocols known as "smart contracts" have begun to gain attention because they can enable the automated execution or execution of transactions, either in part or in whole. Smart contracts implemented by blockchain can offer benefits such as enhanced security, a tamper-resistant and permanent public event record, and reduced transaction costs.

[0009] It is therefore desirable to provide a solution that provides the benefits arising from the automation of processes such as contracts, and the benefits of using blockchain for this automation. Summary of the Invention

[0010] Such an improved solution has been devised.The invention is defined in the accompanying claims.

[0011] According to the present invention, a blockchain-implemented method / system may be provided, which may be described as a method / system for automated execution and control of technological processes. The present invention may provide a technological innovation that facilitates automated execution of processes through the implementation or practical realization of finite state machines or DFAs on a blockchain infrastructure. Machine states may be defined and determined. Conditions or triggers for each state transition may be stored. When a process is executed, the executed states may be recorded in a permanent blockchain ledger. Blockchain transactions may act as agents or participants that move the machine from one state to another. Each state transition may represent or correspond to a step in the process. When a DFA defines a contract, the present invention may provide a mechanism for automated execution and enforcement of the obligations of different contracting parties, as well as other terms and provisions.

[0012] Additionally or alternatively, the present invention may be described as a method / solution using a blockchain to control computer-implemented processes that run outside the blockchain. Thus, the present invention may involve the interplay of very different computer-based systems in terms of architecture and protocols. One or more of the above-mentioned features may be used in accordance with this aspect of the present invention.

[0013] One or more embodiments of the present invention may provide a method for implementing (embodying or realizing) a DFA on or in connection with a blockchain. The DFA may be a software-based DFA. The blockchain may be implemented in connection with a protocol based on Bitcoin or may use another blockchain protocol. Additionally or alternatively, this may be a method configured to enable determination of the state of the DFA implemented by the blockchain. This may be the current state. The method may enable dynamic (runtime) determination of the state of the DFA. Thus, one or more aspects of the present invention may provide a mechanism for implementing a DFA on a blockchain in a more accurate, complex, and intelligent way than simply using it as a secure storage facility to record data about events that have already occurred.

[0014] The invention may include associating a portion of a lock script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA. The portion of the lock script may be a portion of data within the lock script. It may be a portion of metadata. It may be an identifier, a label, or a tag.

[0015] Thus, the present invention may use unspent transaction outputs (UTXOs) on the blockchain to record and identify when and / or currently at a given state that a DFA is running.

[0016] The method may include using a further transaction (Tx2) to transition from a state of the DFA to a further state by using an output (UTXO1) of the transaction (Tx1). The further state may be associated with a portion of data provided in a locking script of an unspent output (UTXO2) of the further transaction. Thus, a UTXO may cause a change in DFA state to be recorded or embodied in a blockchain.

[0017] The method may include using a portion of code to implement or represent at least one state transition trigger that, when executed, causes a further transaction (Tx2) to use the output (UTXO1) of the transaction (Tx1), thus moving the DFA to another state.

[0018] The portion of code may include a machine-testable condition that provides a Boolean result based on an input signal, which may be determined at run time and used by the portion of code to determine whether the unused output (UTXO1) should be used to move the DFA to the further state.

[0019] A portion of the data in the unspent output (UTXO1) may be provided in a lock script.

[0020] The piece of data may be a tag, a label, or a piece of metadata.

[0021] The DFA may be a model of a machine-executable smart contract.

[0022] The unspent output (UTXO1) may contain a lock script with a hash of a puzzle, the solution of which must be provided by a further transaction input to consume the output (UTXO1) and transition the DFA to another state.

[0023] The unspent output (UTXO1) may include a lock script with a hash of a redeem script that must be provided by a further transaction input to spend the output (UTXO1) and transition the DFA to another state. The redeem script may include a cryptographic key.

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

[0025] The present invention also provides a system configured to implement the method of any of the above-described embodiments, which may include a blockchain platform (which may or may not be a Bitcoin blockchain) and at least one computing agent configured to implement DFA with the blockchain.

[0026] Additionally or alternatively, the method may include executing at least one condition using at least one input signal, and performing an action according to a state transition table of the DFA based on a result of the execution of the condition.

[0027] The execution of an action may be identifiable or detectable from the state of the blockchain ledger. This may be accomplished by examining or analyzing the outputs of one or more blockchain transactions. If the transaction is associated with a DFA and / or its associated contract, the outputs may be examined to determine if they have been spent. The state of the DFA may be known from the fact that the outputs have not yet been spent. This may be known by consulting a state transition table devised for the DFA, which is devised prior to execution of the method / system.

[0028] Actions may be performed using transactions (Tx) on the blockchain, where the actions are identifiable from the outputs and / or inputs of at least one transaction on the blockchain.

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

[0030] A DFA may represent or model the execution of a contract, which may be a smart contract.

[0031] 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 being executed, e.g., a time or date derived from a system clock. It may be received from a source external to the computer, e.g., from a remote sensor or remote computing resource.

[0032] At least one input signal may provide a trigger for a transition from one state to another in the DFA, or may "fire" or activate a trigger to cause a subsequent action.

[0033] The method may include determining a state transition table for the DFA. The state transition table may be coded in software. The software may include instructions relating given input signals and state transitions and / or their triggering machine-executable actions.

[0034] The method may include associating a portion of (data within) a lock script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of a DFA. The method may include using a further transaction (Tx2) to transition from the state of the DFA to a further state by using the output (UTXO1) of the transaction (Tx1). The further state may be associated with a portion of data provided in a lock script of an unspent output (UTXO2) of the further transaction.

[0035] The method may include implementing or representing at least one state transition trigger with a portion of code including at least one computer-executable condition that, when executed, causes a further transaction (Tx2) to use the output (UTXO1) of the transaction (Tx1), thus moving the DFA to another state. The portion of code may include a condition that provides a Boolean result based on an input signal.

[0036] The method may include 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 repeat construct. The loop or repeat construct may terminate when a predetermined condition is met.

[0037] A software-implemented DFA may be implemented and / or performed using a distributed architecture or system. The present invention may also provide a system configured to implement any embodiment of the method described above or below.

[0038] The present invention provides a software-implemented DFA including software, the software configured to execute at least one condition using at least one input signal, and based on a result of the execution of the condition, execute an action according to a state transition table of the DFA, wherein the execution of the action is identifiable from a state of a blockchain ledger.

[0039] The present invention may provide a method that includes associating a portion of a lock script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of a DFA. The portion of the lock script may be part of the data within the lock script. It may be part of the metadata. It may be an identifier, label, or tag. Thus, the present invention may use an unspent transaction output (UTXO) on a blockchain to record and identify when a DFA was and / or is currently in a given state during execution.

[0040] The method may include using a further transaction (Tx2) to transition from the state of the DFA to a further state by using an output (UTXO1) of the transaction (Tx1). The further state may be associated with a portion of data provided in a locking script of an unspent output (UTXO2) of the further transaction. Thus, the UTXO records or embodies the change in DFA state in the blockchain.

[0041] The present invention may be substantially described with reference to the "Encoding Techniques" section of this specification, but may also incorporate features from other sections of this specification, and may incorporate any feature described herein.

[0042] Additionally or alternatively, the present invention may include executing a program configured to monitor and / or receive an input signal and, in response to the input signal, generate a blockchain transaction Tx2 that includes an unspent output (UTXO) and uses an output of a previous transaction Tx1.

[0043] The output of the previous transaction Tx1 may have a lock script that includes an identifier associated with a first state of the DFA, and the unspent output (UTXO) of transaction Tx2 may have a lock script that includes a further identifier associated with a further state of the DFA. The identifier may be a label, tag, or means of identifying a state in any form or format. It may include a piece of data such as metadata, or a cryptographic key.

[0044] The program may include an identifier associated with the first state of the DFA. The program may be configured to generate and / or execute a further program that includes a further identifier associated with a further state of the DFA and included in the UTXO of a further transaction, Tx2.

[0045] A DFA may model or represent the execution of a (machine-executable) smart contract, which may be generated by a computer-based resource by populating a template contract with parameters. Thus, contract generation can be automated.

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

[0047] The program may be configured to generate blockchain transaction Tx2 in response to the input signal by using an identifier in the lock script of blockchain transaction Tx1 to determine a current state of the DFA, and using a state transition table of the DFA to determine a further state and its associated identifier based on the current state and the input signal.

[0048] The method may include submitting the blockchain transaction Tx2 and / or the previous transaction Tx1 to a blockchain network.

[0049] Multiple programs can be created and executed, each with an identifier to uniquely identify the state of the DFA. Thus, a series of programs (scripts) can be used to execute a contract. Each script has a lifespan that substantially corresponds to the duration of the state. That is, how long a DFA can be in a given state can be.

[0050] The unspent output (UTXO) of a transaction (Tx2) and / or the output of a previous transaction (Tx1) may contain a lock script with a hash of a puzzle, the solution of which must be provided by an input of another blockchain transaction to consume the output and transition the DFA to another state.

[0051] The unspent output (UTXO) of transaction (Tx2) and / or the output of the previous transaction (Tx1) may include a lock script having a hash of a redeem script that must be provided by an input of another blockchain transaction to consume the output (UTXO) and transition the DFA to another state. The redeem script may include a cryptographic key.

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

[0053] The present invention may provide a system configured to implement, realize, or embody a software-based DFA. The present invention may do so via a blockchain. The system may include a blockchain (which may or may not be implemented using the Bitcoin network), one or more computing agents configured to generate and / or execute at least one program according to any method described above or below, storage resources for storing a state transition table for the DFA, which may be, for example, a hash table or a distributed hash table, and / or at least one template for a blockchain transaction and / or at least one template for a smart contract.

[0054] The invention may be substantially as described below in the section entitled "Compiling and Running a Software-Implemented DFA," although features from other sections of the description may also be applied. The system may be configured to implement or realize the execution of state machines on a blockchain to perform automated execution of (smart) contracts.

[0055] Any feature mentioned in relation to a system of the invention may be applicable to the corresponding method of the invention, and vice versa. Any feature mentioned herein in relation to one embodiment or aspect of the invention may also be applied to any other embodiment or aspect. The blockchain-based DFA of the present invention incorporates at least the following key features: We provide a blockchain-based implementation of a mathematical model of computation, thought of as an abstract machine that can be in one state among a finite set of states and can change (transition) from one state to another when a finite set of triggering events (called inputs) occur. Providing novel techniques for establishing and automatically executing contracts based on the technical realization of the responsibilities of different parties, such as deterministic finite automata (DFA) embodied in computational and storage structures on the blockchain.

[0056] Existing blockchain infrastructure and protocols can be used. Enables and enables the automatic generation, control and execution of smart contracts. · It is automatically executable and can be carried out by a computer. A permanent and immutable record of contracts, their execution and results.

[0057] The present invention provides and utilizes at least the following advantages inherent in blockchain protocols and platforms: · It is inherently secure by design (the Bitcoin protocol does not require any trusted parties). It is distributed, so it avoids a large-scale single point of failure and is not vulnerable to attacks. · Easy to manage and maintain (the Bitcoin network is straightforward to use). It is not expensive (typically only small transaction fees are expected under the Bitcoin protocol). It is not geographically restricted or limited and can be used by anyone with access to the internet, anywhere, anytime. Once data is written to the blockchain, it is visible to everyone and is transparent. Once data is written to the blockchain, no one can change it and it is immutable. · Privacy is maintained and no personally identifiable information is involved. [Brief explanation of the drawings]

[0058] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 shows an overview of a system configured in accordance with an embodiment of the present invention. [Figure 2] 1 shows an illustrative embodiment of the present invention implemented as a DFA performed on a blockchain using P2PKH transactions to represent the various state transitions that a smart contract can trigger. [Figure 3] For each example discussed below, we present a blockchain-based DFA. [Figure 4] Here is an example of a start (state s0) transaction (o) for the puzzle-based implementation described below: [Figure 5] An example of a transition (from state s0 to state ff) transaction (tf) is shown below. [Figure 6] An example of a completed (from state ff) transaction (cf) is shown below. [Figure 7] Similar to Figure 4, but showing a blockchain transaction using a P2SH transaction type with DFA state. [Figure 8] 5 shows an example similar to FIG. 5 but using a P2SH transaction type with DFA state. [Figure 9] 6 shows an example similar to FIG. 6 but using a P2SH transaction type with DFA state. [Figure 10] 10 is a bond state diagram for Example 1 of an encoding technique that may be used in accordance with one embodiment of the present invention. Figure 10 shows the states (bold) and transactions (connecting lines) associated with the illustrated inputs. [Figure 11] 1 shows the state diagram for Example 2, a coupon bond with recursive states. [Figure 12] 12 shows the internal state diagram of the recursive state associated with the example of FIG. [Figure 13]1 shows a state diagram for the European Call Option example from the "Compiling and Execution" section of this application, showing the states (bold) and blockchain transactions (triangles) to be submitted: occurrence (o), transition (t), and completion (c). DETAILED DESCRIPTION OF THE INVENTION

[0059] The term "blockchain" is used herein to encompass 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 variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin is referred to herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0060] An illustrative embodiment of the present invention includes a definition of a DFA that models a process or task, such as a contract, and an associated system of computing resources, sometimes referred to as agents or "bots." Agents are configured to generate transactions and submit them to a blockchain. The present invention, however, is not limited to use in connection with contracts.

[0061] Referring to Figure 1, the present invention provides a process implementation as an abstract DFA embodied on a computing platform—a blockchain—including hardware and software components. Figure 1 provides an overview of a system configured in accordance with an illustrative embodiment of the present invention. The system has computing agents 3 that can interact with other entities 4 (e.g., humans or other computers) to receive instructions. These instructions may be, for example, which smart contracts to create and execute. Thus, the computing agents 3 implement the present invention by interacting with the physical world to respond to and generate events in the "real world" outside of themselves.

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

[0063] The DFA2 itself is specified as a finite set {S, I, t, s0, F}, where S is the (finite) set of possible states that the contract / DFA can be in, and I is the (finite) set of inputs (also known as alphabet), which in the context of this specification mean any event or condition that can occur in connection with the contract, such as a payment being made, a security reaching maturity, a counterparty defaulting, etc. In our mechanism, these input signals are received / generated by one or more agents, which then determine the next state (possibly the same state) of the system.

[0064] The third component of a DFA is the transaction function t: S × I → S. The term "determinism" in "DFA" refers to the uniqueness of the decision: given a state and inputs, there exists one and only one new state (possibly the same state). Thus, given an initial state (S0) and a history of inputs, the outcome of the computation (contract) is a unique one among the set of all possible final outcomes (F ⊆ S). Once all these elements are established, the DFA is fully defined by a transition table, which specifies future states for all possible current and input signals. The states of the DFA are themselves associated with unspent transaction outputs (UTXOs) on the blockchain. As is known in the art, the Bitcoin network keeps track of all available UTXOs. In accordance with the present invention, the mechanism by which a DFA transitions from one state to another is embodied (implemented) in accordance with the present invention by blockchain transactions. In effect, a transaction on the blockchain consumes UTXOs associated with one state (the inputs of the previous transaction) and generates UTXOs associated with the next state (the output).

[0065] <Simple DFA example: Discount (zero coupon) bond> For purposes of illustration, we consider below a discount (zero coupon) bond, which is a simple class of bond that is usually purchased at a price (usually at a discount to its face value) and then held for a specific time until its principal is repaid at maturity. A coupon bond is thus a debt contract with periodic interest payments (coupons) received by the holder from the issuer of the contract until its maturity, when the final coupon plus the bond's principal is paid.

[0066] The possible states we consider are S = {s0,f0,f1}, which respectively denote a holding state (s0), a successful contract termination (if the lucky path is followed) or happy ending (f0), and a failed, e.g., litigation, state (f1). The final state of the system is therefore F = {f0,f1}. The alphabet we consider is I = {r,d,e}, which respectively denote a principal repayment at (or before) maturity (r), an issuer default at (or before) maturity (d), and contract expiration without refund (e). The transaction matrix for this simple contract is shown in Table 1.

[0067] [Table 1] DFA transition table for zero-coupon bonds

[0068] [Table 1] It should be noted that the final states represent the completion of the contract, and therefore no further states need to be specified from them (currently shown as "-" in the transition table, but these lines could be omitted). In principle, more states and / or inputs (and actions) could be defined for this instrument, but this is not done herein for the sake of simplicity and clarity, in order to explain the basic novel aspects of the invention rather than inserting distracting details related to the complexity of the contract.

[0069] Figure 3 shows an embodiment of a zero-coupon bond DFA on the (Bitcoin) blockchain. States are represented by circles, and Bitcoin transactions that move the machine from one state to another are represented by blue triangles. Note that in Figure 3, inputs received by the agent are omitted, but in each state, one or other transitions should occur according to these inputs, and this is reflected in the diagram by the composition of one or other Bitcoin transactions (e.g., t0 or t1 in state s0); transitions that do not change state do not require transactions and are therefore omitted. The DFA's transition transactions (t i), plus the initial occurrence transaction (o) and the transaction corresponding to the completion of the contract (c i ) is possible.

[0070] In what follows, we focus on the flow of funds in a transaction (origin, transition, and completion). Importantly, we note that due to the finite nature of DFAs and (financial) contracts, the process will be completed after a number of transitions. This does not necessarily mean that the maximum cost of establishing and executing a contract is joint and can be determined in advance, e.g., at the time of establishing the DFA (assuming some finite fees for the computing agents and Bitcoin miners involved). It is given by the total amount of funds required to execute the contract along the longest possible path. This, of course, precludes the possibility of infinite loops during execution, but we note that this is not relevant for current (financial) contracts; even contracts such as perpetual bonds, despite their name, are obligations that must be completed at a specific point in the future, e.g., when the indebted entity disappears or inflation makes the payment negligible.

[0071] The particular distribution of fees, how much each agent receives for their work, is not a key element of the present invention, regardless of practical importance. Continuing with the streamlined zero-coupon bond example, the present specification defines the following: an origination transaction (o) fee of 3 mBTC, a transition fee (t iAssume a fee for the completed transaction (ci) of 2mBTC. These fees are automatically included in the transaction itself. Together with a total mining fee of 3mBTC for the three transactions, this results in a total maximum cost of 9mBTC. In our very simple example, all paths are of equal length. Therefore, the final cost of the contract is guaranteed to match its maximum cost. Since this is generally not a necessary example to fully illustrate the general flow of funds, we will assume that the funds provided for the execution of the contract are 10mBTC, and that 1mBTC is returned to the same source of funds after completion. This replaces the final unspent funds upon completion. In other words, the maximum and spent funds are different.

[0072] We assume that funds (10 mBTC) for the establishment and execution of the contract are initially provided by a specific funding source, referred to as the "originator." As mentioned above, in this example, this source also receives 1 mBTC of unspent funds after completion. In principle, the transaction could also include additional funding inputs and outputs, such as the price paid for a zero-coupon bond, a repayment of principal, or any other possible transfer of funds. While this may be of practical interest, it would only obscure the fundamental elements of the present invention. For clarity, such details are not included in the following example. However, it should be noted that the structure is entirely general and such possibilities are not excluded.

[0073] <Implementation for the Description of Technical Solutions - DFA System and Method> Those skilled in the art will readily appreciate that the system may be implemented in a variety of ways, with these variations still falling within the scope of the present invention. For example, the configuration and architecture of the agent system 3 may vary, for example, whether the specific agents involved are known in advance or not. For illustrative purposes, two technical design options are considered here: 1. If participation in the contract is kept relatively open and various computing agents can participate, then a structure based on standard blockchain transactions of the "transaction puzzle" type is possible. 2. Conversely, if each state transaction is pre-assigned to a specific agent (or group of agents), P2SH (pay-to-script-hash) transactions can be used.

[0074] Puzzle-based blockchain transactions and P2SH transactions are known in the field of blockchain technology. Those skilled in the art will also understand that numerous possibilities may exist in addition to or as an alternative to the two options described above. For example, an embodiment may use multiple time-varying agents, a hierarchical structure of agents, etc. While there are numerous possibilities, this specification describes only two options from which those skilled in the art can readily derive other possible variations and implementation options.

[0075] However, it is noted that the type of blockchain transaction used in one embodiment is not essential to the invention, as the parties providing / receiving funds in a transaction (e.g., issuer, purchaser, payee, etc.) are not essential to the invention. Instead, a key element of the invention is that it provides a mechanism (regardless of its detailed specific implementation) that allows the state of a task / contract at any point in time to be defined within the blockchain, and that it allows for the automatic generation of contracts, their execution on the blockchain, and the implementation of appropriate outcomes according to the sequence of events that occur. It is noted that because the entire mechanism is embodied on the blockchain, this inherently provides a permanent, immutable record of contract history and outcomes, among many other benefits.

[0076] <Implementation Option 1: Transaction-Puzzle Approach> In one possible embodiment of the present invention, the agent system 3 is configured as an open computer network where anyone with some internet processing power can join and provide some processing power to the system (e.g., providers of establishing and executing blockchain-based DFA contracts) and be rewarded for their resources. In such a situation, it is not possible to know in advance which specific agent will submit a transaction to the blockchain; that is, 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 such a situation. The general lock / unlock mechanism for this type of transaction is as follows: Locking Script: OP_HASH256 <state s i puzzle>OP_EQUAL Unlocking Script: <puzzle s i solution> where: <state s i puzzle>=HASH( <state s i The puzzle solution is a contract that is created by a contract owner, and the puzzle solution itself may contain any desired information, including the contract's code, state labels, and any other desired information, such as some salt for added security. <state s i puzzle solution>=HASH( <contract code; state s i ; other data; salt>) The concept of "salt" is conventionally known and will be readily understood by those skilled in the art in the context of the present invention. The sequence of actions is as follows, with reference to Figures 1 and 2: First, the agent system (3, step 101) generates a DFA structure 2.

[0077] A transition table specifies and contains trigger events that cause the DFA to transition from one state to another. The transition table contains at least one trigger event or condition for each possible state transition. Thus, a trigger is associated with a current state, i.e., the state the DFA transitions to after this trigger event, and a new state, i.e., the state the DFA will be in after the transition that the trigger initiates.

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

[0079] In step 104, the agent generates an outgoing transaction to state S0, which may be as shown in Figure 4. Suppose the funds allocated to the contract are 10mBTC, the agent fee is 3mBTC, and the funds going out for further processing of the contract are 6mBTC (a 1mBTC mining fee is implicit). At this stage, the contract is embodied as a structure on the blockchain and is in its initial state s0. That is, there is a UTXO associated with state s0 of the particular contract on the blockchain.

[0080] For the illustrative transaction in Figure 4, the funds allocated to the contract are 10mBTC, the agent (botnet) fee is 3mBTC, and the funds going out for further processing of the contract are 6mBTC. A 1mBTC mining fee is implicit.

[0081] As can be inferred by examining the transactions in Figure 4, the original funds for the contract are received via a P2PKH-type transaction (in this case from the “originator”), output 0 (based on the puzzle) can be unlocked by any agent that owns the puzzle solution, and output 1 (P2PKH) pays the desired fee to agent 3 that successfully places the transaction on the blockchain.

[0082] Execution of the contract results in successive transactions being performed by an automated agent 3 in a manner similar to that illustrated in Figure 5. The agent is configured to obtain, generate, or receive a puzzle solution corresponding to the current state (s0). The agent also receives appropriate inputs, reads the transition table (or just the part of the transition table that corresponds to the current state), and generates the appropriate next state (f f ), the agent interacts with some entity or entities (e.g., some other computer in the agent system, or some data / signal source) to obtain a puzzle corresponding to the state f. The agent can then submit a transaction to the blockchain. If the transaction is verified by the blockchain network, the agent receives the associated fee and the DFA enters state f. f For the transition in Figure 5, assume that the incoming funds are 6mBTC, the agent fee is 1mBTC, and the outgoing funds for further processing of the contract are 4mBTC (a 1mBTC mining fee is implicit).

[0083] Figure 6 shows the structure of the last possible transaction, the transaction that completes the execution of the contract (c f) In Figure 6, the input part follows the same transaction puzzle logic as before, while output 0 pays unspent funds returned to the originator (1mBTC as described above), and output 1 pays a fee to the agent. In Figure 6, we assume that the incoming funds are 4mBTC, 1mBTC of unspent funds is returned to the originator, and the agent fee is 2mBTC (a mining fee of 1mBTC is implicit).

[0084] <Implementation Option 2: P2SH-based transactions> The puzzle-based approach described in Option 1 is suitable for use where there are a large number of a priori unknown participants. However, in other cases, a limited or acceptable number of recognized computing agents 3 may be designed for use in connection with the present invention. In this case, P2SH-type transactions may be more suitable for use, as they can be configured to include the public key of the known agent 3, thereby providing an additional layer of security. In the case of a single recognized agent, a possible lock / unlock mechanism for the transaction is as follows: Lock script: OP_HASH160 <state s i redeem script hash>OP_EQUAL Unlock script: OP_0 <agent signature><state s i redeem script> Redeem script: OP_1 <state s i metadata><agent public key> OP_2 OP_CHECKMULTISIG Note that this can be extended to multiple recognized agents by also including the signatures of multiple recognized agents. As mentioned above, state s i The metadata may include any desired information, for example: <state s imetadata>=HASH( <contract code; state s i ; other data>) The sequence of actions is similar to that described above for the puzzle-based approach. First, the agent system 3 generates the DFA structure and stores the transition table externally (e.g., in a DHT). Next, it is determined which agents will process the transaction and retrieve / generate their public keys. These public keys are then included in the Redeem scripts for each possible state of the DFA. Note that these scripts can be stored externally (outside the blockchain) and do not need to be securely transmitted. Next, the computing agents generate the accrued transactions as specified in Figure 7. The example in Figure 7 is similar to that in Figure 4, but uses a P2SH transaction type for the DFA state.

[0085] At this stage, the contract is embodied as a structure on the blockchain and is in its initial state s0. The only change in the transaction relative to Figure 4 is output 0, which is now of type P2SH and contains the public key of the recognized agent as described above.

[0086] While the changes are similar, for the sake of detail, Figures 8 and 9 provide examples of transition and completion transactions based on P2SH transaction types. The flow of funds is the same as described above. Figure 8 shows an example similar to Figure 5, but using a P2SH transaction type with DFA state. Figure 9 shows an example similar to Figure 6, but using a P2SH transaction type with DFA state.

[0087] A Novel Coding Technique for Computer-Implemented DFA Having described a blockchain-based DFA above, attention is now directed to particularly advantageous and novel aspects of the invention. In this section, we describe the novel inventive technique for encoding the state of a DFA into a computer-readable and executable format.

[0088] In traditional approaches to such machines, states are statically defined (a priori) and represent some particular configuration of the system or some particular meaning. For example, states can be given a set or name and associated with a set of tags, or with unspent transaction outputs (UTXOs) as described above for blockchain-based DFAs. This is sufficient for the system to operate, as how the system moves between states determines the (output of) the computation itself, while accepting a chain of inputs.

[0089] In this sense, a DFA (i.e., a set of states, transactions, etc.) is not unique, and two DFAs can be equivalent; that is, they can each produce the same output for a given chain of inputs, although a priori interpretation of the state can be very difficult. Consider, for example, what if they were deployed on different physical machines, or conceived to solve different problems. This also naturally leads to the notion of DFA minimization (see https: / / en.wikipedia.org / wiki / DFA_minimization).

[0090] While a static determination (tagging) of the state is sufficient for the abstract functionality of the state machine itself, and the output of the computation alone is sufficient for many related problems, there are cases where the meaning of the state itself is of practical importance and cannot be inferred from the state's tag. This may be because it is intentionally hidden, for example, for privacy or confidentiality reasons. An example is found when computation is distributed and performed by computing agents that (intentionally) do not have complete information about the system. In these cases, dynamic determination of the system's state is required at run-time.

[0091] An advantageous aspect of the invention described herein is coding techniques that allow for dynamic (on-the-fly, at runtime) determination of the state of a DFA. Such DFAs may include those associated with distributed execution of contracts as described above, but are not exhaustive, and the invention is not limited with respect to the purpose of the DFAs for which the inventive techniques are used, or their specific implementation. Because traditional approaches predetermine states in a static manner, the inventive dynamic state determination is the opposite of traditional methods and offers those skilled in the art a completely different technical solution. The invention goes beyond the mere use of a blockchain to store data about occurring events.

[0092] For purposes of describing and explaining the encoding techniques of the present invention, coupon bonds and perpetual bonds will be used as examples, but the present invention is not limited to these exemplary uses or applications. The present invention is equally applicable to non-financial applications and situations. The characteristics of coupon bonds have been described above. Perpetual bonds are continuous payments that have no end in sight; that is, coupon payments continue essentially forever. In practice, however, due to the effect of compounding positive interest rates, at a particular point in time, the amount of the coupon has no practical meaning, so the discounted value of the contract is actually finite.

[0093] <Example 1 of the encoding technique of the present invention - direct scenario> As already explained, a DFA 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 admissible states. Additionally, a set of actions (a) is defined, which represent side effects of the execution and do not determine the output of the computation.

[0094] For the purposes of description and explanation of the present invention, we consider a three-period coupon bond. The elements (and notation) of the DFA to consider for such a contract are statically defined as given in Tables 2-4. The initial state is designated by S in our notation, and the allowed states are F0 and F1.

[0095] [Table 2] List of coupon bond contract states

[0096] [Table 2] [Table 3] List of contract inputs (event alphabet) for coupon bonds

[0097] [Table 3] All of these inputs can be detected and determined automatically by a computer. In the above example of Table 3, a computer could check if a particular date / time has been reached or if a particular payment has / has not been made via a blockchain transaction. The blockchain can be traversed to see if there is a transaction on the ledger that makes the payment. Because the Bitcoin blockchain provides a permanent, public, and tamper-resistant record, this verification can be done by a computing agent without the need for human intervention.

[0098] [Table 4] List of contract actions for coupon bonds

[0099] [Table 4] Once these elements are defined, the system's functionality can be fully specified by a state transition table, where the current (initial / source) state of the system (row) along with appropriate inputs (columns) follow the table to determine the system's next (final / destination) state and the actions to be performed in parallel with the transition. In our example, this is given in Table 5. Note that execution begins in the initial state (S) and the only possible final (allowed) states are F0 and F1. Because these states represent the final stages of execution, i.e., there are no transitions associated with them, they can be omitted from the table rows. An alternative format for a transition table is given in Table 5.

[0100] [Table 5] Coupon Bond State Transition Table: When the system is in a particular state (row) and a particular input (column) occurs, the system transitions to the indicated state and performs the indicated action (state / action); a hyphen indicates that the input is irrelevant to the given state, i.e., does not apply to the state.

[0101] [Table 5] Another equivalent way of specifying the functionality of a state machine is the so-called state diagram. In a state diagram, the states of the system are represented by circles (blobs), inputs and actions are given by associated labels, and transitions are represented by connecting arrows. In our example, a state diagram is given in Figure 10. Note that the final (allowed) states F0 and F1 are indicated by circles with double-thick lines for convenience. For simplicity, actions have been omitted from this diagram, since they are not relevant to the execution of the system. The meaning of the dashed boxes (recursive states) will be clarified below.

[0102] As noted above, while the functionality of a DFA need not be strict, dynamic determination of the state of a system that is both human- and computer-readable is a practical necessity and constitutes an aspect of the invention described herein. Each state is characterized by a unique set of conditions that may or may not occur as a result of the particular state, or that are unrelated. Each condition must be explicit and (machine-) testable. In other words, there must be a clear computational method that tells whether a condition results or does not occur. Thus, one embodiment of the present invention may interact with the physical world, or at least with the world outside the computer on which the software is running, in that values ​​or inputs for testing may be received from one or more external sources. For example, when data arrives, or when a temperature threshold is exceeded as indicated by a sensor, or when a notification is received from another computer, etc. These conditions may be tested by the computing agent described above.

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

[0104] Of course, it is irrelevant whether this or an equivalent set of conditions is used, as long as they uniquely determine all possible states. That is, the chain of true, false, or don't care values ​​for each state is unique. It should also be noted that, although in this example we have only considered binary values ​​(true or false) or don't care states, these could in principle take on multiple values. Furthermore, in addition to atomic conditions as described herein, each condition may also represent a composed condition made up of several (sub)conditions. All these variations will be readily apparent to those skilled in the art and are encompassed within the scope of the present invention.

[0105] The dashed box in Figure 10 represents the final point to be resolved. As it stands, the diagram is perfectly valid and should correctly describe the dynamics of coupon bonds, but at state T i and condition C i Note that there is an interesting similarity between i and ii: these states are very similar in meaning and differ only in the time period or coupon number (i) they refer to. Therefore, these states can also be represented by a common repeating or recursive state, with additional information indicating which coupon / period they refer to. This can be naturally extended to states that repeat themselves indefinitely, thus opening up the possibility of encoding perpetual bonds. The definition of such a recursive state encoding scheme is addressed in the next section below.

[0106] [Table 6] State Definition Table: Each condition is true (T), false (F), or irrelevant (-) for a particular state, and is therefore defined by a set of dynamically testable values.

[0107] [Table 6] <Example 2 of the encoding technique of the present invention - Recursive state> As mentioned above, some subset of the states of the coupon bond DFA from the last part or the coupon bond (T i and D i The states (i, ii, iii, iii, iv ...

[0108] Table 7. List of contract states for coupon bonds with recursive states

[0109] [Table 7] [Table 8] State transition table for coupon bonds with recursive states

[0110] [Table 8] [Table 9] State Definition Table: Each condition is true (T), false (F), or irrelevant (-) for a particular state and is therefore defined by a set of values, one value for each condition (and conditions can have multiple components).

[0111] [Table 9] Of course, all this only hides the complexity of the internal dynamics of the recursive state, which must be specified separately. However, for complex state machines, this simplification can be significant. An obvious analogy is the introduction of a loop in a programming language. The recursive state itself is also defined as a state machine. Note, however, that since the execution of an abstract computation does not imply a start or end within a recursive state, initial and allowed states are replaced by entry points and exit points in this context. Below we present a list of contract states (Table 10), a state transition table (Table 11), and a state diagram (Figure 12) for a recursive state.

[0112] [Table 10] List of contract substates of a recursive state

[0113] [Table 10] [Table 11] Internal state transition table for recursive states

[0114] [Table 11A] The novelty of this approach is the index (i) that keeps track of how many times a state has been occupied. The growth of this index and similar quantities (e.g., total payment amount) can be calculated externally (in a coded manner, as described below) or achieved by additional DFA actions, as shown in Table 11 for state C. Note also that the inputs (alphabet) of the internal states of this recursive state may depend on the internal index (i) and / or similar quantities. As mentioned above, the allowable states of the system have been replaced by exit points. The corresponding equivalent state diagram is presented in Figure 12.

[0115] Such a recursive state encoding scheme, when expanded, looks very similar to the relevant portion of Table 5. However, since the spirit of this approach is to expand and treat each internal (sub)state separately, it seems more natural not to show it explicitly in the table. Instead, Figure 4 presents pseudocode for an algorithm that assigns the correct value (true or false) to the variables associated with the conditions in the state machine encoding. Of course, variables associated with unrelated conditions need not be assigned any value. In Figure 4, as in Table 5 above, each condition ti indicates whether a particular date has arrived (i.e., ti=T, where t≧t i ), each condition ci indicates whether the corresponding (i-th) coupon has been paid or not.

[0116] Below we provide pseudocode for an algorithm that assigns appropriate values ​​to variables associated with the conditions in the internal state encoding of a recursive state.

[0117]

number

[0118]

number

[0119] [Table 11B] Compiling and Executing a Computer-Implemented DFA Here we describe a novel technique for establishing (compiling) and enforcing contractual agreements based on the realization of different parties' obligations (and other terms and regulations) as computational structures modeled as state machines.

[0120] This scenario describes advantageous technical aspects of a system for establishing and executing such smart contracts over a blockchain. It deals with the flow of information between different (computer) agents that effectively execute the contract. Very generally, we refer to this system as a "botnet" (a collection of computing agents), often without specifying which agents actually perform the described actions. Those skilled in the art will understand that there are many ways to realize such implementation details.

[0121] As mentioned above, a European call option contract will be used as an example to illustrate this aspect of the present invention. A European call option is an agreement that gives an investor the right, but not the obligation, to purchase a stock, bond, commodity, or other asset at a specified price (the strike price) on a specified date (the exercise date). If the buyer decides to exercise the option, which would (reasonably) occur if the asset's price on that date is higher than the strike price, the option writer (seller) himself sells the asset to the holder (buyer) at that price on that date. In this case, the contract may alternatively be settled by a payment to the holder equal to the market price of the asset on the expiration date minus the strike price; otherwise, no payment is required, assuming the option terminates unexercised.

[0122] The standard way to establish and execute (financial) contracts is by having humans sign legal documents and interpret, enforce, and sometimes dispute their terms. These contracts can be thought of as consisting of a set of characters that define the terms and a set of values ​​for parameters specific to the contract, such as date, author, public key, etc. These separate elements are separated in the system of the present invention, where the contract's character essence is captured as an abstract machine, and the DFA and set of values ​​for parameters of a particular instance of the contract are provided independently as described above.

[0123] Returning to our example, the DFA computation system consists of a finite set {S, I, t, s0, F}, which respectively represent possible states (S), inputs (I), transitions (t), initial states (S0), and final states (F), also called admissible states. Furthermore, although not essential to the DFA structure itself, we consider here a set of actions (a) that an agent is required to perform in parallel with submitting a transaction. In the following, as is conventional, the current time (date) is denoted by t, the maturity date by T, and the asset price at maturity by S. T and the strike price is denoted by K.

[0124] The primary focus in this section of the application is the establishment of computer agents associated with the state of the DFA machine. These are implemented as computing resources having scripts. It should be noted that the term "script" in this context should not be confused with a blockchain transaction script, such as an unlock or lock script. Here, the term "script" is used in its more general computational sense. Those skilled in the art will readily understand this and can interpret the meaning of the term from the context.

[0125] Agents (scripts) can change states, perform transitions, and in parallel spin-off other sets of scripts associated with later states. The dynamic, i.e., run-time, identification of DFA states by appropriately capable computer scripts is the key inventive element of this aspect of the invention. In a streamlined example of the invention, the possible states of a contract and the sufficient conditions for their definition are given in Table 12, where the (XML) labels of the states and natural (human) language descriptions of the states are also given.

[0126] Note that not all possible states are considered in the contract, e.g., what may occur in the event of bankruptcy, death of the holder, internet shutdown, etc. However, since the current focus in this chapter of the invention is on analyzing the compilation and execution of the contract, and not the complexity of the DFA itself, the example of the invention is appropriately as simple as possible, if not simpler.

[0127] [Table 12] shows the state definition table for the examples in this chapter: Each condition is true (T), false (F), or irrelevant (-) for a particular state and is therefore defined by this set of values, one value for each condition; also note that a condition can have multiple components.

[0128] [Table 12] Continuing with the description of the different elements of the abstract DFA, we refer to the list of inputs below, also referred to as the event alphabet. This is a list of events that can occur in relation to the contract. For example, expiration is reached, payment is received, etc. These inputs, along with the set of current states of the DFA, determine the transactions to be submitted to the blockchain, as well as any parallel actions to be performed by the agent. However, note that while technically the transition function is an S×I→S mapping, not all inputs are necessarily associated with all states. In our streamlined example, these are given in Table 13, along with (XML) labels and natural language descriptions of the events.

[0129] [Table 13] List of contract inputs (event alphabet)

[0130] [Table 13] Computationally, an event can also be thought of as a change in the conditions that define a state, but as noted above, some events are irrelevant to some (or all) states and do not result in a state transition. Similarly, a list of possible actions, not necessarily all relevant to all states, can be specified in Table 14.

[0131] [Table 14] List of contract actions

[0132] [Table 14] Once all these elements are defined, they are collected into a state transition table. In the state transition table, the current (initial) state of the system (row), together with the appropriate inputs (columns), determines the next (final) state of the system according to the table, as well as the actions to be performed in parallel with the transition. In addition to transition transactions, the DFA of the present invention also considers completion transactions. Instead of placing the system in a later state, a completion transaction places the system in an allowed state (f). The allowed state (f) is a virtual (e.g., not embodied on the blockchain and not associated with any script) state that represents the end of the contract's operations. An example of a European call option of the present invention is given in Table 15. In Table 15, the initial state is associated with a row, the inputs with a column, and each cell contains a later state / action field.

[0133] [Table 15] Contract state transition table

[0134] [Table 15] Furthermore, in our examples, it is common to represent the abstract DFA by the state diagram shown in Figure 13. Note that there is a correspondence between this diagram and a (computationally useful) state transition table; therefore, no additional information is included in the diagram itself. Figure 13 shows an example of a European call option, showing states (circles) and blockchain transactions (triangles) to be submitted: occurrence (o), transition (t), and completion (c).

[0135] <Technical explanation> The DFA compilation mechanism is composed of different elements and files, which are discussed below. How the computational structures embedded in these files, the scripts associated with different states, generate not only blockchain transactions but also the subsequent scripts that fully execute the contract, is the main focus of this chapter of the application. To begin with, the system uses the following two source files in this example:

[0136] DFA European call option-parameters.xml DFA European call option-script.py Here, for the sake of concreteness, we will assume that the primary language used for generating the subsequent files and executing the contract is Python 3.5, and that the parameters are provided in an XML 1.0 document. Of course, these implementation details are not essential to the invention, and those skilled in the art will understand that the use of other standards is equally acceptable.

[0137] The XML document contains a list of parameter fields and values ​​(specified by XML tags) for the particular contract at hand, i.e., a particular European purchase option. In this example, it is handwritten, but it may also be generated automatically, i.e., by a computing resource or agent, or by a human entering the appropriate values ​​via a graphical user interface (GUI), which may again be written in Python.

[0138] The main file of the system's technical specification is the main (Python) script. This file contains, or when executed, inserts a hard-coded version of the abstract state transition table (possible states, inputs, and actions), hard-coded functions that specify the DFA inputs and actions to be considered (e.g., how to look up stock prices, clocks, etc.). When relevant, i.e., in a blockchain-based DFA implementation, this file may contain hard-coded templates of (Bitcoin) transactions to be submitted to the network by the script.

[0139] As mentioned above, the state transition table completely determines the DFA at an abstract 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 required elements, the script can optionally include / generate different human-readable documents, such as state diagrams, alphabets, etc.

[0140] To compile and execute a blockchain-based DFA contract, a user (human or computer) must fill in parameter values ​​and execute a main script. When executed, with this hard-coded information on the script and parameter values, the script establishes the contract, e.g., places the contract on the blockchain, and generates one or more computer programs (other scripts) that are executed in sequence by a system of computing agents that execute the contract. A possible sequence of instructions that may accomplish this is as follows: 1. Read the parameter values ​​(or enter the values ​​directly from the GUI): This loads the parameter values ​​into memory, for example into a hash table (HT) structure (which is called a dictionary in Python) or into a distributed hash table (DHT), for example into the bitTorrent network if this provides some benefit. 2. Uses parameters and hard-coded contract templates to generate a legal contract. This document must be signed (digitally) by the creator of the option. 3. (Optional) Generate human-readable documentation of the contract. 4. Use the parameters and hard-code input and action functions to create instances of these functions with the appropriate parameter values. 5. Load the state transition table into memory (HT or DHT). 6. If relevant, create an origination transaction as specified and submit it to the blockchain network. This can be done using the Pybitcointools library. This creates a UTXO in the blockchain that is associated with the specific state of the contract on the Bitcoin blockchain, as described above. 7. Generate a Python script associated with the occurring state (s0) and execute it (on the same or another computer). This agent (or collection of agents) receives / generates the appropriate inputs, performs the appropriate actions, actions that match the state, and ultimately completes the execution of the contract or generates transition transactions to other states and the derived subsequent scripts that control these states. 8. Finish compilation (main script).

[0141] With the compilation phase complete, the system is up and running. According to one embodiment of this example, there are UTXOs on the blockchain associated with the initial state of the contract, and one or more agents (Python scripts running on botnet agents) monitoring the inputs are ready to take action and generate appropriate transitions that change the state of the DFA to another state or to terminate it.

[0142] The sequence of commands for the transition is as follows: 1. Monitor or generate DFA inputs: function calls such as checking the clock, receiving messages, etc. 2. Once the inputs are determined, read the transition table for the current state, which determines the next state and possibly the action to be taken. 3. Depending on the complexity, if any, take action on subroutines or function calls as the case may be. 4. If relevant, generate a transition transaction according to the blockchain and submit it to the blockchain. 5. Generate and execute the Python associated with the next state. 6. End the current script. The sequence of instructions for completing the contract is as follows: 1. Monitor or generate DFA inputs. These can be subroutine or function calls, such as checking a clock, receiving a message, etc. 2. Once the inputs are determined, read the transition table for the current state. This determines which contract should be completed and possibly the action taken. 3. If any, possibly take action on the function call depending on its complexity. 4. If relevant, generate a completed transaction according to the blockchain and submit it to the blockchain, which uses the last UTXO associated with the contract. 5. Exit the current (and last) script.

[0143] Thus, the DFA is executed by a collection of independent agents (scripts) that receive enough information from the previous agent and then return to the initial main script and parameter file.

[0144] Thus, according to one embodiment of the present invention, contracts are executed by a collection of agents (implemented as scripts) and are dynamically generated as the system transitions between states. These agents have access to the current state of the system (e.g., as embodied by UTXOs on the blockchain), and they need to receive or generate the appropriate inputs according to events occurring in the real world, take appropriate actions, and execute appropriate transactions. All of this can be accomplished within the script (e.g., Python) using well-defined functions and existing libraries. For example, in the European buy option example herein, they should have access to a clock, to check whether the contract expiration has been reached, and to the current price of the asset. Given this information, they can determine which appropriate inputs to consider according to the parameters. Given this and the actions specified in the transaction matrix, the agents can determine which blockchain transactions to generate, thereby placing the system in the next state (in this example, there is only one state) or completing the execution of the contract as appropriate.

[0145] It should be noted that the above-described embodiments do not limit the present invention, and those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" or "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes" or "consists of," and "comprising" means "including" or "including of." The singular reference of an element does not exclude the presence of a plurality of such elements, and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, or by means of a suitably programmed computer. In a device claim enumerating several means, these several means can be embodied by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage. [Explanation of symbols]

[0146] 1. Blockchain 2. DFA 3 Agent 4 world 5. DHT

Claims

1. 1. A method of using a blockchain to control a computer-implemented process that runs outside the blockchain, the method comprising: Blockchain transaction (Tx １ ) Unspent Output (UTXO) １ ) with a given state of the DFA.

2. The blockchain transaction (Tx １ ) Unspent Output (UTXO) １ ) to transition from the state of the DFA to a further state. ２ ) using The further state may be the unspent output (UTXO) of the further transaction. ２ 2. The method of claim 1, wherein the locking script is associated with a portion of the data provided in the locking script.

3. Implementing or representing at least one state transition trigger using a portion of the code, said state transition trigger, when executed, triggers a further transaction (Tx ２ ) to the blockchain transaction (Tx １ ) Unspent Output (UTXO) １ 3. The method of claim 1, further comprising the step of: causing the DFA to use a new state, thereby moving the DFA to another state.

4. The method of claim 3 , wherein the portion of code includes a machine testable condition that provides a Boolean result based on an input.

5. The inputs are determined at runtime and the unused outputs (UTXOs) are used to move the DFA to the further state. １ 5. The method of claim 4, wherein the .intg. suffix is ​​used by a portion of the code to determine whether a .intg. suffix should be used.

6. The Unused Output (UTXO １ 6. The method according to claim 1, wherein part of the data in the file is provided in a lock script.

7. The method of claim 6 , wherein the portion of data is a tag, a label, or a portion of metadata.

8. 10. The method of claim 1, wherein the DFA is a model of a machine-executable smart contract.

9. The Unused Output (UTXO １ ) contains a lock script containing a hash of a puzzle, and the solution to the puzzle is the unspent output (UTXO) １ ) and must be provided by further transactional inputs to transition the DFA to another state.

10. The Unused Output (UTXO １ ) includes a lock script that includes a hash of a Redeem script, and the Redeem script is used to lock the Unspent Output (UTXO) １ ) and must be provided by further transactional inputs to transition the DFA to another state.

11. The method of claim 10 , wherein the Redeem script includes an encryption key.

12. The method according to any of claims 1 to 11, wherein the method is performed by one or more computing agents.

13. i) the states of the DFA are defined and determined, or the conditions or triggers for each state transition are stored in a storage resource; or ii) the method further comprises using unspent transaction outputs among transactions on the blockchain to represent the state of the DFA; or iii) the method further includes using unspent transaction outputs on the blockchain to represent a transition from the given state of the DFA to a different state of the DFA; or iv) a transition from the given state of the DFA to a further state of the DFA represents or corresponds to a step in the computer-implemented process; The method of claim 1.

14. A system configured to perform the method according to any one of claims 1 to 13.

15. The system comprises: Blockchain platform and at least one computing agent configured to implement the DFA and control the computer-implemented process via the blockchain; 15. The system of claim 14, comprising:

Images