Execution of smart contracts using distributed cooperation

Abstract

To provide a computer-implemented method and system for determining an outcome of a smart contract in a block chain network.SOLUTION: A method includes the steps of: determining, between counterparties, a set of conditions having a plurality of possible outcomes that includes a first possible outcome associated with a first distribution of a digital asset and a second possible outcome associated with a second distribution, different from the first distribution, of the digital asset; creating a counterpart transaction that includes, as an output, the set of conditions and the digital asset; receiving an outcome from a third party, an outcome corresponded to the first possible outcome or the second possible outcome; and creating an outcome transaction to transfer control of the digital asset of the counterparty transaction, the outcome transaction including the outcome as an input.SELECTED DRAWING: None

Description

[Technical Field]

[0001] This invention relates, in general, to blockchain technology, and more specifically, to controlling the execution of blockchains based on smart contracts that utilize a combination of dealerless secret sharing and elliptic curve arithmetic and signature properties. The invention further employs cryptographic and mathematical techniques to implement security in relation to electronic transfers conducted over a blockchain network. The invention is particularly suited to, but not limited to, use in smart contracts. [Background technology]

[0002] In this specification, the term “blockchain” may refer to any of several types of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have also been proposed and developed. While the example of Bitcoin may be mentioned for convenience and illustrative purposes as a useful application of the technology described herein, Bitcoin is only one of many applications to which the technology described herein may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the technology described herein may offer the advantage of utilizing a blockchain implementation that has similar limitations to Bitcoin in relation to what constraints can be enforced in a transaction, regardless of whether or not a cryptocurrency exchange occurs.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system. This ledger is composed of blocks, which may consist of transactions and other information. In some examples, a "blockchain transaction" represents an input message encoding a structured set of field values, including data and a set of conditions. Satisfaction of the set of conditions is a requirement for the set of fields to be written to the blockchain data structure. For example, in Bitcoin, each transaction is a data structure encoding the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. In some embodiments, a "digital asset" represents binary data associated with the right to use it. Examples of digital assets include Bitcoin, Ether, and Litecoins. In some implementations, the transfer of control of a digital asset can be accomplished by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block contains a hash of the previous block. As a result, the blocks are chained together, generating a permanent, immutable record of all transactions written to the blockchain since its inception. A transaction contains a small program known as a script. The script has embedded inputs and outputs that specify how and by whom the transaction's output is accessible. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In some examples, “stack-based scripting language” refers to a programming language that supports various stack-based or stack-oriented execution models and operations. That is, a stack-based scripting language may utilize a stack. A stack allows values ​​to be pushed to the top of the stack or popped from the top of the stack. Various operations performed on the stack may result in one or more values ​​being pushed to the top of the stack or popped from there. For example, the OP_EQUAL operation pops the top two items from the stack, compares them, and pushes the result (e.g., 1 if equal, 0 if unequal) to the top of the stack. Other operations performed on the stack, such as OP_PICK, may allow items to be selected from a position other than the top of the stack. In some scripting languages ​​utilized by some embodiments of the present invention, there may be at least two stacks, namely a main stack and an alternate stack. Some operations in the scripting language can move items from the top of one stack to the top of the other stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alternate stack. It should be noted that, in some cases, stack-based scripting languages ​​are not simply limited to a strict last-in, first-out (LIFO) method. For example, a stack-based scripting language may support operations that copy or move the nth item in a stack to the top (e.g., OP_PICK and OP_ROLL in Bitcoin, respectively). Scripts written in a stack-based scripting language may be pushed onto a logical stack that can be implemented using any suitable data structure such as vectors, lists, or stacks.

[0005] For a transaction to be written to the blockchain, it must be "verified." Network nodes (mining nodes) perform tasks to ensure that invalid transactions are rejected from the network and that each transaction is valid. Nodes may have different criteria for validity than other nodes. Since validity in the blockchain is based on consensus, a transaction is considered valid if the majority of nodes agree that the transaction is valid. Software clients installed on the nodes perform this verification task for transactions that reference unspent transactions (UTXOs) by executing unspent transaction (UTXO) lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and other verification conditions are met, where applicable, the transaction is verified by the node. Once a verified transaction is propagated to other network nodes, mining nodes can choose to include the transaction in the blockchain. Therefore, for a transaction to be written to the blockchain, it must (i) be verified by the first node that receives the transaction, and if the transaction is verified, that node relays the transaction to other nodes in the network, (ii) be added to a new block constructed by mining nodes, and (iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered approved when enough blocks have been added to the blockchain to actually create an irrevocable transaction.

[0006] Blockchain technology is most widely known for use in cryptocurrency implementations, but digital entrepreneurs are beginning to develop uses for both Bitcoin-based cryptographic security systems and data that can be stored on the blockchain to implement new systems. If blockchains can be used for automated tasks and processes not limited to the cryptocurrency field, it will be very advantageous. Such solutions can diversify their uses while leveraging the benefits of blockchains (e.g., permanence, tamper resistance of event records, distributed processing, etc.).

[0007] This disclosure describes technical aspects of computer programs based on one or more blockchains. A computer program based on a blockchain is a machine-readable and executable program recorded within a blockchain transaction. A computer program based on a blockchain includes rules that can process inputs to produce results and then execute actions depending on those results. One area of current research is the use of computer programs based on blockchains for the implementation of "smart contracts." Unlike traditional contracts that can be described in natural language, a smart contract can be a computer program designed to automate the execution of machine-readable contract or consent terms.

[0008] In an embodiment, the interaction with a specific entity can be encoded at a specific step within a smart contract, but in other cases, the smart contract can be automatically and self-executing. It is machine-readable and executable. In some examples, the self-execution represents the execution of a smart contract that is successfully executed to enable the transfer of UTXOs. In such examples, the "entity" that can cause the transfer of UTXOs represents an entity that can generate an unlock script without requiring the provision of any secret knowledge. In other words, the unlock transaction is verifiable without verifying that the source of the data (e.g., the entity that generated the unlock transaction) has access to a cryptographic secret (e.g., a secret asymmetric key, a symmetric key, etc.). Also, in such examples, the self-execution represents causing the verification nodes of the blockchain network to execute the unlock transaction subject to the constraints. In some examples, "unlocking" a UTXO (also known as "using" a UTXO) is used in a technical sense and represents generating an unlock transaction that references the UTXO and executing it as valid.

[0009] A blockchain transaction output includes a lock script and information regarding the ownership of a digital asset such as Bitcoin. The lock script, which may also be referred to as an encumbrance, "locks" the digital asset by specifying the conditions that are required to be satisfied in order to transfer the UTXO. For example, the lock script may require that specific data be provided within the unlock script in order to unlock the associated digital asset. The lock script is also known as the "scriptPubKey" in Bitcoin. The technique of requiring a party to provide data in order to unlock a digital asset includes embedding a hash of the data within the lock script. However, this causes problems when the data is undetermined (e.g., unknown, not fixed) when the lock script is generated.

[0010] The present invention may be described as a verification method / system and / or a control method / system for controlling the verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in a record of the transaction on the blockchain. This may, in some applications, result in the exchange or transfer of digital assets via the blockchain. A digital asset may be a unit of resource managed by the blockchain. In some embodiments, a digital asset may be used as a cryptocurrency, but in embodiments, digital assets may be used in other contexts as an addition or alternative. While the present invention is applicable to the control of digital assets, it is also applicable in other contexts that utilize blockchain data structures, which are inherently technical and do not necessarily involve the transfer of digital assets. [Overview of the Initiative]

[0011] Therefore, it is desirable to provide methods and systems for improving blockchain technology in one or more of the above-described embodiments. Such improved solutions are devised hereby. Accordingly, according to the present invention, the methods defined in the appended claims are provided.

[0012] Therefore, a method carried out by a computer, A step in determining a smart contract between trading partners, wherein the set of conditions is as follows: The first possible outcome associated with the first distribution of digital assets, and A second possible outcome associated with the second distribution of the digital assets, different from the first distribution, A step having multiple possible outcomes, The output includes the step of generating a customer transaction that includes the set of conditions and the digital assets encoded in computer executable instructions, A step of receiving an outcome from a third party, wherein the outcome corresponds to the first possible outcome or the second possible outcome, A step of generating an event transaction to transfer control of the digital asset of the aforementioned trading partner transaction, wherein the event transaction includes the event as an input, As a result of verifying the event transaction at a node in the blockchain network, the digital assets are distributed to the trading partner according to the first possible event or the second possible event, and at least partially based on the event; It is desirable to provide a method that is carried out by a computer, including [the necessary components].

[0013] The third party may be a group containing multiple members.

[0014] The outcome may be the result of agreement on responses provided by multiple members.

[0015] The number of members, including multiple members, may be determined. Additionally or alternatively, a threshold number may be determined to determine the outcome. The outcome may be that the responses submitted by at least one of the multiple members match based on the threshold number.

[0016] The outcome may be determined at least in part based on key shares submitted by multiple members. Alternatively, the key shares may be determined according to a secret sharing scheme.

[0017] Key sharing may be committed to a block within the proof-of-stake blockchain by multiple members.

[0018] At least one cooperative algorithm transaction may be generated associated with the second digital asset. Additionally or alternatively, the second digital asset may be distributed to a third party as a result of verifying the distribution transaction generated to transfer control of the second digital asset.

[0019] The second digital asset may include a deposit portion contributed by a third party.

[0020] As an addition or alternative, the second digital asset may include a distribution portion contributed by the trading partner.

[0021] Multiple members may include members whose responses do not conform to the consensus. Additionally or alternatively, as a result of responses not conforming to the consensus, the distribution of the second digital asset may exclude members from receiving their share of the distribution.

[0022] The aforementioned digital asset may include a first quantity of the digital asset contributed by the first party and a second quantity of the digital asset contributed by the second party.

[0023] One of several possible outcomes may be associated with the expiration condition of the condition set. Additionally or alternatively, as a result of validating the outcome transaction and as a result of the expiration condition occurring, the first quantity may be refunded to the first party. Additionally or alternatively, as a result of validating the outcome transaction and as a result of the expiration condition occurring, the second quantity may be refunded to the second party.

[0024] Multiple secret success keys corresponding to multiple possible outcomes may be received from a third party. Additionally or alternatively, a possible outcome may be a cryptographic key corresponding to one of the multiple secret success keys. A secret value determined by the trading partner may be combined with each of the multiple success secret keys to generate multiple obfuscated possible success keys. The trading partner transaction may be generated to further include multiple obfuscated secret keys. The step of verifying the success transaction may include the step of combining the cryptographic key with the secret value to generate a possible success signing key. Additionally or alternatively, the step of verifying the success transaction may include the step of distributing digital assets to the trading partner, at least in part, based on which of the multiple obfuscated secret keys is associated with the possible success signing key.

[0025] Therefore, a method that is carried out by a computer, A step of communicating consent to a set of trading partners to determine the outcome of a set of conditions, wherein the set of conditions includes a first possible outcome and a second possible outcome. A step of generating a first secret key share corresponding to a first possible outcome and a second secret key share corresponding to a second possible outcome using a secret sharing scheme, The steps include transferring the amount of digital assets to the address associated with the first blockchain transaction, As a result of determining that the outcome is a first possible outcome, a step is to disclose a first private key share within a specific time frame, wherein the first private key share is at least partially usable by a set of trading partners to determine the outcome. A step of generating a signature that is at least partially usable for a second blockchain transaction to use the amount of digital assets associated with a first blockchain transaction, based at least partially on a first private key share, To gain control over the quantity of digital assets, it is desirable to provide a method that includes the step of having a second blockchain transaction validated at a node in the blockchain network.

[0026] Furthermore, a method performed by computer, A step of communicating consent to a set of trading partners to determine the outcome of a set of conditions, wherein the set of conditions includes a first possible outcome and a second possible outcome. A step of generating a first secret key share corresponding to a first possible outcome and a second secret key share corresponding to a second possible outcome using a secret sharing scheme, The steps include transferring the amount of digital assets to the address associated with the first blockchain transaction, As a result of determining that the outcome is a first possible outcome, a step is to disclose a first private key share within a specific time frame, wherein the first private key share is at least partially usable by a set of trading partners to determine the outcome. A step of generating a signature that is at least partially usable for a second blockchain transaction to unlock an amount of digital assets associated with a first blockchain transaction, based at least partially on a first private key share, It is desirable to provide a method that includes the step of having a second blockchain transaction verified by a node in the blockchain network.

[0027] A first public key associated with a first possible outcome, and a second public key associated with a second possible outcome, may be generated. Additionally or alternatively, the first and second public keys may be provided to a set of trading partners. Additionally or alternatively, a first private key share may be used to determine outcomes by generating the first private key using the first private key share, at least in part. Additionally or alternatively, a first private key share may be used to determine outcomes by determining that the first private key is associated with the first public key.

[0028] A secret sharing protocol can be a secret sharing protocol that does not require a dealer.

[0029] The step of disclosing the first private key share may include the step of disclosing the first private key share within the third blockchain transaction.

[0030] The third blockchain transaction may be a transaction within a proof-of-stake blockchain.

[0031] The specified time frame may be the second time frame. Additionally or alternatively, the step of disclosing the first private key share may further include the step of committing the cryptographic hash of the first private key share in a commit transaction within the first time frame prior to the second time frame. Additionally or alternatively, the step of verifying the third blockchain transaction may include the step of determining that the first private key share in the third blockchain transaction corresponds to the cryptographic hash in the commit transaction.

[0032] The first blockchain transaction may further include a second quantity of the second digital asset transferred from a subset of the set of trading partners. Additionally or alternatively, control of the second quantity of the second digital asset may further be transferred as a result of a step that validates the second blockchain transaction.

[0033] The first blockchain transaction may further include an expiration condition. Additionally or alternatively, the step of verifying the second blockchain transaction as a result of the expiration condition being met may transfer control of the second quantity of the second digital asset to a subset of the set of trading partners.

[0034] Verification of a second blockchain transaction may include a step of verifying a digital signature generated using a group encryption key, which is associated with a group of trading partners who have agreed to determine the outcome.

[0035] The group of trading partners may include a first subset of trading partners that disclose key shares corresponding to a first possible outcome. Additionally or alternatively, the group of trading partners may include a second subset of trading partners that disclose key shares corresponding to a second possible outcome. Additionally or alternatively, the step of transferring control of a second quantity may include the step of transferring control of the second quantity to the first subset of trading partners, excluding the second subset of trading partners.

[0036] A group public key may be generated associated with a group of trading partners. Alternatively, the group public key may be provided to a set of trading partners. Alternatively, the first blockchain transaction may be generated, at least partially, using the group public key. Alternatively, the verification of the second blockchain transaction may include a step of determining that the group cryptographic key is associated with the group public key of the first blockchain transaction.

[0037] The group secret key share may be generated using a secret sharing protocol. Additionally or alternatively, as a further determined outcome, the group cryptographic key may be generated based at least partially on the group secret key share.

[0038] The first private key share may belong to a group of first private key shares distributed among the group of trading partners. Additionally or alternatively, the first private key share may correspond to a first possible outcome. Additionally or alternatively, the step of determining that an outcome is a first possible outcome may include the step of determining that a threshold number of the group of first private key shares has been disclosed by the group of trading partners.

[0039] Furthermore, it is a system, Processor and A memory containing executable instructions that cause the system to perform the method described in any of the claims as a result of execution by the processor, It is desirable to provide a system that includes this.

[0040] Furthermore, it is desirable to provide a non-temporary computer-readable storage medium that stores executable instructions, and which causes a computer system to execute the method described in any of the claims as a result of execution by one or more processors of a computer system.

[0041] The present invention may be described as a verification method / system and / or a control method / system for controlling the exchange or transfer of digital assets via a blockchain. In some embodiments, the digital asset is part of a token or cryptocurrency. As described below, the present invention may also be described as a secure method / system for a new, improved, and advantageous way of performing operations via a blockchain network or platform. [Brief explanation of the drawing]

[0042] The above-described and other aspects of the present invention are evident from and taught by reference to the embodiments described herein. Embodiments of the present invention are described below, merely by example, with reference to the following appended drawings. [Figure 1] This demonstrates a blockchain environment in which various implementations can be carried out. [Figure 2] An example of a smart contract according to one embodiment is shown. [Figure 3] An example of setting up a smart contract according to one embodiment is shown. [Figure 4] This document presents an example of coordinating outcome decisions according to one embodiment. [Figure 5] An example of smart contract execution according to one embodiment is shown. [Figure 6] This flowchart shows an example of generating smart contracts and cooperative algorithmic transactions according to one embodiment. [Figure 7] This flowchart illustrates an example of executing a smart contract according to one embodiment. [Figure 8] This document describes a computing environment in which various embodiments can be implemented. [Modes for carrying out the invention]

[0043] Referring to Figure 1, Figure 1 shows an exemplary blockchain network 100 associated with a blockchain according to one embodiment of the present disclosure. In this embodiment, the exemplary blockchain network 100 includes blockchain nodes. The blockchain nodes are implemented as peer-to-peer distributed electronic devices, each running an instance of software and / or hardware that performs an operation that conforms to the blockchain protocol, i.e., at least partially agreed upon among the operators of the node 102. In some examples, “node” represents a distributed peer-to-peer electronic device within the blockchain network. An example of a blockchain protocol is the Bitcoin protocol.

[0044] In some embodiments, node 102 can consist of any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, laptop computer, tablet computer, smartphone, etc.), multiple computing devices in a distributed system of a computing resource service provider, or any suitable client device such as computing device 800 in Figure 8). In some embodiments, node 102 has an input for receiving data messages or objects representing proposed transactions, such as transaction 104. In some embodiments, the node can be queried for information it maintains, such as information about the status of transaction 104.

[0045] As shown in Figure 1, some of the nodes 102 are connected in a communicative manner to one or more other nodes 102. Such communicative connections may include one or more wired or wireless connections. In this embodiment, each node 102 maintains at least a portion of the “ledger” of all transactions in the blockchain. In this method, the ledger is a distributed ledger. Transactions processed by nodes that affect the ledger are verifiable by one or more other nodes, thereby maintaining the integrity of the ledger.

[0046] Regarding which nodes 102 can communicate with other nodes, it is sufficient that each node in the exemplary blockchain network 100 can communicate with one or more other nodes 102. As a result, messages to be passed between nodes can propagate through the exemplary blockchain network 100 (or any meaningful part thereof) when the blockchain protocol indicates that a message should be forwarded. One such message may be the issuance of a transaction proposed by one of the nodes 102, for example, node 102A. This transaction may then propagate along a path such as path 106. Another such message may be the issuance of a new block proposed to be included in the blockchain.

[0047] In one embodiment, at least some of the nodes are mining nodes that perform complex calculations, such as solving a cryptographic problem. The mining nodes that solve the cryptographic problem generate a new block in the blockchain and broadcast the new block to other nodes 102. The other nodes 102 verify the work of the mining nodes and, upon verification, accept the block into the blockchain (for example, by adding the block to the blockchain's distributed ledger). In some examples, a block is a group of transactions and may be marked with a timestamp and a "fingerprint" (e.g., a hash) of the previous block. In this way, each block becomes linked to the previous block, thereby creating a "chain" that links blocks in the blockchain. In the embodiment, valid blocks are added to the blockchain by consensus of nodes 102. Also in some examples, the blockchain contains a list of verified blocks.

[0048] In one embodiment, at least some of the nodes 102 operate as verification nodes that verify transactions as described in this disclosure. In some examples, a transaction includes data that provides proof of ownership of a digital asset (e.g., a quantity of Bitcoin) and conditions for accepting or transferring ownership / control of the digital asset. In some examples, an “unlock transaction” represents a blockchain transaction that reassociates at least a portion of the digital asset indicated by unused UTXOs of a previous transaction with an entity associated with a blockchain address (e.g., transfers ownership or control). In some examples, a “previous transaction” represents a blockchain transaction that includes the UTXOs referenced by the unlock transaction. In some embodiments, a transaction includes a “lock script” that prevents the transaction by conditions that must be met before ownership / control becomes transferable (“unlocked”).

[0049] In some embodiments, a blockchain address is an alphanumeric string associated with an entity to which at least some control of a digital asset is transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between the public key associated with the entity and the blockchain address. In some embodiments, transaction verification includes the step of verifying one or more conditions specified in a lock script and / or unlock script. If the verification of transaction 104 is successful, the verification node adds transaction 104 to the blockchain and distributes it to node 102.

[0050] Examples of arithmetic codes referred to in this disclosure include the following: • OP_CHECKSIG. The public key and signature are popped from the stack and verified against the signature in the transaction field according to the SIGHASH type. If the signature is valid, 1 is returned; otherwise, 0 is returned. OP_DUP: Duplicates the top stack item. • OP_ELSE. These statements are executed if the preceding OP_IF, OP_NOTIF, or OP_ELSE is not executed; otherwise, these statements are not executed if the preceding OP_IF, OP_NOTIF, or OP_ELSE is executed. OP_ENDIF. Exits the if / else block. • OP_IF: If the top stack value is not False, the statement is executed and the top stack value is removed. • OP_CHECKMULTISIG. Compare the first signature with each public key until a match is found. Then, using the next public key, compare the second signature with each of the remaining public keys until a match is found. This process is repeated until all signatures have been checked. If the signature is valid, 1 is returned; otherwise, 0 is returned. • OP_CHECKLOCKTIMEVERIFY. If the top stack item is greater than transaction nLockTime, it terminates with an error; otherwise, script evaluation continues.

[0051] Figure 2 shows an exemplary embodiment 200 of the present invention. As shown in Figure 2, the exemplary embodiment 200 may include trading partners 202A-02N (C1-Cn) that generate a smart contract 206. The smart contract 206 distributes a digital asset amount 220 that depends on the agreement of the response 214 received from a group of members 204A-04M (p1-pm) recruited to objectively determine the response 214 in exchange for a distribution 222. In other words, in the embodiment, members 204A-04M jointly act as a decentralized, trustworthy oracle to provide answers to decision problems or function problems. In some examples, “oracle” represents an external agent that provides inputs on which an outcome can be determined, and oracle-related services include Oraclize, TownCrier, and Orisi services. In some embodiments, members 204A to 204M do not need to have knowledge of the identities of other members of the group, or knowledge of the answers provided by other members of the group. Keeping members anonymous to one another minimizes the possibility of collusion among members.

[0052] In some embodiments, the business partners 202A-02N may be two or more entities that have agreed to the terms of the smart contract. In various embodiments, one of the business partners 202 is an individual, a group of individuals, a legal entity, a computing device, or any other entity that can determine or agree to the terms of the smart contract 206. In one use case, the first business partner is a client and the second business partner is an insurer. In some embodiments, at least one of the business partners 202A-02N provides the other entities with a distribution 222 to make them interested in participating as members 204A-04M that determine the outcome of the smart contract 206. In some embodiments, at least one of the business partners 202A-02N determines how many members make up the group of members 204A-04M. In various embodiments, a member is a complete member, a minimum member, or a maximum member of the group. The more members there are in a group, the more reliable the agreement on the answer provided by the group should be.

[0053] In some embodiments, members 204A-04M are groups of entities that can determine the outcome of the conditions of the smart contract 206. In various embodiments, one of the members, like the trading partners 202A-02N, is an individual, a group of individuals, a legal entity, a software application, a computing device, or any other entity that can provide an answer that can be used to determine the outcome of the smart contract 206. As described above, in some embodiments, the members of members 204A-04M may be specified by the trading partners 202A-02N. For example, trading partners 202A-02N specify that there must be 15 members in the group.

[0054] In one embodiment, trading partners 202A-02N generate a smart contract 206 to refund any amount of the digital assets deposited by trading partners 202A-02N (negative transaction distribution) if sufficient members do not join the group (e.g., within a specified time range). As described above, in some embodiments, members 204A-04M may be given a reason to participate in determining the answer 214 by distribution 222 raised by trading partners 202A-02N. In some embodiments, members 204A-04M submit an answer that matches the agreement on the answer and receive distribution 222 or some percentage of distribution 222 (e.g., divided by the number of members). In some of the embodiments described above, members who submit a non-agreement answer (an answer that does not agree with the agreement answer) have their distribution 222 or a percentage of distribution 222 forfeited. In other embodiments, members who submit a non-agreement answer receive a smaller distribution or a smaller percentage of distribution 222 than members who submit an agreement answer.

[0055] In various examples, agreement can represent a simple majority of matching responses, an absolute majority of matching responses, a majority of matching responses submitted before reaching a threshold (e.g., the first three matching responses are considered agreement responses), or a threshold number of matching responses. In some embodiments, business partners 202A-02N determine a threshold for determining agreement. In one example, business partners 202A-02N decide that at least 60% of members 204A-04M must submit matching responses in order to reach agreement.

[0056] Furthermore, in some embodiments, each member commits a deposit (e.g., some amount of digital assets). This deposit gives members 204A-04M an additional reason to submit a response. In other words, in the embodiments described above, a member who agrees to participate but breaks the harmony will lose their committed deposit. In some embodiments, even if a member submits a non-agreeable response, the member will still have their deposit refunded and will not lose any digital assets by participating. When determining the amount of the required deposit, trading partners 202A-02N balance the deposit so that it is not so large that members 204A-04M do not want to participate at all, but large enough to give members 204A-04M a reason to immediately provide a precise response in order to have their deposit refunded.

[0057] In some embodiments, the smart contract 206 is a set of computer-executable instructions (e.g., arithmetic code) designed to automatically transfer control of a digital asset in accordance with conditions agreed upon by trading partners 202A-02N. In some embodiments, the smart contract 206 is encoded within a blockchain transaction (e.g., computer-executable instructions written in a scripting language) and is invoked by the verification of the blockchain transaction by a verification node of the blockchain network. In embodiments, the digital asset associated with the blockchain transaction is redeemable (e.g., obtained) upon the satisfaction of conditions specified in the smart contract 206. In embodiments, the smart contract 206 is contained in a lock script for the verified transaction in the distributed ledger of the blockchain network. In this method, the executable instructions are immutable, and the successful execution of the lock script containing the smart contract 206 is a prerequisite for the transfer of the digital asset of the verified transaction.

[0058] Furthermore, as described above, in the embodiments, the smart contract 206 includes a set of conditions, and unlocking the UTXO of the verified transaction depends on the satisfaction of the set of conditions. In one example, the smart contract 206 is an insurance contract that distributes digital assets to the insured in accordance with the insurance contract, provided as input to the lock script of the blockchain transaction that the insured has suffered a loss covered by the insurance contract. Furthermore, in some embodiments, the smart contract 206 is associated with multiple possible outcomes, and the successful outcome of the execution of verification involving the smart contract 206 may differ depending on the particular outcome. In the example above, the smart contract 206 has at least two possible outcomes: a first possible outcome and a second possible outcome. The first possible outcome is that the insured suffers a covered loss and receives payment in accordance with the insurance contract. The second possible outcome is that the insured does not suffer a loss, and the insurer retains the digital assets and the insured's premium payments. In this embodiment, the execution of a computer-executable instruction within the smart contract 206 causes the smart contract 206 to transfer a digital asset according to one of the possible outcomes, given that data proving a specific outcome is provided as input to the lock script.

[0059] In some embodiments, response 214 is a response that corresponds to one or more of the default conditions specified in the smart contract 206. For example, the smart contract may include several conditions that affect the amount of digital asset 220 to be paid and to which entity the digital asset 220 is paid. Members 204A-04M submit responses 214 that can be used to determine which of the multiple conditions (if any) are satisfied. In some embodiments, responses 214 are submitted in the form of cryptographic keys or digital signatures. In this way, the conditions to be satisfied can be determined by determining which conditions in the smart contract 206 correspond to the submitted cryptographic keys or digital signatures by agreement of members 204A-04M.

[0060] In some embodiments, the digital asset 220 is the amount of digital assets paid according to specific conditions of the satisfied smart contract 206. That is, the amount of digital assets may vary depending on which specific conditions are satisfied. For example, if the first condition is satisfied, 10 units of digital assets may be paid to a particular entity. On the other hand, if the second condition is satisfied, 2 units of digital assets may be paid to the same or a different entity.

[0061] As described above, in some embodiments, the distribution 222 is the amount of digital assets provided as a distribution to members 204A-4M by one or more of the trading partners 202A-02N to agree to participate in providing the response 214. In some embodiments, the distribution 222 is provided by a third party.

[0062] This disclosure assumes that all participants can prove they trust each other and communicate with each other through a secure communication channel. In one embodiment, secure communication can be achieved using a public-key cryptosystem or the Diffie-Hellman key exchange protocol. In one embodiment, each participant in this scheme is required to generate a secret value (private key) derived from a cryptographically secure pseudorandom number generator (CSPRNG) with at least a certain level of entropy. In one embodiment, these values ​​are 256-bit numbers to maintain compatibility with the Bitcoin protocol.

[0063] In one embodiment, certain functions are implemented through elliptic curve operations. In one embodiment, elliptic curve (EC) operations are performed using parameters defined by the Secp256k1 curve, which is currently used in the Bitcoin protocol to perform public key generation, signature generation, and signature verification. In addition to the curve parameters, the Secp256k1 standard specifies the generator point G and its order p. Unless otherwise specified, in embodiments, operations in the algorithms described in this disclosure are performed modulo p. It should also be noted that while certain embodiments of this disclosure are presented in relation to the Bitcoin blockchain, the concepts are applicable to any cryptocurrency blockchain that utilizes elliptic curve signature schemes.

[0064] In one embodiment, two distinct groups of participants are involved: counterparties (Ci) to the main contract, and members (Pi) who contribute to a collaborative algorithm such as a Schelling adjustment game. For example, a Schelling adjustment game is an adjustment game in which two or more individuals are likely to arrive at the same solution (also called a "focal point" or "Schelling point") without communicating with each other. In this method, members act as a decentralized group oracle, providing precise inputs to determine the outcome of the main contract. In this embodiment, counterparties 202A-02N have funds under the control of the contract and jointly provide distributions 222 to members in separate blockchain transactions. However, it should be noted that since the collaborative algorithm provides distributions to members to submit the same answer submitted by a threshold number of members, the answer is not necessarily correct and may reflect the answer that individual members think other members will submit.

[0065] In this embodiment, members commit a refundable security deposit in a separate blockchain transaction after submitting their response, and may receive a share or a portion of a share if their response matches the agreed response. If their response does not match the agreed response, members may get their deposit back, but may not receive share 222 or a portion of share 222, or may receive a smaller portion than the member who submitted the agreed response.

[0066] <Contract Settings> In one embodiment, the main contract (also called the "customer contract") can be implemented as a linked cooperative algorithm (e.g., a Schelling cooperative game) in the following manner: n customers 202A~02N (C1, C2, ..., Cn) agree on the terms and conditions of the contract, including the associated funds. At this stage, the agreement does not need to be formal, and the funds do not need to be committed until the transaction is signed. The general structure of the contract at this stage is shown in Table 1 below.

[0067] [Table 1] [Table 1]

[0068] In one embodiment, when the first condition is met, trading partners 202A-02N receive the amount X of the specified digital asset (DA) in the result. In one embodiment, the conditions (outcomes) must be clearly specified and mutually exclusive. Furthermore, in one embodiment, for each condition i, the sum of the amounts X i j (j=1,...,n) is equal to the funds to be paid to the contract (minus any transaction mining amount). Furthermore, in some embodiments, expiration conditions are specified to specify what should happen to the funds if the protocol stops after the expiration period. In one embodiment, each trading partner C j PKC is a public keyj It has.

[0069] Figure 3 shows an exemplary embodiment 300 of the present disclosure. Specifically, Figure 3 shows a high-level schematic diagram of the public key setting process of an exemplary embodiment 300 of the present disclosure. The exemplary embodiment 300 includes a trading partner 302 that issues a request 308 to a number of members 304 to agree to a contract 306 and provide a deal for the terms within the contract. As can be seen from the figure, the request 308 includes the definition of the contract terms (Def), the distribution to be provided (F), the number of members requested (N), the amount of security deposit requested per member (D), the threshold requested (M), the ghost chain block interval (ΔT), and the commit block height (h B ), and related information such as the identity of the trading partner and the distribution of digital assets controlled by smart contract transaction 330 do not need to be present in / provided in request 308 so as not to affect the voting of group members.

[0070] In exemplary embodiment 300, the trading partners also generate a contract public key 316. In the embodiment, trading partners can communicate with each other (e.g., by email and / or other electronic communications), and at least one of the trading partners 302 can communicate with member 304 through, for example, a portal, an online marketplace, a weblog, peer-to-peer communication, or some other communication forum. In one embodiment, after communicating an agreement that a sufficient number of members (at least the number specified by trading partners 302 in the request 308) are part of the group, member 304 agrees to generate a group public key 312 and a shared public key 314. In exemplary embodiment 309, member 304 generates the group public key 312 and the shared public key 314 using a dealer-free secret sharing scheme. In exemplary embodiment 300, the value of the contract public key 316 provided by trading partner 302 is combined with a separate public key 314 to generate a contract conditions public key 318.

[0071] In exemplary embodiment 300, the trading partner transaction 330 distributes to one or more trading partners 302 according to the outcome determined based on an appropriate digital signature corresponding to one of the contract condition public keys 318. Similarly, in exemplary embodiment 300, the cooperative algorithm transaction 332 transfers the distribution and deposit to member 304 once the outcome of the winner has been determined (by the cooperative algorithm).

[0072] The following is an exemplary use case of the contract setting described above. In this exemplary use case, an insurance contract is generated between two parties 302, namely the client (C1) and the insurer (C2). In this example, the client wants to insure his vineyard against the possibility of severe frost at any time during April 2018. In this example, severe frost is explicitly defined as "any consecutive period of at least 4 hours during the month of April 2018, during which the temperature in the Surrey region remains below -4°C." In this example, the insurer agrees to a policy of paying 10 DA in the event of severe frost in exchange for a premium of 3 DA from the client. Thus, the insurer commits 10 DA to the contract and the client commits 2 DA to the contract. Thus, the contract is as shown in Table 2 below and controls 12 DA (insurer's deposit and premium).

[0073] [Table 2] [Table 2]

[0074] Therefore, under the condition that a severe frost occurs, the client receives 10 DA and the insurer receives 2 DA. On the other hand, under the condition that a severe frost does not occur, the client receives no funds, while the insurer recovers the original 10 DA plus the 2 DA premium, for a total of 12 DA. If neither condition is clearly demonstrated and a deadline condition arises, the client is refunded the 2 DA premium, and the insurer is similarly refunded the 10 DA payment. Note that if there is no ambiguity regarding the event, the deadline condition must be redundant. The deadline exists to prevent the loss of funds if the protocol cannot provide a decision, and in this example, it simply issues refunds to each party. Also note that in embodiments, the trading partners agree on the distribution for the execution of the contract, who will pay this distribution, and that the amount chosen for distribution may depend on the nature of the required security and conditions.

[0075] In this embodiment, one of the trading partners (or a third party / service acting on their behalf) submits a request to an open market (or public forum). The request includes the definition of the contract terms (Def), the distribution to be provided (F), the number of members requested (N), the amount of security deposit required per member (D), the required threshold (M), the ghost chain block interval (ΔT), and the commit block height (h). B Specify the following. In this embodiment, the ghost chain block interval represents how often a block is committed to the ghost chain blockchain. Also in this embodiment, the commit block height represents the number of blocks in the ghost chain.

[0076] Therefore, in the exemplary use case described above, the insurer offers a distribution of 0.2 DA and requires a group of 10 members to submit one of the following two outcomes: 1. Outcome #1: "Somewhere in the county of Surrey, UK, during the month of April 2018, temperatures will remain below -4°C for at least four consecutive hours." 2. Outcome #2: "Any other outcome excluding condition 1"

[0077] In an exemplary use case, the insurer and the client agree on a threshold of 6; that is, an agreement by at least 6 of the 10 members states which of the above conditions has been met. In this example, each member is required to submit a deposit of 0.1 DA. As a result, available members can examine the definition of the outcome and decide whether they wish to participate based on their ability to evaluate the conditions (e.g., whether they have direct or indirect access to the necessary information (i.e., via news / the internet)), the potential profit (F), and the required deposit. Members communicate their acceptance to the business partner, including an authenticated UTXO with the deposit and a public address for communication.

[0078] A sufficient number (N) of members (P i Once the party communicates acceptance of the request, in one embodiment, the trading partner distributes their communication addresses to the group of members. In an embodiment, the members and trading partner can then establish a secure peer-to-peer communication channel with each other. In an embodiment, the group of members executes a dealer-free secret sharing protocol with threshold M to determine the contract conditions / progress (IPK). i A group public key (GPK) and an individual public key (and associated individual key share) are generated for each of the ). These public keys are then sent to the trading partner.

[0079] In an embodiment, the members use a method of sharing a secret key. As a result, each member has a share of the (as yet unknown) secret key. The secret key itself can be calculated from a threshold number of shares (where the threshold is less than or equal to the number of members). Thus, the secret key is not known to any single party, but the group of members can determine an elliptic public key corresponding to the as yet unknown secret key by secure multi-party computation. In this method, the blockchain output can be placed under the control of a shared group key in a trustless manner, and the secret key can be determined (or a signature generated) through the cooperation of a threshold number of members.

[0080] In some embodiments, Shamir’s Secret Sharing scheme (SSSS) is used for this purpose. SSSS is based on the concept that a polynomial of degree t can fit any set of t + 1 (threshold) points. A polynomial f(x) of degree t is formed with the shared key (a0 = f(0)) as the constant term, and the remaining coefficients are randomly chosen. A number of points on the curve equal to the number of members in the group are given to each member. If the number of members joining the points is (t + 1) or more, there is sufficient information to fit a polynomial of degree t to these points, and a0 is disclosed as the secret. In an embodiment, this scheme enables the sharing of a single secret key among any number of members with any threshold.

[0081] Standard SSSS can be extended to remove the requirement for a trusted dealer to generate the polynomial and distribute the secret shares. This removes the dependence on a trusted dealer. In this dealerless SSSS, each member (P i ) generates their own random polynomial f i (x) of degree t, and then securely sends f i (x) to each other participant P i . Each P i then adds up all the received points to obtain the point on the shared polynomial f(x) for P iThe point is their secret share i We obtain =f(i).

[0082] After the secret share is generated, the public key (A) corresponding to the shared secret key (which none of the members yet know) is calculated by the elliptic curve generator G as follows: Participant P i i=1,...,t, their public key share is b i s i We calculate this using ×G, and here we get the following:

number

[0083] These public key shares are then broadcast to all members, and the shared public key A is then simply calculated as the sum of t+1 shares.

number

[0084] It should be noted that the mathematical properties of elliptic curve cryptography (ECC) are utilized in this disclosure. An ECC operation can be defined by a source point G of degree p. Once a random secret key (a) is selected (between 1 and p), the public key (A) can be derived by the following point multiplication. A = a × G

[0085] Furthermore, due to the fundamental properties of point multiplication, the following applies: (a+r)×G=a×G+r×G Here, r is a nonce. In embodiments, this property can be used to utilize random blinding nonces for elliptic curve signatures. Furthermore, in this disclosure, the elliptic curve digital signature algorithm scheme is used in various embodiments to enable groups to jointly sign transactions using a threshold number of key shares without reconstructing the complete private key.

[0086] Continuing with the exemplary use case described above, a group of 10 members jointly executes the dealer-free SSSS protocol (with 6 thresholds agreed upon as described above) three times. The group of 10 members uses a Group Public Key (GPK) and two IQ Public Keys (IPKs). 1 and IPK 2 ) is generated. As a result, each member j then has three secret key shares (GPriv j IPriv j 1 IPriv j 2 ) is owned. The group public key further allows member 304 to determine the blockchain address to send their deposits to.

[0087] In one embodiment, the trading partner 302 then performs a random blind nonsense (R B ) agree. In one embodiment, the selected value is stored by all business partners but kept secret from the member group. In one embodiment, the business partner then R B We compute the corresponding elliptic curve public key for this. PKR=R B ×G The PKR value is then added to each of the contract's public keys. IPK i R =IPK i +PKR

[0088] Therefore, in this example, trading partner 302 calculates the contract condition public key 318 and IPK 1 R =IPK 1 +PKR and IPK 2 R =IPK 2 +PKR, and so on. In this method, the public key 314 is a random blind nonce (R BThe use of ) obfuscates the data. As a result, it becomes highly unlikely that an entity other than trading partner 302, such as member 304, could link any of the contract condition public keys 318 used in trading partner transaction 330 to a separate public key 314 generated by member 304. In this way, trading partner transaction 330 (and the amount it contains) remains anonymous, and decisions made by member 304 are isolated from the influence of knowledge of the details of the contract transaction (e.g., the amount of the digital asset in question).

[0089] In this example, two transactions are generated by agreement of trading partner 302: trading partner transaction 330 (TxC) and cooperative algorithm transaction 332 (TxS). In one embodiment, trading partner transaction 330 has contract funds from trading partner 302 as input. In another embodiment, trading partner transaction 330 has separate outputs for each amount payable to one or both of trading partners 302, depending on the outcome of the contract (e.g., each a unique value X). i j Therefore, each of these UTXOs is distributed to its respective trading partners, depending on the conditions and deadlines. It should also be noted that in some examples, the output may be configured to be paid to a third party that is not a member of trading partner 302. In some embodiments, the output constraint is implemented as a 2-of-2 multi-signature feature.

[0090] An example of the conditions in the exemplary use case, trading partner transaction 320, is shown in Table 3.

[0091] [Table 3] [Table 3]

[0092] An example script for use is shown in Table 4.

[0093] [Table 4] [Table 4]

[0094] In one embodiment, the cooperative algorithm transaction 332 has as input N UTXOs from each member deposit and UTXOs constituting the distribution from the trading partner. In some embodiments, there are two UTXOs, one of which can be unlocked by a signature from the group public key (GPK) containing the deposit, as described in relation to Figure 4, and the other can be unlocked by a signature from the GPK or by a signature from the trading partner after expiration.

[0095] In this embodiment, a threshold number of group members can jointly generate signatures corresponding to the group secret key (GPriv) without explicitly determining the GPriv. In this embodiment, the signatures are indistinguishable from signatures directly generated from the GPriv, but in practice, the threshold signature scheme is used to share the secret key (GPriv j ) can be generated directly from. In this method, GPriv does not need to be determined at any point, but the corresponding signature can be generated from a threshold number of private key shares (GPriv j ) can be determined from this.

[0096] In the above embodiment, a threshold number of group members agree to the transfer of the first UTXO (deposit) (and jointly generate a signature). In the above embodiment, the threshold number of group members can also jointly generate a signature to claim the distribution, but may generate an additional signature corresponding to one of the private keys. In such an embodiment, if the group members are unable to reconstruct one of the private keys by agreement, they cannot claim the distribution, and the distribution is returned to the trading partner after expiration.

[0097] In some embodiments, group members share a threshold number of their private keys (GPpriv jIt should be noted that it is possible to check whether a valid signature corresponding to the (GPK) can be generated at any time (for example, as part of a dealer-free secret sharing protocol) without reconstructing the complete private key. In such embodiments, a threshold number of group members can reclaim their deposit at any time, but will be forfeited if they did not play a role in generating the winning outcome key. An example of the inputs and outputs of the exemplary use case cooperative algorithm transaction 332 is shown in Table 5.

[0098] [Table 5] [Table 5]

[0099] In one embodiment, the cooperative algorithm transaction 332 is signed by the trading partner 302 providing the distribution and then sent to the member group to be signed by each of the members 304. In one embodiment, once each input is signed, the cooperative algorithm transaction is broadcast to the blockchain network. In some embodiments, any participant can stop the protocol (or fail to cooperate) until the cooperative algorithm transaction 332 is signed, and the funds are not placed at risk. In one embodiment, once the cooperative algorithm transaction 332 is confirmed on the blockchain, each trading partner then signs their respective input to trading partner transaction 330 and broadcasts it to the blockchain network. In one embodiment, once trading partner transaction 330 is confirmed on the blockchain, the trading partner contract may be activated.

[0100] <Execute the contract> In one embodiment, after the counterparty transaction 330 is approved, member 304 waits until after the time period specified in the conditions / clause in request 308 has expired. In one embodiment, member 304 then records their vote using a separate blockchain, such as a ghost chain. In some examples, the “ghost chain” represents a proof-of-stake blockchain mined by a group of members, where the member’s deposit is committed to a cooperative algorithm transaction via a group key (GPK). That is, unlike proof-of-work based blockchains (e.g., Bitcoin) where transactions are confirmed by mining nodes interested in the distribution given for performing work, in a ghost chain proof-of-stake blockchain, participants may be interested in recouping their deposits generated within the ghost chain (e.g., their “stake” of some amount of their own digital assets).

[0101] In contrast to traditional blockchains, a ghost chain can be configured to terminate, disappear, and / or expire upon the performance or fulfillment of one or more criteria, goals, or specified objectives. In other words, in some embodiments, a ghost chain is a single-purpose blockchain that is no longer used once its purpose has been achieved. In some embodiments, a ghost chain includes the first block (also called the "genesis block") generated when the ghost chain is deployed or generated for its purpose, criteria, or goals.

[0102] In some embodiments, the proof-of-stake consensus algorithm used by the ghost chain may have the characteristics of regular block times, timestamped blocks, and branching potential. In some embodiments, block distribution ("mining amount") is paid from distribution (F) at a predetermined rate. In some embodiments, mining distribution may be low due to the very small cost of confirming the block. In some embodiments, the cooperative algorithm can be performed entirely on the blockchain (i.e., instead of the ghost chain) by cooperative algorithm transactions, provided there is sufficient scripting capability and blockchain-aware single payment verification (SPV) proof. An example of such a blockchain platform is Ethereum.

[0103] In one embodiment, ghost chain blocks are generated at intervals of ΔT, specified in some examples within the request. In some embodiments, the value of ΔT is selected based on the desired resolution speed of the contact and the desired response time from member 304. In one embodiment, each member 304 reaches a decision on the outcome required by the trading partner contract. Using the exemplary use case described above, each member 304 makes a decision on whether or not a severe frost occurred during the month of April 2018. Allowing for the possibility that not all members 304 may reach the same decision (for example, some members may have false information or submit incorrect answers unintentionally or intentionally), only threshold number M members 304 need to reach the same decision for the decision to be accepted as a result.

[0104] Figure 4 shows an exemplary embodiment 400 of the present disclosure. Specifically, Figure 4 shows a high-level schematic diagram of a smart contract configuration in one embodiment of the present disclosure. As can be seen from the figure, Figure 4 includes transactions 438 that are committed intermittently to a ghost chain 434. In some embodiments, the ghost chain 434 may be a temporary proof-of-stake sidechain generated to record votes in a cooperative algorithm. In some embodiments, transaction 438 is a blockchain transaction embedded in a block of the ghost chain 434. In some embodiments, each consecutive block includes a hash 436 which is a cryptographic hash of the previous block in the ghost chain. The hash 436 links the blocks in the ghost chain 434.

[0105] In this embodiment, the commit mechanism allows members to pre-commit specific values ​​while keeping them hidden from others. Once committed, the values ​​may be disclosed at a later stage. In this method, group members cannot change the values ​​after they commit them, but the values ​​are not disclosed to other members, and this method can be used as a secure voting protocol.

[0106] Typically, a commit scheme can occur in two stages: a commit stage where a value is selected and committed by a member, and a disclosure stage where a value is disclosed by a member and confirmed to match the commit. A secure commit scheme may rely on a random blind nonce to prevent any information about the committed value from being disclosed after the commit stage. However, in this disclosure, the committed value may already be a randomly generated key. Therefore, the commit protocol can be reduced to simply using a secure hash function.

[0107] Therefore, in the anonymous voting protocol disclosed here, at the commit stage, each member hashes the value they wish to commit (for example, using SHA256) and discloses the hash to the group. At the disclosure stage, each member then discloses a pre-image of the hash (the committed value) to the group, and the group verifies each hash. In this way, the group can commit to voting without knowing in advance how many of the rest of the group have voted.

[0108] Therefore, in one embodiment, the block height (h) specified in the request B ) and each member (for example, member 304 in Figure 3) has a private key share of the public key of the conditions / clause corresponding to the contract outcome they have individually determined (private key share of member j for the i-th condition IPriv i j ) submits commit 424. In one embodiment, each member signs their respective commit 424, and the commits are embedded in the ghost chain. In an embodiment, each commit may be a simple hash (e.g., Secure Hash Algorithm, SHA256) of each member's private key share corresponding to the decided result. By hashing the private key share, the votes of the writing members are kept secret until the disclosure stage described later. In this method, the risk of one member's vote influencing another member's vote is minimized.

[0109] In one embodiment, each member then commits their key share 426(IPriv i j ) submit. Next, this key share is the next block (h BIt is embedded in +1). In some embodiments, the key share 426 held by each group member is a share of the complete secret key, determined according to the secret sharing scheme as described above. In such a secret sharing scheme, obtaining at least a threshold number of key shares 426 allows the complete secret key 428 to be arithmetically determined. In one embodiment, when this block is validated, if a threshold number M members have submitted key shares corresponding to one particular outcome, the winning outcome public key (IPK) w ) The winner's complete private key 428 (IPriv w )(for example, one of the separate public keys 314 in Figure 3) can be easily determined and publicly disclosed (where w is the winner's outcome index). In some embodiments, the winner's complete private key 428 is a cryptographic key that is the relative of the winner's public key (for example, one of the separate public keys 314) that is sent to the trading partner and encoded within the smart contract transaction.

[0110] In an exemplary embodiment, the commit height (h B Block x-1 is where the committed key share 426 (member j's share of the random private key) is disclosed in block x. After disclosure, the threshold number of winner's private key shares allows for the determination of the winner's complete private key 428.

[0111] Figure 5 shows an exemplary embodiment 500 of the present disclosure. Specifically, Figure 5 shows a high-level schematic diagram of the execution of the smart contract set up in Figure 3 after the outcome has been determined for Figure 4. The exemplary embodiment 500 includes a trading partner 502 that collects an amount of digital asset 520 in accordance with the outcome associated with the winner's full private key 528 by signing an outcome transaction 530B that unlocks a trading partner transaction 530A. The exemplary embodiment 500 further includes a group member 504 that collects the distribution and deposit via output 522 by signing a distribution transaction 532B that unlocks a cooperative algorithm transaction 532A as a distribution to provide the trading partner 502 with the winner's full private key 528.

[0112] In some embodiments, trading partner 502 is similar to trading partner 202 in Figure 2. In some embodiments, member 504 is similar to member 204 in Figure 2. In some embodiments, signature 518A is a joint digital signature of member 504 for each member 504 to receive their distribution and deposit. In some embodiments, signature 518B is a digital signature of trading partner, which is generated using a complete random signature key 526 formed by combining the winner's complete private key 528 and a random blind nonce 516.

[0113] In some embodiments, the winner's complete private key 528 is similar to the winner's complete private key 428 in Figure 4. In some embodiments, the random blind nonce 516 is the same as the nonce generated in 612 in Figure 6 to obfuscate the contract conditions public key. In some embodiments, the complete stale signing key 526 is the winner's complete private key 428 combined with the random blind nonce 516 using elliptic curve operations. As a result, the outcome of the smart contract can be determined by matching the complete stale signing key 526 with the counterparty contract conditions public key in the smart contract, in the lock script of counterparty transaction 530A.

[0114] In some embodiments, the digital asset 520 is a distribution of pre-locked digital assets within a counterparty transaction 530, following the outcome of the smart contract winner, upon verification of signature 518B. In some embodiments, output 522 reflects pre-locked digital assets within at least one cooperative algorithm transaction payable to member 504, upon verification of signature 518B. In some embodiments, counterparty transaction 530A is a blockchain transaction similar to counterparty transaction 330 in Figure 3, containing a smart contract such as smart contract 206 in Figure 2. In some embodiments, outcome transaction 530B is a blockchain transaction created to redeem / claim the appropriate digital assets in counterparty transaction 530A, following the outcome determined by the smart contract.

[0115] In some embodiments, cooperative algorithm transaction 532A is a blockchain transaction similar to cooperative algorithm transaction 332 in Figure 3, including the distribution and the deposit 522 of member 504. In some embodiments, distribution transaction 532B is a blockchain transaction generated by member 504 to claim their deposit and distribution. As a result of determining the winner's complete private key 428, it is possible to determine which members commit the winner's private key share. In one embodiment, the ghost chain consensus algorithm identifies the "winning" member (i.e., the member who voted for consensus), and distribution transaction 532B(TxF) is generated by the group or by a member of the group to pay the winning member a distribution signed using a GPK by a threshold number (m) of members (e.g., by a threshold signing scheme). In an embodiment, the members embedded the winner's complete private key 428 in the metadata of distribution transaction 532B.

[0116] In some embodiments, member deposits are also repaid as a result of verifying distribution transaction 532B. In some embodiments, member 504's deposit is committed to a different transaction from cooperative algorithm transaction 532. In some of the embodiments described above, refund transactions (TxD) are generated by the group for the group, or by members of the group to refund each member's deposit. In some embodiments, a member who violates a particular ghost chain consensus rule has their deposit distributed among the other members. In embodiments, distribution and refund transactions are then broadcast to the blockchain network.

[0117] Using the above use case as an example, where the client and the insurer agree on an insurance contract in which the insurer underwrites the client's insurance against the possibility of severe frost in the client's vineyard at any time during April 2018, the member group instantiates the ghost chain on the first day of May 2018, with a block generation time of ΔT = 1 day. In the use case, h B The time is set to 5, and as a result, on May 5th, members (e.g., member 304 in Figure 3) submit their signed commitments (e.g., commitment 424) on May 5th. Following ΔT, on May 6th, each member submits a key share (e.g., 426) to disclose their commitment.

[0118] In an example usage, 9 out of 10 members 504 are IPK 1 They committed to their share, and one of the 504 members, IPK 2 They committed their share of the issue (for example, the dissenting member's source of information was incorrect). In this example, the member group was IPriv 1It is determined that the threshold number (6) of commitments can be reconstructed, and then it is possible to identify which members committed to the winner's share (9). In one embodiment, the threshold number of the member group (a subset of winners) can then generate transaction 532 which pays the distribution to the 9 winners and returns all member deposits (fees and deposits 522).

[0119] <Customer Group> In one embodiment, the winner's public key (IPK) w ) The winner's complete secret key 528 (for example, the winner's complete secret key 428 in Figure 4) (IPriv w ) is disclosed by the member group. In one embodiment, either customer 502 (e.g., customer 302 in Figure 3) or the “winner” customer adds a random blind nonce 516 to this value to obtain the complete random signing key 526. IPriv w R =IPriv w +R B

[0120] In this embodiment, this value can then be used by the “winning” trading partner 502 to generate signature 518B (and together with signatures from their own public keys) to claim the output 522 of trading partner transaction 530 (e.g., trading partner transaction 530 in Figure 3) corresponding to the winner’s outcome. In an exemplary use case, the trading partner can use the winner’s complete private key 528 (IPriv) generated by the cooperative algorithm by determining from the members’ agreement that the bad frost outcome objectively occurred. 1 ) to know. As a result, the insurance contract transfers the distribution. In an exemplary use case, each of the trading partners 502 (e.g., each of the trading partners 302) is random blind nonsense 516 (R B ) to IPriv 1 In addition, the complete 526-bit signature key (IPriv 1 RThe value is obtained. This value can then be used with each customer's private key to generate a signature 518B for transferring the corresponding output 522B of customer transaction 530.

number

[0121] Figure 6 is a flowchart showing an example of a process 600 that generates smart contracts and cooperative algorithm transactions according to various embodiments. All or part of process 600 (or any other processes described, or variations and / or combinations thereof) can be executed under the control of one or more computer systems consisting of executable instructions and / or other data, and may be implemented as executable instructions executed jointly on one or more processors. The executable instructions and / or other data may be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash medium).

[0122] For example, part or all of process 600 can be executed by one or more computing devices (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable client device such as computing device 800 in Figure 8). Process 600 includes a series of operations in which two or more trading partners agree on the requirements of a smart contract and the parameters of a cooperative algorithm transaction, work with a group of members to determine the outcome of the smart contract, and generate the smart contract and the cooperative algorithm transaction.

[0123] In some embodiments, in 602, two or more trading partners, such as trading partner 202 in Figure 2, determine the parameters of the smart contract. For example, trading partners may agree on the amount of digital assets (e.g., Bitcoin) each trading partner will commit to the smart contract transaction, the set of conditions, and the amount of digital assets to be paid and to whom they will pay when each condition is met. In a more specific example, an agreement is reached between three trading partners (Alice, Bob, Carol). Here, Alice commits amount X1 of digital assets to the smart contract transaction, Bob commits amount X2, and Carol commits amount X3.

[0124] In this example, the agreed-upon set of conditions is as follows: If the first condition is met, Alice will receive 60% of the committed digital assets of the smart contract, Bob will receive 30%, and Carol will receive 10%. Alternatively, if the second condition is met, Bob and Carol will each receive 50% of the committed digital assets (Alice will receive nothing). Further alternatively, if the third condition is met, Alice's husband, Ted (who has not committed any digital assets to the smart contract), will inherit 100% of the smart contract's digital assets. As a fourth condition, if the first, second, and third conditions are not met within the specified timeframe, Bob, Carol, and Alice may be refunded their committed digital assets.

[0125] In some embodiments, under 604, the trading partner determines the characteristics of the members acting as a group oracle in order to determine which conditions have been met. Specifically, the trading partner agrees on how many digital assets should be provided as a distribution to give members a reason to agree to participate in determining the outcome, the number of members required for the group, how much each member must commit as a security deposit, and the threshold number of matching votes required to qualify as a consensus. In one example, Bob, Carol, and Alice agree to provide 10 units of digital assets to each of up to 10 members of the group who agree to a particular outcome of the smart contract, and that at least 6 responses from the group must match in order to be considered a consensus response. In this example, Bob, Carol, and Alice require each member of the group to commit 0.1 units of digital assets in return.

[0126] In some embodiments, 606, the trading partner determines the timing parameters of the cooperative algorithm transaction, such as the block height and block interval of the ghost chain in which group members commit their responses. For example, the block height (e.g., the number of blocks that should exist in the blockchain) is specified as 5, and the block interval is specified as 1 day, starting at a specific time. This gives group members 5 days (1 day x 5) after the start time to submit their decisions. In the 5th block, the group members submit their signed commitments, and the following day they disclose their commitments.

[0127] In some embodiments, at 608, the trading partner submits a request to group members, similar to request 308 in Figure 3. That is, the request defines the contract terms, the distribution to be provided, the number of members requested, the amount of security deposit required per member, the required threshold for matching votes for the agreement response, the ghost chain block interval and commitment block height (h B), which may include information such as: As stated above, requests may be submitted / filled in any forum or communication medium suitable for submitting / filling such requests, such as a website forum, bulletin board, peer-to-peer application, or online marketplace.

[0128] In some embodiments, in 610, the group members communicate their agreement to the participants when determining the outcome of the smart contract. In some embodiments, the communication of agreement takes place through the same or similar forum where the request was submitted / filled out. In other embodiments, the communication of agreement is performed through direct communication to one or more of the trading partners (e.g., via a communication link in the request).

[0129] In some embodiments, after receiving notification in 612 that the group membership requirements have been met, the trading partner generates a random blind nonce that obfuscates the course of events in the smart contract transaction. The random blind nonce may be determined in various ways. For example, one trading partner may generate a random blind nonce, and the other party or multiple parties may communicate approval / approval to the one party. Alternatively, each party may generate a portion of the random blind nonce, and all of the generated portions may be combined according to a mathematical algorithm to form the random blind nonce.

[0130] In some embodiments, at 614, the trading partner generates / agrees on a smart contract public key similar to the contract public key 316 in Figure 3. In some embodiments, the public key corresponds to a random blind nonce (for example, the blind nonce is the private key and the public key is the elliptic curve public key for the blind nonce). In some embodiments, the contract public key is coupled with each of the random public keys generated by the members at 616. Note that at 616, the group members generate a group public key and a random public key for each of the contract outcomes. Note that the group public key and random keys may be generated using a dealer-free secret sharing protocol as described above. Each group member may have a private key share corresponding to the random public key. The private key shares may be generated using a secret sharing protocol as described in this disclosure, using a threshold of the number of matching votes specified by the trading partner at 604 in Figure 6 as the number of key shares required to regenerate the complete private key corresponding to the winner's random public key. In this embodiment, the group member provides the group public key and the random public key to the trading partner via the communication medium established in 608-12.

[0131] In some embodiments, at 618, at least one of the trading partners generates a contract condition public key by combining each of the event public keys generated by the member group at 616 with a random blind nonce generated at 612. In this way, the contract condition public key is hidden from the group members in the smart contract transaction generated at 620. In some embodiments, at 620, note that the smart contract transaction is generated and signed by the trading partners and committed to the blockchain along with the funds agreed upon by each trading partner (e.g., the amount of digital assets). The smart contract transaction may have separate UTXOs for each amount payable to one or both trading partners, depending on the outcome of the contract.

[0132] Finally, in some embodiments, in 622, the trading partner generates a cooperative algorithm transaction similar to the cooperative algorithm transaction 332 in Figure 3. In some embodiments, the cooperative algorithm transaction includes a deposit from the group members as a UTXO. The deposit may be paid by signature from the group public key generated by the member group in 616 after the group members have submitted their responses or after the deadline. In some embodiments, the cooperative algorithm transaction may include, as an addition or alternative, a distribution provided by the trading partner, which can be unlocked by signature using the group public key or by the trading partner's signature after the deadline. In some embodiments, the UTXO may be in the same cooperative algorithm transaction. On the other hand, in other embodiments, the UTXO may be in a separate transaction. Note that one or more of the operations performed in 602-22 can be performed in various orders and combinations, including concurrently.

[0133] Figure 7 is a flowchart showing an example of a process 700 that executes a smart contract according to various embodiments. All or part of process 700 (or any other processes described, or variations and / or combinations thereof) can be executed under the control of one or more computer systems consisting of executable instructions and / or other data, and may be implemented as executable instructions executed jointly on one or more processors. The executable instructions and / or other data may be stored in a non-temporary computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash medium).

[0134] For example, part or all of process 700 can be performed by one or more computing devices (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable client device such as computing device 800 in Figure 8). Process 700 includes a series of operations in which members commit and disclose their answer key shares, and if there are matching answers of a threshold number, a secret stalemate key associated with the agreed answer can be determined, from which a complete stalemate signing key can be computed.

[0135] In some embodiments, after the start time has begun, each group member makes a decision regarding the outcome of the smart contract within a specific time frame. The specific time frame may depend on the block height and block interval of the ghost chain, such as ghost chain 434 in Figure 4. In the example above, a block height of 5 and a block interval of 1 day give the group members 5 days to decide on their answer.

[0136] At the end of the time period, in some embodiments, at 702, each group member commits the key share corresponding to their own determined answer to a block in the ghost chain, shown as commit 424 in Figure 4. This is shown as commit 424 in Figure 4. As described above, each group member may submit their answer as a simple hash (e.g., SHA-256) of the group member's key share for a particular answer. Note that in some embodiments, not all group members necessarily have to submit their answers in the same block. For example, if a group member arrives at their answer on the third day of five days, that group member may submit their answer in the third block.

[0137] In some embodiments, at 704, in the next block in the ghost chain, members disclose their commitment. This is shown in disclosure 426 in Figure 4 and can be verified by comparing the hash of the disclosure with the hash of the previous commit. In some embodiments, at 706, it is determined whether there are enough key shares to constitute a private key corresponding to a valid spontaneous private key. If not, at 708, the trading partner may reclaim their funds and the members may have their deposits refunded. In such examples, in some embodiments, because an agreement has not been reached, members may not receive a distribution or may receive a smaller distribution.

[0138] Alternatively, in some embodiments, a winner's random private key is generated at 710. The member who submitted the winner's answer can jointly sign a transaction, such as distribution transaction 532B in Figure 5, generated at 712 to collect the distribution and refund the member deposit. The winner's random private key may be provided by the group to a trading partner. This trading partner may combine the winner's random private key with a random blind nonce at 714 to generate a complete random signing key (e.g., the complete random signing key 526 in Figure 5).

[0139] In some embodiments, in 716, each trading partner can sign a live transaction similar to live transaction 520B using a signature generated with their own private key and a signature generated with a complete live signing key, thereby claiming funds suitable for the live performance of a smart contract as agreed in 602 of Figure 6. Note that one or more of the actions performed in 702-16 can be performed in various orders and combinations, including concurrently.

[0140] In the context of describing embodiments of the disclosure, unless otherwise specified, the use of expressions relating to executable instructions (also called code, applications, agents, etc.) that perform actions that “instructions” would normally perform without assistance (e.g., sending data, performing calculations, etc.) indicates that the instructions are executed by a machine, thereby causing the machine to perform a particular action.

[0141] Figure 8 shows a simplified block diagram of a computing device 800 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 800 can be used to implement any of the illustrated systems described above. For example, the computing device 800 may be configured to be used as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 8, the computing device 800 may include one or more processors 802 configured and operably coupled to communicate with a number of peripheral subsystems via a bus subsystem 804 in some embodiments. In some embodiments, these peripheral subsystems include a storage subsystem 806 including a memory subsystem 808 and a file / disk storage subsystem 810, one or more user interface input devices 812, one or more user interface output devices 814, and a network interface subsystem 816. Such a storage subsystem 806 may be used for temporary or long-term storage of information.

[0142] In some embodiments, the bus subsystem 804 provides a mechanism that enables various components and subsystems of the computing device 800 to communicate with each other as intended. While the bus subsystem 804 is schematically shown as a single bus, alternative embodiments of the bus subsystem utilize multiple buses. In some embodiments, the network interface subsystem 816 provides an interface to other computing devices and networks. In some embodiments, the network interface subsystem 816 functions as an interface for receiving data from and transmitting data to other systems from the computing device 800. In some embodiments, the bus subsystem 804 is used to communicate data such as details, search terms, etc.

[0143] In some embodiments, the user interface input device 812 includes one or more user input devices such as a keyboard, integrated mouse, trackball, touchpad, or graphic tablet; a scanner, barcode scanner, touchscreen integrated into a display; a voice recognition system; an audio input device such as a microphone; and other types of input devices. Generally, the use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information into the computing device 800. In some embodiments, the user interface output device 814 includes a display subsystem, a printer, or a non-visual display such as an audio output device, etc. In some embodiments, the display subsystem includes a planar display such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) display, or projection, or other display device. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computing device 800. One or more user interface output devices 814 can be used, for example, to present a user interface and facilitate user interaction with an application that performs the processes and variations described herein, when such interaction is appropriate.

[0144] In some embodiments, the storage subsystem 806 provides a computer-readable storage medium for storing basic programming and data structures that provide functionality for at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), when executed by one or more processors, provide functionality for one or more embodiments of the present disclosure in some embodiments and are stored in the storage subsystem 806 in some embodiments. These application modules or instructions can be executed by one or more processors 802. In various embodiments, the storage subsystem 806 further provides a repository for storing data used in accordance with the present disclosure. In some embodiments, the storage subsystem 806 includes a memory subsystem 808 and a file / disk storage subsystem 810.

[0145] In some embodiments, the memory subsystem 808 includes a number of memories, such as a main random access memory (RAM) 818 for storing instructions and data during program execution, and / or a read-only memory (ROM) 820 on which fixed instructions can be stored. In some embodiments, the file / disk storage subsystem 810 provides non-temporary persistent (non-volatile) storage for program and data files and may include a hard disk drive, a floppy disk drive together with an associated removable medium, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable medium cartridge, or other similar storage medium.

[0146] In some embodiments, the computing device 800 has at least one local clock 824. In some embodiments, the local clock 824 represents a counter that indicates the number of hours ticked since a specific start date, and in some embodiments, it is located inside the computing device 800. In various embodiments, the local clock 824 is used to synchronize data transfers within the processor for the computing device 800 and its constituent subsystems with a specific clock pulse, and can be used to coordinate the synchronized operation between the computing device 800 and other systems in the data center. In another embodiment, the local clock is a programmable internal timer.

[0147] The computing device 800 may be any of various types, including a portable computer device, a tablet computer, a workstation, or any other device described later. Furthermore, in some embodiments, the computing device 800 may include another device that can be connected to the computing device 800 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). In embodiments, such a device includes a port configured to receive an optical fiber connector. Thus, in some embodiments, this device is configured to convert optical signals into electrical signals that are transmitted to the computing device 800 through a port to which the device is connected for processing. Due to the constantly changing characteristics of computers and networks, the description of the computing device 800 shown in Figure 8 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations are possible with more or fewer components than the system shown in Figure 8.

[0148] The specification and drawings should therefore be considered descriptive rather than restrictive. However, it is clear that various modifications and changes thereto may be made without departing from the scope of the invention as described in the claims. Similarly, other variations are within the scope of this disclosure. Thus, the art of the disclosure is subject to various modifications and alternative configurations, though its particular illustrated embodiments have been illustrated and described in detail above. However, there is no intention to limit the invention to one or more specific forms of the disclosure, but rather to cover all modifications, alternative configurations, and equivalents that are included within the scope of the invention as set forth in the appended claims.

[0149] In the context describing embodiments of the disclosure, the terms “a,” “an,” “the,” and similar references (particularly in the context of the claims below) are intended to cover both singular and plural unless specifically indicated or explicitly denied in the context. The terms “comprising,” “having,” “including,” “containing,” etc., should be understood as unrestrictive terms (i.e., “including but not limited to”) unless specifically noted. The term “connected,” when unqualified and referring to a physical connection, should be understood as partially or completely included, appended, or combined, even in the absence of an intermediary. Unless specifically noted, descriptions of ranges of values ​​in this disclosure should function simply as a simplified notation for individually referring to each distinct value contained within that range, and each distinct value should be understood as incorporated herein as individually noted. The use of the terms “set” or “collection” (e.g., “set of items”) or “subset” or “partial collection” should be understood as a non-empty collection containing one or more components, unless specifically noted or explicitly denied in the context. Furthermore, unless otherwise specified or negated by the context, the term “subset” in the context of a corresponding set does not necessarily refer to a proper subset of the corresponding set, and a subset and the corresponding set may be equivalent.

[0150] Associative language, such as "at least one of A, B, and C" or "at least one of A, B, and C," is generally understood in context to indicate that an item, term, etc., can be either A, B, or C, or any non-empty subset of the set A, B, and C, unless otherwise specified or explicitly denied in context. For example, in the example describing a set with three members, the associative phrase "at least one of A, B, and C" or "at least one of A, B, and C" represents any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such associative language is not generally intended to mean that a particular embodiment requires the presence of at least one A, at least one B, and at least one C, respectively.

[0151] The operations of the described processes may be performed in any suitable order unless otherwise specified or explicitly denied in the context. The described processes (or variations and / or combinations thereof) may be executed under the control of one or more computer systems composed of executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that runs in conjunction on one or more processors by hardware or a combination thereof. In some embodiments, the code may be stored on a computer-readable storage medium in the form of a computer program having multiple instructions that can be executed by, for example, one or more processors. In some embodiments, the computer-readable storage medium is non-transient.

[0152] The use of any and all examples, or any exemplary language provided (e.g., "such as"), is merely intended to better illustrate embodiments of the invention and, unless otherwise noted, does not limit the scope of the invention. No language in the specification should be considered to indicate that any unclaimed element is essential for the practice of the invention.

[0153] Embodiments of this disclosure, including the best mode known to the inventors for carrying out the present invention, are described. These various embodiments will become apparent to those skilled in the art by reading the preceding description. The inventors expect that those skilled in the art will appropriately utilize such variations, and the inventors intend that the embodiments of this disclosure will be carried out in ways different from those specifically described. Therefore, the scope of this disclosure includes all modifications and equivalents of the subject matter described in the appended claims, as permitted by applicable law. Furthermore, any combination of the elements described above in all possible variations thereof is encompassed by the scope of this disclosure unless otherwise specifically stated or explicitly denied in the context.

[0154] All cited documents, including publications, patent applications, and patents, are incorporated herein by reference as each document is individually and specifically indicated, and as they are described in whole.

[0155] It should be noted that the embodiments described above are illustrative, not limiting, of the invention, and that those skilled in the art can devise many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference numerals in parentheses are not intended to limit the claims. The terms “comprising,” “comprises,” etc., do not preclude the existence of elements or steps other than those enumerated in any claim or throughout the specification. In this specification, “comprising” means “having or comprising,” and “comprising” means “comprising or comprising.” A single reference to an element does not preclude multiple references to that element, and vice versa. The invention can be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In an apparatus claim enumerating several means, some of these means can be embodied by a single identical hardware item. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously.

[0156] <Summary> The novel technologies described and implied in this disclosure extend the functionality of blockchain without compromising the blockchain's characteristic of guaranteeing the integrity of data stored within the blockchain data structure. For example, these technologies improve computing by implementing and performing methods for obtaining accurate, objective information about real-world events in a trustless manner on the blockchain, particularly in the field of digital record verification, where verification conditions are defined within blockchain transactions where the record is embedded. Furthermore, the technologies described and implied in this disclosure can improve the execution of smart contracts within a blockchain network by utilizing a temporary proof-of-stake blockchain to manage participant voting, which is then made to act as a decentralized, trusted oracle to determine the outcome of smart contracts.

[0157] Furthermore, the technologies described and implied in this disclosure are necessarily rooted in computer technology to obfuscate smart contracts from participants who are made to determine the outcome, thereby preserving the privacy of trading partners, eliminating any reason for participants to collude to tamper with the outcome protocol, and overcoming the problems that arise specifically with the risk of manipulating the outcome of smart contracts. In addition, by utilizing game theory concepts such as Schelling cooperation, anonymous participants may be given a reason to provide accurate information to the protocol. [Explanation of Symbols]

[0158] 100 Blockchain Networks 102 nodes 104 transactions

Claims

1. A method performed by a computer, A step in which a set of conditions is determined among business partners, wherein the set of conditions is as follows: The first possible outcome associated with the first distribution of digital assets, and A second possible outcome associated with the second distribution of the digital assets, different from the first distribution, A step having multiple possible outcomes, The output includes the step of generating a customer transaction that includes the set of conditions and the digital assets encoded in computer executable instructions, A step of receiving an outcome from a third party, wherein the outcome corresponds to the first possible outcome or the second possible outcome, A step of generating an event transaction to transfer control of the digital asset of the aforementioned trading partner transaction, wherein the event transaction includes the event as an input, As a result of verifying the event transaction at a node in the blockchain network, the digital assets are distributed to the trading partner according to the first possible outcome or the second possible outcome, and at least partially based on the outcome; Includes, The aforementioned digital asset includes a first quantity of the digital asset contributed by the first party and a second quantity of the digital asset contributed by the second party. One of the aforementioned multiple possible outcomes is associated with the deadline condition of the set of conditions, A computer-based method further comprising the step of refunding the first amount to the first party and the second amount to the second party as a result of verifying the aforementioned transaction and as a result of the occurrence of the aforementioned expiration condition.

2. The computer-based method according to claim 1, wherein the aforementioned third party is a group comprising multiple members.

3. The computer-based method according to claim 2, wherein the aforementioned outcome is the result of an agreement of responses submitted by the plurality of members.

4. The process further includes the step of determining the number of members including the aforementioned plurality of members, and the threshold number for determining the outcome, The computer-based method according to claim 2, wherein the outcome matches a response submitted by at least the threshold number of the plurality of members.

5. The computer-based method according to claim 4, wherein the outcome is determined at least in part on key shares submitted by the plurality of members, and the key shares are determined according to a secret sharing scheme.

6. The computer-based method according to claim 5, wherein the key share is committed to a block in a proof-of-stake blockchain by the plurality of members.

7. It is a system, Processor and A memory containing executable instructions that cause the system to perform a method performed by a computer according to any one of claims 1 to 6 as a result of execution by the processor, A system that includes this.

8. A non-temporary computer-readable storage medium storing executable instructions, wherein the executable instructions, as a result of being executed by the processor of a computer system, cause the computer system to execute at least one of the methods performed by the computer described in any one of claims 1 to 6.

Images