METHOD AND SYSTEM FOR BLOCKCHAIN-ENHANCED EVENT-LOCKED ENCRYPTION

Abstract

To provide a method and an apparatus for managing ownership of digital assets to maintain blockchain integrity.SOLUTION: A member of a congress comprising a plurality of nodes is operated by: encrypting a plaintext message by using a congress public key to generate an encrypted message according to an identity-based encryption scheme; using an encryption private key corresponding to the encryption public key to generate a digital signature for a first set of instructions for performing a cryptographic operation upon occurrence of an event; and broadcasting, to a proof-of-work blockchain network, a transaction including the encrypted message, the cryptographic public key, the first set of instructions, and a second set of instructions that instructs the first set of instructions to be executed. Executing the first set of instructions includes deriving a decryption key from the plurality of secret key shares and the encryption key that satisfy a threshold.SELECTED DRAWING: Figure 14

Description

[Technical field]

[0001] The present invention relates generally to distributed systems, and more particularly to a method and system for event-locked operations in transactions on a distributed system. Event locking and event-locked encryption may refer to performing operations (computations) on data in response to the occurrence of an event. For example, in an event-locked encryption scheme, an encrypted message may be decrypted in response to the occurrence of an event. A particular type of event-locked encryption is a time-locked encryption scheme in which a message is encrypted and the encrypted message is or can be decrypted after a certain amount of time has passed. The present invention is suitable, without being limited thereto, for efficiently and reliably generating messages, detecting the occurrence of an event, and performing operations in response to verification of the occurrence of the event using a distributed system. For example, a message may be encrypted under a time-locked encryption scheme in which a corresponding decryption operation may occur as a result of the passage of (possibly random) time.

[0002] This document uses the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These forms include, but are not limited to, blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While reference may be made herein to Bitcoin 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. [Background technology]

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized system composed of blocks, which consist of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system, and each transaction contains at least one input and at least one output. These blocks are chained together because each block contains a hash of the previous block, creating a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs, and the scripts specify who can access the transaction's output and how. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated." Several network nodes, acting as miners, work to ensure that each transaction is valid; invalid transactions are rejected from the network. For example, a software client installed on the node performs this validation for transactions that reference unsettled transaction outputs (UTXOs). Validation can be done by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and certain other conditions are met, the transaction is valid and can be written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must i) be verified by the node that receives the transaction (when a transaction is verified, the node relays it to other nodes in the network); ii) be added to a new block constructed by a miner; and iii) be mined (i.e., added to the public ledger of past transactions). A transaction is considered confirmed when enough blocks have been added to the blockchain, making the transaction effectively irreversible.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore implementing new systems using both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain. It would be highly advantageous to be able to use blockchain for automated tasks and processes that are not purely limited to cryptocurrency-denominated payments. Such a solution would allow blockchain to take advantage of its advantages (e.g., permanent, tamper-proof record of events, distributed processing, etc.) while broadening their applications.

[0006] As blockchain technology is expanded to provide new functionality, it is important to maintain the security of the blockchain and the digital assets represented therein. The set of enhanced functions that rely on the blockchain may be subject to attack from malicious parties. Thus, it may be useful to provide methods and apparatus for managing ownership of digital assets to provide additional security to the blockchain or new functions of the blockchain, or to maintain the integrity of the blockchain.

[0007] Additionally, as new improvements or modifications to blockchains are developed, techniques for controlling and transferring digital assets from one blockchain to another while maintaining the integrity of both blockchains would be useful. Thus, it would be desirable to provide improved methods and apparatus that improve blockchain technology in one or more of these aspects. Summary of the Invention

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

[0009] As described in more detail below, congresses can be formed on a blockchain network. A congress is an open membership group that any node in the blockchain network can join by submitting sufficient contributions to a pool associated with the congress. For example, a node can join a congress by transferring digital assets, such as digital currency (e.g., Bitcoin), tokens, or other contributions or value, to a resource (e.g., an account) associated with the congress. A congress can be protected in part by distributed generation of private key shares. Each private key share can be used by an owner to generate partial signatures for transactions. A threshold signature scheme can be used to generate valid signatures for such transactions using at least a threshold number of partial signatures. Member deposits are subject to forfeiture for malicious activity.

[0010] Advantageously, the use of distributed generation of key shares and other security features protects the key shares to prevent malicious activity by group members or non-group members. Such security, coupled with the use of threshold signature schemes, allows for the formation of autonomous, decentralized groups that can be used for any of a number of purposes, such as providing a two-way peg. More specifically, threshold signature schemes allow groups to control digital assets that are emcumbered by a public key associated with the group.

[0011] Thus, in accordance with the present invention, there is provided a computer-implemented method comprising: i) encrypting the plaintext message to a cryptographic public key using at least a Congress public key in accordance with an identity-based encryption scheme to generate an encrypted message, the Congress public key being associated with a member of the Congress, each member of the Congress having access to a secret key share usable in a threshold decryption scheme, where at least a threshold number of the secret key shares are sufficient to derive a decryption key by combination of partial contributions to the decryption key on behalf of the Congress; ii) generating a digital signature for a first set of instructions for performing a cryptographic operation upon occurrence of an event using at least a cryptographic private key corresponding to the cryptographic public key; iii) broadcasting one or more transactions to the proof-of-work blockchain network, the transactions including the encrypted message, the cryptographic public key, at least the first set of instructions, and the second set of instructions; The second set of instructions, in response to reaching a consensus on the occurrence of the event subject to the digital signature being authentic, instructs the members of the Congress to deploy a ghost chain to execute the first set of instructions, wherein executing the first set of instructions includes at least deriving a decryption key from a plurality of secret key shares and the encryption key that satisfy a threshold, the decryption key being cryptographic material sufficient to obtain a plaintext message from the encrypted message.

[0012] In some implementations, the decryption key is derivable based at least in part on a scheme based on pairings over elliptic curves.

[0013] In some embodiments, the identity-based encryption scheme follows the Boneh-Franklin identity-based encryption scheme.

[0014] In some embodiments, the one or more transactions include a transaction that includes a fee to a public group address associated with the congress, where the fee is distributed to at least some of the miners of the ghost chain that cooperate in deriving the decryption key.

[0015] In some embodiments, miners on the Ghost Chain reach consensus on events based on information available from the Proof of Work blockchain.

[0016] In some embodiments, the information obtainable from the proof-of-work blockchain is a timestamp of a transaction submission to the proof-of-work blockchain.

[0017] In some embodiments, the information obtainable from the proof-of-work blockchain is the detection of valid blocks of at least a particular height.

[0018] In some embodiments, consensus is reached based at least in part on detecting that members of the Congress issue at least a threshold number of certificates that an event has occurred, the occurrence of the event being determined at least in part based on information external to the proof-of-work blockchain, and further, the authenticity of the certificates is cryptographically verifiable using cryptographic public keys associated with each member of the Congress.

[0019] In some embodiments, the certificate is issued for a predetermined period of time.

[0020] In some embodiments, the one or more cryptographic operations include one or more decryption operations.

[0021] In some embodiments, the one or more cryptographic operations include one or more authentication operations.

[0022] In some embodiments, a private key share is generated for each of the members of the Congress, and the private key share is used to perform cryptographic operations within a trusted execution environment in the node associated with that member.

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

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

[0025] These and other aspects of the invention will be apparent from and will be elucidated with reference to the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 is a block diagram of an exemplary blockchain network. [Diagram 2] FIG. 1 is a block diagram of an exemplary electronic device that may function as a node in a blockchain network. [Diagram 3] 1 is a flow chart of an exemplary method for initiating a congress. [Figure 4] 4 is a flow chart of an exemplary method for joining a congress. [Diagram 5] 1 is a flow chart of an exemplary method for confiscating digital assets. [Figure 6] 1 is a flow chart of an example method for redistributing key shares. [Figure 7] 4 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 returning a deposit. [Figure 9] FIG. 1 is a block diagram of an exemplary blockchain and an exemplary ghost chain. [Figure 10] 1 is a flow chart of a method for an example requestor to request the completion of a task. [Figure 11] 1 is a flow chart of a method for an example proposer to propose 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 flow chart of an example arbitrator method for arbitrating challengers for a solution to a task. [Figure 14] FIG. 1 is a block diagram of an example blockchain and event-locked messages. [Figure 15] 1 is a flow chart of an exemplary encryption method for generating an event-locked message. [Figure 16] 1 is a flowchart of an example method of performing steps in response to detecting an event specified in an event lock message to generate a decryption key usable to decrypt the event lock message. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0028] 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 conform to a protocol associated with the blockchain. For example, the Bitcoin protocol may be used when the blockchain is the Bitcoin blockchain.

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

[0030] 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 find a nonce by hashing the block header with SHA-256 to a number less than a value dictated by the current difficulty. The hashing power required for the proof-of-work algorithm means that a transaction is considered effectively irreversible after a certain number of blocks have been mined on top of it. The miner 104 who solves the cryptographic problem creates a new block in the blockchain and broadcasts this new block to the other nodes 102. The other nodes 102 verify that the miner 104 has indeed solved the cryptographic problem and therefore demonstrated sufficient proof-of-work before accepting that the block should be added to the blockchain. Blocks are added to the blockchain (i.e., a global distributed ledger) by consensus of nodes 102.

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

[0032] In the case of 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 digital assets to or from a public key (e.g., paying a public key) and to transferring digital assets to or from an address associated with that public key refer to a common action.

[0033] Some of the nodes 102 may not act as miners and instead participate as validating nodes. Validating transactions may include verifying signatures, checking references to valid UTXOs, etc.

[0034] The example of FIG. 1 includes six nodes 102, two 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 higher than the number shown in FIG. 1.

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

[0036] A Congress 110 is an open membership group that a node 102 can join by submitting a sufficient stake to a pool associated with the Congress 110. For example, a node can join a Congress by transferring a digital asset, such as a digital currency (e.g., Bitcoin), token, or other stake or value, to an account associated with the Congress 110. A node 102 that joins a Congress can be any node in a blockchain network, including both mining and non-mining nodes. In at least some applications of Congress (such as when Congress is implementing a two-way peg, as described below), nodes that act as Congress members monitor the blockchain in the sense that they download (but do not necessarily retain) the complete blockchain.

[0037] The techniques for joining, leaving, and participating in a congress 110 are discussed in more detail below.

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

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

[0040] Memory 220 may store the global ledger of blockchain network 100 (FIG. 1), or a portion thereof. That is, memory 220 may store all the blocks of the blockchain, or a portion of the blocks, such as the most recent blocks, or a portion of the information in some blocks.

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

[0042] As shown in FIG. 2, the processor 210 can include a secure area such as a trusted execution environment (TEE) 250. The TEE 250 can be an isolated execution environment that provides additional security to the electronic device 200, such as isolated execution, trusted application integration, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded into the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 can be used to protect the integrity and confidentiality of critical resources, such as keys. Since the TEE 250 is implemented at least partially at the hardware level, the instructions and data executed within the TEE 250 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 parties operating the node 102 that includes the TEE 250.

[0043] The TEE 250 may operate to instantiate an enclave and add pages of memory one at a time, hashing cumulatively. Similar operations may be performed on a remote machine (which may be the development machine or another machine), which determines and stores the expected hash. The contents of the enclave may thus be verified on the remote machine to ensure that the enclave is running an approved algorithm. This verification may be done by comparing hashes. Once the enclave is fully constructed, it may be locked down. It is possible to run code on the TEE 250 and send secrets to this code, but the code cannot be modified. The final hash may be signed by an authentication key, making it available to the data owner to verify before sending secrets to the enclave.

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

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

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

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

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

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

[0050] Digital assets managed by the Congress 110, including digital assets transferred to a Congress address, are under the control of a threshold signature scheme. The threshold signature scheme requires a group of members whose total holdings of private key shares exceed a threshold to generate a valid signature that allows a digital asset to be transferred out of the control of the Congress 110. In other words, at least a threshold number of private key shares must be used to generate a valid signature for an outgoing transfer of a digital asset managed by the Congress 110.

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

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

[0053] The Congress 106 may act as an autonomous group where cooperative behavior is enforced by the threat of confiscation of all or part of the member deposits. With many honest members participating in the cooperative protocol, such digital assets of non-cooperative or malicious members can be confiscated. That is, member deposits in the Congress Pool may be subject to confiscation to ensure that all nodes 102 operate in compliance with a predefined protocol or standard. Confiscation means permanently blocking the return of member deposits that are deemed confiscated. Digital assets forming member deposits that are not returned due to malicious activity may be left in the Congress Pool but may not be returned (e.g., if a consensus is reached on an alt-chain that they should not be returned), transferred immediately or in the future to another unspendable address, or confiscated, the nature of the confiscation may depend on whether the Congress acts as a bonded validator set for the sidechain.

[0054] Additionally, if a Congress member wishes to leave the Congress 110, the member may withdraw his / her member deposit (i.e., request that the Congress 110 return the member deposit to the member's personal address), but withdrawal of funds may only be performed if a number of private key shares exceeding the threshold required to generate a valid digital signature are used by the members of the group (i.e., the Congress) authorizing the withdrawal.

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

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

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

[0058] Ibrahim et al.'s ECDSA scheme is robust to halting adversaries for t<=n / 3, which can prevent corrupted parties from joining the protocol or halt them from joining midstream.

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

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

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

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

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

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

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

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

[0067] A node 102 (FIG. 1) in a blockchain network 100 (FIG. 1) may implement a congress 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 congress 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 congress protocol. Such methods may include any one or combination of methods 300, 400, 500, 600, 700, 800, 1000 of FIGS. 3-8 and 10. Thus, the congress protocol may include one or more of methods 300, 400, 500, 600, 700, 800, 1000 of FIGS. 3-8 and 10. The methods may be performed by the node in cooperation with other nodes associated with other congress members.

[0068] The start of the Congress 3, there is shown a method 300 for initiating a congress 110. The method 300 may be performed by an initial trusted party to set up the congress 110. That is, a node 102 associated with the initial trusted party may perform the method 300.

[0069] The method 300 includes providing a congress public key at operation 302. The congress public key may be provided to other nodes 102 to enable other nodes to pay for the congress public key if they wish to join the congress, i.e., other nodes may transfer digital assets to an address associated with the congress public key in order to join the congress.

[0070] The node 102 executing the method 300 allows payments to be made to the public key until one or more conditions are met, in operation 304. For example, the node may allow payments to be made to the public key for a set period of time or for a set number of blocks. After the conditions are met (e.g., after the expiration of this period of time or after mining a number of blocks), the node 102 executing the method 300 identifies the initial members of the congress, in operation 306.

[0071] After the parties that will make up the initial membership of the congress 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.

[0072] During operation 308, the nodes 102 identified as congress members cooperate to generate new private key shares and new public keys. The original key shares initially sent to such nodes by the trusted party can be used to sign and broadcast a transaction that sends all digital assets in the congress pool to the new public key, which then becomes the congress public key. That is, during operation 308, a new public group address is established and the digital assets under the congress's control are transferred to this new address, which becomes the new address of the group and is associated with the congress public key. After this transfer is confirmed, the congress can operate trustlessly. The new public group address is formed so that it can receive future deposits of digital assets from other nodes that wish to join the congress 110 or for other purposes as described above. Here, the congress members are considered to be registered with the congress, and these nodes can operate without the assistance of the initially trusted party. Furthermore, the original trusted parties will no longer be involved in any part of the running of the Congress.

[0073] Joining a Congress after it has begun Referring now to FIG. 4, this figure illustrates a method 400 for joining a congress. 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 a different one of the nodes 102 operating in the same blockchain network 100 (FIG. 1) operated by the node performing the method 300 of FIG. 3. The method 400 of FIG. 4 includes, at operation 402, obtaining a congress public key. The congress public key may be obtained directly from a party initiating the congress, such as the node performing the method 300 of FIG. 3, or 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 congress public key may be obtained from a public web server accessible via the public internet.

[0074] A node 102 performing the method 400 pays the congress public key by broadcasting a transaction of digital assets from a private account associated with the node 102 to a congress address (i.e., an address associated with the congress public key) in operation 404. More specifically, the node 102 broadcasts a transaction to transfer one or more digital assets to a public group address associated with the congress public key. The public group address is an address for a congress pool. The congress pool contains other digital assets associated with other members of the congress. Thus, the transaction in operation 404, when added to a block by the miner 104 (FIG. 1), transfers the digital assets to the congress pool, which contains digital assets from other members. The public group address may receive both transfers from participants who wish to join the congress and transfers from participants who do not wish to join the congress. Parties that do not wish to join the Congress may transfer digital assets to the Congress Pool, where such digital assets may be placed under full, partial, or conditional control by the Congress using a threshold signature scheme employed by the Congress.

[0075] The transaction in operation 404 may include a flag, identifier, or other attribute that indicates that the party transferring the digital asset wishes to join the Congress and that a deposit has been made for such purposes.

[0076] After depositing the digital assets in the congress pool, the node 102 executing the method 400 receives a private key share in operation 406. The node 102 then regenerates the private key share by executing a single instance of the protocol in operation 408. The generation of the private key share may be performed within the TEE of the node 102.

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

[0078] To regenerate the secret key shares, existing congress members may cooperate to update the key shares in operation 408. For example, node 102 may generate a random polynomial of degree t, with the constant term being zero.

number

number

number

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

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

[0081] After the private key share is generated in operation 408, the private key share may be used in operation 410 of method 400. The private key share may be used to collaboratively generate a valid signature for a transaction from a public group address (which may be broadcast by a member). That is, the private key share may be used in a threshold signature scheme to contribute to the signature generation. In a threshold signature scheme, a threshold number of private key shares of the congress must be used by each member to generate a valid signature that allows the digital asset to be transferred away from the congress. The node 102 executing method 400 may retrieve the private key share from storage and use this private key share to contribute to the signature generation. If a sufficient number of other congress members also contribute to the signature generation using their respective private keys, a signature may be generated and a valid spending transaction may be broadcast. The spending transaction is completed when the miners 104 (FIG. 1) of the blockchain network 100 add the transaction to a mined block (which 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 digital assets represented in the transaction may no longer be under the control of Congress, i.e., such digital assets may no longer be restricted by the Congress public key.

[0082] 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 such that neither other parts of the system nor the member itself can access any data stored in the enclave, such as the private key shares. Additionally, the TEE protects the private key in that if the member wants to return the deposit and accepts the deposit, the TEE cannot retain a copy of the private key, since the member must certify deletion of the private key before returning the member deposit.

[0083] Method 400 of Figure 4 may be performed during or after an initial setup phase, 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 rebalancing, discussed in more detail below).

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

[0085] Confiscation of Digital Assets

[0033] Referring now to Figure 5, an exemplary method 500 for confiscating digital assets is shown. The method 500 of Figure 5 may be performed by the node 102, which may be the same node that performs the method 400 of Figure 4. The method 500 may be performed after operation 408 of the method 400 of Figure 4. As such, the node 102 already has access to the private key shares when the method 500 of Figure 5 is performed.

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

[0087] In operation 503, in response to detecting malicious activity, node 102, in cooperation with other nodes in the congress, may suspend the member that is the malicious participant, i.e., the congress may exclude the malicious participant from further participation in the congress.

[0088] To ensure that all nodes 102 operate in compliance with a predefined protocol or standard, member deposits in the Congress Pool may be subject to confiscation. Confiscation means permanently blocking the return of member deposits that are deemed to have been confiscated. Digital assets forming member deposits that are not returned due to malicious activity may remain in the Congress Pool, but may not be returned (depending on the consensus that this action should be taken), may be transferred immediately or in the future to another unspendable address, or may be confiscated. The nature of the confiscation may depend on whether the Congress acts as a set-aside validator set for the side chain. For example, in operation 504, in response to detecting malicious activity by a malicious party, the node 102 executing the method 500 may use a private key share to provide a partial signature on a confiscation transaction (a transaction that transfers digital assets to a non-spendable address or to another node as a reward for exposing malicious activity). That is, the node cooperates with other nodes in the Congress to confiscate at least a portion of the digital assets previously transferred by the malicious party to the public group address (i.e., the Congress Pool). That is, in response to a group member identifying a violation of a predefined protocol or criteria, the private key share is utilized to contribute to the approval of a transaction of one or more digital assets associated with that group member and held within the Congress Pool.

[0089] Because a threshold signature scheme is used with the Congress public key, an individual node acting alone cannot transfer another Congress member's digital asset deposit away from the Congress pool (e.g., to a non-spendable address). Rather, the digital asset can only be confiscated by transfer if each member uses a threshold number of private key shares to generate a valid signature to transfer the digital asset to another address, or if members of a group with at least a threshold number of private key shares reach a consensus (in operation 503) to put a member on hold, and any withdrawal requests from the held member are automatically ignored. If the digital asset is confiscated by transfer, the other address to which the digital asset may be transferred can be associated with a non-spendable address. For example, this other address can be an address for which no private key exists, preventing anyone from accessing the digital assets tied to the public key of this address. If a transaction is confirmed that transfers the digital assets to a non-spendable address, or if there is consensus on the sidechain that the digital assets should be confiscated, the digital assets may be considered burned since they are no longer held by any member of the Congress or indeed by any node in the blockchain network 100.

[0090] Thus, in operation 504, a node can confiscate digital assets by using its private key share in cooperation with other members of the congress to generate a valid signature to a transaction's unspendable address, which in some embodiments can involve reaching a consensus on the second blockchain that all or a portion of a member's deposit should be permanently taken.

[0091] Additionally, in some implementations, the congress serves as a set of reserve validators that secure a proof-of-stake sidechain, which can be used as a broadcast channel. For example, the congress members of a sidechain may reach a consensus that a member has acted maliciously. This consensus may correspond to the confirmation of a sidechain transaction that contains criminal evidence of the malicious activity. Once consensus is reached, any withdrawal requests made by the malicious member of the member deposit are rejected and the deposit is considered confiscated. The confiscated digital assets may be burned at some point in the future. That is, after some time, a threshold number of members (not including the malicious member) may cooperate to approve the transfer of the confiscated digital assets to a non-spendable address.

[0092] Because the Congress is an open group that nodes 102 of the blockchain network 100 can join by depositing digital assets, group membership may change periodically. When such changes occur, the distribution of private key shares may be updated. Referring now to FIG. 6, an exemplary method 600 for updating private key share distributions is shown. Method 600 may be performed by nodes 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0093] Renewing private key share distribution with new public address At operation 602 of method 600, node 102 detects a redistribution request, which is a request whose fulfillment involves a redistribution of key shares. For example, node 102 may detect that a prospective new member has transferred digital assets to a public group address or that an existing member has requested a withdrawal of a member deposit.

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

[0095] Upon detecting the request in operation 602, the fulfillment involves a redistribution of key shares, and in operation 604, new private key shares are generated by node 102, similar to how private key shares were generated in operation 408 of method 400 of FIG. 4. Other member nodes of the congress also generate their own private key shares. These private key shares can be used in a threshold signature scheme with the new congress public key. A member that leaves the congress at this point does not generate new private key shares during operation 604, and since the leaving member is not assigned private key shares to use with the new congress public key, the leaving member loses the ability to participate in the congress and is no longer considered a congress member.

[0096] Further, upon detection of a redistribution request (which is a request whose fulfillment involves a redistribution of key shares), in operation 606, node 102, in cooperation with other congress members, transfers all digital assets in the public group address to a new public address associated with the new public key (which becomes the new congress public key).

[0097] Thus, according to method 600 of FIG. 6, when the distribution of the escrow changes or when a request to withdraw the escrow is received from a member, the private key shares may be regenerated and all digital assets under the control of the Congress may be moved to the new public key. The frequency with which the members of the Congress may be updated may be limited by the block time of the blockchain network 100. In many applications, rebalancing may only be required infrequently compared to the average block generation time of the proof-of-work main chain.

[0098] Update private key share distribution while preserving existing public group address 7, a further exemplary method 700 for updating a distribution of private key shares 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.

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

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

[0101] When a member leaves a congress using method 700, the member can ensure that his / her private key shares are deleted. To ensure that the old member's private key shares cannot be used, members of the congress may be required to use nodes 102 with a special TEE. A TEE is an architecture implemented at the hardware level that ensures that instructions and data executed within the TEE are protected from access and manipulation from the rest of the system. Using hardware mechanisms, the TEE can address the challenge of remote attestation that can be used to verify the integrity of the system to external parties such as other nodes of the congress.

[0102] Each member node may use a certified TEE configured to generate one or more random secret values ​​that remain inaccessible to the host system without compromising the hardware at the integrated circuit level. The secret value thus generated is used in the distribution generation of the secret key shares (e.g., in operation 410 of method 400 of FIG. 4). The secret value may also be used to establish the public keys shared during the setup phase of the congress. Because the computations associated with the setup protocol are performed within the enclave of the TEE, no member or former member can obtain information about their own or other's secret key shares through member-to-member communication or otherwise. The enclave within the TEE allows the TEE enclave to execute a remote attestation protocol that may be used to prove to other nodes that it is authentic and is executing authorized computer-readable instructions.

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

[0104] The TEE enclave also aims to ensure that the previous key shares and previous secrets that are no longer in use are deleted before returning the member deposit. More specifically, in order to return the member deposit, the authentication protocol may require the TEE enclave to attest to the deletion of the key shares. Each node 102 may interpret such attestation as confirmation that the need for deletion occurred at other nodes via a remote attestation protocol. Thus, the method 700 may also include a step of verifying that the private key shares previously held in the TEE of the member who left the congress have been deleted from the nodes associated with that member. This verification may be performed by receiving a proof of the deletion of the private key shares. Thus, the remote attestation protocol may be used to obtain a proof for the deletion of the private key shares previously held in the TEE of the member who left the congress.

[0105] Method 600 of Figure 6 and method 700 of Figure 7 each have various advantages. For example, method 600 of Figure 6 does not rely on secure deletion, nor does it 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 malicious pooling of key shares less likely to occur.

[0106] Method 700 of FIG. 7 avoids the need to relock digital assets under a new congress public key every time the constituency changes. Additionally, in some circumstances, method 700 may update constituencies faster than method 600 of FIG. 6 because, under method 700 of FIG. 7, digital assets are not moved to a new public key, so no transaction needs to be added to the blockchain to move all digital assets to a new public key. That is, because the public key does not change, constituencies can be updated using method 700 of FIG. 7 without waiting for several blocks to be generated to confirm the transfer of digital assets to a new public key.

[0107] Unregistering from the Congress As mentioned above, a group member may request to leave the congress from time to time, and when the group member unregisters from the congress, digital assets deposited in the congress pool may be returned to the group member. Referring now to Figure 8, an exemplary method 800 for returning a deposit is shown in flow chart form. The method may be performed by a node 102 in cooperation with other nodes 102 of the congress.

[0108] In operation 802 of method 800, node 102 receives a withdrawal request from a requester who is a congress member. The withdrawal request may also be referred to as a deregistration request. The withdrawal request is a request to withdraw a digital asset that was previously deposited by the requester and is currently managed by the congress. The request may be broadcast by the requester to all congress members.

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

[0110] If the Congress protocol is such that the Congress public key changes when constituency changes, node 102 may not acknowledge the deletion of the private key share since the private key share is no longer valid. Instead, a new Congress key is used and other digital assets under Congress control may be transferred to the new Congress key.

[0111] If the nodes 102 approve the withdrawal request based on the evaluation, then in operation 806, the nodes facilitate the withdrawal of the digital assets. That is, the nodes 102 use their private key shares to collaboratively generate a digital signature and use the digital signature to send the digital assets previously deposited by the requester back to the requester. For example, the digital assets may be sent back to an address where the digital assets were previously received. Operation 806 is performed according to a threshold signature scheme, whereby the withdrawal occurs only if at least a threshold number of congress members approve the withdrawal. Operation 806 is performed after a period of inactivity for a member wishing to deregister. This waiting period prevents members from engaging in fraudulent activities while executing the protocol for the return of the member deposit.

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

[0113] The Congress Protocol may, for example, be used to implement a Ghost Chain, in which case the Congress Protocol may be referred to as the Ghost Chain Protocol.

[0114] Ghost Chain Referring now to FIG. 9, diagram 900 illustrates a blockchain 902 and a ghost chain 904. The blockchain 902 is a block-based, proof-of-work, distributed ledger. The ghost chain 904 is a block-based, distributed, proof-of-stake, distributed ledger that can be used for any purpose, such as creating decryption keys according to one or more conditions specified in a flagged transaction or arbitrating disputes between nodes in a blockchain network. For example, a blockchain may include a challenge, where one node challenges a work product sent by another node. Such a challenge is indicated as "C" in FIG. 9. A challenge may occur, for example, when a node (i.e., the challenger) indicates that a proposed outcome in fulfilling a request is invalid.

[0115] When a challenge is raised by a node, a ghost chain is deployed. After a challenge C occurs in response to the challenge, the ghost chain is instantiated. The ghost chain may be instantiated with a genesis block, which is the last block (also called a terminal block) from a previous instantiation of the ghost chain. Miners can add some blocks to the ghost chain to resolve digital disputes until the ghost chain reaches a judgment, denoted by J.

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

[0117] After a decision is reached and a final transaction is constructed and signed, the ghost chain 904 is terminated and the constructed transaction is mined into the main blockchain 902. Because the ghost chain 904 is terminated, it differs from a typical blockchain in that it has a terminal block. This terminal block, which is the last block of the ghost chain 904, occurs when a decision is reached and the resulting transaction is validly signed, such as distributing funds to the main blockchain 902 according to the decision and distributing funds to reward miners of the ghost chain.

[0118] Requester-Proposer-Oppositor and Ghost Chains Thus, a node 102 of a blockchain network (FIG. 1) may implement a requestor-proposer-challenger protocol and / or a ghost chain resolution protocol. Such a node 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.

[0119] 10-13, which illustrate methods that may be included in the requester-proposer-challenger protocol and / or the ghost chain resolution protocol. The requester method illustrated in FIG. 10 may be performed by a requester for a task of a computation exchange. That is, a node 102 requesting completion of a task may perform the requester method of FIG. 10. A node is a node in a blockchain network (FIG. 1), and a node may be referred to as a requester.

[0120] A 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 have completed a task may perform the method of Figure 11. A node is a node in a blockchain network (Figure 1), and the node may be referred to as a proposer.

[0121] A 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 provided by a proposer may perform the method of Figure 12. A node is a node in a blockchain network (Figure 1), and the node may be referred to as a challenger.

[0122] The arbitrator method 1300 is shown in FIG. The arbitrator method 1300 may be performed by a node of a blockchain network in cooperation with other nodes of the blockchain network. A node that performs the arbitrator method in cooperation with other nodes may be referred to as an arbitrator.

[0123] The methods 1000, 1100, 1200, and 1300 of Figures 10-13 may be implemented in concert. For example, the methods collectively provide a requestor-proposer-challenger protocol in which a ghost chain is used to ensure the validity of a proposer's solution.

[0124] In operation 1002 of the requester method 1000 (FIG. 10), a node, referred to as the requester, makes a request. The request is a request to complete a task. For example, the task may be a request for a work product or a request to determine if an off-chain event has occurred, as described in more detail below. The request provides a bounty in the form of a digital asset associated with the blockchain network in exchange for successful completion of the task. The request may originate from outside the blockchain (i.e., "off-chain"). For example, the request may originate at a web server accessible via the Internet. The request may be defined as successfully completed if a candidate solution to the request is not challenged for a certain period of time (which may be referred to as a "challenge period") or if the challenge is resolved by the members of the Congress voting on whether the candidate solution is correct. In some embodiments, the ghost chain is deployed in response to the outcome of the vote.

[0125] In some embodiments, a computation exchange may enable a node to offload computational tasks, as described below. A request may be raised on a computation exchange (at operation 1002). A computation exchange may be a collection of requested tasks. For example, multiple tasks may be published on a computation exchange. The tasks may be published by the same requester or by different requesters. A computation exchange allows a node to offload computations or performance of an algorithm to other nodes.

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

[0127] The proposer may then submit a proposal at operation 1106 of method 1100 (FIG. 11). A proposal is a claim that the proposer has completed 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 the public key of the blockchain network 100 to the requester. The proposer may also commit to a solution to the task. This commitment may be in the form of a hash of the solution (i.e., a hash of a work product, such as the output of a computation or another type of solution).

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

[0129] In response to receiving the proposal, at operation 1006 of method 1000 of FIG. 10, the requester may construct transaction T1. Transaction T1 includes the bounty as an input. The transaction includes the bounty and the proposer's deposit as outputs (i.e., output of T1, T1_out = bounty + proposer's deposit). Transaction T1 is signed to allow the proposer to add to his or her input. For example, transaction T1 may sign SIGHASH_ALL|SIGHASH ANYONECANPAY. SIGHASH_ALL is the default signature hash type that signs the entire transaction except for the signature script, preventing modification of the signed parts. SIGHASH ANYONECANPAY is the signature hash type that signs only the current input.

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

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

[0132] Although not shown in Figures 10 and 11, the proposer can receive the transaction T1 constructed in operation 1006 and add the proposer's deposit as an input to transaction T1. The proposer broadcasts the transaction to other nodes in the blockchain network (Figure 1). The transaction is mined (i.e., added to a block) and made public on the blockchain.

[0133] Once a transaction is mined into the blockchain, a challenge period begins during which any node (FIG. 1) may challenge the proposal submitted by the proposer. If no challenge is made during the challenge period, the proposer may claim the bounty and the proposer's deposit from transaction T1. The proposer may start a timer to track the time remaining in the challenge period and automatically take action when the challenge period ends. For example, the proposer may provide a work product (which may be referred to as a solution), such as a processor work product, to the requester to unlock the transaction. In one example, the proposer may provide a work product indicating that an off-chain event occurred, and node 102 (FIG. 1) may challenge the proposed solution that the off-chain event did in fact occur.

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

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

[0136] Note that if there are no challenges to the proposer's solution, the complete transaction can be executed on the Proof of Work main blockchain 902 (Figure 9) without requiring the execution of the challenge protocol or the Ghost Chain protocol.

[0137] However, a challenger may challenge during the challenge period. For example, in operation 1202 of method 1200, a challenger challenges. The challenger may perform operations similar to operations 1102 and 1104 of method 1100 of FIG. 11 . That is, the challenger may identify a request and complete tasks off-chain before challenging in operation 1202. The challenger may also determine that a challenge should be filed by determining that the challenger's solution differs from the proposer's solution. For example, the challenger may perform a hash of his or her solution and compare the hash to the hash of the proposer's solution, and if the hashes are different, the challenger may file a challenge.

[0138] In operation 1202 of method 1200 of FIG. 12, a challenger files a challenge within a challenge period. The challenger may file a challenge by broadcasting an intent to file a challenge to the blockchain network 100. When a challenge is filed, a group of nodes may assist in determining the validity of the solution. For example, a challenge may be filed in response to a proposal that an off-chain event occurred, where the challenge asserts that the off-chain event did not in fact occur, such that a group of nodes (e.g., a congress) may determine whether to accept the solution provided by the proposer or challenger.

[0139] For example, referring briefly to FIG. 13, this figure illustrates a flow chart of a method 1300 for an arbitrator, where a group of nodes can form a congress that can be used to arbitrate when a challenge is filed. As described above, the congress is secured by depositing digital assets in a proof-of-work blockchain network. For example, in operation 1302 of the method 1300, an arbitrator performing the method 1300 for an arbitrator can join a congress. For example, the arbitrator may perform the method 400 for joining a congress described above with reference to FIG. 4. Thus, in operation 1302, an arbitrator joins a group, which may be called a congress, by depositing digital assets in a public group address associated with the congress to become a group member. The arbitrator performs this deposit on the proof-of-work blockchain network. As described above, the group is associated with a threshold signature scheme for nodes to control private key shares. Joining a group (which may also be called registration) may occur, for example, during deployment of the Ghost Chain. 13 shows that operation 1302 (joining the congress) occurs before operation 1306 (expanding the ghost chain), so operation 1302 may be performed by a node that joined the congress during a previous expansion of the ghost chain (i.e., not during the expansion in operation 1306). However, operations 1306, 1308, and 1310 may be performed by a node that joins the group during operation 1306, for example.

[0140] At operation 1304, the arbitrator cooperates with other nodes in the group to detect a challenge made by the challenger at operation 1202 of the challenger method 1200 of Figure 12. More specifically, the arbitrator cooperates with other nodes in the group to detect a challenge by the challenger to the proposer's work product in response to a request made by the requester.

[0141] With transaction T1 described above, the group takes over control of the bounty and proposer's escrow when a challenge is made. That is, transaction T1 is constructed to be unlockable by the Congress at any time. Thus, the bounty and escrow are placed under the group's control and maintained if a challenge is detected within a period of time called the challenge time following the proposer's delivery of a solution to the request. Thus, when a challenge is detected, the group takes control of the bounty and proposer's escrow.

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

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

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

[0145] Transaction T2 is broadcast to the main blockchain network and mined on the main blockchain network such that the challenger deposit is bound by the Congress public key. The bounty, the proposer deposit, and the challenger deposit are under the exclusive control of the group.

[0146] Thus, the challenger provides evidence of the alternative solution and the deposit to the arbitrator. In operation 1306 of the method 1300 for the arbitrator, after transaction T2 is mined on the main blockchain network, the arbitrator cooperates with other nodes in the group to deploy a ghost chain to resolve the challenge. As described above, the ghost chain is a proof-of-stake blockchain where miners of the ghost chain are members of the group. That is, members of the congress are allowed to mine on the ghost chain. Member deposits on the proof-of-work blockchain network act as a contribution to enable members of the congress to mine on the ghost chain, and the probability that a member will be selected to mine is proportional to the relative amount of the deposit.

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

[0148] Additionally, while the Ghost Chain is being deployed, members can be allowed to register or request to be deregistered from the group. During the registration phase, we register a new member and assign him or her a private key share (as described above with reference to Figure 4). The new member is provided with a genesis block (which can be authenticated by a current threshold of members) and subsequent blocks generated during the registration process.

[0149] A Ghost Chain execution may also include a pre-deregistration phase. During this pre-deregistration phase, a member requesting deregistration can submit proof of removal of certain personal data. Such proof may be required for the return of the member deposit. Evidence of misconduct that may prevent the return of the member deposit can be submitted at this phase (e.g., a newly registered member may submit a genesis block that was pre-committed by current member(s) but is suspected to be fake). The deregistration technique is described in more detail above with reference to Figure 8.

[0150] The deployment of the ghost chain may include an adjudication operation by an arbitrator in cooperation with other nodes in the group. The adjudication operation may include receiving evidence from the proposer and the challenger and resolving the challenge based on the evidence. For example, the received evidence may include one or both of a final solution or intermediate results. The intermediate results may be the result of a step or a series of steps required to perform the requested task. For example, the intermediate steps may be partial work products of the task. The final solution is the final work product that completes the requested task. Evidence may be submitted by the proposer at operation 1108 of the method 1100 for the proposer of FIG. 11 and by the challenger at operation 1206 of the method 1200 for the challenger of FIG. 12. In some cases, the final solution is provided without the intermediate results used to reach the final solution (e.g., a claim that an off-chain event did or did not occur may be provided without the intermediate results).

[0151] The arbitrator and other nodes in the Congress may resolve the challenge by performing a task related to the request to determine the correct solution. For example, the task (e.g., a calculation or algorithm) may be performed on-chain (i.e., on the ghost chain itself). The group may determine whether the proposer's or challenger's solution is correct by comparing such solution to a unique solution determined on the ghost chain. During this process, group members (i.e., miners on the ghost chain) perform calculations and / or analysis to arbitrate the dispute. Group members reach a consensus during this process and sign a block. In some cases, the resolution of the challenge may include a vote by nodes (e.g., members of the Congress) to determine whether the proposer's or challenger's solution should be accepted. This may be used in the case of a binary solution where the solution is one of two values, for example, to determine whether an off-chain event has occurred or not. The result of the vote may be defined as true with respect to whether an off-chain event has occurred or not and treated as the correct solution.

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

[0153] After reaching an arbitration decision on the blockchain, the arbitrator, in cooperation with other nodes in the group, constructs a final transaction (which, when fully signed, is mined into the main blockchain network). The final transaction, which may also be called a settlement transaction, may include various digital asset transfers; for example, (i) bounty + escrow (which may be transferred to nodes deemed successful or legitimate during the arbitration process); (ii) mining fees (for ghost chain mining that has already been performed); (iii) genesis payment (which is a digital asset transfer that occurs based on the previous run of the ghost chain and is determined from the genesis block); and / or (iv) return of member escrows for members who have unsubscribed.

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

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

[0156] The particular manner in which the digital assets are distributed in the final transaction depends on the outcome of the arbitration. For example, if the challenge is successful, the arbitrator, in cooperation with other nodes, may transfer at least the challenger's deposit to the challenger and distribute the proposer's deposit to the ghost chain miners in proportion to the absolute number of blocks mined. If the challenge is successful and the challenger's solution is determined to be correct, the bounty may also be transferred to the challenger. Thus, the challenger may receive the digital assets at operation 1208 of the challenger method 1200 of FIG. 12. However, if a binary search is used such that the correct solution is not identified, the bounty may be returned to the claimant who resubmits the claim, allowing the challenger to submit a proposal based on the answer. Alternatively, if the proposer is eliminated by the binary search, the claimant may treat the challenger's commit as a proposal and resume operation 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 previously considered to be the challenger is now considered to be the proposer. Thus, the new transaction T1 may be constructed to be unlocked by the challenger after the end of the challenge period by providing a solution corresponding to the hash of the solution as provided by the challenger in transaction T2 described above.

[0157] If the proposer's work product is determined to be valid, the arbitrator may cooperate with other nodes to transfer the bounty and the proposer's escrow to the proposer and distribute the challenger's escrow to the ghost chain miners in proportion to the absolute number of blocks mined. The proposer may then receive the digital assets at operation 1110 of method 1100 of FIG.

[0158] 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 made. For example, if no challenge was made, the proposer committed the solution to the blockchain using transaction T1 described above with reference to operation 1006 of the method 1000 of FIG. 10. However, if a challenge was made and a solution to the request is determined by the ghost chain, the ghost chain node may send the solution to the requester at the end of the ghost chain (e.g., at operation 1310 of the arbiter method 1300 of FIG. 13). Thus, the ghost chain protocol allows nodes participating in the ghost chain to automatically send the solution to the requester once they have determined the solution.

[0159] Furthermore, after a decision is reached on the ghost chain and a transaction is constructed and validly signed, the ghost chain is terminated (at operation 1310 of the arbiter 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 sent back to the proof-of-work blockchain network.

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

[0161] As mentioned above, when the arbitrator (i.e., the congress node) reaches a decision, the nodes cooperate to construct a transaction that is broadcast on the main chain (at operation 1308) once a validly signed transaction is generated by adding partial signatures via the threshold signature scheme as described above. Since the transaction itself is a multi-party computation, the nodes that contribute to the transaction may receive rewards for participating in the transaction. However, since the transaction is specified before it is signed, rewards for participating in the signature (including sending partial signatures to the ghost chain via a transaction and actually mining the block) may be deferred until further deployment of the ghost chain. Such deferral may be provided at operation 1310. More specifically, the leaf block may be constructed with information that allows genesis payments to be processed during future deployment of the ghost chain. Such information may be a record of mining fees that may be attributable to blocks created after the construction of the final transaction, such as blocks created during the signing of the final transaction. That is, a genesis payment may be provided to reward nodes that contributed to the signing of the final transaction. The terminal block of the ghost chain becomes the genesis block of the next ghost chain run (i.e., when the ghost chain is next deployed). Thus, a record is created in the terminal block for future genesis payments. Note that according to the embodiment shown immediately above, members register / unregister during the ghost chain run, but this can be triggered by an appeal. In alternative embodiments, registration / unregistration at regular intervals or under other conditions is also possible. This may include a scheduled run of a ghost chain dedicated to this purpose, which is similar to the ghost chain deployment described above, except that there is no arbitration and adjudication phase. In this case, mining fees may be paid at least in part from the “registration fee” required in return for registration.

[0162] Also, note that method 1300 described above describes a run of a ghost chain that is not a first run of a ghost chain. That is, method 1300 describes a run of a ghost chain that was deployed at some point in the past, where there is already a terminal block that includes a genesis payment for the ghost chain. Method 1300 can be modified to allow for a first ghost chain to be deployed. For example, the first time a ghost chain is deployed, a genesis block can be established in a different manner. For example, the genesis block can be provided by an initial trusted party.

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

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

[0165] Although the examples above refer to instruction codes available in Bitcoin, the methods described herein can be used in other types of blockchain networks.

[0166] Although the methods described above have been generally described as being performed at a node, the functioning of the methods relies on cooperation with other nodes and may be performed elsewhere.

[0167] Event-locked encryption from the Congress and Ghost Chains A technique for performing event-locked encryption using congress and ghost chains is described below.

[0168] Event-locked encryption may refer to a mechanism for making cryptographic operations contingent on the occurrence of an event. As an example, time-locked encryption is a particular type of event-locked encryption that refers to a mechanism for sending a message "into the future" so that a given ciphertext is decrypted at or after a particular time in the future. In this case, the event is the passage of (possibly random) time. Thus, event-locked encryption can be used to ensure the performance of cryptographic operations contingent on the occurrence of an event. Examples of cryptographic operations that can be performed include decrypting ciphertext, authenticating digitally signed messages or data, etc. For example, the techniques described herein can be used to perform witness encryption, e.g., as discussed in Bitanksy et al., "Time-Lock Puzzles from Randomized Encodings." This can improve the efficiency of solving problems posed in the context of computational encryption.

[0169] For purposes of illustration, the cryptographic operation performed as part of the event-locked encryption described in connection with Figures 9 and 10 is the decryption of ciphertext contingent on a determination that an event has occurred. However, in various embodiments, other cryptographic operations may be performed instead of or in addition to those described in connection with those shown in Figures 9 and 10. Generally speaking, one or more operations (operations), such as such cryptographic operations, may be performed upon a determination that an event has occurred.

[0170] Events used to facilitate event-locked encryption can be categorized as on-chain and off-chain events. An on-chain event refers to an event that can be confirmed through inspection of the blockchain, and an off-chain event may refer to an event that is not an on-chain event. A message may be encrypted to public key A according to an identity-based encryption scheme. Public key A may be a cryptographic public key with a corresponding cryptographic private key SkA that is accessible to the entity performing the encryption. The Congress public key may be according to those described elsewhere, such as in connection with FIG. 1. The encrypted message, public key A, and the event (e.g., a time threshold) digitally signed by private key SkA may be sent to the blockchain via a flagged transaction. Once the event is confirmed by Congress, a ghost chain is instantiated, which can create a decryption key, facilitating the decryption of the encrypted message. Various techniques for detecting when an event has occurred are discussed below.

[0171] As described elsewhere, such as in connection with FIG. 4, an entity may deposit digital assets in a Congress pool and, in response, receive private key shares to the Congress 110. In some embodiments, the shares received by an entity may be proportional to the amount and / or value of the deposited digital assets. The private key shares may be utilized in a threshold signature scheme in which the Congress manages digital assets restricted by a public key associated with the Congress. The Congress public key restricts digital assets deposited in the Congress pool by members of the Congress 110 in exchange for private key shares, and digital assets deposited (i.e., placed under the total, partial, or conditional control of the Congress) in an address associated with the Congress pool that members or non-members of the Congress 110 have deposited for reasons other than obtaining private key shares. Non-members or members may deposit digital assets in an address associated with the Congress for various reasons. For example, a reason for depositing digital assets in an address associated with the Congress is to provide a fee for the execution of one or more instructions upon detecting the occurrence of an event.

[0172] Ghost chain miners can cooperate to create decryption keys. In general, ghost chains 904 can be deployed for any reason other than simply resolving disputes. A ghost chain is instantiated and acts as an append-only bulletin board for sharing information used to create decryption keys. Members of a congress can be ghost chain miners.

[0173] In some embodiments, a method for performing threshold encryption and decryption may be described according to the techniques described herein. An entity may perform encryption according to an identity-based encryption scheme. For example, an entity may encrypt a message to a cryptographic public key associated with the entity, which utilizes a Congress public key as the system-wide public key of the identity-based encryption scheme. The identity-based encryption scheme may conform to that described by Boneh and Franklin in "Identity-Based Encryption with Weil Pairings." Thus, an entity may encrypt a message to a cryptographic public key using the system-wide public key. The entity has access to a corresponding cryptographic private key, and the system-wide public key may be the Congress public key.

[0174] A transaction can be broadcast to the proof-of-work blockchain network, and the transaction can include an encrypted message according to the identity-based encryption scheme, a message public key A (i.e., the encryption public key that encrypted the message under the identity-based encryption scheme), an event that triggers decryption of the encrypted message, and a fee. In some embodiments, the message public key A is associated with an entity that has access to a signature key S kA, where the message public key A and the signature key S kA are the public and private keys of an asymmetric key pair, respectively. The transaction may further include data that is digitally signed using the private signature key S kA. For example, a set of conditions for decrypting the encrypted message is digitally signed using the private signature key S kA, and the validity of the digital signature is verified using the message public key S kA before deriving the decryption key (e.g., when the message public key A and the private signature key S kA form an asymmetric key pair). Generally speaking, the set of conditions may include information such as when decryption should be performed (e.g., in response to a time-based event) and how decryption should be performed (e.g., the presence or absence of contributions to the decryption key itself must be encrypted under the set of public keys S so that the decryption key is available to one or more entities that have access to the set of private keys corresponding to the set of public keys S). The event may be an event or condition that, when met, indicates that the encrypted message is made decryptable by making the decryption key available. The fee may be for the transfer of digital assets to an address related to the public group address of the Congress 110. The fee may be distributed among members of the Congress who cooperate and participate in performing event-locked decryption of the encrypted message.

[0175] In some cases, it may be implicitly understood that upon verification of the occurrence of an event, the encrypted message is decrypted and / or made decryptable. In other cases, the transaction may further include instructions to perform one or more operations (operations) related to the encrypted message. For example, the instructions may be to decrypt the message and authenticate the decrypted contents. In other embodiments, the instructions may be to decrypt the message, which may include proprietary information (e.g., a private key) that effectively transfers the asset to the owner.

[0176] When consensus is reached that an event has occurred on the main blockchain, a ghost chain can be deployed to generate a decryption key that can be used to decrypt the encrypted message. Generally, in the case of an on-chain event, consensus is reached when the event occurs, but in the case of an off-chain event, consensus can be reached when a threshold number of proofs are confirmed. Thus, a ghost chain can be deployed. The ghost chain can be consistent with those described elsewhere in this disclosure, such as those described in connection with Figures 9-13. The ghost chain 904 can be instantiated with a genesis block, which is the final block from a previous instantiation of the ghost chain. Many blocks are added to the ghost chain by miners, and the decryption key is derived.

[0177] The blocks added to the ghost chain can be used to create a decryption key that can be used to decrypt the encrypted message. Once the necessary amount is included in the ghost chain block (e.g., if the decryption key can be generated), a final transaction can be constructed and signed that has the effect of distributing funds to the main blockchain 902 (e.g., nodes that participate in mining the ghost chain may be paid to create the decryption key). In some cases, the decryption key may be encrypted using a public key associated with the intended recipient and sent in encrypted form to the ghost chain 904. The intended recipient can cryptographically derive the decryption key using the corresponding private key. In some cases, this information may be published on the main blockchain.

[0178] After the final transaction is constructed and signed, the ghost chain 904 is terminated and the constructed transaction is mined into the main blockchain 902. Because the ghost chain 904 is terminated, unlike a typical blockchain, the ghost chain 904 has a terminal block. This terminal block, which is the last block in the ghost chain 904, occurs upon completion of deriving a decryption key or other specified operations, and the resulting transaction that distributes funds to distribute funds on the main blockchain 902 and reward miners of the ghost chain is validly signed.

[0179] In one embodiment, alternatively, the decryption key may be derived using a side chain. A side chain refers to a proof-of-stake blockchain that runs continuously and is not configured to terminate upon derivation of the decryption key. The side chain can be configured to continue to operate and perform various tasks other than derivation of the decryption key. In one embodiment, the side chain is a proof-of-stake blockchain that is configured to facilitate multiple activities, including but not limited to derivation of cryptographic keys. Many blocks are added to the side chain by miners, and the decryption key is derived. The blocks added to the side chain can be used to create a decryption key that can be used to decrypt the encrypted message. The decryption key may be obtained by including the required amount in the side chain block.

[0180] Events may generally be classified as on-chain or off-chain events. An on-chain event may refer to an event that may occur or not occur based on information obtainable from the blockchain. For example, information obtainable from the blockchain may include information about the occurrence of one or more transactions (e.g., a transfer of digital assets from a specific party to another party, a specific number being transferred, a specific amount being transferred, etc.), information contained in the transaction such as a timestamp of when the transaction occurred, or information in the block header such as the height of the block. Generally speaking, consensus on on-chain events may be quickly and efficiently reached by members of the Congress. In the case of an on-chain event, the TEE contributes to the creation of a decryption key using its internally held key shares if it confirms the required event in a confirmed block on the blockchain.

[0181] An off-chain event may refer to an event that may occur or not occur based on information outside of the blockchain. An off-chain event may include information on which a member of the congress can make a decision. For example, an off-chain event may be a determination that a person has died. In response to a determination that an event has occurred, a decryption key is generated (or decryption of an encrypted message occurs). Generally speaking, the TEE does not evaluate whether an off-chain event has occurred. Instead, a congress node may attest to having evaluated whether an event has occurred, issued a certificate for the occurrence or non-occurrence of the event, and verified the occurrence or non-occurrence of the event by signing the certificate using a private key that is only accessible to the node. For example, the certificate may be digitally signed and cryptographically verified using a public key corresponding to the account to which the member's deposit was transferred. Consensus may be reached regarding the verification of the threshold certificates, and a transaction may be constructed and signed as described above.

[0182] In one embodiment, event-locked encryption may be implemented at least in part using the main chain and the blockchain, for example, in connection with various embodiments described above. In embodiments configured to use a side chain to perform one or more cryptographic operations (e.g., deriving a decryption key), the on-chain event that triggers the creation of the decryption key may be an event on the main blockchain or the side chain. For example, in the case of time-locked encryption that makes the decryption key available at a threshold time, the passage of the threshold time may be detected based on a timestamp detected in a block mined on the main blockchain or the side chain. Additionally, in the case of a side chain, a certificate regarding the occurrence of the off-chain event may be mined on either the main chain or the side chain. In some cases, whether the certificate is sent to the main chain or the side chain may be based on a determination that the main chain or the side chain has a faster and more regular block generation. The advantage of generating blocks faster and more regular is that it takes less time to confirm a block. Additionally, it is noted that in various embodiments that use a ghost chain to create the decryption key, the certificate is sent to the main chain, and the ghost chain may be instantiated in response to sufficient certificates being confirmed.

[0183] 14, a diagram 1400 illustrates a blockchain 1402 that may be utilized to implement various techniques of the present disclosure. In some embodiments, the blockchain 902 is a block-based proof-of-work distributed ledger.

[0184] In some embodiments, the message 1404 may include data, information, etc., which is in digital form and encrypted by the sender under an event-locked encryption scheme such that the message is decryptable and / or decrypted upon the occurrence of an event. The message 1404 may be encrypted to a cryptographic public key 1408 according to an identity-based encryption scheme utilizing a congress public key 1406. The cryptographic public key 1408 may have a corresponding cryptographic private key 1422 accessible to the entity generating the event-locked message. The congress public key 1406 may be an asymmetric public key associated with a congress 1410 shown in FIG. 14. The congress 1410 shown in FIG. 14 may correspond to a congress described elsewhere in this disclosure. This congress may be utilized to verify the occurrence of on-chain and off-chain events. The message 1408 may be encrypted to a cryptographic public key 1408 according to an identity-based encryption scheme utilizing the congress public key 1406, thereby generating an encrypted message 1414.

[0185] A transaction 1416 is broadcast to the blockchain 1402, and the transaction may include an encrypted message 1414, a sender public key 1408, and an event 1412. The transaction may be a flagged transaction that includes an identifier as metadata that makes it recognizable as a transaction that serves a particular purpose. The event 1412 may be an event or condition that, when met, indicates that the encrypted message 1414 should be decryptable. The event 1412 may be an on-chain event or an off-chain event, or any combination thereof. The event may correspond to the on-chain and off-chain events described elsewhere in this disclosure. The event 1412 may be encoded in various forms, such as expressed as a predicate that may evaluate to a TRUE or FALSE statement. For example, the event 1412 may be the passage of a specified amount of time, after which the encrypted message 1414 should be decryptable by the recipient 1420. The event 1412 may be digitally signed by the entity that encrypts the message. The digital signature may be generated using a sender private key 1422, which is an asymmetric private key corresponding to the sender public key 1408 used to generate the encrypted message 1414. The sender public key 1408 may be included in the transaction 1416 and may be utilized to cryptographically verify that the digital signature generated in the event 1412 is authentic. In some embodiments, the transaction 1416 also includes a fee. The fee may be for the transfer 1410 of the digital asset to an address associated with the public group address of the congress. The fee may be distributed among members of the congress who cooperate and participate in performing the event-locked decryption of the encrypted message. Methods and processes for generating event-locked messages are described in more detail in conjunction with FIG. 15.

[0186] When a member of the congress 1410 detects that the event has been met, the ghost chain can be deployed to create the decryption key. The ghost chain can be consistent with that described elsewhere in this disclosure, such as that discussed in connection with Figures 9-13. The ghost chain can be instantiated after a node (e.g., a member of the congress) determines that an event has occurred indicating that the event-locked encrypted message should be decrypted. The ghost chain 904 can be instantiated with a genesis block, which is the final block from a previous instantiation of the ghost chain. As more blocks are added to the ghost chain by miners, the creation of the decryption key becomes easier.

[0187] Once the decryption key is created, a transaction is constructed and signed in the ghost chain. The transaction may have the effect of distributing funds to the main blockchain 902. For example, nodes participating in mining the ghost chain are paid to perform one or more operations (e.g., creating and / or distributing the decryption key 1418) when an event is determined to have occurred. In some cases, the decryption key 1418 may be made available to one or more specific parties. For example, consider the case where an encrypted message can only be decrypted by the intended recipient. Upon detecting the occurrence of the event, TEEs belonging to the members of the congress 1410 may generate respective shares of the decryption key, encrypt those shares with a public key associated with the intended recipient, and include those encrypted shares in the ghost chain. The intended recipient may then utilize the corresponding private key to gain access to the decryption key. The recipient 1420 may refer to an entity or computing entity on behalf of the entity receiving the decryption key 1418. The decryption key 1418 can be utilized to perform a cryptographic operation to allow the recipient 1420 to decrypt the encrypted message 1414 that is made available to the recipient 1420 via the blockchain 1402. In some cases, the recipient can refer to multiple entities, such as a group of users or even the general public. For example, the decryption key is published on the main chain, allowing anyone to obtain the decryption key and decrypt the encrypted message. Methods and processes for obtaining the decryption key and using the decryption key to decrypt the encrypted message are described in more detail in conjunction with FIG. 16.

[0188] 15, an example method 1500 for creating an event-locked message that may become decryptable based on the occurrence of an event is shown. Method 1500 may be performed by any suitable system, such as a computing device executing an instance of the blockchain protocol on which blockchain network 100 operates. The method may be performed by node 104. This method may be used, for example, to implement a time-locked encryption technique in which a message is encrypted and the encrypted message becomes decryptable and / or decrypted once a specified time has been reached or passed.

[0189] The system may obtain 1502 a cryptographic public key and a corresponding cryptographic private key. The system may encrypt 1504 a message to the cryptographic public key according to an identity-based encryption scheme, such as the Boneh-Franklin identity-based encryption scheme. The encryption may be performed according to the techniques described by Boneh and Franklin in "Identity-Based Encryption with Weil Pairings." The encryption may be performed using elliptic curve cryptography, such as the methods described below. Encrypting the message may produce an encrypted message or ciphertext.

[0190] The system may also generate (1506) a digital signature for the event that specifies one or more conditions for decryption. The conditions may, for example, indicate the time when the decryption should occur (in time-locked encryption). In some cases, the conditions may also specify whether the contribution to the decryption key should be encrypted before the TEE outputs it, and if so, what set of keys should be used for encryption. A transaction that includes a contribution to the decryption key may be digitally signed using a cryptographic private key that corresponds to the cryptographic public key utilized to encrypt the message according to an identity-based encryption scheme. The authenticity of the digital signature may be cryptographically verified using the cryptographic public key, which may be transmitted to the proof-of-work network as part of the transaction. In some embodiments, the digital signature may be generated via additional data, such as a nonce.

[0191] In some embodiments, the system sends one or more transactions to the proof-of-work blockchain network (1506), including the encrypted message, the public key that encrypted the message, an event indicating the condition under which the encrypted message should be decrypted, at least a corresponding digital signature for the event, and a fee. The event may be an on-chain or off-chain event, such that the Congress 110 can reach a consensus on whether the event has occurred. In the case of an off-chain event, decryption may occur depending on the consensus that a threshold number of certificates for the occurrence of the event have been verified. There may be additional conditions for decryption to occur, such as requiring a threshold to be maintained for a certain period of time (e.g., in a revocable system). The condition may be specified by the requester and encoded in one or more transactions as described above. For example, in the case of time-locked encryption, the event may be the passage of a (possibly random) amount of time, which can be determined and verified using on-chain information. The fee may be for the transfer of digital assets to an address associated with the Congress 110 public group address. The fee may be distributed among members of the Congress who cooperate and participate in performing the event-locked decryption of the encrypted message. In some cases, one or more transactions may indicate that one or more operations (operations) need to be performed in addition to or instead of decrypting.

[0192] In some embodiments, method 1500 may be implemented according to an identity-based threshold scheme as described by Boneh and Franklin in "Identity-Based Encryption with Weil Pairings" and may provide improved efficiency and reliability using techniques described in connection with method 1500 and elsewhere in this disclosure. In some embodiments, method 1500 may assume that there exist G1 and G2 with a bilinear mapping e:G1×G1→G2 and a generator P of G1. In one embodiment, it is assumed that G1 and G2 are both finite cyclic groups of the same prime order q and that the discrete logarithm problem is hard on G1 and G2. Additionally, a congress public key P pub and the corresponding private key

number

number

[0193] Referring now to FIG. 16, this figure illustrates an exemplary method 1600 of event-locked decryption. The method 1600 of FIG. 16 may be performed cooperatively by one or more computer systems, such as nodes of a congress. The method 1600 may be performed at some point after the transaction described in connection with FIG. 15 has been sent and confirmed on the blockchain network. The one or more transactions may include an encrypted message, a cryptographic key, such as a public key associated with an intended recipient, and the like. For example, a first transaction may include an encrypted message, a cryptographic key, an event or condition indicating when the encrypted message should be available for decryption, and a second transaction may include a fee to the congress that may be distributed in connection with the generation of the decryption key upon the occurrence of the event or condition specified in the first transaction.

[0194] A system such as a member of the congress, or more generally a node of a blockchain network, may detect the occurrence of an event related to the transaction described above (1602). The event may be an on-chain event or an off-chain event. In the case of an on-chain event, the TEE contributes to the creation of the decryption key by utilizing the key shares held internally if it confirms the requested event in the blockchain. In some cases, it may be necessary to monitor the on-chain event with confirmed transactions. In the case of an off-chain event, a consensus may be reached on the on-chain event that is considered to be a reliable indicator that the off-chain event has actually occurred. For example, the corresponding on-chain event may be that a threshold number of congress members have been notified that they believe the off-chain event has occurred by sending a specific flagged transaction to the blockchain. In some cases, these notifications (signals) may be retracted if the congress members later determine that the off-chain event has not occurred (e.g., the nodes may determine later and / or based on additional information that the off-chain event has not actually occurred). In such a system, reaching consensus may further require that a flagged transaction remain unretracted for a certain period of time.

[0195] As an alternative method for determining whether an off-chain event occurred, a node may send an indication that an event occurred and include a deposit of digital assets. The deposit may be returned (as well as a payment of at least a portion of the deposited fee as a reward for decoding the event-locked message) if the Congress determines that the event occurred, or may be forfeited if the Congress determines that the event did not occur. In some cases, the solution provided by a node may be challenged, and the resolution of whether an off-chain event occurred may be determined by having members of the Congress vote on whether to accept that the event did or did not occur.

[0196] A transaction such as that described in connection with FIG. 15 may include an encrypted message, a public key A over which the message is encrypted according to an identity-based encryption scheme, and a digitally signed event. The validity of the digital signature over the event may be verified using the public key A (1604). In some cases, the creation of the decryption key by the Ghost Chain may be conditional on the digital signature being valid. In a time-locked encryption scheme, the event may be a timestamp indicating when the encrypted message should be available for decryption. Verifying the authenticity of the digital signature over the timestamp ensures that an entity without access to the private signature key SkA corresponding to the public key A cannot prematurely trigger the creation of the decryption key. By generating a cryptographically verifiable digital signature with the public key A included in the transaction, an adversary cannot induce the Congress to prematurely release the decryption key, for example by "front running" this transaction with another transaction containing any ciphertext encrypted to the public key A before the decryption time. By requiring transactions to include a valid signature, "front-running" attacks are made impossible, as the congress will not progress unless a transaction includes a valid digital signature that was generated using the private signing key SkA that corresponds to the public key A.

[0197] A ghost chain may be deployed (1606), and members of the congress, in cooperation with other nodes in the group, may create or obtain a genesis block for the ghost chain. The genesis block may be the final block from a previous ghost chain deployment (e.g., a terminal block from the last instance the ghost chain was executed, where the previous execution may have occurred in response to, for example, a previous challenge or a previous event-locked decryption). This block may include information regarding the genesis payment. The genesis payment is a transfer of digital assets that has not yet occurred based on a previous deployment of the ghost chain. The ghost chain may be deployed using techniques described elsewhere, such as in connection with FIG. 13.

[0198] Once consensus is reached among the groups that hold at least the threshold number of private key shares, the congress nodes can create a decryption key that can be used to decrypt the encrypted message (1608). The decryption key can be created by including the required amount in a ghost chain block. For example, this can be achieved by sending the amount to the ghost chain via a transaction or by directly mining the amount into the ghost chain as described above. For example, according to a pair-based scheme on an elliptic curve, the decryption key d A =sQ A where Q A is derivable from the encryption key used to encrypt the message, and the decryption key is derivable according to a threshold secret sharing scheme by the cooperation of at least a threshold number of secret key share holders (i.e., members of the Congress).

[0199] In some embodiments, the decryption key may be made public by publishing it in plaintext form to the main blockchain. In some cases, the decryption key may be made accessible only to the group holding a given set of private keys. For example, in some systems, the event-locked message may be made decryptable by the owner of the set of private keys corresponding to the set of public keys S. In one example, each contribution to the decryption key is encrypted using each of the set of public keys S before being output by the TEE, and these cryptograms are sent to the blockchain. As a second example of how cryptograms may be made decryptable by the owner of the set of private keys corresponding to the set of public keys S, after a transaction containing an event-locked message is confirmed, a signing key S kA may be encrypted using each public key in the set of public keys S and distributed to the individual owners of the private keys corresponding to the set of public keys S (e.g., these cryptograms may be included in another transaction and mined into the blockchain). Additionally, a transaction containing an event-locked message may be encrypted using public key A (i.e., the public key corresponding to signing key S kA) to generate the decryption key D before being output by the TEE and sent to the blockchain. A Once this is done, the recipient of the encryption of the signing key SkA can create a decryption key.

[0200] The ghost chain is terminated (1608). That is, once a task (e.g., creating a decryption key) is completed, the ghost chain is terminated. Once the ghost chain is terminated, the decryption key may be recorded in the proof-of-work blockchain network. The ghost chain may be terminated using techniques described elsewhere, such as in connection with Figure 13.

[0201] Continuing with the previous example described in relation to FIG. 15, the decryption function for decrypting the ciphertext c=(u,v) corresponding to the encrypted message is described above. The private key is d A =sQ A QA is the above Q A = H1(A). Thus, the decryption function for decrypting the ciphertext c can be:

number

[0202] As described by Boneh and Franklin in "Identity-Based Encryption with Weil Pairings", the above leads to a particularly efficient threshold decryption scheme. Decrypting a ciphertext c = (u,v) is done by i Q A This can be achieved by broadcasting a threshold number of participants, each of whom has a share s i Next, from the basic properties of the mapping e, we have the following:

number

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

[0204] Below, the scope of the claims as originally filed is described as an example. [Example 1] 1. A computer-implemented method, the computer-implemented method comprising: encrypting a plaintext message to a cryptographic public key using at least a Congress public key in accordance with an identity-based encryption scheme to generate an encrypted message, the Congress public key being associated with a member of the Congress, each member of the Congress having access to a secret key share usable in a threshold decryption scheme in which at least a threshold number of secret key shares are sufficient to derive the decryption key by combination of partial contributions to the decryption key on behalf of the Congress; generating a digital signature for a first set of instructions for performing a cryptographic operation upon the occurrence of an event using at least a cryptographic private key corresponding to the cryptographic public key; broadcasting one or more transactions, the transactions including an encrypted message, a cryptographic public key, at least the first set of instructions, and a second set of instructions, to a proof-of-work blockchain network; the second set of instructions instructs members of the Congress to cooperatively deploy a ghost chain to execute a first set of instructions in response to reaching a consensus on the occurrence of the event conditional on the digital signature being authentic, the execution of the first set of instructions including at least deriving the decryption key from a plurality of secret key shares and an encryption key that satisfy the threshold, the decryption key being cryptographic material sufficient to obtain the plaintext message from the encrypted message; A computer-implemented method. [Example 2] 10. The computer-implemented method of claim 1, wherein the decryption key is derivable based at least in part on a scheme based on pairing over an elliptic curve. [Example 3] 3. The computer-implemented method of claim 1 or 2, wherein the identity-based encryption scheme follows a Boneh-Franklin identity-based encryption scheme. [Example 4] 4. The computer-implemented method of claim 1, wherein the one or more transactions include a transaction including a fee to a public group address associated with the congress, the fee being distributed to at least some of the ghost chain miners that cooperate in deriving the decryption key. [Example 5] 5. The computer-implemented method of claim 1, wherein miners of the ghost chain reach a consensus regarding the event based on information obtainable from the proof-of-work blockchain. [Example 6] 6. The computer-implemented method of claim 5, wherein the information obtainable from the proof-of-work blockchain is a timestamp of a transaction submission to the proof-of-work blockchain. [Example 7] 6. The computer-implemented method of claim 5, wherein the information obtainable from the proof-of-work blockchain is detection of a valid block of at least a particular height. [Example 8] 5. The computer-implemented method of claim 1, wherein the consensus is reached based at least in part on detecting that members of the congress issue at least a threshold number of certificates that the event has occurred, the occurrence of the event being determined at least in part based on information external to the proof-of-work blockchain, and further, the authenticity of the certificates is cryptographically verifiable using cryptographic public keys associated with each member of the congress. [Example 9] 10. The computer-implemented method of claim 8, wherein the certificate is issued for a predetermined period of time. [Example 10] 10. The computer-implemented method of claim 1, wherein the cryptographic operations include one or more decryption operations. [Example 11] 11. The computer-implemented method of claim 1, wherein the cryptographic operations include one or more authentication operations. [Example 12] 12. The computer-implemented method of claim 1, wherein a private key share is generated for each member of the congress, the private key share being used to perform cryptographic operations within a trusted execution environment in a node associated with the member. [Example 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. [Example 14] An electronic device, the electronic device comprising: An interface device; a processor coupled to the interface device; a memory coupled to the processor, The memory stores computer executable instructions that, when executed, configure a processor to perform a method according to any one of claims 1 to 12. electronic equipment. [Example 15] The electronic device of claim 14 , wherein the processor includes a trusted execution environment, and the computer-executable instructions are executed within the trusted execution environment.

Claims

1. 1. A method of confiscating digital assets, the method comprising: a first node that is a member of a congress including a plurality of nodes detecting malicious activity by a malicious node that is also a member of said congress; the first node providing a partial signature to a confiscation transaction to transfer at least a portion of the digital assets deposited by the malicious node when joining the congress to a non-spendable address, the digital assets being deposited by the malicious node; a threshold number of members of the congress determining that the malicious node's digital assets should be confiscated, the determination being made by reaching consensus on a sidechain; and confiscate at least a portion of the digital assets of the malicious node by generating a valid signature for the confiscation transaction and suspending further participation of the malicious node in the congress. method.

2. The step of a node joining the congress includes: obtaining a Congress public key; paying for the Congress public key; receiving a key share; and generating a secret key share.

3. 3. The method of claim 2, wherein the first node provides the partial signature using its private key share associated with a threshold signature scheme.

4. The method of claim 3 , wherein generating the valid signature comprises using the private key share of the first node in cooperation with other members of the congress.

5. The method of claim 1 , wherein malicious activity includes reporting false information to other members of the congress.

6. 6. The method of claim 1, wherein the congress secures a proof-of-stake sidechain that serves as a set-aside validation set and is used as a broadcast channel.

7. The method of claim 1 , wherein the consensus is achieved by determining that the malicious node has violated a predefined protocol or criteria.

8. 8. The method of claim 1, wherein the consensus corresponds to a confirmation of a sidechain transaction that includes criminal evidence of the malicious activity.

9. A computer readable storage medium containing computer executable instructions which, when executed, configure a processor to perform the method of any one of claims 1 to 8.

10. An electronic device, the electronic device comprising: An interface device; a processor coupled to the interface device; a memory coupled to the processor and storing computer executable instructions; The instructions, when executed, configure the processor to perform a method according to any one of claims 1 to 8. electronic equipment.

11. The electronic device of claim 10 , wherein the processor includes a trusted execution environment, and the computer-executable instructions are executed within the trusted execution environment.

Images