Execution of Smart Contracts Using Decentralized Coordination

Abstract

To provide a computer-implemented method for determining smart contract outcome.SOLUTION: A method using a blockchain network comprises: communicating, to a set of counterparties, assent to determine an outcome of a set of conditions, the set of conditions having a first possible outcome and a second possible outcome; generating, using a secret sharing protocol, a first private key share corresponding to the first possible outcome and a second private key share corresponding to the second possible outcome; transferring an amount of digital asset to an address associated with a first blockchain transaction; as a result of determining the outcome to be the first possible outcome, revealing the first private key share within a particular time frame, the first private key share usable, at least in part, by the set of counterparties to determine the outcome; and causing a blockchain transaction to be validated at a node in the blockchain network.SELECTED DRAWING: None

Description

Technical Field

[0001] The present invention generally relates to blockchain technology, and more particularly to controlling the execution of a blockchain based on a smart contract that uses a combination of dealerless secret sharing, elliptic curve operations, and signature characteristics. The present invention further implements security in relation to electronic transfers made via a blockchain network using encryption and mathematical techniques. The present invention is particularly suitable for use in smart contracts, but is not limited thereto.

Background Art

[0002] As used herein, the term "blockchain" may represent any of several types of electronic, computer-based, distributed ledgers. These include consensus-based blockchains and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have also been proposed and developed. The example of Bitcoin may be mentioned as a useful application of the technology described in this disclosure for convenience and illustrative purposes, but Bitcoin is only one of many applications to which the technology described in this disclosure 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 uses, are also within the scope of the present invention. For example, the technology described in this disclosure can provide the advantage of utilizing a blockchain implementation with similar limitations to Bitcoin related to what constraints can be imposed in a transaction, regardless of whether a cryptocurrency exchange occurs.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system. This ledger is composed of blocks, and the blocks may be composed of transactions and other information. In some examples, a "blockchain transaction" represents an input message that encodes a structured set of field values including data and a set of conditions. Here, the satisfaction of the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. For example, in Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets among 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. Examples of digital assets include Bitcoin, Ether, and Litecoins. In some implementations, transferring control of a digital asset can be accomplished by re-associating at least a portion of the digital asset from a first entity to a second entity. Each block includes the hash of the previous block. As a result, the blocks are chained together to produce a permanent and immutable record of all transactions written to the blockchain since its inception. Transactions include a small program known as a script. The script embeds the inputs and outputs that specify how and by whom the outputs of the transaction are accessible. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In some examples, a "stack-based scripting language" represents 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. With a stack, values can be pushed onto the top of the stack or popped from the top of the stack. The various operations performed on the stack can result in pushing one or more of the values onto the top of the stack or popping them 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 not equal) onto the top of the stack. Other operations performed on the stack, such as OP_PICK, may allow an item to be selected from a position other than the top of the stack. In some of the 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 of the scripting language can move an item 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 a stack-based scripting language may not be limited to simply a strict last-in-first-out (LIFO) method in some cases. For example, a stack-based scripting language may support operations to copy or move the nth item in the 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 a vector, list, or stack.

[0005] For a transaction to be written to the blockchain, it must be "verified". Network nodes (mining nodes) perform work 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. The software client installed on the node performs this verification work on transactions that reference UTXOs (unspent transaction outputs) by executing lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and other applicable verification conditions are met, the transaction is verified by the node. When a verified transaction is propagated to other network nodes, the mining node can choose to include the transaction in the blockchain. Therefore, for a transaction to be written to the blockchain, the transaction must (i) be verified by the first node that receives the transaction, and if the transaction is verified, that node relays the transaction to other nodes within the network, (ii) be added to a new block constructed by the mining node, and (iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered approved when a sufficient number of blocks have been added to the blockchain to effectively create an irrevocable transaction.

[0006] Blockchain technology is most widely known for use in the implementation of cryptocurrencies, but digital entrepreneurs are beginning to develop the use of both Bitcoin-based cryptographic security systems and data that can be stored on the blockchain for implementing new systems. It would be highly advantageous if blockchains could be used for automated tasks and processes not limited to the field of cryptocurrencies. Such solutions could diversify their uses while taking advantage of the benefits of blockchains (e.g., permanence, tamper-resistance of event records, distributed processing, etc.).

[0007] This disclosure describes the 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 cause actions to be executed 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 may be a computer program designed to automate the execution of machine-readable contract or agreement terms.

[0008] In an embodiment, an interaction with a particular entity can be encoded at a particular step within a smart contract, but in other cases, the smart contract can be automatic and self-executing. It is machine-readable and executable. In some examples, 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, an 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, self-execution represents causing the verification nodes of the blockchain network to execute the unlock transaction according to the constraints. In some examples, "unlocking" a UTXO (also known as "spending" the 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 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, unfixed) when the lock script is generated.

[0010] The present invention may be described as a verification method / system and / or as a control method / system for controlling the verification of blockchain transactions. In some embodiments, the verified blockchain transaction results in the recording of the transaction on the blockchain. This may result in the exchange or transfer of digital assets via the blockchain in some applications. A digital asset may be a unit of resource managed by the blockchain. In some embodiments, the digital asset may be used as a cryptocurrency, although in embodiments, additionally or alternatively, the digital asset may be used in other contexts. The present invention is applicable to the control of digital assets, but is technical in nature and may be used in other contexts that utilize blockchain data structures that do not inherently involve the transfer of digital assets. SUMMARY OF THE INVENTION

[0011] Accordingly, in one or more of the above-described aspects, it is desirable to provide a method and system for improving blockchain technology. Such an improved solution is devised herein. Accordingly, according to the present invention, a method as defined in the appended claims is provided.

[0012] Accordingly, a computer-implemented method comprising: determining a smart contract between trading parties, the set of conditions comprising: a first possible outcome associated with a first distribution of a digital asset, and a second possible outcome associated with a second distribution of the digital asset, different from the first distribution, the step having a plurality of possible outcomes including; generating, as output, a trading party transaction comprising the set of conditions and the digital asset encoded in computer-executable instructions; Receiving an outcome from a third party, the outcome corresponding to the first possible outcome or the second possible outcome; Generating an outcome transaction to transfer control of the digital asset of the counterparty transaction, the outcome transaction including the outcome as an input; Distributing the digital asset to the counterparty at least partially based on the outcome according to the first possible outcome or the second possible outcome as a result of verifying the outcome transaction at a node in a blockchain network; It is desirable to provide a method implemented by a computer including the above.

[0013] The third party may be a group including a plurality of members.

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

[0015] The number of members including a plurality of members may be determined. Additionally or alternatively, a threshold number for determining the outcome may be determined. The outcome may be that responses submitted by at least the threshold number among a plurality of members match.

[0016] The outcome may be determined at least partially based on key shares submitted by a plurality of members. Additionally or alternatively, the key shares may be determined according to a secret sharing scheme.

[0017] The key shares may be committed by a plurality of members to blocks in a proof-of-stake blockchain.

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

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

[0020] Additionally or alternatively, the second digital asset may include a distribution portion funded by a counterparty.

[0021] The plurality of members may include a member whose response does not match the consensus. Additionally or alternatively, as a result of the response not matching the response consensus, the distribution of the second digital asset may exclude the member from receiving the distribution portion.

[0022] The digital asset may include a first amount of the digital asset funded by a first party and a second amount of the digital asset funded by a second party.

[0023] One of a plurality of possible outcomes may be associated with a time limit condition of a set of conditions. Additionally or alternatively, further, as a result of verifying an outcome transaction and as a result of the occurrence of the time limit condition, the first amount may be refunded to the first party. Additionally or alternatively, further, as a result of verifying an outcome transaction and as a result of the occurrence of the time limit condition, the second amount may be refunded to the second party.

[0024] A plurality of secret outcome keys corresponding to a plurality of possible outcomes may be received from a third party. Additionally or alternatively, a possible outcome may be an encryption key corresponding to one of the plurality of secret outcome keys. A secret value determined by a counterparty may be combined with each of the plurality of outcome secret keys to generate a plurality of obfuscated possible outcome keys. A counterparty transaction may be generated to further include the plurality of obfuscated secret keys. The step of verifying an outcome transaction may include the step of combining an encryption key with a secret value to generate a possible outcome signature key. Additionally or alternatively, the step of verifying an outcome transaction may include the step of distributing a digital asset to a counterparty based at least in part on which of the plurality of obfuscated secret keys is associated with the possible outcome signature key.

[0025] Accordingly, further, a method implemented by a computer, communicating to a set of counterparties an agreement to determine an outcome of a set of conditions, the set of conditions including a first possible outcome and a second possible outcome; generating, using a secret sharing scheme, a first secret key share corresponding to the first possible outcome and a second secret key share corresponding to the second possible outcome; transferring an amount of digital assets to an address associated with a first blockchain transaction; disclosing, within a specific time frame as a result of determining that the outcome is the first possible outcome, the first secret key share, the first secret key share being at least partially usable by the set of counterparties to determine the outcome; generating, based at least in part on the first secret key share, a signature at least partially usable for a second blockchain transaction to use the amount of digital assets associated with the first blockchain transaction; To obtain control over the amount of digital assets, it is desirable to provide a method including the step of causing a second blockchain transaction to be verified at a node within a blockchain network.

[0026] Also, a method implemented by a computer, comprising the step of communicating to a set of counterparties an agreement to determine the outcome of a set of conditions, the set of conditions including a first possible outcome and a second possible outcome, generating, using a secret sharing scheme, a first secret key share corresponding to the first possible outcome and a second secret key share corresponding to the second possible outcome, transferring an amount of digital assets to an address associated with a first blockchain transaction, disclosing, within a specific time frame, as a result of determining that the outcome is the first possible outcome, the first secret key share, the first secret key share being at least partially usable by the set of counterparties to determine the outcome, generating a signature at least partially usable for a second blockchain transaction to unlock an amount of digital assets associated with the first blockchain transaction, based at least in part on the first secret key share, and causing the second blockchain transaction to be verified at a node within a blockchain network. It is desirable to provide a method including these steps.

[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 public key and the second public key may be provided to a set of counterparts. Additionally or alternatively, the first secret key share may be usable to determine an outcome by generating a first secret key, at least in part, using the first secret key share. Additionally or alternatively, the first secret key share may be usable to determine an outcome by determining that the first secret key is associated with the first public key.

[0028] The secret sharing protocol may be a dealerless secret sharing protocol.

[0029] The step of disclosing the first secret key share may include the step of disclosing the first secret key share in a third blockchain transaction.

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

[0031] The specific time frame may be a second time frame. Additionally or alternatively, the step of disclosing the first secret key share may further include the step of committing a cryptographic hash of the first secret key share in a commit transaction within a 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 secret key share within the third blockchain transaction corresponds to the cryptographic hash within the commit transaction.

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

[0033] The first blockchain transaction may further include a time limit condition. Additionally or alternatively, as a result of the time limit condition being met, the step of causing the second blockchain transaction to be verified may transfer control of a second quantity of the second digital asset to a subset of the set of counterparties.

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

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

[0036] A group public key associated with the group of counterparties may be generated. Additionally or alternatively, the group public key may be provided to the set of counterparties. Additionally or alternatively, the first blockchain transaction may be generated at least in part using the group public key. Additionally or alternatively, verification of the second blockchain transaction may include the step of determining that the group encryption 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 result of further determining the outcome, the group encryption key may be generated at least in part based on the group secret key share.

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

[0039] Also, a system comprising a processor, and a memory including executable instructions that, as a result of execution by the processor, cause the system to perform the method according to any of the claims, is desirable.

[0040] Also, a non - transitory computer - readable storage medium storing executable instructions that, as a result of execution by one or more processors of a computer system, cause the computer system to perform the method according to any of the claims is desirable.

[0041] The present invention may be described as a verification method / system and / or as 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 will be explained, the present invention may also be described as a secure method / system for new improved advantageous ways of performing operations via a blockchain network or platform.

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

DETAILED DESCRIPTION OF THE INVENTION

[0043] Referring to FIG. 1, FIG. 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 executing an instance of software and / or hardware that performs operations in accordance with the blockchain protocol, i.e., at least partially agreed upon among the operators of node 102. In some examples, a "node" represents a peer-to-peer electronic device distributed within a blockchain network. An example of a blockchain protocol is the Bitcoin protocol.

[0044] In some embodiments, node 102 can be composed of any suitable computing device (e.g., by a server in a data center, by a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), by a plurality of computing devices in a distributed system of a computing resource service provider, or by any suitable client device such as the computing device 800 of FIG. 8). In some embodiments, node 102 has an input for receiving an object representing a data message or a proposed transaction, such as transaction 104. In some embodiments, the node can be queried about the information maintained by the node, e.g., information about the state of transaction 104.

[0045] As shown in FIG. 1, some of the nodes 102 are communicatively coupled to one or more of the other nodes 102. Such communicative couplings can include one or more of wired or wireless communications. In this embodiment, each of the nodes 102 maintains at least a portion of the "ledger" of all transactions in the blockchain. In this way, the ledger is a distributed ledger. Transactions processed by nodes that affect the ledger are verifiable by one or more of the other nodes, and as a result, the integrity of the ledger is maintained.

[0046] Regarding which node 102 can communicate with which other node, it is sufficient for each of the nodes within the exemplary blockchain network 100 to be able to communicate with one or more other nodes 102. As a result, when the blockchain protocol indicates that a message should be forwarded, the message passed between nodes can propagate through the exemplary blockchain network 100 (or some meaningful portion thereof). One such message can be the issuance of a transaction proposed by one of the nodes 102, for example, node 102A. The transaction can then propagate along a path such as path 106. Another such message can 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 cryptographic problems. A mining node that solves a cryptographic problem generates a new block of the blockchain and broadcasts the new block to other nodes 102. The other nodes 102 verify the work of the mining node and, upon verification, accept the block into the blockchain (e.g., by adding the block to the distributed ledger of the blockchain). In some examples, a block is a group of transactions and may be marked by a timestamp and the "fingerprint" (e.g., hash) of the previous block. In this way, each block becomes linked to the previous block, thereby generating a "chain" that links the blocks within the blockchain. In an embodiment, a valid block is added to the blockchain by the consensus of the nodes 102. Also, in some examples, the blockchain includes 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 the present disclosure. In some examples, a transaction includes data providing 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 re-associates (e.g., transfers ownership or control) at least a portion of a digital asset indicated by an unspent UTXO of a previous transaction to an entity associated with a blockchain address. In some examples, a “previous transaction” represents a blockchain transaction that includes the UTXO referenced by the unlock transaction. In some embodiments, a transaction includes a “lock script” that prevents the transaction from occurring unless conditions are met before ownership / control can be transferred (i.e., “unlocked”).

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

[0050] Examples of the arithmetic codes referred to in the present disclosure include the following. ·OP_CHECKSIG. A public key and a signature are popped from the stack and verified against the signature of the transaction field according to the SIGHASH type. If the signature is valid, 1 is returned; otherwise, 0 is returned. ·OP_DUP. Duplicate the top stack item. ·OP_ELSE. If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed, these statements are executed; otherwise, if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed, these statements are not executed. ·OP_ENDIF. End 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, compare the second signature with each of the remaining public keys by the next public key until a match is found. This process is repeated until all signatures are checked. If the signature is valid, 1 is returned; otherwise, 0 is returned. ·OP_CHECKLOCKTIMEVERIFY. End with an error if the top stack item is greater than the transaction nLockTime; 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 parties 202A to 202N (C1 to Cn) that generate smart contracts 206. The smart contract 206 distributes a digital asset amount 220 that depends on the consensus of responses 214 received from a group of members 204A to 204M (p1 to pm) recruited to objectively determine a response 214 in exchange for a distribution 222. That is, in the embodiment, the members 204A to 204M jointly operate as a distributed and reliable oracle to provide answers to decision problems or function problems. In some examples, an "oracle" represents an external agent that can provide an input for determining an outcome, and oracle-related services include Oraclize, TownCrier, and Orisi services. In some embodiments, the members 204A to 204M may not have knowledge of the identities of other members of the group or the knowledge of the responses provided by other members of the group. By keeping the members anonymous from each other, the possibility of collusion among the members is minimized.

[0052] In some embodiments, the trading parties 202A - 02N may be two or more entities that have agreed to the terms of the smart contract. In various embodiments, one of the trading parties 202 may be an individual, a group of individuals, a corporation, 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 trading party is a client and the second trading party is an insurer. In some embodiments, at least one of the trading parties 202A - 02N provides an allocation 222 as an allocation to another entity to interest it in participating as a member 204A - 04M that determines the outcome of the smart contract 206. In some embodiments, at least one of the trading parties 202A - 02N determines which members make up the group of members 204A - 04M. In various embodiments, a member may be a full member, a minimum member, or a maximum member among the members. The more members there are in a group, the more reliable the consensus of the answers provided by the group should be.

[0053] In some embodiments, the members 204A - 04M are a group of entities that can determine the outcome of the conditions of the smart contract 206. In various embodiments, similar to the trading parties 202A - 02N, one of the members may be an individual, a group of individuals, a corporation, 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 among the members 204A - 04M may be designated by the trading parties 202A - 02N. In one example, the trading parties 202A - 02N designate that there must be 15 members in the group.

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

[0055] In various examples, the consensus represents 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 3 matching responses are considered the consensus response), or a threshold number of matching responses. In some embodiments, the trading parties 202A - 02N determine a threshold for determining the consensus. In one example, the trading parties 202A - 02N determine that at least 60% of the members 204A - 04M must submit a matching response in order to reach a consensus.

[0056] Further, in some embodiments, each of the members commits a deposit (e.g., some amount of digital assets). The deposit provides a further reason for the members 204A - 04M to submit an answer. That is, in the above - described embodiments, a member who votes in favor but breaks harmony loses the deposit committed by that member. In some embodiments, even if a member submits a non - consent answer, the member still gets the deposit refunded and the member does not lose the digital assets at least by participating. When determining the amount of the required deposit, the counterparties 202A - 02N balance such that the deposit is not so large that members 204A - 04M have no incentive to participate at all, but is large enough to give members 204A - 04M a reason to provide an accurate answer promptly in order to get their deposits refunded.

[0057] In some embodiments, the smart contract 206 is a set of computer - executable instructions (e.g., opcode) designed to automatically transfer control of digital assets according to conditions agreed upon by the counterparties 202A - 02N. In some embodiments, the smart contract 206 is encoded within a blockchain transaction (such as computer - executable instructions written in a scripting language) and is triggered by the verification of the blockchain transaction by the verification nodes of the blockchain network. In an embodiment, the digital assets associated with the blockchain transaction are redeemable (e.g., obtainable) upon fulfillment of the conditions specified in the smart contract 206. In an embodiment, the smart contract 206 is included in the lock script of the verified transaction in the distributed ledger of the blockchain network. In this way, the executable instructions are made immutable, and the successful execution of the lock script including the smart contract 206 is a prerequisite for transferring the digital assets of the verified transaction.

[0058] Furthermore, as described above, in an embodiment, the smart contract 206 includes a set of conditions, and unlocking the UTXO of the verified transaction depends on the fulfillment 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 when the insured provides proof of suffering a loss covered by the insurance contract as an input to the lock script of the blockchain transaction. Further, in some embodiments, the smart contract 206 is associated with multiple possible outcomes, and the result of the successful execution of the verification including the smart contract 206 may vary depending on a particular outcome. In the example described above, the smart contract 206 has at least two possible outcomes: namely, a first possible outcome and a second possible outcome. The first possible outcome is that the insured suffers a covered loss and receives a payment in accordance with the insurance contract. The second possible outcome is that the insured does not suffer a loss and the insurer maintains the digital assets and the insured's insurance premium payment. In an embodiment, the execution of the computer-executable instructions in the smart contract 206 causes the smart contract 206 to transfer digital assets in accordance with one of the possible outcomes when data proving a particular outcome is provided as an input to the lock script.

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

[0060] In some embodiments, the digital asset 220 is an amount of digital assets that is paid according to certain conditions of the satisfied smart contract 206. That is, depending on which specific conditions are satisfied, the amount of digital assets can vary. For example, if the first condition is satisfied, 10 units of digital assets may be paid to a specific 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 the members 204A - 04M by one or more of the trading partners 202A - 02N to agree to participate in the provision of the response 214. In some embodiments, the distribution 222 is provided by a third party.

[0062] In the present disclosure, it is assumed that all participants prove that they can trust each other and can 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 manner is required to generate a secret value (private key) derived from a cryptographically secure pseudorandom number generator (CSPRNG) by at least a certain level of entropy. In one embodiment, to maintain compatibility with the Bitcoin protocol, these values are 256 - bit numerical values.

[0063] In one embodiment, certain functions are realized 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 a generator point G and its order p. Unless otherwise specified, in the embodiments, the operations in the algorithms described in this disclosure are performed modulo p. Also note that while specific embodiments of this disclosure are presented in the context of the Bitcoin blockchain, the concepts are applicable to any cryptocurrency blockchain that utilizes an elliptic curve signature scheme.

[0064] In one embodiment, two separate groups of participants are included. Namely, the trading parties (Ci) to the main contract, and the members (Pi) who contribute to a cooperative algorithm such as the Schelling adjustment game. For example, the Schelling adjustment game is a coordination game in which two or more individuals can easily reach the same solution (also called the "focal point" or "Schelling point") without communicating with each other. In this way, the members function as a decentralized group oracle that provides accurate inputs to determine the outcome of the main contract. In the embodiment, the trading parties 202A~02N have funds under the control of the contract and jointly provide the distribution 222 to the members in separate blockchain transactions. However, note that since the cooperative algorithm provides the distribution to the members to submit the same answer as submitted by a threshold number of members, the answer is not necessarily correct and may reflect what an individual member thinks the other members will submit.

[0065] In an embodiment, a member commits a refundable security deposit in a separate blockchain transaction after the member has submitted their answer, and may be able to receive an allocation or a portion of the allocation if their answer matches the consensus answer. If their answer does not match the consensus answer, the member can retrieve their deposit, but cannot receive the allocation 222 or a portion of the allocation, or may receive less than what is received by the members who submitted the consensus answer.

[0066] <Contract Setup> In one embodiment, the main contract (also referred to as the "counterparty contract") can be implemented as a collaborative algorithm (e.g., a Schelling coordination game) linked in the following way. n counterparties 202A~02N (C1, C2,..., Cn) agree to the terms and conditions of the contract, including the associated funds. At this stage, the agreement does not have to be formal, and the funds do not have 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 satisfied, counterparties 202A~02N receive an amount X of the digital asset (DA) specified in the result. In one embodiment, the conditions (outcomes) must be clearly specified and mutually exclusive. Further, in one embodiment, also 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 (subtracting any transaction mining amount). Further, in some embodiments, a time limit condition is specified to specify what should happen to the funds if the protocol stops after the time limit period. In one embodiment, each counterparty C j has a public key PKCj has

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

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

[0071] In exemplary embodiment 300, the counterparty transaction 330 is distributed to one or more of the counterparties 302 according to the outcome determined based on the appropriate digital signature corresponding to one of the contract condition public keys 318. Similarly, in exemplary embodiment 300, the collaborative algorithm transaction 332 transfers the distribution and deposit to the members 304 when the outcome of the winner is determined (by the collaborative algorithm).

[0072] The following is an exemplary usage example of the above contract setting. In the exemplary usage example, an insurance contract is generated between two counterparties 302, namely the client (C1) and the insurer (C2). The client wishes to insure against the possibility of severe frost in his vineyard at any time during April 2018 in this example. In this example, severe frost is clearly defined as "any continuous period of at least 4 hours during the month of April 2018, with the temperature maintained below -4°C in the area of Surrey". In this example, the insurer agrees to a policy of paying 10DA if there is severe frost in exchange for a premium of 3DA from the client. Therefore, the insurer commits 10DA to the contract and the client commits 2DA to the contract. Therefore, the contract is shown in Table 2 below and controls 12DA (the insurer's deposit and premium).

[0073] [Table 2]

Table 2

[0074] Thus, under the condition that severe frost occurs, the client receives 10DA and the insurer receives 2DA. On the other hand, under the condition that severe frost does not occur, the client receives no funds, while the insurer retrieves the original 10DA plus a 2DA premium, for a total of 12DA. Neither condition is clearly demonstrated. In the event of a time condition, the client is refunded the 2DA premium and the insurer is similarly refunded the payment of 10DA. Note that the time condition must be redundant if there is no ambiguity regarding the event. The time limit exists to prevent the loss of funds in case the protocol cannot provide a decision. In this example, it only issues refunds to each party. Also, in an embodiment, note that the counterparty agrees on the distribution for the execution of the contract, who pays for this distribution, and the amount selected for the distribution may depend on the nature of the required security and conditions.

[0075] In an embodiment, one of the counterparties (or a third party / service acting on their behalf) submits a request to an open market (or to a public forum). The request specifies the definition of the contract conditions (Def), the provided distribution (F), the number of required members (N), the amount of the required security deposit per member (D), the required threshold (M), the ghost chain block interval (ΔT), and the commit block height (h B ). In an embodiment, the ghost chain block interval represents the frequency at which blocks are committed to the ghost chain block chain. Also, in an embodiment, the commit block height represents the number of blocks in the ghost chain.

[0076] Thus, in the above exemplary use case, the insurer provides a distribution of 0.2DA and requires that a group of 10 members submit one of the following two scenarios. 1. Scenario #1: "In the month of April 2018, somewhere in the Surrey region of the UK, the temperature is kept below -4°C for at least 4 consecutive hours." 2. Scenario #2: "Any other scenario except 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 out of 10 members states which of the above conditions have been met. In this example, members are required to each submit a deposit of 0.1 DA. As a result, the available members can consider the definition of the outcome and their ability to evaluate the conditions (e.g., whether they have access to the necessary information directly or indirectly (i.e., via the news / Internet)), the possible profit (F), and based on the required deposit, decide whether they want to participate. The members communicate to the counterparty what they have committed, including the authenticated UTXO containing the deposit and the public address for communication.

[0078] When a sufficient number (N) of members have communicated acceptance of the request, in one embodiment, the counterparty distributes their communication addresses to the group of members. In an embodiment, the members and the counterparty can then establish a secure peer-to-peer communication channel with each other. In an embodiment, the group of members executes a dealerless secret sharing protocol with a threshold M to generate a group public key (GPK) and individual public keys (and associated individual key shares) for each of the contract conditions / outcomes (IPK i ). These public keys are then sent to the counterparty. i )

[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 multiparty 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 as the constant term (a0 = f(0)), 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 approach 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 value of P i on the shared polynomial f(x).The point, their secret share s i = f(i) is obtained.

[0082] After the secret shares are generated, the public key (A) corresponding to the shared secret key (unknown to any member yet) is calculated as follows by the elliptic curve generator G. Participant P i , i = 1, ..., t, calculates their public key share as b i s i × G, where it is as follows.

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 the t + 1 shares.

Number

[0084] Note that the mathematical properties of elliptic curve cryptography (ECC) are utilized in this disclosure. ECC operations can be defined by a generator point G of degree p. When 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 basic properties of point multiplication, it is as follows. (a + r) × G = a × G + r × G Here, r is a nonce. In an embodiment, this property can be used to utilize random blinding nonces for elliptic curve signatures. Also, in this disclosure, the elliptic curve digital signature algorithm scheme is used in various embodiments to enable a group to jointly sign a transaction using threshold numbers of key shares without reconstructing the complete secret key.

[0086] Continuing with the above exemplary usage, a group of 10 members jointly execute the SSSS protocol without a dealer (with a threshold of 6 as agreed above) three times. The group of 10 members generates a group public key (GPK) and two ephemeral public keys (IPK 1 and IPK 2 ). As a result, each member j then owns three secret key shares (GPriv j , IPriv j 1 , IPriv j 2 ). The group public key further enables member 304 to determine the blockchain address for sending their deposits.

[0087] In one embodiment, counterparty 302 then agrees on a random blind nonce (R B ). In the embodiment, the selected value is stored by all counterparties but kept secret from the member group. In one embodiment, the counterparty then calculates the corresponding elliptic curve public key for R B . PKR = R B × G The value of PKR is then added to each of the contract public keys. IPK i R = IPK i + PKR

[0088] Thus, in this example, counterparty 302 calculates the contract conditional public key 318, IPK 1 R = IPK 1 + PKR, and IPK 2 R = IPK 2 + PKR, and so on. In this method, the public key 314 is the random blind nonce (R B) is obfuscated by its use. As a result, entities other than the counterparty 302, such as the member 304, are very unlikely to be able to link any of the contract condition public keys 318 used in the counterparty transaction 330 to a separate public key 314 generated by the member 304. In this way, the counterparty transaction 330 (and the amount it contains) remains anonymous, and the decisions made by the 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 were generated by agreement of the counterparty 302. That is, the counterparty transaction 330 (TxC) and the cooperative algorithm transaction 332 (TxS). In one embodiment, the counterparty transaction 330 has, as an input, contract funds from the counterparty 302. Also, in one embodiment, the counterparty transaction 330 has separate outputs for each amount payable to one or both of the counterparties 302, depending on the outcome of the contract (e.g., each unique value X i j ). Therefore, each of these UTXOs is distributed to the respective counterparties, depending on the conditions and expiration conditions. Also, it should be noted that in some examples, the output may be configured to pay a third party who is not a member of the counterparty 302. In some embodiments, the output constraint is implemented as a 2-of-2 multi-signature function.

[0090] An example of a condition in the exemplary usage counterparty transaction 320 is shown in Table 3.

[0091] [Table 3]

Table 3

[0092] The script of the exemplary usage example is shown in Table 4.

[0093] [Table 4] [Table 4]

[0094] In one embodiment, the cooperative algorithm transaction 332 has, as inputs, N UTXOs from each of the member deposits and the UTXOs that make up the distribution from the counterparty. In some embodiments, there are two UTXOs, and as described in connection with FIG. 4, one can be unlocked by a signature from a group public key (GPK) that includes a deposit, and the other can be unlocked by a signature from the GPK or by a signature of the counterparty after expiration.

[0095] In embodiments, a threshold number of group members can jointly generate a signature corresponding to GPriv without explicitly determining the group private key (GPriv). In embodiments, the signature cannot be distinguished from a signature generated directly from GPriv, but in implementation, it can be generated directly from the secret key shares (GPriv j ) by a threshold signature scheme. In this method, GPriv does not need to be determined at any point in time, but the corresponding signature can be determined from the threshold number of secret key shares (GPriv j ).

[0096] In the above embodiments, a threshold number of group members agree (and jointly generate a signature) to transfer the first UTXO (deposit). In the above embodiments, a threshold number of group members can also jointly generate a signature to claim the distribution, but can additionally generate k signatures corresponding to one of the possible private keys. In such embodiments, if the group members cannot reconstruct one of the resulting private keys by reaching an agreement, they cannot claim the distribution, and the distribution is returned to the counterparty after expiration.

[0097] In some embodiments, the group members have their threshold number of secret key shares (GPpriv jNote that it can be checked whether (e.g., as part of a dealer-free secret sharing protocol) (GPK) can generate a valid signature at any time without reconstructing the complete secret key. In such an embodiment, the group members of the threshold number can withdraw the deposit at any time, but if they do not fulfill their role in generating the winning outcome key, the distribution will be forfeited. An example of the input and output of the collaborative algorithm transaction 332 of an exemplary use case is shown in Table 5.

[0098] [Table 5]

Table 5

[0099] In one embodiment, the collaborative algorithm transaction 332 is signed by the payee 302 providing the distribution and then sent to the member group to be signed by each of the members 304 in turn. In an embodiment, when each input is signed, the collaborative algorithm transaction is broadcast to the blockchain network. In some embodiments, any participant can stop the protocol (or fail to cooperate) until the collaborative algorithm transaction 332 is signed, and the funds are not placed in a risky state. In one embodiment, when the collaborative algorithm transaction 332 is confirmed on the blockchain, each payee then signs their respective input to the payee transaction 330 and broadcasts it to the blockchain network. In an embodiment, when the payee transaction 330 is approved within the blockchain, the payee contract may be activated.

[0100] <Execution of the contract> In one embodiment, after the counterparty transaction 330 is approved, member 304 waits until after the time period specified in the conditions / terms in request 308 has ended. In one embodiment, member 304 then uses a separate blockchain such as a ghost chain to record their vote. In some examples, a "ghost chain" represents a proof-of-stake blockchain mined by a group of members. Here, the deposits of the members are committed to the collaborative algorithm transaction via a group public key (GPK). That is, unlike a proof-of-work based blockchain (e.g., Bitcoin) where transactions are confirmed by mining nodes interested in the allocation given for performing the work, in the proof-of-stake blockchain of the ghost chain, participants may be interested in recovering the deposits (e.g., some amount of their "stake" of their own digital assets) generated in the ghost chain.

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

[0102] In some embodiments, the proof-of-stake consensus algorithm utilized by the ghost chain may have characteristics of regular block times, timestamped blocks, and the possibility of forks. In some embodiments, block rewards (the "mining amount") are paid out at a predetermined rate (F). In some embodiments, the mining reward can be low due to the very small cost of securing a block. In some embodiments, the collaborative algorithm can be fully performed on the blockchain (i.e., instead of the ghost chain) by a collaborative algorithm transaction, provided there is sufficient scripting ability and a simple payment verification (SPV) proof that recognizes the blockchain. An example of such a blockchain platform is Ethereum.

[0103] In one embodiment, ghost chain blocks are generated at intervals of ΔT, which in some instances are specified in the requirements. 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 of the members 304 reaches a determination of the result required by the trading contract. Using the above exemplary use case, each of the members 304 makes a determination as to whether a severe frost occurred in April 2018. Allowing for the possibility that not all of the members 304 necessarily reach the same determination (e.g., some of the members may have incorrect information or may submit an answer that is inadvertently or deliberately wrong), only a threshold number M of the members 304 need to reach the same determination for the determination to be accepted as the result.

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

[0105] In an embodiment, the commit scheme enables members to pre-commit to a specific value while keeping the value hidden from others. Once the value is committed, it can be disclosed at a later stage. In this way, members of the group cannot change the value after they have committed it, but the value is not disclosed to other members, and thus it can be used as a secure voting protocol.

[0106] Typically, the commit scheme can occur in two stages. That is, a commit stage in which a value is selected and committed by a member, and a disclosure stage in which the value is disclosed by the member and approved to match the commit. Typically, 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 the present disclosure, the committed value may already be a randomly generated key. Therefore, the commit protocol can be reduced to simply utilizing a secure hash function.

[0107] Thus, in the anonymous voting protocol of the present disclosure, at the commit stage, each member hashes the value they wish to commit (e.g., using SHA256), discloses the hash to the group, and at the disclosure stage, each member then discloses the 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 the vote without knowing in advance how much of the rest of the group is voting.

[0108] Thus, in one embodiment, at the block height (h B ) specified in the claim, each of the members (e.g., member 304 in FIG. 3) submits a commit 424 to the secret key share (the secret key share IPriv i j ) of the conditional / term public key corresponding to the contract result they individually determined. In one embodiment, each member signs their respective commit 424, and the commit is embedded in the ghost chain. In an embodiment, each commit can be a simple hash (e.g., Secure Hash Algorithm, SHA256) of the secret key share of each member corresponding to the determined result. By hashing the secret key share, the vote of the member writing it is kept secret until the disclosure stage described below. In this way, the risk that the vote of one member affects the vote of another member is minimized.

[0109] In one embodiment, each member then submits their committed key share 426 (IPriv i j ). Next, this key share is in the next block (h Bis 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 a secret sharing scheme as described above. In such a secret sharing scheme, obtaining at least a threshold number of key shares 426 can arithmetically determine the complete secret key 428. In one embodiment, when this block is verified, if members of the threshold number M submit key shares corresponding to one particular outcome, the winning complete secret key 428 (IPriv w ) corresponding to the winning outcome public key (IPK w ) (e.g., one of the separate public keys 314 in FIG. 3) can be easily determined and publicly disclosed (where w is the index of the winning outcome). In some embodiments, the winning complete secret key 428 is a cryptographic key that is the counterpart of the winning public key (e.g., one of the separate public keys 314) encoded in the smart contract transaction and sent to the counterparty.

[0110] In an exemplary embodiment, the commit height (h B ) is block x - 1, and the committed key share 426 (share of the outcome secret key of member j) is disclosed in block x. After the disclosure, the threshold number of winning secret key shares enables the determination of the winning complete secret key 428.

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

[0112] In some embodiments, the counterparty 502 is similar to the counterparty 202 in Figure 2. In some embodiments, the member 504 is similar to the member 204 in Figure 2. In some embodiments, the signature 518A is the joint digital signature of the members 504 for each member 504 to receive their distribution and deposit. In some embodiments, the signature 518B is the digital signature of the counterparty, and the digital signature is generated using a complete outcome 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 at 612 in Figure 6 to obfuscate the contract condition public key. In some embodiments, the complete outcome signature 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 comparing the complete outcome signature key 526 with the counterparty contract condition public key in the lock script of the counterparty transaction 530A within the smart contract.

[0114] In some embodiments, digital asset 520 is the distribution of digital assets pre - locked in counter - party transaction 530 that follows the outcome of the smart contract winner upon verification of signature 518B. In some embodiments, output 522 reflects the digital assets pre - locked in at least one collaborative algorithm transaction payable to member 504 upon verification of signature 518B. In some embodiments, counter - party transaction 530A is a blockchain transaction similar to counter - party transaction 330 of FIG. 3, including a smart contract such as smart contract 206 of FIG. 2. In some embodiments, outcome transaction 530B is a blockchain transaction created to reimburse / charge the appropriate digital assets of counter - party transaction 530A according to the determined outcome of the smart contract.

[0115] In some embodiments, collaborative algorithm transaction 532A is a blockchain transaction similar to collaborative algorithm transaction 332 of FIG. 3, including the deposit 522 of the distribution and member 504. In some embodiments, distribution transaction 532B is a blockchain transaction generated by them to charge the deposit and distribution of member 504. As a result of determining the winner's complete private key 428, it is possible to determine the member who commits 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 the consensus), and distribution transaction 532B (TxF) is generated by the group or by the members of the group to pay the distribution signed using GPK by a threshold number (m) of members (e.g., by a threshold signature scheme) to the winning member. In an embodiment, the member embeds the winner's complete private key 428 in the metadata of distribution transaction 532B.

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

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

[0118] In an exemplary usage example, 9 out of 10 members 504 commit their shares of IPK 1 and 1 out of members 504 commits their share of IPK 2 (e.g., the information source of the dissenting member was incorrect). In this example, the member group has IPriv 1It is determined that it can be reconstructed from the commitment of the threshold number (6), and then it can be identified which members committed to the winner's share (9). In one embodiment, the threshold number of the member group (subset of winners) can then generate a transaction 532 that pays out the distribution to nine winners and returns all member deposits (fees and deposit 522).

[0119] <Counterparty Group> In one embodiment, the winner's full secret key 528 corresponding to the winner's outcome public key (IPK w ) (e.g., the winner's full secret key 428 in FIG. 4) (IPriv w ) is disclosed by the member group. In one embodiment, either the counterparty 502 (e.g., the counterparty 302 in FIG. 3) or the "winner" counterparty adds the random blind nonce 516 to this value to obtain the full outcome signature key 526. IPriv w R =IPriv w +R B

[0120] In an embodiment, this value can then be used by the "winner" counterparty 502 to generate a signature 518B (along with its own signature from its public key) to claim the output 522 of the counterparty transaction 530 corresponding to the winner's outcome (e.g., the counterparty transaction 530 in FIG. 3). In an exemplary use case, the counterparty determines from the member's consent that an objective outcome of a severe frost has occurred, and thus knows the winner's full secret key 528 (IPriv 1 ) generated by the collaborative algorithm. As a result, the insurance contract transfers the distribution. In an exemplary use case, each of the counterparties 502 (e.g., each of the counterparties 302) adds a random blind nonce 516 (R B ) to IPriv 1 to obtain the full outcome signature key 526 (IPriv 1 R) is obtained. This value can then be used with the private key of each counterparty to generate a signature 518B for transferring the corresponding output 522B of the counterparty transaction 530.

Number

[0121] FIG. 6 is a flowchart illustrating an example of a process 600 for generating smart contracts and collaborative algorithm transactions according to various embodiments. Some or all of process 600 (or any other process described, or variations and / or combinations of those processes) can be executed under the control of one or more computer systems configured by executable instructions and / or other data, and may be implemented as executable instructions to be executed jointly on one or more processors. The executable instructions and / or other data can be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on magnetic, optical, or flash media).

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

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

[0124] In this example, the agreed set of conditions is that when the first condition is met, Alice receives 60% of the digital assets committed to the smart contract, Bob receives 30% of the committed digital assets, and Carol receives 10% of the committed digital assets. Alternatively, when the second condition is met, Bob and Carol each receive 50% of the committed digital assets (Alice gets nothing). As a further alternative, when the third condition is met, Ted, Alice's husband (who has not committed digital assets to the smart contract), inherits 100% of the digital assets of the smart contract. As a fourth condition, if the first, second, and third conditions are not met during a specified time frame, Bob, Carol, and Alice may have their committed digital assets refunded.

[0125] In some embodiments, at 604, the counterparty determines the characteristics of the members operating as a group oracle to determine which conditions are met. That is, the counterparty agrees on how many digital assets should be provided as an allocation to provide a reason for the members 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 votes that must agree to obtain eligibility as an agreement. In one example, Bob, Carol, and Alice agree to provide 10 units of digital assets to each of up to 10 members of a group that agrees to a particular outcome of a smart contract, and that at least 6 responses from the group must match for it to be considered an agreed response. In this example, Bob, Carol, and Alice require that each member of the group commit 0.1 units of digital assets as consideration.

[0126] In some embodiments, at 606, the counterparty determines the timing parameters of the collaborative algorithm transaction, such as the block height and block interval of the ghost chain at which the group members commit their responses. For example, the block height (e.g., the number of blocks that should exist within the blockchain) is specified as 5, the block interval is specified as 1 day, and it starts at a particular time. This gives the group members 5 days (1 day × 5) after the start time to submit their decisions. At the 5th block, the group members submit their signed commitments, and the next day, they disclose their commitments.

[0127] In some embodiments, at 608, the counterparty submits requests to the group members that are similar to request 308 of FIG. 3. That is, the requests define the contract conditions, the allocation provided, the number of members required, the amount of security deposit required per member, the required threshold of matching votes for an agreed response, the ghost chain block interval, and the commitment block height (h B) may include information such as that described above. As described above, the request may be submitted / entered in any forum or communication medium suitable for submitting / entering such requests, such as a website forum, bulletin board, peer-to-peer application, or online marketplace.

[0128] In some embodiments, at 610, the members of the group communicate their agreement to the participants when determining the outcome of the smart contract. In some embodiments, the communication of the agreement is done through the same or a similar forum as the forum in which the request was submitted / entered. In other embodiments, the communication of the 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, at 612, after receiving notice that the group membership requirements have been met, the trading partner generates a random blind nonce that obscures the outcome in the smart contract transaction. The random blind nonce may be determined in various ways. For example, one trading partner may generate the random blind nonce and the other party or parties may communicate approval / agreement to the one party. Alternatively, each party may generate a portion of the random blind nonce and all of the generated portions are combined according to a mathematical algorithm to form the random blind nonce.

[0130] In some embodiments, at 614, the counterparty generates / agrees on a public key of the smart contract, similar to the contract public key 316 of FIG. 3. In an embodiment, the public key corresponds to a random blind nonce (e.g., 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 combined at 616 with each of the outcome public keys generated by the members. Note that at 616, the group members generate a group public key and an outcome public key for each of the results of the contract. Note that the group public key and the outcome key may be generated using a dealerless secret sharing protocol as described above. Each group member may have a secret key share corresponding to the outcome public key. The secret key share is used as the number of key shares required to regenerate the complete secret key corresponding to the outcome public key of the winning outcome for the number of matching votes specified by the counterparty at 604 of FIG. 6, and may be generated using a secret sharing protocol as described in the present disclosure. In an embodiment, the group members provide the group public key and the outcome public key to the counterparty via the communication medium established at 608-12.

[0131] In some embodiments, at 618, at least one of the counterparties generates a contract condition public key by combining each of the outcome public keys generated by the member group at 616 with the 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, note that at 620, the smart contract transaction is generated and signed by the counterparty and committed to the blockchain along with the funds (e.g., the amount of digital assets) agreed upon by each of the counterparties. The smart contract transaction may have separate UTXOs for each of the amounts payable to one or both counterparties, depending on the outcome of the contract.

[0132] Finally, in some embodiments, at 622, the counterparty generates a collaborative algorithm transaction similar to the collaborative algorithm transaction 332 of FIG. 3. In some embodiments, the collaborative algorithm transaction includes, as a UTXO, a deposit from a group member. The deposit may be paid by a signature from the group public key generated by the member group at 616 after the group members have submitted their responses or after the deadline. In some embodiments, the collaborative algorithm transaction may include, additionally or alternatively, a distribution provided by the counterparty that can be unlocked by a signature using the group public key or by the signature of the counterparty after the deadline. In some embodiments, the UTXO may be within the same collaborative algorithm transaction. On the other hand, in other embodiments, the UTXO may be within a separate transaction. Note that one or more of the operations performed at 602-22 can be executed in various orders and combinations, including in parallel.

[0133] FIG. 7 is a flowchart illustrating an example of a process 700 for executing a smart contract according to various embodiments. Part or all of the process 700 (or any other process described, or variations and / or combinations of those processes) can be executed under the control of one or more computer systems composed of executable instructions and / or other data, and may be implemented as executable instructions that execute jointly on one or more processors. The executable instructions and / or other data can be stored in a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on magnetic, optical, or flash media).

[0134] For example, some 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 of FIG. 8). Process 700 includes a series of operations, where members commit and disclose their answer key shares, and if there are threshold-matching answers, the secret commitment key associated with the consensus answer can be determined, and then the complete commitment signature key can be calculated.

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

[0136] At the end of the time period, in some embodiments, at 702, each of the group members commits the key share corresponding to their determined answer to a block in the ghost chain shown as mix 424 in FIG. 4. This is shown as commit 424 in FIG. 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 shares for a particular answer. Note that in some embodiments, not all group members necessarily need to submit their answers within the same block. For example, if a group member reaches their answer on the 3rd day out of 5 days, that group member may submit their answer in the 3rd block.

[0137] In some embodiments, at 704, in the next block in the ghost chain, members disclose their commitments. This is shown in disclosure 426 of FIG. 4 and can be verified by comparing the hash of the disclosure with the hash of the previous commitment. In some embodiments, at 706, it is determined whether the number of key shares is sufficient to construct a secret key corresponding to a valid outcome secret key. If not, at 708, the counterparty may recover their funds and the members may be refunded their deposits. In such an example, in some embodiments, since no consensus answer was reached, the members may not receive a distribution or may receive a small distribution.

[0138] Alternatively, in some embodiments, at 710, a winner's outcome secret key is generated. The member who submitted the winner's answer can co-sign at 712 on a transaction such as distribution transaction 532B of FIG. 5 that was generated to collect the distribution and refund the member deposits. The winner's outcome secret key may be provided to the counterparty by the group. This counterparty may, at 714, combine the winner's outcome secret key with a random blind nonce to generate a complete outcome signature key (e.g., complete outcome signature key 526 of FIG. 5).

[0139] In some embodiments, at 716, each of the counterparties can sign a transaction similar to outcome transaction 520B with a signature generated using their own secret key and a signature generated using the complete outcome signature key, thereby claiming funds suitable for the outcome of the smart contract as agreed at 602 of FIG. 6. Note that one or more of the operations performed at 702 - 16 can be executed in various orders and combinations including in parallel.

[0140] In the context of describing the disclosed embodiments, unless otherwise specified, the use of expressions related to executable instructions (also referred to as code, applications, agents, etc.) that perform operations (e.g., data transmission, calculation, etc.) that are normally performed without assistance by an instruction indicates that the instruction is executed by a machine, thereby causing the machine to perform a specific operation.

[0141] FIG. 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 can be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 8, the computing device 800 can include one or more processors 802 that are configured and operatively coupled to communicate with a number of peripheral subsystems via a bus subsystem 804 in an embodiment. In some embodiments, these peripheral subsystems include a storage subsystem 806 that includes 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 can be used for temporary or long-term storage of information.

[0142] In some embodiments, the bus subsystem 804 provides a mechanism that enables the various components and subsystems of the computing device 800 to communicate with each other as intended. The bus subsystem 804 is shown schematically as a single bus, although 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 to a network. The network interface subsystem 816 functions, in some embodiments, 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 utilized to communicate data such as details, search terms, and the like.

[0143] In some embodiments, the user interface input device 812 includes one or more user input devices such as a keyboard, an integrated mouse, a trackball, a touchpad, or a pointing device such as a graphics tablet, a scanner, a barcode scanner, a touch screen incorporated 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, one or more user interface output devices 814 include a display subsystem, a printer, or a non-visual display such as an audio output device, and the like. In some embodiments, the display subsystem includes a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a flat panel device such as a projection, or other display devices. 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 to enable user interaction with an application that executes the processes and variations described herein when such interaction is appropriate.

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

[0145] In 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 in which fixed instructions can be stored. In some embodiments, the file / disk storage subsystem 810 provides non-transitory persistent (non-volatile) storage for program and data files and may include a hard disk drive, a floppy disk drive in conjunction with a related removable medium, a compact disc read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0146] In some embodiments, computing device 800 has at least one local clock 824. The local clock 824, in some embodiments, represents a counter that represents the number of hours elapsed since a specific start date and, in some embodiments, is disposed 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 the subsystems included therein at specific clock pulses and can be used to coordinate motoring operations between the computing device 800 and other systems within the data center. In another embodiment, the local clock is a programmable internal timer.

[0147] The computing device 800 can be any of a variety of types including a portable computing device, a tablet computer, a workstation, or any of the other devices described hereinafter. Further, in some embodiments, the computing device 800 can include another device connectable to the computing device 800 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). In an embodiment, such a device includes a port configured to receive an optical fiber connector. Thus, in some embodiments, this device is configured to convert an optical signal into an electrical signal that is transmitted to the computing device 800 through the port connecting the device for processing. Due to the constantly changing nature of computers and networks, the description of the computing device 800 shown in FIG. 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 FIG. 8.

[0148] The specification and drawings are to be regarded, therefore, as illustrative rather than restrictive. However, it is clear that various changes and modifications may be made therein without departing from the scope of the invention as set forth in the claims. Similarly, other variations are within the scope of the disclosure. Accordingly, the disclosed technology is subject to various changes and alternative configurations, although the specific illustrated embodiments have been shown and described in detail above. However, there is no intention to limit the invention to the one or more specific forms disclosed, and on the contrary, it is intended to cover all changes, alternative configurations, and equivalents included within the scope of the invention as defined by the appended claims.

[0149] The terms "a" and "an", "the", and similar references in the context of describing embodiments of the disclosure are intended to cover both singular and plural (in the context of the following claims in particular), unless the context specifically indicates otherwise or is clearly negated. Terms such as "having", "comprising", "including", "containing", etc. should be considered as open-ended terms (i.e., meaning "including but not limited to") unless otherwise specified. The term "connected" when unmodified and referring to a physical connection should be considered to mean being included, added, or joined together, in whole or in part, even when there is no intervening element. The recitation of a range of values in this disclosure is, unless otherwise specified, merely a shorthand notation for referring individually to each of the separate values within that range, and each separate value is to be considered as incorporated herein as if it were individually recited. The use of the terms "set or collection" (e.g., "a set of items") or "subset or subcollection" is to be considered, unless otherwise specified or negated by the context, as a non-empty collection containing one or more elements. Further, unless otherwise specified or negated by the context, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set, and the subset and the corresponding set may be equal.

[0150] Conjunctive 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 be used to indicate that an item, term, etc. can be any one of A or B or C, or any non-empty subset of the set of A and B and C, unless otherwise stated or clearly negated in context. For example, in an example for the description of a set having three members, the conjunctive 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 conjunctive 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 process can be performed in any suitable order, unless otherwise stated or clearly negated in context. The described process (or variations and / or combinations thereof) can be executed under the control of one or more computer systems configured by executable instructions and implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that execute in cooperation on one or more processors by hardware or a combination thereof. In some embodiments, the code can be stored on a computer-readable storage medium in the form of a computer program having, for example, a plurality of instructions executable by one or more processors. In some embodiments, the computer-readable storage medium is non-transitory.

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

[0153] Embodiments of the present disclosure including the best mode known to the inventor for carrying out the present invention are described. These various embodiments will become apparent to those skilled in the art upon reading the foregoing description. The inventor expects those skilled in the art to appropriately utilize such variations, and the inventor intends that the embodiments of the present disclosure be practiced in a manner different from that particularly described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by the applicable law. Further, any combination of the above-described elements in all possible variations is included within the scope of the present disclosure unless otherwise specifically stated or clearly negated by context.

[0154] All cited documents, including publications, patent applications, and patents, are hereby incorporated by reference as if each document were individually and specifically shown and as if the whole of each document were described herein.

[0155] It should be noted that the above-described embodiments do not limit the present invention but explain it, and those skilled in the art can devise many alternative embodiments without departing from the scope of the present invention defined by the appended claims. In the claims, any reference signs in parentheses do not intend to limit the claim. Terms such as "having" and "comprising" do not exclude the presence of elements or steps other than those recited in any claim or the entire specification. In this specification, "having" means "having or consisting of", and "comprising" means "comprising or consisting of". A singular reference to an element does not exclude a plural reference to that element. Vice versa. The present invention can be implemented by hardware including several distinct elements and by a computer appropriately programmed. In apparatus claims listing several means, some of these means can be embodied by one and the same hardware item. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be advantageously used.

[0156] <Summary> The novel technologies described and suggested in this disclosure extend the functionality of the blockchain without compromising the property of the blockchain that guarantees the integrity of data stored within the blockchain data structure. For example, these technologies, in particular, in the field of digital record verification defined within blockchain transactions where the conditions for verification are embedded in records, perform and carry out methods for obtaining accurate objective information regarding real-world events in a trustless manner on the blockchain, thereby improving the field of computing. Further, the technologies described and suggested in this disclosure utilize a temporary proof-of-stake blockchain to manage the voting of participants who are made to operate as a distributed and trustworthy oracle for determining the outcome of smart contracts, thereby improving the execution of smart contracts within the blockchain network.

[0157] Furthermore, the technologies described and suggested in this disclosure obfuscate smart contracts from participants who are made to determine the outcome, thereby maintaining the privacy of the counterparty, removing the reason for participants to collude to overturn the outcome protocol, and specifically overcoming the problems arising with the risk of manipulating the outcome of smart contracts, which necessarily roots in computer technology. Further, by utilizing concepts of game theory such as Schelling coordination, anonymous participants can be given a reason to provide accurate information to the protocol.

Claims

1. A method implemented by a first computing device, comprising: encoding a smart contract including a set of conditions agreed upon between trading parties into a trading party transaction, wherein at least one of the trading parties is the first computing device, and satisfaction of a predetermined condition among the set of conditions is as follows: a first possible outcome associated with a first distribution of a digital asset, and a second possible outcome associated with a second distribution of the digital asset different from the first distribution, corresponding to a predetermined outcome among a plurality of possible outcomes, and encoding the smart contract includes generating, as output, the trading party transaction including the set of conditions encoded into computer-executable instructions and the digital asset; receiving an outcome from a third party, the outcome corresponding to the first possible outcome or the second possible outcome, the third party being at least one second computing device; generating an outcome transaction to transfer control of the digital asset of the trading party transaction, the outcome transaction including the outcome as input; distributing the digital asset to the trading party at least partially based on the outcome according to the first possible outcome or the second possible outcome as a result of verifying the outcome transaction at a node in a blockchain network; A method comprising.

2. The method according to claim 1, wherein the third party is a group including a plurality of members which are a plurality of second computing devices.

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

4. The method according to claim 2 or 3, wherein the number of members including the plurality of members is determined.

5. The method according to any one of claims 2 to 4, wherein a threshold value for determining the outcome is determined.

6. The method according to claim 5, wherein the outcome matches at least the responses submitted by at least a threshold number of the plurality of members.

7. The method according to any one of claims 2 to 6, wherein the outcome is determined based at least in part on key shares submitted by the plurality of members.

8. The method according to claim 7, wherein the key shares are determined according to a secret sharing scheme.

9. The method according to claim 7 or 8, wherein the key shares are committed by the plurality of members to blocks in a proof-of-stake blockchain.

10. The method according to any one of claims 2 to 9, wherein the plurality of members includes members having responses that do not agree.

11. The method according to claim 10, wherein as a result of the response not agreeing with the response consensus, the second distribution excludes the member from receiving a distributed portion.

12. The method according to any one of claims 1 to 11, wherein at least one cooperative algorithm transaction associated with the second distribution is generated.

13. The method according to any one of claims 1 to 12, wherein the second distribution is distributed to the third party as a result of verifying a distribution transaction generated to transfer control of the second distribution.

14. The method according to any one of claims 1 to 13, wherein the second distribution includes a deposit portion funded by the third party.

15. The method according to any one of claims 1 to 14, wherein the second distribution includes a distributed portion contributed by the trading partner.

16. The method according to any one of claims 1 to 15, wherein the digital asset includes a first quantity of the digital asset contributed by a first party and a second quantity of the digital asset contributed by a second party.

17. The method according to any one of claims 1 to 16, wherein the plurality of possible outcomes are associated with a time limit condition of the set of conditions.

18. The method according to claim 17, which depends on claim 16, wherein as a result of verifying the outcome transaction and as a result of the occurrence of the time limit condition, the first quantity is refunded to the first party.

19. The method according to claim 17 or 18, which depends on claim 16, wherein as a result of verifying the outcome transaction and as a result of the occurrence of the time limit condition, the second quantity is refunded to the second party.

20. The method according to any one of claims 1 to 19, wherein a plurality of secret outcome keys corresponding to the plurality of possible outcomes are received from the third party.

21. The method according to claim 20, wherein the outcome includes an encryption key corresponding to one of the plurality of secret outcome keys.

22. The method according to claim 20 or 21, wherein a secret value determined by the trading partner is combined with each of the plurality of secret outcome keys to generate a plurality of obfuscated outcome keys.

23. The method according to claim 22, wherein the trading partner transaction further includes the plurality of obfuscated outcome keys.

24. The step of verifying the outcome transaction includes combining the cryptographic key with the secret value to generate an outcome signature key, according to claim 22 or 23, which depends on claim 21.

25. The step of verifying the outcome transaction includes distributing the digital asset to the recipient, at least partially based on which of the plurality of obfuscated outcome keys is associated with the outcome signature key, according to any one of claims 23 and 24, which depends on claim 23.

26. A system comprising: a processor; a memory including executable instructions that, as a result of execution by the processor, cause the system to execute the method according to any one of claims 1 to 25; and the system includes the above.

27. A non-transitory computer-readable storage medium storing executable instructions that, as a result of execution by a processor of a computer system, cause the computer system to execute at least the method according to any one of claims 1 to 25.

Images