Smart contract execution using distributed coordination

Abstract

The invention relates to a distributed ledger technology, such as a consensus-based block chain. A computer-implemented method for smart contract result determination is described. The method is implemented by using a block chain network. A set of conditions between counterparties is determined, the set of conditions having a plurality of possible results, the results including a first possible result associated with a first allocation of the digital assets and a second possible result associated with a second allocation of the digital assets, the second allocation being different from the first allocation. A counterparty transaction is created that includes, as outputs, a set of conditions encoded as computer executable instructions and a digital asset. A result is received from the third party, the result corresponding to the first possible result or the second possible result. A result transaction is created to transfer control of the digital assets of the counterparty transaction, the result transaction including the result as an input. As a result transaction is verified at a node in the blockchain network, digital assets are assigned to counterparties according to the first possible result or the second possible result based at least in part on the result.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201880061618.5 (PCT international application number PCT / IB2018 / 057058), application date September 14, 2018, and name “Smart Contract Execution Using Distributed Coordination”. Technical Field

[0002] The present invention generally relates to blockchain technology, and more specifically to using a combination of dealer-free secret sharing, elliptic curve arithmetic and signatures to control the execution of blockchain-based smart contracts. The present invention also utilizes cryptographic and mathematical techniques to enhance the security associated with electronic transfers made through blockchain networks. The present invention is particularly suitable for, but not limited to, use in smart contracts. Background Art

[0003] In this document, the term "blockchain" may refer to any of several types of computer-based electronic distributed ledgers. They include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variants. The technology described in this disclosure can be applied to many blockchain technologies. A variety of blockchain implementations and protocols, including non-commercial applications, fall within the scope of the present invention.

[0004] Blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system, which consists of blocks, and blocks in turn consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured set of field values ​​including data and a set of conditions, where the implementation of the condition set is a prerequisite for writing the field set into the blockchain data structure. For example, each transaction can be a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. In some embodiments, a "digital asset" refers to binary data associated with a right to use. In some embodiments, the transfer of control of a digital asset can be performed by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block contains a hash of the previous block, so the blocks become linked together to create a permanent, immutable record of all transactions that have been written to the blockchain since the blockchain was created. Transactions contain small programs called scripts embedded in their inputs and outputs, which specify how and by whom the output of the transaction can be accessed. These scripts can be written in a stack-based scripting language.

[0005] In some examples, a "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models and operations. That is, a stack-based scripting language can utilize a stack. Using a stack, values ​​can be pushed to or popped from the top of the stack. Various operations performed on the stack can cause one or more values ​​to be pushed to or popped from the top of the stack. For example, the OP_EQUAL operation pops the top two items from the stack, compares them, and then pushes the result (e.g., 1 if equal, 0 if not equal) to the top of the stack. Other operations performed on the stack (e.g., OP_PICK) can allow items to be selected from locations other than the top of the stack. In some scripting languages ​​used in some embodiments, there may be at least two stacks: a main stack and a backup stack. Some operations of the scripting language can move items from the top of one stack to the top of another stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the backup stack. It should be noted that in some cases, a stack-based scripting language may not be limited to operating in a strictly last-in, first-out (LIFO) manner. For example, a stack-based scripting language may support an operation that copies or moves the nth item in a stack to the top. Scripts written in a stack-based scripting language may be pushed into a logical stack, which may be implemented using any appropriate data structure, such as a vector, a list, or a stack.

[0006] In order for a transaction to be written to the blockchain, it must be "verified". Network nodes (mining nodes) work to ensure that each transaction is valid, and invalid transactions are rejected from the network. Nodes can have different validity criteria than other nodes. Because validity in the blockchain is based on consensus, a transaction is considered valid if the majority of nodes agree that it is valid. The software client installed on the node performs this verification work in part on transactions that reference unspent transactions (UTXO) by executing UTXO lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, and other verification conditions are met (if applicable), the transaction is verified by the node. The verified transaction is propagated to other network nodes, whereby the network node (mining node) can choose to include the transaction in the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must i) be verified by the first node that receives the transaction - if the transaction is verified, the node relays it to other nodes in the network; ii) be added to a new block built by the network node (mining node); and iii) be mined, that is, added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks are added to the blockchain to make the transaction effectively irreversible.

[0007] While blockchain technology is widely known for its implementation using cryptocurrency, digital entrepreneurs have begun exploring the implementation of new systems using the cryptographic security systems that some blockchain implementations are based on and the data that can be stored on the blockchain. It would be very beneficial if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such a solution would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while being more versatile in its applications.

[0008] The present disclosure describes a technical solution for one or more blockchain-based computer programs. A blockchain-based computer program is a machine-readable and executable program recorded in a blockchain transaction. A blockchain-based computer program includes rules that can process inputs to produce results, and then these rules can cause actions to be taken based on these results. One area of ​​current research is the use of blockchain-based computer programs to implement "smart contracts." Unlike traditional contracts written in natural language, smart contracts can be computer programs that are designed to automatically execute the terms of a machine-readable contract or agreement.

[0009] In an embodiment, although the interaction with a specific entity can be encoded at a specific step of the smart contract, the smart contract can also be automatically executed and self-enforced. It is machine-readable and executable. In some examples, automatic execution refers to the execution of a smart contract that is successfully carried out to realize the transfer of UTXO. Note that in this example, the "entity" that can cause the UTXO transfer refers to an entity that can create an unlocking script without proving that it has some secrets. In other words, the unlocking transaction can be verified without proving that the data source (e.g., the entity that creates the unlocking transaction) has access to the cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). In addition, in this example, self-enforcement refers to causing the verification node of the blockchain network to implement the unlocking transaction according to the constraints. In some examples, using "unlocking" UTXO (also called "consuming" UTXO) in a technical sense refers to creating a reference UTXO and executing a valid unlocking transaction.

[0010] Blockchain transaction outputs include a locking script and information about the ownership of a digital asset. A locking script (also known as a block) "locks" a digital asset by specifying the conditions that need to be met to transfer the UTXO. For example, a locking script may require certain data to be provided in an unlocking script in order to unlock the associated digital asset. The technique of requiring a party to provide data to unlock a digital asset involves embedding a hash of the data in the locking script. However, this can cause problems if the data is not determined when the locking script is created (e.g., unknown and fixed data).

[0011] The present invention may be described as a verification method / system, and / or as a control method / system for controlling verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in the recording of the transaction on the blockchain, which in some applications may result in the exchange or transfer of digital assets via the blockchain. A digital asset may be a unit of resource managed by a blockchain. While in some embodiments, a digital asset may be used as a cryptocurrency, it is contemplated that in embodiments, digital assets may be used additionally or alternatively in other contexts. Note that while the present invention may be applicable to the control of digital assets, it is technical in nature and may be used in other contexts that utilize blockchain data structures without necessarily involving the transfer of digital assets. Summary of the invention

[0012] Therefore, it is desirable to provide methods and systems that improve blockchain technology in one or more of these scenarios. Such improved solutions have now been devised. Therefore, according to the present invention, there is provided a method as defined in the appended claims.

[0013] Therefore, it is desirable to provide a computer-implemented method comprising:

[0014] A condition set between the counterparties is determined, the condition set having a plurality of possible outcomes, the outcomes comprising:

[0015] a first possible outcome associated with the first allocation of the digital asset; and

[0016] a second possible outcome associated with a second allocation of the digital asset, the second allocation being different than the first allocation;

[0017] creating a counterparty transaction, the counterparty transaction comprising the set of conditions encoded as computer-executable instructions and the digital asset as an output;

[0018] receiving a result from a third party, the result corresponding to the first possible result or the second possible result;

[0019] creating a resulting transaction to transfer control of the digital asset of the counterparty transaction, the resulting transaction including the outcome as an input; and

[0020] As a result of verifying the resulting transaction on a node of a blockchain network, the digital asset is allocated to the counterparty according to the first possible outcome or the second possible outcome based at least in part on the outcome.

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

[0022] The result may be a result of a consensus of responses submitted by the plurality of members.

[0023] The number of members may be determined to include the plurality of members. Additionally or alternatively, a threshold number may be determined to determine the result. The result may match responses submitted by at least the threshold number of members of the plurality of members.

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

[0025] The key shares may be submitted by the plurality of members to a block in a proof-of-stake blockchain.

[0026] At least one coordinated algorithmic transaction associated with the second digital asset may be created. Additionally or alternatively, the second digital asset may be allocated to the third party as a result of verifying the allocation transaction created to transfer control of the second digital asset.

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

[0028] Additionally or alternatively, the second digital asset may include an allocated portion of the counterparty contribution.

[0029] The plurality of members may include a member whose reply does not match the consensus. Additionally or alternatively, the allocation of the second digital asset may be such that the member is unable to receive the allocated portion due to the reply not matching the consensus of replies.

[0030] The digital assets may include a first amount of digital assets contributed by a first party and a second amount of digital assets contributed by a second party.

[0031] One of the plurality of possible outcomes may be associated with a timeout condition of the condition set. Additionally or alternatively, further as a result of verifying the resulting transaction and the occurrence of the timeout condition, the first amount may be refunded to the first party. Additionally or alternatively, further as a result of verifying the resulting transaction and the occurrence of the timeout condition, the second amount may be refunded to the second party.

[0032] A plurality of secret result keys corresponding to the plurality of possible results may be received from the third party. Additionally or alternatively, the result may be a cryptographic key corresponding to one of the plurality of secret result keys. A secret value determined by the counterparty may be combined with each of the plurality of secret result keys to produce a plurality of obfuscated result keys. The counterparty transaction may be created to further include the plurality of obfuscated private keys. Verifying the result transaction may include combining the cryptographic key with the secret value to produce a result signing key. Additionally or alternatively, verifying the result transaction may include allocating the digital asset to the counterparty based at least in part on which of the plurality of obfuscated private keys is associated with the result signing key.

[0033] Therefore, it is also desirable to provide a computer-implemented method, the computer-implemented method comprising:

[0034] communicating consent to the set of counterparties to determine an outcome of a set of conditions, the set of conditions having a first possible outcome and a second possible outcome;

[0035] Generate a first private key share corresponding to the first possible result and a second private key share corresponding to the second possible result using a secret sharing protocol;

[0036] Transferring a certain amount of digital assets to the address associated with the first blockchain transaction;

[0037] As a result of determining the outcome as the first possible outcome, a first private key share is revealed within a specific time frame, and the first private key share is at least partially usable by the set of counterparties to determine the outcome;

[0038] generating a signature based at least in part on the first private key share, the signature being usable at least in part to authenticate a second blockchain transaction to consume the amount of digital assets associated with the first blockchain transaction; and

[0039] The second blockchain transaction is verified at a node in the blockchain network to obtain control over the certain amount of digital assets.

[0040] Furthermore, it is desirable to provide a computer-implemented method comprising:

[0041] communicating consent to a set of counterparties to determine an outcome of a set of conditions, the set of conditions having a first possible outcome and a second possible outcome;

[0042] Generate a first private key share corresponding to the first possible result and a second private key share corresponding to the second possible result using a secret sharing protocol;

[0043] Transferring a certain amount of digital assets to the address associated with the first blockchain transaction;

[0044] As a result of determining the outcome as the first possible outcome, a first private key share is revealed within a specific time interval, and the first private key share is at least partially usable by the set of counterparties to determine the outcome;

[0045] generating a signature based at least in part on the first private key share, the signature being usable at least in part to authenticate a second blockchain transaction to unlock the amount of digital assets associated with the first blockchain transaction; and

[0046] The second blockchain transaction is verified at a node in the blockchain network.

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

[0048] The secret sharing protocol may be a dealer-free secret sharing protocol.

[0049] Revealing the first private key share may include revealing the first private key share in a third blockchain transaction.

[0050] The third blockchain transaction may be a transaction in a proof-of-stake blockchain.

[0051] The specific time interval may be a second time interval. Additionally or alternatively, revealing the first private key share may further include submitting a cryptographic hash of the first private key share in a commitment transaction within a first time interval prior to the second time interval. Additionally or alternatively, verifying the third blockchain transaction may include determining that the first private key share in the third blockchain transaction corresponds to the cryptographic hash in the commitment transaction.

[0052] The first blockchain transaction may further include a second amount of a second digital asset transferred from a subset of the set of counterparties. Additionally or alternatively, control of the second amount of the second digital asset may be further transferred as a result of the second blockchain transaction being validated.

[0053] The first blockchain transaction may further include a timeout condition. Additionally or alternatively, as a result of satisfying the timeout condition, validating the second blockchain transaction may transfer control of the second amount of the second digital asset to a subset of the set of counterparties.

[0054] Verification of the second blockchain transaction may include verifying a digital signature generated using a group cryptographic key associated with the group of participants that have agreed to determine the outcome.

[0055] The group of participants may include a first subset of participants that reveal key shares corresponding to the first possible outcome. Additionally or alternatively, the group of participants may include a second subset of participants that reveal key shares corresponding to the second possible outcome. Additionally or alternatively, transferring control of the second amount may include transferring control of the second amount to the first subset of participants, excluding the second subset of participants.

[0056] A group public key associated with the group of participants 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 created at least in part using the group public key. Additionally or alternatively, verification of the second blockchain transaction may include determining that the group cryptographic key is associated with the group public key of the first blockchain transaction.

[0057] A secret sharing protocol may be used to generate a group private key share. Additionally or alternatively, further as a result of determining the result, a group cryptographic key may be generated based at least in part on the group private key share.

[0058] The first private key share may belong to a plurality of first private key shares distributed among a group of participants. Additionally or alternatively, the first private key share may correspond to a first possible outcome. Additionally or alternatively, determining the outcome as a first possible outcome may include determining that a threshold number of the plurality of first private key shares have been revealed by the group of participants.

[0059] Furthermore, it is desirable to provide a system comprising: a processor; and a memory, comprising executable instructions, which, due to execution by the processor, cause the system to perform any of the methods claimed.

[0060] Furthermore, it is desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by one or more processors of a computer system, cause the computer system to perform at least any of the methods claimed.

[0061] 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 described below, the present invention may also be described as a security method / system for operating in a new, improved, and advantageous manner via a blockchain network or platform. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0063] Figure 1 A blockchain environment in which various embodiments may be implemented is shown;

[0064] Figure 2 An example of a smart contract according to an embodiment is shown;

[0065] Figure 3 An example of establishing a smart contract according to an embodiment is shown;

[0066] Figure 4 An example of coordination result determination according to an embodiment is shown;

[0067] Figure 5 An example of smart contract execution according to an embodiment is shown;

[0068] Figure 6 is a schematic diagram illustrating an example of creating a smart contract and coordinating algorithmic transactions according to an embodiment;

[0069] Figure 7 is a schematic diagram showing an example of executing a smart contract according to an embodiment; and

[0070] Figure 8 A computing environment is shown in which various embodiments may be implemented. DETAILED DESCRIPTION

[0071] First reference Figure 1 , which illustrates an exemplary blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure. In this embodiment, the exemplary blockchain network 100 includes blockchain nodes implemented as peer-to-peer distributed electronic devices, each node running an instance of software and / or hardware that performs operations that comply with a blockchain protocol that is at least partially agreed upon between operators of the nodes 102. In some examples, a "node" refers to a peer electronic device distributed among a blockchain network.

[0072] In some embodiments, node 102 may include any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device (e.g., Figure 8In some embodiments, nodes 102 have multiple inputs to receive data messages or objects representing proposed transactions (e.g., transaction 104). In some embodiments, nodes are queryable for information they maintain (e.g., information about the state of transaction 104).

[0073] like Figure 1 As shown, some nodes 102 may be communicatively coupled to one or more other nodes 102. Such communicatively coupling may include one or more of wired or wireless communications. In this embodiment, each node 102 maintains at least a portion of a "ledger" of all transactions in the blockchain. In this way, the ledger will be a distributed ledger. Transactions processed by a node that affects the ledger may be confirmed by one or more other nodes, thereby maintaining the integrity of the ledger.

[0074] With respect to which nodes 102 can communicate with which other nodes, it is sufficient that each node in the exemplary blockchain network 100 is able to communicate with one or more other nodes 102 such that messages passed between nodes can propagate throughout the exemplary blockchain network 100 (or some significant portion thereof), assuming that the message is one that the blockchain protocol indicates should be forwarded. One such message might be a publication of a proposed transaction by one of the nodes 102 (e.g., node 102A), which would then propagate along a path such as path 106. Another such message might be a publication of a new block proposed for inclusion on the blockchain.

[0075] In an embodiment, at least a portion of nodes 102 are network nodes (mining nodes) that perform complex computations (e.g., solving cryptographic problems). The network node that solves the cryptographic problem creates a new block for the blockchain and broadcasts the new block to other nodes in node 102. The other nodes in node 102 confirm the work of the network node that solves the cryptographic problem (mining node) and accept the block into the blockchain after confirmation (e.g., by adding it to the distributed ledger of the blockchain). In some examples, a block is a group of transactions, typically marked with a timestamp and "fingerprint" (e.g., hash) of the previous block. In this way, each block can become linked to the previous block, thereby creating a "chain" of linked blocks in the blockchain. In an embodiment, a valid block is added to the blockchain by consensus of nodes 102. In some examples, the blockchain also includes a list of verified blocks.

[0076] In an embodiment, as described in the present disclosure, at least a portion of nodes 102 operate as validating nodes for validating transactions. In some examples, transactions include data that provide proof of digital asset ownership and conditions for accepting or transferring digital asset ownership / control. In some examples, an "unlocking transaction" refers to a blockchain transaction that reassociates (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" refers to a blockchain transaction that contains a UTXO referenced by an unlocking transaction. In some embodiments, a transaction includes a "locking script" that blocks a transaction by providing a condition that must be met before ownership / control can be transferred ("unlocked").

[0077] In some embodiments, a blockchain address is a string of alphanumeric characters that is associated with an entity to which control of at least a portion of a digital asset is being transferred / reassociated. 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 involves verifying one or more conditions specified in a locking script and / or an unlocking script. After successfully verifying transaction 104, the verification node adds transaction 104 to the blockchain and assigns it to node 102.

[0078] Examples of operation codes referenced in this disclosure include:

[0079] OP_CHECKSIG, where the public key and signature are popped from the stack based on the SIGHASH type and verified against the signature of the transaction field. Returns 1 if the signature is valid, 0 otherwise.

[0080] OP_DUP, which duplicates the top stack item

[0081] OP_ELSE, if the previous OP_IF or OP_NOTIF or OP_ELSE has not been executed, then these statements will be executed; otherwise, if the previous OP_IF or OP_NOTIF or OP_ELSE has been executed, then these statements will not be executed

[0082] OP_ENDIF, which ends the if / else block

[0083] OP_IF, which executes the statement and deletes the top stack value if the top stack value is not False

[0084] OP_CHECKMULTISIG, which compares the first signature to each public key until a match is found. Then, using subsequent public keys, the second signature is compared to each remaining public key until a match is found. This process is repeated until all signatures have been checked. If the signature is valid, it returns 1, otherwise it returns 0.

[0085] OP_CHECKLOCKTIMEVERIFY, if the top stack item is greater than the transaction nLockTime, exit with error; otherwise, script evaluation continues

[0086] Figure 2 An exemplary embodiment 200 of the present disclosure is shown. Figure 2 As shown, exemplary embodiment 200 may include counterparties 202A-02N (C1-C n ), the counterparty 202A-02N(C1-C n ) creates a smart contract 206, which allocates a certain amount of digital assets 220, which depends on the number of digital assets from the member groups 204A-04M (p1-p m ) received the consensus of the reply 214, the member group 204A-04M (p1-p m ) is recruited to objectively determine the answer 214 in exchange for the allocation 222. That is, in an embodiment, members 204A-04M collectively act as a distributed trusted authority to provide answers to decision-making problems or functional problems. In some examples, "authority" refers to an external agent that provides input that can determine the result; authority-related services include Oraclize, TownCrier, and Orisi services. In some embodiments, members 204A-04M do not necessarily know the identities of other members of the group or the answers provided by other members of the group. By keeping members anonymous from each other, the possibility of collusion between members can be minimized.

[0087] In some embodiments, counterparties 202A-02N can be two or more entities that have agreed on the terms of the smart contract. In various embodiments, one of counterparties 202 is an individual, a group of individuals, a company, a computing device, or some other entity that can determine or agree to the terms of the smart contract 206. In one use case, the first counterparty is a customer and the second counterparty is an insurance company. In some embodiments, at least one of counterparties 202A-02N provides allocation 222 as an allocation to attract other entities to participate as members 204A-04M of the result of determining the smart contract 206. In some embodiments, at least one of counterparties 202A-02N determines how many members to include member groups 204A-04B. In various embodiments, the number is the exact number, minimum number, or maximum number of members. The more members in the group, the more reliable the consensus reply provided by the group.

[0088] In some embodiments, members 204A-04M are groups of entities that can determine the outcome of a condition of smart contract 206. As with counterparties 202A-02N, in various embodiments, one of the members is an individual, group of individuals, company, software application, computing device, or some other entity that can provide a response that can be used to determine the outcome of smart contract 206. As described above, in some embodiments, the number of members 204A-04M can be specified by counterparty 202A-02N. In one example, counterparty 202A-02N specifies that there must be 15 members in the group.

[0089] In an embodiment, if not enough members join the group (e.g., within a specified time), the counterparty 202A-02N generates a smart contract 206 to refund any amount of digital assets deposited by the counterparty 202A-02N (minus the transaction allocation). As described above, in some embodiments, the member 204A-04M can be provided with a reason to participate in determining the reply 214 through the allocation 222 proposed by the counterparty 202A-02N. In some embodiments, the member 204A-04M submits a reply that matches the consensus of the reply and receives the allocation 222 or a portion of the allocation 222 (e.g., divided by multiple members). In some of these embodiments, a member who submits a non-consensus reply (a reply that is inconsistent with the consensus reply) loses its allocation 222 or a portion of the allocation 222. In other embodiments, the member who submits the non-consensus reply receives less allocation or a smaller portion of the allocation 222 than the member who submitted the reply that matched the consensus received.

[0090] In various examples, consensus refers to a simple majority of matching replies, a supermajority of matching replies, a majority of matching replies submitted before a threshold is reached (e.g., the first three matching replies are considered consensus replies), or a threshold number of matching replies. In some embodiments, counterparty 202A-02N determines a threshold for determining consensus. In an example, counterparty 202A-02N determines that at least 60% of members 204A-04M must submit matching replies to reach consensus.

[0091] In addition, in some embodiments, each member commits a deposit (e.g., a deposit of a certain amount of digital assets), which provides further reasons for members 204A-04M to submit responses. That is, in these embodiments, members who agree to participate but do not comply with the agreement lose their committed deposits. In some embodiments, even if a member submits a non-consensus response, the deposit is still returned to the member, so that the member at least does not lose digital assets due to participation. When determining the amount of the required deposit, the counterparty 202A-02N can make a trade-off so that the deposit is large enough to provide members 204A-04M with a reason to provide a timely and accurate response in order to return their deposit, but not large enough to prevent members 204A-04M from not wanting to participate at all.

[0092] In some embodiments, smart contract 206 is a collection of computer executable instructions (e.g., operation codes) designed to automatically transfer control of digital assets based on conditions agreed to by counterparties 202A-02N. In some embodiments, smart contract 206 is coded in a blockchain transaction (e.g., as computer executable instructions written in a scripting language) and activated by verification of the blockchain transaction by a verification node of the blockchain network. In an embodiment, the digital assets associated with the blockchain transaction can be redeemed (e.g., obtainable) by satisfying the conditions specified in smart contract 206. In an embodiment, smart contract 206 is included in the locking script of a verified transaction in the distributed ledger of the blockchain network. In this way, the executable instructions are rendered immutable, and the successful execution of the locking script containing smart contract 206 is a prerequisite for transferring the digital assets of the verified transaction.

[0093] In addition, 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 satisfaction of the set of conditions. In the example, the smart contract 206 is an insurance contract, and when a proof that the insured suffered a loss covered by the insurance contract is provided as an input to the locking script of the blockchain transaction, the digital asset is allocated to the insured according to the insurance contract. In addition, in some embodiments, the smart contract 206 is associated with multiple possible results, and the result of successfully executing the verification containing the smart contract 206 may be different depending on the specific result. In the above example, the smart contract 206 has at least two possible results: a first possible result, a second possible result. The first possible result is that the insured suffers a covered loss and receives a payment according to the insurance contract. The second possible result is that the insured does not suffer a loss, and the insurance company retains the digital asset and the insured's premium. In an embodiment, if data proving a specific result is provided as an input to the locking script, the execution of the computer executable instructions in the smart contract 206 will cause the smart contract 206 to transfer the digital asset according to one of the possible results.

[0094] In some embodiments, the reply 214 is a reply corresponding to one or more result 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 paid and to which entity the digital assets 220 are paid. Members 204A-04M submit a reply 214, which can be used to determine which of the multiple conditions (if any) are met. In some embodiments, the reply 214 is submitted in the form of a cryptographic key or digital signature. In this way, the satisfied condition can be determined by determining which condition in the smart contract 206 corresponds to the cryptographic key or digital signature submitted by the consensus of members 204A-04M.

[0095] In some embodiments, digital asset 220 is the amount of digital asset paid based on a specific condition of smart contract 206 being met. That is, the amount of digital asset may be different depending on which specific condition is met. For example, if a first condition is met, 10 units of digital asset may be paid to a specific entity, and if a second condition is met, 2 units of digital asset may be paid to the same or different entity.

[0096] As described above, in some embodiments, allocation 222 is an amount of digital assets that one or more of counterparties 202A-02N provide as an allocation to members 204A-04M to agree to participate in providing responses 214. In some embodiments, allocation 222 is provided by a third party.

[0097] In the present disclosure, it is assumed that all participants can mutually authenticate and can communicate with each other via a secure communication channel. In an embodiment, a public key cryptography system or a Diffie-Hellman key exchange protocol can be used to achieve secure communication. In an embodiment, each participant in the scheme is required to generate a secret value (private key) derived from a cryptographically secure pseudo-random number generator (CSPRNG) with at least a certain degree of entropy. In an embodiment, these values ​​are 256-bit numbers.

[0098] In an embodiment, certain functions are facilitated by using elliptic curve operations. In an embodiment, elliptic curve (EC) operations are performed using parameters defined by the Secp256k1 curve, which is currently used in some blockchain implementations for public key generation, signature generation, and signature verification. In addition to the curve parameters, the Secp256k1 standard also specifies the generator point G and its order p. Unless otherwise specified, in an embodiment, the operations in the algorithms described in the present disclosure are performed modulo p. Note also that it is contemplated that the concepts described herein are also applicable to any blockchain that employs an elliptic curve signature scheme.

[0099] In an embodiment, two separate groups of participants are involved, namely the counterparties to the master contract (C i ) and members who contributed to coordination algorithms (e.g., Schelling coordination games) (P i ). For example, the Schelling coordination game is a coordination game in which two or more individuals attempt to arrive at the same solution (also known as a "central point" or "Schelling point") without communicating with each other. In this way, members act as distributed group authorities that provide accurate input to determine the outcome of the master contract. In an embodiment, counterparties 202A-02N obtain funds under the control of the contract and collectively provide allocations 222 to members in separate blockchain transactions. Note, however, that because the coordination algorithm provides an allocation to a member for submitting a response that is identical to a response submitted by a threshold number of members, the response is not necessarily correct, but may reflect the response that a single member believes other members will submit.

[0100] Additionally, in an embodiment, members pledge a deposit in a separate blockchain transaction that can be returned after the member submits their answer and can potentially win the allotment or a portion of the allotment if their answer matches the consensus answer. If their answer is not the consensus answer, the member can get their deposit back, but may not necessarily receive the allotment 222 or a portion of the allotment 222, or may receive a smaller portion than the member who submitted the consensus answer received.

[0101] Contract establishment

[0102] In an embodiment, a master contract (also referred to as a "counterparty contract") may be implemented as a linked coordination algorithm (e.g., Schelling coordination game) in the following manner: n number of counterparties 202A-02N (C1, C2, . . . , C n ) Agree to the terms and conditions of the contract, including the funds involved. Note that at this stage, the agreement can be informal and no funds need to be committed until the transaction is signed. The overall structure of the contract at this stage is shown below in Table 1.

[0103] Table 1:

[0104]

[0105] In an embodiment, when the first condition is met, the counterparty 202A-02N receives a quantity X of digital assets (DA) specified in the result. Note that in an embodiment, the conditions (results) must be explicitly specified and must be mutually exclusive. In addition, in an embodiment, the quantity of each condition i The sum of is also equal to the funds to be paid into the contract (minus any transaction mining fees). In addition, in some embodiments, a timeout condition is added to specify what happens to the funds if the protocol fails after a timeout period. In an embodiment, each counterparty C j PKC with public key j .

[0106] Figure 3 An exemplary embodiment 300 of the present disclosure is shown. Specifically, Figure 3 A high-level schematic diagram of a public key establishment process for an exemplary embodiment 300 of the present disclosure is shown. The exemplary embodiment 300 includes a counterparty 302 that has agreed to a contract 306 and has issued a request 308 to a plurality of members 304 to provide results to the conditions in the contract. As shown, the request 308 may include relevant information such as a definition of the contract conditions (Def), an allocation provided (F), a required number of members (N), a required deposit amount per member (D), a required threshold (M), a virtual chain block interval (ΔT), and a committed block height (h B ). The identity of the counterparty and the allocation of digital assets controlled by the smart contract transaction 330 may not be present / rejected in the request 308, so as not to affect the voting of the group members.

[0107] In the exemplary embodiment 300, the counterparties also generate contract public keys 316. In an embodiment, the counterparties 302 are able to communicate with each other (e.g., via email and / or other electronic communications), and at least one of the counterparties 302 is able to communicate with the members 304, such as through a portal, an online marketplace, a web log, peer-to-peer communications, or some other communication forum. In an embodiment, after sufficient members (at least equal to the number specified by the counterparties 302 in the request 308) signal their consent to become part of the group, the members 304 agree to generate a group public key 312 and a shared public key 314 corresponding to each contract condition / outcome. In the exemplary embodiment 309, the members 304 generate the group public key 312 and the shared public key 314 using a dealer-free secret sharing scheme. In the exemplary embodiment 300, the value of the contract public key 316 provided by the counterparty 302 is combined with the individual public key 314 to produce the contract condition public key 318.

[0108] In the exemplary embodiment 300, counterparty transactions 330 are allocated to one or more counterparties 302 based on an outcome determined based on an appropriate digital signature corresponding to one of the contract condition public keys 318. Similarly, in the exemplary embodiment 300, coordination algorithm transactions 332 transfer allocations and deposits to members 304 after determining (via the coordination algorithm) a winning outcome.

[0109] The following is an exemplary use case for the above contract establishment. In the exemplary use case, an insurance contract is created between two counterparties 302, a customer (C1) and an insurance company (C2). In this example, the customer wishes to insure against the possibility of severe frost on his vineyard at any time in April 2018. In this example, severe frost is explicitly defined as "any continuous period of at least 4 hours in April 2018 when the temperature in Surrey remains below -4°C". In this example, the insurance company agrees to a policy that it will pay 10DA in the event of severe frost in exchange for a premium of 2DA from the customer. Therefore, the insurance company commits 10DA to the contract and the customer commits 2DA to the contract. Therefore, the contract will control a total of 12DA (the insurance company's deposit and the premium) as shown in Table 2 below.

[0110] Table 2:

[0111]

[0112] Thus, in the condition that severe frost occurs, the client receives 10DA and the insurer receives 2DA. On the other hand, in the condition that severe frost does not occur, the client does not recover any funds, while the insurer recovers the original 10DA plus 2DA of the premium, totaling 12DA. In the event that neither condition is clearly confirmed and a timeout condition occurs, the client is refunded the 2DA premium and likewise, the insurer is refunded the 10DA payout. Note that the timeout condition should be redundant if the event is unambiguous; if the protocol fails to provide a decision, the timeout exists to prevent the loss of funds and, in this example, only a refund is made to the parties. Note also that in an embodiment, the counterparties also agree on an allocation for the execution of the contract and who will pay that allocation; the amount chosen for the allocation may depend on the desired security and the nature of the condition.

[0113] In an embodiment, one of the counterparties (or a third party / service acting on its behalf) publishes a request to an open market (or public forum) specifying the definition of the contract conditions (Def), the allocation provided (F), the required number of members (N), the amount of margin required by each member (D), the required threshold (M), the virtual chain block interval (ΔT), and the committed block height (h B ). In an embodiment, the virtual chain block interval refers to the frequency of submitting blocks to the virtual chain blockchain. In addition, in an embodiment, the committed block height refers to the number of blocks in the virtual chain.

[0114] So, in the example use case above, the insurance company offers an allocation of 0.2DA and asks the group of 10 members to submit one of the following two outcomes:

[0115] 1. Result 1: "In April 2018, anywhere in Surrey, UK, the temperature remained below -4°C for at least 4 hours".

[0116] 2. Result 2: "[Other results than condition 1]"

[0117] In an exemplary use case, both the insurance company and the client agree to a threshold of 6. That is, the agreement of at least 6 of the 10 members will dictate which of the above conditions are met. In the example, members are required to submit a deposit of 0.1DA each. As a result, valid members can view the result definition and decide whether they wish to participate based on their ability to evaluate the conditions (e.g., whether they can access the required information directly or indirectly (i.e., via news / internet)), the potential to win (F), and the required deposit. The member communicates its acceptance to the counterparty and includes a certified UTXO containing the deposit, as well as a public address for communication.

[0118] In an embodiment, when a sufficient number (N) of members (P i) signals that they accept the request, the counterparty assigns its communication address to the member group. In an embodiment, the member and counterparty can then establish a secure peer-to-peer communication channel with each other. In an embodiment, the member group executes a dealer-free secret sharing protocol with a threshold M to generate a secret key for each contract condition / outcome (IPK i ) generates a group public key (GPK) and individual public keys (and associated personal key shares), and these public keys are sent to the counterparty.

[0119] In an embodiment, members use a method of sharing a secret key such that each member has a share of a (yet unknown) secret key. The secret key itself can be computed from a threshold number of shares (where the threshold is less than or equal to the number of members). Thus, while the secret key is not known to any single party, the group of members can determine the elliptical public key corresponding to the yet unknown secret key via secure multi-party computation. In this way, blockchain outputs can be placed under the control of a shared group key in an untrusted manner, and the secret key can be determined (or a signature generated) through the cooperation of a threshold number of members.

[0120] 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 be fitted to any set of t+1 (threshold) points. A polynomial f(x) of degree t is formed with the shared secret key as a constant term (a0=f(0)), and the remaining coefficients are randomly selected. Each member is given a number of points on the curve equal to the number of members in the group. If the number of members combining their points is equal to or greater than (t+1), then there is enough information to fit a polynomial of degree t to these points, and a o In an embodiment, the scheme enables sharing of a single private key among an arbitrarily large number of members with an arbitrary threshold.

[0121] The standard SSSS can be extended to remove the requirement for a trusted dealer to create the polynomial and distribute the secret shares, thereby eliminating the reliance on a trusted dealer. In this dealerless SSSS, each member (P i ) Generate its own random polynomial f with a degree of t i (x), then f i (j) Send securely to every other participant P j Then each P i Sum all received points to get their secret shares s i = f(i), which is P on the shared polynomial f(x). i point.

[0122] After the secret shares are created, the public key (A) corresponding to the shared private key (not yet known to any member) is calculated using the elliptic curve generator G as follows. i , where i = 1, ..., t + 1, and its public key share is calculated as b i s i ×G, where

[0123]

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

[0125]

[0126] Note that the arithmetic properties of elliptic curve cryptography (ECC) are exploited in this disclosure. The ECC operation can be defined with a generator point G of order p. Once a random private key (a) is chosen (between 1 and p), the public key (A) can be derived by point multiplication:

[0127] A=a×G

[0128] Furthermore, due to the basic properties of point multiplication:

[0129] (a+r)×G=a×G+r×G

[0130] Where r can be a random number. In an embodiment, this property can be used to employ a random blind random number for an elliptic curve signature. In addition, in the present disclosure, an elliptic curve digital signature algorithm scheme is used in various embodiments to enable a group to jointly sign a transaction using a threshold number of key shares without having to reconstruct a complete private key.

[0131] To further the above exemplary use case, a group of 10 members collectively executes the dealerless SSSS protocol three times (with a threshold of 6 as described above). The group of 10 members generates a group public key (GPK) and two result public keys (IPK 1 and IPK 2 ). As a result, each member j then has 3 secret key shares (GPriv j , and ). The group public key also enables member 304 to determine the blockchain address to which their deposit is sent.

[0132] In an embodiment, the counterparty 302 then generates a random blinding random number (R B ) is agreed upon. In this embodiment, the selected value is stored by all counterparties but is kept secret from the group of members. In an embodiment, the counterparties then calculate R B The corresponding elliptic curve public key:

[0133] PKR=R B ×G

[0134] Then, add the value of PKR to each contract condition public key:

[0135]

[0136] Thus, in this example, counterparty 302 calculates contract condition public key 318, and In this way, due to the use of random blind random numbers (R B ), public keys 314 are obfuscated such that it is extremely unlikely that an entity other than counterparty 302 (e.g., member 304) will be able to link any contract condition public key 318 used in counterparty transaction 330 to a separate public key 314 generated by member 304. In this way, counterparty transactions 330 (and the amounts they contain) remain anonymous, and decisions made by member 304 are not influenced by knowledge of contract transaction details (e.g., a certain amount of digital assets at risk).

[0137] In this example, two transactions are created through the agreement of the counterparties 302: the counterparty transaction 330 (TxC) and the coordinated algorithmic transaction 332 (TxS). In an embodiment, the counterparty transaction 330 has as input the contract funds from the counterparties 302. In addition, in an embodiment, the counterparty transaction 330 has a separate output for each amount that can be paid to one or both counterparties 302 depending on the contract outcome (e.g., Each unique value of ). Thus, each of these UTXOs is allocated to a respective counterparty based on conditions and timeout conditions. It is also important to note that in some examples, outputs may be constructed to pay third parties that are not members of counterparty 302. In some embodiments, output constraints are implemented as a 2-of-2 multi-signature function.

[0138] Table 3 shows an example of conditions in a counterparty transaction 320 for an exemplary use case.

[0139] Table 3:

[0140]

[0141] Table 4 shows the script for an exemplary use case.

[0142] Table 4:

[0143]

[0144] In an embodiment, the coordination algorithm transaction 332 takes as input the N UTXOs from each member's deposit and the UTXOs that constitute the allocation from the counterparty. In some embodiments, there are two UTXOs: one that can be unlocked by a signature from the group public key (GPK) containing the deposit, and the other containing the allocation, which can also be unlocked by a signature from the GPK or by the counterparty signature after a timeout, such as Figure 4 as described in the context of .

[0145] In an embodiment, a threshold number of group members can collaborate to generate a signature corresponding to the group private key (GPriv) without explicitly determining GPriv. In an embodiment, the signature will be indistinguishable from a signature generated directly from GPriv, but it can actually be generated directly from the private key share (GPriv) via a threshold signature scheme. j ) is generated. In this way, GPriv does not need to be determined at any point in time, but can be generated based on a threshold number of private key shares (GPriv j ) to determine the corresponding signature.

[0146] In these embodiments, a threshold number of group members agree (and jointly generate a signature) to transfer the first UTXO (the deposit). In these embodiments, a threshold number of group members may also collaborate to generate a signature to claim the allocation, but produce an additional signature corresponding to one of the resulting private keys. In such embodiments, if the group members cannot reconstruct one of the resulting private keys by reaching consensus, they cannot claim the allocation, and the allocation will be returned to the counterparty(ies) after a timeout.

[0147] Note that in some embodiments, group members may be able to check a threshold number of their private key shares (GPriv j ) will generate a valid signature corresponding to (GPK) without having to reconstruct the full private key. In such an embodiment, a threshold number of group members may also be able to withdraw the deposit at any time, but will forfeit the allocation if they did not play a role in generating the winning outcome key. Table 5 shows an example of the inputs and outputs of the coordination algorithm transaction 332 for an exemplary use case.

[0148] Table 5:

[0149]

[0150] In an embodiment, the coordination algorithm transaction 332 is signed by the counterparty 302 providing the allocation, and then sent to the member group and signed by each member 304 in turn. In this embodiment, once each input is signed, the coordination algorithm transaction 332 is broadcast to the blockchain network. Note that in some embodiments, until the coordination algorithm transaction 332 is signed, any participant can withdraw from the agreement (or fail to cooperate) and there is no financial risk. In an embodiment, once the coordination algorithm transaction 332 is confirmed on the blockchain, each counterparty signs their respective inputs to the counterparty transaction 330 and broadcasts it to the blockchain network. In this embodiment, once the counterparty transaction 330 is confirmed in the blockchain, the counterparty contract can be activated.

[0151] Contract Execution

[0152] In an embodiment, after confirming the counterparty transaction 330, the member 304 waits until the time period specified in the condition / item in the request 308 expires. In an embodiment, the member 304 then utilizes a separate blockchain (e.g., a virtual chain) to record their vote. In some examples, the "virtual chain" refers to a proof-of-stake blockchain (mined by a group of members), whose deposits are committed to the coordination algorithm transaction via a group key (GPK). That is, unlike a blockchain based on proof of work (where transactions are verified by mining nodes that are interested in being granted an allocation for performing work), in a virtual chain proof-of-stake blockchain, participants may be interested in recovering deposits made in the virtual chain (e.g., a portion of the amount of their digital assets that they "collateralized").

[0153] Unlike traditional blockchains, a virtual chain can be configured to terminate, disappear, and / or expire when one or more criteria, goals, or specified purposes are performed or met. That is, in some embodiments, a virtual chain is a single-purpose blockchain that is no longer used once its purpose is achieved. In some embodiments, a virtual chain includes an initial block (also called a "genesis block") that is created when the virtual chain is deployed or created for its purpose, standard, or goal.

[0154] In some embodiments, the proof-of-stake consensus algorithm used by the virtual chain may have the following characteristics: regular block times, timestamped blocks, and low fork probability. In some embodiments, block allocations ("mining amounts") are paid from allocations (F) at a predetermined rate. In some embodiments, the mining distribution may not be high because the cost of verifying blocks is negligible. Note that in some embodiments, given sufficient scripting capabilities and single payment confirmation (SPV) proofs that can identify blockchains, the coordination algorithm can be completely performed on the blockchain (i.e., instead of the virtual chain) through coordination algorithm transactions. An example of such a blockchain platform is Ethereum.

[0155] In an embodiment, virtual chain blocks are generated at intervals of ΔT, which in some cases are specified in the request. In some embodiments, the value of ΔT is selected based on the desired speed of contract resolution and the desired response time from the members 304. In an embodiment, each member 304 reaches a determination of the outcome sought by the counterparty contract. Using the exemplary use case given above, each member 304 determines whether severe frost occurred in April 2018. Given the possibility that not all members 304 may obtain the same determination result (e.g., a portion of the members may have incorrect information, or may accidentally or intentionally submit an incorrect response), only a threshold number M of members 304 need to obtain the same determination result in order to accept the determination result as the result.

[0156] Figure 4 An exemplary embodiment 400 of the present disclosure is shown. Specifically, Figure 4 A high-level schematic diagram showing the smart contract setup of an embodiment of the present disclosure is shown. As shown in the figure, Figure 4 Includes transactions 438 submitted to virtual chain 434 at multiple intervals. In some embodiments, virtual chain 434 can be a temporary proof-of-stake side chain created to record votes in a coordination algorithm. In some embodiments, transaction 438 is a blockchain transaction that is added to (mined into) a block of virtual chain 434. In some embodiments, each successive block includes hash 436, which is a cryptographic hash of the previous block in the virtual chain. Hash 436 links the blocks in virtual chain 434.

[0157] In an embodiment, the submission scheme enables members to submit a specific value in advance while keeping that value hidden from others. Once the value is submitted, it can be revealed in a later stage. In this way, group members cannot change the value after they submit it, but it is not revealed to other members, and in this way it can be used as a secure voting protocol.

[0158] Typically, a commit scheme can occur in two phases: a commit phase, in which a member selects and commits the value; and a reveal phase, in which the member reveals the value and confirms that the value is consistent with the commit. Typically, a secure commit scheme can rely on random blinding nonce to prevent any information about the submitted value from being revealed after the commit phase. However, in the present disclosure, the submitted value may already be a randomly generated key. Therefore, the commit protocol can be reduced to simply employ a secure hash function.

[0159] Thus, in the anonymous voting protocol of the present disclosure: in the commit phase, each member hashes (e.g., using SHA256) the value they wish to commit and reveals the hash to the group, then in the reveal phase, each member reveals the hash pre-image (the submitted value) to the group, and the group verifies each hash. In this way, the group can commit a vote without knowing in advance how any remaining members of the group will vote.

[0160] Therefore, in an embodiment, at the block height (h B ), each member (e.g. Figure 3 Members 304 of the i-th condition submit a commitment 424 (member j's private key share for the i-th condition) to the private key share of the condition / item public key corresponding to the contract outcome they have determined respectively. ). In an embodiment, each member signs their respective commitment 424, and these commitments are added (mined into) the virtual chain. In an embodiment, each commitment can be a simple hash (e.g., Secure Hash Algorithm (SHA) 256) of the respective member's private key share corresponding to the determined result; by hashing the private key share, each member's vote is kept secret until the reveal phase described below. In this way, the risk of one member's vote influencing another member's vote can be minimized.

[0161] In an embodiment, each member then submits their committed key share 426 Then the key share 426 is added to (mined into) the next block (h B +1). In some embodiments, the key shares 426 held by each group member are shares of the full private key determined according to a secret sharing scheme such as described above. In such a secret sharing scheme, obtaining at least a threshold number of key shares 426 may allow the full private key 428 to be mathematically determined. In an embodiment, once the block is verified, if a threshold number of members have submitted key shares corresponding to a particular result, then the winning result public key (IPK w )(For example, Figure 3 The winning complete private key 428 (IPriv w ) can be easily determined and publicly revealed (w is the winning outcome index). In some embodiments, the winning full private key 428 is the counterparty's cryptographic key of the winning public key (e.g., one of the individual public keys 314) that is sent to the counterparty and encoded in the smart contract transaction.

[0162] In an exemplary embodiment, the committed height (h B) is block x-1, and the submitted key share 426 (the share of the resulting private key for member j) is revealed at block x. After the reveal, a threshold number of winning private key shares enables the winning full private key 428 to be determined.

[0163] Figure 5 An exemplary embodiment 500 of the present disclosure is shown. Specifically, Figure 5 Shown in accordance with Figure 4 Execute after determining the result Figure 3 A high-level schematic diagram of a smart contract setup in . The exemplary embodiment 500 includes a counterparty 502, who collects an amount of digital assets 520 based on the result associated with the winning full private key 528 by signing a result transaction 530B that unlocks the counterparty transaction 530A. The exemplary embodiment 500 further includes a member 504 of a group, who collects an allocation (one or more) and a deposit via output 522 by signing an allocation transaction 532B, which unlocks the coordination algorithm transaction 532A as an allocation for providing the winning full private key 528 to the counterparty 502.

[0164] In some embodiments, counterparty 502 and Figure 2 202. In some embodiments, member 504 and Figure 2 518A is a collective digital signature of members 504 so that each member receives its allocation and deposit. In some embodiments, signature 518B is a digital signature of the counterparty and is a digital signature generated using full result signing key 526, which is formed by combining winning full private key 528 with random blinding nonce 516.

[0165] In some embodiments, the winning full private key 528 is Figure 4 The winning complete private key 428 is similar to the winning complete private key 428. In some embodiments, the random blind random number 516 is similar to the winning complete private key 428. Figure 6 612 to obfuscate the contract condition public key. In some embodiments, the full result signing key 526 is the winning full private key 428 combined with the random blind random number 516 using an elliptic curve algorithm, so that the result of the smart contract can be determined by matching the full result signing key 526 with the counterparty contract condition public key in the smart contract in the counterparty transaction 530A locking script.

[0166] In some embodiments, digital asset 520 is an allocation of digital assets previously locked in counterparty transaction 530 based on the winning outcome of the smart contract after verification of signature 518B. In some embodiments, output 522 reflects digital assets previously locked in at least one coordinated algorithmic transaction payable to member 504 after verification of signature 518A. In some embodiments, counterparty transaction 530A is a transaction with Figure 3 330 similar blockchain transactions that include smart contracts, such as Figure 2 Smart contract 206. In some embodiments, the result transaction 530B is a blockchain transaction created to redeem / claim the appropriate digital asset of the counterparty transaction 530A based on the determined outcome of the smart contract.

[0167] In some embodiments, the coordinated algorithmic transaction 532A is Figure 3 The coordination algorithm transaction 332 is similar to the blockchain transaction containing the allocation and deposit 522 of member 504. In some embodiments, the allocation transaction 532B is a blockchain transaction created by member 504 to claim its deposit and allocation. Figure 4 The member that submitted the winning private key share is identifiable as a result of the winning full private key 428 in the virtual chain consensus algorithm. In an embodiment, the virtual chain consensus algorithm identifies the "winning" member (i.e., the member that voted with consensus), and creates a distribution transaction 532B (TxF) by the group, for the group, or by the members of the group to pay the distribution (F) to the winning member, signed by a threshold number (m) of members using GPK (e.g., via a threshold signature scheme). In an embodiment, the member embeds the winning full private key 428 in the metadata of the distribution transaction 532B.

[0168] In some embodiments, as a result of verifying the allocation transaction 532B, the member's deposit is also repaid. In some embodiments, the deposit of member 504 is submitted to a transaction different from the coordination algorithm transaction 532A. In some embodiments of these embodiments, a refund transaction (TxD) is created by the group, for the group, or by the members of the group to refund each member's deposit. In some embodiments, members who break certain virtual chain consensus rules will distribute their deposits among other members. In an embodiment, the allocation transaction and the refund transaction are then broadcast to the blockchain network.

[0169] Using the above use case as an example, where a customer and an insurance company enter into an insurance contract to insure the customer against the possibility of severe frost in his vineyard at any time in April 2018, the member group instantiates a virtual chain on the first day of May 2018 with a block generation time of ΔT = 1 day. In the use case example, h B Set to 5, so that on the fifth day of May, members (e.g. Figure 3 Members 304) submit their signed commitments (e.g., commitment 424) on the fifth day of May. Next ΔT, on the sixth day of May, each member submits a key share (e.g., 426) to reveal its commitment.

[0170] In the example use case, 9 out of every 10 members 504 commit their share of IPK 1 , 1 of the 504 members commits their share of IPK 2 (For example, the dissenting member's information source is incorrect.) In this example, the member group determines that the IPriv 1 , which members pledged a share of the winnings (9) can then be identified. In an embodiment, a threshold group of members (a subset of the winners) can then create and co-sign (signature 518A) a transaction 532 that pays the allocation to the 9 winners and returns all member deposits (fees and deposits 522).

[0171] Counterparty Group

[0172] In one embodiment, the member group reveals the winning public key (IPK w ) corresponding to the winning complete private key 528 (e.g., Figure 4 The winning complete private key 428)(IPriv w In an embodiment, the counterparty 502 (e.g., Figure 3 The counterparty 302) or the "winning" counterparty (y / ies) adds the random blinding nonce 516 to this value to obtain the full resulting signing key 526:

[0173]

[0174] In this embodiment, this value can then be used by the "winning" counterparty(ies) 502 to generate a signature 518B (along with a signature from their own public key) to claim the counterparty transaction 530 corresponding to the winning outcome (e.g., Figure 3 In the exemplary use case, the counterparty obtains the winning full private key 528 (IPriv 1 As a result, the insurance contract is transferred and allocated. In the exemplary use case, each counterparty 502 (eg, each counterparty 302) sends a random blinding random number 516 (R B )Add to IPriv 1 To get the complete result signing key 526 This value may then be used with each counterparty's private key to produce a signature 518B to transfer the corresponding output 522B of the counterparty's transaction 530:

[0175] Output #1: 10DA

[0176]

[0177] Output #2: 2DA

[0178]

[0179] Figure 6 600 for creating smart contracts and coordinating algorithmic transactions according to various embodiments. Part or all of process 600 (or any other process described, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and part or all of process 600 (or any other process described, or variations and / or combinations of these processes) may be implemented as executable instructions that are executed together on one or more processors. Executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash memory medium).

[0180] For example, part or all of process 600 may 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 electronic client device (e.g., Figure 8 The process 600 includes a series of operations in which two or more counterparties agree on the requirements for a smart contract and the parameters for coordinating algorithmic transactions, establish relationships with a group of members to determine the results of the smart contract, and create a smart contract and coordinate algorithmic transactions.

[0181] In some embodiments, at 602, two or more counterparties (e.g., Figure 2 The counterparties 202) determine the parameters of the smart contract. For example, the counterparties can reach an agreement on the number of digital assets each counterparty commits to the smart contract transaction, a set of conditions, and the number of digital assets to be paid after each condition is met and to whom the payment is made. As a more specific example, an agreement is reached between three counterparties (Alice, Bob, and Carol) whereby Alice will commit to the smart contract transaction a number of digital assets X1, Bob will commit to a number of digital assets X2, and Carol will commit to a number of digital assets X3.

[0182] In this example, the set of conditions agreed upon is: if the first condition is met, Alice receives 60% of the committed digital assets of the smart contract, Bob receives 30% of the committed digital assets, and Carol receives the remaining 10% of the committed digital assets. Alternatively, if the second condition is met, Bob and Carol each receive 50% of the committed digital assets (and Alice receives nothing). Alternatively, if the third condition is met, Alice's husband Ted (who has not committed any digital assets to the smart contract) inherits 100% of the digital assets of the smart transaction. As a fourth condition, if the first, second, and third conditions are not met within the specified time frame, Bob, Carol, and Alice may be refunded their committed digital assets.

[0183] In some embodiments, in 604, the counterparty determines the characteristics of the member who will act as the group authority to determine which conditions are met. That is, the counterparty reaches an agreement on the following matters: how much digital assets are provided as a distribution to provide the reason for the member to agree to participate in determining the result, the number of members required for the group, how much each member must submit as a deposit, and the threshold value of the number of matching votes that are eligible as consensus. As an example, Bob, Carol, and Alice agree to provide 10 units of digital assets to each of the maximum 10 members in the group that agree on a specific result of the smart contract, where at least 6 replies from the group must match in order to be considered as a consensus reply. In this example, Bob, Carol, and Alice will require each member in the group to submit 0.1 units of digital assets as collateral.

[0184] In some embodiments, the counterparty determines timing parameters for the coordinated algorithmic transaction, such as the block height and block interval of the virtual chain to which the group members will submit their responses, at 606. For example, if the block height (e.g., the number of blocks in the blockchain) is specified as 5, and the block interval is specified as one day (starting at a specific time), this gives group members five days (1 day x 5) after the start time to submit their decisions; at the fifth block, the group members submit their signed commitments, and the next day, they reveal their commitments.

[0185] In some embodiments, at 608, the counterparty submits a request for group membership, similar to Figure 3 That is, the request may include information such as the definition of the contract conditions, the allocation provided, the number of members sought, the amount of security deposit required from each member, the threshold of matching votes required for a consensus answer, the virtual chain block interval, and the committed block height (h B ). As described above, the request may be submitted / published in any forum or communication medium suitable for submitting / publishing such a request, such as a website forum, bulletin board, peer-to-peer application, or online marketplace.

[0186] In some embodiments, at 610, the group members signal that they agree to participate in determining the outcome of the smart contract. In some embodiments, the signaling of the agreement is accomplished through a forum that is the same or similar to the forum to which the request was submitted / published. In other embodiments, the signaling of the agreement is accomplished through direct communication with one or more counterparties (e.g., via a communication link in the request).

[0187] In some embodiments, in 612, after receiving notification that the group membership requirements have been met, the counterparty generates a random blind random number to obfuscate the results in the smart contract transaction. The random blind random number can be determined in a variety of ways. For example, one counterparty can generate a random blind random number, and the other party or parties can signal approval / agreement with this party. Alternatively, each party can generate a portion of the random blind random number, and all generated portions can be combined according to a mathematical algorithm to form a random blind random number.

[0188] In some embodiments, at 614, the counterparty generates a Figure 3 A public key similar to / agreed upon the contract public key 316 of the present invention. In an embodiment, the public key corresponds to a random blinded nonce (e.g., where the blinded nonce is the private key and the public key is the elliptic curve public key of the blinded nonce). In some embodiments, the contract public key is combined with each result public key generated by the member in 616. As described above, in 616, the group members generate a group public key, and for each contract result, a result public key is generated. As described above, the group public key and the result key may be created using the dealer-free secret sharing protocol described above. Each group member may have a private key share corresponding to the result public key. The private key shares may be generated using the secret sharing protocol described in the present disclosure, where the result public key is generated using Figure 6 The threshold of the number of matching votes specified by the adversary in 604 is used as the number of key shares required to recreate the complete private key (which corresponds to the resulting public key of the winning outcome). In an embodiment, the group member provides the group public key and the resulting public key to the adversary via the communication medium established in 608-12.

[0189] In some embodiments, at least one of the counterparties creates a contract condition public key in 618 by combining each result public key generated by the member group in 616 with the random blinding nonce generated in 612. In this way, the contract condition public key is concealed from the group members in the smart contract transaction created in 620. As described above, in some embodiments, in 620, the smart contract transaction is created and signed by the counterparties, and the smart contract is submitted to the blockchain with the funds (e.g., the amount of digital assets) agreed by each counterparty. Depending on the contract outcome, the smart contract transaction may have a separate UTXO for each amount that can be paid to one or both counterparties.

[0190] Finally, in some embodiments, at 622, the counterparty creates a coordinated algorithmic transaction with Figure 3 The coordination algorithm transaction 332 is similar. In some embodiments, the coordination algorithm transaction may include a deposit from a group member as a UTXO, which can be spent by a signature from the group public key (generated by the member group in 616) after the group member submits its reply or after a timeout. In some embodiments, the coordination algorithm transaction may additionally or alternatively include an allocation provided by a counterparty, which may also be unlocked by a signature using the group public key or by a counterparty signature after a timeout. In some embodiments, the UTXO may be in the same coordination algorithm transaction, while in other embodiments, the UTXO may be in separate transactions. Note that one or more of the operations performed in 602-22 may be performed in various orders and combinations (including in parallel).

[0191] Figure 7 is a schematic diagram showing an example of a process 700 for executing a smart contract according to various embodiments. Part or all of process 700 (or any other process described, or a variation and / or combination of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and part or all of process 700 (or any other process described, or a variation and / or combination of these processes) may be implemented as executable instructions that are executed together on one or more processors. Executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash memory medium).

[0192] For example, part or all of process 700 may 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 electronic client device (e.g., Figure 8The process 700 includes a series of operations in which members submit and reveal their reply key shares, and if there is a threshold of matching replies, a secret result key associated with the consensus reply can be determined, and a full result signing key can be calculated based on the secret result key.

[0193] In some embodiments, after the start time begins, each group member makes a determination regarding the outcome of the smart contract within a specific time frame. The specific time frame may depend on factors such as the virtual chain (e.g. Figure 4 The block height and block interval of the virtual chain 434 of the blockchain. In the above example, the block height is five and the block interval is one day, which gives group members five days to determine their responses.

[0194] At the end of the time period, in some embodiments, at 702, each group member submits a key share corresponding to their own determined answer to a block in the virtual chain, such as Figure 4 As shown in the commitment 424 of . As described above, each group member may submit a reply as a simple hash (e.g., SHA-256) of the group member's share of the specific reply. Note that in some embodiments, not all group members need to submit their replies in the same block. For example, if a group member gets his / her reply on the third day out of five days, the group member may submit their reply in the third block.

[0195] In some embodiments, at 704, in the next block of the virtual chain, the members reveal their commitments, such as Figure 4 This can be confirmed by comparing the revealed hash to the previously submitted hash, as shown in the disclosure 426. In some embodiments, at 706, it is determined whether the number of key shares is sufficient to construct a private key corresponding to a valid resulting private key. If not, then at 708, the counterparty may recover its funds and the member may be refunded its deposit. In this case, because no consensus reply was reached, in some embodiments, the member may not receive an allocation, or may receive a smaller allocation.

[0196] Otherwise, in some embodiments, a winning result private key is generated at 710. The member submitting the winning reply may co-sign the transaction, e.g. Figure 5 The allocation transaction 532B in 712 is created to collect the allocation and return the member deposit in 712. The winning result private key can be provided to the counterparty through the group, and the counterparty can use the winning result private key with the winning result in 714. Figure 6 The random blinding random number determined in 612 is combined to produce the complete result signing key (e.g., Figure 5 The complete result signing key 526).

[0197] In some embodiments, at 716, each counterparty may sign a result transaction similar to result transaction 520B using a signature generated using their own private key and a signature generated using the full result signing key, thereby claiming funds appropriate to the smart contract result, as in Figure 6 As agreed in 602. Note that one or more operations performed in 702-16 may be performed in various orders and combinations (including in parallel).

[0198] Note that in the context of describing the disclosed embodiments, unless otherwise specified, expressions using executable instructions (also referred to as code, applications, agents, etc.) that perform operations that the "instructions" would not normally perform independently (e.g., transfer of data, computation, etc.) indicate that the instructions are being executed by a machine, causing the machine to perform the specified operations.

[0199] Figure 8 800 is a schematic simplified block diagram of a computing device 800 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 800 can be used to implement any of the systems shown and described above. For example, the computing device 800 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Figure 8 As shown, the computing device 800 may include one or more processors 802, which in an embodiment are configured to communicate and be operably coupled to a plurality of peripheral subsystems via a bus subsystem 804. In some embodiments, these peripheral subsystems include a storage subsystem 806 (including a memory subsystem 808 and a file / disk storage subsystem 810), one or more user interface input devices 812, one or more user interface output devices 814, and a network interface subsystem 816. Such a storage subsystem 806 may be used to store information temporarily or long term.

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

[0201] In some embodiments, the user interface input device 812 includes one or more user input devices (e.g., keyboards); pointing devices (e.g., integrated mice, trackballs, touchpads, or graphics tablets); scanners; barcode scanners; touch screens incorporated into displays; audio input devices (e.g., voice recognition systems, microphones); and other types of input devices. In general, 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 (e.g., an audio output device, etc.). In some embodiments, the display subsystem includes a cathode ray tube (CRT), a flat panel device (e.g., a liquid crystal display (LCD)), a light emitting diode (LED) display, or a projector or other display device. In general, 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, facilitating user interaction with an application performing the process and changes therein when such interaction is appropriate.

[0202] In some embodiments, the storage subsystem 806 provides a computer-readable storage medium for storing basic programming and data structures that provide the functions of at least one embodiment of the present disclosure. In some embodiments, when executed by one or more processors, the application program (program, code module, instruction) provides the functions of one or more embodiments of the present disclosure, and in an embodiment, is stored in the storage subsystem 806. These application modules or instructions can be executed by one or more processors 802. In various embodiments, the storage subsystem 806 additionally provides a repository for storing data used according to the present disclosure. In some embodiments, the storage subsystem 806 includes a memory subsystem 808 and a file / disk storage subsystem 810.

[0203] In an embodiment, the memory subsystem 808 includes a plurality of memories, such as a primary 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 may be stored. In some embodiments, the file / disk storage subsystem 810 provides non-transitory permanent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive and associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0204] In some embodiments, computing device 800 includes at least one local clock 824. In some embodiments, local clock 824 is a counter that represents the number of ticks that have occurred since a particular start date, and in some embodiments, is located internal to computing device 800. In various embodiments, local clock 824 is used to synchronize data transfers among processors for computing device 800 and subsystems included therein with specific clock pulses, and can be used to coordinate synchronous operations between computing device 800 and other systems in a data center. In another embodiment, the local clock is a programmable interval timer.

[0205] The computing device 800 may be any of a variety of types, including a portable computer device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 800 may include other devices that may, in some embodiments, be connected to the computing device 800 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). In embodiments, such devices include ports configured to accept fiber optic connectors. Thus, in some embodiments, the device is configured to convert optical signals into electrical signals that are transmitted through a port that connects the device to the computing device 800 for processing. Due to the ever-changing nature of computers and networks, Figure 8 The description of the computing device 800 shown is intended only as a specific example to illustrate a preferred embodiment of the device. Figure 8 Many other configurations of the systems are possible with more or fewer components than those shown.

[0206] Therefore, the description and drawings should be regarded as illustrative rather than restrictive. However, it is obvious that various modifications and changes can be made thereto without departing from the scope of the invention given in the claims. Similarly, other variations also fall within the scope of the present disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments are shown in the drawings and described in detail above. However, it should be understood that there is no intention to limit the present invention to one or more specific forms disclosed, on the contrary, the present invention is intended to cover all modifications, alternative constructions and equivalents that fall within the scope of the invention defined in the appended claims.

[0207] In the context of describing the disclosed embodiments (particularly in the context of the appended claims), the use of the terms "one", "an" and "the" and similar references should be interpreted as covering the singular and the plural, unless otherwise indicated or contradictory in the context. Unless otherwise indicated, the terms "include", "have", "include" and "contain" should be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" should be interpreted as being partially or completely contained therein, attached to or combined together when it is not modified and refers to a physical connection, even if there is an object involved. Unless otherwise indicated, the enumeration of numerical ranges in the present disclosure is only intended to serve as a shorthand method for individually quoting each individual value falling within the range, and each individual value is incorporated into the specification as if it were individually listed. Unless otherwise indicated or contradictory in the context, the use of the term "set" (e.g., "set of items") or "subset" should be interpreted as a non-empty set including one or more members. In addition, unless otherwise indicated or contradictory in the context, the term "subset" of a corresponding set does not necessarily represent a proper subset of the corresponding set, but a subset and a corresponding set may be equal.

[0208] Unless otherwise indicated or clearly contradicted by context, conjunctive language such as phrases of the form "at least one of A, B, and C" should be understood by context to be generally used to indicate that an item, term, etc. can be A or B or C, or any non-empty subset of the set of A and B and C. For example, in the illustrative example of a set with three members, the conjunctive phrase "at least one of A, B, and C" refers to 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 imply that certain embodiments require the presence of at least one of A, at least one of B, and at least one of C.

[0209] The operations of the process may be performed in any suitable order unless otherwise indicated or clearly contradicted by the context. The process (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors by hardware or a combination thereof. In some embodiments, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program that includes a plurality of instructions that may be executed by one or more processors. In some embodiments, the computer-readable storage medium is non-transitory.

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

[0211] Embodiments of the present disclosure are described, including the best modes known to the inventor for implementing the present invention. By reading the foregoing description, variations of these embodiments will become apparent to those skilled in the art. The inventors hope that those skilled in the art will adopt these variations as appropriate, and the inventors hope that the embodiments of the present disclosure can be practiced in a manner different from the specific description. Therefore, the scope of the present disclosure includes all modifications and equivalents of the subject matter listed in the appended claims as allowed by applicable law. In addition, unless the context otherwise indicates or is clearly contradictory, any combination of the above elements in all possible variations thereof is covered by the scope of the present disclosure.

[0212] All references, including publications, patent applications, and patents, cited are herein incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety.

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

[0214] Summarize

[0215] The novel techniques described and suggested in this disclosure extend the functionality of blockchains without undermining the properties of blockchains that ensure the integrity of data stored within blockchain data structures. For example, these techniques improve the field of computing, particularly in the field of digital record verification, by conducting and executing methods for obtaining accurate and objective information about real-world events in a trustless manner on a blockchain, where conditions for verification are defined within blockchain transactions embedded in the record. In addition, the techniques described and suggested in this disclosure improve the execution of smart contracts within a blockchain computer network by utilizing a temporary proof-of-stake blockchain to manage the voting of participants arranged to act as a distributed trusted authority for determining the outcome of the smart contract.

[0216] Furthermore, the techniques described and suggested in this disclosure may have to be rooted in computer technology in order to overcome the problems caused specifically by the risk of manipulating the outcome of a smart contract by obfuscating the smart contract from the participants arranged to determine said outcome, thereby maintaining the privacy of the counterparties and eliminating reasons for participants to collude to subvert the outcome agreement. Furthermore, by employing game theory concepts such as Schelling coordination, anonymous participants may be given reasons to provide accurate information to the protocol.

Claims

1. A computer-implemented method comprising: A condition set between the counterparties is determined, the condition set having a plurality of possible outcomes, the outcomes comprising: a first possible outcome associated with the first allocation of the digital asset; and a second possible outcome associated with a second allocation of the digital asset, the second allocation being different than the first allocation; creating a counterparty transaction, the counterparty transaction comprising the set of conditions encoded as computer-executable instructions and the digital asset as an output; receiving a result from a third party, the result corresponding to the first possible result or the second possible result; creating a resulting transaction to transfer control of the digital asset of the counterparty transaction, the resulting transaction including the outcome as an input; and As a result of verifying the resulting transaction at a node in a blockchain network, the digital asset is allocated to the counterparty according to the first possible outcome or the second possible outcome based at least in part on the outcome.

2. The computer-implemented method of claim 1 , wherein: The third party is a group including a plurality of members.

3. The computer-implemented method of claim 2, wherein: The result is a result of a consensus of responses submitted by the plurality of members.

4. The computer-implemented method of claim 2, further comprising: Sure: the number of members to include the plurality of members; as well as a threshold amount to determine said outcome; as well as The result matches responses submitted by at least a threshold number of members of the plurality of members.

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

6. The computer-implemented method of claim 5, wherein: The key shares are submitted by the plurality of members to a block in the proof-of-stake blockchain.

7. The computer-implemented method of any preceding claim, further comprising: creating at least one coordinated algorithmic transaction associated with a second digital asset; as well as The second digital asset is allocated to the third party as a result of verifying the fee transaction created to transfer control of the second digital asset.

8. The computer-implemented method of claim 7, wherein: The second digital asset includes the deposit portion contributed by the third party.

9. A computer-implemented method according to claim 7 or claim 8, wherein: The second digital asset includes a portion of the fee contributed by the counterparty.

10. The computer-implemented method of claim 9, wherein: The result is a result of a consensus of responses submitted by the plurality of members; The plurality of members includes members whose responses do not match the consensus; as well as Because the reply does not match the consensus of replies, the allocation of the second digital asset prevents the member from receiving the fee portion.

11. A computer-implemented method according to any one of the preceding claims, wherein: The digital assets include a first amount of digital assets contributed by a first party and a second amount of digital assets contributed by a second party.

12. The computer-implemented method of claim 11, wherein: One of the plurality of possible outcomes is associated with a timeout condition of the condition set; as well as Further as a result of verifying the resulting transaction and as a result of the timeout condition occurring, the first amount is refunded to the first party and the second amount is refunded to the second party.

13. A system comprising: processor; as well as A memory comprising executable instructions, which, due to execution by the processor, cause the system to perform the computer-implemented method according to any one of claims 1 to 12.

14. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor of a computer system, cause the computer system to perform the computer-implemented method according to any one of claims 1 to 12.

Images