Blockchain for general computation

Abstract

To provide a method, a system, and a storage medium, for enhancing reliability of a result of a calculation task distribution system.SOLUTION: A block chain network contains: a step of monitoring a calculation task distribution system, and detecting an adverse claim against a provision side character string containing an instruction of a second digital asset referred by an input to a provider transaction related to a hash of a solution against a calculation task provided by a provider side computer system in accordance with a request that designates the related calculation task from a request side computer system and a first digital asset; a step of solving the adverse claim by using the block chain network by selecting one solution from a set of the solutions containing the provision side character string provided to the block chain network; and a step of distributing the digital asset by the first and second digital assets to a party of the calculation task distribution system on the basis of the partial solution.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] The present invention relates generally to distributed systems, and more particularly to a method and system for increasing the reliability of transactions on a distributed system. The present invention is particularly suited for, but not limited to, use in increasing the reliability of computations in a computational task distribution system.

[0002] In this document, the term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers. These forms include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, reference may be made herein to "Bitcoin" as a useful application of the technology described in this disclosure, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the technology described in this disclosure utilizes blockchain implementations regardless of whether cryptocurrency exchange occurs, providing advantages to other cryptocurrencies that have similar constraints on blockchain validation and / or validation of cryptocurrency transactions as Bitcoin.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, which may be composed of transactions and, in one embodiment, contain additional information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured collection of field values ​​that contain data and a set of conditions, where satisfaction of the set of conditions is a prerequisite for writing the set of fields to the blockchain's data structure. Since there is no central processing system to manage the ledger, a blockchain may also be called a peer-to-peer electronic ledger, and transactions in the ledger may be verified using a consensus protocol between nodes in the distributed system. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and each transaction contains at least one input and at least one output. These blocks are chained together, as each block contains a hash of the previous block, creating a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs, and the scripts specify who can access the transaction's outputs and how. In the Bitcoin platform, these scripts may be written using stack-based scripting languages. Note that stack-based scripting languages ​​may refer to programming languages ​​that support a variety of stack-based or stack-oriented execution models and behaviors, but may not be limited to strictly last-in, first-out (LIFO) behaviors. For example, a stack-based scripting language may support an operation that copies or moves the nth item in a stack to the top (e.g., Bitcoin's OP_PICK and OP_ROLL, respectively).Scripts written in stack-based scripting languages ​​can be pushed onto a logical stack, which can be implemented using any suitable data structure, such as a vector, list, or stack.

[0004] As used herein, a "digital asset" may be a unit of resource managed by a blockchain. In some embodiments, such as Bitcoin, resources are not tokenized, so that, for example, there is no identifier of the resource identified on the blockchain, but rather control of the resource is evidenced by the ability to generate valid transactions that are recorded on the blockchain. However, some blockchain implementations may use tokenized resources, so that, for example, resources can be unambiguously identified using information recorded on the blockchain. While digital assets may be used as cryptocurrency in some embodiments, in embodiments, it is contemplated that digital assets may additionally or alternatively be used in other contexts. It is noted that the present invention is applicable to control of digital assets, but may be used in other contexts that are technical in nature and utilize blockchain data structures without necessarily involving the transfer of digital assets. A "digital asset" as used in this disclosure may refer to one or more digital assets. For example, a transaction may include multiple inputs, each of which may represent a different digital asset. In this example, the digital asset to which control is transferred is a collection of multiple digital assets, and the collection itself may be a digital asset. Similarly, a transaction may subdivide and / or combine these multiple inputs to produce one or more outputs, such that, for example, the number of inputs and outputs may vary.

[0005] In order for a transaction to be written to the blockchain, it must be "validated." Validity may be determined by the nodes based on a common set of rules used by the majority of nodes with block-producing capabilities. For example, in the Bitcoin protocol, some network nodes act as miners and work to ensure that each transaction is valid, and invalid transactions are rejected from the network. In some instances, a "miner" is a computational system that works to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on a node performs this validation work on transactions that reference unsettled transaction outputs (UTXOs) by executing the associated lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and certain other conditions are met, the transaction is valid and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it needs to i) be verified by the node that receives the transaction (once a transaction is verified, the node relays it to other nodes in the network); ii) be added to a new block constructed by miners; and iii) be mined (i.e., added to the public ledger of past transactions).

[0006] Recently, digital entrepreneurs have started to explore implementing new systems using both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain. It would be highly advantageous to be able to use the blockchain for automated tasks and processes that are not limited to the cryptocurrency realm. Such a solution would allow the blockchain to take advantage of its advantages (e.g. permanent tamper-proof record of events, distributed processing, etc.) while broadening its uses.

[0007] Blockchains are largely immutable and mostly anonymous. The immutable and mostly anonymous nature of blockchain technology presents many technical challenges in protecting users from malicious behavior. For example, refunds are often unavailable and new technical systems are required to maintain transaction integrity, as transactions are effectively irreversible due to the large number of blocks built on top of the block containing the transaction. Such challenges are made difficult by the decentralized and trustless nature of blockchain technology, i.e., there is no central party that guarantees transaction integrity, which is instead achieved by technical means. It is therefore desirable for blockchain technology to increase the reliability of transactions.

[0008] Trustworthiness challenges may exist in computational task distribution systems, which are services that allow off-chain execution of costly computations. Such computational task distribution systems allow nodes in a network to outsource the execution of an algorithm to another remote node. The result of the algorithm is reported to the node that outsourced the operation of the algorithm. The node receiving the result may not know whether the result is trustworthy. For the receiving node to determine whether the answer is correct, it generally needs to execute the algorithm itself, which defeats the purpose of outsourcing. It is therefore desirable to increase the trust of the results of computational task distribution systems by blockchain technology. Summary of the Invention

[0009] 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 recorded in a blockchain transaction. A blockchain-based computer program is composed of rules that can process inputs to generate results, and actions can be taken depending on those results. Blockchain-based computer programs can be very flexible and complex, where a locking script has access to both the unlocking transaction and previous transactions. One area of ​​current research is the use of blockchain-based computer programs for the implementation of "smart contracts." Unlike traditional contracts that are written in natural language, smart contracts are computer programs designed to automate the execution of the terms of a machine-readable contract or agreement.

[0010] Another area of ​​interest related to blockchain is the use of "tokens" (i.e., "colored coins") to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. The tokens thus act as identifiers that allow the real-world items to be referenced from the blockchain.

[0011] It is thus desirable to provide methods and systems that improve upon blockchain technology in one or more of these aspects.

[0012] Thus, according to the present invention there is provided a method as defined in the accompanying claims. Thus, in accordance with the present invention, there is provided a computer-implemented method (and corresponding system) as defined in the accompanying claims, which may be described as a method for implementing a computational task distribution system using a blockchain network. The computer-implemented method includes: i) monitoring a computational task distribution system to detect a challenge to a proposer string provided by a proposer computer system in response to a request made by a requester computer system, the request specifying a computational task and a first digital asset associated with the request, the proposer string being indicated by a hash of a solution to the computational task, and the proposer string specifying a second digital asset referenced in an input to a proposer transaction associated with the proposer string; and ii) as a result of detecting the challenge, resolving the challenge using the first blockchain network by at least: a) selecting at least one solution from a set of solutions provided to the first blockchain network that includes at least the proposer string; and b) distributing digital assets by the first digital asset and the second digital asset to one or more participants of the computational task distribution system based at least in part on the solution.

[0013] A ghost chain is an ephemeral blockchain. In contrast to traditional blockchains, a ghost chain can be configured to terminate, disappear, and / or expire upon performance or one or more criteria, goals, or specified purposes are met. That is, a ghost chain can be a single-purpose blockchain that ceases operation once its purpose is achieved. A ghost chain can be referred to as a genesis block and can include the first block created for the deployment of the ghost chain or created for the purpose, criteria, or goal of the ghost chain.

[0014] The computer-implemented method may also include working with other nodes of the group to construct a transaction (including the bounty and proposer's deposit as inputs, and the bounty, proposer's deposit, and challenger's deposit as outputs) transferable to the group, and providing the challenger with the transaction to add the challenger's deposit as an input. In one embodiment, the bounty (e.g., the proposer's deposit and the challenger's deposit) are transaction values ​​that act as a signal to another computer system that the work can be performed along with a value indicating the importance of the work relative to the other bounties. In some embodiments, the bounty is a digital asset. In one embodiment, the bounty, when recorded in a first transaction on the blockchain, enables another computer system in the blockchain network to write a second transaction to the blockchain (e.g., by successfully unlocking the lock script of the first transaction as a result of executing the unlock script of the second transaction). The bounty and proposer's deposit may be under the control of the group prior to construction of the challenger transaction. For example, if a challenge is detected within a period of time after a proposer has committed a solution to a request, the bounty and the proposer's escrow may be placed under the exclusive control of the group.

[0015] A proposing string may be selected from the set of solutions based at least in part on a timestamp associated with the proposing string.

[0016] A challenge can specify a hash of a challenger string for a computation task, and the solution set includes the challenger string.

[0017] The computational task distribution system can be implemented as web services associated with a proof-of-work blockchain network.

[0018] Computational task distribution systems can be implemented on proof-of-work blockchain networks.

[0019] The first blockchain network may be a proof-of-stake blockchain network.

[0020] The suggestion string may indicate that the computational task has no solution.

[0021] A challenge may indicate that a computational task has no solution.

[0022] The digital assets may include a deposit provided by the proposer to the first blockchain network.

[0023] Digital assets may be distributed from the first digital asset, the second digital asset, and a third digital asset referenced in an input to the transaction associated with the dispute.

[0024] Resolving the challenge may include executing a set of validation operations corresponding to one or more of the set of solutions.

[0025] Resolving the challenge may include performing an arbitration procedure that includes at least receiving from the proposer a first set of intermediate results of the proposing string with respect to the set of solutions. Additionally or alternatively, resolving the challenge may include receiving from the challenger a second set of intermediate results of the challenging string with respect to the set of solutions. Additionally or alternatively, resolving the challenge may include comparing the first set of intermediate results with the second set of intermediate results to determine a location where the proposing string and the challenging string diverge. Additionally or alternatively, resolving the challenge may include selecting a solution based at least in part on repeating one or more calculations of the first set of intermediate results at the location using the first blockchain and / or repeating one or more calculations of the second set of intermediate results at the location using the first blockchain.

[0026] Resolving the challenge may include at least identifying an incorrect solution of the set of solutions by receiving from the proposer at least a first set of intermediate results of the proposed strings with respect to the set of solutions. Additionally or alternatively, resolving the challenge may include receiving from the challenger a second set of intermediate results of the challenged strings with respect to the set of solutions. Additionally or alternatively, resolving the challenge may include analyzing the first set of intermediate results and the second set of intermediate results to identify locations where the proposed strings and the challenged strings diverge. Additionally or alternatively, resolving the challenge may include identifying an incorrect solution based at least in part on the analysis. In some embodiments of the computer-implemented method, developing a ghost chain to resolve the challenge may include performing tasks associated with the request on the ghost chain to determine a correct solution for one or more proposed strings and / or one or more challenged strings.

[0027] In some embodiments of the computer-implemented method, developing a ghost chain to resolve the objection may include performing a portion of a task in the ghost chain to determine that either the proposer or the objector is in error at an intermediate step of a task related to the request.

[0028] In some embodiments of the computer-implemented method, terminating the ghost chain may include transferring information related to the resolution of the dispute to a proof-of-work blockchain network.

[0029] In some embodiments of the computer-implemented method, terminating the ghost chain may include constructing a terminal block that includes a record of the mining distribution resulting from blocks created during the signing of the final transaction.

[0030] According to the present invention, there may be provided an electronic device including an interface device, a processor coupled to the interface device, and a memory coupled to the processor, the memory storing computer executable instructions that, when executed, configure the processor to perform the methods described herein.

[0031] According to the present invention, a computer-readable storage medium may be provided that includes computer-executable instructions that, when executed, configure a processor to perform the methods described herein. [Brief description of the drawings]

[0032] These and other aspects of the invention will be apparent from and will be elucidated with reference to the embodiments described hereinafter, which embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 is a block diagram of an exemplary blockchain network. [Diagram 2]FIG. 1 is a block diagram of an exemplary electronic device that may function as a node in a blockchain network. [Diagram 3] FIG. 1 is a block diagram of an example environment in which task requests may be generated and solutions may be proposed with respect to a computational task distribution system associated with a blockchain network. [Figure 4] FIG. 1 is a block diagram of an exemplary environment in which a proposed solution may be generated for a computational task distribution system in which blockchain transactions are associated with task requests and which is associated with a blockchain network. [Diagram 5] FIG. 1 is a block diagram of an exemplary environment in which blockchain transactions are associated with challenges and in which a proposed solution may be generated with respect to a computational task distribution system associated with a blockchain network. [Figure 6] FIG. 1 is a block diagram of an exemplary environment in which challenges to proposed solutions may be resolved for a computational task distribution system associated with a blockchain network. [Figure 7] FIG. 1 is a block diagram of an exemplary environment for a computational task distribution system associated with a blockchain network that does not accept challenges to proposed solutions. [Figure 8] FIG. 1 illustrates a first portion of a flowchart of an exemplary process for resolving proposed solutions and challenges to tasks in a computational task distribution system associated with a blockchain network. [Figure 9] FIG. 13 illustrates a second portion of a flowchart of an exemplary process for resolving proposed solutions and challenges to tasks in a computational task distribution system associated with a blockchain network. [Figure 10] 1 is a flowchart of an exemplary process for initiating a congress with respect to a computational task distribution system associated with a blockchain network. [Figure 11]1 is a flowchart of an exemplary process for joining a congress with respect to a computational task distribution system associated with a blockchain network. [Figure 12] 1 is a flowchart of an exemplary process for expropriating digital assets with respect to a computational task distribution system associated with a blockchain network. [Figure 13] 1 is a flowchart of an exemplary process for updating private key share distribution for a computational task distribution system associated with a blockchain network. [Figure 14] 1 is a flowchart of an exemplary process for updating private key share distribution for a computational task distribution system associated with a blockchain network. [Figure 15] 1 is a flowchart of an exemplary process for returning a deposit with respect to a computational task distribution system associated with a blockchain network. [Figure 16] FIG. 1 is a block diagram of an example environment in which the first and second blockchain networks may be implemented in a blockchain network-related computational task distribution system. [Figure 17] 1 is a flowchart of an exemplary process for providing a two-way peg or system for distributing computational tasks associated with a blockchain network. [Figure 18] FIG. 1 is a block diagram of an exemplary environment in which a blockchain and ghost chain may be implemented in a computational task distribution system associated with a blockchain network. [Figure 19] 1 is a flowchart of an exemplary process for requesting completion of a task with respect to a computational task distribution system associated with a blockchain network. [Figure 20] 1 is a flowchart of an example process for proposing a solution to a computational task related to a distributed system associated with a blockchain network. [Figure 21]1 is a flowchart of an example process for challenging a solution to a computational task in a distributed system associated with a blockchain network. [Figure 22] 1 is a flowchart of an example process for arbitrating challengers regarding a solution to a computational task in a computational task distribution system associated with a blockchain network. [Figure 23] FIG. 1 is a block diagram of an exemplary environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] Referring first to FIG. 1, this figure illustrates in block diagram form an example blockchain network 100 associated with a blockchain. The blockchain network may be a public blockchain network, which is a peer-to-peer open membership network that anyone can join without an invitation or the consent of other members. Under which the blockchain network 100 operates, distributed electronic devices running an instance of a blockchain protocol may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol.

[0034] The electronic devices that execute the blockchain protocol and form the nodes 102 of the blockchain network 100 may be various types of devices, including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smart watches, or other electronic devices.

[0035] The nodes 102 of the blockchain network 100 may be coupled to one another using any suitable communication technology, which may include wired and wireless communication technologies. Such communications conform to a protocol associated with the blockchain. For example, the Bitcoin protocol may be used if the blockchain is the Bitcoin blockchain.

[0036] Nodes 102 maintain a global ledger of all transactions on the blockchain. Thus, the global ledger may be a distributed ledger. Each node 102 may store a full or partial copy of the global ledger. In the case of a proof-of-work-certified blockchain, transactions by nodes 102 that affect the global ledger may be verified by other nodes 102 so that the validity of the global ledger is maintained. In the case of a proof-of-work-based blockchain, blocks may also be verified by checking the proof-of-work sent with the block.

[0037] At least some of the nodes 102 act as mining nodes 104 of the blockchain network 100. The blockchain network 100 of FIG. 1 may be a proof-of-work blockchain in which mining nodes 104 perform costly computations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve a cryptographic problem. In Bitcoin, a mining node 104 finds a nonce by hashing the block header with SHA-256 to a number less than a value dictated by the current difficulty. The hashing power required for the proof-of-work algorithm means that a transaction can be considered effectively irreversible after a certain number of blocks have been mined on top of it. A mining node 104 that solves the cryptographic problem creates a new block in the blockchain and broadcasts this new block to the other nodes 102. The other nodes 102 verify that the mining node 104 has actually solved the cryptographic problem and therefore demonstrated sufficient proof-of-work before accepting that the block should be added to the blockchain. Blocks may be added to the blockchain (i.e., a global distributed ledger) by consensus of nodes 102.

[0038] A block created by a mining node 104 may include transactions broadcast to the blockchain by a node 102. For example, a block may include a transaction from an address associated with one node 102 to an address associated with another node 102. In this way, a block serves as a record of transactions from one address to another. A party requesting that a transaction be included in a block proves that it is authorized to initiate a transfer (e.g., in the case of Bitcoin, to transfer Bitcoins) by signing the request with a private key that corresponds to a public key. Only if the request is validly signed can the transfer (transaction) be added to the block.

[0039] In the case of Bitcoin, there is a one-to-one correspondence between public keys and addresses: each public key is associated with a single address. Thus, references herein to transferring digital assets to and from a public key (e.g., transferring to a public key) and to an address associated with that public key refer to general actions.

[0040] Some of the nodes 102 may not operate as mining nodes, but instead participate as validating nodes. Validating transactions may include verifying signatures, checking references to valid UTXOs, etc.

[0041] The example of FIG. 1 includes six nodes 102, two of which participate as mining nodes 104. In practice, the number of nodes 102 or mining nodes 104 may be different. In many blockchain networks, the number of nodes 102 and mining nodes 104 may be much higher than the number shown in FIG. 1.

[0042] As described below, various nodes 102 may cooperate to form a group referred to herein as a congress 106. In the illustrated example, three nodes 102 are shown as participating in the congress 106. However, the actual members of the congress 106 may be much larger.

[0043] A congress 106 may be an open membership group that a node 102 may join upon submitting a sufficient contribution to a pool associated with the congress 106. For example, a node may join a congress by transferring digital assets, such as digital currency (e.g., Bitcoin), tokens, or other contributions or consideration, to an account associated with the congress 106. A node 102 that joins a congress may be a node in a blockchain network, including both mining and non-mining nodes. In at least some applications of congress, nodes that act as congress members monitor the blockchain in the sense that they download (but do not necessarily retain) the complete blockchain. Techniques for joining, leaving, and participating in a congress 106 are discussed in more detail below.

[0044] As described in more detail below, members of the Congress may form a temporary ghost chain network 108. The ghost chain first blockchain network creates and maintains a distributed ledger, referred to herein as a ghost chain. The ghost chain network 108 may be deployed during the execution of the methods described herein to verify authenticity or to arbitrate when a challenge occurs to a proposed side string generated upon request. For example, the ghost chain network 108 may be deployed to verify the integrity of a work product generated by a processor, which may be a work product submitted by a node 102 of the blockchain network 100. For example, the ghost chain network 108 may be deployed to arbitrate algorithm-related disputes generated on the blockchain network 100. Such disputes may arise when the authenticity of a work product generated by a processor of one node is challenged by another node.

[0045] A ghost chain may be an ephemeral blockchain. Unlike a traditional blockchain, a ghost chain may be configured to terminate once it has achieved the purpose described herein. That is, a ghost chain may be a single-purpose blockchain that ceases to exist once its purpose is achieved. A ghost chain contains an initial block, called a genesis block, and may only be created when the ghost chain is deployed for its purpose (e.g., to verify the integrity of a work product generated by a processor).

[0046] The blockchain associated with the blockchain network is a proof-of-work blockchain, while the ghost chain can be a proof-of-stake blockchain. A proof-of-stake based ghost chain network 108 provides an alternative mechanism for achieving consensus. In a proof-of-stake ghost chain, the blockchain can be secured by proof-of-stake instead of proof-of-work. In proof-of-stake, mining nodes 110 of the ghost chain deposit a digital asset and the probability of being selected as a node to mine a block can be proportional to the amount of digital asset they provide as a deposit. A proof-of-stake blockchain system can be used to avoid the computational costs and energy required to mine with a proof-of-work blockchain. Additionally, a proof-of-stake blockchain allows for more frequent and regular block production than a proof-of-work blockchain.

[0047] A plurality of nodes 102 function as mining nodes 110 of the ghost chain network 108. At least some of the mining nodes 110 of the ghost chain network 108 may not function as mining nodes 104 of the blockchain network 100. Because the ghost chain network 108 may be a proof-of-stake blockchain network, the mining nodes 110 deposit digital assets for inclusion as mining nodes. More specifically, the ghost chain mining nodes 110 form a bonded validator set for mining on the ghost chain network 108. These mining nodes 110 may also be members of a congress 106 associated with the blockchain network 100. That is, a node 102 may be part of both the proof-of-work blockchain network 100 and the ghost chain network 108, and function as a mining node 110 in the ghost chain network 108 and as a member of a congress 106 established in the proof-of-work blockchain network 100. These mining nodes 110 join the congress 106 and participate in the congress 106 according to the method described below. The deposit of their digital assets into the congress pool may be done on the proof-of-work blockchain. That is, a congress member deposits their “contribution” into the proof-of-work first blockchain network 100 to become a congress member, and the congress member may function as a mining node 110 on the ghost chain by forming a set aside validation set. The congress 106 may be an open membership group that a node may join upon submitting a sufficient contribution to the pool associated with the congress 106.

[0048] It should be noted that the computer-implemented methods described herein describe a computational marketplace that may be implemented in Bitcoin (or other such blockchains) that lacks a sufficiently rich scripting language, rather than a blockchain that may be implemented in a blockchain that has a sufficiently rich scripting language (i.e., a scripting language that may be used to implement in a blockchain-based computational marketplace). More specifically, a scripting language that may be used to implement in a blockchain-based computational marketplace may be sufficiently rich to perform an adjudicating function between a proposer and a challenger (e.g., determine a winner) when a proposed side string is challenged, as described herein. In the absence of challenge, a computational marketplace may be run from start to finish in Bitcoin (or other similar blockchains) without invoking additional protocols and without using additional features such as congress and ghost chains as described herein. For example, Ethereum has a sufficiently rich scripting language that may be used to implement in a blockchain-based computational marketplace (e.g., a scripting language that is sufficiently rich to perform an adjudicating function between a proposer and a challenger). See, for example, the Truebit description https: / / people.cs.uchicago.edu / ~teutsch / papers / truebit.pdf, which describes such a system.

[0049] The computer-implemented methods described herein describe how to implement a computational marketplace on a more restrictive platform such as Bitcoin (or some other such blockchains) using an additional ephemeral proof-of-stake blockchain (e.g., Ghost Chain) and a Congress protocol for resolving challenges to proposed strings. In the computer-implemented methods described herein, the distribution layer (e.g., Bitcoin) retains the security associated with a restricted scripting language. For example, using the computer-implemented methods described herein (i.e., using Ghost Chain and Congress in conjunction with a network such as Bitcoin), it may become more difficult (and in some embodiments impossible) to create complex blockchain-based computer programs, thereby making their behavior difficult or even impossible to predict. However, such sufficiently rich scripting languages ​​(e.g., Ethereum) may be used to create complex blockchain-based computer programs whose behavior becomes difficult or even impossible to predict with the blockchain protocol. By implementing additional functionality for computational markets on top of protocols such as Bitcoin (e.g., using Ghost Chains and Congress), the security of the underlying blockchain (where the funds reside) may not be affected, thus making it more difficult (and in some embodiments impossible) to create complex blockchain-based computer programs, thereby making their behavior difficult or even impossible to predict.

[0050] 2 illustrates, in block diagram form, an example electronic device 200 that may function as a node (e.g., a node such as one of the nodes 102 shown in connection with FIG. 1 ) in a blockchain network (e.g., a blockchain network such as the blockchain network 100 shown in connection with FIG. 1 ) as described in connection with FIG. 1 and according to one embodiment. The example electronic device 200 may function as a node, such as one of the nodes 102 shown in connection with FIG. 1 , in a blockchain network, such as the blockchain network 100 shown in connection with FIG. 1 . In one embodiment, the blockchain network is a peer-to-peer blockchain network.

[0051] 2 is a block diagram illustrating components of an example electronic device 200 that may function as a node 102 in a peer-to-peer blockchain network 100. The example electronic device 200 may also be referred to as a processing device. The electronic device may take a variety of forms including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smart watch, or another type of format.

[0052] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components may be directly or indirectly coupled to each other and may communicate with each other. For example, the processor 210, the memory 220, and the interface device 230 may communicate with each other via a bus 240. The memory 220 stores computer software programs including machine-readable instructions and data for performing functions described herein. For example, the memory may include processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to implement a protocol associated with the blockchain network 100. For example, the instructions may include instructions for implementing the Bitcoin protocol.

[0053] Memory 220 may store the global ledger of blockchain network 100 or a portion thereof. That is, memory 220 may store all blocks of the blockchain, or a portion of the blocks, such as the most recent block, or a portion of the information in some blocks. Additionally, memory 220 may store the ghost chain or a portion thereof while the ghost chain is being deployed.

[0054] 2, memory 220 is shown as a single block, in reality electronic device 200 may include multiple memory components. The memory components may be of various types including, for example, RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. Additionally, while memory 220 is shown separate from processor 210, processor 210 may include embedded memory.

[0055] As shown in FIG. 2, the processor 210 can include a secure area such as a trusted execution environment (TEE) 250. The TEE 250 can be an isolated execution environment that provides additional security to the electronic device 200, such as isolated execution, integration of trusted applications, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded into the TEE 250 can be protected in terms of confidentiality and integrity. The TEE 250 can be used to protect the integrity and confidentiality of critical resources, such as keys. Since the TEE 250 is implemented at least partially at the hardware level, the instructions and data executed within the TEE 250 can be protected against access and manipulation from the rest of the electronic device 200 and from external parties, such as the owner of the electronic device. The data and computations within the TEE 250 can be secured from parties operating the node 102 that includes the TEE 250.

[0056] The TEE 250 may operate to instantiate enclaves and add pages of memory one at a time, hashing cumulatively. As used herein, an enclave may be an isolated memory region of data within the TEE 250 that is protected from external access. Special instructions may be used to place application code and data within an enclave. Enclaves are typically protected from external access using hardware security. As used herein, and unless otherwise clear from the context, an enclave may be the same as the TEE 250 and may be instantiated within the TEE 250.

[0057] A similar operation of instantiating an enclave can also be performed on a remote machine (which can be the development machine or another machine), which determines and stores the expected hash. The contents of the enclave can then be verified on the remote machine to ensure that it is running an approved algorithm. This verification can be done by comparing hashes. Once the enclave is fully constructed, it can be locked down. It is possible to run code on the TEE 250 and send secrets to this code, but the code cannot be modified. The final hash can be signed by an authentication key, which can be made available to the data owner to verify secrets before sending them to the enclave.

[0058] The TEE 250 may be used to protect the confidentiality and integrity of private key shares related to the Congress public key used by the Congress 106 (as described above with respect to FIG. 1). For example, the TEE 250 may be used to generate and store private key shares. The TEE 250 aims to ensure that members cannot directly obtain information about the private key shares held within the TEE 250 enclave or other private key shares from inter-member or inter-enclave communications. The protocol may also be robust against enclave threshold compromise. Additionally, the TEE 250 allows for remote attestation that may be used by a node 102 to prove to other nodes 102 that the TEE 250 is authentic and is executing approved computer-executable instructions for the protocol implemented by the Congress 106. Remote attestation may be provided by the TEE 250 by executing a particular portion of code and sending a hash of the code inside the enclave, signed with the enclave's internal attestation key.

[0059] The TEE 250 may be used to guarantee the deletion of private key shares when a member of the Congress 106 that previously used the private key shares on the electronic device 200 chooses to leave the Congress. The electronic device 200 may communicate proof of deletion to other Congress members via a remote attestation protocol provided by the TEE 250. Proof of deletion may be required before a member is permitted to withdraw his / her member deposit; that is, the return of the deposit may be conditioned on proof of deletion of the private key shares held within the member's enclave.

[0060] The TEE 250 may be equipped with a secure random number generator, possibly internal to the TEE's enclave, that may be used to generate secret keys, random challenges, or other random data. The TEE 250 may also be configured to read data from and write data to external memory. Such data may be encrypted with a secret key held only within the enclave.

[0061] The TEE 250 can be implemented using a variety of platforms, including the Trusted Platform Module (TPM) and Intel Software Guard Extensions (SGX). For example, SGX supports remote attestation, which allows an enclave to obtain a signed statement containing a hash of a given member, called a quote, from the processor running the particular enclave. A third-party attestation service, such as the Intel Attestation Service (IAS), can attest that these signed statements come from a genuine CPU that complies with the SGX specification.

[0062] The electronic device 200 functions as a node 102 (FIG. 1) in the blockchain network 100 (FIG. 1) and can join or otherwise participate in a congress 106 (FIG. 1). A congress 106 can be formed when a group of digital asset holders pool digital assets, such as digital currencies, tokens, or other contributions or consideration supported by the blockchain network 100.

[0063] A congress 106 may be a permissioned or unauthorized group. That is, any node 102 (FIG. 1) in the blockchain network 100 (FIG. 1) may join the congress 106 (i.e., any node that monitors and stores at least a portion of the information in the blockchain). To join the congress 106, the node 102 transfers one or more digital assets to a digital asset pool associated with the congress 106 (i.e., to a public group address associated with one or more digital assets, which in turn is associated with other members of the congress). This digital asset pool may be referred to as a congress pool. For example, a node 102 may join the congress 106 by transferring (i.e., depositing) such digital assets to an address associated with the congress pool (i.e., a “congress address,” which may also be referred to as a public group address). The digital assets may be placed under the control of a group threshold signature that includes a single public key, referred to as the congress public key. The congress members hold distributively generated private key shares. The number of shares held may be proportional to the amount deposited in the pool.

[0064] Digital assets managed by the Congress 106, including digital assets transferred to a Congress address, may be under the control of a threshold signature scheme. In a threshold signature scheme, a group of members with a combined holding of private key shares exceeding a threshold may be required to generate a valid signature that allows a digital asset to be transferred out of the control of the Congress 106. That is, at least a threshold number of private key shares must be used to generate a valid signature for an outgoing transfer of a digital asset managed by the Congress 106.

[0065] The Congress public key encumbers digital assets deposited in the Congress Pool by members of the Congress 106 in exchange for private key shares, and digital assets deposited (i.e., placed under full, partial, or conditional control of the Congress) in addresses associated with the Congress Pool by members or non-members of the Congress 106 (deposited for reasons other than obtaining private key shares). Non-members or members may deposit digital assets in addresses associated with the Congress for a variety of reasons.

[0066] Since the same Congress public key may restrict both member deposits (i.e., digital assets offered by Congress members in exchange for private key shares) and digital assets offered by members or non-members for other purposes, at least some deposits to Congress-associated addresses may be specially flagged to indicate the type of deposit. For example, a transaction transferring digital assets to a Congress address may include a flag, identifier, or other attribute indicating the nature of the deposit being made. As an example, a transaction transferring digital assets to a Congress address that is not made for the purpose of joining the Congress or increasing the Congress member's stake may include a special identifier indicating that the deposit is being made for another purpose. Such an identifier may be used by the nodes 102 associated with the Congress 106 when managing private key generation. More specifically, a node 102 that escrows digital assets for the purpose of joining a group will be assigned a private key share of the Congress 106 (e.g., as a result of making the escrow of the digital assets), while other nodes 102 that have escrowed digital assets for other purposes (e.g., for transfer to an altchain) may not hold the Congress private key share (i.e., corresponding to the Congress public key).

[0067] The Congress 106 may function as a self-governing group where cooperative behavior is enforced by the threat of confiscation of all or part of the member deposits. With many honest members participating in the cooperative protocol, such digital assets of non-cooperative or malicious members can be confiscated. Furthermore, if a Congress member wishes to leave the Congress 106, the member may withdraw his / her member deposit (i.e., request that the Congress 106 return (return) the member deposit to the member's personal address). However, the withdrawal of funds may only be performed if a number of private key shares exceeding the threshold required to generate a valid digital signature are used by the members of the group (i.e., the Congress) authorizing the withdrawal.

[0068] The threshold signature scheme implemented by the Congress 106 can be of various types. A threshold signature scheme allows for the sharing of signing power among n parties, as long as at least a threshold number of private key shares contribute to the generation of a valid signature. Thus, a valid signature cannot be generated using a subset of the private key shares that is less than the threshold. More specifically, each party controls a share of a private signing key, and the threshold number of key shares must be used to combine the partial signatures to generate a valid signature. A subset of the key shares that is less than the threshold cannot be used to combine the partial signatures to generate a valid signature.

[0069] The threshold signature scheme can be an Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. For example, the ECDSA scheme is described by Ibrahim et al. in “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”, 2003 EIII 46 th The threshold signature scheme may be of the type proposed in Midwest Symposium on Circuits and Systems, 1: 276-280 (2003). This threshold signature scheme is an extension of the digital signature scheme, an elliptic curve cryptography based algorithm, in which t+1 key shares from n key share holders may be required to reconstruct a private key. Using this scheme, valid signatures can be constructed without the need to reconstruct a private key and without one party having to reveal their key shares to the other parties.

[0070] The maximum number of adversaries allowed by this scheme is t, since t+1 key shares can be sufficient to reconstruct the secret. An adversary in Ibrahim et al.'s model can be an entity that bribes a party holding a secret share and gains access to that secret share. Adversaries can be of various types. For example, a Byzantine adversary is an adversary who pretends to participate in the protocol but actually transmits false information. The ECDSA scheme proposed by Ibrahim can be robust against malicious adversaries up to t<=n / 4. This robustness can be increased up to t<=n / 3, but at the cost of increased complexity.

[0071] Ibrahim et al.'s ECDSA scheme can be robust to halting adversaries with t<=n / 3, either by preventing corrupted parties from joining the protocol or by preventing them from joining midstream.

[0072] The ECDSA scheme includes various mechanisms that the nodes 102 can use to identify malicious or non-cooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomials required for Shamir's secret sharing (SSS). SSS can be a form of secret sharing where the secret is split into multiple parts and each participant is provided with their own unique part. These parts can be used to reconstruct the secret. VSS can be used by the nodes 102 to identify malicious nodes 102 or members if inconsistent shares are provided to different nodes 102 or are broadcast to all nodes and secretly sent to the nodes different shares than the blinded shares. Inconsistent shares can be identified by any one of the nodes 102. The sharing of the secret can be made verifiable by including auxiliary information that allows the nodes 102 to verify the shares as consistent.

[0073] The transmission of erroneous shares (i.e., shares that are broadcast and different from the blind shares) to individual nodes can be identified by the nodes intended to receive the shares. The identification of erroneous shares that are privately transmitted to nodes can be made publicly verifiable using techniques of Publicly Verifiable Secret Sharing (PVSS). Such techniques can avoid possible delays in identifying fraudulent senders that may occur if PVSS is not used and the recipient of the erroneous share is offline or is disconnected from a substantial portion of the network when the erroneous share is transmitted.

[0074] Misbehavior, such as providing inconsistent shares to different nodes, may be addressed by the Congress 106 to thwart malicious behavior. For example, if a node 102 (FIG. 1) is identified as a malicious actor by other nodes 102, a threshold (e.g., t+1) number of nodes 102 (i.e., nodes associated with the Congress members) may cooperate to punish the malicious actor. For example, the nodes 102 may take action with respect to digital assets (e.g., digital currency, tokens, or other contributions or consideration) deposited with the Congress by the malicious actor. For example, the Congress may burn the digital currency, tokens, contributions or consideration by transferring them to a return address, or the Congress may confiscate such digital assets by refusing to authorize their return to the malicious actor. Non-misbehaving nodes 102 may also thwart misbehavior by cooperating to exclude the misbehaving node (e.g., by substantially invalidating the key share, e.g., by excluding the node from participation in the congress protocol, or by re-sharing the secret key and not allocating shares to the misbehaving node).

[0075] The ECDSA technique described above can be strengthened using a TEE. For example, the threshold ECDSA signature technique based on Ibrahim et al. assumes a strong adversary, referred to here as a Byzantine adversary. This type of adversary may behave arbitrarily, not only refusing to participate in the signing process and refusing to intervene and stop the participants, but also pretending to participate honestly and sending fraudulent information. However, using a TEE and generating the data used for signing within an enclave in the TEE where the secret private key shares are stored may provide additional security, since the enclave is highly unlikely to be compromised in significant numbers. For example, if each TEE is assigned only one key share, and assuming n is large enough, it can be reasonably expected that the number of TEEs that can be compromised will not reach the robustness threshold against a Byzantine adversary. This allows the protocol to be secure if it is resistant to a small fraction of malicious adversaries relative to the total number of key shares.

[0076] For example, if every node has a TEE, obtaining secrets stored within the enclave can only be achieved with significant effort and expense in obtaining physical access to the node, unless the manufacturer of the TEE has been compromised. Such a manufacturer-level compromise is expected to be manageable. For example, if the manufacturer dishonestly claims that multiple public keys correspond to a genuine TEE, the manufacturer could launch an attack by directly accessing the private key shares. However, such an attack would require a significant number of key shares to allow the manufacturer to create valid signatures without assistance from other nodes. This would mean accumulating a large portion of the total pool of stake, which would be quite expensive. Moreover, carrying out an attack would destroy a large portion of the pool of stake held.

[0077] When using a TEE, it may be useful to consider the robustness of the protocol against “corrupted nodes.” A corrupted node may be a node whose hardware outside the TEE is corrupted, but whose integrity is not compromised. A corrupted node may control what information the enclave receives and does not receive. In particular, a corrupted node may hesitate, i.e., refrain, from participating in the protocol. If the information provided to the protocol needs to be signed by a private key kept secret in the enclave (if the corresponding public key was authenticated during authentication), the private key may be as trustworthy as the enclave itself. Thus, a corrupted node cannot send arbitrary (authenticated) information to the protocol, but may only attempt to interfere by pausing or tricking the enclave into acting corruptly, e.g., by providing old information to the enclave. Thus, in the case of a corrupted node, a successful attack requires the collection of a sufficient number of partial signatures to generate a complete signature. In a TEE, the Ibrahim et al. protocol may be robust against 2t corrupted nodes. Since signatures can be generated for n-2t>=2t+1, a qualifying subset of key shares of size 2t+1<=(n+1) / 2 may be sufficient. Thus, when using a TEE, the threshold of a threshold signature scheme can be set to a number equal to or greater than 50% of the key shares in order to generate valid signatures in the presence of corrupted nodes.

[0078] Other threshold signature schemes can also be used. For example, the threshold signature scheme may be an ECDSA threshold scheme of the type proposed by Goldfeder et al., “Securing Bitcoin Wallets via a New DSA / EDCSA threshold signature scheme”, (2015). This protocol allows t+1 parties to generate valid signatures. As a result, the number of key shares that an adversary must control to generate a valid signature may be equal to the number of key shares that the adversary must possess to reconstruct the private key. This technique can provide an efficient scheme when unanimity is required to generate a valid signature. In the most general case, this scheme imposes space requirements that scale exponentially with the number of congress members, since for any threshold, the entire protocol must be repeated for a possible subset of t+1 players out of n. Thus, a large number of key shares may need to be stored for large values ​​of both n and t. To ease such storage requirements, standard Bitcoin multi-signatures may be combined with threshold signatures. In particular, when multiple signatures are used to lock digital assets, each private key is divided into shares. This approach makes larger congresses more efficient in terms of space requirements. Scaling properties can also be improved by iteratively constructing the scheme for large numbers of participants at multiple levels from small party sizes. For example, the threshold signature scheme may be combined with the approach of Cohen et al., Efficient Multiparty Protocols via Log-Depth Threshold Formulas (2013), Advances in Cryptology - CRYPTO 2013 pp 185-202.

[0079] Other threshold schemes may be used, including non-ECDSA signature schemes. For example, the nodes 110 may implement the congress 106 using a threshold scheme based on the Schnorr scheme.

[0080] Nodes in a blockchain network may implement a congress protocol based on a selected threshold signature scheme. Such nodes may include computer-executable instructions stored in a memory, such as memory 220 described with respect to FIG. 2, that implement the congress protocol. Such instructions, when executed by a processor, such as processor 210 described with respect to FIG. 2, cause a node 102, such as an electronic device 200 of the type described with respect to FIG. 2, to perform one or more methods of the congress protocol. Such methods may include any one or combination of the example processes described herein. Thus, the congress protocol may include one or more of the example processes as described herein. The example processes may be performed by a node in cooperation with other nodes associated with other congress members.

[0081] FIG. 3 illustrates in block diagram form an example environment 300 that may generate task requests and propose solutions for a computational task distribution system associated with a blockchain network as described in connection with FIG. 1 and according to one embodiment. In the example environment 300 illustrated in FIG. 3, a requester 302 having a task 304 initiates 308 a request 310 that includes the task 304 and a proposed distribution 306 for completing the task 304. The task 304 may be a task for solving some problem that requires a certain amount of computational power to solve. In an example, the task 304 is a task to determine whether a certain number is factorizable and, if so, what the factors of the number are. Other examples of tasks may be a task to determine an optimal solution to a problem, a task to determine a solution within a certain predefined threshold, or other such tasks. The task 304 may be a single computationally intensive task, or a combination of multiple tasks that are not individually computationally intensive but may require significant computational power to solve as a whole.

[0082] The proposed share 306 may be a sufficient amount of digital assets to attract an entity to determine a solution to the task (i.e., to attract an entity to consume sufficient computing power to determine a solution). Conceivably, if the proposed share 306 is too low, few (or no) solutions may be provided to the requester and / or the solutions may be of low quality. Conversely, if the proposed share 306 is unreasonably high, too many solutions may be provided to the requester, and while a large number of solutions increases confidence in the answer, an excessively large number of solutions may cause processing difficulties.

[0083] In the exemplary environment 300 shown in FIG. 3, the request 310 may be posted to a computational task distribution system 314, which may include multiple such requests 316. In one embodiment, the computational task distribution system is associated with a blockchain network (e.g., Bitcoin) as described in connection with FIGS. 1 and 2, and is implemented as a web page where requesters post requests for solutions as described herein. In such an embodiment, the computational task distribution system 314 may include one or more web services and / or one or more application programming interfaces (APIs) that can be used, for example, to post requests for solutions, post notices of proposed strings in response to such requests, and / or post notices of challenge to proposed strings. In such an embodiment, a blockchain network is used to enable parties to request solutions, provide solutions, and challenge solutions in a trustless environment (i.e., in an environment without a centralized party, ensuring transaction integrity, and where transaction integrity is achieved using the blockchain network).

[0084] In one embodiment, the blockchain network functions as an append-only public bulletin board (i.e., notices cannot be removed from the bulletin board, only added). This is because once a block in the blockchain is confirmed, all nodes in the blockchain network can see the information contained in the block, and all pieces of information in the block are time-stamped and immutable. By using the blockchain network to request solutions, provide solutions, and challenge solutions as described herein, participants can be assured that requests, solutions, and challenges are immutable. It should be noted that in one embodiment, the computational task distribution system 314 does not require the blockchain network to post requests for solutions to the computational task distribution system 314, post notices of proposed strings in response to such requests, and / or post notices of challenges to proposed strings (e.g., to advertise requests, such as request 310).

[0085] In one embodiment, the computational task distribution system 314 is implemented on a blockchain network (e.g., Bitcoin), such as the network described in connection with Figures 1 and 2. In such an embodiment, the request 310 is mined as a transaction into the blockchain network of the computational task distribution system 314, as described in more detail below. In such an embodiment, the requester 302 may operate as a node in the blockchain network.

[0086] A proposer 318, which may also operate as a node of a blockchain network with which the blockchain network is associated or as a node on which the computational task distribution system 314 is implemented, may monitor 320 the computational task distribution system 314 to identify requests that include shares that the proposer deems sufficient to interest the proposer 318 in consuming computational power to solve the associated task. In the example shown in FIG. 3, the proposer has identified a request 310 to include a proposed share 306 that is sufficient to interest the proposer in generating a solution to task 304 (referred to herein as a “proposed string”). Note that unless expressly stated or made clear by context, a proposed solution from a proposer is a proposed string (which may also be referred to herein simply as a “solution”), and thus, for example, a proposed solution (e.g., a proposed string) from a proposer may be referred to simply as a “proposed solution” or a “proposed string” rather than a “proposed proposed solution” or a “proposed proposed string.”

[0087] Although not shown in FIG. 3, proposer 318 may be one of multiple proposers that propose a solution in hopes of claiming the proposed share. For example, a single task (i.e., a single request) may generate tens, hundreds, thousands, or more proposed strings. In one embodiment, a solution may be selected from multiple proposers based at least in part on a timestamp associated with the solution. For example, in one embodiment, a solution may be selected because it is the first solution received (i.e., the timestamp associated with the solution is earlier than the timestamps of other solutions from other proposers).

[0088] If the proposer 318 is able to generate the proposed string 322 (i.e., in one embodiment, using computation outside the blockchain network), the proposer 318 generates a commit to the proposed string using a hash 332 of the proposed string 322, generates a private key 324 to sign the solution, and generates (328) a commit to the proposed string 330 (including the hash 332 of the proposed string 322) and a public key 334 (corresponding to the private key 324) so ​​that the commit to the proposed string 330 can be securely transmitted (336) to the requester 302. As used herein, the proposed string may be a piece of data generated by the proposer and transmitted to the requester, where the proposed string asserted by the proposer is the output of the computational task being requested. Similarly, as used herein, a challenged string may be a piece of data generated by a challenger and made available to the Congress within a challenge period (described below), where the challenged string asserts that the challenged string is the output of a requested computational task and differs from the proposed string (i.e., presents a different solution).

[0089] As used herein, a solution can be one of several different items, depending on the embodiment. In one embodiment, a solution is a proposed string that survived the challenge period. In one embodiment, a solution is either a proposed string or a challenged string whose corresponding string matches an on-chain computation triggered by a challenge to the solution as described herein. Also, as used herein, a proposed solution can be either a proposed string (if provided by a proposer) or a challenged string (if provided by a challenger in response to a proposed string). Also, as used herein, a commit to a solution can be a hash of the solution (as described above). A commit to a solution can be used in contrast to a commit to a proposed string, which is a hash of a proposed string provided to a requester, and in contrast to a commit to a challenged string, which is a hash of a challenged string provided to a congress.

[0090] Note that a commit to the proposed string using the hash 332 of the proposed string 322 may be referred to herein simply as a “hash”, such as, for example, the hash 332 in a commit to the proposed string 330. In one embodiment, a commit to the proposed string 330 may be sent as a transaction on a blockchain network (as described herein). As used herein, a commit to the proposed string includes the proposed solution (e.g., the proposed string 322).

[0091] Note that the solution commitment 330 does not include the proposed string 322, but only the hash 332 of the proposed string 322, thereby assuring the requester 302 that the proposer does in fact have a solution to the task. In one embodiment, the purpose of sending the commitment to the proposed string 330 is to be able to assure the requester that the string that is later purchased (e.g., as a solution) is the same as the string that is past the challenge period (discussed below) and is therefore a solution to the task. The requester can verify this string by comparing the hash values. However, the proposed string 322 (i.e., a hash pre-image of the commitment to the proposed string) can later be mined into the blockchain network, allowing the proposer 318 to collect the proposed share (i.e., the bounty offered by the requester) when the solution is provided to the requester 302. Using transactions on a blockchain network, both as described herein, a requester cannot access the solution without losing the proposed share 306, and a proposer cannot claim the proposed share until the proposed string 322 is verified. Accordingly, in one embodiment, the proposer provides a deposit 326 that includes a hash 332 of the proposed string 322, which is sufficient to verify the solution in the event of a challenge (as described below) and is returned to the proposer in the absence of a challenge.

[0092] Because the blockchain network facilitates transactions between mutually untrusted parties without the need for a central “escrow” agent while allowing for the fair exchange of solutions for distribution, implementation of the computational task distribution system 314 on a blockchain network prevents bad faith behavior on the part of the requester 302 (e.g., deciding not to recognize a valid solution by not accepting it, or deciding to provide a share of the solution once it is received) and bad faith behavior on the part of the proposer (e.g., proposing a solution that has not verified (i.e., does not pass the test) or not providing a solution once it is received). If a valid proposed string 322 for a task 304 is submitted by the proposer 318 (barring challenge, as described herein), the proposed share 306 may be distributed by the requester 302.

[0093] Not shown in FIG. 3 is one example of when a share is distributed without a valid solution. If task 304 is a task without a valid solution, then "no solution" may be the only valid solution. For example, if the task must determine the prime factorization of the number 51, the solutions are 3 and 17 (i.e., two prime numbers that, when multiplied, equal 51). However, if the task must determine the prime factorization of the number 52 with exactly two factors, there is no solution (2, 2, and 13 could be solutions, but are not valid solutions according to the task). While these may be simple tasks, they illustrate the problem of how a proposer can demonstrate the absence of a solution while still obtaining a share. For fairly difficult tasks, determining that there is no solution may require significant computational power.

[0094] Conceivably, if a proposer indicates "no solution" by providing a hash of the "no solution", the requester can easily recognize the hash and simply ignore the solution (i.e., not complete the transaction, since the requester does not need to complete the transaction to "know" the solution). Because the requester can easily recognize this hash, there may be no reason for the requester to buy the result from the proposer.

[0095] One way to deal with this case may be to require the proposer to concatenate an appropriate flag (e.g., the words "no solution") with some other information. To avoid the situation just described, the information may be some information that is only accessible to those who performed the computation (and found that there is no solution). In one embodiment, the proposer uses at least a portion of the transcript of the computation that results in a no-solution state. A portion of the transcript may be used if the entire transcript is very large, since the hash preimage (e.g., the solution) is mined into the blockchain and the proposer collects the bounty. Thus, the proposer may use a sparse sample of the transcript selected according to an agreed upon formula as a pre-hash solution. This sample may be concatenated with a flag indicating that no solution was found, hashed, and sent to the requester. Note that sending a sample of the transcript without the text flag is not effective, as it may be mistaken for a solution to the computation.

[0096] 4 illustrates in block diagram form an exemplary environment 400 in which blockchain transactions related to task requests and proposed solutions can be generated for a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and in accordance with one embodiment. In the exemplary environment 400 illustrated in FIG. 4, a requester 402 provides 404 a first transaction 406 having as input a proposed distribution amount ("B") and as output a proposed distribution amount plus a proposer's deposit ("D"). The output can be claimed by the proposer after a challenge period (i.e., a period during which other nodes can challenge the proposer's solution, as described herein).

[0097] The first transaction 406 may be provided (408) to a proposer 410, who may add (412) a deposit ("D") to the inputs to generate a final first transaction 414, which may be sent (416) to the computational task distribution system's blockchain 418 (i.e., the blockchain of the blockchain network with which the computational task distribution system is associated or the blockchain of the blockchain network in which the computational task distribution system is implemented). All of the transactions in which the requester 402 provides (404) the first transaction 406, in which the first transaction 406 is provided (408) to the proposer 410, and in which the proposer 410 adds (412) the deposit to the inputs to generate the final first transaction 414 may be executed (e.g., on the Bitcoin blockchain) using blockchain transactions in the blockchain 418, as described herein.

[0098] Figure 5 illustrates in block diagram form an example environment 500 in which blockchain transactions related to a challenge to a proposed solution may be generated for a computational task distribution system associated with a blockchain network as described in connection with Figure 3 and according to one embodiment. In the example environment 500 shown in Figure 5, a challenger 502 challenges a solution provided by a proposer (as described herein) prior to the end of a challenge period.

[0099] In the example shown in FIG. 5, the challenger 502 broadcasts 508 an intent to challenge the solution (i.e., by generating a blockchain transaction indicating the intent to challenge). The intent to challenge, in one embodiment, includes a deposit 506 sufficient to offset the effort of responding to the challenge. In one embodiment, the proposer deposit (as described herein) and the challenger deposit 506 are equal in amount. In one embodiment, the challenger also includes a hash of an alternative solution 504. The alternative solution 504 generated by the challenger may be referred to herein as a “challenge string.” However, as with proposed strings, unless explicitly stated or made clear by context, a solution proposed by a challenger (which may simply be referred to as a "solution") is a challenged string, e.g., a solution proposed by a challenger (e.g., a challenged string) may be referred to simply as a "proposed solution" or "challenged string" rather than a "proposed challenged solution" or a "proposed challenged string." In one embodiment, the challenger 502 may challenge a proposed solution without a hash of an alternative solution 504 if the challenger provides a deposit 506.

[0100] In one embodiment, in response to the challenge, a transaction 514 may be generated (512) by the Congress 510, which includes as input the output of the previous transaction (the request transaction) ("B+D") and as output the previous share plus the proposer's deposit and the challenger's deposit ("B+D+D"). Similar to the first transaction, the second transaction may be provided (516) to the challenger 502, who may add the challenger's deposit 506 to the input to generate (518) an updated transaction 520, which may be mined (522) into the blockchain 524. As discussed above, each transaction shown in FIG. 5 may be implemented using a blockchain. Although not shown in FIG. 5, the challenger 502 may be one of multiple challengers (i.e., each proposed string may also generate tens, hundreds, thousands, or more challenged strings).

[0101] FIG. 6 illustrates in block diagram form an example environment 600 in which a challenge to a proposed solution may be resolved for a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and according to one embodiment. In the example environment 600 illustrated in FIG. 6, a congress 602 instantiates a ghost chain 604 (described herein) starting from information in a source block 608 of a blockchain 606. The source block 608 may also be referred to herein as the block where the challenge arose (e.g., the block of the challenge 1806 described in connection with block FIG. 18). After the challenge is resolved by the ghost chain using the methods described herein, the congress 602 creates (610) one or more transactions 612 for distributing the proposed distribution ("B") plus the escrow ("D") to one or more parties, as described herein. The one or more transactions 612 may then be mined (614) into the blockchain 606 at a current block 616.

[0102] In a first example of how to create one or more transactions 612 to transfer a proposed distribution ("B") plus an additional deposit ("D") to one or more participants, in the absence of a proposed solution, the requester can reuse the UTXO of the original transaction ("B") since there is no ghost chain instantiated to adjudicate challenges. In one embodiment, in the absence of a proposed solution, there is no deposit and the bounty ("B") is never added to the input of the proposer string.

[0103] In a second example of how to create one or more transactions 612 to send the proposed distribution ("B") plus an additional deposit ("D") to one or more participants, there may be a proposed solution, but no ghost chain instantiated to determine the challenge if there are no challengers. Thus, the proposer can claim the UTXO ("B") of the original transaction if the solution is accepted by the requester and the proposer can also recover the proposer's deposit ("D"), reducing the cost to verify the solution. In one embodiment, the cost used to verify the solution is zero if there are no challengers, and the proposer can claim the UTXO ("B") of the original transaction if the solution is accepted by the requester and the proposer can also recover the entire proposer's deposit ("D"). Conversely, the requester can claim the UTXO ("B") of the original transaction if the solution is not accepted by the requester and the proposer can recover the proposer's deposit ("D"). In one embodiment, a proposer may claim funds using a solution after the challenge period if the hash of the solution used to claim the funds is the same as the hash of the solution in the solution commitment, as described above.

[0104] In one embodiment, a proposer may reject a proposed solution by challenging the solution (i.e., by acting as a challenger to the proposed proposer string), as described above.

[0105] In a third example of how to create one or more transactions 612 to send a proposed distribution ("B") plus an additional deposit ("D") to one or more participants, if there is one challenger and a ghost chain 604 has been instantiated to adjudicate the challenge, if the proposer "wins" the challenge, the proposer can claim the UTXO of the original transaction ("B"), the proposer can also recover the proposer's deposit ("D") minus the cost of verifying the solution, and the challenger can recover the challenger's deposit ("D") minus the cost of challenging the solution. Conversely, if the challenger “wins” the challenge, the challenger can claim the UTXO of the original transaction (“B”), the proposer can recover the proposer’s deposit (“D”) minus the cost of verifying the solution, and the challenger can recover the challenger’s deposit (“D”) minus the cost of challenging the solution. In one embodiment, the loser of the challenge (e.g., the proposer or the challenger) remits the entire cost of the challenge. In one embodiment, both parties to the challenge (e.g., the proposer and the challenger) split the cost of the challenge equally. In one embodiment, both parties to the challenge (e.g., the proposer and the challenger) similarly split the cost of verification equally. As may be appreciated, the examples of how to create one or more transactions 612 to transfer the proposed distribution ("B") plus additional deposit ("D") to one or more participants are merely illustrative, and thus other examples of how to create one or more transactions 612 to transfer the proposed distribution ("B") plus additional deposit ("D") to one or more participants may be considered within the scope of this disclosure.

[0106] It should be noted that the arbitration procedure may be used to significantly reduce the length of the computation to be performed in the ghost chain. In one embodiment, arbitration may be performed without the need to rerun the entire computation. In such an embodiment, the arbitration protocol requires that the proposer and challenger provide intermediate results of the computation that led to their final answer. Since the inputs of the computation are the same (posted by the requester) and the outputs are different (the proposer and challenger reached different answers), there should be at least one transition between two intermediate values ​​where the proposer's and challenger's computations diverge. Such a "transition point" can be identified using a binary search on the two lists of values ​​(i.e., the difference between the two lists of values). The number of operations required to perform this search is on the order of the base 2 logarithm (i.e., log2) of the lengths of the two lists. For example, if the computation of the two lists has 1024 elements, the number of operations required to perform the search for the transition is ln1024, or 10.

[0107] Once the intermediate step where the two calculations diverge is determined (i.e., if a transition point is found), the ghost chain can be used to recalculate that single transition and arbitrate between the two proposals. Note that unlike arbitration by rerunning the calculation on-chain (e.g., the main chain), a binary search approach as described herein may be able to eliminate one party as incorrect but not be able to confirm the correctness of the other party. Thus, in one embodiment, the solutions of parties not eliminated by the binary search may be subject to another challenge period.

[0108] FIG. 7 illustrates in block diagram form an example environment 700 for a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and according to one embodiment, where no challenge to the proposed solution is received. In the example environment 700 illustrated in FIG. 7, a proposer 702 receives (704) a distribution 706 including a proposed distribution 708 ("B") and a proposer's deposit 710 ("D") in a transaction 712 generated from a blockchain 714. In one embodiment, the distribution 706 includes the proposed distribution 708 ("B") and the proposer's deposit 710 ("D") less the costs used to verify the proposer's 702 solution. In one embodiment, where there was no challenge, the costs used to verify the proposer's 702 solution are zero, and the distribution 706 includes the proposed distribution 708 ("B") and all of the proposer's deposits 710 ("D").

[0109] 8 illustrates in flow chart form a first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task in the context of a computational task distribution system associated with a blockchain network as described in conjunction with FIG. 3 and according to one embodiment. The first portion 800 of the exemplary process for resolving proposed solutions and challenges to a task in the context of a computational task distribution system associated with a blockchain network may be performed by a node, such as one of the nodes 102 described in conjunction with FIG. 1 of a blockchain network, such as the blockchain network 100 described in conjunction with FIG. 1. That is, a node, such as one of the nodes 102 described in conjunction with FIG. 1, may perform the first portion 800 of the exemplary process for resolving proposed solutions and challenges to a task in the context of a computational task distribution system associated with a blockchain network as described in conjunction with FIG. 8.

[0110] In a first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task in relation to a computational task distribution system associated with a blockchain network, a requestor requests completion of a task including an associated share of the solution as described herein.

[0111] In a first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task in relation to a computational task distribution system associated with a blockchain network, in step 804, the proposer contacts the requester with a public key and a hash of the proposed solution. Although not shown in FIG. 8, prior to step 804, the proposer received the task as described herein, determined that the associated share is sufficient, generated a solution, and generated all hashes of the solution. In one embodiment, the proposer contacts the requester with a public key and a hash of the proposed solution using a secondary secure channel. In one embodiment, the proposer contacts the requester with a public key and a hash of the proposed solution using a blockchain implementing the computational task distribution system. In one embodiment, there are multiple proposers with solutions.

[0112] In a first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task in relation to a computational task distribution system associated with a blockchain network, in step 806, a requester constructs a first transaction that includes the associated distribution as an input and the associated distribution plus a deposit as an output, which may be unlocked at any time by the proposer after the challenge period or by a congress as described herein.

[0113] In a first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task in relation to a computational task distribution system associated with a blockchain network, in step 808, the requester sends a first transaction to a proposer, as described herein, so that the proposer can add the proposer's deposit to the transaction's input, thus providing the proposer an opportunity to invest in the task. Having the proposer add a deposit to the transaction inhibits the proposer from flooding the requester with erroneous solutions.

[0114] In a first portion 800 of an exemplary process for proposing solutions to and resolving challenges to a task in relation to a computational task distribution system associated with a blockchain network, in step 810, a proposer adds their deposit as input to a first transaction and broadcasts the first transaction to the blockchain as described herein.

[0115] In step 812 of the first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task with respect to a computational task distribution system associated with a blockchain network, it may be determined whether a challenge has been received. In one embodiment, a challenge may be received from another node (e.g., a challenger) as described herein. In one embodiment, a challenge is generated by a challenger by mining a transaction into the blockchain as described above, and thus received by nodes in the blockchain, including the requester and the proposer. In one embodiment, multiple challenges are received for each proposed solution. In one embodiment, the computational task distribution system is an off-chain system (e.g., a web service) where tasks are listed, notices of proposed solutions are posted, and challenges to those proposed solutions are posted. In such an embodiment, a blockchain associated with the computational task distribution system is used to provide solutions, provide share of the solutions, and manage challenges (e.g., via a ghost chain).

[0116] If it is determined in step 812 that a challenge has been received, the first portion 800 of the exemplary process for resolving proposed solutions and challenges to tasks in a computational task distribution system associated with a blockchain network continues with step 902 of a second portion 900 of the exemplary process for resolving proposed solutions and challenges to tasks in a computational task distribution system associated with a blockchain network.

[0117] If no challenge is determined to have been received in step 812, then in step 814 of the first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task for a computational task distribution system associated with a blockchain network, it may be determined whether the challenge period has expired. In one embodiment, the challenge period is set by the requester. In one embodiment, the challenge period is set by the computational task distribution system. In one embodiment, the challenge period is determined based at least in part on the period required to mine a number of blocks. For example, a blockchain network may be mined at a rate of once every 10 minutes (e.g., the Bitcoin network). In such an example, the challenge period may be based on the time required to mine 288 blocks (e.g., 48 hours, or 6 blocks per hour for approximately 2 days).

[0118] If, at step 814, it is determined that the challenge period has not expired, the first portion 800 of the exemplary process for resolving challenges and proposed solutions to tasks in a computational task distribution system associated with a blockchain network continues with determining, at step 812, whether a challenge has been received.

[0119] If, in step 814, it is determined that the challenge period has expired, then, in step 816 of a first portion 800 of an exemplary process for resolving proposed solutions and challenges to a task for a computational task distribution system associated with a blockchain network, the proposer claims the proposer's deposit for the unchallenged actual solution in addition to the bounty, as described herein.

[0120] It should be noted that one or more of the operations performed in the first portion 800 of the example process shown in FIG. 8 may be performed in various orders and combinations, including in parallel.

[0121] 9 illustrates in flow chart form a second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task in the context of a computational task distribution system associated with a blockchain network as described in conjunction with FIG. 3 and according to one embodiment. The second portion 900 of the exemplary process for resolving proposed solutions and challenges to a task in the context of a computational task distribution system associated with a blockchain network may be performed by a node, such as one of the nodes 102 described in conjunction with FIG. 1 of a blockchain network, such as the blockchain network 100 described in conjunction with FIG. 1. That is, a node, such as one of the nodes 102 described in conjunction with FIG. 1, may perform the second portion 900 of the exemplary process for resolving proposed solutions and challenges to a task in the context of a computational task distribution system associated with a blockchain network as described in conjunction with FIG. 9.

[0122] In a second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task in relation to a computational task distribution system associated with a blockchain network, a challenge may be received, as described herein.

[0123] In step 904 of a second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task in a computational task distribution system associated with a blockchain network, the congress constructs a second transaction including the relevant share plus a deposit as an input and the relevant share plus 2x the deposit as an output, which can be unlocked by the congress at any time. In step 904, the relevant share includes both the deposit from the proposer and the deposit from the challenger, and therefore includes 2x the deposit. However, in step 904, the deposit from the challenger has not yet been added to the input of the transaction.

[0124] In step 906 of a second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task with respect to a computational task distribution system associated with a blockchain network, the congress sends the second transaction to a depositor (e.g., the challenger) so that the challenger's deposit can be added to the input of the transaction, as described herein.

[0125] In step 908 of a second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task with respect to a computational task distribution system associated with a blockchain network, the depositor adds the second deposit as an input to a second transaction and broadcasts the second transaction to the blockchain as described herein.

[0126] In step 910 of a second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task in relation to a computational task distribution system associated with a blockchain network, the Congress creates a ghost chain to resolve the challenge using the methods described herein.

[0127] In step 912 of the second portion 900 of the exemplary process for resolving proposed solutions and challenges to a task for a computational task distribution system associated with a blockchain network, the congress resolves the challenges and provides an actual solution according to the resolution of the challenges (i.e., from one or more proposed strings and / or one or more challenged strings). In step 912, the congress resolves the challenges using a ghost chain, as described herein. In one embodiment, the congress resolves the challenges using an on-chain computation method. In one embodiment, the congress resolves the challenges using a binary search technique, as described herein.

[0128] In step 914 of a second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task with respect to a computational task distribution system associated with a blockchain network, the congress distributes the output of the second transaction using one or more transactions according to the resolution and resolution costs, as described herein.

[0129] In step 916 of the second portion 900 of an exemplary process for resolving proposed solutions and challenges to a task in relation to a computational task distribution system associated with a blockchain network, the congress terminates the ghost chain. In one embodiment, the terminated ghost chain (e.g., a terminal block of the ghost chain) is used as the starting block of a subsequent ghost chain, as described herein.

[0130] In one embodiment, there are one or more solutions in a set of solutions that includes the proposed string and the challenged string. In one embodiment, for the computational task distribution system associated with a blockchain network described in connection with FIG. 8 and FIG. 9, an exemplary process for resolving proposed solutions and challenges to a task includes resolving the challenge by at least selecting one solution from a set of solutions provided to the first blockchain network using a first blockchain network, the set of solutions including at least the proposed string. In one embodiment, selecting one solution from the set of solutions includes selecting a correct solution based at least in part on one or more selection criteria. In one embodiment, selecting one solution from the set of solutions includes eliminating one or more incorrect solutions based at least in part on one or more selection criteria. In one embodiment, an algorithm such as a binary search algorithm is used to eliminate one or more incorrect solutions until one solution is selected from the set of solutions.

[0131] In an embodiment in which multiple solutions are received with the same hash (e.g., where each proposed string has the same hash value), with respect to the computational task distribution system associated with a blockchain network described in connection with Figures 8 and 9, an exemplary process for resolving proposed solutions and challenges to a task includes selecting one solution from the set of solutions based at least in part on a timestamp associated with the proposed string (i.e., the timestamp may be used to select one solution from multiple solutions having the same hash value, e.g., the first received solution may be selected).

[0132] It should be noted that one or more of the operations performed in the second portion 900 of the example process shown in FIG. 9 may be performed in various orders and combinations, including in parallel.

[0133] FIG. 10 illustrates in flow chart form an example process 1000 for initiating a congress with respect to a computational task distribution system associated with a blockchain network as described with respect to FIG. 3 and according to one embodiment. The example process 1000 may be performed by a node, such as one of the nodes 102 described with respect to FIG. 1, of a blockchain network, such as the blockchain network 100 described with respect to FIG. 1. That is, a node, such as one of the nodes 102 described with respect to FIG. 1, may perform the example process 1000 for initiating a congress with respect to a computational task distribution system associated with a blockchain network as described with respect to FIG. 10. In one embodiment, the process 1000 is performed by an initially trusted party to set up the congress.

[0134] Process 1000 includes, at step 1002, providing a congress public key. The congress public key may be provided to other nodes to allow other nodes to escrow the congress public key if they wish to join the congress, i.e., other nodes may transfer a token to an address associated with the congress public key in order to join the congress.

[0135] In step 1004, the node executing process 1000 may allow distribution of the public key until one or more conditions are met. For example, the node may allow distribution of the public key for a determined period of time or for a determined number of blocks. After the conditions are met (e.g., after the end of the period of time or after mining that number of blocks), in step 1006, the node executing process 1000 identifies the initial members of the congress.

[0136] After the parties that will make up the initial membership of the congress have been identified, the private key may be divided into private key shares according to a threshold signature scheme, step 1008. The private key shares may then be distributed to the identified parties from the nodes executing process 1000, step 1010. The private key shares may be associated with a threshold signature scheme, of the type described herein.

[0137] During step 1010, the nodes identified as congress members cooperate to generate new private key shares and new public keys. The original key shares sent to such nodes by the original trusted party can be used to sign and broadcast a transaction that sends all digital assets in the congress pool to the new public key, which then becomes the congress public key. That is, during step 1010, a new group public address is established, digital assets under the congress's control can be transferred to this new address, which becomes the new address of the group and is associated with the congress public key. After this transfer is confirmed, the congress can operate trustlessly. The new group public address may be formed in the future to receive digital asset deposits from other nodes that want to join the congress, or for other purposes as described above. The congress is now considered to be registered with the congress, and these nodes can operate without the assistance of the original trusted party. Furthermore, the original trusted party is no longer involved in the congress operation.

[0138] It should be noted that one or more of the operations performed in the example process 1000 illustrated in FIG. 10 may be performed in various orders and combinations, including in parallel.

[0139] 11 illustrates in flowchart form an example process 1100 for joining a congress in the context of a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and according to one embodiment. The example process 1100 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 1100 for joining a congress in the context of a computational task distribution system associated with a blockchain network as described in connection with FIG. 11.

[0140] The exemplary process 1100 shown in FIG. 11 may operate in conjunction with the exemplary process 1000 described in connection with FIG. 10. In one embodiment, the exemplary process 1100 is performed by different nodes (e.g., nodes such as node 102) operating in the same blockchain network 100 (FIG. 1) (on which the node performing the exemplary process 1000 operates). In step 1102, the exemplary process 1100 includes obtaining a congress public key. The congress public key may be obtained directly from a party initiating the congress, such as the node performing the exemplary process 1000 of FIG. 10, or may be obtained from a third party, including, for example, a third party system operating outside the blockchain network. For example, the congress public key may be obtained from a public web server accessible via the public Internet.

[0141] In step 1104, a node executing the exemplary process 1100 deposits a digital asset to the congress public key by broadcasting a digital asset transaction from a private account associated with the node to a congress address (i.e., an address associated with the congress public key). More specifically, a node can broadcast a transaction to transfer one or more digital assets to a public group address associated with the congress public key. The public group address may be an address of a congress pool. The congress pool includes other digital assets associated with other members of the congress. Thus, in step 1104, when the transaction is added to a block by a miner (e.g., the mining node 104 described in connection with FIG. 1), the transaction transfers the digital asset, including digital assets from other members, to the congress pool. The public group address may receive both transfers from participants who want to join the congress and transfers from participants who do not want to join the congress. Parties that do not wish to join the Congress may transfer digital assets to the Congress Pool, where such digital assets may be placed under full, partial, or conditional control by the Congress using a threshold signature scheme employed by the Congress.

[0142] In step 1104, the transaction may include a flag, identifier, or other attribute that indicates that the parties transferring the digital assets wish to join the Congress and that a deposit is being made for such purposes.

[0143] After depositing the digital asset in the congress pool, the node executing the example process 1100 receives a private key share in step 1106. The node then regenerates the private key share by executing a single instance of the protocol in step 1108. The generation of the private key share may be performed within the node's TEE.

[0144] In step 1108, the node generates private key shares that can be used in a threshold signature scheme in which at least a threshold number of private key shares must be used to generate a valid signature for a transaction on behalf of the Congress. Other holders of private key shares are other members of the Congress who have joined the Congress on a permissioned or non-permissioned basis by transferring their respective digital assets to the public group address.

[0145] To regenerate the secret key shares, existing congress members may cooperate to update the key shares in step 1108. For example, the nodes may generate a random polynomial of degree t, with the constant term being zero.

number

number

number

[0146] The private key shares may be generated within the TEE (as described above in connection with at least FIG. 2) and may be securely stored in the node. For example, the private key shares may be stored in the TEE.

[0147] After the private key shares have been generated by each node, the funds under the control of the previous Congress public key (e.g., funds transferred to the public group address associated with the original Congress public key) may be transferred (with the cooperation of a sufficient number of group nodes to generate valid signatures under the threshold signature scheme) to the new Congress public key associated with the new private key shares.

[0148] After the private key share is generated in step 1108, the private key share may be used in step 1110 of the exemplary process 1100. The private key share may be used to cooperatively generate a valid signature for a transaction from a public group address (which may be broadcast by a member). That is, the private key share may be used in a threshold signature scheme to contribute to the signature generation. A threshold signature scheme may require each member to use a threshold number of private key shares of the congress to generate a valid signature that allows digital assets to be transferred away from the congress. A node executing the exemplary process 1100 may retrieve the private key share from storage and use this private key share to contribute to the signature generation. If a sufficient number of other congress members also contribute to the generation of the signature using their respective private keys, a signature may be generated and a valid spending transaction may be broadcast. When a mining node of the blockchain network adds the transaction to a mined block (which is added to the blockchain by consensus of the nodes in the blockchain network) and the block is confirmed, the spending transaction may be completed. At this point, the digital assets represented in the transaction may no longer be under the control of Congress, i.e., such digital assets may no longer be restricted by the Congress public key.

[0149] The use of the private key share in step 1108 may be performed within the node's TEE. The TEE protects the private key share such that other parts of the system or the member itself cannot access any data, such as the private key share, stored in the enclave. Additionally, the TEE protects the private key in that the TEE cannot retain a copy of the private key, since if a member wants to refund his or her deposit and wants to receive the deposit, the TEE must certify deletion of the private key before returning the members deposit.

[0150] 11 may be performed during or after an initial setup phase, i.e., the exemplary process 1100 may be performed before the initial key shares are distributed (e.g., during step 1010 of the exemplary process 1000) or after (e.g., during a rebalancing, discussed in more detail below).

[0151] The transaction in step 1110 can transfer the digital assets back to the party that originally deposited them in the Congress Pool. That is, the transfer can return the digital assets to the depositor. The transfer can also transfer the digital assets to another location. For example, the digital assets may be transferred to a third party or to a return address.

[0152] It should be noted that one or more of the operations performed in the example process 1100 illustrated in FIG. 11 may be performed in various orders and combinations, including in parallel.

[0153] FIG. 12 illustrates in flow chart form an example process 1200 for expropriating digital assets in relation to a computational task distribution system associated with a blockchain network as described in relation to FIG. 3 and according to one embodiment. The example process 1200 may be performed by a node of a blockchain network, such as the blockchain network 100 described in relation to FIG. 1, such as one of the nodes 102 described in relation to FIG. 1. That is, a node, such as one of the nodes 102 described in relation to FIG. 1, may perform the example process 1200 for expropriating digital assets described in relation to FIG. 12. In one embodiment, the node performing the example process 1200 shown in FIG. 12 is the same node performing the example process 1100 described in relation to FIG. 11. The example process 1200 may be performed after step 1108 of the example process 1200, and when the example process 1200 is performed, the node performing the example process 1200 already has access to the private key share.

[0154] In step 1202, the node detects malicious activity by a malicious party. The malicious party may be another member of the congress. Malicious activity may be detected when the node determines that a member of the congress violates a predefined protocol or criteria. For example, if a node that is a member in a congress reports false information (i.e., false, inconsistent, or unacceptable information) to other members of the congress, the member may be considered a malicious member.

[0155] In step 1204, in response to detecting malicious activity, the node, in cooperation with other nodes in the congress, can suspend the member that is the malicious participant, i.e., the congress can exclude the malicious participant from further participation in the congress.

[0156] To ensure that all nodes operate in compliance with predefined protocols or standards, member deposits in the Congress Pool may be subject to confiscation. Confiscation means permanently blocking the return of a member deposit that is deemed to have been confiscated. Digital assets forming a member deposit that are not returned due to malicious activity may remain in the Congress Pool, but may not be returned, and may be transferred to another return address immediately or in the future, or may be confiscated. The nature of the confiscation may depend on whether the Congress acts as a bonded validator set for the alternative chain. For example, in step 1206, in response to detecting malicious activity by a malicious party, a node performing the exemplary process 1200 may provide a partial signature on the confiscation transaction using a private key share. That is, the node cooperates with other nodes in the Congress to confiscate at least a portion of the digital assets previously transferred by the malicious party to the public group address (i.e., the Congress Pool). That is, in response to a group member identifying a violation of a predefined protocol or criteria, the private key share may be utilized to contribute to the approval of a transaction of one or more digital assets associated with that group member and held within the congress pool.

[0157] A threshold signature scheme may be used with the Congress public key so that an individual node acting alone cannot transfer another Congress member's digital asset deposit away from the Congress pool (e.g., to a return address). Rather, digital assets are confiscated by transfer only if each member uses a threshold number of private key shares to generate a valid signature to transfer the digital assets to another address, or if members of the group with at least a threshold number of private key shares reach a consensus (in step 1204) to put a member on hold, and withdrawal requests from the suspended member are automatically ignored. Another address to which the digital assets may be transferred in the event that the digital assets are confiscated by transfer may be associated with the return address. For example, this other address may be an address for which no private key exists, preventing any party from accessing the digital assets tied to the address's public key. Once the Digital Assets have been transferred to the return address, they may be considered burned, as they may no longer be redeemed by members of the Congress or indeed by nodes of the blockchain network.

[0158] Thus, in step 1206, a node can confiscate digital assets by cooperating with other members of the congress to generate a valid signature to the return address of the transaction using its private key share.

[0159] Additionally, in some embodiments, the congress serves as a set of reserved validators that protect the proof-of-stake alternate chain, which may be used as a broadcast channel. For example, the congress members of the alternate chain may reach a consensus that a member acted maliciously. This consensus may correspond to the confirmation of an alternate chain transaction that includes criminal evidence of malicious activity. Once consensus is reached, a withdrawal request for the member deposit made by the malicious member may be denied and the deposit may be considered confiscated. All or a portion of the confiscated digital assets may be burned at some point in the future. That is, after some time, a threshold number of members (not including the malicious member) may cooperate to allow the transfer of the confiscated digital assets to a return address. Instead, some or all of the digital assets may be sent as a distribution to the node that provided evidence of the member's misconduct.

[0160] Since the Congress may be an open group that any node in the blockchain network can join by depositing digital assets, the group membership may change periodically, and when such changes occur, the distribution of private key shares may be updated.

[0161] It should be noted that one or more of the operations performed in the example process 1200 illustrated in FIG. 12 may be performed in various orders and combinations, including in parallel.

[0162] FIG 13 illustrates in flow chart form an example process 1300 for updating a private key share distribution for a computational task distribution system associated with a blockchain network as described in connection with FIG 3 and according to one embodiment. The example process 1300 may be performed by a node, such as one of the nodes 102 described in connection with FIG 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG 1. That is, a node, such as one of the nodes 102 described in connection with FIG 1, may perform the example process 1300 for updating a private key share distribution described in connection with FIG 13.

[0163] In step 1302 of the example process 1300, a node detects a redistribution request, which is a request the fulfillment of which will involve a redistribution of key shares. For example, the node may detect that a prospective new member has transferred digital assets to a public group address or that an existing member has requested a withdrawal of a member deposit.

[0164] Digital assets may be transferred to the public group address (i.e., the Congress Pool) by nodes that request to join or increase their participation in the Congress, and by other nodes that do not request to join the Congress, but instead transfer the digital asset to the Congress for another purpose (such as transferring the digital asset to an alternative chain, as described below). In step 1302, the node may use one or more attributes included in at least a portion of the digital asset's transaction to the public group address to identify Congress members (i.e., parties that transferred the digital asset to the Congress public key in order to join the Congress, and not parties for another purpose). For example, a particular transaction may be flagged as a special transaction using transaction attributes. Such attributes (or the presence or absence of the attributes) may indicate the purpose of making the transfer. For example, a flag may be included in the transaction if the transferor is not requesting to join the Congress.

[0165] Upon detection of the request in step 1302, its fulfillment may involve a redistribution of key shares and in step 1304 new private key shares may be generated by the nodes in a manner similar to how private key shares were generated as described above. Other member nodes of the congress also generate their own private key shares. These private key shares may be used in a threshold signature scheme with the new congress public key. A member that leaves the congress at this point may lose the ability to participate in the congress and may no longer be considered a congress member, since they were not able to generate new private key shares during step 1304 and the leaving member has not been assigned private key shares for use with the new congress public key.

[0166] Further, upon detection of a redistribution request (which may be a request whose fulfillment involves a redistribution of key shares), in step 1306, the node, in cooperation with other congress members, transfers all digital assets in the public group address to a new public address associated with the new public key (which may be the new congress public key).

[0167] Thus, according to the example process 1300 of FIG. 13, when the distribution of the escrow changes or when a request to withdraw the escrow is received from a member, the private key shares may be regenerated and all digital assets under the control of the Congress may be moved to the new public key. The frequency with which the members of the Congress can be updated may be limited by the block time of the blockchain network. In many applications, only infrequent rebalancing may be required.

[0168] It should be noted that one or more of the operations performed in the example process 1300 illustrated in FIG. 13 may be performed in various orders and combinations, including in parallel.

[0169] FIG 14 illustrates in flow chart form an example process 1400 for updating a private key share distribution for a computational task distribution system associated with a blockchain network as described in connection with FIG 3 and according to one embodiment. The example process 1400 may be performed by a node, such as one of the nodes 102 described in connection with FIG 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG 1. That is, a node, such as one of the nodes 102 described in connection with FIG 1, may perform the example process 1400 for updating a private key share distribution described in connection with FIG 14.

[0170] In the exemplary process 1400 of FIG. 14, the congress public key is not changed every time the distribution of member escrows is changed. When a request to allocate new key shares is detected (which may occur by depositing digital assets to a public group address in step 1402), the node cooperates with other members of the congress to issue new private key shares for the same public key to new members of the group (in step 1404). The number of cooperating nodes may be at least the threshold number of nodes required to generate digital signatures under the threshold signature scheme. In step 1404, additional key shares may be allocated while other key shares remain the same. This may involve a change in the threshold (of the threshold signature scheme), but in practice the change is small. Alternatively, in step 1404, additional key shares may be allocated while other key shares are updated. Such an update may require proof of deletion of any previously generated key shares. In this case, new shares may be allocated while maintaining the same threshold (in the context of SSS, this involves sharing with a new polynomial of increased degree).

[0171] In step 1402, the node may identify congress members (i.e., parties who have transferred the digital asset to the congress public key in order to join the congress, and not parties for other purposes) using one or more attributes included in at least a portion of the transaction to the public group address of the digital asset. For example, a particular transaction may be flagged as a special transaction using the transaction's attributes. Such an attribute (or the presence or absence of the attribute) may indicate the purpose of making the transfer. For example, a flag may be included in the transaction if the transferor is not requesting to join the congress.

[0172] When a member leaves a congress using the exemplary process 1400, the member can securely delete his / her private key shares. To ensure that the old member's private key shares cannot be used, members of the congress may be required to use nodes with special TEEs. The TEE is an architecture implemented at the hardware level that ensures that instructions and data executed within the TEE are protected from access and manipulation from other parts of the system, as described above. Using hardware mechanisms, the TEE can accommodate remote attestation challenges that can be used to verify the integrity of the system to external parties, such as other nodes of the congress.

[0173] Each member node may use a certified TEE configured to generate one or more random secret values ​​that remain inaccessible to the host system without compromising the hardware at the integrated circuit level. The secret value thus generated is used in the distribution generation of the secret key shares, as described above. This secret value may also be used to establish the public key that is shared during the setup phase of the congress. Since the computations related to the setup protocol may be performed within the enclave of the TEE, no member or former member may obtain information about their own or other's secret key shares through member-to-member communication or otherwise. The enclave within the TEE may run a remote attestation protocol that may be used to prove to other nodes that the TEE enclave is authentic and is executing authorized computer-readable instructions.

[0174] Computations related to changing groups may be performed within the TEE enclave, e.g., generation of a new secure random secret that may be used in computing a new polynomial for SSS purposes may be performed within the TEE enclave.

[0175] The TEE enclave also aims to ensure that prior to returning the member deposit, previous key shares and previous secrets that are no longer in use are securely deleted. More specifically, to return the member deposit, the attestation protocol may require the TEE enclave to attest to the deletion of the key shares. Each node may interpret such attestation as confirmation that the required deletion has occurred at other nodes via the remote attestation protocol. Thus, the exemplary process 1400 may also include verifying that the private key shares previously held in the TEE of the member who left the congress have been deleted from the nodes associated with that member. This verification may be done by receiving a proof of the deletion of the private key shares. Thus, the remote attestation protocol may be used to obtain an attestation for the deletion of the private key shares previously held in the TEE of the member who left the congress.

[0176] It should be noted that the exemplary process 1300 and the exemplary process 1400 each provide various advantages when implemented. For example, the exemplary process 1300 does not rely on secure deletion and does not need to rely on trusted hardware. However, the exemplary process 1300 may benefit from such hardware in some circumstances, as such hardware may make, for example, malicious pooling of key shares less likely. In another example, the exemplary process 1400 avoids the need to have to relock digital assets under a new congress public key every time a constituency changes. Furthermore, in some circumstances, the exemplary process 1400 may update constituencies faster than the exemplary process 1300, because in the exemplary process 1400, digital assets are not moved to a new public key, and therefore no transaction needs to be added to the blockchain to move all digital assets to a new public key. That is, because the public key does not change, constituencies can be updated using the exemplary process 1400 without waiting for several blocks (e.g., six blocks) to be generated to confirm the transfer of digital assets to a new public key.

[0177] It should be noted that one or more of the operations performed in the example process 1400 illustrated in FIG. 14 may be performed in various orders and combinations, including in parallel.

[0178] FIG. 15 illustrates in flow chart form an example process 1500 for returning a deposit in a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and according to one embodiment. The example process 1500 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 1500 for returning a deposit in a computational task distribution system associated with a blockchain network as described in connection with FIG. 15. As described above, a group member may sometimes request to withdraw from the congress, and digital assets deposited in the congress pool may be returned when the group member unsubscribes from the congress.

[0179] In step 1502 of the exemplary process 1500, a node may receive a withdrawal request from a requester who is a congress member. The withdrawal request may also be referred to as a deregistration request. The withdrawal request may be a request to withdraw a digital asset that was previously deposited by the requester and is currently managed by the congress. The request may be broadcast by the requester to all congress members.

[0180] In response to receiving the request, in step 1504, the node evaluates the request against determined criteria. Such criteria may be predefined criteria. If the Congress operates according to a Congress protocol in which the Congress public key is not changed every time group membership changes, in step 1504, the node may verify that the private key share was deleted by the requester. Such verification may be obtained using a remote attestation protocol associated with the TEE.

[0181] If the Congress Protocol is one in which the Congress public key changes when constituency changes, nodes may not acknowledge the deletion of private key shares because the private key shares are no longer valid. Instead, a new Congress key may be used and other digital assets under Congress control may be transferred to the new Congress key.

[0182] In step 1504, an evaluation may also be made as to whether a ghost chain is currently deployed. If a ghost chain is deployed, withdrawal requests may be denied until the ghost chain ceases operation, i.e., congress members mining on the ghost chain will be prevented from withdrawing their token "stake" at least until the ghost chain is terminated.

[0183] If the nodes approve the withdrawal request based on their reputation, then in step 1506, the nodes facilitate the withdrawal of the digital assets. That is, the nodes use their private key shares to collaboratively generate a digital signature and use this digital signature to return to the requester the digital assets previously deposited by the requester. For example, the digital assets may be sent back to the address where the digital assets were previously received. Step 1506 may be performed according to a threshold signature scheme, whereby the withdrawal occurs only if at least a threshold number of congress members approve the withdrawal. Step 1506 may be performed after the member wishing to unsubscribe has had their activities suspended for a period of time. This waiting period prevents the member from engaging in fraudulent activities while executing the protocol for the return of the member deposit.

[0184] The Congress Protocol can be used for many different purposes. It provides a secure mechanism to perform a variety of functions. It operates trustlessly and can control ownership of digital assets.

[0185] The Congress Protocol may be used, for example, to implement a ghost chain as described herein, in which case the Congress Protocol may be referred to as a ghost chain protocol.

[0186] It should be noted that one or more of the operations performed in the example process 1500 illustrated in FIG. 15 may be performed in various orders and combinations, including in parallel.

[0187] Figure 16 illustrates in block diagram form an example environment 1600 in which a first and second blockchain network may be implemented for a computational task distribution system associated with a blockchain network as described in connection with Figure 3 and according to one embodiment. The first blockchain network 1614 may be of the type described above with reference to Figure 1. The first blockchain network 1614 includes multiple nodes 1602, 1606 that may be coupled to each other using any suitable communication technology, which may include wired and wireless communication technologies.

[0188] The nodes 1602, 1606 of the first blockchain network 1614 maintain a global ledger of all transactions on the first blockchain (which may be referred to herein as the “main chain”). At least some of the nodes 1602, 1606 operate as mining nodes 1604 of the first blockchain network 1614, as described herein.

[0189] The second blockchain network 1616 may be a proof-of-stake blockchain network. The second blockchain network 1616 includes multiple nodes 1612, 1606 that may be coupled to each other and that maintain a global ledger for the second blockchain network 1616. The global ledger for the second blockchain network 1616 may be separate and distinct from the global ledger for the first blockchain network 1614. The global ledger for the second blockchain network 1616 may be referred to herein as an "alternative chain."

[0190] The proof-of-stake based second blockchain network 1616 provides an alternative mechanism for achieving consensus. In a proof-of-stake blockchain network, the blockchain may be secured by proof-of-stake instead of proof-of-work. Under proof-of-stake, mining nodes 1608 deposit a security deposit of digital assets and the probability of being selected as a node to mine a block may be proportional to the amount of digital assets provided as the security deposit. Proof-of-stake blockchain systems can be used to avoid the computational expense and energy required to mine a proof-of-work blockchain. Proof-of-stake blockchains allow for more frequent and regular block production than proof-of-work blockchains.

[0191] The second blockchain network 1616 also includes multiple nodes 1606, 1612, which may use any suitable communication technology together. These nodes 1606, 1612 maintain a global ledger for the second blockchain network 1616.

[0192] A plurality of nodes 1606 serve as mining nodes 1608 of the second blockchain network 1616. Because the second blockchain network 1616 may be a proof-of-stake blockchain network, the mining nodes 1608 deposit digital assets for inclusion as mining nodes. More specifically, the alternative chain mining nodes 1608 form a set aside validator set for mining on the second blockchain network 1616. These mining nodes 1608 may also be members of a congress 1610 associated with the first blockchain network 1614. That is, a node 1606 that may be part of both the first blockchain network 1614 and the second blockchain network 1616 serves as a mining node 1608 of the second blockchain network 1616 and as a member of a congress 1610 established on the first blockchain network 1614. These mining nodes 1608 join and participate in the congress 1610 according to the method described above. Depositing digital assets to the congress pool can be done on the main chain. That is, congress members also function as mining nodes 1608 on the second blockchain network 1616 by depositing their “contribution” to the first blockchain network 1614 of proof of work to become congress members of the first blockchain network 1614 and form a set-aside validation set. The member deposit on the first blockchain network 1614 functions as a security deposit for the second blockchain network 1616.

[0193] Note that the amount of private key shares held by a member may be based on the amount of the member's security deposit, and such deposit is subject to forfeiture for malicious behavior, so that members with greater influence on the activities of the Congress (i.e., members holding more private key shares) stand to lose more than members with less influence. The Congress 1610 may be an open membership group that any node may join upon submitting sufficient contributions to a pool associated with the Congress 1610. Because the Congress members may be mining nodes on the second blockchain network 1616, the Congress members may form new digital assets on the second blockchain network 1616, effectively transferring digital assets from the first blockchain network 1614 to the second blockchain network 1616. As described at least in connection with FIG. 17 herein, the Congress 1610 may be used to provide a two-way peg between the proof-of-work blockchain and the proof-of-stake blockchain.

[0194] Nodes 1602, 1606, and 1612 shown in FIG. 16 may be electronic devices such as electronic device 200 described in connection with FIG.

[0195] 17 illustrates in flowchart form an example process 1700 for providing a two-way peg in relation to a computational task distribution system associated with a blockchain network as described in relation to FIG. 3 and according to one embodiment. The example process 1700 may be performed by a node, such as one of the nodes 102 described in relation to FIG. 1, of a blockchain network, such as the blockchain network 100 described in relation to FIG. 1. That is, a node, such as one of the nodes 102 described in relation to FIG. 1, may perform the example process 1700 for providing a computational task distribution system or two-way peg associated with a blockchain network as described in relation to FIG. 17.

[0196] In one embodiment, the exemplary process 1700 is performed by a node, such as the node 1606 described in connection with Figure 16, that operates in both a first blockchain network 1614 (i.e., a proof-of-work blockchain network) and a second blockchain network 1616 (i.e., a proof-of-stake blockchain network), both of which are described in connection with Figure 16. Computer readable instructions may be stored in a memory of such a node, which instructions, when executed by a processor of the node, are configured to cause the processor to perform the exemplary process 1700.

[0197] In step 1702, a node (e.g., node 1606) joins a congress. Joining a congress may be as described above with reference to FIG. 4. For example, the node may transfer one or more digital assets to a public group address associated with a congress public key, where there are one or more other digital assets associated with other members of the congress (e.g., other nodes such as node 1606). When a node joins a congress, the node generates a private key share for use in a threshold signature scheme that requires the use of at least a threshold number of private key shares to generate a valid signature on behalf of the congress. As described above, the threshold signature scheme may be of various types, including a threshold scheme based on an Elliptic Curve Digital Signature Algorithm or a Schnorr scheme.

[0198] Other holders of private key shares may be other members of the Congress who have joined the Congress on a permissioned or non-permissioned basis by transferring their respective digital assets to the public group address.

[0199] In step 1704, the nodes that joined the Congress form a bonded validation set together with other members of the Congress on a proof-of-stake blockchain network (e.g., on the second blockchain network 1616). That is, after depositing digital assets as security (which bond may be referred to herein as “bonding”), the members of the Congress (formed by their bond to the first blockchain network 1614) now function as mining nodes on the second blockchain network (e.g., the second blockchain network 1616) and periodically generate new blocks for the second blockchain network.

[0200] After the congress is formed, in step 1706, the congress member nodes can detect confirmation of a special transaction to the group public address of the digital asset on the proof-of-work blockchain network. The transaction can be determined to be special if it meets predefined criteria that distinguish it from the transaction used to join the congress. For example, the transaction can be determined to be special if it contains a particular flag, variable, or attribute.

[0201] After detecting the special transaction, the node may wait until at least a threshold number of blocks have been added to the blockchain of the proof-of-work blockchain network. This waiting period may reduce the risk of a possible reorganization of the blockchain on the proof-of-work blockchain network that may invalidate the transaction in step 1706. Thus, although not shown in FIG. 17, the method may include an operation of determining that at least a threshold number of blocks have been added to the blockchain of the proof-of-work blockchain network after detecting the special transaction.

[0202] After the threshold number of blocks have been added to the proof-of-work blockchain, the node generates (at step 1708) corresponding digital assets on the proof-of-stake blockchain network. These digital assets may be generated in response to detecting the special transaction and in an amount corresponding to the amount of the digital assets of the special transaction detected in step 1706.

[0203] The generated digital assets may be placed on the proof-of-stake blockchain network in an account associated with the owner of the public key that detected the special transaction in step 1706. The party that transfers the digital assets to the congress on the proof-of-stake blockchain network thus resumes control of the digital assets on the proof-of-stake blockchain network. This party is now free to use those digital assets in various ways, for example, by transferring them to other accounts.

[0204] The generation may be performed by a selected congress member. More specifically, a congress member that also functions as a mining node of the proof-of-stake blockchain network (e.g., a miner such as mining node 1608 described in connection with FIG. 16) may be selected to generate blocks by the proof-of-stake blockchain network. The probability that a node is selected may be based on the amount of digital assets that the node has contributed. The probability may be proportional to the amount of digital assets that the node has deposited in the congress public key.

[0205] At some point, an owner of digital assets may wish to return those digital assets to the proof-of-work blockchain network (i.e., the main chain). To do so, the owner may issue a request to return the digital assets to the proof-of-work blockchain network. Such a request may be issued in the form of a special transaction on the proof-of-stake blockchain network. This transaction may be special in that it is a transaction to a special return address, which is the address to which the sender sends funds when they wish to return those funds to the main chain. That is, the transaction may be special in that the address is a special address. In step 1710, a node may detect a request to return the digital assets on the proof-of-stake blockchain network to the proof-of-work blockchain network. For example, in step 1710, there may be mining of a transaction that sends funds to a special address.

[0206] To prevent reorganization, a node may wait until at least a threshold number of blocks have been added to the blockchain of the proof-of-stake blockchain network after the request is detected in step 1710. Thus, although not shown in FIG. 17, example process 1700 may include an operation of determining that at least a threshold number of blocks have been added to the blockchain of the proof-of-stake blockchain network after the request is detected.

[0207] Upon detecting such a request and determining that a threshold number of blocks have been added to the proof-of-stake blockchain, in step 1712, the nodes use their private key shares of the congress to collaboratively generate a valid signature for the transaction from the public group address. For example, the transaction can be circulated among congress members either directly or via the alternative chain by including the necessary information in the transaction, and members can add their partial signatures until a valid signature is obtained, at which point the transaction can be broadcast to mining nodes of the proof-of-work blockchain network (e.g., mining node 1604 described in connection with FIG. 16). The transaction transfers digital assets to an address on the proof-of-work blockchain network (which can be an address associated with the node that made the request detected in step 1710).

[0208] The special address to which the digital assets are transferred in step 1710 may be a return address. Thus, the transfer of the digital assets in step 1710 burns (i.e., destroys) the digital assets on the proof-of-stake blockchain to prevent duplication of the digital assets across the two blockchains.

[0209] To enhance security, at least some of the operations of the transfer may be performed on the node in a trusted execution environment. For example, a determination that at least a threshold number of blocks have been added to the blockchain of the proof-of-stake blockchain network may be performed in the trusted execution environment on the node. The node may also verify the validity of the request detected in step 1710 in the trusted execution environment before using the private key share. The generation and use of the private key share may also be performed in the trusted execution environment.

[0210] It should be noted that one or more of the operations performed in the example process 1700 illustrated in FIG. 17 may be performed in various orders and combinations, including in parallel.

[0211] To further enhance the security of the protocols described herein, it is noted that the protocols may include one or more safeguards to protect against a "one-way bet attack." An example of a one-way bet attack occurs when a fraudster (i.e., a node associated with a malicious party) constructs a transaction on the main chain that transfers all or a portion of a digital asset under the control of the Congress (i.e., bound by the Congress public key). The fraudster may provide the transaction to other members to add a partial signature. A valid signature can be generated if a threshold number of private key shares associated with the members are involved. If the threshold signature scheme used in the protocol is not an aggregate signature scheme (e.g., if ECDSA is used), it may be difficult to identify the members who provided the partial signature. A member who may be due for distribution if the fraud is successful may add a partial signature to the transaction and allow the transaction to pass without exposing themselves as a party to the fraud. Adding a partial signature can be seen as a one-way staking, since the worst that can happen is that insufficient partial signatures are collected to obtain a complete signature. Thus, the protocol may include one or more features to protect the protocol against one-way staking. For example, the TEE of each node may be configured to periodically attest all partially signed transactions and / or may be required to broadcast such attestations before withdrawing the deposit. If a node attests that it added a partial signature to a transaction that is later determined to be a fraudulent transaction (by a congress member threshold), such malicious activity may be detected by other honest member nodes as described herein. If such malicious activity is detected, honest member nodes may cooperate to place the member on hold as described herein and / or confiscate the member's digital assets as described herein.While this technique helps protect the protocol against one-way staking, it can introduce overhead if periodic proofs are used. Furthermore, fraud may go undetected for long periods of time if proofs are required before the return of the deposit.

[0212] The protocol may include other security measures to protect against one-way staking. For example, an aggregate signature scheme such as the "BGLS" scheme of Boneh, Gentry, Lynn and Shacham (Aggregate and Verifiably Encrypted Signatures from Bilinear Maps. International Conference on the Theory and Applications of Cryptographic Techniques EUROCRYPT 2003: Advances in Cryptology- pp 416-432) may be used. With aggregate signatures, different signers can sign different messages, but only one signature is produced, and this signature can be verified in a "single shot".

[0213] To use BGLS, each member's TEE may hold a single private key share for the threshold signature scheme used on the main chain and a BGLS private key. The public key corresponding to the BGLS private key may be referred to as a share ID ("SID"). The BGLS private key may be a random number generated using a secure random number generator within the TEE. The private key shares for the threshold signature scheme may be shares calculated within the TEE using a multiparty key generation protocol.

[0214] BGLS can provide secure protection against one-way staking in the following way: When nodes distribute the Congress public key for registration purposes as described herein, the registration transaction contains the number and hash of the most recent block on the main chain that the enclave has confirmed, and the number and hash of the most recent block on the second blockchain (i.e., the alternate chain), which can be used as a broadcast channel between members and a quote (a hash of the initial contents of memory in the enclave, signed by the TEE's attestation key and bound to the SID).

[0215] Before the TEE is required to provide the necessary data for a registration transaction, the members must sequentially submit all blocks on the main chain and the secondary blockchain into the TEE starting from the genesis block of each blockchain. The TEE can be configured to check the proof-of-work on the main chain and keep a record of the current constituencies, which can be obtained by parsing registration and deregistration transactions. This allows the TEE to establish up-to-date SIDs independently (e.g., from the owner, etc.) i.e., the TEE can establish SIDs corresponding to all current members of the congress.

[0216] To register, a (prospective) member can construct, sign, and broadcast a registration transaction forwardable to the Congress public group address to the main chain blockchain network (e.g., the first blockchain network 1614). The registration transaction references sufficient UTXOs for at least one key share. Once the registration transaction is confirmed on the main chain, the members of the Congress can cooperate to issue new key shares to the registered member's TEE as described herein.

[0217] When a Congress wants to initiate a digital asset transaction bound by a Congress public key, the Congress node can propose a transaction (i.e., denoted herein as “transaction T(M)”) on the second blockchain network (i.e., the alternative chain). Transaction T(M) is now an unsigned transaction intended to transfer digital assets onto the main chain M, which may be proposed on the alternative chain A. That is, the second blockchain network (i.e., the alternative chain) may be used as a broadcast channel. If a member wants to communicate some information to all other members, it may put the information in a transaction and send this transaction to the alternative chain.

[0218] Transaction T(M) may be considered approved on the second blockchain network (e.g., the alternative chain) once at least a threshold number of blocks have been mined on the second blockchain network. Once the TEE has confirmed that the transaction has been approved (i.e., proposed and confirmed) on the second blockchain network (i.e., the alternative chain), it broadcasts a precommit. The precommit may consist of a BLGS signature on transaction T(M) and a SID corresponding to the BLGS signature. The precommit is sent to the second blockchain network and shared with other congress members. That is, the precommit may be encapsulated in a transaction on the second blockchain network.

[0219] Once the threshold pre-commit is confirmed by the node, more specifically by the TEE (where both blocks from the main chain and the second blockchain network are input), the node can output a pre-commit (partial signature) on transaction T(M). The threshold can be set, for example, to a simple majority of all current SIDs. The commit included in the transaction can be sent to the second blockchain network including a partial signature of T(M) referencing T(M).

[0220] Once at least a threshold number of commits to construct a complete signature have been confirmed in the second blockchain network, a signed transaction T(M) may be constructed and broadcast to the first blockchain network (e.g., the mainchain).

[0221] The use of pre-commit can provide additional security, since properties of the aggregate signature scheme mean that members cannot contribute to the pre-commit without revealing their identity: their identity can be made public in the form of a SID, which is associated with the member deposit during the registration process.

[0222] In addition to the above-mentioned measures, the TEE associated with a node can be further configured to commit or pre-commit only if the transaction is approved on the second blockchain network. For example, every block can be constructed in the TEE and configured such that the block always contains pre-commits or commits to approved transactions that require those pre-commits or commits (corresponding to the TEE's SID and constructed in the TEE). As a result, a member cannot refrain from sending commits or pre-commits to approved transactions and continue mining on the alternative chain.

[0223] Nodes that monitor pre-commitments to unconfirmed transactions on the second blockchain network can report such malicious behavior to other members of the set aside validation set. Malicious members (identified by their SIDs) may be punished by withholding and / or confiscation of member deposits as described above. For example, in response to monitoring pre-commitments to unconfirmed transactions, members can cooperate to immediately suspend their SIDs, receive no further pre-commitments, and suspend the guilty member's participation in the protocol. Furthermore, when a transaction containing evidence of guilt is confirmed on the second blockchain network, the guilty member's deposit is forfeited and the deposit is burned. Honest members can cooperate to compensate nodes that reported malicious behavior (e.g., by transferring at least a portion of the confiscated digital assets to the node that reported the malicious behavior). Thus, applying an aggregate signature scheme at the pre-commit stage can enhance the security of the protocol, for example, by preventing one-way staking attacks.

[0224] To prevent members from deceiving the TEE into determining that the current difficulty of the proof-of-work in the main chain is lower than it is currently, the TEE may be configured to take action when a sudden drop in difficulty is observed. More specifically, the difficulty may be established from the time interval between blocks when they are sent to the TEE as they arrive. A drop in difficulty may be expected to be gradual, and a sudden drop (which may be determined to be "sudden" based on predefined criteria) may be caused by a member attempting to deceive the TEE by not providing a block as it arrives, making it easier to fake a proof-of-work main chain block to make it appear that the difficulty has dropped. To provide further security, the TEE may be configured to respond to a sudden drop in the difficulty of the main chain by outputting a pre-commit to the new difficulty (along with the hash of the block and the block number) to be mined into the second blockchain network. Including the block hash allows one to verify that the block corresponds to the new difficulty level, while including the block number allows other members to quickly compare the claimed difficulty / block hash with a block at the same level in their copy of the blockchain.

[0225] Only if a block from the second blockchain is provided that contains a threshold pre-commitment for that same difficulty (which corresponds to other members who had deposits before the difficulty spike) can it re-adjust the difficulty of the main chain and accept new members to enroll on the main chain since the spike in difficulty has been confirmed.

[0226] When an aggregate signature scheme such as BGLS is used, the procedure for returning a member deposit may include additional requirements. For example, a node requesting the return of a deposit may need to attest (through its TEE) to the deletion of both its private key shares and its BGLS private key. Other member nodes may be configured to include pre-commit or only partial signatures in transactions returning a member deposit to a leaving member if the leaving member attests to the deletion of both its private key shares and its BGLS private key.

[0227] The leaving member's node may also be required to pre-commit or attest all committed transactions via the TEE. Other member nodes may be configured to include pre-committed or only partial signatures in transactions returning member deposits to the leaving member if the leaving member did not pre-commit to a transaction determined to be unapproved.

[0228] The above procedure ensures that malicious members have little to gain from withholding blocks from the TEE. The only pre-commitments that the TEE can consider valid (other than those corresponding to confirmed SIDs) are those corresponding to BLGS private keys that no longer exist (and the only way this can happen with any significant probability is if members did not provide the latest blocks to the TEE, and the TEE registered some members as up-to-date when in fact some members had left the Congress, removed their key shares, and withdrawn their member deposits). Moreover, as a result of the above, members may not convince the TEE to provide pre-commitments for fraudulent (i.e., unconfirmed) transactions and then allow the return of the deposit by the Congress. Thus, members may be incentivized to ensure that the TEE has the latest copy of the blockchain (i.e., the main chain and the alternative chain).

[0229] Thus, the protocol can be secured by configuring nodes to operate according to a protocol that includes one or more of the following features: (i) a TEE can be configured to require that a threshold pre-commitment be confirmed on a second blockchain network (e.g., a proof-of-stake alternative chain) before outputting a partial signature on a pre-committed transaction; (ii) a member deposit can only be returned if the member's TEE attests to the deletion of its private key shares and BGLS private key and all transactions (both of which were pre-committed and which have been determined (by consensus on the second blockchain network) to be unapproved); (iii) blocks constructed within the TEE can always contain (pre-)commitments for approved transactions that require them (approved / pre-committed transactions that have not yet collected a threshold (pre-)commitment); (iv) a TEE can be configured to respond to an observed sudden drop in the difficulty of the main chain by outputting a pre-commit for the new difficulty (along with a hash of the block) to be mined on the second blockchain network. Only if a block of the second blockchain is provided containing a pre-commitment of the same difficulty threshold (which corresponds to other members who had deposits before the difficulty spike) will it be able to re-adjust the difficulty of the main chain and accept new members to be enrolled on the main chain since the spike in difficulty has been confirmed.

[0230] The protocols supporting the second blockchain network described herein may be layered on top of an existing public proof-of-work blockchain protocol, such as Bitcoin, in a permissionless manner, since they interact through the construction of digital signatures via a multiparty protocol external to the main chain (e.g., Bitcoin), meaning that the protocol may operate without requiring the consent of the main chain's miners or developers. Thus, the protocol may be implemented "on top of" an existing public proof-of-work blockchain and may not be contingent on changes to the protocol of that public proof-of-work blockchain. In this sense, protocols may be added to a blockchain in a permissionless manner (i.e., without requiring permission), since the blockchain protocol itself does not need to be changed to accommodate the further protocol.

[0231] It should be noted that while the exemplary processes described herein are generally described as being performed on nodes, the functionality of the exemplary processes described herein relies on cooperation with other nodes and may be performed by other computing devices as described herein. Additionally, while the above description generally describes congress being implemented in a proof-of-work blockchain network, congress may instead be implemented in a proof-of-stake blockchain network.

[0232] In addition to the specific advantages and features already mentioned, the techniques described herein may provide additional advantages. For example, a two-way peg may add Turing complete blockchain-based computer program functionality to a binary blockchain system consisting of an existing proof-of-work blockchain (such as Bitcoin) and a proof-of-stake alternative chain. More specifically, such functionality may be achieved by using a Turing complete scripting language to provide the proof-of-stake alternative chain. Furthermore, at least some of the techniques described herein may provide a proof-of-stake blockchain that does not suffer from the nothing-at-stake problem of previously suggested proof-of-stake blockchain implementations, and the advantages of faster and more regular block production associated with traditional proof-of-stake schemes. Furthermore, at least some of the techniques described herein may provide a reason for miners of a proof-of-stake mainchain to hold a significant number of digital assets, which increases the security of the proof-of-work mainchain.

[0233] FIG. 18 illustrates in block diagram form an example environment 1800 in which blockchain and ghost chains may be implemented in relation to a computational task distribution system associated with a blockchain network, as described in relation to FIG. 3 and in accordance with one embodiment.

[0234] The blockchain 1802 may be a block-based proof-of-work distributed ledger as described herein. The ghost chain 1804, also as described herein, may be a block-based proof-of-stake distributed ledger that may be used, for example, to arbitrate disputes between nodes in a blockchain network. For example, the blockchain may include a challenge 1806 where one node challenges a work product submitted by another node. A challenge 1806 may occur, for example, when a node (i.e., the challenger) indicates that a proposed outcome in fulfilling a request is invalid.

[0235] When a challenge 1806 is raised by a node, a ghost chain 1804 may be deployed. A ghost chain may be instantiated after a challenge 1806 occurs in response to a challenge. The ghost chain may be instantiated with a genesis block, which is the last block (also called a terminal block) from a previous instantiation of the ghost chain. Several blocks may be added to the ghost chain by mining nodes until the ghost chain reaches a judgment 1808 to resolve digital disputes.

[0236] When the decision 1808 is reached, a transaction (hereinafter referred to as a final or settlement transaction) may be constructed and signed (as described in more detail below). This transaction may have the effect of distributing funds to the main blockchain 1802 according to the decision 1808, distributing funds to mining nodes of the ghost chain, etc. The transaction may also transmit the result of the decision back to the main blockchain 1802 (e.g., the transaction may be mined in decision block 1810). More specifically, the result may be encapsulated in the transaction.

[0237] After a decision is reached and a final transaction is constructed and signed, the ghost chain 1804 terminates and the constructed transaction may be mined into the main blockchain 1802 at decision block 1810. Because the ghost chain 1804 terminates, it may differ from a typical blockchain in that the ghost chain has a terminal block. This terminal block, which may be the last block of the ghost chain 1804, occurs once a decision (e.g., decision block 1808 of the ghost chain 1804) is decided and the resulting transactions, such as distributing funds to the main blockchain 1802 according to this decision and distributing funds to mining nodes of the ghost chain, are validly signed.

[0238] Thus, a node in a blockchain network may implement a claimant-proposer-challenger protocol and / or a ghost chain resolution protocol. Such a node may include computer-executable instructions stored in a memory, such as memory 220 described in connection with FIG. 2, that implement such a protocol. Such instructions, when executed by a processor, such as processor 210 described in connection with FIG. 2, cause a node (such as electronic device 200 of the type described in connection with FIG. 2) to perform one or more methods related to the claimant-proposer-challenger protocol and / or the ghost chain resolution protocol. Such methods may include any one or combination of example processes 1900, 2000, 2100, or 2200 described herein.

[0239] 19-22, which illustrate methods that may be included in the Requester-Proposer-Challenger Protocol and / or the Ghost Chain Resolution Protocol. The Requester method (e.g., the method of example process 1900 shown in FIG. 19) may be performed by a requester of a task in a computational task distribution system. That is, a node requesting completion of a task may perform the Requester method shown in FIG. 19. In one embodiment, the node is a node in a blockchain network, and the node may be referred to as a requester.

[0240] A proposer method (e.g., the method of example process 2000 shown in FIG. 20) may be performed by a proposer for a solution to a task. That is, a node that claims to have completed a task may perform the proposer method shown in FIG. 20. A node is a node in a blockchain network, and the node may be referred to as a proposer.

[0241] A challenger method (e.g., the method of example process 2100 shown in FIG. 21) may be performed by a challenger regarding a solution to a task. That is, a node that challenges a solution presented by a proposer may perform the challenger method shown in FIG. 21. A node is a node of a blockchain network, and the node may be referred to as a challenger.

[0242] An arbitrator method (e.g., the method of example process 2200 shown in FIG. 22) may be performed by a node of a blockchain network in cooperation with other nodes of the blockchain network. A node that performs the arbitrator method in cooperation with other nodes may be referred to as an arbitrator.

[0243] The methods described in example processes 1900, 2000, 2100, and 2200 of Figures 19-22 operate in concert to collectively provide a requestor-proposer-challenger protocol that is used by the ghost chain to determine the validity of a proposed string (and / or to determine the validity of a challenged string if the proposed string is subject to challenge), as described herein.

[0244] FIG. 19 illustrates in flow chart form an example process 1900 for requesting completion of a task in relation to a computational task distribution system associated with a blockchain network as described in relation to FIG. 3 and according to one embodiment. The example process 1900 may be performed by a node, such as one of the nodes 102 described in relation to FIG. 1, of a blockchain network, such as the blockchain network 100 described in relation to FIG. 1. That is, a node, such as one of the nodes 102 described in relation to FIG. 1, may perform the example process 1900 for requesting completion of a task in relation to a computational task distribution system associated with a blockchain network as described in relation to FIG. 19. It should be noted that one or more operations performed in the example process 1900 illustrated in FIG. 19 may be performed in various orders and combinations, including in parallel.

[0245] FIG. 20 illustrates in flow chart form an example process 2000 for proposing a solution to a task in a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and according to one embodiment. The example process 2000 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 2000 for proposing a solution to a task in a computational task distribution system associated with a blockchain network as described in connection with FIG. 20. It should be noted that one or more operations performed in the example process 2000 illustrated in FIG. 20 may be performed in various orders and combinations, including in parallel.

[0246] FIG. 21 illustrates in flow chart form an example process 2100 for disputing a solution to a task in a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and according to one embodiment. The example process 2100 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 2100 for disputing a solution to a task in a computational task distribution system associated with a blockchain network as described in connection with FIG. 21. It should be noted that one or more operations performed in the example process 2100 illustrated in FIG. 21 may be performed in various orders and combinations, including in parallel.

[0247] FIG. 22 illustrates in flow chart form an example process 2200 for arbitrating challengers against a solution to a task in a computational task distribution system associated with a blockchain network as described in connection with FIG. 3 and according to one embodiment. The example process 2200 may be performed by a node, such as one of the nodes 102 described in connection with FIG. 1, of a blockchain network, such as the blockchain network 100 described in connection with FIG. 1. That is, a node, such as one of the nodes 102 described in connection with FIG. 1, may perform the example process 2200 for arbitrating challengers against a solution to a task in a computational task distribution system associated with a blockchain network as described in connection with FIG. 22. It should be noted that one or more operations performed in the example process 2200 illustrated in FIG. 22 may be performed in various orders and combinations, including in parallel.

[0248] In step 1902 of the exemplary process 1900, a node (which may be referred to herein as a “requester”) makes a request. The request may be a request to complete a task. For example, the task may be a request for a work product. More specifically, the task may be a request for a processor work product (i.e., for a processor to generate a specified work product, such as the output of a computation). The task may be a costly computation, a task that requires input from an external source, such as a financial contract, or a task that generates data with specific properties, such as an algorithm or document. The request provides a reward in the form of a digital asset associated with a blockchain network (e.g., the blockchain network 100 described in connection with FIG. 1 ) in exchange for successful completion of the task. The request may originate from outside the blockchain (i.e., “off-chain”). For example, the request may originate at a web server accessible via the Internet. A request may be defined as successfully completed when a candidate solution to the request is not challenged for a certain period of time (which may be referred to herein as the “challenge period”), or when the candidate solution is found to match the result of the on-chain computation, where challenges may be resolved by re-running the computation on the ghost chain.

[0249] A request may be issued (at step 1902) on a computational task distribution system. The computational task distribution system may include a collection of tasks requested by various requesters. For example, multiple tasks may be submitted on the computational task distribution system. The tasks may be submitted by the same requester or by different requesters. The computational task distribution system allows nodes to offload computations or algorithmic performance to other nodes.

[0250] In step 2002 of the exemplary process 2000, a node, referred to herein as a proposer, identifies a request. The node then proceeds to complete the task off-chain (in step 2004). For example, the algorithm, data, or other result requested by the requester may be obtained as a work product by a processor.

[0251] The proposer may then submit a proposal in step 2006 of the exemplary process 2000. A proposal may be a claim that the proposer has completed a task associated with the request issued by the requester in step 1902 of the exemplary process 1900. To submit a proposal, the proposer may send a blockchain network public key to the requester. The proposer may also commit to a solution to the task. This commitment may be in the form of a hash of the solution (i.e., a hash of a work product, such as the output of a computation or another type of solution).

[0252] The requestor receives the proposal at step 1904 of the example process 1900. For example, the requestor may receive the proposer's public key and a "commit" (e.g., a hash of the desired work product).

[0253] In response to receiving the proposal, in step 1906 of the example process 1900, the requester may construct transaction T1. Transaction T1 includes the bounty as an input. The transaction includes the bounty and the proposer's deposit as outputs (i.e., output of T1, T1_out=bounty+proposer's deposit). Transaction T1 may be signed to allow the proposer to add to his or her input. For example, transaction T1 may be signed SIGHASH_ALL|SIGHASH ANYONECANPAY. SIGHASH_ALL may be a default signature hash type that signs the entire transaction except for the signature script, preventing modification of the signed parts. SIGHASH ANYONECANPAY may be a signature hash type that signs only the current input.

[0254] Transaction T1 can be constructed to be unlocked in two ways. After the challenge period (described below) has ended, transaction T1 can be unlocked with the proposer's signature (i.e., the signature corresponding to the public key provided by the proposer to the requester) and the solution corresponding to the commit. For example, the transaction can be locked for the challenge period, but unlocked by the proposer if no challenge is made within this period, using the opcode OP_CHECKSEQUENCEVERIFY. Transaction T1 can also be constructed to be unlocked at any time with the congress group signature, as described above. That is, transaction T1 can be unlocked before or after the challenge period ends, when the nodes that are members of the congress cooperate to use their respective private key shares to unlock transaction T1 according to the congress threshold signature scheme.

[0255] Transaction T1 may also contain information about a suspect (unconfirmed) solution, such as a commit. For example, a hash of a desired work product may be added to transaction T1 using the OP_PUSHDATA opcode. More specifically, the hash of the desired work product may be added to a lock script for transaction T1. This lock script may be configured to be unlocked (after the end of the challenge period) by an unlock script that provides a solution that hashes to the hash of the desired work product included in the lock script.

[0256] Although not shown in Figures 19 and 20, the proposer can receive the transaction T1 constructed in step 1906 and add the proposer's deposit as an input to transaction T1. The proposer broadcasts the transaction to other nodes in the blockchain network. Transaction T1 is mined (i.e., added to a block) and made public on the blockchain.

[0257] Once transaction T1 is mined into the blockchain, a challenge period begins during which any node may challenge the proposal submitted by the proposer. If no challenge is made during the challenge period, the proposer may claim the bounty and the proposer's deposit from transaction T1. The proposer may start a timer to track the time remaining in the challenge period and may automatically take action when the challenge period ends. For example, the proposer may provide a work product (which may be referred to herein as a solution) to the requester and unlock the transaction.

[0258] A proposer cannot provide a solution to a requester directly. Instead, a proposer can provide a solution by embedding the solution in a transaction on the main blockchain network. For example, a proposer can provide a solution with an unlock script (e.g., unlock script that evaluates lock script of T1 to TRUE) that unlocks a lock script (in transaction T1) that restricts the bounty and the proposer's deposit. As described above, the lock script can be configured to verify that the proposed solution in the unlock script hashes to a value (i.e., a "commit") previously given by the requester. When the unlock script successfully unlocks the lock script that restricts the digital assets previously restricted by the lock script of transaction T1 (i.e., the UTXO of transaction T1), the transaction containing the unlock script unlocks the transaction by restricting the digital assets (i.e., the proposer's deposit and bounty) with a new lock script (which, for example, restricts the digital assets using the proposer's public key, giving the proposer full control over the digital assets).

[0259] As mentioned above, transaction T1 can be constructed to lock the bounty and proposer escrow using the OP_CHECKSEQUENCEVERIFY code, allowing the proposer to automatically claim the bounty and proposer escrow after the challenge period has ended without further approval from the claimant.

[0260] Note that if there are no challenges to the proposer's solution, the full transaction can be executed on the Proof of Work main blockchain without requiring the execution of the challenge protocol or the ghost chain protocol.

[0261] However, a challenger may challenge during the challenge period. For example, in step 2102 of the exemplary process 2100, the challenger challenges. The challenger may perform operations similar to steps 2002 and 2004 of the exemplary process 2000. That is, the challenger may identify a request and complete tasks off-chain before challenging in step 2102. The challenger may also determine that a challenge is necessary by determining that the challenger's solution is different from the proposer's solution. For example, the challenger may perform a hash of his or her solution and compare the hash to the hash of the proposer's solution, and if the hashes are different, the challenger may challenge.

[0262] In step 2102 of the example process 2100 of FIG. 21, a challenger files a challenge within a challenge period. The challenger may file a challenge by broadcasting an intent to file a challenge to the blockchain network. Once a challenge is filed, a group of nodes may assist in determining the validity of the solution.

[0263] For example, a group of nodes may form a congress, which may be used to arbitrate when a challenge is raised. As described above, the congress is secured by the deposit of digital assets on a proof-of-work blockchain network. In step 2202 of the exemplary process 2200, an arbitrator performing the exemplary process 2200 of an arbitrator may join a congress as described above. Thus, in step 2202, an arbitrator joins and becomes a group member by depositing digital assets in a public group address associated with the congress, which may be called a congress. The arbitrator makes this deposit on the proof-of-work blockchain network. As described above, the group may be associated with a threshold signature scheme for nodes to control private key shares. Joining a group (which may be called registration) may occur, for example, during deployment of the ghost chain. 22 shows step 2202 (joining the congress) occurring before step 2206 (developing the ghost chain), step 2202 may be performed by a node that joined the congress during a previous development of the ghost chain (i.e., not during the development in step 2206). However, steps 2206, 2208, and 2210 may also be performed by a node that joins the group during step 2206, for example.

[0264] In step 2204, the arbitrator, in cooperation with other nodes in the group, detects a challenge made by the challenger in step 2102 of the exemplary process 2100. More specifically, the arbitrator, in cooperation with other nodes in the group, detects a challenge by the challenger to the proposer's work product in response to a request made by the requester.

[0265] With transaction T1 described above, once a challenge is made, the group takes over control of the bounty and proposer's escrow. That is, transaction T1 can be constructed to be unlockable by the Congress at any time. Thus, the bounty and escrow are under the group's control and maintained. In this way, the group controls the bounty and proposer's escrow regardless of whether a challenge occurs. In one embodiment, once a challenge is detected, the group jointly signs an unlock transaction related to the challenge to distribute the share and / or escrow as described herein. As described herein, the share and / or escrow are redeemable by the group at any time, but only by the proposer (or the challenger, if successful) after an associated timeout period.

[0266] After the group manages the bounty and proposer's deposit, in response to the detection of a challenger, the arbitrator, in cooperation with other nodes in the group, can facilitate the deposit of digital assets by the challenger. For example, in response to the detection of a challenge, the Congress can construct transaction T2 with inputs equal to the bounty and proposer's deposit (e.g., T2_in = bounty + proposer's deposit) and output equal to the sum of the bounty, proposer's deposit, and challenger's deposit (e.g., T2_out = bounty + proposer's deposit + challenger's deposit). Transaction T2 can be configured to distribute to the group at any time. That is, transaction T2 can be configured to distribute to the Congress public key. Transaction T2 can be signed SIGHASH_ALL|SIGHASH ANYONECANPAY. The arbitrator, along with other arbitrators, can provide transaction T2 to the challenger to add the challenger's deposit as an input. For example, the arbitrator, together with other nodes, can publish transaction T2 to other nodes.

[0267] After transaction T2 is published, the challenger adds the challenger's deposit as an input to transaction T2. ​​That is, the challenger provides a deposit of digital assets (at step 2104 of example process 2100) and places such deposit under the control of the group. More specifically, the challenger's deposit may be under the control of the Congress public key. Thus, the bounty, the proposer's deposit, and the challenger's deposit are all under the control of the group and are bounded by the Congress public key. As explained in detail in the Congress description above, the threshold signature scheme allows a threshold number of Congress members to cooperatively generate valid signatures for a transaction that includes the bounty, the proposer's deposit, and the challenger's deposit using their respective private key shares. The proposer's deposit and the challenger's deposit may be of the same size.

[0268] The challenger can also commit to the solution of the challenge. For example, the challenger can add a hash of the solution to transaction T2, e.g., using the opcode OP_PUSHDATA.

[0269] Transaction T2 is broadcast to the main blockchain network and can be mined on the main blockchain network, so that the challenger deposit is restricted by the Congress public key. The bounty, the proposer deposit, and the challenger deposit can be under the exclusive control of the group.

[0270] Thus, the challenger provides evidence of an alternative solution and a deposit to the arbitrator. In step 2206 of the exemplary process 2200, after transaction T2 is mined onto the main blockchain network, the arbitrator cooperates with other nodes in the group to deploy a ghost chain to resolve the challenge. As described above, the ghost chain may be a proof-of-stake blockchain where mining nodes of the ghost chain are members of the group. That is, members of the congress may be allowed to mine on the ghost chain. Member deposits on the proof-of-work blockchain network serve as a contribution to enable members of the congress to mine on the ghost chain, and the probability that a member will be selected to mine may be proportional to the relative amount of the deposit.

[0271] While the ghost chain is being deployed (at step 2206), the arbitrator, in cooperation with other nodes in the group, may create or obtain a genesis block for the ghost chain. The genesis block may be the final block from the last ghost chain deployment (e.g., the terminal block from the last instance when the ghost chain was executed and a previous run was made in response to a previous challenge). This block may contain information about the genesis distribution. The genesis distribution may be a transfer of digital assets that has not yet taken place and is based on a previous deployment of the ghost chain.

[0272] Additionally, while the Ghost Chain is being deployed, members can be allowed to register or request to be deregistered from the group. During the registration phase, new members can be registered and assigned private key shares as described herein. New members can be provided with a genesis block (which can be authenticated by a current threshold of members) and subsequent blocks generated during the registration process.

[0273] A Ghost Chain implementation may also include a pre-deregistration phase. During this pre-deregistration phase, a member requesting deregistration can submit proof of the deletion of certain personal data. Such proof may be required for the return of the member deposit. Evidence of fraudulent activity that may prevent the return of the member deposit can be submitted at this phase (e.g., a newly registered member can submit a genesis block that was pre-committed by current member(s) but is suspected to be fake). Deregistration techniques are described in more detail above.

[0274] The deployment of the ghost chain may include an arbitration operation by an arbitrator in cooperation with other nodes of the group. The arbitration operation may include receiving evidence from the proposer and the challenger and resolving the challenge based on the evidence. For example, the received evidence may include one or both of a final solution or intermediate results. The intermediate results may be the result of a step or a series of steps required to perform the requested task. For example, the intermediate steps may be partial work products of the task. The final solution may be a final work product that completes the requested task. Evidence may be submitted by the proposer in step 2008 of the exemplary process 2000 and by the challenger in step 2106 of the exemplary process 2100.

[0275] The arbiter and other nodes in the Congress can resolve the challenge by performing a task related to the request to determine the correct solution. For example, the task (e.g., a calculation or algorithm) may be performed on-chain (i.e., on the ghost chain itself).

[0276] By comparing such solutions with the unique solutions determined by the ghost chain, the group can determine whether the proposing or challenging string is correct. During this process, group members (i.e. ghost chain mining nodes) perform calculations and / or analysis to arbitrate the dispute. During this process, group members reach a consensus and sign a block.

[0277] To reduce computational requirements and time delays, the group may perform a binary search procedure while resolving the challenge using the ghost chain. More specifically, the proposer and challenger may each provide one or more intermediate results related to the computation or analysis. Because the inputs of the computation or analysis may be the same for both proposer and challenger (as specified by the requester) and the outputs may differ, there may be transitions between the intermediate steps where the challenger and proposer diverge. Once such a transition is identified, the group need use the ghost chain to perform only the single operation, step, or procedure associated with the transition. In this way, the arbitrator, in cooperation with other nodes, may perform only a portion of the tasks on the ghost chain and determine that either the proposer or challenger made an error in an intermediate step of the task associated with the request. With this binary search approach, the group may not identify a correct solution, but rather an incorrect solution. Because the group does not determine the correct solution, a solution that is not identified as incorrect is not necessarily correct.

[0278] The arbitrator (in cooperation with other nodes in the group) makes a decision while the ghost chain is being deployed. When the arbitrator and other nodes in the congress resolve the challenge (i.e., when such nodes form a consensus on the resolution), a decision can be said to be reached.

[0279] After reaching an arbitration decision on the blockchain, the arbitrator works with other nodes in the group to construct a final transaction (which will be mined into the main blockchain network when fully signed). The final transaction, which may also be called a settlement transaction, may include various digital asset transfers; for example, bounty + deposit (which may be transferred to nodes deemed successful or legitimate during the adjudication process); mining dividends (in case of ghost chain mining that has already been performed); genesis transfer (which may be a digital asset transfer that occurs based on a previous run of the ghost chain and is determined from the genesis block); and / or the return of member deposits for members who have left the group.

[0280] This transaction may also contain useful metadata. For example, a settlement transaction may return a solution to the blockchain network. Thus, during this process, the group (i.e., the arbitrator working with other nodes in the group) can commit the outcome of their decision to the blockchain network. The group can also commit the Merkle root hash of the intermediate computation state that was determined on-chain on the ghost chain to the blockchain network.

[0281] Digital assets under group control may be distributed (by step 2208) by the arbitrator in cooperation with other nodes in the group. Such distribution of digital assets may be performed according to a threshold signature scheme defined for the congress (i.e., for the group). As noted in the discussion of congress above, the threshold signature scheme may be configured such that at least a threshold number of members are required to generate a valid signature on the congress public key. Thus, the arbitrator, together with other nodes in the group (i.e., together with other arbitrators), may agree to the transfer of digital assets by adding a partial signature to the final transaction using the arbitrator's private key shares. The other nodes also add partial signatures using their respective private key shares until they have created a valid signature of the final transaction using at least the threshold number of private key shares required under the threshold signature scheme.

[0282] The particular manner in which the digital assets are distributed in the final transaction may depend on the outcome of the arbitration. For example, if the challenge is successful, the arbitrator, in cooperation with other nodes, may transfer at least the challenger's deposit to the challenger and distribute the proposer's deposit to the mining nodes of the ghost chain in proportion to the absolute number of blocks mined. If the challenge is successful and the challenger's solution is determined to be correct, the bounty may also be transferred to the challenger. Thus, the challenger may receive the digital assets in step 2108 of the exemplary process 2100. However, if a binary search is used such that the correct solution is not identified, the bounty may be returned to the claimant who resubmits the claim, allowing the challenger to submit a proposal based on the answer. Alternatively, if the proposer is eliminated by the binary search, the claimant may treat the challenger's commit as a proposal and resume operation in step 1906 of the exemplary process 1900. That is, the claimant may construct a new transaction T1 based on the challenger's proposal. This transaction may be as described above with reference to step 1906, except that a node previously considered to be a challenger may now be considered to be a proposer. Thus, a new transaction T1 may be constructed to be unlocked by the challenger after the end of the challenge period by providing a solution that corresponds to the hash of the solution provided by the challenger in transaction T2 described above.

[0283] If the proposer's work product is determined to be valid, the arbitrator may cooperate with other nodes to transfer the bounty and the proposer's deposit to the proposer, and distribute the challenger's deposit to the mining nodes of the ghost chain in proportion to the absolute number of blocks mined. The proposer may then receive the digital assets in step 2010 of the exemplary process 2000.

[0284] If both the proposer's and challenger's solutions are incorrect, half of the challenger's deposit and half of the proposer's deposit may be distributed to the mining nodes in proportion to the absolute number of blocks mined. The remaining deposits may be returned to the parties that received them.

[0285] The requester receives the solution at step 1908 of the exemplary process 1900. The manner in which the requester receives the solution at step 1908 may depend on whether a challenge was made. For example, if no challenge was made, the proposer committed the solution to the blockchain using transaction T1 described above with reference to step 1906 of the exemplary process 1900. However, if a challenge was made and a solution to the request is determined by the ghost chain, the ghost chain node may send the solution to the requester at the end of the ghost chain (e.g., at step 2210 of the exemplary process 2200). Thus, the ghost chain protocol allows nodes participating in the ghost chain to automatically send the solution to the requester once they have determined the solution.

[0286] Furthermore, after a decision has been reached on the ghost chain and a transaction has been constructed and validly signed, the ghost chain may terminate (at step 2210 of example process 2200). That is, once the challenge has been resolved, the ghost chain terminates. Once the ghost chain has terminated, information related to the resolution of the challenge may be returned to the proof-of-work blockchain network.

[0287] Once a ghost chain is terminated, no further blocks can be added to it. That is, unlike a typical blockchain, a ghost chain has a terminal block. A ghost chain can be implemented as a proof-of-stake blockchain that does not fork. The absence of forks means that there can be a clear terminal block (i.e. a terminal block that is agreed upon by all nodes in the group) when the ghost chain is terminated. After this terminal block, the ghost chain serves its purpose and cannot be added to.

[0288] As mentioned above, once the arbitrator (i.e., the congress node) reaches a decision, the nodes cooperate to construct a transaction that may be broadcast on the main chain (at step 2208) once a validly signed transaction is generated by the addition of partial signatures via the threshold signature scheme as described above. Since the transaction itself is a multiparty computation, the nodes that contribute to the transaction may receive at least a partial share of the digital assets for participating in the transaction. However, since the transaction is specified before it is signed, the rewards for participating in the signature (including the sending of partial signatures to the ghost chain via the transaction and the actual mining of the block) may be deferred until further deployment of the ghost chain. Such a deferral may be provided at step 2210. More specifically, the leaf block may be constructed with information that allows the genesis distribution to be processed during future deployment of the ghost chain. Such information may be a record of mining distributions that may be attributable to blocks created after the construction of the final transaction, such as blocks created during the signing of the final transaction. That is, the genesis distribution may be designed to be distributed to the nodes that contributed to the signing of the final transaction. The leaf blocks of a ghost chain can become the genesis block of the next ghost chain run (i.e., the next time the ghost chain is deployed), and thus records are made in the leaf blocks for future genesis distributions.

[0289] According to the embodiment shown immediately above, members register / unregister while the ghost chain is running, which may be triggered by a challenge. In alternative embodiments, registering / unregistering at regular intervals or under other conditions is also possible. This may include a scheduled run of a ghost chain dedicated to this purpose, which is similar to the ghost chain deployment described above, except that there is no adjudication and decision stage. In this case, mining dividends may be at least partially distributed from a "registration dividend" that may be required in return for registration.

[0290] Also, note that the exemplary process 2200 described above describes a run of a ghost chain that may not be the first run of a ghost chain. That is, the exemplary process 2200 describes the deployment of a ghost chain that was deployed at some point in the past, and there is already a terminal block that contains a genesis distribution for the ghost chain. The exemplary process 2200 can be modified to allow for the deployment of a first ghost chain. For example, the first time a ghost chain is deployed, the genesis block can be established in a different manner. For example, the genesis block can be provided by an initial trusted party.

[0291] By using a proof-of-stake based blockchain to arbitrate challenges, the ghost chain's solution can provide a faster resolution than performing such arbitration on the proof-of-work blockchain network itself, since proof-of-stake allows for more regular block production and can be configured to allow for high frequency block production. Additionally, by performing such arbitration operations on the ghost chain rather than the main blockchain itself, the load on the main blockchain network is reduced, as tasks can be pushed out of the network.

[0292] Additionally, the ephemeral nature of ghost chains (i.e., the fact that ghost chains are inherently ephemeral and will terminate) may avoid or mitigate the risk of nothing-at-stake issues that typically affect proof-of-stake blockchain networks. Due to the ephemeral nature of ghost chain networks, Congress can require ghost chain mining nodes to leave their stakes in place until the ghost chain is terminated. That is, Congress can be configured to prevent congress members from withdrawing their stakes while the ghost chain is running.

[0293] It should be noted that while the examples above refer to instruction codes available in Bitcoin, the methods described herein can also be used in other types of blockchain networks.

[0294] FIG. 23 illustrates in block diagram form an exemplary computing device 2300 that may be used to implement at least one embodiment of the present disclosure. FIG. 23 illustrates a simplified block diagram of an exemplary computing device 2300 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the exemplary computing device 2300 may be used to implement any of the systems or methods illustrated and described herein. For example, the exemplary computing device 2300 may 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. 23, the exemplary computing device 2300 may include one or more processors 2302 that may be configured to communicate and operably couple with multiple peripheral subsystems via a bus subsystem 2304. These peripheral subsystems may include a storage subsystem 2306 that includes a memory subsystem 2308 and a file storage subsystem 2310, one or more user interface input devices 2312, one or more user interface output devices 2314, and a network interface subsystem 2316. Such storage subsystem 2306 may be used for temporary or long-term storage of information related to the transactions or operations described in this disclosure.

[0295] The bus subsystem 2304 may provide a mechanism for allowing various components and subsystems of the exemplary computing device 2300 to communicate with each other as intended. Although the bus subsystem 2304 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 2316 may provide an interface to other computing devices and networks. The network interface subsystem 2316 may act as an interface for receiving data from the exemplary computing device 2300 and transmitting data to other systems. For example, the network interface subsystem 2316 may enable a user to connect the device to a wireless network or to other networks as described herein. The bus subsystem 2304 may be utilized to communicate data related to transactions or operations described in this disclosure to one or more processors 2302 and / or other entities external to the system via the network interface subsystem 2316.

[0296] The user interface input devices 2312 may include one or more user input devices, such as a keyboard, a pointing device, such as an integrated mouse, trackball, touchpad, or 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 the computing device 2300. The one or more user interface output devices 2314 may include a display subsystem, a printer, or a non-visual display, such as an audio output device. The display subsystem may be a flat panel 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 the computing device 2300. One or more output devices 2314 may be used to present a user interface that facilitates user interaction with applications performing the processes and variations thereof described herein, where such interaction is appropriate.

[0297] The storage subsystem 2306 may provide a computer readable storage medium for storing basic programming and data structures that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) that, when executed by one or more processors, provide functionality of one or more embodiments of the present disclosure may be stored in the storage subsystem 2306. These application modules or instructions may be executed by one or more processors 2302. The storage subsystem 2306 may further provide a repository for storing data used in accordance with the present disclosure. The storage subsystem 2306 may include a memory subsystem 2308 and a file / disk storage subsystem 2310.

[0298] The memory subsystem 2308 may include multiple memories, including a main random access memory (RAM) 2318 for storing instructions and data during program execution, and a read only memory (ROM) 2320 that may store fixed instructions. The file storage subsystem 2310 provides non-transitory persistent (non-volatile) storage (also referred to herein as a non-transitory computer-readable storage medium) for program and data files, and may include hard disk drives, floppy disk drives with associated removable media, compact disk read only memory (CD-ROM) drives, optical drives, removable media cartridges, and other similar storage media.

[0299] The exemplary computing device 2300 may include at least one local clock 2324. The local clock 2324 may be a counter that represents the number of ticks that have occurred since a particular starting date, and may be integrally located within the exemplary computing device 2300. The local clock 2324 may be used to synchronize data transfers among the processors of the exemplary computing device 2300 and all subsystems contained therein at a particular clock pulse, and may be used to coordinate synchronous operations between the exemplary computing device 2300 and other systems within a data center. In one embodiment, the local clock 2324 is an atomic clock. In another embodiment, the local clock is a programmable interval timer.

[0300] The exemplary computing device 2300 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described herein. Additionally, the exemplary computing device 2300 may include another device that may be connected to the exemplary computing device 2300 via one or more ports 2326 (e.g., USB, headphone jack, lighting connector, etc.). The device that may be connected to the exemplary computing device 2300 may include multiple ports configured to receive fiber optic connectors. Thus, the device that may be connected to the exemplary computing device 2300 may be configured to convert optical signals to electrical signals that may be transmitted through ports that connect the device to the exemplary computing device 2300 for processing. Due to the ever-changing nature of computers and networks, the description of the exemplary computing device 2300 shown in FIG. 23 is intended only as a specific example to illustrate an embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 23.

[0301] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, although it will be apparent that various modifications and changes may be made therein without departing from the broader spirit and scope of the invention as set forth in the appended claims.

[0302] Other variations are within the spirit of the disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof have been shown in the drawings and have been described above in detail. It is to be understood, however, that there is no intention to limit the invention to the particular form(s) disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention as defined by the appended claims.

[0303] In the context of describing the disclosed embodiments (particularly in the context of the claims below), the use of the terms "a," "an," "the," and similar referents are to be construed to cover both the singular and the plural, unless otherwise stated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to, the term"), unless otherwise noted. The term "connected," when unmodified and referring to a physical connection, is to be construed as being partially or wholly contained within, attached to, or joined to, even if there is something intervening. Recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of individually referring to each individual value falling within the range, unless otherwise stated herein, unless each individual value is incorporated herein as if it were individually set forth herein. Use of the term "set" (e.g., "set of items") or "subset" should be construed as a non-empty collection that contains one or more members, unless otherwise noted or contradicted by context. Further, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily indicate a proper subset of the corresponding set, and a subset and a corresponding set may be equivalent.

[0304] Connecting language such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" will be understood in context as commonly used to indicate that an item, term, etc. is either A, B, or C, or a non-empty subset of the set A, B, and C, unless otherwise indicated or clearly contradicted by context. For example, in the illustrative example of a three-member set, the connecting phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to either "A," "B," "C," "A,B," "A,C," "B,C," or "A,B,C." Thus, such connecting 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.

[0305] The operations of the processes described herein may be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. The processes described herein (or variations and / or combinations thereof) may be performed under the control of one or more computer systems comprised of executable instructions and may be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) collectively executed by one or more processors. The code may be stored in a computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

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

[0307] This specification describes embodiments of the present disclosure, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventors anticipate that such variations will be employed by those skilled in the art as appropriate, and the inventors intend for the embodiments of the present disclosure to be carried out in ways other than as specifically described herein. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto, as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is included within the scope of the present disclosure, unless otherwise indicated herein or otherwise clearly contradicted by context.

[0308] It should be noted that the above-described embodiments are illustrative rather than limiting of the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, reference signs placed in parentheses shall not be construed as limiting the scope of the claims. Words such as "comprising, having, comprises" do not exclude the presence of elements or steps other than those listed in the claim or the specification as a whole. In this specification, "comprises, comprising" means "includes, including" or "consists of, consisting of". A reference to a singular element does not exclude a reference to a plural of such element and vice versa. The present 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 may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0309] The contents of the claims as originally filed are described below as examples. [Example 1] 1. A computer-implemented method, the computer-implemented method comprising: monitoring a computational task distribution system to detect a challenge to a proposed string provided by a proposing computer system in response to a request made by a requesting computer system, the request specifying a computational task and a first digital asset associated with the request, the proposed string being represented by a hash of a solution to the computational task, and the proposed string specifying a second digital asset referenced in an input to a proposer transaction associated with the proposed string; As a result of detecting said challenge, at least resolving the challenge using a first blockchain network by at least selecting a solution from a set of solutions provided to the first blockchain network, the solution including at least the proposed string; and distributing digital assets according to the first digital asset and the second digital asset to one or more participants of the computational task distribution system based at least in part on the solution. A computer-implemented method. [Example 2] 2. The computer-implemented method of example 1, wherein the proposed side string is selected from the solution set based at least in part on a timestamp associated with the proposed side string. [Example 3] 3. The computer-implemented method of any one of claims 1 to 2, wherein the challenge specifies a hash of a challenger string for the computational task, and the solution set includes the challenger string. [Example 4] 4. The computer-implemented method of any one of claims 1 to 3, wherein the computational task distribution system is implemented as a web service associated with a proof-of-work blockchain network. [Example 5] 4. The computer-implemented method of any one of Examples 1 to 3, wherein the computational task distribution system is implemented on a proof-of-work blockchain network. [Example 6] 6. The computer-implemented method of any one of Examples 1 to 5, wherein the first blockchain network is a proof-of-stake blockchain network. [Example 7] 7. The computer-implemented method of any one of examples 1 to 6, wherein the suggestion string indicates that the computational task has no solution. [Example 8] 8. The computer-implemented method of any one of examples 1 to 7, wherein the challenge indicates that the computational task has no solution. [Example 9] 9. The computer-implemented method of any one of Examples 1 to 8, wherein the digital assets include a deposit provided by a proposer to the first blockchain network. [Example 10] A computer-implemented method as described in any one of Examples 1 to 9, wherein the digital assets are distributed from the first digital asset, the second digital asset, and a third digital asset referenced in an input to the transaction related to the dispute. [Example 11] 11. The computer-implemented method of any one of Examples 1 to 10, wherein resolving the challenge includes performing a set of validation operations corresponding to one or more of the set of solutions. [Example 12] The step of resolving the objection comprises at least receiving from a proposer intermediate results of a first set of the proposer strings with respect to the set of solutions; receiving from the challenger a second set of intermediate results of the challenger strings with respect to said set of solutions; comparing the first set of intermediate results to the second set of intermediate results to determine where the proposer string and the challenger string diverge; Selecting a solution, comprising: repeating the calculation of one or more of the first set of intermediate results at the location using the first blockchain; and 12. The computer-implemented method of any one of Examples 1 to 11, comprising: performing an arbitration procedure using the first blockchain, the arbitration procedure including at least a step of selecting a solution based at least partially on repeating one or more calculations of the second set of intermediate results at the location. [Example 13] The step of resolving the objection comprises at least receiving from a proposer intermediate results of a first set of the proposer strings with respect to the set of solutions; receiving from the challenger a second set of intermediate results of the challenger strings with respect to said set of solutions; analyzing the first set of intermediate results and the second set of intermediate results to identify locations where the proposer string and the challenger string diverge; 13. The computer-implemented method of any one of Examples 1 to 12, comprising at least the steps of: identifying an erroneous solution based at least in part on the analysis; and identifying the erroneous solution of the set of solutions by: [Example 14] 1. A system comprising: A processor; and a memory containing executable instructions that, when executed by the processor, cause the system to perform the computer-implemented method of any one of Examples 1 to 13. system. [Example 15] A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause the computer system to perform at least one of the computer-implemented methods described in any one of Examples 1 to 13.

Claims

1. 1. A computer-implemented method, the computer-implemented method comprising: monitoring a computational task distribution system to detect a challenge to a proposed string provided by a proposing computer system in response to a request made by a requesting computer system, the request specifying a computational task and a first digital asset associated with the request, the proposed string being represented by a hash of a solution to the computational task, and the proposed string specifying a second digital asset referenced in an input to a proposed transaction associated with the proposed string; As a result of detecting said challenge, at least placing the first digital asset and the second digital asset under the exclusive control of a group of nodes via a public key associated with the group of nodes, the first digital asset and the second digital asset being configured to be released when a threshold number of members of the group of nodes generate a valid signature of the public key associated with the group of nodes; resolving the challenge by at least selecting a solution from a set of solutions provided to the first blockchain network using a first blockchain network, the set of solutions including at least the proposed string; and the group of nodes distributing digital assets from the first digital asset and the second digital asset to one or more participants in the computational task distribution system based at least in part on the solution. A computer-implemented method.

2. The computer-implemented method of claim 1 , wherein the proposed side string is selected from the solution set based at least in part on a timestamp associated with the proposed side string.

3. 3. The computer-implemented method of claim 1 or 2, wherein the challenge specifies a hash of a challenger string for the computational task, and the solution set includes the challenger string.

4. 4. The computer-implemented method of claim 1, wherein the computational task distribution system is implemented as a web service associated with a proof-of-work blockchain network.

5. 4. The computer-implemented method of claim 1, wherein the computational task distribution system is implemented on a proof-of-work blockchain network.

6. 6. The computer-implemented method of claim 1, wherein the first blockchain network is a proof-of-stake blockchain network.

7. The computer-implemented method of claim 1 , wherein the suggestion string indicates that the computational task has no solution.

8. The computer-implemented method of claim 1 , wherein the challenge indicates that the computational task has no solution.

9. 9. The computer-implemented method of claim 1, wherein the digital assets include a deposit provided by a proposer to the first blockchain network.

10. 10. The computer-implemented method of claim 1, wherein the digital assets are distributed from the first digital asset, the second digital asset, and a third digital asset referenced in an input to a transaction related to the dispute.

11. 11. The computer-implemented method of claim 1, wherein resolving the challenge comprises performing a set of validation operations corresponding to one or more of the set of solutions.

12. The step of resolving the objection comprises at least receiving from a proposer intermediate results of a first set of the proposer strings with respect to the set of solutions; receiving from the challenger a second set of intermediate results of the challenger strings with respect to said set of solutions; comparing the first set of intermediate results to the second set of intermediate results to determine where the proposing string and the challenging string diverge; Selecting a solution, comprising: repeating the calculation of one or more of the first set of intermediate results at the location using the first block chain; and 12. The computer-implemented method of claim 1, further comprising: performing an arbitration procedure using the first block chain, the arbitration procedure including at least a step of: selecting a solution based at least partially on repeating the computation of one or more of the second set of intermediate results at the location.

13. The step of resolving the objection comprises at least receiving from a proposer intermediate results of a first set of the proposer strings with respect to the set of solutions; receiving from the challenger a second set of intermediate results of the challenger strings with respect to said set of solutions; analyzing the first set of intermediate results and the second set of intermediate results to identify locations where the proposing string and the challenging string diverge; 13. The computer-implemented method of claim 1 , comprising at least the steps of: identifying an erroneous solution based at least in part on the analysis; and identifying the erroneous solution of the set of solutions by:

14. 1. A system comprising: A processor; and a memory containing executable instructions which, upon execution by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 13. system.

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

Images