Methods and systems for blockchain-implemented event-lock encryption

Abstract

To provide methods and systems for updating distribution of secret key sharing in a blockchain.SOLUTION: A method includes: encrypting, using a cryptographic public key, a plaintext message to generate an encrypted message; generating, using a cryptographic secret key corresponding to the cryptographic public key, a digital signature over a first set of instructions to perform cryptographic operations upon an occurrence of an event; and broadcasting a transaction to a proof-of-work blockchain network, the transaction comprising the encrypted message, the cryptographic public key, the first set of instructions, and a second set of instructions. The second set of instructions, in response to reaching a consensus on the occurrence of the event and contingent upon the digital signature being authentic, instructs to cooperate with members of a congress to deploy a ghost chain to perform the first set of instructions. Performing the first set of instructions includes deriving the decryption key from the cryptographic key and a plurality of private key shares that satisfies a threshold.SELECTED DRAWING: Figure 15

Description

Technical Field

[0001] The present invention generally relates to distributed systems, and more specifically, to methods and systems for event locking operations in transactions on distributed systems. Event locking and event locking encryption can mean performing operations (calculations) on data in response to the occurrence of an event. For example, in an event locking encryption scheme, an encrypted message can be decrypted in response to the occurrence of an event. A particular type of event locking encryption is time-locking encryption, where a message is encrypted and the encrypted message is decrypted or decryptable after a certain period of time has elapsed. The present invention, without particular limitation, is suitable for efficiently and reliably generating messages, detecting the occurrence of events, and executing operations in response to verification of the occurrence of events using a distributed system. For example, a message can be encrypted under a time-locking encryption scheme where a corresponding decryption operation can occur as a result of the passage of (possibly random) time.

[0002] In this document, the term "blockchain" is used 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 use of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Although this document may refer to Bitcoin for convenience and illustrative purposes, it should be noted that the present invention is not limited to use in the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

Background Art

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

[0004] In order to write a transaction to the blockchain, it needs to be "verified". Some network nodes function as miners and perform the task of confirming that each transaction is valid, and invalid transactions are rejected from the network. For example, the software client installed on a node performs this verification task for transactions that reference unspent transaction outputs (UTXOs). Verification can be done by executing its lock and unlock scripts. When the execution of the lock and unlock scripts is evaluated as TRUE and other specific conditions are met, the transaction is valid and this transaction can be written to the blockchain. Thus, in order to write a transaction to the blockchain, the transaction needs to be: i) verified by the node that receives the transaction (once the transaction is verified, the node relays the verified transaction to other nodes within the network); ii) added to a new block constructed by miners; iii) mined (i.e., added to the public ledger of past transactions). A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain and the transaction cannot be substantially reversed.

[0005] Although blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to explore implementing new systems using both the Bitcoin-based cryptographic security system and the data that can be stored on the blockchain. It would be very beneficial if the blockchain could be used for automated tasks and processes that are not purely limited to cryptocurrency-based payments. Such a solution would allow these applications to be expanded further while leveraging the advantages of the blockchain (such as a permanent tamper-proof record of events, distributed processing, etc.).

[0006] As blockchain technology is extended to provide new features, it is important to maintain the security of the blockchain and the digital assets represented therein. The set of extended features that rely on the blockchain can be subject to attacks from malicious parties. Therefore, it may be useful to provide additional security to the blockchain or new features of the blockchain, or to provide methods and apparatuses for managing the ownership of digital assets to maintain the integrity of the blockchain.

[0007] Furthermore, when new improvements or modifications to the blockchain are developed, techniques for controlling and transferring digital assets from one blockchain to another while maintaining the integrity of both blockchains, one blockchain and another blockchain, are useful. Thus, it is desirable to provide improved methods and apparatuses for improving blockchain technology in one or more of these aspects. SUMMARY OF THE INVENTION

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

[0009] As will be described in more detail below, a congress can be formed on a blockchain network. The congress is an open membership group, and any node within the blockchain network can join this group by submitting sufficient funds to a pool associated with the congress. For example, a node can join the congress by transferring digital currency (such as Bitcoin), tokens, or other digital assets such as other funds or value to a resource (such as an account) associated with the congress. The congress can be partially protected by the distributed generation of secret key shares. An owner can use each secret key share to generate a partial signature of a transaction. A threshold signature scheme can be used to generate a valid signature of such a transaction using at least a threshold number of partial signatures. Member deposits are subject to forfeiture for malicious acts.

[0010] Advantageously, by using the distributed generation of key shares and other security features, the key shares are protected and malicious activities by group members or non-group members are prevented. Such security, combined with the use of a threshold signature scheme, enables the formation of an autonomous and decentralized group that can be used for any of several purposes, such as providing a two-way peg, for example. More specifically, the threshold signature scheme allows the group to control digital assets encumbered by a public key associated with the group.

[0011] Accordingly, the present invention can provide a computer-implemented method. The computer-implemented method is i) A step of encrypting a plaintext message into an encrypted public key using at least a congress public key according to an identity-based encryption method, wherein the congress public key is associated with a member of the congress, and each member of the congress has access to a secret key share that can be used in a threshold decryption method. In the threshold decryption method, at least a threshold number of secret key shares are sufficient to derive a decryption key by combining partial contributions to the decryption key on behalf of the congress. The generating step; ii) A step of generating a digital signature for a first instruction set for performing an encryption operation when an event occurs using at least an encrypted secret key corresponding to the encrypted public key; iii) A step of broadcasting one or more transactions including the encrypted message, the encrypted public key, at least the first instruction set, and a second instruction set to a proof-of-work blockchain network; and The second instruction set instructs to cooperate with members of the congress to deploy a ghost chain and execute the first instruction set in response to reaching a consensus on the occurrence of an event on the condition that the digital signature is genuine. Executing the first instruction set includes at least deriving a decryption key from a plurality of secret key shares and an encryption key that satisfy a threshold. The decryption key is encryption material sufficient to obtain a plaintext message from the encrypted message.

[0012] In some embodiments, the decryption key is derivable based at least in part on a scheme based on pairings on an elliptic curve.

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

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

[0015] In some embodiments, the ghost chain miners reach a consensus regarding an event based on information obtainable from the proof-of-work blockchain.

[0016] In some embodiments, the information obtainable from the proof-of-work blockchain is the timestamp of the transaction transmission 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 at least at a specific height.

[0018] In some embodiments, the members of the congress reach a consensus based at least in part on detecting that at least a threshold certificate that the event has occurred is issued, the occurrence of the event is determined based at least in part on information external to the proof-of-work blockchain, and further, the authenticity of the certificate is cryptographically verifiable using the cryptographic public key associated with each member of the congress.

[0019] In some embodiments, the certificate is issued over a predetermined period.

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

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

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

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

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

Brief Description of the Drawings

[0025] These and other aspects of the present invention will become apparent from the embodiments described herein and will be described with reference to these embodiments. Here, embodiments of the present invention will be described by way of example only with reference to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

DETAILED DESCRIPTION OF THE INVENTION

[0026] Blockchain network Referring initially to FIG. 1, this figure shows, in block diagram form, an exemplary blockchain network 100 related to a blockchain. The blockchain network can be a public blockchain network, which is a peer-to-peer open membership network where anyone can join without invitation or the consent of other members. Under the operation of the blockchain network 100, a distributed electronic device that executes an instance of the blockchain protocol can participate in the blockchain network 100. Such a distributed electronic device can be referred to as a node 102. The blockchain protocol can 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 can 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 smartwatches, or other electronic devices.

[0028] The nodes 102 of the blockchain network 100 are coupled to each other using appropriate communication technologies that can include wired and wireless communication technologies. Such communication complies with the protocols related to the blockchain. For example, if the blockchain is the Bitcoin blockchain, the Bitcoin protocol can be used.

[0029] Node 102 maintains a global ledger of all transactions on the blockchain. Thus, the global ledger is a distributed ledger. Each node 102 can store a complete copy or a partial copy of the global ledger. In the case of a blockchain guaranteed by proof of work, transactions by node 102 that affect the global ledger are verified by other node 102s so that the validity of the global ledger is maintained. When the blockchain is a proof-of-work-based blockchain, the block is also verified by checking the proof of work sent with the block.

[0030] At least some of the nodes 102 operate 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 calculations to facilitate transactions on the blockchain. For example, in a proof-of-work blockchain, a miner may need to solve a cryptographic problem. In Bitcoin, miner 104 hashes the block header with SHA-256 and finds a nonce such that the result is a number smaller than the value specified by the current difficulty. The hash power required for the proof-of-work algorithm means that a transaction is considered substantially irreversible after a certain number of blocks have been mined on top of it. The miner 104 that solves the cryptographic problem creates a new block for the blockchain and broadcasts this new block to other nodes 102. Other nodes 102 verify whether sufficient proof of work has been demonstrated before accepting that miner 104 has actually solved the cryptographic problem and thus should add the block to the blockchain. The block is added to the blockchain (i.e., the global distributed ledger) by consensus of the nodes 102.

[0031] The blocks created by minor 104 contain the transactions broadcast to the blockchain by node 102. For example, the block may contain a transaction from an address associated with one node 102 to an address associated with another node 102. Thus, the block functions as a record of the transaction from one address to another. The party requesting to include the transaction in the block proves that it has the authority to initiate the transfer (e.g., use Bitcoin in the case of Bitcoin) by signing the request using the private key corresponding to the public key. The transfer (transaction) can be added to the block only if the request is validly signed.

[0032] In the case of Bitcoin, there is a one-to-one correspondence between the public key and the address. That is, each public key is associated with a single address. Thus, references herein to the transfer of digital assets between public keys (e.g., payments to public keys) and to the transfer of digital assets between the addresses associated with those public keys refer to common operations.

[0033] Some of the nodes 102 may not operate as minors and may instead participate as verification nodes. Verification of the transaction may include verification of signatures, confirmation of references to valid UTXOs, etc.

[0034] The example of FIG. 1 includes six nodes 102, two of which are participating as minors 104. In practice, the number of nodes 102 or minors 104 may be different. In many blockchain networks, the number of nodes 102 and minors 104 may be much larger than the numbers shown in FIG. 1.

[0035] As described below, various nodes 102 can cooperate to form a group called a congress 110 herein. In the illustrated example, three nodes 102 are shown as participating in the congress 110. However, the actual members of the congress 110 can be far more numerous.

[0036] Congress 110 is an open membership group to which nodes 102 can join by submitting a sufficient stake to a pool associated with the congress 110. For example, a node can join the congress by transferring digital currency (such as Bitcoin), tokens, or other digital assets such as stakes and values to an account associated with the congress 110. Nodes 102 that join the congress can be nodes within the blockchain network, including both mining nodes and non - mining nodes. In at least some applications of the congress (such as when the congress is performing a two - way peg, as described below), nodes that function as congress members monitor the blockchain in the sense of downloading (but not necessarily retaining) the complete blockchain.

[0037] The methods of joining, leaving, and participating in the congress 110 will be discussed in more detail below.

[0038] An electronic device operating as a node FIG. 2 is a block diagram showing the components of an exemplary electronic device 200 that can function as a node 102 (FIG. 1) in a peer - to - peer blockchain network 100 (FIG. 1). The exemplary electronic device 200 can also be referred to as a processing device. The electronic device can take various 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 smartwatch, 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 can communicate with each other via a bus 240. The memory 220 stores a computer software program including machine-readable instructions and data for executing the functions described herein. For example, the memory may include processor-executable instructions that, when executed by the processor 210, cause the electronic device to execute 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 related to the blockchain network 100 (Figure 1). For example, the instructions may include instructions for implementing the Bitcoin protocol.

[0040] The memory 220 may store the global ledger of the blockchain network 100 (Figure 1) or a part thereof. That is, the memory 220 can store all the blocks of the blockchain, or a part of the blocks such as the latest block, or a part of the information in some blocks.

[0041] In Figure 2, the memory 220 is shown as a single block, but in reality, the electronic device 200 may include multiple memory components. The memory components may be of various types, including, for example, RAM, HDD, SSD, flash drives, etc. Different types of memory may be suitable for different purposes. Further, although the memory 220 is shown separately from the processor 210, the 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 such as execution in an isolated state, integration of trusted applications, and confidentiality of assets to the electronic device 200. The TEE 250 provides an execution space that guarantees that computer instructions and data loaded within the TEE 250 are protected from the perspective of confidentiality and integrity. The TEE 250 can be used to protect the integrity and confidentiality of important 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 external parties such as the owner of the electronic device. The data and calculations within the TEE 250 are protected from security by the parties operating the node 102 including the TEE 250.

[0043] The TEE 250 can operate to instantiate an enclave while hashing cumulatively and adding memory pages one by one at a time. Similar operations can also be performed on a remote machine (which can be a development machine or another machine), and the remote machine determines and stores the expected hash. Therefore, it is possible to verify the content of the enclave on the remote machine to ensure that the enclave is executing an approved algorithm. This verification can be performed by comparing the hashes. Once the enclave is fully constructed, the enclave can be locked down. It is possible to execute code in the TEE 250 and send secrets to this code, but the code cannot be changed. The final hash can be signed by an authentication key and made available to the data owner for verification before the data owner sends the secrets to the enclave.

[0044] The TEE250 can be used to protect the confidentiality and integrity of private key shares associated with the congressional public key used by Congress 110 (Figure 1). For example, the TEE250 can be used for the generation and storage of private key shares. The TEE250 aims to prevent members from directly obtaining the private key shares held within the TEE250 enclave or information regarding other private key shares from member-to-member or enclave-to-enclave communications. This protocol can also be robust against the compromise of the enclave's threshold. Additionally, the TEE250 enables remote authentication that can be used by node 102 (Figure 1), and the TEE250 can prove to other nodes 102 that it is genuine and executing approved computer-executable instructions for the protocol implemented by Congress 110. Remote authentication can be provided by the TEE250 by executing a specific portion of the code and transmitting a hash of the code within the enclave, signed with the enclave's internal authentication key.

[0045] The TEE250 can be used to prove the secure deletion of private key shares when a member of Congress 110 who previously used private key shares on the electronic device 200 chooses to leave Congress. The electronic device 200 can provide proof of deletion to other Congress members via the remote authentication protocol provided by the TEE250. Proof of deletion may be required before a member is permitted to withdraw their member deposit. That is, the return of the deposit may be conditional upon proof of the deletion of the private key shares held within the member's enclave.

[0046] The TEE250 can be equipped with a secure random number generator inside the enclave of the TEE, and this random number generator can be used to generate secret keys, random challenges, or other random data. The TEE250 can also be configured to read data from an external memory and to write data to the external memory. Such data can be encrypted with a secret key that is only held within the enclave.

[0047] The TEE250 can be implemented using various platforms such as the Trusted Platform Module (TPM) or 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 on which a particular enclave is running. A third-party attestation service such as the Intel Attestation Service (IAS) can prove that these signed statements are from a genuine CPU compliant with the SGX specification.

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

[0049] Congress and Threshold Signatures Congress 110 may be a permitted group or a non-permitted group. That is, any node 102 (Figure 1) within the blockchain network 100 (Figure 1) can join Congress 110 (i.e., any node that monitors and stores at least a portion of the information within the blockchain). To join Congress 110, the node 102 transfers one or more digital assets to a digital asset pool associated with Congress 110 (i.e., to a public group address associated with one or more digital assets and then associated with other members of the Congress). This digital asset pool may be referred to as the Congress pool. For example, the node 102 can join 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 management of a group threshold signature that includes a single public key called the Congress public key. Congress members hold distributively generated secret key shares. The number of shares held may be proportional to the amount deposited in the pool.

[0050] The digital assets managed by Congress 110 include the digital assets transferred to the Congress address and are placed under the management of a threshold signature scheme. In the threshold signature scheme, a group of members whose total holding of secret key shares exceeds the threshold is required to generate a valid signature that enables the transfer of the digital assets out of the management of Congress 110. That is, it is necessary to use at least the threshold number of secret key shares to generate a valid signature for an outgoing transfer of the digital assets managed by Congress 110.

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

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

[0053] Congress 106 can function as a self-governing group where cooperative behavior is enforced by threatening to confiscate all or part of the members' deposits. By having many honest members participate in a cooperative protocol, such digital assets of non-cooperative or malicious members can be confiscated. That is, to ensure that all nodes 102 operate in accordance with a predetermined protocol or standard, the members' deposits in the Congress pool can be subject to confiscation. Confiscation means permanently preventing the return of the member deposits deemed to be confiscated. The digital assets that form the member deposits not returned due to malicious activities can be left in the Congress pool but may not be returned (for example, if a consensus is reached that they should not be returned on an alt-chain), and are immediately or in the future transferred to another unspendable address, or confiscated, and the nature of the confiscation may depend on whether Congress functions as a bonded validator set for the side chain.

[0054] Furthermore, if a Congress member wishes to withdraw from Congress 110, the member can withdraw their member deposit (i.e., request that Congress 110 return the member deposit to the member's personal address). However, the withdrawal of funds is only executed if a threshold number of secret key shares required to generate a valid digital signature are used by members of the group (i.e., Congress) that approves the withdrawal.

[0055] The threshold signature scheme implemented by Congress 110 can be of various types. The threshold signature scheme enables sharing of signature capabilities among n parties as long as at least the threshold number of secret key shares contribute to the generation of a valid signature. It is not possible to generate a valid signature using a subset less than the threshold. More specifically, each party manages a share of the secret signature key, and to combine partial signatures to generate a valid signature, the threshold number of key shares must be used. 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 can be of the type proposed by Ibrahim et al. in “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”, 2003 EIII 46 th Midwest Symposium on Circuits and Systems, 1: 276 - 280 (2003). This threshold signature scheme is an extension of a digital signature scheme that is an elliptic curve cryptography - based algorithm, in which t + 1 key shares from parties consisting of n key - share owners are required to reconstruct the secret key. Using this scheme, it is possible to create a valid signature without the need to reconstruct the secret key and without a party having to reveal its key share to other parties.

[0057] Since t + 1 key shares can be sufficient to reconstruct the secret, the maximum number of allowed adversaries by this method is t. An adversary in the model of Ibrahim et al. is an entity that bribes a party holding a secret share and accesses that secret share. There can be various types of adversaries. For example, a Byzantine adversary is an adversary that pretends to participate in the protocol but actually sends incorrect information. The ECDSA method proposed by Ibrahim is robust against malicious adversaries with a maximum of t <= n / 4. This robustness can be increased up to t <= n / 3, but the cost of complexity increases.

[0058] The ECDSA method of Ibrahim et al. is robust in halting adversaries with t <= n / 3. By halting the adversary, it is possible to prevent a bribed party from participating in the protocol or halt mid - participation.

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

[0060] The transmission of incorrect shares (i.e., shares different from the blindly shared shares broadcast) to individual nodes can be identified by the receiving nodes of the shares. The identification of incorrect shares secretly sent to a node can be made public and verifiable using publicly verifiable secret sharing (PVSS) techniques. Such techniques can avoid the possibility of delay in identifying malicious senders that can occur when PVSS is not used and the recipient of the incorrect share is offline or disconnected from a substantial part of the network when the incorrect share is sent.

[0061] Malicious acts, such as providing inconsistent shares to different nodes, can be addressed by a Congress 110 that prevents malicious acts. For example, if a certain node 102 (Figure 1) is identified as a malicious party by other nodes 102, a number of nodes 102 (i.e., nodes associated with Congress members) exceeding a threshold (e.g., t + 1) can cooperate to punish the malicious party. For example, node 102 can take actions related to digital assets (digital currency, tokens, or other contributed funds, values, etc.) deposited with the Congress by a malicious party. For example, the Congress can burn by transferring digital currency, tokens, contributed funds, or values to an unspendable address, or the Congress can confiscate such digital assets by refusing to return them by consensus with other nodes. Nodes 102 that are not the nodes performing malicious acts can also prevent malicious acts by cooperating to exclude the nodes performing malicious acts (e.g., by substantially invalidating key shares, by excluding nodes from participating in the Congress protocol, or by resharing the secret key and not allocating shares to the nodes performing malicious acts).

[0062] The above - mentioned ECDSA technology can be enhanced using a TEE. For example, the threshold ECDSA signature technology based on Ibrahim et al. assumes here a powerful adversary, called the Byzantine adversary. This type of adversary can not only refuse to participate in the signature process and refuse to break in and stop it among the relevant parties, but can also act arbitrarily, such as pretending to participate honestly and sending illegal information. However, by using a TEE and generating the data used for signature within the enclave of the TEE where the secret key share is stored, additional security can be provided because the probability that a significant number of enclaves are exposed to danger is very low. For example, assuming that n is large enough when only one key share is assigned to each TEE, it can be reasonably expected that the number of TEEs that may be exposed to danger does not reach the threshold of robustness against the Byzantine adversary. Thus, when there is resistance to only a small percentage of malicious adversaries with respect to the total number of key shares, the protocol can be made secure.

[0063] For example, when there is a TEE in all nodes, the acquisition of the secret stored in the enclave can only be achieved when the manufacturer of the TEE is not acquired and with a great deal of effort and cost for physical access to the nodes. Such a manufacturer - level acquisition is expected to be manageable. For example, if the manufacturer dishonestly claims that a plurality of public keys correspond to a genuine TEE, the manufacturer may directly access the secret key share and initiate an attack. However, for such an attack, a significant number of key shares are required to enable the manufacturer to create a valid signature without the support of other nodes. This means accumulating most of the total investment, which is quite costly. Furthermore, by launching an attack, most of the invested funds held will be destroyed.

[0064] When using a TEE, it is useful to consider the robustness of the protocol against "corrupted nodes". A corrupted node is a node where external hardware outside the TEE is involved in corruption, but the integrity of the TEE is not compromised. A corrupted node can control the information that the enclave receives and does not receive. In particular, a corrupted node may hesitate to participate in the protocol, i.e., it may hold back. When the information provided to the protocol needs to be signed by a secret key secretly held in the enclave (when the corresponding public key is authenticated as genuine during authentication), the secret key is as trustworthy as the enclave itself. Thus, a corrupted node cannot send arbitrary (authenticated) information to the protocol and may only attempt interference by pausing or deceiving the enclave into operating incorrectly, e.g., by providing old information to the enclave. Therefore, in the case of a corrupted node, to succeed in an attack, it is necessary to collect a sufficient number of partial signatures to generate a complete signature. In a TEE, the protocol by Ibrahim et al. is robust against 2t corrupted nodes. Since a signature can be generated when n - 2t >= 2t + 1, a qualified subset of key shares of size 2t + 1 <= (n + 1) / 2 suffices. Therefore, when using a TEE, when there are corrupted nodes, the threshold of the threshold signature scheme can be set to be more than 50% of the number of key shares to generate a valid signature.

[0065] Other threshold signature schemes can also be used. For example, the threshold signature scheme may be of the type of ECDSA threshold scheme proposed by Goldfeder et al., "Securing Bitcoin Wallets via a New DSA / EDCSA threshold signature scheme", (2015). With this protocol, t + 1 parties can generate a valid signature. As a result, the number of key shares that an adversary must control (manage) to generate a valid signature is equal to the number of key shares that the adversary must own to reconstruct the secret key. This approach can provide an efficient way when unanimity is required to generate a valid signature. In the most common case, this method requires repeating the entire protocol for each possible subset of t + 1 players out of n for any threshold value, thus imposing a space requirement that scales exponentially with the number of congress members. Thus, when both the values of n and t are large, a large number of key shares need to be stored. To mitigate such storage requirements, standard Bitcoin multisignature can be combined with threshold signatures. In particular, when multiple signatures are used to lock a digital asset, each secret key is split into shares. This approach makes larger congresses more efficient from the perspective of space requirements. The scaling characteristics can also be improved by iteratively constructing schemes for a large number of participants at multiple levels from a small number of participant sizes. For example, the threshold signature scheme may be combined with the approach of Cohen et al., Efficient Multiparty Protocols via Log-Depth Threshold Formulae (2013), Advances in Cryptology-CRYPTO2013 pp 185-202.

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

[0067] A node 102 (FIG. 1) within the blockchain network 100 (FIG. 1) can implement a congress protocol based on a selected threshold signature scheme. Such a node 102 may include computer-executable instructions stored in a memory 220 (FIG. 2) that implement the congress protocol. When executed by a processor 210 (FIG. 2), such instructions cause the node 102 (such as the electronic device 200 of the type described with reference to FIG. 2) to execute 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 FIG. 10. Thus, the congress protocol may include one or more of methods 300, 400, 500, 600, 700, 800, 1000 of FIGS. 3-8 and FIG. 10. The methods may be executed in cooperation with other nodes related to other congress members.

[0068] Initiation of Congress Referring now to FIG. 3, a method 300 for initiating a congress 110 is shown. Method 300 may be initially executed by a trusted party to set up the congress 110. That is, a node 102 associated with the initially trusted party may execute method 300.

[0069] Method 300 includes, in operation 302, providing a congress public key. The congress public key is provided to other nodes 102 and may enable these other nodes to make a payment to the congress public key if they wish to join the congress. That is, 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 that executes method 300 permits payment to the public key in operation 304 until one or more conditions are met. For example, the node may permit payment to the public key for a determined period or number of determined blocks. After the conditions are met (e.g., after the expiration of this period or after the mining of a plurality of blocks), the node 102 that executes method 300 identifies the initial members of the congress in operation 306.

[0071] After the parties constituting the initial members of the congress are identified, in operation 307, the secret key is split into secret key shares according to a threshold signature scheme. Next, in operation 308, the secret key shares are distributed to the parties identified from the node 102 that executes method 300. The secret key shares are associated with a threshold signature scheme that can be of the type described herein.

[0072] During operation 308, the nodes 102 identified as congress members cooperate to generate a new secret key share and a new public key. The original key share sent to such nodes by the initially trusted parties is used to sign and can be used to broadcast a transaction that sends all digital assets within 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, digital assets under the management of the congress 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 in a trustless (not relying on a centralized sovereign system) manner. The new public group address is formed so that other nodes wishing to join the congress 110, or for other purposes as described above, can receive future deposits of digital assets. Here, congress members are considered to be registered with the congress, and these nodes can operate without the assistance of the initially trusted parties. Furthermore, the initially trusted parties are no longer involved in any part of the congress operation.

[0073] Joining the Congress after the Congress has been initiated Referring now to FIG. 4, this figure shows a method 400 for joining a congress. The method 400 of FIG. 4 may operate in relation to the method 300 of FIG. 3, but the method 400 of FIG. 4 is executed by a different one of the nodes 102 operating in the same blockchain network 100 (FIG. 1) that is operated by the node executing the method 300 of FIG. 3. The method 400 of FIG. 4 includes, in operation 402, obtaining a congress public key. The congress public key can be obtained directly from a person starting the congress, such as the node executing the method 300 of FIG. 3, or can 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 can be obtained from a public web server accessible via the public Internet.

[0074] The node 102 executing the method 400 makes a payment to the congress public key in operation 404 by broadcasting a transaction of digital assets from the private account associated with the node 102 to the congress address (i.e., the address associated with the congress public key). More specifically, the node 102 broadcasts a transaction that transfers one or more digital assets to a public group address associated with the congress public key. The public group address is an address for the congress pool. The congress pool contains other digital assets associated with other members of the congress. Thus, when the transaction in operation 404 is added to a block by the miner 104 (FIG. 1), it transfers the digital assets to the congress pool that includes digital assets from other members. The public group address may receive transfers from both parties who wish to join the congress and those who do not wish to join the congress. A party who does not wish to join the congress transfers digital assets to the congress pool, and such digital assets can be placed under the overall, partial, or conditional control of the congress using a threshold signature scheme adopted by the congress.

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

[0076] After depositing the digital asset into the Congress pool, in operation 406, node 102 executing method 400 receives a secret key share. Next, in operation 408, node 102 regenerates the secret key share by executing a single instance of the protocol. Generation of the secret key share may be performed within the TEE of node 102.

[0077] In operation 408, node 102 generates a secret key share used in a threshold signature scheme, and in the threshold signature scheme, at least a threshold number of secret key shares must be used to generate a valid signature for the transaction on behalf of Congress. The other owners of the secret key shares are other members of Congress who have joined Congress in a permission - based or permissionless manner by transferring their respective digital assets to a public group address.

[0078] To regenerate the secret key share, in operation 408, existing Congress members can cooperate to update the key share. For example, node 102 can generate a random polynomial of degree t, where the constant term is zero

Number

Number

Number

[0079] The secret key share may be generated within the TEE 250 (Figure 2) and can be securely stored in node 102. For example, the secret key share may be stored in the TEE 250.

[0080] After the secret key shares are generated by each node, funds under the management of the previous congress public key (e.g., funds transferred to the public group address associated with the original congress public key) can be transferred to the new congress public key associated with the new secret key share (by the cooperation of a sufficient number of group nodes to generate a valid signature under the threshold signature scheme).

[0081] In operation 408, after the secret key share is generated, the secret key share can be used in operation 410 of method 400. Using the secret key share, a valid signature for a transaction can be cooperatively generated from a public group address (which can be broadcast by a member). That is, the secret key share can be used in a threshold signature scheme to contribute to signature generation. In a threshold signature scheme, each member of the congress needs to use a threshold number of secret key shares to generate a valid signature that allows the digital asset to be transferred (away from) the congress to another location. Node 102 that executes method 400 can retrieve the secret key share from storage and use this secret key share to contribute to signature generation. When a sufficient number of other congress members also contribute to signature generation using their respective secret keys, a signature is generated and a valid spending transaction can be broadcast. When the miner 104 (Figure 1) of the blockchain network 100 adds the transaction to the mined block (which is added to the blockchain by consensus of the nodes 102 within the blockchain network 100) and the block is confirmed, the spending transaction is completed. At this point, the digital asset represented in the transaction may no longer be under the control of the congress. That is, such a digital asset may no longer be restricted by the congress public key.

[0082] The use of the secret key share in operation 408 can be executed within the TEE of node 102. The TEE protects the secret key share so that other parts of the system and the members themselves cannot access any data such as the secret key share stored in the enclave. Further, the TEE protects the secret key in that the TEE cannot hold a copy of the secret key because when a member wishes to receive the deposit back and receives the deposit, the member needs to prove the deletion of the secret key before returning the member deposit.

[0083] The method 400 of FIG. 4 can be executed during or after the initial setup phase. That is, the method 400 can be executed before the initial key shares are distributed (e.g., during operation 308 of the method 300 of FIG. 3) or after (e.g., during rebalancing, which will be discussed in more detail below).

[0084] The transaction in operation 410 can transfer digital assets back to the parties that originally deposited those digital assets into the congress pool. That is, the transfer (transfer) may return the digital assets to the depositor. The transfer may also transfer the digital assets elsewhere. For example, the digital assets may be transferred to a third party or an inaccessible address.

[0085] Confiscation of Digital Assets Referring now to FIG. 5, an exemplary method 500 for confiscating digital assets is shown. The method 500 of FIG. 5 may be executed by node 102, which may be the same node that executes the method 400 of FIG. 4. The method 500 may be executed after operation 408 of the method 400 of FIG. 4. Thus, node 102 already has access to the secret key shares when the method 500 of FIG. 5 is executed.

[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 has violated a predefined protocol or criterion. For example, when a node that is a member of the congress reports false information (i.e., false, inconsistent, or unacceptable information) to other members of the congress, that member may be considered a malicious member.

[0087] In operation 503, in response to the detection of malicious activities, node 102 can cooperate with other nodes within the congress to suspend members who are malicious parties. That is, the congress can exclude malicious parties from further participation in the congress.

[0088] To ensure that all nodes 102 operate in accordance with pre - defined protocols or criteria, the member deposits to the congress pool can be subject to forfeiture. Forfeiture means permanently preventing the return of the member deposits considered to be forfeited. Digital assets that form the member deposits and are not returned due to malicious activities can be left in the congress pool, but (depending on the consensus that this measure should be taken) may not be returned, and may be immediately or in the future transferred to another unspendable address or forfeited. The nature of the forfeiture may depend on whether the congress functions as a side - chain checkpoint verification set. For example, in operation 504, in response to detecting malicious activities by a malicious party, the node 102 executing method 500 can use a secret - key share to provide a partial signature for a forfeiture transaction (a transaction that transfers digital assets to an unspendable address or to another node as a reward for exposing malicious activities). That is, the node cooperates with other nodes in the congress to forfeit at least a portion of the digital assets previously transferred to the public group address (i.e., the congress pool) by the malicious party. That is, in response to confirming that a group member has violated pre - defined protocols or criteria, the secret - key share is used 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] Since the threshold signature scheme is used with the congress public key, individual nodes acting alone cannot transfer the deposits of another congress member's digital assets to a location separate from the congress pool (e.g., to an unspendable address). Rather, the digital assets can only be forfeited by transfer if each member uses a threshold number of secret key shares to generate a valid signature for transferring the digital assets to another address, or if at least a group of members that amounts to a threshold number of secret key shares reaches a consensus to put a member on hold (in operation 503), and withdrawal requests from the put-on-hold member are automatically ignored. If the digital assets are forfeited by transfer, the other address to which the digital assets can be transferred can be associated with an unspendable address. For example, this other address may be an address without a secret key, and access to the digital assets associated with the public key of this address can be made inaccessible to anyone. When a transaction transferring the digital assets to an unspendable address is confirmed, or when a consensus that the digital assets should be forfeited is obtained on the side chain, the digital assets can be considered burned because they are no longer on hold by any congress member or actually by any node within the blockchain network 100.

[0090] Accordingly, in operation 504, the node can forfeit the digital assets by cooperating with other members of the congress to use the secret key shares to generate a valid signature for the transaction to an unspendable address, and in some embodiments, reaching a consensus in a second blockchain that all or part of a member's deposit should be permanently taken up can be involved.

[0091] Furthermore, in some embodiments, the Congress functions as a stake verification set that protects the proof-of-stake side chain, which can be used as a broadcast channel. For example, the Congress members of the side chain may reach a consensus that a certain member has acted maliciously. This consensus may correspond to the confirmation of side chain transactions that include criminal evidence of malicious activities. Once the consensus is reached, withdrawal requests for the member deposits made by the malicious member are rejected, and the deposits are considered confiscated. The confiscated digital assets can be burned at a future time. That is, after a while, a threshold number of members (excluding the malicious member) can cooperate to approve the transfer of the confiscated digital assets to an unspendable address.

[0092] Since the Congress is an open group that the nodes 102 of the blockchain network 100 can join by depositing digital assets, the group members can be changed periodically. When such a change occurs, the distribution of the secret key shares can be updated. Referring now to FIG. 6, an exemplary method 600 for updating the secret key share distribution is shown. The method 600 can be executed by the nodes 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0093] Update of Secret Key Share Distribution Using a New Public Address In operation 602 of method 600, the node 102 detects a redistribution request, which is a request and whose fulfillment involves the redistribution of the key shares. For example, the node 102 can detect that a new prospective member has transferred digital assets to the public group address or that an existing member has requested a withdrawal of the member deposit.

[0094] Digital assets can be transferred to a public group address by nodes that require joining or increasing participation in the Congress, and other nodes that do not require joining the Congress but instead transfer digital assets to the Congress for another purpose (such as transferring digital assets to a side chain as described below). In operation 602, node 102 can use one or more attributes included in at least a part of the transaction to the public group address of the digital asset to identify Congress members (i.e., those who transfer digital assets to the Congress public key to join the Congress and are not related parties for other purposes). For example, a specific transaction may be flagged as a special transaction using the attributes of the transaction. Such attributes (or the presence or absence thereof) may indicate the purpose of the transfer. For example, a transaction may include a flag when the transferor does not require joining the Congress.

[0095] In response to the detection of a request in operation 602, its fulfillment involves the re - distribution of key shares. In operation 604, new secret key shares are generated by node 102 in the same way as the method generated in operation 408 of method 400 in FIG. 4. Other member nodes of the Congress also generate their respective secret key shares. These secret key shares can be used in the threshold signature scheme of the new Congress public key. At this point, members who withdraw from the Congress do not generate new secret key shares during operation 604, and since no secret key shares for use with the new Congress public key are assigned to the withdrawing members, the withdrawing members lose the ability to participate in the Congress and are no longer considered Congress members.

[0096] Further, in response to detecting a redistribution request (which is a request whose fulfillment involves redistribution of key shares), at operation 606, node 102 cooperates with other congress members to transfer all digital assets within the public group address to a new public address associated with a new public key (which becomes the new congress public key).

[0097] Thus, according to method 600 of FIG. 6, when the deposit distribution is changed or when a request to withdraw a deposit from a member is received, the secret key shares are regenerated and all digital assets under the management of the congress can be moved to the new public key. The frequency with which the congress members can be updated can be limited by the block time of the blockchain network 100. In many applications, only an infrequent re - balance may be required as compared to the average block generation time of the proof - of - work main chain.

[0098] Updating secret key share distribution while retaining the existing public group address Referring now to FIG. 7, a further exemplary method 700 for updating the distribution of secret key shares is shown. Method 700 can be executed by node 102 of blockchain network 100 in cooperation with other nodes of blockchain network 100.

[0099] In method 700 of FIG. 7, the congress public key does not change each time the distribution of member deposits is changed. When a request to assign a new key share (which may occur by depositing digital assets to the public group address) is detected (operation 702), node 102 cooperates with other members of the congress to issue (in operation 704) a new secret key share for the same public key to the new members of the group. The number of nodes that cooperate is at least the threshold number of nodes required to generate a digital signature in a threshold signature scheme. In operation 704, while additional key shares are assigned, other key shares may 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 assigned while other key shares are being updated. Such an update needs to be accompanied by proof of deletion of any previously generated key shares. In this case, new shares can be assigned 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 can use one or more attributes included in at least a part of a transaction to the public group address of the digital asset to identify a congress member (i.e., a person who transfers digital assets to the congress public key to join the congress and is not a person for another purpose). For example, a particular transaction may be flagged as a special transaction using the attributes of the transaction. Such an attribute (or the presence or absence of the attribute) may indicate the purpose of 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 quits the congress using method 700, the member can securely delete their secret key share. To ensure that the old member's secret key share cannot be used, members of the congress may be required to use node 102 with a special TEE. A TEE is an architecture implemented at the hardware level that guarantees that the instructions and data executed within the TEE are protected from access and manipulation by the rest of the system. The TEE can use hardware mechanisms to address the issue of remote authentication 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 can use an authenticated TEE configured to generate one or more random secret values that remain inaccessible to the host system without damaging the hardware at the integrated circuit level. The secret values generated in this way are used in the distribution generation of the secret key share (e.g., in operation 410 of method 400 in FIG. 4). This secret value can also be used to establish a shared public key that is shared during the congress setup phase. Since the calculations associated with the setup protocol are executed within the enclave of the TEE, a member or a former member cannot obtain information about their own or other secret key shares through member - to - member communication or other means. The enclave within the TEE enables the execution of a remote attestation protocol that can be used to prove to other nodes that the TEE enclave is genuine and executing approved computer - readable instructions.

[0103] Calculations related to group changes are executed within the enclave of the TEE. For example, the generation of a new secure random secret that can be used when calculating a new polynomial for SSS purposes is executed within the enclave of the TEE.

[0104] The enclaves of the TEE also aim to ensure that any previously unused key shares and previous secrets are securely deleted before returning the member deposits. More specifically, for returning the member deposits, the authentication protocol may require the enclaves of the TEE to prove the deletion of the key shares. Each node 102 can interpret such a proof as confirmation that the need for deletion has occurred at other nodes via the remote attestation protocol. Thus, method 700 may also include the step of verifying that the secret key shares previously held within the TEE of a member who has left the congress have been deleted from the nodes associated with that member. This verification can be done by receiving a proof of the deletion of the secret key shares. Therefore, the remote attestation protocol can be used to obtain a proof for the deletion of the secret key shares previously held within the TEE of a member who has left the congress.

[0105] The method 600 of FIG. 6 and the method 700 of FIG. 7 each have various advantages. For example, the method 600 of FIG. 6 does not rely on secure deletion and does not need to rely on trusted hardware. However, in some situations, the method 600 of FIG. 6 may benefit from such hardware because it may make malicious pooling of key shares less likely by such hardware.

[0106] The method 700 of FIG. 8 avoids the need to re-lock digital assets under a new congress public key each time the membership changes. Further, in some situations, the method 700 may update the membership faster than the method 600 of FIG. 6. This is because under the method 700 of FIG. 7, the digital assets are not moved to a new public key, so there is no need to add a transaction to the blockchain to move all the digital assets to the new public key. That is, since the public key does not change, the method 700 of FIG. 7 can be used to update the membership without waiting for several blocks to be generated to confirm the transfer of the digital assets to the new public key.

[0107] Unregistration from Congress As described above, group members may sometimes request to withdraw from Congress, and when unregistering a group member from Congress, the digital assets deposited in the Congress pool may be returned to that group member. Referring to FIG. 8 here, an exemplary method 800 for returning the deposit is shown in flowchart form. This method can be executed by 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 an unregistration request. The withdrawal request is a request to withdraw digital assets previously deposited by the requester and 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, node 102 evaluates the request against the determined criteria. Such criteria may be pre-determined criteria. When the Congress operates according to a Congress protocol in which the Congress public key is not changed each time the group membership is changed, in operation 804, node 102 can confirm that the secret key share has been deleted by the requester. Such confirmation can be obtained using a remote attestation protocol related to the TEE.

[0110] When the Congress protocol is one in which the Congress public key is changed when the membership is changed, since the secret key share is no longer valid, node 102 may not confirm the deletion of the secret key share. Instead, a new Congress key may be used and other digital assets under the management of the Congress may be transferred to the new Congress key.

[0111] When node 102 approves a withdrawal request based on an evaluation, in operation 806, the node facilitates the withdrawal of the digital asset. That is, node 102 cooperatively generates a digital signature using its secret key share and uses this digital signature to return to the requester the digital asset previously deposited by the requester. For example, the digital asset can be sent back to the address that previously received the digital asset. Operation 806 is performed according to a threshold signature scheme, whereby the withdrawal is made only if at least a threshold number of congress members have approved the withdrawal. Operation 806 is performed after a member who wishes to deregister has ceased activity for a certain period. This waiting period prevents members from engaging in improper behavior while the protocol for returning member deposits is being executed.

[0112] The congress protocol can be used for a number of different purposes. The congress provides a secure mechanism for performing various functions. The congress operates in a trustless manner (not relying on a centralized system) and can manage the ownership of digital assets.

[0113] The congress protocol can be used, for example, to implement a ghost chain, in which case the congress protocol can be called the ghost chain protocol.

[0114] Ghost chain Referring to FIG. 9 here, FIG. 900 shows a blockchain 902 and a ghost chain 904. The blockchain 902 is a distributed ledger of block-based proof-of-work. The ghost chain 904 is a distributed ledger of block-based distributed proof-of-stake that can be used for any purpose, such as creating a decryption key according to one or more conditions specified by a flagged transaction, or arbitrating disputes between nodes in a blockchain network. For example, a blockchain may include an objection where a node objects to the work product sent from another node. Such an objection is shown as "C" in FIG. 9. An objection may occur, for example, when a node (i.e., the objector) indicates that the result proposed in the fulfillment of a request is invalid.

[0115] When an objection is raised by a node, the ghost chain is deployed. After objection C occurs in response to the objection, the ghost chain is instantiated. The ghost chain can be instantiated with a genesis block that is the final block (also called the terminal block) of a previous instantiation of the ghost chain. Miners can add several blocks to the ghost chain until a judgment J is reached to resolve the digital dispute.

[0116] When the judgment is reached, a transaction (hereinafter referred to as the final transaction or settlement transaction) can be constructed and signed (as will be described in more detail below). This transaction can be a transaction that has the effect of distributing funds to the main blockchain 902 according to the judgment, distributing funds to reward the miners of the ghost chain, etc. The transaction can also return the result of the judgment to the main blockchain 902. More specifically, the result can be encapsulated in the transaction.

[0117] After reaching a decision and constructing and signing the final transaction, the ghost chain 904 ends, and the constructed transaction is mined into the main block chain 902. Because the ghost chain 904 ends, it is different from a typical block chain in that there is a terminal block in the ghost chain. This terminal block, which is the last block of the ghost chain 904, occurs when the decision is made, and the resulting transactions, such as distributing funds to the main block chain 902 according to this decision and distributing funds to reward the miners of the ghost chain, are validly signed.

[0118] Claimant-Proposer-Objector and Ghost Chain Accordingly, the node 102 of the blockchain network (FIG. 1) can implement the claimant-proposer-objector protocol and / or the ghost chain resolution protocol. Such a node may be stored in the memory 220 (FIG. 2) and include computer-executable instructions for implementing such a protocol. When executed by the processor 210 (FIG. 2), such instructions cause the node 102 (such as the electronic device 200 of the type described with reference to FIG. 2) to execute one or more methods of the protocol. Such methods may include any one or combination of the methods 1000, 1100, 1200, 1300 of FIGS. 10-13.

[0119] Referring now to FIGS. 10-13, these figures illustrate methods that may be included in the claimant-proposer-objector protocol and / or the ghost chain resolution protocol. The method regarding the claimant shown in FIG. 10 (requester method) may be executed by the claimant regarding the task of computing exchange. That is, the node 102 that requests the completion of the task may execute the method regarding the claimant of FIG. 10. The node is a node within the blockchain network (FIG. 1), and the node may be called a claimant.

[0120] The proposer method 1100 is shown in FIG. 11. The proposer method 1100 can be executed by a proposer regarding a solution to a task. That is, the node 102 claiming to have completed the task can execute the method of FIG. 11. The node is a node in the blockchain network (FIG. 1), and the node can be called a proposer.

[0121] The challenger method 1200 is shown in FIG. 12. The challenger method 1200 can be executed by a challenger regarding a solution to a task. That is, the node 102 objecting to the solution presented by the proposer can execute the method of FIG. 12. The node is a node in the blockchain network (FIG. 1), and the node can be called a challenger.

[0122] The arbitrator method 1300 is shown in FIG. 13. The arbitrator method 1300 can be executed by a node in the blockchain network in cooperation with other nodes in the blockchain network. A node that executes the arbitrator method in cooperation with other nodes can be called an arbitrator. method) 1300 is shown in FIG. 13. The arbitrator method 1300 can be executed by a node in the blockchain network in cooperation with other nodes in the blockchain network. A node that executes the arbitrator method in cooperation with other nodes can be called an arbitrator.

[0123] The methods 1000, 1100, 1200, and 1300 in FIGS. 10 to 13 are executed in cooperation. For example, the methods collectively provide a requester-proposer-challenger protocol in which the ghost chain is used to guarantee the validity of the proposer's solution.

[0124] In operation 1002 of method 1000 (FIG. 10) regarding a requester, a node called the requester makes a request. The request is a request to complete a task. For example, the task can be a request for a work product or a request to determine whether an off-chain event, which will be described in more detail below, has occurred. In exchange for the successful completion of the task, the request offers a bounty in the form of a digital asset related to the blockchain network. The request can be issued from outside the blockchain (i.e., "off-chain"). For example, the request can be issued by a web server accessible via the Internet. If no objection is raised to the candidate solution to the request for a certain period (which can be called the "objection period"), or if the objection is resolved by members of the congress voting on whether the candidate solution is correct, the request can be defined as having been successfully completed. In some embodiments, the ghost chain is deployed according to the result of the vote.

[0125] In some embodiments, as described below, through computational exchange, a node may be able to offload a computational task. (In operation 1002) The request can be raised through computational exchange. The computational exchange can be a collection of requested tasks. For example, multiple tasks can be published through computational exchange. The tasks can be published by the same requester or another requester. Through computational exchange, a node can offload the performance of a computation or an algorithm to other nodes.

[0126] In operation 1102 of method 1100 (FIG. 11) regarding a proposer, a node called the proposer identifies a request. Next, the node proceeds to complete the task off-chain (in operation 1104). For example, the algorithm, data, or other results requested by the requester may be obtained as a work product by a processor.

[0127] Next, the proposer can submit a proposal in operation 1106 of method 1100 (Figure 11). The proposal is a claim that the tasks related to the requirements issued by the requester in operation 1002 of method 1000 in Figure 10 have been completed. To submit the proposal, the proposer can send the public key of the blockchain network 100 to the requester. The proposer can also commit to a solution for the task. This commitment can be in the form of a hash of the solution (i.e., the hash of the work product such as the output of the calculation or another type of solution).

[0128] The requester receives the proposal in operation 1004 of method 1000 in Figure 10. For example, the requester can receive the public key of the proposer and the "commitment" (e.g., the hash of the target work product).

[0129] In response to receiving the proposal, in operation 1006 of method 1000 in Figure 10, the requester can construct transaction T1. Transaction T1 includes a reward as an input. The transaction includes a reward and the proposer's deposit as outputs (i.e., the output of T1, T1_out = reward + proposer's deposit). Sign the transaction T1 so that the proposer can add it to their input. For example, transaction T1 can be signed with SIGHASH_ALL|SIGHASH_ANYONECANPAY. SIGHASH_ALL is the default signature hash type that signs the entire transaction except the signature script and prevents changes to the signed part. SIGHASH_ANYONECANPAY is a signature hash type that signs only the current input.

[0130] Transaction T1 is constructed to be unlocked in two ways. After the expiration of the objection period (described later), the transaction T1 can be unlocked with the signature of the proposer (i.e., the signature corresponding to the public key provided by the proposer to the claimant) and the solution corresponding to the commit. For example, the instruction code OP_CHECKSEQUENCEVERIFY can be used to lock the transaction over the objection period, but if there is no objection during this period, it can be unlocked by the proposer. The transaction is also constructed to be unlocked at any time with the group signature of Congress 110 (Figure 1). That is, according to the threshold signature scheme of Congress 110, when nodes that are members of Congress cooperate and use their respective secret key shares to unlock the transaction, the transaction can be unlocked before or after the expiration of the objection period.

[0131] Transaction T1 may also contain information regarding suspicious (unconfirmed) solutions such as commits. For example, the OP_PUSHDATA instruction code can be used to add the hash of the target work product to the transaction. More specifically, the hash of the target work product can be added to the lock script of the transaction. This lock script is configured to be unlocked (after the expiration of the objection period) by an unlock script that gives a solution that hashes to the hash of the target work product contained 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 on the blockchain network (Figure 1). The transaction is mined (i.e., added to a block) and published on the blockchain.

[0133] When a transaction is mined into the blockchain, a challenge period is started, during which any node (Figure 1) can challenge the proposal submitted by the proposer. If no challenge is made during the challenge period, the proposer can claim the reward and the proposer's deposit from transaction T1. The proposer starts a timer to track the remaining time in the challenge period and can automatically take action when the challenge period ends. For example, the proposer can provide the claimant with a work product (which may be called a solution), such as a processor work product, and unlock the lock of the transaction. In one example, the proposer provides a work product indicating that an off-chain event has occurred, and node 102 (Figure 1) can challenge the proposed solution that the off-chain event has actually occurred.

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

[0135] As described above, transaction T1 can be constructed to lock the reward and the proposer's deposit using the OP_CHECKSEQUENCEVERIFY code. This allows the proposer to automatically claim the reward and the proposer's deposit after the end of the objection period without further approval from the claimant.

[0136] Note that when there is no objection to the proposer's solution, a complete transaction can be executed on the proof-of-work main blockchain 902 (FIG. 9) without the need to execute the objection protocol or the ghost chain protocol.

[0137] However, an objector can raise an objection during the objection period. For example, in operation 1202 of method 1200, the objector raises an objection. The objector can perform operations similar to operations 1102 and 1104 of method 1100 in FIG. 11. That is, the objector can identify the request and complete the task off-chain before raising the objection in operation 1202. Also, the objector can determine that an objection should be raised by determining that the objector's solution is different from the proposer's solution. For example, the objector can execute the hash of their own solution and compare the hash with the hash of the proposer's solution, and if the hashes are different, the objector can raise an objection.

[0138] In operation 1202 of method 1200 in FIG. 12, the objector raises an objection within the objection period. The objector can raise an objection by broadcasting the intention to raise an objection to the blockchain network 100. When an objection is raised, a group of nodes can assist in determining the validity of the solution. For example, an objection may be raised in response to a proposal that an off-chain event has occurred, and the objection asserts that the off-chain event has not actually occurred, whereby a group of nodes (e.g., the congress) can determine whether to accept the solution provided by the proposer or the objector.

[0139] For example, referring briefly to FIG. 13, this figure shows a flowchart of method 1300 for an arbiter, where a group of nodes can form a congress that can be used to conduct arbitration when an objection is raised. As described above, the congress is protected by depositing digital assets into a proof-of-work blockchain network. For example, in operation 1302 of method 1300 for the arbiter, the arbiter performing method 1300 for the arbiter can join the congress. For example, the arbiter may perform method 400 for joining the congress described above with reference to FIG. 4. Thus, in operation 1302, the arbiter joins a group that can be called the congress by depositing digital assets into the public group address associated with the congress, becoming a group member. The arbiter performs this deposit on the proof-of-work blockchain network. As described above, the group is associated with a threshold signature scheme for the nodes to control secret key shares. Joining the group (which may also be called registration) can be performed, for example, during the deployment of the ghost chain. FIG. 13 shows that operation 1302 (joining the congress) is performed before operation 1306 (deployment of the ghost chain), so operation 1302 can be performed by a node that joined the congress during a previous deployment of the ghost chain (i.e., not during the deployment in operation 1306). However, operations 1306, 1308, and 1310 may be performed, for example, by a node that joins the group during operation 1306.

[0140]

[0141] In operation 1304, the arbiter cooperates with other nodes in the group to detect the objection made by the objector in operation 1202 of method 1200 for the objector in FIG. 12. More specifically, the arbiter cooperates with other nodes in the group to detect the objection by the objector to the work product of the proposer in response to the request made by the requester.Upon the filing of an opposition due to the above-mentioned transaction T1, the group takes over the management of the award money and the depositor's deposit of the proposer. That is, transaction T1 is constructed to be unlockable by the congress at any time. Therefore, the award money and the deposit are placed under the management of the group and maintained if an opposition is detected within a period called the opposition time following the delivery of the solution to the request by the proposer. Thus, when an opposition is detected, the group manages the award money and the depositor's deposit of the proposer.

[0142] After the group manages the award money and the depositor's deposit of the proposer, in response to the detection of the opposer, the arbiter can cooperate with other nodes of the group to facilitate the deposit of digital assets by the opposer. For example, in response to the detection of an opposition, the congress can construct a transaction T2 that includes an input equal to the award money and the depositor's deposit of the proposer (e.g., T2_in = award money + depositor's deposit of the proposer) and an output equal to the sum of the award money, the depositor's deposit of the proposer, and the depositor's deposit of the opposer (e.g., T2_out = award money + depositor's deposit of the proposer + depositor's deposit of the opposer). Transaction T2 is configured to be paid to the group at any time. That is, transaction T2 is configured to be paid to the congress public key. Transaction T2 can be signed with SIGHASH_ALL|SIGHASH_ANYONECANPAY. The arbiter can provide transaction T2 to the opposer to add the depositor's deposit of the opposer as an input together with other arbiters. For example, the arbiter can disclose transaction T2 to other nodes together with other nodes.

[0143] After transaction T2 is published, the objector adds the objector's deposit as an input to transaction T2. That is, the objector provides the deposit of the digital asset (in operation 1204 of method 1200 regarding the objector in FIG. 12) and places such deposit under the management of the group. More specifically, the objector's deposit is placed under the management of the congress public key. Therefore, the reward, the proposer's deposit, and the objector's deposit are all placed under the management of the group and restricted by the congress public key. As described in detail in the above description of the congress, by means of the threshold signature scheme, a threshold number of congress members can cooperate to generate a valid signature of the transaction including the reward, the proposer's deposit, and the objector's deposit using their respective secret key shares. The proposer's deposit and the objector's deposit may be of the same size.

[0144] The objector can also commit to the solution of the objection. For example, the objector can add the hash of the solution to transaction T2 using, for example, the instruction code OP_PUSHDATA.

[0145] Transaction T2 is broadcast to the main blockchain network and mined on the main blockchain network such that the objector's deposit is restricted by the congress public key. The reward, the proposer's deposit, and the objector's deposit are placed under the exclusive management of the group.

[0146] In this way, the objector provides evidence of the alternative solution and the deposit to the arbiter. In operation 1306 of method 1300 regarding the arbiter, after transaction T2 is mined on the main blockchain network, the arbiter cooperates with other nodes in the group to deploy a ghost chain to resolve the objection. As described above, the ghost chain is a proof-of-stake blockchain where the miners of the ghost chain are members of the group. That is, members of the congress are permitted to mine on the ghost chain. The member deposits on the proof-of-work blockchain network function as the funds contributed to enable members of the congress to mine on the ghost chain, and the probability that a member is selected for mining is proportional to the relative amount of the deposit.

[0147] (In operation 1306) While the ghost chain is being deployed, the arbiter can cooperate with other nodes in the group to create or obtain the genesis block of the ghost chain. The genesis block can be the final block from the last ghost chain deployment (e.g., the terminal block from the last instance where the ghost chain was executed and the previous execution was performed in response to a past objection). This block may contain information regarding the genesis payment. The genesis payment is a transfer of digital assets, which has not yet been made and is based on a previous deployment of the ghost chain.

[0148] Furthermore, while the ghost chain is being deployed, members can be permitted to register or request deregistration from the group. During the registration phase, new members are registered and (as described above with reference to FIG. 4) a secret key share is assigned to that member. The new member is provided with the genesis block (which can be authenticated by the current threshold members) and subsequent blocks generated during the registration process.

[0149] The execution of a ghost chain may also include a pre-cancellation stage. During this pre-cancellation stage, the member who requested the cancellation can send proof of the deletion of specific personal data. Such proof may be required for the return of the member deposit. Evidence of improper conduct that may prevent the return of the member deposit can be sent at this stage (for example, a newly registered member can send a genesis block that is suspected of being fake and has been pre-committed by the current member(s)). The method of cancellation is described in detail above with reference to FIG. 8.

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

[0151] The arbiter and other nodes of the congress can resolve objections by performing tasks related to the request to determine the correct solution. For example, the task (e.g., calculation or algorithm) can be executed on-chain (i.e., on the ghost chain itself). The group can determine which of the proposer's solution and the objector's solution is correct by comparing such a solution with the unique solution determined on the ghost chain. During this process, group members (i.e., miners of the ghost chain) perform calculations and / or analyses to arbitrate on the dispute. The group members reach a consensus and sign the block during this process. In some cases, the resolution of objections may include a vote by nodes (e.g., members of the congress) to determine whether to accept the proposer's solution or the objector's solution. This can be used, for example, in the case of a binary solution where the solution is one of two values, such as determining whether an off-chain event has occurred. The result of the vote is defined as true regarding whether an off-chain event has occurred and may be treated as the correct solution.

[0152] (Cooperating with other nodes of the group) The arbiter makes a judgment while the ghost chain is being deployed. It can be said that a judgment has been reached when the arbiter and other nodes of the congress resolve an objection (i.e., when such nodes form a consensus regarding the resolution).

[0153] After reaching an arbitration decision on the blockchain, the arbitrator constructs the final transaction (which is mined into the main blockchain network when fully signed) in cooperation with the other nodes of the group. The final transaction, which may also be referred to as the settlement transaction, includes various digital asset transfers; for example, (i) rewards + deposits (which may be transferred to the nodes that were considered successful or legitimate during the arbitration process); (ii) mining fees (for the already executed ghost chain mining); (iii) genesis payments (which are digital asset transfers that occur based on previous executions of the ghost chain and are determined from the genesis block); and / or (iv) return of the member deposits of the deregistered members may be included.

[0154] This transaction may also include useful metadata. For example, the settlement transaction may return the solution to the blockchain network. Thus, during this process, the group (i.e., the arbitrator cooperating with the other nodes of the group) can commit the result of the arbitration to the blockchain network. The group can also commit the Merkle root hash of the intermediate computational state as an on-chain determined on the ghost chain to the blockchain network.

[0155] Thus, digital assets under group management can be distributed by an arbiter in cooperation with other nodes of the group (in operation 1308). The distribution of such digital assets is carried out in accordance with a threshold signature scheme defined for the congress (i.e., for the group). As described in the above congress discussion, 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 arbiter can agree to the transfer of digital assets by adding a partial signature to the final transaction using the arbiter's secret key share together with other nodes of the group (i.e., together with other arbiters). Until a valid signature of the final transaction is created using at least the threshold number of secret key shares required under the threshold signature scheme, other nodes also add partial signatures using their respective secret key shares.

[0156] The specific method of distributing digital assets in the final transaction depends on the result of arbitration. For example, if the objection is successful, the arbitrator can cooperate with other nodes to transfer at least the depositor's funds of the objector to the objector and distribute the depositor's funds of the proposer to the miners of the ghost chain in proportion to the absolute number of mined blocks. If the objection is successful and the solution of the objector is determined to be correct, the bonus can also be transferred to the objector. In this way, the objector can receive digital assets in operation 1208 of method 1200 regarding the objector in FIG. 12. However, if binary search is used such that the correct solution is not identified, the bonus can be returned to the claimant who re-files the claim, enabling the objector to submit a proposal based on the response. Alternatively, if the proposer is excluded by binary search, the claimant can treat the objector's commitment as a proposal and resume operations in operation 1006 of method 1000 in FIG. 10. That is, the claimant can construct a new transaction T1 based on the objector's proposal. This transaction can be as described above with reference to operation 1006, except that the node previously regarded as the objector is now regarded as the proposer. In this way, the new transaction T1 can be constructed such that the solution corresponding to the hash of the solution is given as provided by the objector in the above-mentioned transaction T2 and is unlocked by the objector after the end of the objection period.

[0157] If it is determined that the work product of the proposer is valid, the arbitrator can cooperate with other nodes to transfer the bonus and the proposer's deposit to the proposer and distribute the depositor's funds of the objector to the miners of the ghost chain in proportion to the absolute number of mined blocks. In this way, the proposer can receive digital assets in operation 1110 of method 1100 in FIG. 11.

[0158] The requester receives a solution in operation 1008 of method 1000 regarding the requester in FIG. 10. The method by which the requester receives the solution in operation 1008 may depend on whether an opposition has been filed. For example, if no opposition has been filed, the proposer committed the solution to the blockchain using transaction T1 described above with reference to operation 1006 of method 1000 in FIG. 10. However, if an opposition has been filed and the solution to the claim 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., in operation 1310 of method 1300 regarding the arbiter in FIG. 13). Therefore, according to the ghost chain protocol, nodes participating in the ghost chain can automatically send the solution to the requester when the solution is determined.

[0159] Furthermore, after reaching a decision in the ghost chain, constructing and validly signing a transaction, the ghost chain ends (in operation 1310 of method 1300 regarding the arbiter in FIG. 13). That is, when the opposition is resolved, the ghost chain ends. When the ghost chain ends, information related to the resolution of the opposition can be returned to the proof-of-work blockchain network.

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

[0161] As described above, when the arbiter (i.e., the node of the Congress) reaches a decision, the nodes cooperate to construct a transaction that is broadcast on the main chain (in operation 1308) when a validly signed transaction is generated by adding partial signatures in the threshold signature scheme as described above. Since the transaction itself is a computation among others, the nodes contributing to this transaction may receive a reward for participating in this transaction. However, since the transaction is specified before being signed, the reward for participating in the signature (including the transmission of partial signatures to the ghost chain via the transaction and the actual mining of the block) may be deferred until a further ghost chain is deployed. Such a deferral may be provided in operation 1310. More specifically, the terminal block may be constructed to include information that enables the processing of the genesis payment during the future deployment of the ghost chain. Such information may be a record of the mining fees attributable to blocks created after the construction of the final transaction, such as the block created during the signing of the final transaction. That is, the genesis payment can be defined to reward the nodes that contributed to the signing of the final transaction. The terminal block of the ghost chain becomes the genesis block for the execution of the next ghost chain (i.e., when the ghost chain is deployed next). Therefore, a record is created in the terminal block for future genesis payments. According to the embodiment shown just above, members register / deregister during the execution of the ghost chain, and it should be noted that this can be triggered by an objection. In an alternative embodiment, registration / deregistration at regular intervals or under other conditions is also possible. This may include a schedule-adjusted execution of a ghost chain dedicated for this purpose, which is similar to the above-described ghost chain deployment except that there is no arbitration and decision-making phase. In this case, the mining fee may be paid at least partially from the "registration fee" required in return for registration.

[0162] Also, note that in the above-described method 1300, it is described about the execution of a ghost chain that is not the execution of the first ghost chain. That is, the method 1300 describes the deployment of a ghost chain that was deployed at a certain point in the past, and there already exists a terminal block including a genesis payment for the ghost chain. The method 1300 can be modified to be able to deploy the first ghost chain. For example, when the ghost chain is first deployed, the genesis block can be established in another way. For example, the genesis block can be provided by the first trusted party.

[0163] By arbitrating disputes using a proof-of-stake-based blockchain, the solution of the ghost chain can be configured by proof of stake to enable more regular block generation and block generation at a high frequency, so that a faster solution can be provided than performing such arbitration in the proof-of-work blockchain network itself. Further, by performing such arbitration operations on the ghost chain rather than on the main blockchain itself, tasks are pushed out from the main blockchain network, thus reducing the load on the main blockchain network.

[0164] Furthermore, the temporary nature of the ghost chain (i.e., the fact that the ghost chain is essentially temporary and ends) can typically avoid or mitigate the risk of the nothing-at-stake problem that does not do anything when staking, which affects the proof-of-stake blockchain network. Due to the temporary nature of the ghost chain network, the congress can require the miners of the ghost chain to leave the deposit in a predetermined place until the ghost chain ends. That is, during the execution of the ghost chain, the congress can be configured so that the congress members cannot withdraw their staked funds.

[0165] While the above example refers to the instruction codes available in Bitcoin, the methods described in this specification can also be used in other types of blockchain networks.

[0166] While the above method has generally been described as being executed at a node, the functionality of this method depends on cooperation with other nodes and can be executed elsewhere.

[0167] Event Lock Encryption from Congress and Ghost Chain A method for performing event lock encryption using Congress and Ghost Chain will be described below.

[0168] Event lock encryption can refer to a mechanism that performs cryptographic operations in response to the occurrence of an event. As an example, time-lock encryption is a specific type of event lock encryption that refers to a mechanism for "sending" a message "into the future" such that a given ciphertext is decrypted at or after a specific point in the future. In this case, the event is the (possibly random) passage of time. Thus, event lock encryption can be used to ensure the performance of cryptographic operations conditional 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, using the techniques described in this specification, the efficiency of solving problems presented in the context of knowledge encryption (witness encryption), as discussed in, for example, Bitanksy et al., "Time-Lock Puzzles from Randomized Encodings", can be improved.

[0169] For illustrative purposes, the cryptographic operations performed as part of the event-lock encryption described in connection with FIGS. 9 and 10 are the decryption of ciphertext conditional on the occurrence of an event. However, in various embodiments, other cryptographic operations may be performed instead of, or in addition to, those described in connection with what is shown in FIGS. 9 and 10. Generally speaking, when it is determined that an event has occurred, one or more operations (computations), such as such cryptographic operations, may be performed.

[0170] Events used to facilitate event-lock encryption can be classified into on-chain events and off-chain events. An on-chain event refers to an event that can be confirmed through inspection of a blockchain, and an off-chain event can refer to an event that is not an on-chain event. A message can be encrypted with public key A according to an identity-based encryption scheme. Public key A may be a cryptographic public key having a corresponding cryptographic secret key SkA that is accessible to the entity performing the encryption. The congress public key may be in accordance with what is described elsewhere, such as in connection with FIG. 1. An event (e.g., a time threshold) digitally signed with the encrypted message, public key A, and secret key SkA can be sent to the blockchain via a flagged transaction. When the event is confirmed by the congress, a ghost chain can be instantiated and a decryption key can be created, 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 can deposit digital assets into a congress pool and, in response, receive a secret key share for Congress 110. In some embodiments, the share received by the entity may be proportional to the amount and / or value of the deposited digital assets. The secret key share can be utilized in a threshold signature scheme in which Congress manages the digital assets restricted by a public key associated with Congress. The Congress public key restricts the digital assets deposited by members of Congress 110 into the congress pool in exchange for the secret key share, and digital assets deposited into an address associated with the congress pool by members or non-members of Congress 110 for reasons other than obtaining the secret key share (i.e., placed under the overall, partial, or conditional control of Congress). Non-members or members may deposit digital assets into an address associated with Congress for various reasons. For example, the reason for depositing digital assets into an address associated with Congress is to provide a fee for the execution of one or more instructions upon detection of the occurrence of an event.

[0172] Miners of the ghost chain can cooperate to create a decryption key. Generally, the ghost chain 904 can not only simply resolve disputes but also be deployed for some reason. The ghost chain is instantiated and functions as an additional dedicated bulletin board for sharing information used to create the decryption key. Members of Congress can become miners of the ghost chain.

[0173] In some embodiments, a method for performing threshold encryption and decryption can be described according to the techniques described herein. An entity can perform encryption according to an identity-based encryption scheme. For example, an entity can encrypt a message with an encryption public key associated with the entity, where this encryption uses the congress public key as the public key for the entire system of the identity-based encryption scheme. The identity-based encryption scheme can correspond to that described by Boneh and Franklin in "Identity-Based Encryption from the Weil Pairing". Thus, an entity can encrypt a message with an encryption public key using the public key for the entire system. The entity can access the corresponding encryption private key, and the public key for the entire system can be the congress public key.

[0174] A transaction can be broadcast to a proof-of-work blockchain network, and the transaction can include an encrypted message according to an identity-based encryption scheme, a message public key A (i.e., the public key of the encryption key that encrypts the message under the identity-based encryption scheme), an event that triggers the 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 the signature key SkA, and the message public key A and the signature key SkA are the public key and the private key of an asymmetric key pair, respectively. The transaction may further include data digitally signed using the private signature key SkA. For example, a set of conditions for decrypting the encrypted message is digitally signed using the private signature key SkA, and the validity of the digital signature is verified using the message public key A before deriving the decryption key (e.g., when the message public key A and the private signature key SkA form an asymmetric key pair). Generally speaking, the set of conditions may include information such as when to perform decryption (e.g., in response to a time-based event) and how to perform decryption (e.g., it may be necessary to encrypt the presence or absence of contributions to the decryption key itself under a set of public keys S so that one or more entities having access to the set of private keys corresponding to the set of public keys S can utilize the decryption key). The event can be an event or condition that, when satisfied, enables the decryption of the encrypted message by making the decryption key available. The fee can be for the transfer of digital assets to an address associated with the public group address of Congress 110. The fee can be distributed among the members of Congress who cooperate and participate in the execution of the event lock decryption of the encrypted message.

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

[0176] When a 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 on-chain events, a consensus is reached when the event occurs, while in the case of off-chain events, a consensus can be reached when a threshold number of proofs are confirmed. Therefore, the ghost chain can be deployed. The ghost chain may conform to what is described elsewhere in this disclosure, such as that related to FIGS. 9-13. The ghost chain 904 may be instantiated with a genesis block that 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] Using the blocks added to the ghost chain, a decryption key can be created that can be used to decrypt the encrypted message. If the required amount is included in the ghost chain block (for example, if a decryption key can be generated), the final transaction that has the effect of distributing funds to the main block chain 902 can be constructed and signed (for example, nodes participating in the mining of the ghost chain may be paid to create the decryption key). In some cases, the decryption key can be encrypted using the public key associated with the intended recipient and sent to the ghost chain 904 in encrypted form. The intended recipient can derive the decryption key using the corresponding private key by means of a cryptographic technique. In some cases, this information may be made public on the main block chain.

[0178] After the final transaction has been constructed and signed, the ghost chain 904 ends and the constructed transaction is mined into the main block chain 902. Since the ghost chain 904 ends, unlike a typical block chain, the ghost chain 904 has a terminal block. This terminal block, which is the last block of the ghost chain 904, occurs when the decryption key is derived or when other specified operations are completed, and the resulting transaction that distributes funds on the main block chain 902 and distributes funds to reward the 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 is continuously executed and is not configured to end when deriving the decryption key. The side chain can continue to operate and can be configured to perform various tasks other than deriving the decryption key. In one embodiment, the side chain is a proof-of-stake blockchain configured to facilitate a plurality of activities including, but not limited to, deriving cryptographic keys. Many blocks are added to the side chain by miners, and the decryption key is derived. Using the blocks added to the side chain, a decryption key that can be used to decrypt the encrypted message can be created. If the required amount is included in the side chain block, the decryption key may be obtained.

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

[0181] An off-chain event can refer to an event that can occur or not occur based on information outside the blockchain. The off-chain event may include information that a member of the congress can make a decision on. For example, the off-chain event may determine that a person has died. In response to the determination that the event has occurred, a decryption key is generated (or decryption of the encrypted message occurs). Generally speaking, the TEE does not evaluate whether the off-chain event has occurred. Instead, the nodes of the congress evaluate whether the event has occurred, issue a certificate for the occurrence or non-occurrence of the event, and sign the certificate using a secret key that only the nodes can access, thereby proving that the occurrence or non-occurrence of the event has been verified. For example, the certificate can be digitally signed and verified by encryption using the public key corresponding to the account to which the member's deposit has been transferred. A consensus can be reached regarding the confirmation of the threshold certificate, and the transaction can be constructed and signed as described above.

[0182] In one embodiment, event lock encryption can be implemented using at least in part the main chain and blockchains, for example, in relation to the various embodiments described above. In embodiments configured to perform one or more cryptographic operations (e.g., derivation of a decryption key) using a side chain, the on-chain event that triggers the creation of the decryption key can be an event related to the main blockchain or side chain. For example, in the case of time-lock encryption that enables the use of the decryption key at a threshold time, the elapse of the threshold time can be detected based on the timestamp detected in a block mined on the main blockchain or side chain. Further, in the case of a side chain, a certificate regarding the occurrence of an off-chain event can be mined on either the main chain or side chain. In some cases, whether the certificate is sent to the main chain or side chain can be based on the determination that the main chain or side chain is generating blocks faster and more regularly. The advantage of generating blocks faster and more regularly is that the time required for block confirmation is reduced. Further, in various embodiments that use a ghost chain to create the decryption key, it should be noted that the certificate is sent to the main chain and the ghost chain can be instantiated in response to sufficient certificates being confirmed.

[0183] Referring now to FIG. 14, FIG. 1400 shows a blockchain 1402 that can be utilized to perform 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 can include data, information, etc., which are in digital form and are encrypted by the sender under an event-lock encryption scheme such that the message is decryptable and / or decrypted upon the occurrence of an event. The message 1404 can be encrypted to the encryption public key 1408 according to an identity-based encryption scheme that utilizes the congress public key 1406. The encryption public key 1408 can have a corresponding encryption private key 1422 accessible to the entity that generates the event-lock message. The congress public key 1406 can be an asymmetric public key associated with the congress 1410 shown in FIG. 14. The congress 1410 shown in FIG. 14 can correspond to the congress described elsewhere in this disclosure. This congress can be used to verify the occurrence of on-chain events and off-chain events. The message 1408 can be encrypted to the encryption public key 1408 according to an identity-based encryption scheme that utilizes the congress public key 1406, thereby generating the encrypted message 1414.

[0185] Transaction 1416 is broadcast to blockchain 1402, and this transaction may include encrypted message 1414, sender public key 1408, and event 1412. The transaction can be a flagged transaction that includes, as metadata, an identifier that makes it recognizable as a transaction useful for a particular purpose. Event 1412 can be an event or condition that, when satisfied, enables the encrypted message 1414 to be decrypted. Event 1412 can be an on-chain event, an off-chain event, or any combination thereof. The event can conform to the on-chain events and off-chain events described elsewhere in this disclosure. Event 1412 can be encoded in various forms, such as an expression as a predicate that can be evaluated to a TRUE or FALSE statement. For example, event 1412 can be the elapse of a specified time, after which the encrypted message 1414 must be decryptable by recipient 1420. Event 1412 can be digitally signed by the entity that encrypts the message. The digital signature can be generated using sender secret key 1422, which is an asymmetric secret key corresponding to sender public key 1408 used to generate encrypted message 1414. Sender public key 1408 can be included in transaction 1416 and can be utilized to cryptographically verify that the digital signature generated for event 1412 is genuine. In some embodiments, transaction 1416 also includes a fee. The fee can be for the transfer 1410 of digital assets to an address associated with the public group address of the congress. The fee can be distributed among the members of the congress who cooperate and participate in the execution of the decryption of the event lock of the encrypted message. The method and process for generating the event lock message will be described in more detail in relation to FIG. 15.

[0186] When a member 1410 of the Congress detects that the event has been satisfied, a ghost chain can be deployed to create a decryption key. The ghost chain may conform to what is described in other parts of this disclosure, such as that discussed in relation to FIGS. 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 an event-locked encrypted message should be decrypted. The ghost chain 904 can be instantiated with a genesis block that is the final block from a previous instantiation of the ghost chain. Many blocks are added to the ghost chain by miners, facilitating the creation of the decryption key.

[0187] Once a decryption key is created, a transaction is constructed and signed on the ghost chain. The transaction can be a transaction that has the effect of distributing funds to the main blockchain 902. For example, nodes participating in the mining of the ghost chain receive payments to perform one or more operations (e.g., creation and / or distribution of the decryption key 1418) when an event is determined to have occurred. In some cases, the decryption key 1418 can 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. When a TEE belonging to a member of Congress 1410 detects the occurrence of an event, it can generate respective shares of the decryption key, encrypt those shares with the public key associated with the intended recipient, and include those encrypted shares in the ghost chain. Thus, the intended recipient can use the corresponding private key to obtain access to the decryption key. The recipient 1420 can refer to an entity or a computing entity instead of the entity that receives the decryption key 1418. The decryption key 1418 is used to perform cryptographic operations so that the recipient 1420 can decrypt the encrypted message 1414 made available to the recipient 1420 via the blockchain 1402. In some cases, the recipient can refer to multiple entities such as a user group or even the general public. For example, the decryption key is published on the main chain and anyone can obtain the decryption key and decrypt the encrypted message. The method and process for obtaining the decryption key and using the decryption key to decrypt the encrypted message will be described in more detail in relation to FIG. 16.

[0188] Referring now to FIG. 15, an exemplary method 1500 is shown for creating an event lock message that can be made decryptable based on the occurrence of an event. Method 1500 can be performed by any suitable system, such as a computer device that executes an instance of the blockchain protocol on which blockchain network 100 operates. This method can be performed by node 104. Using this method, for example, a time-lock encryption technique can be implemented in which an encrypted message becomes decryptable / or is decrypted when a specified time is reached or elapsed.

[0189] The system can obtain an encryption public key and a corresponding encryption private key (1502). The system can encrypt the message with the encryption public key according to an identity-based encryption method such as the Boneh-Franklin identity-based encryption method (1504). The encryption can be performed according to the technique described by Boneh and Franklin in "Identity-Based Encryption from the Weil Pairing". The encryption can be performed using elliptic curve cryptography such as the method described below. When the message is encrypted, an encrypted message or ciphertext can be generated.

[0190] The system can also generate a digital signature for an event that specifies one or more conditions for decryption (1506). The conditions can indicate, for example, the time when decryption should be performed (in the case of time-lock encryption). In some cases, it can also be conditioned whether it is necessary to encrypt the contribution to the decryption key before the TEE outputs it, and if so, the set of keys to be used for encryption. A transaction containing a contribution to the decryption key may be digitally signed using the cryptographic private key corresponding to the cryptographic public key used to encrypt the message according to an identity-based encryption scheme. The authenticity of the digital signature can be verified cryptographically using the cryptographic public key, which can be sent 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 (1506) to the proof-of-work blockchain network that include an encrypted message, the public key that encrypted the message, an event indicating the conditions under which the encrypted message should be decrypted, at least the corresponding digital signature for the event, and a fee. The event can be an on-chain event or an off-chain event such that Congress 110 can reach a consensus as to whether the event has occurred. In the case of an off-chain event, decryption can occur in response to a consensus that a threshold number of certificates for the occurrence of the event have been verified. (For example, in a system where revocation is possible) There can be additional conditions for performing decryption, such as requiring the threshold to be maintained over a certain period of time. The conditions are specified by the requester and can be encoded in one or more of the transactions described above. For example, in the case of time-lock encryption, the event can be the (possibly random) passage of time, which can be determined and verified using on-chain information. The fee can be for the transfer of digital assets to an address associated with the public group address of Congress 110. The fee can be distributed among the members of Congress who cooperate and participate in performing the event-lock decryption of the encrypted message. In some cases, one or more transactions may indicate that one or more operations (computations) need to be performed in addition to or instead of decryption.

[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 from the Weil Pairing" and may provide improved efficiency and reliability using the techniques described in connection with method 1500 and other places in this disclosure. In some embodiments, it may be assumed that there exist G1 and G2 including a bilinear mapping e: G1×G1→G2 and a generator P of G1. In one embodiment, both G1 and G2 are finite cyclic groups of the same prime order q, and the discrete logarithm problem is assumed to be difficult on G1 and G2. Further, the congress public key P pub and the corresponding secret key

Number

Number

[0193] Referring now to FIG. 16, this figure shows an exemplary method 1600 for event lock decryption. The method 1600 of FIG. 16 can be executed cooperatively by one or more computer systems, such as nodes of a congress. The method 1600 can be executed at a certain point in time after the transactions described in connection with FIG. 15 have been sent and confirmed in the blockchain network. One or more transactions can include encrypted messages, cryptographic keys such as public keys associated with the intended recipient, and the like. For example, the first transaction can include an encrypted message, a cryptographic key, and an event or condition indicating when the encrypted message should be made decryptable, and the second transaction can include a fee to the congress that can be allocated in connection with the generation of a decryption key upon the occurrence of the event or condition specified in the first transaction.

[0194] A system, such as a member of a congress or more generally a node of a blockchain network, can detect the occurrence of an event related to the above-described transaction (1602). The event may be an on-chain event or an off-chain event. In the case of an on-chain event, when the TEE confirms the event requested in the blockchain, it contributes to the creation of a decryption key using the key share held internally. In some cases, it is necessary to monitor on-chain events with the confirmed transactions. In the case of an off-chain event, a consensus that is considered a reliable indicator indicating that the off-chain event has actually occurred may be obtained with an on-chain event. For example, the corresponding on-chain event may be that a threshold congress member who believes that an off-chain event has occurred has received a notification by sending a specific flagged transaction to the blockchain. In some cases, these notifications (signals) may be withdrawn if the congress member later determines that the off-chain event has not occurred (for example, the node may later determine based on subsequent and / or additional information that the off-chain event has not actually occurred). In such a system, it may be further necessary for the flagged transaction to remain unwithdrawn for a certain period of time to reach a consensus.

[0195] As an alternative method for determining whether an off-chain event has occurred, a node can send an indication that an event has occurred and can include a deposit of digital assets. The deposit is returned by the congress (similar to the payment of at least a portion of the fees deposited as a reward for decrypting the event lock message) if the congress determines that the event has occurred and can be confiscated if the congress determines that the event has not occurred. In some cases, objections can be raised to the solution provided by the node, and the resolution of whether an off-chain event has occurred can be determined by having the members of the congress vote on whether to accept that the event has occurred or not.

[0196] As described in connection with FIG. 15, the transaction may include an encrypted message, a public key A with which the message is encrypted according to an identity-based encryption scheme, and a digitally signed event. The validity of the digital signature for the event can 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-lock encryption scheme, the event can be a timestamp indicating when the encrypted message should be made decryptable. By verifying the authenticity of the digital signature for the timestamp, entities that do not have access to the secret signature key SkA corresponding to the public key A are prevented from prematurely triggering the creation of the decryption key. By generating a digitally signed signature that is cryptographically verifiable 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 that contains any ciphertext encrypted with the public key A before the decryption time. By requiring that the transaction include a valid signature, a "front running" attack is made impossible because the congress does not proceed unless the transaction contains a valid digital signature generated using the secret signature key SkA corresponding to the public key A.

[0197] A ghost chain can be deployed (1606), and members of the congress can cooperate with other nodes of the group to create or obtain the genesis block of the ghost chain. The genesis block can be the final block from a previous ghost chain deployment (e.g., the terminal block from the last instance in which the ghost chain was run, and the previous execution can be done, for example, in response to a past challenge or the decryption of a previous event block). This block may contain information regarding the genesis payment. The genesis payment is a transfer of digital assets that has not yet been made based on a previous deployment of the ghost chain. The ghost chain can be deployed using techniques described elsewhere, such as in relation to Figure 13.

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

[0199] In some embodiments, the decryption key can be made public by publishing it in plaintext form to the main blockchain. Optionally, only the group holding a given set of secret keys may be allowed access to the decryption key. For example, in some systems, an event-lock message can be made decryptable by the owner of the set of secret keys corresponding to the set S of public keys. In one example, each contribution to the decryption key is encrypted using each of the set S of public keys before being output by the TEE, and these ciphertexts are sent to the blockchain. As a second example of how the owner of the set of secret keys corresponding to the set S of public keys can make the ciphertext decryptable, after a transaction containing the event-lock message is confirmed, the signature key SkA can be encrypted using each public key of the set S of public keys and distributed to the individual owners of the set of secret keys corresponding to the set S of public keys (e.g., these encryptions can be mined into the blockchain in another transaction). Further, the transaction containing the event-lock message is decrypted using the public key A (i.e., the public key corresponding to the signature key SkA) before being output by the TEE and sent to the blockchain to specify that the contribution to the decryption key d A should be encrypted. Once this is done, the recipient of the encryption of the signature key SkA can create the decryption key.

[0200] The ghost chain ends (1608). That is, once the task (e.g., creation of the decryption key) is complete, the ghost chain ends. When the ghost chain ends, the decryption key can be recorded on the proof-of-work blockchain network. The ghost chain can be ended using techniques described elsewhere, such as in relation to FIG. 13.

[0201] Continuing the description of the previous example described in relation to FIG. 15, the decryption function for decrypting the ciphertext c = (u, v) corresponding to the encrypted message has been described above. The secret key can be derived as d A = sQ A and QA is the above Q A is defined as =H1(A). Therefore, the decryption function for decrypting the ciphertext c can be as follows.

Equation

[0202] As described by Boneh and Franklin in "Identity-Based Encryption from the Weil Pairing", the above leads to a particularly efficient threshold decryption scheme. The decryption of the ciphertext c = (u, v) can be achieved by broadcasting e(s i Q A , u), where each participant with a threshold holds a share s i of the system-wide secret key. Next, from the basic properties of the mapping e, we have the following.

Equation

[0203] The above-described embodiments are illustrative rather than limiting of the present invention, and it should be noted 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 claims. Words such as "comprising," "comprises," etc. do not exclude the presence of elements or steps other than those listed in the claims or the entire specification. In this specification, "comprising," "comprises" means "including," "includes" or "consisting of," "consists of." A reference to a singular element does not exclude a reference to plural such elements, and vice versa. The present invention can be implemented by means of hardware including several distinct elements and by a computer appropriately programmed. In apparatus claims listing several means, some of these means can be embodied by the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used advantageously.

[0204] The following is described as an example the claims at the time of initial filing. [Example 1] A method implemented by a computer, the method implemented by the computer comprising: A step of encrypting a plaintext message into an encrypted public key using at least a congress public key according to an identity-based encryption method, wherein the congress public key is associated with a member of the congress, and each member of the congress has access to a secret key share that can be used in a threshold decryption method. In the threshold decryption method, at least a threshold number of secret key shares are sufficient to derive the decryption key by a combination of partial contributions to the decryption key on behalf of the congress. The generating step; Generating a digital signature for a first set of instructions for performing an encryption operation upon the occurrence of an event, using at least the encrypted secret key corresponding to the encrypted public key; Broadcasting one or more transactions including the encrypted message, the encrypted 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 commands the members of the congress to cooperate to deploy a ghost chain and execute the first set of instructions in response to reaching a consensus on the occurrence of the event on the condition that the digital signature is genuine. Executing the first set of instructions includes at least deriving the decryption key from a plurality of secret key shares and an encryption key that satisfy the threshold. The decryption key is sufficient encryption material to obtain the plaintext message from the encrypted message. A method implemented by a computer. [Example 2] The method implemented by a computer according to claim 1, wherein the decryption key is derivable based at least in part on a scheme based on pairing on an elliptic curve. [Example 3] The method implemented by a computer according to claim 1 or 2, wherein the identity-based encryption method follows the Boneh-Franklin identity-based encryption method. [Example 4] The one or more transactions include a transaction that includes a fee to a public group address associated with the congress, and the fee is distributed to at least some of the miners of the ghost chain that cooperate to derive the decryption key, the computer-implemented method according to any one of claims 1 to 3. [Example 5] The method implemented on a computer according to any one of claims 1 to 4, wherein miners of the ghost chain reach a consensus regarding the event based on information obtainable from the proof-of-work blockchain. [Example 6] The method implemented on a computer according to claim 5, wherein the information obtainable from the proof-of-work blockchain is a timestamp of a transaction transmission to the proof-of-work blockchain. [Example 7] The method implemented on a computer according to claim 5, wherein the information obtainable from the proof-of-work blockchain is the detection of valid blocks at least at a specific height. [Example 8] Based at least in part on detecting that a member of the congress issues at least a threshold certificate that the event has occurred, a consensus is reached, and the occurrence of the event is determined based at least in part on information external to the proof-of-work blockchain. Further, the authenticity of the certificate is verifiable cryptographically using a cryptographic public key associated with each member of the congress, the computer-implemented method according to any one of claims 1 to 4. [Example 9] The method implemented on a computer according to claim 8, wherein the certificate is issued over a predetermined period. [Example 10] The method implemented on a computer according to any one of claims 1 to 9, wherein the cryptographic operations include one or more decryption operations. [Example 11] The method implemented by a computer according to any one of claims 1 to 10, wherein the cryptographic operation includes one or more authentication operations. [Example 12] The respective secret key shares of the members of the congress are generated, and the secret key shares are used to perform cryptographic operations within a trusted execution environment in a node associated with the member. The method implemented by a computer according to any one of claims 1 to 11. [Example 13] A computer-readable storage medium including computer-executable instructions that, when executed, configure a processor to implement the method according to any one of claims 1 to 12. [Example 14] An electronic device, the electronic device An interface device, A processor coupled to the interface device, A memory coupled to the processor, and has The memory stores computer-executable instructions that, when executed, configure a processor to implement the method according to any one of claims 1 to 12. Electronic device. [Example 15] The processor includes a trusted execution environment, and the computer-executable instructions are executed within the trusted execution environment. The electronic device according to claim 14.

Claims

1. 1. A method for updating a distribution of secret key shares, the method comprising: In response to changes in the membership of the group of nodes that constitute the Congress, detecting a redistribution request to redistribute key shares among a new group of nodes; generating new secret key shares for each node in the new group of nodes; transferring digital assets from a public address associated with a previous group of nodes to a new public address and a new public key associated with the new group of nodes; method.

2. 2. The method of claim 1 , wherein the new private key shares are used in a threshold signature scheme in which at least a threshold number of private key shares must be used to generate a valid signature for a transaction on behalf of a congress constituting the new group of nodes.

3. The step of generating a secret key share comprises: [0010] generating a point [0025] and setting this as the secret key share of the first node of the new node group.

4. This polynomial [0030] 4. The method of claim 3, further comprising the step of distributing the above points to each congress member (i=1, . . . , n) of the new node group.

5. 5. The method of claim 4, wherein each congress member (i=1, . . . , n) adds the received value to an existing secret key share to obtain the new secret key share.

6. The method of claim 1 , wherein the redistribution request is detected when a potential new member transfers digital assets to a public group address.

7. 7. The method of claim 6, wherein the redistribution request is detected when an existing member of the previous group of nodes requests a withdrawal of a member deposit.

8. The method of claim 7 , further comprising the step of, in response to receiving the redistribution request, evaluating the redistribution request against determined criteria.

9. 9. The method of claim 8, further comprising facilitating a withdrawal of said member deposit, said withdrawal being facilitated according to a threshold signature scheme and occurring only if at least a threshold number of congress members approve said withdrawal.

10. 10. The method of claim 9, further comprising the step of making said withdrawal after a period of inactivity by a member who wishes to leave.

11. The method according to any one of claims 1 to 10, wherein, when the redistribution request is detected, one or more attributes in at least a portion of the transactions of digital assets to a public group address are used to identify members of the previous groups that constitute the congress.

12. A computer-readable storage medium comprising computer-executable instructions that, when executed, configure a processor to perform the method of any one of claims 1 to 11.

13. 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 has stored therein computer-executable instructions which, when executed, configure the processor to perform a method according to any one of claims 1 to 11. electronic equipment.

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

Images