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

Abstract

To provide a system and a method for executing, controlling, and automating a task or a process on a block chain such as a bit coin block chain.SOLUTION: A method includes the steps in which an agent system generates a deterministic finite automaton (DFA) structure, generates each puzzle in a possible state for the DFA is generated by a computing agent, stores a transition table and a puzzle for each transition related to the transition table into an external database or a dispersion hash table, and an agent generates a generation transaction to an initial state.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention generally relates to systems and protocols for the automatic execution of computer protocols of computer-based processes, and more particularly to the verification, enforcement, and / or execution of conditionally controlled processes such as those related to contracts. The present invention, however, is not limited to use related to contracts. The present invention also relates to blockchain technologies such as, but not limited to, Bitcoin blockchain, and can be used to benefit smart contracts.

Background Art

[0002] The use of computers to automate and control the execution of tasks and processes has long been desired. This is particularly relevant, for example, with respect to the execution of agreements between parties such as those related to financial contracts. Smart contracts are a subject of academic research and practical interest because the electronic versions of the essence of contracts are better defined and as a result can be executed and implemented by computers. One of the main problems associated with contract management in recent years is that it tends to be ad hoc and involves local stores and copies of contracts that are maintained manually. These copies get out of sync with each other and require their own storage and maintenance. This is inefficient and causes problems related to security and cost. These problems can be solved at least partially by automating the execution of machine-readable and executable documents (which have conventionally sometimes been referred to as "smart contracts"). Such automated solutions also help to minimize the potential ambiguities and interpretations arising from natural language and legal terms. As a result, contracts can be executed at a lower cost but in a more efficient and reliable manner when they are automated.

[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 rich enough structure to represent a wide range (if not all) of conceivable financial contracts. The concepts of finite state machines and DFA are well known within the scope of computer science. A DFA is a mathematical model of computation that can be thought of as an abstract machine that is in one of a finite set of states and can change (transition) from one state to another when a triggering event or condition occurs. Its computing power is greater than that of combinatorial logic but less than that of stack machines.

[0004] The automatic execution of contracts has also been studied in recent years in relation to blockchain technology. An example of this is CN105893042A. This document 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 related scripts can be used in a much more powerful and technically complex way to provide more intelligent behavior, as discussed in the present specification.

[0005] A blockchain is a computer-implemented decentralized, distributed peer-to-peer computer system composed of immutable blocks. Also, the immutable blocks are composed of transactions. This is related to a consensus-based protocol. Each block contains the hash of the previous block, and the blocks together form a chain that produces a tamper-resistant permanent record of all the transactions that have been written to the blockchain since its inception. Once these blocks become part of the blockchain, they can be inspected by the public because modifications can cause a change in the hash, but they cannot be modified or deleted.

[0006] A transaction includes a small program known as a script that is incorporated into its inputs and outputs. The script specifies how and by whom the outputs of the transaction can be accessed. Each unspent transaction (referred to as a UTXO) can be used as an input to a new transaction. Thus, the chain grows over time. Each output has an associated amount of the relevant currency available to an address on the network, provided that the requirements specified within the output's lock script are met. An address is the public key of a cryptographic 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, an output in a P2SH (pay to script hash) transaction is associated with a pubkey script (also known as an unlock script) that contains the hash of a second script, a Redeem script that the recipient must provide along with his signature in a later transaction in order to use the output.

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

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

[0009] Therefore, it is desirable to provide a solution that brings the benefits resulting from the automation of processes such as contracts, and the benefits of using the blockchain for this automation.

Summary of the Invention

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

[0011] According to the present invention, a method / system implemented by the blockchain can be provided. This can be described as a method / system for the automatic execution and control of technical processes. The present invention can provide an innovation that aids in the automatic execution of processes through the implementation or practical embodiment of a finite state machine or DFA in the blockchain infrastructure. The state of the machine may be defined and determined. The conditions or triggers for each state transition may be stored. When the process is executed, the executed state may be recorded in a permanent blockchain ledger. A blockchain transaction may function as an agent or participant that moves the machine from one state to another. Each state transition may represent or correspond to a step in the process. When the DFA defines a contract, the present invention can provide a mechanism for the automatic execution and enforcement of the responsibilities of different contract parties, as well as other terms and regulations.

[0012] Additionally or alternatively, the present invention may be described as a method / solution that uses a blockchain to control a process implemented by a computer that runs outside the blockchain. Accordingly, the present invention may involve the interaction of computer-based systems that are very different in terms of architecture and protocol. One or more of the above-described 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 of implementing (embodiment or realization) a DFA on or in relation to a blockchain. The DFA may be a software-based DFA. The blockchain may be implemented in relation to a Bitcoin-based protocol or may use another blockchain protocol. Additionally or alternatively, this may be a method configured to enable the determination of the state of a DFA implemented by a blockchain. This may be the current state. The method may enable the dynamic (runtime) determination of the state of the DFA. Accordingly, 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 for recording data regarding events that have already occurred.

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

[0015] Accordingly, the present invention may use unspent transaction outputs (UTXOs) on a blockchain to record and identify the state and / or the fact that a DFA is in a given state during execution.

[0016] The method may include using the output (UTXO1) of the transaction (Tx1) to use a further transaction (Tx2) to transition from the state of the DFA to a further state. The further state may be associated with a part of the data provided within the lock script of the unspent output (UTXO2) of the further transaction. Thus, the UTXO may record or embody the change of the DFA state in the blockchain.

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

[0018] The part of the 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 part of the code to determine whether the unspent output (UTXO1) should be used to move the DFA to the further state.

[0019] A part of the data within the unspent output (UTXO1) may be provided within the lock script.

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

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

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

[0023] The unused output (UTXO1) may include a lock script having the hash of the Redeem script, and the Redeem script must be provided by an input of a further transaction in order to use the output (UTXO1) and transition the DFA to another state. The Redeem script may have 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 embodiments. The system may include a blockchain platform (which may or may not be a Bitcoin blockchain), and at least one computing agent configured to implement a DFA by the blockchain.

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

[0027] The execution of the action may be identifiable or detectable from the state of the blockchain ledger. This can be achieved by considering or analyzing the outputs of one or more blockchain transactions. When a transaction is related to the DFA and / or a contract related to the DFA, the output may be inspected to determine whether the output has been used. The state of the DFA can be recognized from the fact that the output has not yet been used. This can be recognized by referring to the state transition table devised for the DFA. This is devised before the execution of the method / system.

[0028] Actions may be executed using transactions (Tx) on a blockchain. An action may be 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 the current state of the DFA based on whether an action has been executed.

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

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

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

[0033] The method may include determining a state transition table of the DFA. The state transition table may be encoded in software. The software may include instructions related to given input signals and state transitions and / or the machine-executable actions that trigger them.

[0034] The method may include the step of associating a portion of the lock script (the data therein) of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of a DFA. The method may have the step of 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 the data provided within the lock script of an unspent output (UTXO2) of the further transaction.

[0035] The method may include the step of implementing or representing at least one state transition trigger using a portion of code that includes at least one computer-executable condition, wherein the state transition trigger, when executed, causes the further transaction (Tx2) to use the output (UTXO1) of the transaction (Tx1), and thus move 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 the step of 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 the scope of a loop or iterative construct. The loop or iterative construct may end when a predetermined condition is met.

[0037] The DFA implemented by software may be implemented and / or executed 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 DFA implemented by software including software, wherein the software executes at least one condition using at least one input signal and, based on the result of the execution of the condition, is configured to execute an action according to the state transition table of the DFA, and the execution of the action is distinguishable from the state of the blockchain ledger.

[0039] The present invention may provide a method including the step of associating a part of the lock script of an unspent output (UTXO1) of a blockchain transaction (Tx1) with a given state of the DFA. A part of the lock script may be a part of the data within the lock script. This may be a part of the metadata. This may be an identifier, a label, or a tag. Thus, the present invention may use unspent transaction outputs (UTXOs) on the blockchain to record and identify the state and / or the current presence of the DFA in a given state during execution.

[0040] The method may have the step of 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 part of the data provided within the lock script of the unspent output (UTXO2) of the further transaction. Thus, the UTXO causes the change of the DFA state to be recorded or embodied in the blockchain.

[0041] The present invention may be described substantially with reference to the chapter of "Coding Techniques" described herein, but features from other chapters of this specification may also be incorporated, and any features described in this specification may be incorporated.

[0042] Additionally or alternatively, the present invention may include the step of monitoring and / or receiving an input signal and, in response to the input signal, executing a program configured to generate a blockchain transaction Tx2 that includes an unspent output (UTXO) and uses the 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 the first state of the DFA, and the unspent output (UTXO) of the 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 means of identifying a label, tag, or state in any form or format. This may be part of the data such as metadata, or may have 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 the further transaction Tx2.

[0045] The DFA may model or represent the execution of a (machine-executable) smart contract. The smart contract may be generated by computer-based resources by transplanting parameters into a template contract. Thus, contract generation can be automated.

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

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

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

[0049] Multiple programs may be generated and executed, and each program has an identifier for uniquely identifying the state of the DFA. Thus, a series of programs (scripts) may be used to execute a contract. Each script has a lifespan that substantially corresponds to the period of the state. That is, how long the DFA is, it may be or be in that given state.

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

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

[0052] The state of the DFA is represented by the unspent outputs (UTXOs) within a transaction on the blockchain. Using a given UTXO may represent a transition to a different state. The states, actions, conditions, and triggers may be provided within the transition table of the DFA and / or encoded 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 this via a blockchain. The system may include a blockchain (the blockchain 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 of the methods described above or below, a storage resource storing the state transition table of the DFA, which may be, for example, a hash table or a distributed hash table, and / or at least one template for blockchain transactions and / or at least one template for smart contracts.

[0054] The present invention may be described substantially in the chapter entitled "Compilation and Execution of DFA by Software" below. However, features from other chapters of the description may also apply. The system may be configured to perform or realize the execution of a state machine on the blockchain in order to perform the automatic execution of (smart) contracts.

[0055] Any feature mentioned in relation to the system of the present invention may be applicable to the corresponding method of the present invention, and vice versa. Any feature mentioned in this specification in relation to a particular embodiment or aspect of the present invention may also be applied to any other embodiment or aspect. The blockchain-based DFA of the present invention incorporates at least the following main features: Provide a blockchain-based implementation of a mathematical model of computation, which can be considered as an abstract machine that can change (transition) from one state in a finite set of states to another state when a trigger event (referred to as an input) in the finite set occurs. Provide a novel technology for establishing and automatically executing contracts based on the technical implementation of the responsibilities of different parties, such as a deterministic finite automaton (DFA) embodied in the computational and memory structures on a blockchain.

[0056] Existing blockchain infrastructure and protocols can be used. Enable and implement the automatic generation, control, and execution of smart contracts. Be automatically executable and enforceable by a computer. Permanent and immutable records of contracts, their execution, and results.

[0057] The present invention provides and utilizes at least the following advantages inherent in blockchain protocols and flat platforms: · Secure by design (the Bitcoin protocol does not require a trusted party). · Decentralized. Therefore, it avoids a single large-scale failure point and is not vulnerable to attacks. · Easy to manage and maintain (the Bitcoin network is easy to use). · Not expensive (usually, only a small transaction fee is expected under the Bitcoin protocol). · Not geographically restricted or limited and can be used by anyone with Internet access anywhere at any time. · When data is written to the blockchain, anyone can view it and it is transparent. · When data is written to the blockchain, no one can change it and it is immutable. · Privacy is maintained and personally identifiable information is not involved.

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Embodiments for Carrying Out the Invention

[0059] In this specification, the term "blockchain" is used to encompass all forms of electronic, computer-based distributed ledgers based on general will, including but not limited to blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variations. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Bitcoin is mentioned in this specification for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are included within the scope of the present invention.

[0060] Embodiments for the description of the present invention include the definition of a DFA that models a process or task such as a contract, and a related system of computing resources sometimes referred to as an agent or "bot". An agent is configured to generate transactions and submit them to the blockchain. However, the present invention is not limited to use related to contracts.

[0061] Referring to FIG. 1, the present invention provides the implementation of a process as an abstract DFA embodied on a computing platform - blockchain - that includes hardware and software components. FIG. 1 provides an overview of a system configured according to an embodiment for the description of the present invention. The system has a computing agent 3 that is capable of interacting with other entities 4 (e.g., humans or other computers) to receive instructions. These instructions can be, for example, which smart contracts to generate and execute. Thus, the computing agent 3 interacts with the physical world and, outside of itself, in the "real world", by responding to and causing events, to implement the present invention.

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

[0063] The DFA 2 itself is specified as a finite set {S, I, t, s0, F}. Here, S is the (finite) set of possible states in which the contract / DFA can exist, and I is the (finite) set of inputs (also known as the alphabet), which in the context of the present specification means any event or condition that can occur in relation to the contract, such as a payment being made, a security reaching maturity, a counter - party's default, etc. In the mechanism of the present application, these input signals are received / generated by one or more agents, which then determine the next state of the system (possibly the same state).

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

[0065] <Example of a simple DFA: Discount (zero - coupon) bond> For the sake of explanation, below, we consider discount (zero - coupon) bonds, which are simple bonds that are usually purchased at a certain price (usually at a discount to their face value) and then held for a specific period until their principal is repaid at maturity. Thus, a coupon bond is a debt contract with regular interest payments (coupons) that the holder receives from the issuer of the contract until its maturity, when in addition to the final coupon, the principal of the bond is also paid.

[0066] The possible states to be considered are S = {s0, f0, f1}, representing the holding state (s0), the normal termination of the contract (lucky path followed) or a happy ending (f0), and the state of failure, e.g., litigation (f1), respectively. The final states of the system are, therefore, F = {f0, f1}. The alphabet to be considered is I = {r, d, e}, representing the repayment of the principal amount at (or before) maturity (r), the issuer's default at (or before) maturity (d), and the termination of the contract without a refund (e), respectively. The transaction matrix for this simple contract is shown in Table 1.

[0067] [Table 1] Transition Table of the DFA Representing a Zero-Coupon Bond

[0068]

Table 1

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

[0070] Below, attention is directed to the flow of funds in the transactions (generation, transition, and completion). Importantly, due to the finiteness of the DFA and the (financial) contract, one notices that the process completes after a number of transitions. This does not necessarily mean that the maximum costs of establishing and executing the contract are combined and can be determined in advance, for example, at the time of establishing the DFA (assuming some finite fees for the computing agents and Bitcoin miners involved). This is given by the total amount of funds required to execute a contract following the longest possible path. This, of course, rules out the possibility of an infinite loop during execution, but note that this is not related to the current (financial) contract, and that even a contract such as a perpetual bond is a bond that should complete at a specific future point in time despite its name, for example, when the entity with the liability disappears or the payment becomes negligibly small due to inflation.

[0071] The specific allocation of fees, how much each agent receives for their work, is not a main element of the present invention despite its practical importance. Continuing with the example of the rationalized zero-coupon bond, this specification has the following: a fee for the generation transaction (o) of 3 mBTC, a transition fee (t) of 1 mBTC iFor a transaction, assume the fees for the completed transaction (ci) of 2 mBTC. These fees are automatically included in the transaction itself. Together with the total mining fees of 3 mBTC for the three transactions, this results in a maximum cost of 9 mBTC in total. In the very simple example of this specification, the lengths of all paths are equal. Therefore, the final cost of the contract will surely match its maximum cost. Since this generally does not need to be an example to fully explain the general flow of funds, assume that the funds provided for the execution of the contract are 10 mBTC and 1 mBTC is refunded to the same source of funds after completion. This replaces the final unused funds upon completion. That is, the maximum and used funds are different.

[0072] Assume that the funds (10 mBTC) for the establishment and execution of the contract are initially provided by a specific source of funds referred to as the "originator". As described above, in this example, this source also receives 1 mBTC of unused funds after completion. In principle, additional inputs and outputs of funds can also be included in the transaction. For example, the price paid for a zero-coupon bond, the repayment of the principal, or any other conceivable transfer of funds. This can be a matter of actual concern, but in this regard, it only obscures the basic elements of the present invention. For the sake of clarity, such details are not included in the following examples. However, it should be noted that the structure is completely general and such possibilities are not excluded.

[0073] <Implementation - DFA System and Method for the Explanation of Technical Solutions> Those skilled in the art will immediately understand that the system can be implemented in various ways. These variations are still included within the scope of the present invention. For example, the configuration and architecture of the agent system 3 can vary. For example, whether the specific agents involved are known in advance. Here, two technical design options are considered for the purpose of explanation. 1. When participation in the contract is kept relatively open and various computing agents can participate, a structure based on a standard blockchain transaction of the "transaction puzzle" type is possible. 2. Conversely, when the transactions for each state are pre-assigned to a specific agent (or group of agents), P2SH (pay-to-script-hash) transactions can be used.

[0074] Blockchain transactions based on puzzles and P2SH transactions are known in the field of blockchain technology. Those skilled in the art will also understand that there may be numerous possibilities in addition to or as an alternative to the two options described above. For example, one embodiment may use a plurality of agents that change over time, and / or a hierarchical structure of agents, etc. There are many possibilities, but in this specification, only two options are described from which those skilled in the art can immediately derive other possible variations and implementation options.

[0075] However, note that since the parties that provide / receive funds in the transaction (e.g., the issuer, purchaser, recipient, etc.) are not essential for the present invention, the type of blockchain transaction used in one embodiment is not essential for the present invention. Instead, the main elements of the present invention are that at any given time, the state of the task / contract is defined within the blockchain, and it provides a mechanism (regardless of its detailed specific implementation) that enables the automatic generation of the contract, its execution on the blockchain, and the implementation of appropriate results according to the series of events that occur. Since the entire mechanism is embodied on the blockchain, note that this provides, among many other advantages, in particular, a permanently immutable record of the contract history and results.

[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 ability can participate, provide some processing ability to the system (e.g., a provider of establishing and executing DFA contracts based on blockchain), and be rewarded for their resources. In such a situation, it is impossible to know in advance which specific agent will submit a transaction to the blockchain. That is, it is impossible 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> Here, <state s i puzzle>=HASH(<state s i puzzle solution>), and the puzzle solution itself may include the contract code, labels of the state, any other desired information, e.g., any desired information including some sort for additional 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 immediately understood by those skilled in the art in the context of the present invention. The series of actions is as follows with reference to FIGS. 1 and 2. First, the agent system (3, step 101) generates a DFA structure 2.

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

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

[0079] In step 104, the agent generates a genesis transaction to state S0. This can be as shown in FIG. 4. Assume that the funds allocated to the contract are 10 mBTC, the agent fee is 3 mBTC, and the funds going out for further processing of the contract are 6 mBTC (the 1 mBTC mining fee is implicit). At this stage, the contract is instantiated as a structure on the blockchain and is in its initial state s0. That is, there is a UTXO associated with the state s0 of the specific contract on the blockchain.

[0080] For the transaction for the description of FIG. 4, assume that the funds allocated to the contract are 10 mBTC, the agent (botnet) fee is 3 mBTC, and the funds going out for further processing of the contract are 6 mBTC. The 1 mBTC mining fee is implicit.

[0081] As can be inferred by considering the transaction of FIG. 4, the original funds of the contract are received by a P2PKH-type transaction (from the "originator" in this example), output 0 (puzzle-based) can be unlocked by any agent owning the puzzle solution, and output 1 (P2PKH) pays the desired fee to agent 3 who has successfully placed the transaction on the blockchain.

[0082] By the execution of the contract, successive transactions are executed by automated agent 3 in a manner similar to that illustrated in FIG. 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 only the part of the transition table corresponding to the current state), and interacts with some entity or entities (e.g., some other computer within the agent system, or some data / signal source) to obtain the puzzle corresponding to the appropriate next state (f f ). The agent can then submit the transaction to the blockchain. If the transaction is verified by the blockchain network, the agent receives the associated fee and the DFA goes to state f f . In the transition of FIG. 5, assume that the incoming funds are 6 mBTC, the agent fee is 1 mBTC, and the funds going out for further processing of the contract are 4 mBTC (the 1 mBTC mining fee is implicit).

[0083] FIG. 6 shows the final structure of the possible transactions, i.e., the transaction (c f) is shown. In Figure 6, the input part follows the same transaction puzzle logic as before. On the other hand, output 0 pays the unused funds (1 mBTC as described above) back to the originator, and output 1 pays the fee to the agent. In Figure 6, assume that the incoming funds are 4 mBTC, 1 mBTC of unused funds are returned to the originator, and the agent fee is 2 mBTC (the 1 mBTC mining fee is implicit).

[0084] <Implementation Option 2: P2SH-Based Transaction> The approach based on the puzzle described in Option 1 is suitable for use where there are a large number of empirically unknown participants. However, in other cases, a limited or acceptable number of recognized computing agents 3 may be designed for use related to the present invention. In this case, a P2SH-type transaction can be configured to include the public keys of the known agents 3, thereby providing an additional security layer and may be more suitable for use. For the case of a single recognized agent, the realizable 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 a number of recognized agents by also including the signatures of a number of recognized agents. As described above, the metadata of state s i may include, for example, any of the following desired information: <state s imetadata >= HASH(<contract code; state s i ; other data>) A series of actions is the same as in the above-described case of the puzzle-based approach. First, the agent system 3 generates a DFA structure and stores the transition table externally (e.g., in a DHT). Next, it is determined which agents will process the transaction and search for / generate their public keys. This public key is then included in the Redeem script 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 generated transactions as specified in FIG. 7. The example in FIG. 7 is similar to FIG. 4 but uses the P2SH transaction type for DFA states.

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

[0086] The changes are similar, but for details, FIGS. 8 and 9 provide examples of transition transactions and completion transactions based on the P2SH transaction type. The flow of funds is the same as described above. FIG. 8 shows an example similar to FIG. 5 but using the P2SH transaction type for DFA states. FIG. 9 shows an example similar to FIG. 6 but using the P2SH transaction type for DFA states.

[0087] <New Coding Technique for DFA Implemented by a Computer> The DFA based on the blockchain has been described above, but here we draw attention to a particularly advantageous and novel aspect of the present invention. In this chapter, a novel technique of the present invention for coding the states of a DFA into a computer-readable and executable form is described.

[0088] In conventional methods for such machines, the state is determined statically (a priori) and represents some specific configuration or some specific meaning of the system. For example, the state can be given a set or name and associated with a set of tags, or with unused transaction outputs (UTXOs) as described above for a blockchain-based DFA. This is sufficient for the system to operate as the calculation itself (the output) is determined by how the system moves between states, while accepting an input chain.

[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, although it may be very difficult to have an a priori interpretation of the states, the same output can result for each given input chain. For example, consider the case where they are deployed on different physical machines or are considered for solving different problems. This also naturally leads to the concept of DFA minimization (see https: / / en.wikipedia.org / wiki / DFA_minimization).

[0090] The static determination (tagging) of the state is sufficient for the abstract function of the state machine itself and sufficient for many problems where only the output of the calculation is relevant, but the meaning of the state itself can be practically important and not inferable from the state tags. This can be because, for example, it is intentionally hidden for privacy or confidentiality reasons. An example is found when the calculation is distributed and executed by computing agents that (intentionally) do not have complete information about the system. In these cases, a dynamic determination of the state of the system is required at runtime.

[0091] An advantageous aspect of the invention described in this specification is a coding technique that enables the dynamic (on-the-fly, runtime) determination of the states of a DFA. Such a DFA may include, but is not limited to, those associated with the distributed execution of contracts as described above, and the invention is not limited with respect to the purpose of the DFA for which the techniques of the invention are used or their specific implementation. Since conventional approaches pre-determine states in a static manner, the dynamic state determination of the present invention is the opposite of traditional methods and provides a completely different technical solution to those skilled in the art. The present invention goes beyond the mere use of a blockchain for storing data regarding the events that occur.

[0092] For the description and explanation of the coding technique of the present invention, coupon bonds and perpetuities are 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 uses and situations. The characteristics of coupon bonds have been described above. A perpetuity is a never-ending, continuous payment. That is, coupon payments continue in principle forever. In practice, however, due to the effect of compounding at a positive interest rate, at a certain point in time, the amount of the coupon has no practical significance, so the discounted value of the contract is actually finite.

[0093] <Example 1 of the coding technique of the present invention - direct scenario> As already explained, a DFA is composed of a finite set {S, I, t, s0, F}, representing possible states (S), inputs (I), transitions (t), an initial state (S0), and final states (F), also called accepting states. Furthermore, a set of actions (a) is defined, which represents the side effects of the execution and does not determine the output of the calculation.

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

[0095] [Table 2] List of Contract States of Coupon Bonds

[0096] [Table 2] [Table 3] List of Contract Inputs (Event Alphabets) of Coupon Bonds

[0097] [Table 3] All of these inputs can be automatically detected and determined by a computer. In the above example of Table 3, it is possible for a computer to check whether a specific date / time has been reached, or whether a specific payment has been made / has not been made via a blockchain transaction. The blockchain can be traversed to check whether there is a transaction for making a payment in the ledger. Since the Bitcoin blockchain provides a permanent, publicly available, tamper-resistant record, this verification can be performed by a computing agent without the need for human intervention.

[0098] [Table 4] List of Contract Actions of Coupon Bonds

[0099] [Table 4] Once these elements are defined, the functionality of the system can be fully specified by a state transition table. In the state transition table, the current (initial / transition source) state of the system (row) together with the appropriate input (column) determines, according to the table, the next (final / transition destination) state of the system and the actions to be performed in parallel with the transition. In the example of the present invention, this is given in Table 5. Note that the execution starts in the initial state (S), and the possible final (acceptable) states are only F0 and F1. Since these states indicate the final processing of the execution, i.e., there are no transitions associated with them, they can be omitted from the rows of the table. An alternative format of the transition table is given in Table 5.

[0100] [Table 5] State Transition Table for Coupon Bonds: 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 a given state, i.e., it does not apply to the state.

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

[0102] As described above, although the function of the DFA does not need to be strict, a dynamic determination of the state of the system that is readable by both humans and computers is actually necessary and constitutes an aspect of the present invention described in this specification. Each state is characterized by a unique set of conditions that either occur or do not occur or are irrelevant as a result of a particular state. Each condition must be explicit and (machine) testable. In other words, there must be a clear computational method for determining whether a condition occurs as a result. Thus, one embodiment of the present invention may interact with the physical world or, at least, the external world of the computer on which the software is running in terms that values or inputs for testing can 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 an example of the present invention, this can be achieved by the set of conditions presented in Table 6. In Table 6, the states to be tested are given in rows, and the defined conditions are given in columns. Each condition t indicates whether a particular date has arrived. For example, the condition indicated as t0 means t > t0, and each condition ci (or p) is whether the corresponding payment has been made. Note that the payment of a coupon (or principal) whose due date has not yet arrived is irrelevant to the state that occurs before the corresponding maturity date.

[0104] Of course, whether this or an equivalent set of conditions is used is irrelevant as long as they uniquely determine all possible states. That is, the chain of true, false, or irrelevant values for each state is unique. It should be further noted that in this example, only binary values (true or false) or irrelevant states have been considered, but in principle, these can take multiple values. Furthermore, in addition to atomic conditions as described in the present specification, each condition can also represent a composed condition consisting of several (sub) conditions. All these variations are immediately obvious to those skilled in the art and are included within the scope of the present invention.

[0105] The dashed box in Figure 10 means the last point to be solved. At present, the figure is completely valid and should correctly describe the dynamics of the coupon bond, but the state T i and state C i Note that there are interesting similarities between them. That is, these states are very similar in meaning and differ only in the time period they refer to or the coupon number (i). Therefore, these states can also be represented by a common repetitive or recursive state, as well as additional information indicating which coupon / period they refer to. This can be naturally extended to a state that repeats itself indefinitely, thus opening up the possibility of coding perpetual bonds. The definition of the coding method using such a recursive state is solved in the next chapter below.

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

[0107] [Table 6] [Example 2 - Recursive State of the Encoding Technology of the Present Invention] As described above, some subsets of the states of the coupon bond DFA from the last part or the coupon bond (T i and D i state) correspond to very similar interpretations of the states of the state machine and differ only in the time period or coupon number (i) they refer to. That is, in a sense, these states can be considered as states that repeat themselves many times (for example, from i = 1 to a given imax, where imax = 3 in this example). In this case, it makes sense to simplify the representation of the DFA by including all these states in the recursive state (R) to be handled separately. With this simplification, the following presents a list of contract conditions (Table 7), a state transition table (Table 8), an equivalent state diagram (Figure 11), and a state definition table (Table 9) for the exemplary coupon bond DFA of the present invention. Note that the other elements (inputs and actions) of the DFA remain the same as in the previous chapter.

[0108] [Table 7] List of Contract States of Coupon Bonds with Recursive States

[0109] [Table 7] [Table 8] State Transition Table of Coupon Bonds with Recursive States

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

[0111] [Table 9] Of course, all this does is hide the complexity of the bond dynamics within the recursive state, and the recursive state 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 programming languages. The recursive state itself is also defined as a state machine. Note, however, that since the execution of the abstract calculation does not imply a start or end within the recursive state, the initial and allowed states are replaced by entry and exit points in this context. Below, a list of contract states (Table 10), a state transition table (Table 11), and a state diagram (Figure 12) for the recursive state are presented.

[0112] [Table 10] List of Contract Sub - states of the Recursive State

[0113] [Table 10] [Table 11] Internal State Transition Table of the Recursive State

[0114] [Table 11A] The novelty of this approach is the index (i) that tracks the history of how many times a state has been occupied. The increase of this index and similar quantities (e.g., total payment amount) can be calculated externally (in the coding scheme as described later) or achieved by additional DFA actions as shown in Table 11 for state C. Note also that the input (alphabet) of the internal state of this recursive state may depend on the internal index (i) and / or similar quantities. As described 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 coding scheme for the recursive state, when extended, appears very similar to the relevant part of Table 5. However, since the spirit of this approach is to expand and handle each internal (sub) state separately, it is considered more natural not to show it explicitly in the table. Instead, Figure 4 presents the pseudocode of an algorithm that assigns the correct value (true or false) to the variables associated with the conditions of the state machine coding. Of course, variables associated with irrelevant conditions do not need to be assigned any value. In Figure 4, as in Table 5 above, each condition ti indicates whether a specific day has arrived (i.e., ti = T means t ≥ t i ), and each condition ci indicates whether the corresponding (i-th) coupon has been paid.

[0116] Below, the pseudocode of an algorithm that assigns appropriate values to the variables associated with the conditions of the coding scheme for the internal state of the recursive state is provided.

[0117]

Number

[0118] [Number] [Table 11] Alternative format of the state transition table of the coupon bond in Table 5

[0119] [Table 11B] [Compilation and Execution of DFA Implemented by Computer] Here, a novel technique for the establishment (compilation) and execution of a contractual agreement based on the realization of the responsibilities of different parties (and other terms and regulations) as a computational structure modeled as a state machine is described.

[0120] In this scenario, the advantageous technical aspects of the system regarding the establishment and execution of such smart contracts via a blockchain are described. This deals with the flow of information between different (computer) agents that effectively execute the contract. Very generally, this system is represented as a "botnet" (a collection of computing agents), and often does not specify which agent actually executes the described actions. Those skilled in the art will understand that there are many ways to implement the details of such an implementation.

[0121] As described above, a contract for a European call option is used as an example for explaining the essence 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, product, or other asset at a specified price (exercise price) on a specified date (expiration date). If the buyer decides to exercise the option, this decision (rationally) occurs when the price of the asset on that day is higher than the exercise price. However, the writer (seller) of the option himself / herself sells the asset to the holder (buyer) at that price on that day. In this case, the contract may alternatively be settled by paying the holder an amount equal to the difference between the market price of the asset at the expiration date and the exercise price, and in other cases, no payment is required and it is assumed that the option expires without being exercised.

[0122] (Finance) The standard way to establish and execute a contract is for a human to sign a legal document, interpret and execute its terms, and sometimes litigate. These contracts are considered to consist of the text defining the items and a set of values of the parameters specific to the contract, such as dates, writers, public keys, etc. These separate elements are separated in the system of the present invention. Here, the essence of the contract text is captured as an abstract machine, and the DFA and the set of values of the parameters of a specific instance of the contract are provided independently as described above.

[0123] Returning to the example of the present invention, the DFA computing system is composed of a finite set {S, I, t, s0, F}, representing possible states (S), inputs (I), transitions (t), an initial state (S0), and final states (F), also called accepting states. Further, although not essential for the DFA structure itself, here, a set of actions (a) that an agent is required to perform in parallel with the submission of a transaction is considered. Below, as in the prior art, the current time (date) is represented by t, the expiration date by T, the asset price at expiration by S T is represented by, and the exercise price by K.

[0124] The main focus in this chapter of the present application is the establishment of computer agents associated with the states of a DFA machine. These are implemented as computing resources having scripts. It should be noted that the term "script" should not be confused with the script of a blockchain transaction such as an unlock or lock script in this context. Here, the term "script" is used in a more general computer processing sense. A person skilled in the art can immediately understand this and interpret the meaning of the term from the context.

[0125] An agent (script) can change states, perform transitions, and, in parallel, spin off other sets of scripts associated with subsequent states. The dynamics of the DFA state, i.e., runtime identification, by a computer script with appropriate capabilities is a major inventive element of this aspect of the present invention. In a rationalized example of the present invention, the possible states of a contract and the sufficient conditions for their definitions are given in Table 12. Here, the (XML) label of the state and an explanation in the natural (human) language of the state are also given.

[0126] Note that not all conceivable states are considered in the contract as to what can occur in the event of, for example, bankruptcy, death of the holder, internet shutdown, etc. However, the current focus in this chapter of the present invention is the analysis of contract compilation and execution, not the complexity of the DFA itself, so the examples of the present invention are appropriate and as simple as possible while still being sufficient.

[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 thus defined by this set of values, with one value for each condition; also note that a condition can have multiple components.

[0128] [Table 12] Continue the description of the different elements of the abstract DFA and refer to the following list of inputs. This is a list of events, also called the alphabet. This is a list of events that can occur in relation to the contract. For example, reached maturity, received payment, etc. These inputs, together with the current set of states of the DFA, determine the transactions to be submitted to the blockchain, as well as the parallel actions to be executed by the agents. However, note that technically the transition function is an S×I→S mapping, but not all inputs are necessarily related to all states. In the rationalized example of the present invention, these are given in Table 13, together with the (XML) labels and the natural language descriptions of the events.

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

[0130]

Table 13

[0131] [Table 14] List of contract actions

[0132]

Table 14

[0133] [Table 15] State Transition Table of the Contract

[0134]

Table 15

[0135] <Technical Explanation> The DFA compilation mechanism consists of different elements and files discussed below. The main focus of this chapter of the present application is how to generate not only the blockchain transactions but also the scripts after the contract is fully executed, which are the computational structures embedded in these files and the scripts associated with different states. First, 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, assume that the main language used for the subsequent file generation and contract execution is Python 3.5, and the parameters are provided in an XML 1.0 document. Of course, the details of these implementations are not essential to the present 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 a particular upcoming contract, namely a certain European call option. In this example, this is handwritten, but it could also be generated automatically, i.e., by computing resources or agents, or by a human entering appropriate values here also via a graphical user interface (GUI) created by Python.

[0138] The main file of the system's technical specifications is the (Python) main script. This file contains 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 examine stock prices, clocks, etc.), or that are inserted when executed. In the case where it is relevant, i.e., in a DFA implementation based on a blockchain, this file may include a hard-coded template of the (Bitcoin) transaction to be submitted to the network by the script.

[0139] As described above, the state transition table completely determines the DFA at the abstract level and contains only the elements necessary for its own function. However, note that there is a correspondence between the legal text and the DFA state transition table. In addition to these essential elements, optionally, the script can also include / generate different human-readable documents, such as state diagrams, alphabets, etc.

[0140] To compile and execute a DFA contract based on a blockchain, a user (human or computer) needs to fill in the values of the parameters and execute the main script. Using this hard-coded information on the script and the values of the parameters, when executed, the script establishes the contract, for example, places the contract on the blockchain and generates one or more computer programs (other scripts). The one or more computer programs are continuously executed by a system of computing agents that execute the contract. A possible series of instructions to achieve this is as follows: 1. Read out the parameter values (or directly input the values 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 a distributed hash table (DHT), for example, into the BitTorrent network if this brings any benefits. 2. Use the parameters and the hard-coded contract template to generate a legal contract. This document needs to be (digitally) signed by the creator of the call option. 3. (Optional) Generate a human-readable document of the contract. 4. Use the parameters and the hard-coded input and action functions to generate instances of these functions with appropriate parameter values. 5. Load the state transition table into memory (HT or DHT). 6. When relevant, generate the generated transaction as specified and submit it to the blockchain network. This can be executed by using the Pybitcointools library. This generates UTXOs within the blockchain associated with the specific state of the contract on the Bitcoin blockchain as described above. 7. Generate a Python script associated with the generated state (s0) and execute it (on the same or another computer). This agent (or set of agents) receives / generates appropriate inputs, executes actions that conform to the appropriate actions and states, and ultimately completes the execution of the contract or generates a derived subsequent script that controls the transition transactions to another state and these states. 8. End the compilation (main script).

[0141] Upon completion of the compilation stage, the system starts and executes. 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 executed on botnet agents) that monitor the inputs are ready to perform actions and generate appropriate transitions that change the state of the DFA to another state or end it.

[0142] A series of instructions for the transition are as follows: 1. Monitor or generate DFA inputs. Function calls such as clock checks, message reception, etc. 2. When the input is determined, read the transition table for the current state. This determines the next state and, optionally, the action to be taken. 3. If any, depending on the complexity, perform actions for subroutines or function calls as appropriate. 4. When relevant, generate a transition transaction according to the blockchain and submit it to the blockchain. 5. Generate and execute the Python associated with the following state. 6. Terminate the current script. The sequence of instructions for the completion of the contract is as follows: 1. Monitor or generate DFA inputs. These can be subroutines or function calls such as clock checks, message receptions, etc. 2. When the input is determined, read the transition table for the current state. This determines that the contract should be completed and, in some cases, the actions taken. 3. If any, depending on the complexity, perform actions on the function calls in some cases. 4. When relevant, generate a completion transaction according to the blockchain and submit it to the blockchain. This uses the last UTXO associated with the contract. 5. Terminate the current (and last) script.

[0143] Therefore, the DFA is executed by a set of independent agents (scripts). The set of independent agents (scripts) receives sufficient information from the previous agent and then returns to the initial main script and parameter file.

[0144] According to one embodiment of the present invention, therefore, the contract is executed by a set of agents (implemented as a script) and is dynamically generated when the system transitions between states. These agents should have access to the current state of the system (e.g., when embodied by UTXOs on a blockchain), receive or generate appropriate inputs according to events occurring in the real world, perform appropriate actions, and execute appropriate transactions. All of this can be achieved within a script (e.g., Python) using appropriately defined functions and existing libraries. For example, in the case of the European call option in this specification, it should have access to the clock, a check as to whether the contract has expired, and the current price of the asset. Given this information, it is possible to determine which appropriate inputs should be considered according to the parameters. Given this and the actions specified in the transaction matrix, the agent can determine which blockchain transactions should be generated, thereby placing the system in the next state (in this example, there is only one state), or appropriately completing the execution of the contract.

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

Explanation of Signs

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

Claims

1. A method for implementing a DFA on a blockchain, comprising: Blockchain transaction (Tx １ ) Unspent Output (UTXO) １ ) to a given state of said DFA; A method including

2. said transaction (Tx １ ) by using said output (UTXO １ ), using a further transaction (Tx ２ ) to transition the state of said DFA to a further state, further includes, wherein the further state is associated with a part of data provided within an unspent output (UTXO ２ ) of the further transaction, the method according to claim 1.

3. The method according to claim 2, wherein a part of the data in the unused output (UTXO 1) is provided in a lock script.

4. Performing or representing at least one state transition trigger using a portion of the code, wherein the state transition trigger, when executed, causes the output (UTXO １ ) of the transaction (Tx １ ) to be used in a further transaction (Tx ２ ), thereby moving the DFA to another state ２ ), causing the output (UTXO １ ) of the transaction (Tx １ ) to be used in a further transaction (Tx ２ ), thereby moving the DFA to another state １ ), causing the output (UTXO １ ) of the transaction (Tx <000008>) to be used in a further transaction (Tx <000007>), thereby moving the DFA to another state １ ), causing the output (UTXO <000009>) of the transaction (Tx <000008>) to be used in a further transaction (Tx <000007>), thereby moving the DFA to another state The method according to any one of claims 1 to 3, further comprising

5. The method according to claim 4, wherein a part of the code includes machine-testable conditions that provide a Boolean result based on an input.

6. The input is determined at runtime and is used by a portion of the code to determine whether the unused output (UTXO １ ) should be used to move the DFA to the further state, the method according to claim 5.

7. The method according to any one of claims 1 to 6, wherein a part of the data is part of a tag, label, or metadata.

8. The method according to any one of claims 1 to 7, wherein the DFA is a model of a machine-executable smart contract.

9. The unused output (UTXO １ ) includes a lock script having a hash of a puzzle, and a solution of the puzzle must be provided by an input of a further transaction to use the output (UTXO １ ) and to transition the DFA to another state. The method according to any one of claims 1 to 8

10. The unused output (UTXO １ ), which includes a lock script having a hash of a Redeem script, where the Redeem script must be provided by an input of a further transaction in order to use the output (UTXO １ ) and transition the DFA to another state, the method according to any one of claims 1 to 9.

11. The method according to claim 10, wherein the Redeem script has a cryptographic key.

12. The method according to any one of claims 1 to 11, further comprising the step of using one or more computing agents to execute the steps according to any one of claims 1 to 11.

13. A method for implementing a DFA on a blockchain, the method comprising: A step of executing a program, the program monitoring and / or receiving an input signal, responding to the input signal, and including an unspent output (UTXO) and using the output of a previous transaction Tx １ of a blockchain transaction Tx ２ configured to generate, the step comprising Previous transaction Tx １ The output of which includes an identifier associated with the first state of the DFA, Transaction Tx ２ wherein the unused output (UTXO) includes a further identifier associated with a further state of the DFA

14. A system configured to implement, realize, or embody a software-based DFA, wherein the DFA to be implemented, realized, or embodied follows the method according to any one or more of claims 1 to 13.

15. A system configured to execute the method according to any one of claims 1 to 13.

16. The system comprises: A blockchain platform; and At least one computing agent configured to implement the DFA via the blockchain. The system according to claim 15, comprising

Images