Execution of smart contract using distributed coordination

Abstract

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

Description

[Technical field]

[0001] The present invention relates generally to blockchain technology, and more particularly to controlling the execution of blockchain based smart contracts that use a combination of dealerless secret sharing and properties of elliptic curve arithmetic and signatures. The present invention further utilizes cryptographic and mathematical techniques to enforce security in connection with electronic transfers made over a blockchain network. The present invention is particularly, but not exclusively, suited for use in smart contracts. [Background technology]

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

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system. The ledger is composed of blocks, which may be composed of transactions and other information. In some examples, a "blockchain transaction" represents an input message that encodes a structured collection of field values ​​that includes data and a set of conditions, where satisfaction of the set of conditions is a necessary condition for the set of fields to be written to the blockchain data structure. For example, in Bitcoin, each transaction is a data structure that encodes the transfer of control of a digital asset between participants of the blockchain system, and includes at least one input and at least one output. In some embodiments, a "digital asset" represents binary data associated with rights to use. Examples of digital assets include Bitcoin, Ether, and Litecoins. In some implementations, transferring 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 includes a hash of the previous block. As a result, blocks are chained together to create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs, known as scripts, that embed inputs and outputs that specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] 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 may utilize a stack. A stack allows values ​​to be pushed onto the top of the stack or popped off the top of the stack. Various operations performed on the stack may result in one or more of the values ​​being pushed onto or popped off the top of the stack. For example, the OP_EQUAL operation pops the top two items off the stack, compares them, and pushes the result (e.g., 1 if equal, 0 if not equal) onto the top of the stack. Other operations performed on the stack, such as OP_PICK, may allow an item to be selected from a position other than the top of the stack. In some scripting languages ​​utilized by some of the embodiments of the present invention, there may be at least two stacks: a main stack and an alternate stack. Some operations of the scripting language can move an item from the top of one stack to the top of the other stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alt stack. It should be noted that stack-based scripting languages ​​may in some cases not be limited to just a strict last-in-first-out (LIFO) approach. For example, a stack-based scripting language may support operations to copy or move the nth item in the stack to the top (e.g., OP_PICK and OP_ROLL, respectively, in Bitcoin). Scripts written in stack-based scripting languages ​​may be pushed onto a logical stack, which may be implemented using any suitable data structure, such as a vector, list, or stack.

[0005] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (mining nodes) perform work to ensure that invalid transactions are rejected from the network and that each transaction is valid. Nodes may have different criteria for validity than other nodes. Since validity in the blockchain is based on consensus, a transaction is considered valid if a majority of nodes agree that the transaction is valid. A software client installed on a node performs this validation work for transactions that reference unspent transaction (UTXO)s by executing UTXO locking and unlocking scripts. A transaction is validated by a node if execution of the locking and unlocking scripts evaluates to TRUE and other validation conditions are met, if applicable. Once a validated transaction has been propagated to other network nodes, a mining node can choose to include the transaction in the blockchain. Thus, for a transaction to be written to the blockchain, it must (i) be verified by the first node that receives the transaction, which if so relays it to other nodes in the network, (ii) be added to a new block constructed by mining nodes, and (iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed once a sufficient number of blocks have been added to the blockchain to make the transaction truly irreversible.

[0006] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to exploit the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such solutions could make their uses more diverse while taking advantage of the benefits of blockchain (e.g. permanence, tamper resistance of the record of events, decentralized processing, etc.).

[0007] This disclosure describes technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program is a machine-readable and executable program that is recorded in a blockchain transaction. A blockchain-based computer program includes rules that can process inputs to generate an outcome and then perform an action dependent on the outcome. One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts." Unlike traditional contracts that may be written in natural language, smart contracts may be computer programs designed to automate the execution of the terms of a machine-readable contract or agreement.

[0008] In embodiments, interactions with specific entities may be encoded in specific steps within a smart contract, but in other cases, the smart contract may be automatic and self-executing, which may be machine-readable and executable. In some examples, automatic execution refers to the execution of a smart contract that is successfully executed to allow the transfer of a UTXO. In such examples, an "entity" capable of effecting the transfer of a UTXO may represent an entity capable of generating an unlock script without being required to provide knowledge of any secret. In other words, an unlock transaction is verifiable without verifying that the source of the data (e.g., the entity that generated the unlock transaction) has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-execution refers to having validating nodes of a blockchain network execute the unlock transaction in accordance with constraints. In some examples, "unlocking" a UTXO (also known as "spending" a UTXO) is used in a technical sense to refer to generating an unlock transaction that references a UTXO and executes as valid.

[0009] A blockchain transaction output includes a lock script and information about the ownership of a digital asset, such as Bitcoin. The lock script, sometimes called an encumbrance, "locks" a digital asset by specifying conditions that must be satisfied in order to transfer the UTXO. For example, a lock script may require that certain data be provided in an unlock script to unlock an associated digital asset. A lock script is also known as a "scriptPubKey" in Bitcoin. Techniques for requiring a party to provide data to unlock a digital asset include embedding a hash of the data in the lock script. However, this creates problems if the data is undetermined (e.g., not known, not fixed) when the lock script is generated.

[0010] The present invention may be described as a verification method / system and / or a control method / system for controlling the verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in the recording of the transaction on the blockchain. This may in some applications result in the exchange or transfer of digital assets over the blockchain. Digital assets may be units of resources managed by the blockchain. Digital assets may be used as cryptocurrency in some embodiments, although in embodiments, digital assets may additionally or alternatively be used in other contexts. The present invention is applicable to the control of digital assets, but may be used in other contexts utilizing blockchain data structures that are technical in nature and do not necessarily involve the transfer of digital assets. Summary of the Invention

[0011] It is therefore desirable to provide a method and system for improving blockchain technology in one or more of the above mentioned aspects. Such an improved solution is now conceived. Thus, according to the present invention there is provided a method as defined in the accompanying claims.

[0012] Thus, there is provided a computer-implemented method comprising: determining a smart contract between counterparties, the set of conditions including: A first possible outcome associated with a first distribution of the digital asset; and a second possible outcome associated with a second distribution of the digital asset that is different from the first distribution; and generating, as an output, a trading partner transaction that includes the set of conditions and the digital asset encoded in computer-executable instructions; receiving an outcome from a third party, the outcome corresponding to the first possible outcome or the second possible outcome; generating an outcome transaction to transfer control of the digital asset of the counterparty transaction, the outcome transaction including the outcome as an input; distributing the digital assets to the counterparties according to the first possible outcome or the second possible outcome as a result of verifying the outcome transaction at a node in a blockchain network and based at least in part on the outcome; It is desirable to provide a computer-implemented method comprising:

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

[0014] An outcome may be the result of a consensus of answers provided by multiple members.

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

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

[0017] Key shares may be committed by multiple members to blocks in a proof-of-stake blockchain.

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

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

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

[0021] The plurality of members may include a member whose answer does not conform to the agreement. Additionally or alternatively, as a result of the answer not conforming to the answer agreement, the distribution of the second digital asset may exclude the member from receiving the distribution portion.

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

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

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

[0025] Thus, there is further provided a computer-implemented method comprising: communicating to a set of trading partners consent to determining an outcome of a set of conditions, the set of conditions including a first possible outcome and a second possible outcome; generating, using a secret sharing scheme, a first private key share corresponding to a first possible outcome and a second private key share corresponding to a second possible outcome; transferring an amount of digital assets to an address associated with the first blockchain transaction; as a result of determining that the outcome is a first possible outcome, disclosing within a specified time frame a first private key share, the first private key share being usable at least in part by the set of counterparties to determine the outcome; generating a signature usable at least in part for a second blockchain transaction to spend an amount of the digital asset associated with the first blockchain transaction based at least in part on the first private key share; and having the second blockchain transaction validated at a node in the blockchain network to gain control over the amount of the digital asset.

[0026] Also provided is a computer-implemented method, comprising: communicating to a set of trading partners consent to determining an outcome of a set of conditions, the set of conditions including a first possible outcome and a second possible outcome; generating, using a secret sharing scheme, a first private key share corresponding to a first possible outcome and a second private key share corresponding to a second possible outcome; transferring an amount of digital assets to an address associated with the first blockchain transaction; as a result of determining that the outcome is a first possible outcome, disclosing within a specified time frame a first private key share, the first private key share being usable at least in part by the set of counterparties to determine the outcome; generating a signature usable at least in part for a second blockchain transaction to unlock an amount of a digital asset associated with the first blockchain transaction, based at least in part on the first private key share; and having the second blockchain transaction validated at a node in the blockchain network.

[0027] 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 a set of trading partners. Additionally or alternatively, the first private key share may be usable 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 usable to determine the outcome by determining that the first private key is associated with the first public key.

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

[0029] Disclosing the first private key share may include disclosing the first private key share in a third blockchain transaction.

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

[0031] The particular time frame may be a second time frame. Additionally or alternatively, disclosing the first private key share may further include committing a cryptographic hash of the first private key share in a commit transaction within a first time frame prior to the second time frame. Additionally or alternatively, validating 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 commit transaction.

[0032] The first blockchain transaction may further include a second amount of the 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 having the second blockchain transaction validated.

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

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

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

[0036] A group public key associated with the group of counterparties may be generated. Additionally or alternatively, the group public key may be provided to the set of counterparties. Additionally or alternatively, the first blockchain transaction may be generated, at least in part, using the group public key. Additionally or alternatively, validating the second blockchain transaction may include determining that a group encryption key is associated with the group public key of the first blockchain transaction.

[0037] The group private key shares may be generated using a secret sharing protocol. Additionally or alternatively, as a result of further determining course of events, a group encryption key may be generated based at least in part on the group private key shares.

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

[0039] Also, a system comprising: A processor; a memory containing executable instructions which, upon execution by a processor, cause the system to perform a method according to any of the claims; It is desirable to provide a system including:

[0040] It is also desirable to provide a non-transitory computer readable storage medium having executable instructions stored thereon which, upon execution by one or more processors of a computer system, cause the computer system to perform a method as claimed in any of the claims.

[0041] The present invention may be described as a method / system for verifying and / or controlling the exchange or transfer of digital assets over a blockchain. In some embodiments, the digital assets are tokens or portions of cryptocurrencies. As described below, the present invention may also be described as a secure method / system for new, improved and advantageous ways of performing operations over a blockchain network or platform. [Brief description of the drawings]

[0042] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Figure 1] 1 illustrates a blockchain environment in which various embodiments may be implemented. [Diagram 2] 1 illustrates an example of a smart contract, according to one embodiment. [Diagram 3] 1 illustrates an example of configuring a smart contract, according to one embodiment. [Figure 4] 1 illustrates an example of coordinating outcome decisions according to one embodiment. [Diagram 5] 1 illustrates an example of smart contract execution, according to one embodiment. [Figure 6] 1 is a flow diagram illustrating an example of generating smart contracts and collaborative algorithmic transactions, according to one embodiment. [Figure 7] 1 is a flow diagram illustrating an example of executing a smart contract, according to one embodiment. [Figure 8] 1 illustrates a computing environment in which various embodiments can be practiced. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] Referring to FIG. 1, FIG. 1 illustrates an example blockchain network 100 associated with a blockchain, according to one embodiment of the disclosure. In this embodiment, the example blockchain network 100 includes blockchain nodes. The blockchain nodes are implemented as peer-to-peer distributed electronic devices, each executing instances of software and / or hardware that perform operations according to a blockchain protocol, i.e., agreed upon at least in part among operators of the nodes 102. In some examples, a "node" represents a peer-to-peer electronic device distributed within the blockchain network. One example of a blockchain protocol is the Bitcoin protocol.

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

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

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

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

[0048] In one embodiment, at least some of the nodes 102 operate as validating nodes that validate transactions as described herein. In some examples, the transaction includes proof of ownership of a digital asset (e.g., a quantity of Bitcoin) and data providing conditions for accepting or transferring ownership / control of the digital asset. In some examples, an "unlock transaction" refers to a blockchain transaction that reassociates (e.g., transfers ownership or control) at least a portion of a digital asset represented 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 includes a UTXO referenced by the unlock transaction. In some embodiments, the transaction includes a "lock script" that blocks the transaction with conditions that must be met before ownership / control can be transferred ("unlocked").

[0049] In some embodiments, a blockchain address is an alphanumeric string associated with an entity to which control of at least a portion of a digital asset is 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, validating the transaction includes verifying one or more conditions specified in the lock script and / or the unlock script. Upon successful validation of the transaction 104, the validating node adds the transaction 104 to the blockchain and distributes it to the nodes 102.

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

[0051] FIG. 2 illustrates an exemplary embodiment 200 of the present invention. As shown in FIG. 2, the exemplary embodiment 200 may include trading partners 202A-02N (C1-Cn) that generate a smart contract 206. The smart contract 206 distributes a digital asset amount 220 that depends on the consensus of answers 214 received from a group of members 204A-04M (p1-pm) that are recruited to objectively determine answers 214 in exchange for a share 222. That is, in an embodiment, the members 204A-04M collectively act as a distributed trusted oracle to provide answers to decision or function problems. In some examples, an "oracle" represents an external agent that provides inputs that can determine an outcome, and oracle-related services include Oraclize, TownCrier, and Orisi services. In some embodiments, members 204A-04M may not have knowledge of the identities of other members of the group or of answers provided by other members of the group. By keeping members anonymous to one another, the possibility of collusion between members is minimized.

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

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

[0054] In one embodiment, the trading partners 202A-02N generate smart contracts 206 to refund any amount of the digital assets deposited by trading partners 202A-02N (negative transaction shares) if not enough members join the group (e.g., within a specified time range). As mentioned above, in some embodiments, the members 204A-04M may be given reason to participate in determining the answer 214 by the shares 222 raised by trading partners 202A-02N. In some embodiments, the members 204A-04M submit answers that match the consensus of the answers and receive their shares 222 or some percentage of the shares 222 (e.g., divided by the number of members). In some of the above embodiments, members who submit non-consensus answers (answers that do not agree with the consensus answer) forfeit their shares 222 or a percentage of the shares 222. In other embodiments, members who submit non-consensus answers receive less shares or a smaller percentage of the shares 222 than are received by members who submit answers that match the consensus.

[0055] In various examples, consensus may represent a simple majority of matching answers, an absolute majority of matching answers, a majority of matching answers submitted before a threshold is reached (e.g., the first three matching answers are considered the consensus answer), or a threshold number of matching answers. In some embodiments, trading partners 202A-02N determine the threshold for determining consensus. In one example, trading partners 202A-02N determine that at least 60% of members 204A-04M must submit matching answers to reach consensus.

[0056] Further, in some embodiments, each of the members commits a deposit (e.g., some amount of digital assets) that gives the members 204A-04M an additional reason to submit a response. That is, in the above embodiment, a member who agrees to participate but breaks the agreement loses his / her committed deposit. In some embodiments, even if the member submits a non-agreement response, the member still receives a refund of the deposit, so that the member at least does not lose digital assets by participating. In determining the amount of the required deposit, the trading partners 202A-02N strike a balance between making the deposit not so large that members 204A-04M will not want to participate at all, but large enough to give the members 204A-04M a reason to provide an accurate response immediately in order to get their deposit refunded.

[0057] In some embodiments, the smart contract 206 is a set of computer-executable instructions (e.g., opcode) designed to automatically transfer control of digital assets according to conditions agreed upon by counterparties 202A-02N. In some embodiments, the smart contract 206 is encoded in a blockchain transaction (e.g., as computer-executable instructions written in a scripting language) and is activated by validation of the blockchain transaction by validating nodes of the blockchain network. In embodiments, the digital assets associated with the blockchain transaction are redeemable (e.g., obtained) upon satisfaction of conditions specified in the smart contract 206. In embodiments, the smart contract 206 is included in the locking script of a validated transaction in the distributed ledger of the blockchain network. In this manner, the executable instructions are made immutable, and successful execution of the locking script containing the smart contract 206 is a prerequisite for transferring the digital assets of the validated transaction.

[0058] Further, as described above, in embodiments, smart contract 206 includes a set of conditions, and unlocking the UTXO of the validated transaction is dependent on the satisfaction of the set of conditions. In one example, smart contract 206 is an insurance contract that distributes digital assets to an insured according to the insurance contract upon the insured providing proof that he or she suffered a loss covered by the insurance contract as an input to the locking script of the blockchain transaction. Further, in some embodiments, smart contract 206 is associated with multiple possible outcomes, and the successful execution of a validation involving smart contract 206 may differ depending on the particular outcome. In the above example, smart contract 206 has at least two possible outcomes: a first possible outcome and a second possible outcome. The first possible outcome is that the insured suffers a covered loss and receives a payment according to the insurance contract. The second possible outcome is that the insured does not suffer a loss, and the insurer keeps the digital assets and the insured's premium payment. In embodiments, execution of computer-executable instructions in the smart contract 206 causes the smart contract 206 to transfer digital assets according to one of the possible outcomes when data evidencing the particular outcome is provided as input to the lock script.

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

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

[0061] As discussed above, in some embodiments, the share 222 is an amount of digital assets provided by one or more of the business partners 202A-N as a share to the members 204A-M for agreeing to participate in providing the answer 214. In some embodiments, the share 222 is provided by a third party.

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

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

[0064] In one embodiment, two separate groups of participants are included: counterparties (Ci) to the main contract, and members (Pi) who contribute to a collaborative algorithm such as the Schelling coordination game. For example, the Schelling coordination game is a coordination game in which two or more individuals are likely to reach the same solution (also called a "focal point" or "Schelling point") without communicating with each other. In this way, the members act as decentralized group oracles that provide accurate inputs to determine the outcome of the main contract. In an embodiment, the counterparties 202A-02N have funds under the control of the contract and collectively provide shares 222 to the members in separate blockchain transactions. However, it is noted that since the collaborative algorithm provides shares to members for submitting the same answers as those submitted by a threshold number of members, the answers are not necessarily correct and may reflect the answers that individual members think other members will submit.

[0065] In embodiments, members commit a refundable security deposit after they submit their answer in a separate blockchain transaction and may earn a share or a portion of a share if their answer matches the consensus answer. If their answer does not match the consensus answer, members may get their deposit back but may not receive their share 222 or a portion of their share 222, or may receive a smaller portion than would be received by a member who submitted the consensus answer.

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

[0067] [Table 1] [Table 1]

[0068] In one embodiment, if a first condition is satisfied, trading partner 202A-02N receives an amount X of the digital asset (DA) specified in the result. In one embodiment, the conditions (conditions) must be clearly specified and mutually exclusive. Furthermore, in one embodiment, for each condition i, the sum of the amounts X i j (j=1,...,n) is equal to the funds due to the contract (minus any transaction mining amount). Additionally, in some embodiments, a deadline condition is specified to specify what should happen to the funds if the protocol dies after a deadline period. In one embodiment, each counterparty C j is the public key PKCj has.

[0069] FIG. 3 illustrates an exemplary embodiment 300 of the present disclosure. Specifically, FIG. 3 illustrates a high-level schematic diagram of a public key establishment process of the exemplary embodiment 300 of the present disclosure. The exemplary embodiment 300 includes a trading partner 302 that has issued a request 308 to a number of members 304 to agree to a contract 306 and provide commitments to the terms in the contract. As can be seen, the request 308 includes a definition of the contract terms (Def), a share to be offered (F), a number of members requested (N), a requested amount of security deposit per member (D), a requested threshold (M), a ghost chain block interval (ΔT), and a commit block height (h). B ), the identity of the counterparty and the distribution of digital assets controlled by the smart contract transaction 330 may not be present / given in the request 308 so as not to influence the votes of the group members.

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

[0071] In the exemplary embodiment 300, the exchange transaction 330 distributes to one or more of the exchanges 302 according to an outcome determined based on an appropriate digital signature corresponding to one of the contract terms public keys 318. Similarly, in the exemplary embodiment 300, the collaborative algorithm transaction 332 transfers the distributions and deposits to the members 304 upon determining (by the collaborative algorithm) the winning outcome.

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

[0073] [Table 2] [Table 2]

[0074] Thus, with the condition that a severe frost occurs, the client receives 10 DA and the insurer receives 2 DA. On the other hand, with the condition that a severe frost does not occur, the client does not receive funds, while the insurer gets back the original 10 DA plus the 2 DA premium, for a total of 12 DA. If neither condition is clearly demonstrated and the deadline condition occurs, the client is refunded the 2 DA premium and the insurer is likewise refunded the 10 DA payment. Note that if there is no ambiguity regarding the event, the deadline condition must be redundant. The deadline exists to prevent funds from being lost in the event that the protocol cannot provide a decision, and in this example, only issues refunds to each party. Also note that in an embodiment, the counterparties agree on the share for the execution of the contract and who will pay this share, and the amount selected for the share may depend on the nature of the security and condition required.

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

[0076] Thus, in the exemplary use case above, an insurer provides a share of 0.2 DA and requests that a group of 10 members submit one of two outcomes: 1. Event #1: "During the month of April 2018, the temperature remains below -4°C for at least 4 consecutive hours anywhere in the Surrey, UK region." 2. Consequence #2: "Any other consequence except condition 1."

[0077] In an exemplary use case, the underwriter and the client agree on a threshold of 6; that is, agreement by at least 6 of the 10 members states which of the above conditions are met. In this example, members are required to submit a deposit of 0.1 DA each. As a result, available members can review the outcome definition and decide whether they want to participate based on their ability to evaluate the conditions (e.g., whether they have access to the required information directly or indirectly (i.e., via the news / internet)), the possible payoff (F), and the required deposit. Members communicate their acceptance to the counterparty and include an authenticated UTXO containing the deposit and a public address for communication.

[0078] A sufficient number (N) of members (P i Once the IPK communicates acceptance of the request, in one embodiment, the trading partners distribute their communication addresses to the group of members. In an embodiment, the members and trading partners can then establish a secure peer-to-peer communication channel with each other. In an embodiment, the group of members executes a dealer-free secret sharing protocol with a threshold M to agree on the contract terms / outcomes (IPK i ), generate a Group Public Key (GPK) and individual public keys (and associated individual key shares) for each of the parties. These public keys are then sent to the trading partners.

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

[0080] In some embodiments, Shamir's Secret Sharing scheme (SSSS) is used for this purpose. SSSS is based on the idea 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 key (a0=f(0)) as the constant term, and the remaining coefficients are chosen randomly. 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 connecting the points is equal to or greater than (t+1), there is enough information to fit a polynomial of degree t to these points, and a0 is disclosed as a secret. In embodiments, this scheme allows the sharing of a single secret key among an arbitrarily large number of members with an arbitrary threshold.

[0081] A standard SSSS can be extended to remove the requirement of a trusted dealer to generate the polynomial and distribute the secret shares. This removes the dependency on a trusted dealer. In this dealer-less SSSS, each member (P i ) are polynomials f of their own random degree t i Generate (x), then f i (x) to each of the other participants P i Each P i Then, by adding up all the received points, we obtain the P iThe secret they share is i =f(i).

[0082] After the secret share is generated, the public key (A) corresponding to the shared secret key (which is not yet known to any of the participants) is calculated by the elliptic curve generator G as follows: i , i=1,...,t, express their public key shares as b i s i × G, where:

number

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

number

[0084] Note that the mathematical properties of Elliptic Curve Cryptography (ECC) are utilized in this disclosure. An ECC operation can be defined by a generator point G of degree p. Once a random private key (a) is chosen (between 1 and p), a public key (A) can be derived by point multiplication as follows: A = a × G

[0085] Furthermore, by the fundamental properties of point multiplication: (a+r)×G=a×G+r×G where r is a nonce. In embodiments, this property can be used to apply random blinding nonces to elliptic curve signatures. Also, in this disclosure, an elliptic curve digital signature algorithm scheme is used in various embodiments to allow a group to jointly sign a transaction with a threshold number of key shares without reconstructing the complete private key.

[0086] Continuing with the exemplary use case above, a group of 10 members jointly runs a dealerless SSSS protocol (with a threshold of 6, as agreed upon above) three times. The group of 10 members shares a group public key (GPK) and two eventual public keys (IPK 1 and IPK 2 As a result, each member j then generates three secret key shares (GPriv j ,IPriv j 1 ,IPriv j 2 ). The group public key also allows members 304 to determine the blockchain address to send their deposits to.

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

[0088] Thus, in this example, trading partner 302 calculates contract terms public key 318, IPK 1 R =IPK 1 +PKR and IPK 2 R =IPK 2 +PKR, and so on. In this method, the public key 314 is generated by dividing the public key 314 by a random blind nonce (R B), making it highly unlikely that an entity other than the trading partner 302, such as a member 304, would be able to link any of the contract terms public keys 318 used in the trading partner transaction 330 to a separate public key 314 generated by the member 304. In this manner, trading partner transactions 330 (and the amounts they contain) remain anonymous, and decisions made by members 304 are insulated from being influenced by knowledge of the details of the contract transaction (e.g., the amount of the digital asset at issue).

[0089] In this example, two transactions are generated by the agreement of the counterparties 302: a counterparty transaction 330 (TxC) and a collaborative algorithm transaction 332 (TxS). In one embodiment, the counterparty transaction 330 has as input the contract funds from the counterparties 302. In one embodiment, the counterparty transaction 330 also has separate outputs (e.g., each with a unique value X i j ). Each of these UTXOs are then distributed to their respective counterparties, subject to the conditions and expiry conditions. It should also be noted that in some instances, outputs may be constructed for payment to third parties that are not members of counterparties 302. In some embodiments, the output constraints are implemented as a 2-of-2 multi-signature function.

[0090] An example of a condition in a merchant transaction 320 for an exemplary use case is shown in Table 3.

[0091] [Table 3] [Table 3]

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

[0093] [Table 4] [Table 4]

[0094] In one embodiment, the collaborative algorithm transaction 332 has as inputs N UTXOs from each of the member depositors and a UTXO constituting the distribution from the counterparty. In some embodiments, there are two UTXOs, one that can be unlocked by a signature from a group public key (GPK) that contains the deposit, and the other that can be unlocked by a signature from the GPK or by a counterparty signature after it has expired, as described in connection with FIG.

[0095] In an embodiment, a threshold number of group members can jointly generate a signature corresponding to a group private key (GPriv) without explicitly determining GPriv. In an embodiment, the signature is indistinguishable from a signature generated directly from GPriv, but in practice, the threshold signature scheme requires the secret key shares (GPriv) to be shared among all members. j In this way, GPriv does not need to be determined at any time, but the corresponding signature can be generated directly from a threshold number of private key shares (GPriv j ) can be determined.

[0096] In the above embodiment, a threshold number of group members agree to transfer (and jointly generate a signature) the first UTXO (the deposit). In the above embodiment, the threshold number of group members can also jointly generate a signature to claim a share, but possibly generate an additional signature corresponding to one of the private keys. In such an embodiment, if the group members cannot reconstruct one of the contingent private keys by reaching a consensus, they cannot claim the share, and the share is returned to the counterparty after it expires.

[0097] In some embodiments, group members share a threshold number of their private key shares (GPpriv jNote that it is possible to check whether a group member ( ) can generate a valid signature corresponding to the (GPK) at any time (e.g., as part of a dealerless secret sharing protocol) without reconstructing the full private key. In such an embodiment, a threshold number of group members may withdraw their deposits at any time, but would forfeit their share if they did not play their part in generating the winning outcome key. An example of inputs and outputs of a collaborative algorithm transaction 332 for an exemplary use case is shown in Table 5.

[0098] [Table 5] [Table 5]

[0099] In one embodiment, the collaborative algorithm transaction 332 is signed by the counterparty 302 providing the share and then sent to the member group to be signed in turn by each of the members 304. In an embodiment, once each input is signed, the collaborative algorithm transaction is broadcast to the blockchain network. In some embodiments, any participant can stop the protocol (or fail to collaborate) and no funds are put at risk until the collaborative algorithm transaction 332 is signed. In one embodiment, once the collaborative algorithm transaction 332 is confirmed on the blockchain, each counterparty then signs their respective input to the counterparty transaction 330 and broadcasts it to the blockchain network. In an embodiment, once the counterparty transaction 330 is confirmed in the blockchain, the counterparty contract may be activated.

[0100] <Contract execution> In one embodiment, after the exchange transaction 330 is approved, the member 304 waits until after the time period specified in the terms / conditions in the request 308 has expired. In one embodiment, the member 304 then records their vote using a separate blockchain, such as a ghost chain. In some examples, a "ghost chain" refers to a proof-of-stake blockchain that is mined by a group of members, where the members' deposits are committed to a collaborative algorithmic transaction via a group key (GPK). That is, unlike proof-of-work based blockchains (e.g., Bitcoin), where transactions are verified by mining nodes that are interested in receiving a share for performing the work, in the ghost chain's proof-of-stake blockchain, participants may express an interest in recovering their deposits (e.g., their "stake" of some amount of their own digital assets) that are generated in the ghost chain.

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

[0102] In some embodiments, the proof-of-stake consensus algorithm utilized by the ghost chain may have properties of regular block times, timestamped blocks, and the possibility of forking. In some embodiments, block shares ("mining amounts") are paid out of shares (F) at a predefined rate. In some embodiments, mining shares may be low due to the negligible cost of verifying blocks. In some embodiments, the collaborative algorithm may operate entirely on the blockchain (i.e., on behalf of the ghost chain) with collaborative algorithm transactions, given sufficient scripting capabilities and blockchain-aware single payment verification (SPV) proofs. One example of such a blockchain platform is Ethereum.

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

[0104] FIG. 4 illustrates an exemplary embodiment 400 of the present disclosure. Specifically, FIG. 4 illustrates a high-level schematic diagram of a smart contract configuration of one embodiment of the present disclosure. As can be seen, FIG. 4 includes transactions 438 that are committed to a ghost chain 434 at intervals. In some embodiments, the ghost chain 434 may be a temporary proof-of-stake sidechain created to record votes in a collaborative algorithm. In some embodiments, the transactions 438 are blockchain transactions embedded in blocks of the ghost chain 434. In some embodiments, each successive block includes a hash 436 that is a cryptographic hash of the previous block in the ghost chain. The hash 436 links the blocks in the ghost chain 434.

[0105] In an embodiment, the commit scheme allows members to pre-commit certain values ​​while keeping the values ​​hidden from others. Once the values ​​are committed, they can be disclosed at a later stage. In this way, members of the group cannot change the values ​​after they commit, but the values ​​are not disclosed to other members, and in this way it can be used as a secure voting protocol.

[0106] Typically, a commit scheme may occur in two phases: a commit phase, where values ​​are selected and committed by members, and a disclosure phase, where values ​​are disclosed by members and acknowledged as consistent with the commit. Typically, a secure commit scheme may rely on random blinding nonces to prevent any information about the committed values ​​from being disclosed after the commit phase. However, in this disclosure, the committed values ​​may already be randomly generated keys. Thus, the commit protocol can be reduced to simply utilizing a secure hash function.

[0107] Thus, in the disclosed anonymous voting protocol, in the commit phase, each member hashes (e.g., with SHA256) the value they wish to commit and discloses the hash to the group, and in the disclose phase, each member then discloses a pre-image of the hash (the committed value) to the group, which verifies each hash. In this way, a group can commit to a vote without knowing in advance how much of the rest of the group is voting.

[0108] Thus, in one embodiment, the block height (h B ), each of the members (e.g., member 304 in FIG. 3) obtains a private key share of the condition / clause public key corresponding to the contract outcome that they have individually determined (the private key share IPriv i j ) in which they submit a commit 424. In one embodiment, each member signs their respective commit 424, and the commit is embedded in the ghost chain. In an embodiment, each commit can be a simple hash (e.g., Secure Hash Algorithm, SHA256) of the respective member's private key share that corresponds to the determined outcome. By hashing the private key shares, each member's vote remains private until the disclosure stage, described below. In this way, the risk of one member's vote influencing another member's vote is minimized.

[0109] In one embodiment, each member then submits their committed key share 426 (IPriv i j ) is then sent to the next block (h B+1). In some embodiments, the key shares 426 held by each group member are shares of a perfect private key determined according to a secret sharing scheme, such as that described above. In such a secret sharing scheme, obtaining at least a threshold number of key shares 426 allows a perfect private key 428 to be arithmetically determined. In one embodiment, when this block is verified, if a threshold number M of members have submitted key shares corresponding to one particular outcome, a winning outcome public key (IPK w ) corresponding to the winner's complete private key 428 (IPriv w ) (e.g., one of the distinct public keys 314 in FIG. 3) can be easily determined and publicly disclosed (where w is the winner's outcome index). In some embodiments, the winner's full private key 428 is a cryptographic key that is the counterpart of the winner's public key (e.g., one of the distinct public keys 314) that was sent to the counterparty and encoded into the smart contract transaction.

[0110] In an exemplary embodiment, the commit height (h B ) is block x-1, and the committed key shares 426 (member j's share of the eventual private key) are disclosed in block x. After disclosure, a threshold number of the winner's private key shares make it possible to determine the winner's full private key 428.

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

[0112] In some embodiments, trading partner 502 is similar to trading partner 202 of Figure 2. In some embodiments, member 504 is similar to member 204 of Figure 2. In some embodiments, signature 518A is a joint digital signature of members 504 under which each member 504 receives their shares and deposits. In some embodiments, signature 518B is a trading partner's digital signature, which is generated using a perfect eventual signing key 526 formed by combining the winner's perfect private key 528 and the random blind nonce 516.

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

[0114] In some embodiments, digital assets 520 are distributions of digital assets previously locked in the trader transaction 530 following the outcome of the winner of the smart contract upon verification of signature 518B. In some embodiments, output 522 reflects digital assets previously locked in at least one collaborative algorithmic transaction payable to member 504 upon verification of signature 518B. In some embodiments, trader transaction 530A is a blockchain transaction similar to trader transaction 330 of FIG. 3, including a smart contract such as smart contract 206 of FIG. 2. In some embodiments, outcome transaction 530B is a blockchain transaction created to redeem / claim the appropriate digital assets of trader transaction 530A following the outcome determined by the smart contract.

[0115] In some embodiments, the collaborative algorithm transaction 532A is a blockchain transaction similar to the collaborative algorithm transaction 332 of FIG. 3, including the distribution and the member's 504 deposit 522. In some embodiments, the distribution transaction 532B is a blockchain transaction generated by the members 504 to claim their deposit and distribution. As a result of determining the winner's full private key 428, the members who commit the winner's private key share can be determined. In one embodiment, the Ghost Chain consensus algorithm identifies the "winning" member (i.e., the member who voted for the consensus), and the distribution transaction 532B (TxF) is generated by the group or by the members of the group to pay the winning member a distribution signed by a threshold number (m) of members using the GPK (e.g., by a threshold signature scheme). In an embodiment, the members embedded the winner's full private key 428 in the metadata of the distribution transaction 532B.

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

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

[0118] In an exemplary use case, nine of the ten members 504 have the IPK 1 commit their share of the IPK 2 In this example, the member group committed their share of the IPriv 1can be reconstructed from a threshold number of (6) commitments, and then identify which members have committed to the winner's shares (9). In one embodiment, the threshold number of members in the group (a subset of the winners) can then generate transaction 532 that pays the shares to the nine winners and returns all member deposits (fees and deposits 522).

[0119] <Business Partner Group> In one embodiment, the winner's public key (IPK w 4) (IPriv w ) is disclosed by the member group. In one embodiment, either trading partner 502 (e.g., trading partner 302 in FIG. 3) or the “winning” trading partner appends a random blind nonce 516 to this value to obtain a perfect-by-flight signing key 526. IPriv w R =IPriv w +R B

[0120] In an embodiment, this value can then be used by the "winning" trading partners 502 to generate a signature 518B (along with a signature from their own public key) to claim the output 522 of the trading partner transaction 530 (e.g., trading partner transaction 530 of FIG. 3) corresponding to the winning outcome. In an exemplary use case, the trading partners use the winner's full private key 528 (IPriv) generated by the collaborative algorithm by determining from member consensus that a severe frost event objectively occurred. 1 ) as a result of which the insurance contract transfers the distribution. In an exemplary use case, each of the trading partners 502 (e.g., each of the trading partners 302) knows the random blind nonce 516 (R B ) IPriv 1 In addition, a full signature key 526 (IPriv 1 R), which can then be used with each counterparty's private key to generate a signature 518B for transferring the corresponding output 522B of the counterparty transaction 530.

number

[0121] 6 is a flow diagram illustrating an example of a process 600 for generating smart contracts and collaborative algorithmic transactions, according to various embodiments. Some or all of the process 600 (or any other processes described, or variations and / or combinations of those processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data and may be implemented as executable instructions executing cooperatively on one or more processors. The 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 medium).

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

[0123] In some embodiments, at 602, two or more counterparties, such as counterparties 202 of FIG. 2, determine parameters of a smart contract. For example, the counterparties may reach an agreement on the amount of digital assets (e.g., Bitcoin) that each of the counterparties will commit to the smart contract transaction, a set of conditions, and the amount of digital assets they will pay and to whom they will pay if each of the conditions is satisfied. As a more specific example, an agreement is reached between three counterparties (Alice, Bob, Carol), where Alice commits amount X1, Bob commits amount X2, and Carol commits amount X3 of the digital assets to the smart contract transaction.

[0124] In this example, the set of conditions agreed upon is: if the first condition is met, Alice receives 60% of the smart contract's committed digital assets, Bob receives 30% of the committed digital assets, and Carol receives 10% of the committed digital assets. Alternatively, if the second condition is met, Bob and Carol each receive 50% of the committed digital assets (Alice gets 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 smart contract's digital assets. As a fourth condition, if the first, second, and third conditions are not met within a specified time frame, Bob, Carol, and Alice may be refunded their committed digital assets.

[0125] In some embodiments, at 604, the counterparties determine the characteristics of a member who will act as a group oracle to determine which conditions have been met. That is, the counterparties reach an agreement on how many digital assets should be contributed as shares to provide a reason for the members to agree to participate in determining the outcome, the number of members needed in the group, how much each member must commit as a security deposit, and the threshold number of matching votes to qualify as a consensus. In one example, Bob, Carol, and Alice agree to contribute 10 units of digital assets to each of up to 10 members of the group who agree to a particular outcome of the smart contract, and at least 6 responses from the group must match to be considered a consensus response. In this example, Bob, Carol, and Alice request that each member of the group commit 0.1 units of digital assets in return.

[0126] In some embodiments, at 606, the counterparties determine the timing parameters of the collaborative algorithmic transaction, such as the block height and block interval of the ghost chain at which the group members commit their answers. For example, the block height (e.g., the number of blocks that should be in the blockchain) is specified to be 5, and the block interval is specified to be 1 day, starting at a particular time. This gives the group members 5 days (1 day x 5) after the start time to submit their decisions. At the 5th block, the group members submit their signed commitments, and the next day they disclose their commitments.

[0127] In some embodiments, at 608, the counterparty submits a request for group membership, which is similar to request 308 of FIG. 3. That is, the request defines the terms of the contract, the share offered, the number of members sought, the amount of security deposit required per member, the required threshold of matching votes for consensus answers, the ghost chain block interval and the commitment block height (h BAs noted above, the request may be submitted / made in any forum or communication medium suitable for submitting / making such a request, such as a website forum, message board, peer-to-peer application, or online marketplace.

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

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

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

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

[0132] Finally, in some embodiments, at 622, the counterparties generate a collaborative algorithm transaction similar to collaborative algorithm transaction 332 of FIG. 3. In some embodiments, the collaborative algorithm transaction includes the deposit from the group member as a UTXO. The deposit may be paid by a signature from a group public key generated by the member group at 616 after the group members submit their answer or after expiration. In some embodiments, the collaborative algorithm transaction may additionally or alternatively include a share provided by the counterparty that may be unlocked by a signature using the group public key or by the counterparty's signature after expiration. In some embodiments, the UTXO may be in the same collaborative algorithm transaction, while in other embodiments, the UTXO may be in a separate transaction. Note that one or more of the operations performed at 602-22 may be performed in various orders and combinations, including in parallel.

[0133] 7 is a flow diagram illustrating an example of a process 700 for executing a smart contract, according to various embodiments. Some or all of the process 700 (or any other processes described, or variations and / or combinations of those processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data and may be implemented as executable instructions executing cooperatively on one or more processors. The 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 medium).

[0134] For example, some or all of process 700 may be performed by one or more computing devices (e.g., by a server at a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable client device such as computing device 800 of FIG. 8). Process 700 includes a series of operations in which members commit and disclose their answer key shares, and if a threshold number of matching answers exist, a private event key associated with the agreed-upon answer can be determined, from which a full event signing key can be calculated.

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

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

[0137] In some embodiments, at the next block in the ghost chain, the member discloses their commitment at 704. This is shown in disclosure 426 of FIG. 4 and can be verified by comparing the hash of the disclosure with the hash of the previous commit. In some embodiments, it is determined at 706 whether the number of key shares is sufficient to constitute a private key corresponding to a valid eventual private key. If not, at 708, the counterparty may withdraw their funds and the member may be refunded their deposit. In such an example, in some embodiments, the member may not receive a share or may receive a smaller share because a consensus answer was not reached.

[0138] Alternatively, in some embodiments, a winner's eventual private key is generated at 710. The members who submitted the winning answers can jointly sign a transaction, such as distribution transaction 532B of FIG. 5, generated to collect distributions and return member deposits at 712. The winner's eventual private key may be provided by the group to a counterparty, who may combine the winner's eventual private key with a random blind nonce at 714 to generate a full eventual signing key (e.g., full eventual signing key 526 of FIG. 5).

[0139] In some embodiments, at 716, each of the counterparties can sign an eventual transaction similar to eventual transaction 520B with a signature generated using their own private key and a signature generated using their full eventual signing key, thereby claiming funds appropriate to the smart contract eventual as agreed upon at 602 of Figure 6. Note that one or more of the operations performed at 702-16 can be performed in various orders and combinations, including in parallel.

[0140] In the context of describing embodiments of the disclosure, unless otherwise noted, use of language relating to executable instructions (also referred to as code, applications, agents, etc.) that perform operations that the "instructions" typically perform without assistance (e.g., transmitting data, performing calculations, etc.) indicates that the instructions are executed by a machine, thereby causing the machine to perform the particular operation.

[0141] FIG. 8 illustrates a simplified block diagram of a computing device 800 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 800 can be used to implement any of the illustrated systems described above. For example, the computing device 800 can be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 8, the computing device 800 can include one or more processors 802 that, in an embodiment, are configured and operably coupled to communicate with a number 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 can be used for temporary or long-term storage of information.

[0142] In some embodiments, bus subsystem 804 provides a mechanism that allows the various components and subsystems of computing device 800 to communicate with each other as intended. Although bus subsystem 804 is shown generally as a single bus, alternative embodiments of the bus subsystem utilize multiple buses. In some embodiments, network interface subsystem 816 provides an interface to other computing devices and networks. Network interface subsystem 816, in some embodiments, serves as an interface to receive data from and transmit data to other systems from computing device 800. In some embodiments, bus subsystem 804 is utilized to communicate data such as details, search terms, etc.

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

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

[0145] In an embodiment, memory subsystem 808 includes multiple 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, file / disk storage subsystem 810 provides non-transient persistent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive with associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0146] In some embodiments, computing device 800 has at least one local clock 824, which in some embodiments represents a counter that represents the number of ticks since a particular starting date and in some embodiments is located internal to computing device 800. In various embodiments, local clock 824 is used to synchronize data transfers within a processor for computing device 800 and the subsystems contained therein with a particular clock pulse, and can be used to coordinate synchronization operations between computing device 800 and other systems in a data center. In another embodiment, the local clock is a programmable internal timer.

[0147] The computing device 800 may be any of a variety of types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 800 may, in some embodiments, include another device that can be connected to the computing device 800 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). In embodiments, such a device includes a port configured to receive a fiber optic connector. Thus, in some embodiments, the device is configured to convert optical signals into electrical signals that are transmitted to the computing device 800 through the port connecting the device for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 800 shown in FIG. 8 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 8.

[0148] The specification and drawings are therefore to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that various modifications and changes thereto may be made without departing from the scope of the invention as set forth in the appended claims. Similarly, other variations are within the scope of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been shown and described above in detail. There is no intention, however, to limit the invention to the particular form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents encompassed within the scope of the invention as defined by the appended claims.

[0149] The terms "a" and "an," "the," and similar references in the context of describing embodiments of the disclosure (particularly in the context of the claims below) are intended to cover both the singular and the plural, unless the context indicates otherwise or clearly contradicts. The terms "comprising," "having," "including," "containing," and the like, should be considered open-ended terms (i.e., meaning "including but not limited to") unless otherwise noted. The term "connected," when unmodified and referring to a physical connection, should be considered to be partially or wholly contained in, attached to, or joined together, even if there is no intermediary. Recitations of ranges of values ​​in this disclosure, unless otherwise noted, merely serve as a shorthand notation for individually referring to each individual value contained in the range, and each separate value should be considered to be incorporated herein as if set forth individually. Use of the term "set" (e.g., "set of items") or "subset" should be considered to be a non-empty set containing one or more members, unless otherwise noted or contradicted by context. Further, unless expressly stated otherwise or contradicted by context, the term "subset" of a corresponding set does not necessarily indicate a proper subset of the corresponding set; a subset and a corresponding set may be equivalent.

[0150] Conjunctive language, such as "at least one of A, B, and C" or "at least one of A, B, and C," is generally understood in the context to be used to indicate that an item, term, etc. may be either A or B or C, or any non-empty subset of the set A, B, and C, unless otherwise noted or clearly contradicted by the context. For example, in the illustrative example of a set having three members, the conjunctive phrase "at least one of A, B, and C" or "at least one of A, B, and C" represents any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such conjunctive language is generally not intended to imply that a particular embodiment requires that there be at least one A, at least one B, and at least one C, respectively.

[0151] The operations of the described processes may be performed in any suitable order unless otherwise noted or clearly contradicted by context. The described processes (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 execute in conjunction on one or more processors, by hardware or a combination thereof. In some embodiments, the code may be stored in a computer readable storage medium, e.g., in the form of a computer program having a plurality of instructions executable by one or more processors. In some embodiments, the computer readable storage medium is non-transitory.

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

[0153] The embodiments of the present disclosure have been described, including the best mode known to the inventors for carrying out the invention. Various of these embodiments will become apparent to those skilled in the art upon reading the foregoing description. The inventors expect those skilled in the art to take advantage of such variations as appropriate, and the inventors intend for the embodiments of the present disclosure to be carried out in ways other than as specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the scope of the present disclosure unless otherwise indicated or otherwise clearly contradicted by the context.

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

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

[0156] <Summary> The novel techniques described and suggested in this disclosure extend the functionality of blockchain without destroying the blockchain's property of ensuring the integrity of data stored in the blockchain data structure. For example, these techniques improve the field of computing by implementing and performing methods for obtaining accurate objective information about real-world events in a trustless manner on the blockchain, especially in the field of digital record verification where the conditions of verification are defined in the blockchain transaction embedded in the record. Furthermore, the techniques described and suggested in this disclosure may improve the execution of smart contracts in a blockchain network by utilizing an ephemeral proof-of-stake blockchain to manage the votes of participants who are made to act as decentralized trusted oracles to determine the outcome of the smart contract.

[0157] Moreover, the techniques described and suggested in this disclosure are necessarily rooted in computer technology to overcome problems that arise specifically with the risk of manipulating the outcome of a smart contract by obfuscating the smart contract from the participants who are supposed to determine the outcome, thereby maintaining counterparty privacy and eliminating the reason for participants to collude to subvert the outcome protocol. Moreover, by utilizing game-theoretic concepts such as Schelling cooperation, anonymous participants may be given an incentive to provide accurate information to the protocol. [Explanation of symbols]

[0158] 100 Blockchain Networks 102 nodes 104 Transactions

Claims

1. 1. A computer-implemented method comprising: determining a set of conditions among trading partners, the set of conditions including: A first possible outcome associated with a first distribution of the digital asset; and a second possible outcome associated with a second distribution of the digital asset that is different from the first distribution; and generating, as an output, a trading partner transaction that includes the set of conditions and the digital asset encoded in computer-executable instructions; receiving an outcome from a third party, the outcome corresponding to the first possible outcome or the second possible outcome; generating an outcome transaction to transfer control of the digital asset of the counterparty transaction, the outcome transaction including the outcome as an input; distributing the digital assets to the counterparties according to the first possible outcome or the second possible outcome as a result of verifying the outcome transaction at a node in a blockchain network and based at least in part on the outcome; 23. A computer-implemented method comprising:

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

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

4. determining a number of members comprising the plurality of members and a threshold number for determining the outcome; The computer-implemented method of claim 2 , wherein the outcome corresponds to answers submitted by at least the threshold number of the plurality of members.

5. 5. The computer-implemented method of claim 4, wherein the outcome 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. 6. The computer-implemented method of claim 5, wherein the key shares are committed by the multiple members to a block in a proof-of-stake blockchain.

7. 7. The computer-implemented method of claim 1, wherein the digital assets include a first amount of the digital assets contributed by a first party and a second amount of the digital assets contributed by a second party.

8. one of the plurality of possible outcomes is associated with a deadline condition of the set of conditions; 8. The computer-implemented method of claim 7, further comprising the step of refunding the first amount to the first party and the second amount to the second party as a result of verifying the eventual transaction and as a result of the occurrence of the deadline condition.

9. 1. A system comprising: A processor; a memory containing executable instructions that, upon execution by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 8; A system including:

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

Images