Rapid decentralized consensus on the blockchain

Abstract

To provide a computer-implemented method.SOLUTION: The method includes: joining, by a node, a group through deposit of digital assets to a public group address to become a group member, where the group is associated with a threshold signature scheme and the deposit of digital assets is made on a proof-of-work blockchain network; and cooperating with other nodes of the group to: detect a challenge, by a challenger, to work product of a proposer in response to a request made by a requester; deploy a ghost chain to resolve the challenge, where the ghost chain is a proof-of-stake blockchain in which miners of the ghost chain are members of the group; and terminate the ghost chain upon resolution of the challenge.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to distributed systems, and in particular to a system for distributed consensus having application to improving the reliability of blockchain transactions in distributed systems. The present invention is particularly, but not exclusively, suitable for use in improving the reliability of computations in computation exchanges. [Background technology]

[0002] The term "blockchain" is used herein to include all forms of electronic, computer-based, distributed ledgers. These include, but are not limited to, blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although Bitcoin is referred to herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system composed of blocks. Blocks are in turn composed of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of tokens between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks are chained together to create 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. Scripts specify how and by whom the output of a transaction can be accessed. On the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Some network nodes, acting as miners, perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on the node performs this verification work on the transactions and unspent transaction outputs (UTXOs) that it references. The verification may be performed by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, and if certain other conditions are met (such as the inclusion of sufficient mining fees), the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the node that received the transaction, and if the transaction is verified, the node relays the transaction 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. A transaction is considered confirmed once a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

[0005] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptocurrency security system on which Bitcoin is based, and the data that can be stored on the blockchain, to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be more diverse in their applications, while still being able to take advantage of the benefits of blockchain (e.g., permanent, tamper-resistant record of events, distributed processes, etc.). Summary of the Invention

[0006] In some such solutions, a distributed consensus may be achieved. For example, unlike many traditional payment systems, blockchains can be highly immutable and often anonymous. The immutable and largely anonymous nature of blockchain technology presents many technical challenges when protecting users from fraud. For example, multiple blocks built on a block containing a transaction make the transaction effectively irreversible, so refunds are often not available and new technical systems are required to maintain the integrity of the transaction. Such challenges are also made difficult by the decentralized and untrusted nature of blockchain technology, i.e., there is no central party that guarantees the integrity of the transaction; instead, the integrity of the transaction is achieved through technical means. It is therefore desirable for blockchain technology to improve the reliability of transactions, such as through the use of digital consensus.

[0007] Trustworthiness challenges can exist in computation exchanges, sometimes called computation marketplaces. A computation marketplace is a service that allows off-chain execution of costly computations. Such exchanges allow nodes in the network to outsource the execution of an algorithm to another remote node. The result of the algorithm is then reported back to the node that outsourced the operation of the algorithm. The node receiving the result may not know whether the result is trustworthy or not. In order for the receiving nodes to determine whether the answer is correct or not, they would need to run the algorithm themselves, which defeats the purpose of outsourcing. It is therefore desirable to improve the trust of the results of computation exchanges in blockchain technology.

[0008] It would therefore be desirable to provide improved methods and apparatus that enhance blockchain technology in one or more of the above aspects.

[0009] Thus, according to the present invention there is provided a method as defined in the accompanying claims.

[0010] Thus, according to the present invention, there may be provided a computer-implemented method, comprising: i) a node joining a group through a transfer of a token to a public group address to become a group member, the group being associated with a threshold signature scheme in which the node controls a private key share, the transfer of token occurring on a proof-of-work blockchain network; ii) a node, in response to a challenge of the work product by a challenger, in cooperation with other nodes of the group, achieving a distributed consensus regarding the correctness of the proposer's work product, the challenge being in response to a request made by a requester, the achieving a distributed consensus comprising: a) deploying a ghost chain to achieve the distributed consensus that resolves the challenge, the ghost chain being a proof-of-stake blockchain in which miners of the ghost chain are members of the group; and b) terminating the ghost chain upon the resolution of the challenge.

[0011] Advantageously, in this manner, a distributed consensus may be achieved among nodes of a blockchain network, and achieving such a distributed consensus using ghost chains may be more efficient than the consensus achieved using proof-of-work blockchains.

[0012] A ghost chain may be an ephemeral blockchain. In contrast to a traditional blockchain, a ghost chain may be configured to terminate, disappear, and / or expire upon execution or meeting one or more criteria, goals, or specified purposes. That is, a ghost chain may be a single-purpose blockchain that ceases to exist once its purpose is accomplished. A ghost chain may include a first block, which may be called a genesis block, that may only be generated when the ghost chain is deployed or generated for its purpose, criteria, or goal.

[0013] In some implementations, a computer-implemented method is provided that includes: i) joining, by a node, a group through depositing digital assets to a public group address to become a group member, the group being associated with a threshold signature scheme in which the node controls a private key share, and the transfer of digital assets occurring on a proof-of-work blockchain network; and ii) by the node, in cooperation with other nodes in the group, a) detecting a challenge by a challenger to a proposer's work product in response to a request made by a requester, b) deploying a ghost chain to resolve the challenge, the ghost chain being a proof-of-stake blockchain in which miners of the ghost chain are members of the group, and c) terminating the ghost chain upon resolution of the challenge.

[0014] The computer-implemented method further includes composing a transaction in cooperation with other nodes of the group, the transaction being payable to the group (i.e., transferring tokens to the group) and having as inputs a bounty and a proposer deposit, and having as outputs the bounty, the proposer deposit, and a challenger deposit, and providing the transaction to the challenger for adding the challenger deposit as an input. The bounty, the proposer deposit, and the challenger deposit are tokens. The bounty and the proposer deposit may be under the exclusive control of the group prior to composing the transaction. For example, the bounty and the proposer deposit may be under the exclusive control of the group upon detection of the challenge within a time period following delivery of a solution to the request by the proposer.

[0015] In some implementations, the computer-implemented method may further include, upon successful challenge, cooperating with other nodes in the group to i) transfer at least the challenger deposit to the challenger, and ii) distribute the proposer deposit to miners of the ghost chain in proportion to the absolute number of blocks mined.

[0016] In some implementations, the computer-implemented method may further include, if the proposer's work product is determined to be valid, i) transferring the bounty and the proposer deposit to the proposer, and ii) distributing the challenger deposit to miners of the ghost chain in proportion to the absolute number of blocks mined.

[0017] In some implementations of the computer-implemented method, the transfer may be performed by the node using the private key share adding partial signatures to the transaction to which other nodes have added partial signatures based on their respective private key shares, until at least the threshold number of private key shares required under the threshold signature scheme have been used to generate a valid signature.

[0018] In some implementations of the computer-implemented method, unfolding the ghost chain to resolve the challenge may include receiving evidence from the proposer and the challenger and resolving the challenge based on the received evidence, which may include one or both of a final solution or intermediate results.

[0019] In some implementations of the computer-implemented method, expanding the ghost chain to resolve the challenge may include executing a task associated with the request on the ghost chain to determine a correct solution.

[0020] In some implementations of the computer-implemented method, unfolding the ghost chain to resolve the challenge may include executing a portion of the task on the ghost chain to determine that either the proposer or the challenger made an error at an intermediate step of a task associated with the request.

[0021] In some implementations of the computer-implemented method, terminating the ghost chain may include forwarding information related to the distributed consensus (i.e., the solution to the challenge) to a proof-of-work blockchain network.

[0022] In some implementations of the computer-implemented method, completing the ghost chain may include constructing a final block that includes a record of a mining fee commission for the block generated during the signing of the final transaction.

[0023] Thus, according to the present invention, there may be provided a computer-implemented method, comprising: i) a node joining a group through a transfer of a token to a public group address to become a group member, the group being associated with a threshold signature scheme in which the node controls a private key share, the transfer of token occurring on a proof-of-work blockchain network; ii) a node, in response to a challenge of the work product by a challenger, in cooperation with other nodes of the group, achieving a distributed consensus regarding the correctness of the proposer's work product, the challenge being in response to a request made by a requester, the achieving a distributed consensus comprising: a) deploying a ghost chain to achieve the distributed consensus that resolves the challenge, the ghost chain being a proof-of-stake blockchain in which miners of the ghost chain are members of the group; and b) terminating the ghost chain upon the resolution of the challenge.

[0024] Advantageously, in this manner, a distributed consensus may be achieved among nodes of a blockchain network, and achieving such a distributed consensus using ghost chains may be more efficient than the consensus achieved using proof-of-work blockchains.

[0025] A ghost chain may be an ephemeral blockchain. In contrast to a traditional blockchain, a ghost chain may be configured to terminate, disappear, and / or expire upon execution or meeting one or more criteria, goals, or specified purposes. That is, a ghost chain may be a single-purpose blockchain that ceases to exist once its purpose is accomplished. A ghost chain may include a first block, which may be called a genesis block, that may only be generated when the ghost chain is deployed or generated for its purpose, criteria, or goal.

[0026] In some implementations, a computer-implemented method is provided that includes: i) joining, by a node, a group through depositing digital assets to a public group address to become a group member, the group being associated with a threshold signature scheme in which the node controls a private key share, and the transfer of digital assets occurring on a proof-of-work blockchain network; and ii) by the node, in cooperation with other nodes in the group, a) detecting a challenge by a challenger to a proposer's work product in response to a request made by a requester, b) deploying a ghost chain to resolve the challenge, the ghost chain being a proof-of-stake blockchain in which miners of the ghost chain are members of the group, and c) terminating the ghost chain upon resolution of the challenge.

[0027] The computer-implemented method further includes composing a transaction in cooperation with other nodes of the group, the transaction being payable to the group (i.e., transferring tokens to the group) and having as inputs a bounty and a proposer deposit, and having as outputs the bounty, the proposer deposit, and a challenger deposit, and providing the transaction to the challenger for adding the challenger deposit as an input. The bounty, the proposer deposit, and the challenger deposit are tokens. The bounty and the proposer deposit may be under the exclusive control of the group prior to composing the transaction. For example, the bounty and the proposer deposit may be under the exclusive control of the group upon detection of the challenge within a time period following delivery of a solution to the request by the proposer.

[0028] In some implementations, the computer-implemented method may further include, upon successful challenge, cooperating with other nodes in the group to i) transfer at least the challenger deposit to the challenger, and ii) distribute the proposer deposit to miners of the ghost chain in proportion to the absolute number of blocks mined.

[0029] In some implementations, the computer-implemented method may further include, if the proposer's work product is determined to be valid, i) transferring the bounty and the proposer deposit to the proposer, and ii) distributing the challenger deposit to miners of the ghost chain in proportion to the absolute number of blocks mined.

[0030] In some implementations of the computer-implemented method, the transfer may be performed by the node using the private key share adding partial signatures to the transaction to which other nodes have added partial signatures based on their respective private key shares, until at least the threshold number of private key shares required under the threshold signature scheme have been used to generate a valid signature.

[0031] In some implementations of the computer-implemented method, unfolding the ghost chain to resolve the challenge may include receiving evidence from the proposer and the challenger and resolving the challenge based on the received evidence, which may include one or both of a final solution or intermediate results.

[0032] In some implementations of the computer-implemented method, expanding the ghost chain to resolve the challenge may include executing a task associated with the request on the ghost chain to determine a correct solution.

[0033] In some implementations of the computer-implemented method, unfolding the ghost chain to resolve the challenge may include executing a portion of the task on the ghost chain to determine that either the proposer or the challenger made an error at an intermediate step of a task associated with the request.

[0034] In some implementations of the computer-implemented method, terminating the ghost chain may include forwarding information related to the distributed consensus (i.e., the solution to the challenge) to a proof-of-work blockchain network.

[0035] In some implementations of the computer-implemented method, completing the ghost chain may include constructing a final block that includes a record of a mining fee commission for the block generated during the signing of the final transaction.

[0036] 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 executables that, when executed, configure the processor to perform a method as described herein.

[0037] 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.

[0038] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0039] [Figure 1] FIG. 1 illustrates a block diagram of an exemplary blockchain network. [Diagram 2] FIG. 1 illustrates a block diagram of an example electronic device that can function as a node in a blockchain network. [Diagram 3] 1 is a flow chart of an exemplary method for initiating a congress. [Figure 4] 1 is a flow chart of an exemplary method of participating in a council. [Diagram 5] 1 is a flow chart of an exemplary method for seizing a token. [Figure 6] 1 is a flow chart of an exemplary method for redistributing key shares. [Figure 7]13 is a flow chart of a further exemplary method for redistributing key shares. [Figure 8] 1 is a flow chart of an exemplary method for reverting before transfer of a token to a council. [Figure 9] FIG. 1 is a block diagram of an exemplary blockchain and an exemplary ghost chain. [Figure 10] 1 is a flowchart of an example requestor method for requesting the completion of a task. [Figure 11] 1 is a flowchart of an example proposer method for proposing a solution to a task. [Figure 12] 4 is a flow chart of an example challenger method for challenging a solution to a task. [Figure 13] 1 is a flowchart of an exemplary method for reaching a consensus among cooperating nodes in response to a solution challenge to a task. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0040] <Blockchain network> Reference is first made to Figure 1. Figure 1 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 may join without invitation or approval from other members. The blockchain network 100 operates under a blockchain protocol, and distributed electronic devices running instances of the 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.

[0041] The electronic devices that execute the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, 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.

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

[0043] Nodes 102 maintain a global ledger of all transactions on the blockchain. The global ledger is therefore 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 secured blockchain, transactions by nodes 102 that affect the global ledger are verified by other nodes 102. As a result, the validity of the global ledger is maintained. When the blockchain is a proof-of-work based blockchain, blocks are also verified by checking the proof-of-work submitted with the block.

[0044] At least some of the nodes 102 act as miners 104 of the blockchain network 100. The blockchain network 100 of FIG. 1 is a proof-of-work blockchain in which miners 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, miners 104 discover a nonce. The resulting block header is hashed by SHA-256 to a number less than a value determined by the current mining difficulty. The hashing power required for the proof-of-work algorithm means that a transaction is considered effectively irreversible after a certain number of blocks have been mined on it. The miner 104 who solves the cryptographic problem generates a new block of the blockchain and broadcasts the new block to the other nodes 102. The other nodes 102 verify that the miner 104 has indeed solved the cryptographic problem and thus established sufficient proof-of-work before accepting that the block should be added to the blockchain. Blocks are added to the blockchain (i.e., the distributed global ledger) by consensus of the nodes 102.

[0045] Blocks generated by miners 104 include transactions that have been broadcast to the blockchain by nodes 102. For example, a block may include a transaction from an address associated with one of the nodes 102 to an address associated with another of the nodes 102. In this way, a block serves as a record of transactions from one address to another. The party that requested a transaction to be included in a block proves that they are authorized to initiate the transfer (e.g., in the case of Bitcoin, to spend Bitcoin) by signing the request with a private key that corresponds to their public key. Only if the request is validly signed may the transfer be added to the block.

[0046] In Bitcoin, there is a one-to-one correspondence between public keys and addresses; that is, each public key is associated with a single address. Thus, references herein to transferring tokens to or from a public key (e.g., paying a public key) and to transferring tokens to or from an address associated with a public key refer to a common action.

[0047] Some of the nodes 102 may not act as miners, but instead participate as validating nodes. Validating a transaction may involve checking signatures, verifying references to valid UTXOs, etc.

[0048] The example of Figure 1 includes five nodes 102, three of which participate as miners 104. In practice, the number of nodes 102 or miners 104 may be different. In many blockchain networks, the number of nodes 102 and miners 104 may be much greater than the number shown in Figure 1.

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

[0050] The council 110 is an open membership group that may be joined by any node 102 by submitting a sufficient stake to a pool associated with the council 110. For example, a node may join a council through the transfer of one or more tokens or digital assets to an account associated with the council 110. Nodes 102 that join a council may be any nodes in the blockchain network, including both mining and non-mining nodes. In at least some applications of a council, nodes acting as council members monitor the blockchain in the sense that they download (but do not necessarily retain) the complete blockchain.

[0051] Techniques for joining, leaving, and joining the council 110 are discussed in detail below.

[0052] As described in more detail below, members of the congress may form a temporary ghost chain network 120. The ghost chain first blockchain network creates and maintains a distributed ledger called a ghost chain. The ghost chain network 120 may be deployed during transactions to verify the authenticity or to reach a distributed consensus on whether a particular objective solution is correct in response to the occurrence of a challenge to the objective solution. For example, the ghost chain network 120 may be deployed to verify the integrity of a processor-generated work product, which may be a work product submitted by a node 102 of the blockchain network 100. For example, the ghost chain network 120 may be deployed to reach a distributed consensus on the correctness of a result generated on the blockchain network 100. A dispute regarding the correctness of a result may exist when the authenticity of a processor-generated work product of one node is challenged by another node.

[0053] A ghost chain is an ephemeral blockchain. Unlike traditional blockchains, a ghost chain is configured to terminate once its purpose is accomplished. That is, a ghost chain is a single-purpose blockchain that ceases to exist once its purpose is accomplished. A ghost chain contains a first block, which may be called a genesis block, that is generated only when the ghost chain is deployed for its purpose (e.g., to verify the integrity of the work product generated by a processor).

[0054] The blockchain associated with the blockchain network is a proof-of-work blockchain, while the ghost chain is a proof-of-stake blockchain. A proof-of-stake based ghost chain network 120 provides an alternative mechanism for achieving consensus. In a proof-of-stake ghost chain network, the blockchain is secured by proof-of-stake instead of proof-of-work. Under proof-of-stake, ghost chain miners 125 transfer tokens, where token holdings are represented by a digital ledger of the proof-of-work blockchain like security, and the probability of being selected as a node to mine a block is proportional to the amount of tokens transferred. A proof-of-stake blockchain system can be used to avoid the computational expense and energy required to mine on a proof-of-work blockchain. Additionally, a proof-of-stake blockchain can allow for higher frequency and more regular block generation than a proof-of-work blockchain.

[0055] A number of nodes 102 act as miners 125 of the ghost chain network 120. At least some of the miners 125 of the ghost chain network 120 may not act as miners 104 of the blockchain network 100. Because the ghost chain network 120 is a proof-of-stake blockchain network, the miners 125 transfer tokens to be included as miners. In particular, the ghost chain miners 125 form a combined validator set to mine on the ghost chain network 120. These miners 125 are also members of the council 110 associated with the blockchain network 100. That is, the nodes 102 that are part of both the proof-of-work blockchain network 100 and the ghost chain network 120 act as miners 125 of the ghost chain network 120 and as members of the council 110 established on the proof-of-work blockchain network 100. These miners 125 join and participate in the council 110 according to a method described below. Their transfer of tokens to the council pool occurs within the proof-of-work blockchain: council members transfer their "stake" on the proof-of-work first blockchain network 100 to the pool to become council members and form a combined validator set, allowing them to act as miners 125 on the ghost chain. The council 110 is an open membership group that may be joined by any node by submitting a sufficient stake to the pool associated with the council 110.

[0056] <Electronic devices acting as nodes> 2 is a block diagram illustrating components of an example electronic device 200 that may function as a node 102 (FIG. 1) in a peer-to-peer blockchain network 100 (FIG. 1). 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 form.

[0057] 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 a computer software program 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 (FIG. 1). For example, the instructions may include instructions for implementing the Bitcoin protocol.

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

[0059] 2, in practice, 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 internal memory.

[0060] As shown in FIG. 2, the processor 210 may include a secure domain such as a Trusted Execution Environment (TEE) 250. The TEE 250 is an isolated execution environment that provides additional security to the electronic device 200, such as isolated execution, trusted application integrity, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded inside the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 may be used to protect the integrity and confidentiality of critical resources, such as keys. The TEE 250 is implemented at least partially at the hardware level. As a result, the instructions and data executed within the TEE 250 are 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 are secured from the party that operates the node 102 that includes the TEE 250.

[0061] The TEE 250 instantiates an enclave and may then operate to add memory pages one by one, while cumulatively hashing. Similar operations may be performed on a remote machine (which may be the developer's machine or another machine). As a result, the remote machine determines and stores the expected hash. The contents of the enclave can thus be verified by any remote machine, ensuring that the enclave is running an approved algorithm. This verification may be performed by comparing hashes. Once the enclave is fully constructed, it is fixed. It is possible to run code within the TEE 250 and send secrets to the code, but the code cannot be changed. The final hash may be signed by an attestation key and made available to the data owner to verify it before he sends any secrets to the enclave.

[0062] The TEE 250 may be used to protect the confidentiality and integrity of private key shares associated with the council public key used by the council 110 (FIG. 1). For example, the TEE 250 may be used for the generation and storage of private key shares. The TEE 250 is to ensure that no member can directly obtain information about the private key shares or other private key shares held in the TEE 250 from inter-member or inter-enclave communications. The protocol is robust against a threshold of enclave compromise. Additionally, the TEE 250 may enable remote attestation. Remote attestation may be used by a node 102 (FIG. 1) to attest to other nodes 102 that the TEE 250 is authentic and is executing approved computer-executable instructions for the protocols implemented by the council 110. Remote attestation may be provided by the TEE 250 by executing a particular piece of code and sending a hash of the code inside the enclave, signed by the enclave's internal attestation key.

[0063] The TEE 250 may be used to attest to the secure deletion of private key shares when a member of the assembly 110 who has previously used a private key share on the electronic device 200 chooses to leave the assembly. The electronic device 200 may communicate the attestation of the deletion to other assembly members through a remote attestation protocol provided within the TEE 250. The attestation of the deletion may be required before a member is allowed to reinstate their previous transfers to the assembly pool once they become a member of the assembly. That is, the reinstatement of a transfer may be conditional on the attestation of the deletion of the private key shares held within the member's enclave.

[0064] The TEE 250 may include a secure random number generator that is internal to the TEE's enclave and can 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.

[0065] The TEE 250 may be implemented using various platforms such as a Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). SGX, for example, supports remote attestation. Remote attestation allows an enclave to obtain signed statements from a processor running a particular enclave with a given has of members, known as a quote. A third-party attestation service such as the Intel Attestation Service (IAS) can certify that these attested statements originate from a genuine CPU that conforms to the SGX specification.

[0066] The electronic device 200 may operate as a node 102 (FIG. 1) in the blockchain network 100 (FIG. 1) and may join or otherwise participate in a council 110 (FIG. 1). A council 110 is formed when a group of token bearers pools tokens or stakes or value supported by the blockchain network 100 (FIG. 1).

[0067] <Congress and Threshold Signature> The council 110 may be a permissioned or unpermissioned group. That is, the council 110 may be joined by any node 102 (FIG. 1) in the blockchain network 100 (FIG. 1) (i.e., by any node that monitors and stores at least a portion of the information in the blockchain). To join the council 110, a node 102 transfers one or more tokens to a pool associated with the council 110 (i.e., to a public group address associated with one or more tokens, where the one or more tokens are associated with other members of the council). This pool may be called a council pool. For example, a node 102 may join the council 110 by transferring such tokens to an address associated with the council pool (i.e., to a "council address", which may also be called a public group address). In effect, the transfer acts as a deposit of some digital assets into the council pool. The tokens are under the control of a group threshold signature with a single public key, called the council public key. The council members hold private key shares generated by a distribution method. The number of shares held may be proportional to the amount transferred to the pool.

[0068] Tokens controlled by Council 110, including any tokens transferred to a Council address, are under the control of a threshold signature scheme. Under a threshold signature scheme, a group of members whose combined private key share holdings exceed a threshold must generate a valid signature that allows a token to be transferred away from the control of Council 110. That is, at least the threshold number of private key shares must be used to generate a valid signature for any outgoing transfer of a token controlled by Council 110.

[0069] The Congress public key encumbers tokens transferred to the Congress pool by members of Congress 110 in exchange for private key shares, and any tokens transferred to an address associated with the Congress pool by members or non-members of Congress 110 that are deposited for reasons other than obtaining private key shares (i.e., placed under the control of Congress in whole, in part, or conditionally). Non-members or members may transfer tokens to an address associated with a Congress for a variety of reasons.

[0070] Since the same council public key may prevent both member transfers (i.e., tokens provided by council members in exchange for private key shares) and tokens provided by members or non-members for other purposes, at least some transfers to addresses associated with the council may be given special attention to indicate the type of token. For example, a transaction transferring tokens to a council address may include a flag, identifier, or other attribute indicating the characteristics of the token being generated. As an example, a transaction transferring tokens to a council address that are not generated for the purpose of joining a council or raising stakes in council membership may include a special identifier to indicate that the transfer is generated for another purpose. Such an identifier may be used by the nodes 102 associated with the council 110 when managing private key generation. In particular, a node 102 that transfers tokens for the purpose of joining a group will be assigned a private key share of the council 110 (as a result of making the token transfer). Meanwhile, other nodes 102 that transfer tokens for other purposes (e.g., to transfer to a sidechain) may not hold the council private key share of the council (corresponding to the council public key).

[0071] The council 110 may operate as an autonomous group where cooperative behavior is enforced through the threat of confiscation of all or part of the tokens transferred to the pool by a given member. Non-cooperative or dishonest members may have such tokens confiscated through participation in a cooperative protocol by a majority of honest members.

[0072] Additionally, when a council member wishes to leave council 110, they may request a reversal of their transfers (i.e., request that council 110 transfer tokens previously transferred by the member to the pool back to the member's personal address). In effect, such council members may request a withdrawal of their prior deposits into the pool of digital assets. However, the withdrawal of funds can only be performed if a number of private key shares exceeding a threshold number required to generate a valid digital signature are used by the members of the group (i.e., council) to authorize the withdrawal.

[0073] Threshold signature schemes implemented by council 110 may be of various kinds. A threshold signature scheme allows the ability to share a signature among n parties as long as at least a threshold number of private key shares contribute to generating a valid signature. Any subset less than the threshold cannot generate a valid signature. In particular, each of the parties controls a share of a private signature key, and a threshold number of key shares must be used to generate a valid signature through the combination of partial signatures. Any subset of key shares less than the threshold cannot generate a valid signature through the combination of partial signatures.

[0074] The threshold signature scheme may be an Elliptic Curve Digital Signature Algorithm (ECDSA) scheme. For example, the ECDSA scheme is described in "A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme" by Ibrahim et al., 2003 EIII 46 thIt 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 a digital signature scheme that is an algorithm based on elliptic curve cryptography, where t + 1 key shares from n key share holders are required to reconstruct the secret key. This scheme may be used to construct valid signatures without the need to reconstruct the secret key and without any party having to disclose their key share to another party.

[0075] Since t + 1 key shares are sufficient to reconstruct the secret, the maximum number of allowable adversaries by this technology is t. An adversary is a corrupted entity that holds secret shares and has access to the secret shares in the model of Ibrahim et al. Adversaries can be of various types. For example, a Byzantine adversary is an adversary who can participate in the protocol while actually sending incorrect information. The ECDSA scheme proposed by Ibrahim is robust against up to t <= n / 4 malicious adversaries. This robustness can be increased up to t = < n / 3, but at the cost of greater complexity.

[0076] The ECDSA scheme of Ibrahim et al. is robust against up to t = < n / 3 static adversaries. A static adversary can prevent a corrupted party from participating in the protocol or stop their participation midway.

[0077] The ECDSA scheme includes various mechanisms that can be used by the nodes 102 to identify dishonest or non-cooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomials necessary for Shamir's Secret Sharing (SSS). SSS is a form of secret sharing in which the secret is split into parts and provided to each participant in its own unique part. These parts may be necessary to reconstruct the secret. VSS can be used by the nodes 102 to identify dishonest nodes 102 or members if inconsistent shares are provided to different nodes 102 or if shares are transmitted secretly to nodes, as opposed to hidden shares, where shares are broadcast to all nodes. Inconsistent shares can be identified by any of the nodes 102. Secret sharing can be made verifiable by including auxiliary information that allows the nodes 102 to verify their shares as consistent.

[0078] The transmission of fraudulent shares to individual nodes (i.e., shares that are different from the broadcasted hidden shares) can be identified by the intended recipients of the shares. The identification of fraudulent shares being transmitted in secret to nodes can be made publicly verifiable using techniques known as 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 recipients of the fraudulent shares are offline or disconnected from the root of the network when the fraudulent shares are transmitted.

[0079] Misbehavior such as providing inconsistent shares to different nodes can be resolved by the council 110 to prevent malicious behavior. For example, when a node 102 (FIG. 1) is identified as a misbehaving party by other nodes 102, members of the node 102 (i.e., nodes associated with council members) over a threshold (e.g., t+1) may cooperate to penalize the misbehaving party. For example, the node 102 may take action related to tokens (such as tokens or other stakes or value) transferred (i.e., deposited) to the council by the misbehaving party. For example, the council may burn digital currency, tokens, stakes, or value by transferring them to an unusable address. Alternatively, the council may confiscate such tokens by refusing to authorize their return to the misbehaving party. Non-misbehaving nodes 102 may prevent misbehaving by cooperating to exclude the misbehaving node (e.g., by effectively invalidating key shares, e.g., by excluding the node from participating in the council protocol, or by re-sharing private keys and not allocating shares to the misbehaving node).

[0080] The ECDSA technique described above may be extended through the use of TEEs. For example, the threshold ECDSA signature technique based on Ibrahim et al. anticipates a strong form of adversary, referred to here as a Byzantine adversary. This type of adversary may behave arbitrarily. For example, they may not only refuse to participate in the signing process or stop a party midway, but may also pretend to participate honestly and transmit fraudulent information. However, by using a TEE and generating the data to be used for signing within an enclave of the TEE where the secret private key shares are stored, additional security may be provided since the enclave is highly unlikely to be compromised in any significant number. If each TEE is assigned more than one key share, for example, the number of potentially compromised TEEs may be reasonably expected not to approach the adversarial robustness threshold, assuming n is sufficiently large. This allows the protocol to be secure if it is resistant to a small proportion of fraudulent adversaries relative to the total number of key shares.

[0081] For example, if every node has a TEE, obtaining secrets stored in the enclave can only be achieved by physical access to the node, and only with great effort and expense, unless the manufacturer of the TEE is corrupt. Such manufacturer-level corruption is expected to be manageable. For example, if a manufacturer tries to falsely claim that a large number of public keys correspond to honest TEEs, they could gain direct access to the private key shares and launch an attack. However, such an attack may require a sufficient number of key shares for the manufacturer to be able to generate valid signatures without assistance from other nodes. This may mean accumulating a large portion of the total stake, which can be very expensive. Furthermore, carrying out an attack may destroy a large portion of the value of the stake held.

[0082] When a TEE is used, it is useful to contemplate the robustness of the protocol against “corrupted nodes”. A corrupted node is a node whose hardware outside the TEE contains errors, but whose integrity of the TEE is not compromised. A corrupted node may have control over what information the enclave does and does not receive. In particular, a corrupted node may suspend, 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 within the enclave (if the corresponding public key was authenticated during attestation), then the private key is as trustworthy as the enclave itself. Thus, a corrupted node cannot send arbitrary (authenticated) information to the protocol, but only tries to interfere by suspending or by trying to trick the enclave into behaving incorrectly, for example by providing stale information. Then, with a corrupted node, a successful attack may require collecting a sufficient number of partial signatures to generate a complete signature. With a TEE, the Ibrahim et al. protocol is robust against 2t corrupted nodes. Since signatures can be generated for n-2t>=2t+1, any regular subset of the key shares of size 2t+1<=(n+1) / 2 suffices. Thus, when a TEE is used, the threshold of a threshold signature scheme may be configured to be a number equal to or greater than 50% of the key shares in order to generate valid signatures in the presence of corrupt nodes.

[0083] Other threshold signature schemes may be used. For example, the threshold signature scheme may be an ECDSA threshold scheme of the kind proposed by Goldfeder et al., "Securing Bitcoin Wallets Via a New DSA / ECDSA threshold signature scheme" (2015). This protocol allows t+l parties to generate valid signatures. Thus, the number of key shares that an adversary must control to generate a valid signature is 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 unanimous agreement is required to generate a valid signature. In the most general case, this scheme imposes space requirements that grow exponentially with the number of parliament members, since the entire protocol must be repeated for any possible subset of t+l players out of n for any threshold. Thus, for large values ​​of both n and t, a huge number of key shares need to be stored. To mitigate such storage requirements, standard Bitcoin multisignatures may be combined with threshold signatures. In particular, tokens may be locked using multisignatures. As a result, each private key is divided into shares. This technique can be more efficient in terms of space requirements for larger conferences. Scaling properties can also be improved by constructing the scheme in a multi-level, iterative manner for large numbers of participants of smaller party sizes. For example, the threshold signature scheme can be combined with the technique of Cohen et al., "Efficient Multiparty Protocols via Log-Depth Threshold Formulae" (2013), Advances in Cryptology-CRYPTO 2013 pp185-202.

[0084] Other threshold schemes may be used, including non-ECDSA signature schemes. For example, a threshold scheme based on the Schnorr scheme may be used by the nodes 102 to implement the council 110.

[0085] A node 102 (FIG. 1) in a blockchain network 100 (FIG. 1) may implement a parliament protocol based on a selected threshold signature scheme. Such a node 102 may include computer-executable instructions stored in memory 220 (FIG. 2) that implement the parliament protocol. Such instructions, when executed by a processor 210 (FIG. 2), cause a node 102 (such as an electronic device 200 of the type described with reference to FIG. 2) to perform one or more methods of the parliament protocol. Such methods may include any one or combination of the methods 300, 400, 500, 600, 700, 800, 1000 of FIGS. 4-8 and 10. Thus, the parliament protocol may include one or more of the methods 300, 400, 500, 600, 700, 800, 1000 of FIGS. 4-8 and 10. The methods may be performed by the node in cooperation with other nodes associated with other parliament members.

[0086] <Start of the Assembly> 3, a method 300 for initiating a parliament 110 is shown. The method 300 may be performed by an initial trusted party to establish the parliament 110. A node 102 associated with the initial trusted party may perform the method 300.

[0087] The method 300 includes providing a parliament public key at operation 302. The parliament public key may be provided to other nodes 102 so that other nodes can pay for the parliament public key if they wish to join the parliament, i.e., other nodes may transfer a token to an address associated with the parliament public key to join the parliament.

[0088] The node 102 executing method 300 allows payments for the public key until one or more conditions are met, at operation 304. For example, the node may allow payments for 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 a number of blocks), the node 102 executing method 300 identifies the initial members of the council, at operation 306.

[0089] After the parties that will make up the initial members of the parliament have been identified, the private key is divided into private key shares according to a threshold signature scheme in operation 307. The private key shares are then distributed to the identified parties from the node 102 executing the method 300 in operation 308. The private key shares are associated with a threshold signature scheme, which may be of the type described herein.

[0090] During operation 308, the nodes 102 identified as council members cooperate to generate new private key shares and new public keys. The original key shares originally sent to such nodes by the trusted party may be used to sign and broadcast a transaction that sends all tokens in the council pool to the new public key, which then becomes the council public key. That is, during operation 408, a new group public address is established and the tokens under the control of the council are transferred to this new address. This new address becomes the new address of the group and is associated with the council public key. After this transfer is confirmed, the council cannot operate trustlessly. The new group public address is created and future transfers of tokens are received to it from other nodes that wish to join the council 110 or for other purposes as described above. The council members are now considered to have joined the council, and these nodes can now operate without the assistance of the originally trusted party. Furthermore, the originally trusted party no longer plays any role in the operation of the council.

[0091] <Joining the Congress after it has begun> Referring to FIG. 4, FIG. 4 illustrates a method 400 for joining a council. The method 400 of FIG. 4 may operate in conjunction with the method 300 of FIG. 3, but the method 400 of FIG. 4 is performed by another of the nodes 102 operating within the same blockchain network 100 (FIG. 1) as the node performing the method 300 of FIG. 3 operates. The method 400 of FIG. 4 includes, at operation 402, obtaining a council public key. The council public key may be obtained directly from a party initiating the council, such as the node performing the method 300 of FIG. 3. Alternatively, the council public key may be obtained from a third party, including, for example, a third-party system operating outside the blockchain network 100 (FIG. 1). For example, the council public key may be obtained from a public web server accessible via the public Internet.

[0092] At operation 404, the node 102 executing the method 400 pays the congress public key by broadcasting a transaction of tokens from a private account associated with the node 102 to a congress address (i.e., an address associated with the congress public key). In particular, the node 102 broadcasts a transaction to transfer one or more tokens to a public group address associated with the congress public key. The public group address is an address for the congress pool. The congress pool contains other tokens associated with other members of the congress. Thus, at operation 404, the transaction, when added to a block by the miner 104 (FIG. 1), transfers the tokens to the congress pool, which contains tokens from other members. The public group address may receive both transfers from parties that want to join the congress and transfers from parties that do not want to join the congress. Parties that do not want to join the congress transfer their tokens to the congress pool. As a result, the tokens may be under full, partial, or conditional control by the congress using a threshold signature scheme used by the congress.

[0093] The transaction in operation 404 may include a flag, identifier, or other attribute indicating that the party transferring the tokens wishes to join the Congress and that the transfer is being generated for such purposes.

[0094] After transferring the token to the council pool, the node 102 executing the method 400 receives the private key share at operation 406. The node 102 then regenerates the private key share by executing a single instance of the protocol at operation 408. The generation of the private key share may be performed within the TEE of the node 102.

[0095] At operation 408, node 102 generates private key shares to 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. The other holders of the private key shares are other members of the congress who have joined the congress on an permissioned or unauthorized basis by transfer of their respective tokens to the public group address.

[0096] To regenerate the secret key shares, the existing council members may cooperate to update the key shares in operation 408. For example, the nodes 102 may generate a random polynomial f of degree t with a constant term of zero. 0 n+1 Node 102 may then generate point f(x). 0 n+1 (n+1) and set this as their private key share. The nodes 102 may then compute this polynomial f 0 n+1 (i) The point above may be distributed to each of the existing parliament members, i=1,...,n. Each existing parliament member (i=1,...,n) then adds the received value to their existing private key share to obtain a new private key share. Node 102 now has an equal private key share with all other members, and the corresponding public key remains unchanged. As mentioned above, threshold signature schemes may be of various types, including threshold schemes based on Elliptic Curve Digital Signature Algorithms or Schnorr schemes.

[0097] The private key shares may be generated within the TEE 250 (FIG. 2) and securely stored in the node 102. For example, the private key shares may be stored in the TEE 250.

[0098] 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 (through 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.

[0099] After the private key shares are generated in operation 408, they may be used in operation 410 of method 400. The private key shares may be used to collaboratively generate valid signatures for transactions from the public group address that may be broadcast by the members. That is, the private key shares may be used in a threshold signature scheme to contribute to signature generation. Under a threshold signature scheme, a threshold number of private key shares of the council must be used by each member to generate a valid signature that allows a token to be transferred away from the council. The node 102 executing method 400 may read the private key shares from storage and use the private key shares to contribute to signature generation. If a sufficient number of other council members also use their respective private keys to contribute to signature generation, a signature may be generated and a valid outgoing transaction may be broadcast. The outgoing transaction is completed when the miners 104 (FIG. 1) of the blockchain network 100 add the transaction to a mined block that is added to the blockchain by consensus of the nodes 102 in the blockchain network 100 and the block is confirmed. At this point, the tokens presented in the transaction may no longer be under the control of the council. That is, such tokens may no longer be encumbered by the Congress public key.

[0100] The use of the private key shares in operation 408 may be performed within the TEE of node 102. The TEE protects the private key shares. As a result, neither other parts of the system nor the members themselves can access any data stored in the enclave, such as the private key shares. Additionally, the TEE protects the private key in that it cannot retain a copy of the private key, since if a member wants to return their transfer and receive a return of their transfer, they must prove the deletion of the private key before their transfer is returned.

[0101] Method 400 of Figure 4 may be performed during or after an initial stage, i.e., method 400 may be performed before the initial key shares are distributed (e.g., during operation 308 of method 300 of Figure 3) or after (e.g., during a rebalancing, as described in more detail below).

[0102] The transaction at operation 410 may transfer the tokens back to the party that originally transferred the tokens to the congress pool. That is, the transfer may return the tokens to the party. The transfer may also transfer the digital assets to another location. For example, the tokens may be transferred to a third party or to an unusable address.

[0103] <Token confiscation> Referring to Figure 5, an example method 500 for forfeiting tokens is shown. Method 500 of Figure 5 may be performed by node 102, which may be the same node that performs method 400 of Figure 4. Method 500 may be performed after operation 408 of method 400 of Figure 4. As a result, node 102 already has access to the private key shares when method 500 of Figure 5 is performed.

[0104] At operation 502, node 102 detects fraudulent activity by a dishonest party. The dishonest party may be another member of the assembly. The dishonest activity is detected when node 102 determines that the assembly member is violating a predefined protocol or standard. For example, when a node that is a member of the assembly reports erroneous information (i.e., false, fraudulent, or otherwise unacceptable information) to other members of the assembly, the member may be deemed to be a dishonest member.

[0105] In operation 503, in response to detecting the fraudulent activity, node 102, in cooperation with other nodes in the council, may suspend the member who is the fraudulent party, i.e., the council may exclude the fraudulent party from further participation in the council.

[0106] To ensure that all nodes 102 operate according to a predefined protocol or standard, a member's transfer to the congress pool may be subject to forfeiture. Forfeiture means permanently preventing the return of a member's transfer deemed forfeited. Tokens forming a member's transfer that are not returned due to misconduct may remain in the congress pool, but are not returned, transferred immediately or in the future to another unusable address, or otherwise confiscated. The nature of the forfeiture may depend on whether the congress acts as a combined set of validators for the side chain. For example, in operation 504, in response to detecting misconduct by a fraudulent party, a node 102 executing method 500 may use a private key share to provide a partial signature for the forfeit transaction. That is, the node cooperates with other nodes in the congress to forfeit at least a portion of the tokens previously transferred by the fraudulent party to a public group address (i.e., to the congress pool). That is, in response to observing that a group member violates a predefined protocol or standard, the private key share is utilized to contribute to the authentication of a transaction of one or more tokens held in the congress pool associated with the group member.

[0107] Because a threshold signature scheme is used with the council public key, an individual node acting alone cannot redirect another council member's transfer of tokens away from the council pool (e.g., to an unusable address). Rather, tokens can only be confiscated by transfer when a threshold number of private key shares are used to generate a valid signature by their respective members to transfer the tokens to another address, or when a group of members with at least the threshold number of private key shares reach a consensus to suspend the member (at operation 503), which causes a withdrawal request from the suspended member to be automatically ignored. Once tokens are confiscated by transfer, the other address to which the tokens may be transferred may be associated with the unusable address. For example, the other address may be an address without a private key. As a result, no party can access the tokens bound by the public key of the address. Once tokens are transferred to an unusable address, they may be considered burned, since they can no longer be used by any member of the council or indeed by any node in the blockchain network 100.

[0108] Thus, in operation 504, the node may confiscate tokens by using its private key share in cooperation with other members of the council to generate a valid signature for a transaction to the unusable address.

[0109] Furthermore, in some implementations, the council may act as a joint set of validators that secure a proof-of-stake sidechain. This sidechain may be used as a broadcast channel. For example, a consensus may be reached by council members on a sidechain on which a member has been acting dishonestly. This consensus may correspond to the confirmation of a sidechain transaction that includes denouncing evidence of dishonesty. Once consensus is reached, any request to recover a member's transfer made by a dishonest member is denied and the transfer is considered confiscated. All or part of the confiscated tokens may be burnt at some future time. That is, at some later time, a threshold number of members (not including the dishonest member) may cooperate to authorize the transfer of the confiscated tokens to a disabled address. Some or all of the tokens may instead be sent as a reward to the nodes that provided evidence of the member's dishonesty.

[0110] Since the council is an open group that may be joined by any node 102 of the blockchain network 100 through the transfer of tokens, group membership may change periodically. When such changes occur, the private key share distribution may be updated. Referring to FIG. 6, an example method 600 for updating the private key share distribution is shown. The method 600 may be performed by a node 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0111] <Update private key share distribution with new public address> At operation 602 of method 600, node 102 detects a redistribution request. A redistribution request is a request whose fulfillment involves a redistribution of key shares. For example, node 102 may detect that a prospective new member has transferred tokens to a public group address or that an existing member has requested a withdrawal of a member transfer.

[0112] Tokens may be transferred to the public group address (i.e., to the council pool) by nodes requesting to join the council or to increase their involvement in the council, or by other nodes that do not request to join the council but instead transfer tokens to the council for another purpose (e.g., transferring tokens to a sidechain as described above). In operation 602, node 102 may identify council members (i.e., parties that transferred tokens to the council public key in order to join the council and not for another purpose) using one or more attributes included in at least a portion of the transaction of tokens to the public group address. For example, a particular transaction may be flagged as a special transaction using an attribute in the transaction. Such an attribute (or its presence or absence) may indicate the purpose for which the transfer is made. For example, a flag may be included in the transaction when the transferor is not requesting to join the council.

[0113] In response to detecting the request in operation 602, fulfilling the request involves a redistribution of key shares in operation 604. New private key shares are generated by node 102 in a manner similar to how the private key shares were generated in operation 408 of method 400 of FIG. 4. The other member nodes of the parliament also generate their own private key shares. These private key shares may be used in a threshold signature scheme against the new parliament public key. Members who leave the parliament at this point do not generate new private key shares during operation 604. Because they are not assigned private key shares for use with the new parliament public key, they lose the ability to participate in the parliament and are no longer considered parliament members.

[0114] Further, in response to detecting a redistribution request (which is a request whose fulfillment involves a redistribution of key shares), in operation 606, node 102, in cooperation with other council members, transfers all of the tokens in the public group address to a new public address associated with the new public key (which then becomes the new council public key).

[0115] Thus, according to method 600 of Figure 6, when the distribution of transfers changes or when a request is received from a member to revert the transfer of assets to Hoop, the private key shares may be regenerated and all of the tokens under the control of the council may be moved to the new public key. The frequency with which the membership of the council may be updated is limited by the block time of the blockchain network 100. Many applications may require rebalancing only infrequently.

[0116] <Update private key share distribution while preserving existing public group addresses> 7, a further exemplary method 700 for updating private key share distribution is shown. The method 700 may be performed by a node 102 of a blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0117] In method 700 of FIG. 7, the council public key does not change each time a transfer of a token to / from the public group address occurs. When a request to allocate new key shares is detected (which may occur through a transfer of a token to the public group address at operation 702), node 102 cooperates with other members of the council to issue (at operation 704) new private key shares for the same public key to the new members of the group. The number of cooperating nodes is at least the threshold number of nodes required to generate a digital signature under the threshold signature scheme. At operation 704, 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), although the change may be small in practice. Alternatively, at operation 704, additional key shares may be allocated while other key shares are updated. Such an update needs to be accompanied by an attestation of the deletion of any key shares of the previous generation. In this case, new shares may be allocated while maintaining the same threshold (in the context of SSS, this involves increased order shares in the new polynomial).

[0118] At operation 702, node 102 may identify council members (i.e., parties who transferred tokens to the council public key in order to join the council and not for another purpose) using one or more attributes included in at least a portion of the transaction of the token to the public group address. For example, a particular transaction may be marked as a special transaction using an attribute in the transaction. Such an attribute (or its presence or absence) may indicate the purpose for which the transfer is made. For example, a flag may be included in the transaction when the transferor is not requesting to join the council.

[0119] When members leave a council using method 700, they may securely delete their private key shares. To ensure that old members' private key shares are unusable, council members may be required to use nodes 102 with special TEEs. TEEs are architectures implemented at the hardware level that ensure that instructions and data executed within them are protected against access and manipulation from the rest of the system. TEEs may utilize hardware mechanisms to respond to remote attestation challenges that can be used to verify the integrity of the system to external parties, such as other nodes in the council.

[0120] 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 integrated circuit level hardware. The secret value thus generated may be used in the distributed generation of secret key shares (e.g., in operation 410 of method 400 of FIG. 4). This secret value may also be used to establish a shared public key during the assembly establishment phase. The computations associated with the setup protocol are performed within the TEE enclave. As a result, no member or former member can derive any information about their own or others' secret key shares from member-to-member communications or in any other manner. The enclave within the TEE allows a remote attestation protocol to be performed. The remote attestation protocol may be used to prove to other nodes that the TEE enclave is authenticated and is executing authorized computer-readable instructions.

[0121] Computations related to group changes are performed within the TEE enclave, e.g., generation of new secure random secrets that can be used in computing new polynomials for SSS purposes is performed within the TEE enclave.

[0122] The TEE enclave also aims to ensure that previous key shares and previous secrets that should no longer be used are securely deleted before previous transfers to the pool made upon a particular member joining the parliament can be restored. In particular, to restore such transfers to the pool, the attestation protocol may require the TEE enclave to attest to the deletion of the key shares. Each node 102 may interpret such attestation as confirmation through the remote attestation protocol that the requested deletion occurred on the other node. Thus, the method 700 may further include the step of verifying that the private key shares previously held in the TEE of the member that has left the parliament have been deleted from the node associated with that member. This verification may be performed by receiving an attestation 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 that has left the parliament.

[0123] Method 600 of Figure 6 and method 700 of Figure 7 each provide various benefits. For example, method 600 of Figure 6 does not rely on secure deletion and does not need to rely on trusted hardware. However, method 600 of Figure 6 may benefit from such hardware in some circumstances, as such hardware may make fraudulent pooling of key shares less likely.

[0124] Method 700 of Figure 7 avoids having to relock tokens under a new council public key every time membership changes. Additionally, in some circumstances, method 700 may update membership faster than method 600 of Figure 6. This is because under method 700 of Figure 7, tokens are not moved to a new public key, so transactions do not need to be added to the blockchain to move all tokens to a new public key. That is, membership may be updated using method 700 of Figure 7 and there is no need to wait for several blocks to be generated to confirm the transfer of tokens to a new public key, because the public key does not change.

[0125] <Removal from Parliament> As mentioned above, group members may from time to time request to leave a parliament. When group members remove themselves from a parliament, any tokens they previously transferred to the parliament pool may be returned to them. Referring to Figure 8, an exemplary method 800 for returning such transfers is shown in flow chart form. The method may be performed by node 102 in cooperation with other nodes 102 of the parliament.

[0126] At operation 802 of method 800, node 102 receives a withdrawal request from a requester who is a member of the council. The withdrawal request may also be referred to as a deletion request. The withdrawal request is a request to withdraw tokens that were previously transferred by the requester to the pool and are now controlled by the council. The request may be broadcast by the requester to all members of the council.

[0127] In response to receiving the request, at operation 804, the node 102 evaluates the request against the determined criteria. Such criteria may be predefined criteria. If the council operates according to a council protocol in which the council public key is not changed whenever group membership changes, then at operation 804 the node 102 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.

[0128] If the council protocol is such that the council public key is changed when membership changes, then node 102 may not acknowledge the deletion of the private key share since the private key share is no longer valid. Instead, a new council key may be used and other tokens under the control of the council may be transferred to the new council key.

[0129] At operation 804, the evaluation may consider whether a ghost chain is currently deployed. If a ghost chain is deployed, then withdrawal requests are muted until operation of the ghost chain ceases. That is, council members mining on the ghost chain are prevented from withdrawing their "stakes" in tokens at least until the ghost chain is terminated.

[0130] If the nodes 102 approve the withdrawal request based on the evaluation, then in operation 806 the nodes facilitate the withdrawal of the tokens. That is, the nodes 102 use their private key shares to jointly generate digital signatures and use the digital signatures to transfer back to the requester the tokens previously transferred by the requester to the pool. For example, the tokens may be sent back to the address from which they were previously received. Operation 806 is performed according to a threshold signature scheme, so that the withdrawal is only valid if at least a threshold number of council members approve the withdrawal. Operation 806 is performed after the member desiring to be removed has been suspended from activity for a period of time. This waiting period prevents the member from engaging in fraudulent behavior while a protocol for the return of the member's previous transfer to the pool is being performed.

[0131] The Congress protocol may be used for many different purposes. The Congress provides a secure mechanism to perform various functions. The Congress does not have to operate trustlessly and provides ownership control over the tokens.

[0132] The Congress protocol may be used, for example, to implement a ghost chain, in which case it may be referred to as a ghost chain protocol.

[0133] <Ghost Chain> Referring to FIG. 9, a blockchain 902 and a ghost chain 904 are shown. The blockchain 902 is a block-based distributed proof-of-work ledger. The ghost chain 904 is a block-based distributed proof-of-stake ledger that may be used to achieve a distributed consensus among nodes of the blockchain. For example, the consensus may be used to achieve a consensus to resolve disputes between nodes in a blockchain network. For example, the blockchain may include challenges, where one node challenges a work product submitted by another node. Such a challenge is shown as "C" in FIG. 9. A challenge may arise, for example, when a node (i.e., a challenger) indicates that a proposed result in fulfilling a request is invalid.

[0134] When a challenge is issued by a node, a ghost chain 904 is deployed. The ghost chain is instantiated after a challenge C is raised in response to the challenge. The ghost chain may be instantiated with a genesis block, which is the final block (also called the end block) from a previous instantiation of the ghost chain. Multiple blocks are added to the ghost chain by miners to resolve the digital dispute until the ghost chain reaches a consensus (i.e., verdict), denoted by J.

[0135] Once a consensus is reached, a transaction (hereinafter referred to as a final or settlement transaction) may be constructed and signed (described in more detail below). This transaction may have the effect of distributing funds on the main blockchain 902 according to the consensus, distributing funds to reward miners on the ghost chain, etc. The transaction may communicate the outcome of the consensus back to the main blockchain 902. In particular, the outcome may be encapsulated within the transaction.

[0136] After consensus is reached and final transactions are composed and signed, the ghost chain 904 terminates and the composed transactions are mined into the main blockchain 902. Because the ghost chain 904 terminates, it differs from a standard blockchain that has a terminal block. This terminal block is the last block in the ghost chain 904 that occurs once a consensus has been determined and the resulting transactions, such as distributing funds on the main blockchain 902 according to the consensus, distributing funds to reward miners on the ghost chain, etc., are validly signed.

[0137] <Requestor-Proposer-Challenger and Ghost Chains> Thus, a node 102 (FIG. 1) in a blockchain network 100 (FIG. 1) may implement a requestor-proposer-challenger protocol and / or a ghost chain resolution protocol. Such a node 102 may include computer-executable instructions stored in memory 220 (FIG. 2) that implement such a protocol. Such instructions, when executed by a processor 210 (FIG. 2), cause a node 102 (such as an electronic device 200 of the type described with reference to FIG. 2) to perform one or more methods of the protocol. Such methods may include any one or combination of methods 1000, 1100, 1200, 1300 of FIGS. 10-13.

[0138] 10-13, methods that may be included in the requester-proposer-challenger protocol and / or the ghost chain resolution protocol are shown. A requester method 1000 is shown in FIG. 10 and may be performed by a requester of a task in a computation exchange. That is, a node 102 that requests the completion of a task may perform the requester method 1000 of FIG. 10. This node is a node in the blockchain network 100 (FIG. 1), and this node may be referred to as the requester.

[0139] The proposer method 1100 is shown in Figure 11. The proposer method 1100 may be performed by a proposer of a solution to a task. That is, a node 102 that claims to complete a task may perform the method 1100 of Figure 11. This node is a node in the blockchain network 100 (Figure 1), and this node may be called a proposer.

[0140] The challenger method 1200 is shown in Figure 12. The challenger method 1200 may be performed by a challenger of a solution to a task. That is, a node 102 that challenges a solution submitted by a proposer may perform the method 1200 of Figure 11. This node is a node in the blockchain network 100 (Figure 1), and this node may be called a challenger.

[0141] An arbitration method 1300 for achieving consensus among nodes is shown in Figure 13. The arbitration method 1300 is performed by a node of a blockchain network in cooperation with other nodes of the blockchain network to achieve a distributed consensus. A node that performs the arbitration method in cooperation with other nodes may be referred to as an arbitrator.

[0142] The methods 1000, 1100, 1200, 1300 of Figures 10-13 may be implemented cooperatively, for example, the methods may cooperatively provide a requestor-proposer-challenger protocol in which a ghost chain is used to guarantee the validity of the proposer's solution.

[0143] At operation 1002 of the requester method 1000 (FIG. 10), a node called the requester issues a request. A request is a request to complete a task. For example, the task may be a request for a work product. In particular, the task may be a request for a work product to a processor (i.e., a request for a processor to generate a predetermined work product, such as the result of a computation). The task may be an expensive 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 offers a reward in the form of a token associated with the blockchain network 100 in exchange for successful completion of the task. The request may be issued outside the blockchain (i.e., “off-chain”). For example, the request may be issued on a web server accessible via the Internet. A request is defined as successfully completed when a candidate solution to the request is not challenged for a fixed period of time (which may be referred to as a “challenge period”) or, in the case of a challenge that is solved by rerunning the computation on the ghost chain, when the candidate solution is found to match the result of the on-chain computation.

[0144] A request may be issued (at operation 1002) in a computation exchange. A computation exchange may be a collection of requested tasks. For example, multiple tasks may be issued in a computation exchange. The tasks may be issued by the same requestor or by different requestors. A computation exchange allows nodes to offload computations or algorithmic execution to other nodes.

[0145] At operation 1102 of proposer method 1100 (FIG. 11), a node, called the proposer, identifies a request. The node then proceeds to complete the task off-chain (at operation 1104). For example, the algorithm, data, or other result requested by the requester may be obtained as a work product by a processor.

[0146] The proposer may then submit a proposal at operation 1106 of method 1100 (FIG. 11). A proposal is a claim to complete a task associated with the request issued by the requester at operation 1002 of method 1000 of FIG. 10. To submit a proposal, the proposer may send their public key for the blockchain network 100 to the requester. The proposer may commit to solving the task. This commit may be in the form of a hash of the solution (i.e., a hash of the product of the work, such as the output of a computation or another type of solution).

[0147] The requester receives the proposal at operation 1004 of method 1000 of Figure 10. For example, the requester may receive the proposer's public key and a "commit" (e.g., a hash of the asserted work product).

[0148] In response to receiving the proposal, at operation 1006 of method 1000 of FIG. 10, the requester may construct transaction T1. The transaction includes the bounty as an input. The transaction also includes the bounty and the proposer's deposit as outputs (i.e., T1_out=bounty+proposer_deposit). Transaction T1 is signed to allow proposers to add their own inputs. For example, transaction T1 may be signed SIGHASH_ALL|SIGHASH_ANYONECANPAY. SIGHASH_ALL is the default signature hash type that signs the entire transaction except for any signature script, preventing modification of the signed portions. SIGHASH_ANYONECANPAY is the signature hash type that signs only the current input.

[0149] Transaction T1 is configured to be unlocked in two ways. After the end of the challenge period (described below), it may be unlocked by the proposer's signature (i.e., the signature corresponding to the public key that the proposer provided to the requester) and the solution corresponding to the commit. For example, the opcode OP_CHECKSEQUENCEVERIFY may be used to lock the transaction for the challenge period, but allow it to be unlocked by the proposer if there is no challenge within that period. The transaction is also configured to be unlocked at any time by a group signature of the parliament 110 (FIG. 1). That is, the transaction can be unlocked before or after the end of the challenge period when the nodes that are members of the parliament use their respective private key shares to cooperatively unlock the transaction according to the threshold signature scheme of the parliament 110.

[0150] A transaction may also include information about the suspect solution, such as a commit. For example, a hash of the asserted work product may be added to the transaction using the OP_PUSHDATA opcode. In particular, the hash of the asserted work product may be added to the transaction's lock script. This lock script is configured to be unlocked (after the end of a challenge period) by an unlock script that provides a solution that hashes the hash of the asserted work product included in the lock script.

[0151] Although not shown in FIGS. 10 and 11 , the processor may receive the transaction T1 constructed in operation 1006 and may add the proposer deposit as an input to transaction T1. The processor broadcasts the transaction to other nodes in the blockchain network 100 ( FIG. 1 ). The transaction is then mined (i.e., added to a block) on the blockchain so that it is publicly visible.

[0152] Once a transaction is mined on the blockchain, a challenge period begins. During the challenge period, node 102 (FIG. 1) may challenge the proposal submitted by the proposer. If a challenge is not issued during the challenge period, the proposer may claim the bounty and the proposer deposit from transaction T1. The proposer may start a timer to track the amount of time remaining in the challenge period and may automatically take action when the challenge period ends. For example, the processor may provide a work product, such as the processor's work product (which may be referred to as a solution), to the requester and may unlock the transaction.

[0153] The proposer may not provide the solution to the proposer directly. Instead, the proposer may provide the solution by embedding the solution in a transaction on the main blockchain network. For example, the proposer may provide the solution in an unlock script. The unlock script unlocks a lock script (in transaction T1) that blocks the bounty and the proposer deposit. As described above, the lock script may be configured to check that the proposed solution in the unlock script is a hash of a value that the requester was given previously (i.e., in a "commit") by the proposer. If the unlock script successfully unlocks the lock script that blocks the tokens (i.e., the UTXOs of transaction T1) previously blocked by the lock script of transaction T1, the transaction containing the unlock script uses the transaction by blocking the tokens (i.e., the proposer deposit and the bounty) with a new lock script (which may, for example, use the proposer's public key to block the tokens, so that the proposer completes control over the tokens).

[0154] As mentioned above, transaction T1 may be configured to lock the bounty and proposer deposit with the OP_CHECKSEQUENCEVERIFY code, which allows the proposer to automatically claim the bounty and proposer deposit after the challenge period ends without further authorization from the requestor.

[0155] If there are no challenges to the proposer's solution, it turns out that the completed transaction can be executed on the proof-of-work main blockchain 902 (Figure 9) and there is no need to execute the challenge protocol or the ghost chain protocol.

[0156] However, the challenger may issue a challenge during the challenge period. For example, at operation 1202 of method 1200, the challenger issues a challenge. The challenger may have performed operations similar to operations 1102 and 1104 of method 1100 of FIG. 11 . That is, the challenger may have identified a request and completed tasks off-chain before issuing the challenge at operation 1202. The challenger may have determined that a challenge should be issued by determining that the challenger's solution differs from the proposer's solution. The challenger may, for example, perform a hash of their solution and compare the hash to the hash of the proposer's solution, and if the hashes differ, the challenger may issue a challenge.

[0157] At operation 1202 of method 1200 of Figure 12, a challenger issues a challenge within a challenge period. The challenger may do this by broadcasting an intention to challenge to the blockchain network 100. Once a challenge is issued, a group of nodes may help determine the validity of the solution.

[0158] For example, referring briefly to FIG. 13, FIG. 13 shows a flow chart of an arbiter method 1300. A group of nodes may form a congress that may be used to reach a distributed consensus, such as when a challenge is raised. The congress is secured by a transfer on a proof-of-work blockchain network, as described above. For example, at operation 1302 of method 1300, an arbiter performing the arbiter method 1300 may join a congress. For example, the arbiter may perform the method 400 for joining a congress described above with reference to FIG. 4. Thus, at operation 1302, the arbiter joins a group, which may be called a congress, through a transfer of a token to a public group address associated with the congress to become a group member. The arbiter makes this transfer on a proof-of-work blockchain network. As described above, the group follows a threshold signature scheme in which the nodes control private key shares. Joining a group, which may also be called joining, may be performed, for example, during the deployment of a ghost chain. 13 illustrates operation 1302 (joining a council) as being performed before operation 1306 (developing the ghost chain), so it is performed by a node that joined the council during a previous development of the ghost chain (i.e., not during the development in operation 1306). However, operations 1306, 1308, and 1310 may be performed by a node that joins the group during operation 1306, for example.

[0159] At operation 1304, the arbitrator cooperates with other nodes in the group to detect challenges issued by challengers at operation 1202 of challenger method 1200 of Figure 12. In particular, the arbitrator cooperates with other nodes in the group to detect challenges to the proposer's work product by challengers in response to requests generated by requesters.

[0160] Due to transaction T1, as described above, the group assumes control of the bounty and proposer deposit when a challenge is issued. That is, transaction T1 is considered unlockable by the council at any time. Thus, the bounty and deposit are placed under the group's control and remain under its control when a challenge is detected within a period of time called the challenge time following delivery of a solution to a request by the proposer. Thus, when a challenge is detected, the group has control of the bounty and proposer deposit.

[0161] After the group has control of the bounty and proposer deposit, and in response to detecting a challenger, the arbitrator cooperates with other nodes in the group to facilitate the transfer of tokens by the challenger. For example, in response to detecting a challenge, the council may construct transaction T2 with inputs equal to the bounty and proposer deposit (e.g., T2_in=bounty+proposer deposit) and outputs equal to the sum of the bounty, proposer deposit, and challenger deposit (e.g., T2_out=bounty+proposer deposit+challenger deposit). Thus, obviously, the bounty and proposer deposit may be under the exclusive control of the group prior to the construction of transaction T2 (as described above). Transaction T2 may be configured to pay the group at any time. That is, transaction T2 is configured to pay the council public key. Transaction T2 may be signed SIGHASH_ALL|SIGHASH_ANYONECANPAY. The arbiter, together with other arbiters, may provide transaction T2 to the challenger for adding the challenger deposit as an input. For example, the arbiter, together with other nodes, may make transaction T2 publicly available to other nodes.

[0162] After transaction T2 is made publicly available, the challenger transfers the tokens as input to transaction T2. ​​That is, the challenger transfers the tokens in the tokens (at operation 1204 of challenger method 1200 of FIG. 12) and places such deposits under the control of the group. In particular, the transferred tokens (the "challenger deposits") are placed under the control of the council public key. The bounty, proposer deposit, and challenger deposit are thus all under the control of the group and bound by the council public key. As described in more detail above in the council description, the threshold signature scheme allows a threshold number of council members to use their respective private key shares to cooperatively generate valid signatures for transactions involving the bounty, proposer deposit, and challenger deposit. The proposer deposit and the challenger deposit may be of equal size.

[0163] The challenger may commit their challenge solution. For example, the challenger may add a hash of the solution to transaction T2, for example using opcode OP_PUSHDATA.

[0164] Transaction T2 is broadcast to and mined on the main blockchain network, resulting in the challenger deposit being blocked by the Congress public key. The bounty, proposer deposit, and challenger deposit are now under the exclusive control of the group.

[0165] Thus, the challenger provides the arbiter with a proof of the alternative solution and a deposit. After transaction T2 is mined into the main blockchain network, in operation 1306 of the arbiter method 1300, the arbiter, in cooperation with other nodes in the group, deploys the ghost chain to reach a decentralized consensus, thereby resolving the challenge. As described above, the ghost chain is a proof-of-stake blockchain where miners of the ghost chain are members of the group. That is, members of the council are allowed to mine on the ghost chain. Their member transfers (i.e., member deposits) to a pool on the proof-of-work blockchain network act as their stake to allow them to mine on the ghost chain. The probability that any member is selected to mine is proportional to their relative transfer amounts (i.e., the amount of their deposits).

[0166] While the ghost chain is being deployed (at operation 1306), a provenance block of the ghost chain may be generated and obtained by the arbiter in cooperation with other nodes in the group. The provenance block may be the final block from the last ghost chain deployment (e.g., the last instance the ghost chain was run and a terminal block from the previous run may have responded to a previous challenge). This block may contain information regarding the provenance payment. The provenance payment is a transfer of digital tokens yet to be generated based on a previous deployment of the ghost chain.

[0167] Additionally, while the Ghost Chain is being deployed, members may be allowed to join or may request to be removed from the group. During the joining phase, new members may join. As a result, they are assigned private key shares (as described above with reference to FIG. 4). New members are provided with the genesis block (which is authenticated by a threshold number of current members) and any subsequent blocks generated during the joining process.

[0168] A pre-deletion phase may also be included in the ghost chain execution. During this pre-deletion phase, any member that has requested to be deleted may submit an attestation for the deletion of certain private data. Such an attestation may be required to reinstate the member's transfer to the pool (i.e., the attestation may be required to return the member deposit). Evidence of misconduct that would preclude reinstatement of the member's previous transfer may be submitted at this stage (e.g., a newly joined member may submit a provenance block that was previously committed by one or more current members but is suspected to be false). The technique of deletion was detailed with reference to FIG. 8.

[0169] The deployment of the ghost chain may include an adjudication operation by an arbiter in cooperation with other nodes of the group. The adjudication operation may include the steps of 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 an intermediate result. The intermediate result 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 is the final work product that completes the requested task. The evidence may be submitted by the proposer at operation 1108 of the proposer method 1100 of FIG. 11 and by the challenger at operation 1206 of the challenger method 1200 of FIG. 12.

[0170] The arbiter and other nodes of the council may reach a distributed consensus regarding the correctness of the solution, thereby resolving the challenge by performing a task associated with 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). The group may determine which of the proposer's and challenger's solutions is correct by comparing these solutions with its own solutions determined on the ghost chain. During this process, group members (i.e., ghost chain miners) perform calculations and / or analysis to reach a distributed consensus. During this process, group members reach a consensus and sign a block.

[0171] To reduce computational requirements and time delays, the group may perform a binary search procedure while using the ghost chain to resolve the challenge. In particular, the proposer and challenger may each provide one or more intermediate results of their computation or analysis. Because the inputs of the computation or analysis are the same for both the proposer and challenger (as may be specified by the requester), and the outputs are different, there are transitions between intermediate steps that diverge for the challenger and the proposer. Once such a transition is identified, the group may use the ghost chain to perform only a single operation, step, or procedure associated with the transition. Thus, the reconciler, in collaboration with other nodes, may perform only a portion of the task on the ghost chain to determine that either the proposer or the challenger made a mistake in an intermediate step of the task associated with the request. Under this binary search technique, the group may not identify the 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.

[0172] The arbiter (in cooperation with other nodes in the group) reaches a consensus while the ghost chain is being deployed. In fact, a decision on a consensus is reached when the arbiter and other nodes in the council resolve challenges.

[0173] After a consensus (i.e., arbitration decision) is reached on the blockchain, the arbitrator, in cooperation with other nodes in the group, composes a final transaction (to be mined into the main blockchain network once fully signed). The final transaction may also be called a settlement transaction, and may include various token transfers, such as (i) bounty+deposit (which may be transferred to nodes deemed successful or vindicated in the adjudication process), (ii) mining fees (for ghost chain mining already performed), (iii) provenance payment (which is a token transfer that is scheduled based on the previous run of the ghost chain and is determined from the provenance block), and / or (iv) reinstatement (i.e., return) of tokens transferred to the parliamentary pool of removed members.

[0174] This transaction may also contain useful metadata. For example, the resolve transaction may forward the solution back to the blockchain network. Thus, during this process, the group (i.e., the arbitrator working with other nodes in the group) may commit the consensus result to the blockchain network. The group may also commit the Merkle root hash of the intermediate computation state as determined on-chain on the ghost chain to the blockchain network.

[0175] Thus, the tokens under group control may be distributed (at operation 1308) by the arbiter in cooperation with other nodes of the group. Such distribution of tokens is performed according to a threshold signature scheme defined (i.e., for the group) for the council (i.e., for the group). As seen in the above discussion of the council, the threshold signature scheme is configured such that at least a threshold number of members are required to generate a valid signature of the council public key. Thus, the arbiter, together with other nodes of the group (i.e., together with other arbiters), may agree to transfer the tokens by adding a partial signature to the final transaction using the arbiter's private key share. The other nodes also add partial signatures using their respective private key shares until at least the threshold number of private key shares required to generate a valid signature of the final transaction under the threshold signature scheme have been used.

[0176] The particular manner in which the tokens are distributed in the final transaction depends on the outcome of the consensus. For example, when the consensus is that the stated solution is incorrect, the arbiter, in cooperation with other nodes, transfers at least the challenger deposit to the challenger and distributes the proposer deposit to miners of the ghost chain in proportion to the absolute number of blocks mined. When the consensus is that the challenger's solution is correct, the bounty may also be transferred to the challenger. Thus, the challenger may receive the tokens at operation 1208 of the challenger method 1200 of FIG. 12. However, if a binary search is used and, as a result, a correct solution is not identified, the bounty may be returned to the requester, who may reissue the request, allowing the challenger to submit a proposal based on their answer. Alternatively, once the proposer is removed through the binary search, the requester may treat the challenger's commit as a proposal and may resume operation at operation 1006 of the method 1000 of FIG. 10. That is, the requester may construct a new transaction T1 based on the challenger's proposal. This transaction may be as described above with reference to operation 1006, except that the node that was formally considered as the challenger is now considered as the proposer. Thus, the new transaction T1 may be configured 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 as proposed by the challenger in transaction T2, as described above.

[0177] When the consensus is that the proposer's work product is valid, the arbitrator, in cooperation with other nodes, transfers the bounty and proposer deposit to the proposer and distributes the challenger deposit to miners of the ghost chain in proportion to the absolute number of blocks mined. Thus, the proposer may receive tokens at operation 1100 of method 1110 of FIG.

[0178] When the consensus is that the proposer's solution and the challenger's solution are both incorrect, half of the challenger deposit and half of the proposer deposit may be distributed to the miners in proportion to the absolute number of blocks mined. Any remaining tokens may be returned to the party from which they were received.

[0179] The requester receives the solution at operation 1008 of the requester method 1000 of FIG. 10. The manner in which the requester receives the solution at operation 1008 may depend on whether a challenge was issued. For example, if a challenge was not issued, the proposer committed the solution to the blockchain using transaction T1, as described above with reference to operation 1006 of the method 1000 of FIG. 10. However, if a challenge was issued, and if the ghost chain has determined a solution to the request, the ghost chain node may send the solution to the requester at the end of the ghost chain (e.g., at operation 1310 of the reconciliation method 1300 of FIG. 13). The ghost chain protocol may thus allow nodes participating in the ghost chain to automatically send the solution to the requester once they have determined the solution.

[0180] Furthermore, after a consensus is reached on the ghost chain and a transaction is constructed and validly signed, the ghost chain is terminated (at operation 1310 of the reconciliation method 1300 of FIG. 13). That is, once the challenge is resolved, the ghost chain is terminated. Once the ghost chain is terminated, information related to the resolution of the challenge may be forwarded back to the proof-of-work blockchain network.

[0181] Once a ghost chain is terminated, no further blocks are mined into it. That is, unlike a standard blockchain, a ghost chain has a terminal block. A ghost chain may be implemented as a proof-of-stake blockchain that does not fork. The absence of forking means that when the ghost chain is terminated, there is a clear terminal block (i.e., a terminal block agreed upon by all nodes in the group). After this terminal block, the ghost chain serves its own purpose and no more is added.

[0182] As mentioned above, when the arbiters (i.e., the nodes of the council) reach a consensus that generates a valid signature for the transaction through the addition of partial signatures according to the threshold signature scheme as described above, the nodes cooperatively compose the transaction to be broadcast on the main chain (at operation 1308). Since the transaction is itself a multi-party computation, the nodes that contribute to the transaction may be expected to be rewarded for participating in the transaction. However, since the transaction is specified before it is signed, rewards for participating in the signature (which may include sending the partial signature with the transaction to the ghost chain and actually mining the block) may be deferred until further deployment of the ghost chain. Such a deferral may be provided at operation 1310. In particular, the leaf blocks may be configured with information that allows the provenance payment to be processed during future deployment of the ghost chain. Such information may be a record of mining fees scheduled for blocks generated after the final transaction was constructed, such as blocks generated during the signing of the final transaction. That is, a provenance payment may be defined to reward nodes that contributed to the signing of the final transaction. The leaf blocks of the ghost chain become the genesis blocks of the next ghost chain run (i.e., the next time the ghost chain is deployed), and thus records are generated in the leaf blocks for future genesis payments.

[0183] Note that according to the implementation just described, member joining / removal during a ghost chain run may be triggered by a challenge. Alternative implementations may allow joining / removal at regular intervals or under other conditions. This may include scheduled runs of a ghost chain specifically for this purpose. This may be similar to the ghost chain deployment described above, except that it does not have a ruling and consensus stage. In this case, mining fees may be paid at least in part from a "joining fee" required in return for joining.

[0184] Also, method 1300 described above described a ghost chain execution that is not a first ghost chain execution. That is, method 1300 described the deployment of a ghost chain that was deployed at some point in the past. As a result, the terminal block includes an origin payment that already exists for the ghost chain. Method 1300 may be modified to allow for the deployment of a first ghost chain. For example, the origin block may be established in another manner when the ghost chain is initially deployed. For example, the origin block may be provided by a trusted party initially.

[0185] By using a proof-of-stake based blockchain to achieve distributed consensus (i.e. to arbitrate challenges), faster consensus can be achieved than by trying to achieve such consensus on a proof-of-work blockchain network, because proof-of-stake allows for more regular block production and can be configured to allow for high frequency block production. Additionally, by performing the operations necessary to achieve such distributed consensus on a ghost chain rather than the main blockchain itself, tasks are pushed out from the main blockchain network, resulting in a lighter load on the main blockchain network.

[0186] Furthermore, the transitory nature of ghost chains (i.e., ghost chains are ephemeral in nature and terminating) may avoid or reduce the risk of the nothing-at-stake problem that typically affects proof-of-stake blockchain networks. The ephemeral nature of ghost chain networks allows a council to require that transfers by miners of a ghost chain to the council pool are not reverted until the ghost chain is terminated. That is, a council may be configured to not allow council members to effect reversion of their previous transfers to the pool (i.e., recovering their stakes) while a ghost chain is running.

[0187] Although the above examples refer to opcodes available in Bitcoin, the methods described herein may be used with other types of blockchain networks.

[0188] Although the above method has been described as generally being performed at a node, aspects of the method are strongly dependent on other nodes and may be performed elsewhere.

[0189] It should be noted that the above-described embodiments do not limit the present invention, and that those skilled in the art can devise numerous alternative embodiments without departing from the scope of the present invention, which is defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claims. The word "comprising" or "comprises" and the like does not exclude the presence of elements or steps other than those listed in any claim and in the specification as a whole. In this specification, "comprises" means "includes" or "consists of", and "comprising" means "including" or "including of". The singular reference of an element does not exclude the presence of a plurality of such elements and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, or by means of a suitably programmed computer. In a device claim enumerating several means, these several means may be implemented by one and the same hardware element. The fact that certain quantities are recited in mutually different dependent claims does not indicate that a combination of these quantities cannot be used to advantage. [Explanation of symbols]

[0190] 102 nodes 110 Parliament

Claims

1. 1. A computer-implemented method, executed by a first node that issues a request on a blockchain, the method comprising: joining a group by the first node through a transfer of a token to a public group address to become a group member, the group being associated with a threshold signature scheme in which the first node controls a private key share, and the transfer of tokens occurs over a proof-of-work blockchain network; issuing a request to the group to complete a work effort; receiving a proposal for said work product from a second node of said group; structuring a transaction in response to receiving the proposal; obtaining a solution for the work product and determining that there is no challenge for which the solution is proposed; committing the transaction to the blockchain; 23. A computer-implemented method comprising:

2. 10. The computer-implemented method of claim 1, wherein the request is a computational exchange, the computational exchange enabling a node to offload computations or execution of an algorithm to another node.

3. 10. The computer-implemented method of claim 1, wherein the second node completes a task off-chain.

4. 2. The computer-implemented method of claim 1, wherein the second node transmits the second node's public key for the blockchain network to the first node to submit the proposal.

5. The computer-implemented method of claim 4 , wherein the second node commits a solution to a task in the form of a hash of the solution.

6. 6. The computer-implemented method of claim 5, wherein the first node receives the second node's public key and the hash of the solution.

7. 2. The computer-implemented method of claim 1, wherein the transaction includes a bounty as an input and a proposer's deposit as an output, the transaction being signed by the first node such that the second node can add its own input.

8. The computer-implemented method of claim 1 , wherein the transaction is configured to be unlocked after expiration of a challenge period.

9. The computer-implemented method of claim 1 , wherein the transaction is configured to be unlocked at any time by a group signature.

10. The computer-implemented method of claim 1 , further comprising a challenge period during which any node may challenge a proposal submitted by the second node.

11. 11. The computer-implemented method of claim 10, wherein if no challenge is issued during the challenge period, the second node claims the bounty and proposer deposit from the transaction.

12. 2. The computer-implemented method of claim 1, wherein the second node provides the solution to the first node by embedding the solution in a transaction on a main blockchain network.

13. A computer readable storage medium comprising computer executable instructions which, when executed, configure a processor to perform a method according to any one of claims 1 to 12.

14. 1. An electronic device comprising: An interface device; a processor coupled to the interface device; a memory coupled to said processor, said memory storing computer executable instructions that, when executed, configures said processor to perform a method according to any one of claims 1 to 12; An electronic device comprising:

Images