Methods related to blockchain networks

Abstract

This invention provides a method and system for setting up off-chain transfer channels to restore a blockchain network in the event of a node failure. [Solution] The method involves providing the enclave public key from the enclave associated with the TEE on the node to the hub, establishing a channel with the hub by broadcasting a funding transaction that restricts digital assets with the first public key, second public key, and third public key to the blockchain network, receiving a commitment transaction encrypted with the enclave public key, detecting a defect, and issuing a fail-safe activation request to the group using the data from the enclave.

Description

Technical Field

[0001] The present invention generally relates to distributed ledgers, and more particularly to off-blockchain channels. The present invention is particularly, but not limited to, related to providing a fail-safe mode in case of a failure of an off-blockchain channel established between participants for the purpose of electronic communication and exchange. Such channels, and the communications / transfers conducted via them, can be vulnerable with respect to attacks and network failures.

Background Art

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

[0003] A blockchain is a consensus-based electronic ledger, implemented as a computer-based, decentralized system composed of blocks consisting of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and it contains at least one input and at least one output. Each block contains the hash of the preceding block, and as a result, those blocks together create a persistent and immutable record of all transactions that have been written to the blockchain since its inception. A transaction contains a small program called a script, which is embedded in the input and output of the transaction, and the script specifies how and by whom the output of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated." Several network nodes act as miners, working to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, in Bitcoin, a software client installed on a node performs this validation work on transactions that reference the unspent transaction output (UTXO). Validation may also be performed by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and certain other conditions are met, the transaction is valid and can be written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must be i) validated by the node receiving the transaction, and if the transaction is valid, relayed to other nodes in the network by that node; ii) added to a new block constructed by a miner; and iii) mined, i.e., added to the public ledger of past transactions. A transaction is considered agreed upon when a sufficient number of blocks have been added to the blockchain to make the transaction virtually irreversible.

[0005] Scalability within blockchain protocols, including Bitcoin, is a subject of much debate within the cryptocurrency community. The question of how to enable scaling raises various technical challenges. For example, blockchain networks operate on a "gossip protocol" where all state changes to the ledger are broadcast to all participants, and consensus on the state is agreed upon based on the gossip protocol, meaning that all nodes in the blockchain network must know about all transactions occurring globally. This global tracking of transactions may limit the volume or frequency of transactions in at least some blockchain networks. For example, as is the case at the time of writing, Bitcoin is unlikely to directly replace existing high-capacity electronic payment systems such as Visa®. In fact, executing a Visa® transaction with Bitcoin is expected to consume 400 terabytes of data per year. Many nodes in existing blockchain networks cannot handle this amount of bandwidth and storage.

[0006] To accommodate a larger volume of transactions, off-chain (i.e., off-blockchain) methods known as "payment channels" have been proposed. For example, an off-chain payment channel called the "Lighting Network" is described in "The Bitcoin Lighting Network: Scalable Off-Chain Instant Payments" by Poon and Dryja (January 14, 2016). According to the Lighting Network, value transactions occur off-blockchain. The Lighting Network describes a technique in which previously exchanged off-chain commitment transactions can be broadcast to the blockchain if certain uncooperative or adversarial actions occur after a payment channel has been established. The Lighting Network includes safeguards to remove the incentive for participants to broadcast outdated commitment transactions that do not reflect the current state of the payment channel. For example, if a new commitment transaction is exchanged to update the state of the payment channel (e.g., to transfer value from one participant to another), a secret value associated with the previous commitment transaction is shared from one party to the other. This value may be used in a breach remedy transaction (BRT). More specifically, if a participant node detects that another node is broadcasting an outdated commitment transaction and attempting to get the blockchain to promise the balance reflected in that outdated commitment transaction, the participant node may rather use its value to claim all of its digital assets through the payment channel.Under this breach remedy scheme, commitment transactions are locked, and therefore, the party that generated the signature for the commitment transaction (typically the party broadcasting the commitment transaction to the blockchain network) is required to wait before the digital assets associated with the commitment transaction can be used. For example, the parties may be required to wait 1,000 blocks after broadcasting the commitment transaction before their transaction attempting to consume the digital assets is added to the blockchain. This waiting period allows the counterparty to issue a breach remedy transaction if the commitment transaction does not reflect the current state of the payment channel. [Overview of the project]

[0007] A payment channel is typically configured so that participants can transfer value off-chain, but can also transfer such transfers to the blockchain network if they wish to leave the payment channel. This occurs, for example, when a hub (with which they have a payment channel) becomes unresponsive. However, if a very large number of payment channels fail, the blockchain network may not have the capacity to handle the sudden influx of transactions requested to be written to the blockchain. For example, if a hub the size of the Visa® network fails, the blockchain network may not be able to effectively process all the transactions suddenly broadcast to the blockchain network. Thus, there are serious technical issues related to the network's ability to handle transactions when a network failure occurs and to network resilience.

[0008] For example, if a node broadcasts an outdated commitment transaction (i.e., a commitment transaction that does not reflect the current state of the payment channel) to the blockchain network during such a malfunction, the transaction bottleneck resulting from the malfunction may prevent the breach relief transaction from being added to the blockchain network quickly enough to prevent the outdated commitment transaction from being targeted for breach relief. Thus, the payment channel may be vulnerable to attacks during widespread malfunctions.

[0009] Therefore, there is a need for improved security technologies to establish links or channels between parties for electronic transactions.

[0010] Accordingly, the present invention provides a method as defined in the appended claims. The present invention may be referred to as a security method / system. The present invention may be referred to as an encrypted security method. The present invention can provide resilience in a blockchain network in the event of node failure. The present invention can prevent or at least reduce the possibility of selfish exploitation in such a situation.

[0011] The techniques for setting up off-chain forwarding channels are described below in more detail.

[0012] More specifically, a congress is used during channel setup. A congress is a group of nodes that any node in the blockchain network can join by submitting sufficient stake ("member deposit") to a pool of digital assets associated with the congress ("congress pool"). For example, a node can join the congress by transferring digital assets such as digital currency (such as Bitcoin), tokens, or other stake or value to an account related to the congress. The congress can be secured in part through the decentralized generation of private key shares. Each private key share can be used by its owner to generate a partial signature of a transaction. A threshold signature scheme can be used to generate a valid signature for such a transaction using at least a threshold number of partial signatures. Member deposits are forfeited in case of malicious activity.

[0013] Advantageously, Congress nodes may be configured to implement a fail-safe mode in which such nodes can close (payment) channels if the hub stops operating according to a given protocol. For example, if the hub becomes unresponsive, Congress nodes can implement a fail-safe protocol to close payment channels in a manner that reduces the risk of the blockchain network being overwhelmed by transactions attempting to close channels. For example, Congress may perform batch closures in which multiple payment channels are closed in a single transaction. Furthermore, Congress may stagger closures so that at least some channel closures are delayed.

[0014] Accordingly, the present invention may provide a computer-implemented method. The computer implementation method includes: providing an enclave public key from an enclave associated with a trusted execution environment on a node to a hub; establishing a channel with the hub by broadcasting a funding transaction to the blockchain network that restricts digital assets with a first public key, a second public key, and a third public key, wherein the encumbrance is: 1) both a first signature generated from a first private key corresponding to a first public key and a second signature generated from a second private key corresponding to a second public key; or 2) released by a valid third signature for a third public key, the third public key being associated with a group; receiving a commitment transaction from the hub in the enclave, the commitment transaction being encrypted with the enclave public key; detecting a hub failure; and issuing a fail-safe activation request to the group using data from the enclave based on the commitment transaction.

[0015] The channel may be referred to as a “exchange channel,” “communication channel,” or “payment channel.” For convenience of reference, the term “payment channel” may be used.

[0016] In some implementations, a failsafe activation request specifies the block number of the most recently added block to the blockchain network, and the group is configured to ignore failsafe activation requests that are deemed expired based on the block number specified in the failsafe activation request and the current block number of the most recently added block to the blockchain.

[0017] In some implementations, the method further includes: determining that failsafe mode is not being executed and that the failsafe activation request has expired; and issuing another failsafe activation request to the group, wherein the other failsafe activation request includes a new block number for a new recent block added to the blockchain.

[0018] In some implementations, the step of issuing a failsafe activation request includes a step of automatically posting the failsafe activation request online in response to detecting a hub malfunction.

[0019] In some implementations, the failsafe activation request specifies the fee to be charged by the node that closes the channel.

[0020] In some implementations, the method involves a group deploying a sidechain in response to a fail-safe activation request, and then using the sidechain to exchange value with other nodes.

[0021] In some implementations, failsafe activation requests are generated within the enclave and signed using the enclave private key associated with the enclave public key.

[0022] In some implementations, the method further includes the steps of deciphering the commitment transaction, determining the balance associated with the channel, and determining the value associated with the breach relief transaction. The value is the previous secret value associated with the previous commitment transaction.

[0023] In some implementations, the method further includes the step of broadcasting a sidechain transaction to a miner of the deployed sidechain in response to a fail-safe activation request, and the sidechain transaction transfers value.

[0024] According to the present invention, a method implemented on a computer may be provided. The method implemented on a computer includes: detecting one or more fail-safe activation requests issued by one or more nodes participating in one or more channels with a hub, where a channel allows commitments for value transactions related to a blockchain network to be exchanged outside the blockchain network, and a fail-safe activation request has been issued by a node that previously opened the channel by broadcasting a funding transaction that restricts digital assets with a public key related to the group; verifying that one or more fail-safe activation requests meet a predetermined criterion; and generating a valid signature for a transaction to close one or more channels in cooperation with other nodes in the group.

[0025] As described above, a channel may be referred to as a payment channel, an exchange channel, or a communication channel. For simplicity of reference, the term "payment channel" will be used hereinafter.

[0026] In some implementations, the step of verifying that a fail-safe activation request meets a predetermined criterion includes verifying that the number of fail-safe activation requests weighted by the balance of the individual node that issued such a request exceeds a threshold.

[0027] In some implementations, a fail-safe activation request specifies the individual block number of the block most recently added to the blockchain of the blockchain network when each fail-safe activation request was generated, and the group is configured to ignore fail-safe activation requests that are determined to be expired based on the block number specified in the fail-safe activation request and based on the current block number of the block most recently added to the blockchain.

[0028] In some implementations, the method further includes provisioning a temporary side chain after confirming that one or more fail-safe activation requests satisfy a predetermined criterion and before cooperatively generating a valid signature. The temporary side chain allows for further transfer of value. A transaction that closes one or more channels may also be based on the value transferred in the side chain.

[0029] In some implementations, the processor includes a trusted execution environment and the computer-executable instructions are executed within the trusted execution environment.

[0030] 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 perform the methods described herein.

[0031] 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 the processor to perform the methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] These and other aspects of the invention will be apparent from, and elucidated with reference to, the embodiments described herein. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

[0033] [Figure 1] FIG. 1 shows a block diagram of an exemplary blockchain network.

[0034] [Figure 2]Figure 2 shows a block diagram of an exemplary electronic device that can function as a node in a blockchain network.

[0035] [Figure 3] Figure 3 is a flowchart illustrating an example of how to issue a failsafe activation request.

[0036] [Figure 4] Figure 4 is a flowchart illustrating an example of how to participate in the Congress.

[0037] [Figure 5] Figure 5 is a flowchart illustrating an exemplary method for confiscating digital assets.

[0038] [Figure 6] Figure 6 is a flowchart illustrating an exemplary method for redistributing key shares.

[0039] [Figure 7] Figure 7 is a flowchart illustrating another exemplary method for redistributing key shares.

[0040] [Figure 8] Figure 8 is a flowchart illustrating an example method for returning a deposit.

[0041] [Figure 9] Figure 9 is a flowchart illustrating an exemplary method for implementing a fail-safe mode for payment channels. [Figure 10] Figure 10 is a block diagram of a ghost chain. [Modes for carrying out the invention]

[0042] Blockchain network First, refer to Figure 1, which shows an exemplary blockchain network 100 related to blockchain in the form of a block diagram. The blockchain network may be a public blockchain network, which may be a peer-to-peer open membership network that anyone can join without invitation or consent from other members. Distributed electronic devices running an instance of the underlying blockchain protocol on which the blockchain network 100 operates can participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol.

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

[0044] Nodes 102 of the blockchain network 100 are connected to each other using appropriate communication technologies, which may include wired and wireless communication technologies. Such communication adheres to protocols associated with the blockchain network. For example, if the blockchain is a Bitcoin blockchain, the Bitcoin protocol may be used.

[0045] Node 102 maintains a global ledger of all transactions on the blockchain. Therefore, the global ledger is a distributed ledger. Each node 102 can store a complete or partial copy of the global ledger. In the case of a proof-of-work blockchain, transactions by node 102 that affect the global ledger are verified by other nodes 102 to ensure the validity of the global ledger. If the blockchain is a proof-of-work blockchain, blocks are also verified by examining the proof-of-work submitted with the block.

[0046] At least some of the nodes 102 act as miners 104 of the blockchain network 100. The blockchain network 100 in Figure 1 may be a proof-of-work blockchain where miners 104 perform costly computations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve cryptographic problems. In Bitcoin, miner 104 discovers a nonce such that the block header hashs to a number smaller than a value defined by the current difficulty using SHA-256. The hash power required for a proof-of-work algorithm means that after a predetermined number of blocks have been mined over a transaction, the transaction is considered virtually irreversible. The miner 104 that solves the cryptographic problem creates a new block for the blockchain and broadcasts that new block to the other nodes 102. The other nodes 102 verify that miner 104 has shown sufficient proof-of-work before accepting that miner 104 has indeed solved the cryptographic problem and therefore the block should be added to the blockchain. The block is added to the blockchain (i.e., the distributed global ledger) by consensus of node 102.

[0047] As an alternative to Proof-of-Work, Blockchain Network 100 may instead be a Proof-of-Stake blockchain network. A Proof-of-Stake blockchain network provides an alternative mechanism for achieving consensus. In a Proof-of-Stake blockchain network, the blockchain is secured by proof-of-stake rather than proof-of-work. Under Proof-of-Stake, miners deposit a security deposit of digital assets, and the probability of being selected as a node to mine blocks is proportional to the amount of digital assets provided as security deposit. A Proof-of-Stake blockchain system can be used to avoid the computational costs and energy required to mine on a Proof-of-Work blockchain. Furthermore, a Proof-of-Stake blockchain may enable more frequent and regular block creation than a Proof-of-Work blockchain.

[0048] A block created by miner 104 contains transactions that were broadcast to the blockchain by node 102. For example, a block may contain a transaction from an address associated with one of the nodes 102 to an address associated with the other node 102. In this way, a block functions as a record of transactions from one address to another. Those who request that transactions be included in a block prove that they are authorized to initiate a transfer (for example, to use Bitcoin in the case of Bitcoin) by signing the request with their private key corresponding to their public key. A transfer can only be added to a block if the request is validly signed.

[0049] In the case of Bitcoin, there is a one-to-one correspondence between a public key and an address. That is, each public key is associated with a single address. Therefore, in this specification, transferring digital assets to or from a public key (e.g., a payment to a public key) and transferring digital assets to or from an address associated with that public key refer to the same operation.

[0050] Some nodes within the blockchain network (102) do not function as miners, but instead can participate as verification nodes. Transaction verification may include verifying signatures, verifying references to valid UTXOs, and so on.

[0051] The example in Figure 1 includes five nodes 102, two of which participate as miners 104. In reality, the number of nodes 102 or miners 104 can vary. In many blockchain networks, the number of nodes 102 and miners 104 can be much larger than the number shown in Figure 1.

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

[0053] Congress 110 may be an open membership group, in which any node 102 can participate by contributing sufficient stake to the pool associated with Congress 110. For example, a node can participate in Congress by transferring digital assets such as digital currency (e.g., Bitcoin), tokens, or other stake or value to an account associated with Congress 110 (e.g., to a group public address or group public key). Nodes 102 participating in Congress may be any node in the blockchain network, including both mining nodes and non-mining nodes.

[0054] Congress 110 can be used to facilitate the setup of off-blockchain payment channels 120a,120b between nodes. This off-blockchain payment channel may be referred to herein as an off-chain payment channel, off-chain channel, or payment channel. The payment channel allows for the exchange of value off the blockchain. The payment channel allows the channel state of the payment channel (i.e., the net account of the individual nodes involved in the payment channel) to be committed to the blockchain at any time. That is, the parties can transfer value in multiple off-blockchain transactions and can update the blockchain at any point in time to reflect the current channel state of the payment channel.

[0055] In this embodiment, the first payment channel 120a is established between two nodes, the first node 102a and the second node 102b, and the second payment channel 120b is established between two nodes, the first node 102a and the third node 102c. However, in practice, payment channels may be established between nodes, or a different number of payment channels may be established. Payment channels 120a and 120b may be established in a hub-and-spoke (HAS) configuration, in which a central hub (e.g., the first node 102a in this example) establishes payment channels with both the second node 102b and the third node. This HAS configuration allows any node connected to the hub to transfer value off-chain to any other node connected to that hub, or to receive value off-chain from any other node connected to the hub. For example, the second node 102b can transfer value off-chain to the third node 102c or receive value from the third node. The hub may be connected to more nodes than shown in Figure 1. Furthermore, a hub or non-hub node associated with one payment channel can establish other payment channels with other hub or non-hub nodes.

[0056] During the setup of a payment channel, each node associated with payment channel 120 (for example, in the illustrated example, the first node 102a and the second node 102b for the first payment channel 120a, and the first node 102a and the third node 102c for the second payment channel 120b) locks digital assets in a special way that funds the payment channel. After setup is complete, these digital assets may be allocated using a commitment transaction and an exchange of “value” that effectively invalidates previous commitment transactions. More specifically, a payment channel allows nodes associated with the payment channel to exchange commitment transactions. A commitment transaction is a transaction exchanged by nodes without (initial) broadcasting to the blockchain network. A commitment transaction provides a ledger that determines the allocation of digital assets associated with the payment channel. This allocation may be called the channel state. A commitment transaction can be broadcast at any time by one of the nodes associated with the payment channel. Commitment transactions may operate as described in the following document: Poon and Dryja in “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, January 14, 2016 (hereinafter “the Lightning Network”). However, payment channels may be configured in a different manner than described in the Lightning Network. More specifically, a group of nodes referred to herein as the Congress may be involved in a setup protocol that allows the group of nodes to assist in the event of a failure in the payment channel. Such a failure may result, for example, from a hub failure. Protocols for configuring payment channels, including failsafe modes provided by the Congress and the protocol to implement failsafe modes, are described in more detail below.

[0057] Electronic devices that operate as nodes Figure 2 is a block diagram showing the components of an exemplary electronic device 200 that could function as a node 102 (Figure 1) of a peer-to-peer blockchain network 100 (Figure 1). The exemplary electronic device 200 is also called a processing device. Electronic devices can take various forms, including, for example, desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or other types of forms.

[0058] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components can be directly or indirectly coupled to each other and can 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 containing machine-readable instructions and data for performing 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 perform the methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to perform protocols related to the blockchain network 100 (Figure 1). For example, the instructions may include instructions for implementing the Bitcoin protocol.

[0059] Memory 220 can store the global ledger of the blockchain network 100 (Figure 1) or a portion thereof. That is, memory 220 can store all or a portion of the blocks of the blockchain, for example, the most recent block, or a portion of the information in several blocks.

[0060] Although memory 220 is shown as a single block in Figure 2, the electronic device 200 may actually contain multiple memory components. The memory components may be of various types, including, for example, RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. Furthermore, although memory 220 is shown separately from the processor 210, the processor 210 may include internal memory.

[0061] As shown in Figure 2, the processors 210 of some nodes 102 (for example, nodes forming Congress 110 and / or nodes participating in a payment channel that provides a fail-safe mode as described herein) may include a secure area such as a Trusted Execution Environment (TEE) 250. The TEE 250 is an isolated execution environment that provides additional security to the electronic device 200, such as isolated execution, trusted application integrity, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded within the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 may also be used to protect the integrity and confidentiality of critical resources such as keys. The TEE 250 is implemented at least partially at the hardware level, and as a result, instructions and data executed within the TEE 250 are protected from access and manipulation by external parties such as the rest of the electronic device 200 and the owner of the electronic device. Data and calculations within the TEE 250 are protected from anyone operating the node 102 containing the TEE 250.

[0062] TEE250 may operate by instantiating an enclave while hashing cumulatively, adding one page of memory at a time. A similar operation may also be performed on a remote machine (which may be a developer machine or another machine) so that the remote machine determines and stores the expected hash. Thus, the contents of the enclave can be verified by any remote machine to ensure that the enclave is running an approved algorithm. This verification may be performed by comparing hashes. Once the enclave is fully constructed, it is locked down. It is possible to execute code on TEE250 and send secrets to the code, but the code cannot be modified. The final hash may be signed with an authentication key, allowing the data owner to verify it before sending any secrets to the enclave.

[0063] A TEE250 used by a node functioning as a Congress member may be used to protect the confidentiality and integrity of private key shares associated with the Congress public key used by Congress 110 (Figure 1). For example, a TEE250 may be used for generating and storing private key shares. A TEE250 is intended to ensure that no member can directly obtain information about private key shares held within a TEE250 enclave, or any other private key shares, through member-to-member or enclave-to-enclave communication. The Congress protocol is also robust against compromises in the TEE threshold. Furthermore, a TEE250 may enable remote attestation, which can be used by node 102 (Figure 1), to prove to other nodes 102 that the TEE250 is authentic and is executing computer executable instructions approved with respect to the protocol implemented by Congress 110 or the payment channel. Remote authentication may be provided by the TEE250 by sending a hash of a code that executes a specific code portion and is signed internally to the enclave by the enclave's internal authentication key (which may be referred to herein as the enclave private key).

[0064] A TEE250 provided by a node functioning as a congress member may be used to certify the deletion of a private key share if a member of congress 110 who previously used a private key share on an electronic device 200 chooses to leave the congress. The electronic device 200 can provide authentication of deletion to other congress members via a remote authentication protocol provided in the TEE250. Proof of deletion may be required before a member is allowed to withdraw their member deposit. That is, the return of the deposit may be conditional on authentication of the deletion of the private key share held within the member's enclave.

[0065] The TEE250 provided by nodes participating in payment channels 120a,120b with the hub (Figure 1) may be used to allow the hub to verify (e.g., by remote certification) that the node is executing existing approved code. Furthermore, the TEE250 enclave stores an enclave private key associated with an enclave public key that may be provided to the hub. The hub may use the enclave public key to send encrypted messages to the enclave. These encrypted messages may contain one or more commitment transactions and one or more values ​​that can be used in a breach remedy transaction (BRT), that is, the values ​​that effectively invalidate the outdated channel state. The commitment transactions and values ​​may be decrypted by the enclave and provided to other components, systems, or subsystems of the node (e.g., the node's main processor). The TEE, more specifically the TEE250 enclave, may also be used to generate a failsafe activation request in the event that the payment channel hub becomes unresponsive. As will be explained in more detail below, a fail-safe activation request may be generated based at least in part on data stored in the enclave. For example, a fail-safe activation request may be generated based on the latest channel status (reflecting the current balance of digital assets in the payment channel). A fail-safe activation request may also include other information, such as the most recent block added to the blockchain of the blockchain network, and a statement of the fees to be paid to Congress in exchange for closing the channel. The fail-safe activation request is signed by the enclave using the enclave private key so that it can be verified as having been provided by the enclave.

[0066] The TEE250 may be equipped with an internal secure random number generator for the TEE enclave, which can be used to generate private keys, random challenges, or other random data. The TEE250 may also be configured to read data from external memory and to write data to external memory. Such data may be encrypted with a secret key that is kept only within the enclave.

[0067] TEE250 can be implemented using various platforms such as Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). For example, SGX supports remote authentication, which allows an enclave to retrieve signed statements from the processor running a particular enclave, along with a given hash of a member known as a quote. Third-party authentication services, such as Intel Attestation Service (IAS), can prove that these signed statements are derived from a genuine CPU compliant with the SGX specification.

[0068] Nodes acting as congress members, and nodes acting as non-hub participants in payment channels, may include TEEs, but at least some nodes acting as hubs may not have TEE250. In other words, nodes acting as payment channel hubs are not required to operate TEEs to participate in (and be protected by) fail-safe mode.

[0069] The electronic device 200 functions as a node 102 (Figure 1) in the blockchain network 100 (Figure 1). Several nodes may participate in or become members of a Congress 110. The Congress 110 is formed when a group of digital asset holders pool digital assets such as digital currency, tokens, or other shares or values ​​supported by the blockchain network 100 (Figure 1). The Congress may implement fail-safe modes related to payment channels, for example. For example, if a hub fails, the Congress may trigger a fail-safe mode to facilitate the sequential closure of payment channels and / or facilitate another off-chain transfer of value (i.e., off-mainchain transfer of value).

[0070] Some nodes can participate as non-hub participants in a payment channel. Such nodes can, for example, set up payment channels with the hub or with other non-hub participants. Techniques for setting up payment channels are described below, as are techniques for implementing fail-safe modes in case of failure of the hub or payment channel.

[0071] Other nodes do not have to participate as non-hub participants or act as congress members. Instead, such nodes may function as one or more miners, validators, or hubs, or provide other functions related to the blockchain network.

[0072] Participation in payment channels and handling of channel malfunctions Next, referring to Figure 3, a method 300 for joining a payment channel and addressing channel failures is shown. Method 300 may be executed by a node 102 of the blockchain network. Such a node 102 may include computer-executable instructions stored in memory 220 (Figure 2) that implement method 300. When such instructions are executed by a processor 210 (Figure 2), they cause node 102 (such as an electronic device 200 of the type described with reference to Figure 2) to execute method 300.

[0073] In Operation 302, the enclave associated with TEE250 (Figure 2) on the node performing Method 300, and more specifically on node 102 performing the Method, provides the enclave public key to the hub to be included in the payment channel. The enclave public key is a public cryptographic key associated with the enclave private key, which is securely stored in the enclave. The enclave public key allows the hub to communicate directly with the enclave; that is, the hub uses the enclave public key to encrypt its communications to the enclave.

[0074] The enclave public key may be provided directly to the hub by the node executing the method, or it may be provided to the hub by including the enclave public key as metadata in the funding transaction referenced below in relation to operation 304. Thus, although operations 302 and 304 are shown using separate blocks in the flowchart of Figure 3, operation 302 may be performed as part of operation 304 of method 300 in Figure 3.

[0075] In Operation 304, the node performing Method 300 establishes (i.e., sets up) a payment channel with the hub. More specifically, the payment channel may be set up by broadcasting a funding transaction to the blockchain network that restricts digital assets with a first public key, a second public key, and a third public key, thereby removing the restriction on the digital assets by 1) a first signature generated from a first private key corresponding to the first public key and a second signature generated from a second private key corresponding to the second public key; or 2) a third signature valid for the third public key alone. The third public key is a public key associated with a group such as Congress 110 (Figure 1). For example, the third public key may be a group public key (which may be referred to as a Congress public key). The first public key is associated with the node performing Method 300, and the second public key is associated with other nodes, such as the hub, which are participants in the payment channel to be set up.

[0076] Thus, a funding transaction is configured so that the two parties to the payment channel can mutually remove restrictions on the digital assets associated with the funding transaction, or so can a Congress operating independently remove the restrictions. That is, a funding transaction is configured so that restrictions can be removed in one of two ways: If the parties to the payment channel wish to cooperate, the restrictions can be removed if they both use their respective private keys (i.e., the first public key and the private key associated with the second public key) to generate signatures for a transaction consuming the restricted digital assets. Under this scenario, their valid signatures together remove the restrictions. The second way restrictions can be removed is by multiple members of a Congress cooperating to generate valid signatures on behalf of the Congress according to a threshold signature scheme. Threshold signature schemes are described in detail in the detailed discussion of Congress. Generally, threshold signature schemes require the coordination of a number of Congress member nodes controlling at least a threshold number of key shares. Because Congress is protected by the deposit of its shares, if it acts contrary to the Congress Protocol, Congress member nodes are at risk of forfeiting their shares. For example, if a Congress member contributes a partial signature to a transaction that effectively steals digital assets related to the funding transaction of Operation 304, the Congress member is at risk of having their deposit revoked by honest Congress members who control at least a threshold number of key shares.

[0077] As described above in the description of Operation 302, the funding transaction broadcast in Operation 304 of Method 300 may include a public key associated with the TEE of the node executing the Method as metadata for the funding transaction. For example, an enclave public key may be specified as metadata in the funding transaction.

[0078] After setting up a payment channel, the node executing Method 300 is connected to the hub by the payment channel, which forms one spoke of a hub-and-spoke payment network and can exchange value with other nodes connected to the hub by other "spokes," and, if necessary, with the hub itself. For example, a node can now transfer value off-chain with other non-hub nodes by transferring tokens (in Operation 306) through the hub. More specifically, value can be transferred by exchanging one or more "values" that invalidate previous commitment transactions and the commitment transactions with the hub. Commitment transactions can be received in encrypted form in the enclave of the node executing Method 300. For example, the received commitment transaction may be encrypted with the enclave public key, thereby keeping the commitment transaction secure within the enclave. Thus the enclave can see all commitment transactions sent by the hub and is therefore always aware of the latest channel state. The enclave can decrypt commitment transactions, verify the balances associated with the channel, and verify the values ​​associated with breach relief transactions. This value is a previous secret value associated with a previous commitment transaction, and it can be used in a breach remedy transaction if the counterparty (such as a hub) violates the protocol by attempting to broadcast an outdated commitment transaction to the blockchain network.

[0079] Commitment transactions can generally be exchanged in the manner described in the writing network. Commitment transactions can be exchanged with a value that effectively invalidates the previous channel state; that is, the value effectively renders older commitment transactions unavailable. Any attempt by a dishonest participant to broadcast an old (i.e., not current) commitment transaction proves unwise, because the value that invalidates the previous channel state can be used by an honest participant to penalize the dishonest participant (for example, by claiming all the funds in the channel).

[0080] As long as the payment channel continues to function as intended, it can be closed at any time by mutual agreement of the parties to the payment channel. It should be recalled that the funding transaction used to fund the payment channel was configured so that both parties to the payment channel (e.g., the node and hub implementing Method 300) could remove the restrictions on the digital assets by cooperating in a 2-of-2 multi-signature protocol. Thus, these nodes could cooperate to generate their respective signatures for a transaction that would close the payment channel and redistribute the digital assets previously restricted by the funding transaction. In other words, these nodes could easily redistribute funds in a manner that takes into account the current state of the payment channel, without necessarily having to rely on a commitment transaction. However, if the other party becomes uncooperative and refuses to sign such a transaction, a commitment transaction may be required.

[0081] As mentioned above, payment channels may fail under certain circumstances, which can be detected in Operation 308. For example, a hub may fail, and such a failure can be detected by a node in Operation 308. A hub failure can be detected, for example, if the hub fails to provide the enclave with the expected commitment transaction in response to a request to update the channel.

[0082] In response to detecting a hub failure, a node may issue a failsafe activation request to a group (i.e., a group or congress associated with a third public key) in Operation 310. The failsafe activation request may also be issued to the group by automatically sending the failsafe activation request online in response to detecting a hub failure. For example, the failsafe activation request may be submitted to a web server that acts as a central repository for failsafe activation requests and is configured to be monitored by member nodes of the group. The failsafe activation request may be generated within an enclave and signed using an enclave private key associated with an enclave public key. The failsafe activation request is issued to the group using data from the enclave. For example, the data used to generate the failsafe activation request may be based on commitment transactions received during Operation 306. For example, the failsafe activation request may include a signed statement of the current state. The current state of a payment channel is its balance, and this status, condition, or balance determines the allocation of digital assets, taking into account recent commitment transactions associated with the payment channel.

[0083] A failsafe activation request may also contain other information. For example, a failsafe activation request may specify a fee to be paid by a node to close a payment channel. A failsafe activation request may also contain freshness data, such as a timestamp. The timestamp or other freshness data may specify the date and / or time the failsafe activation request was generated or issued by the TEE. Alternatively, the timestamp may specify the block number of the most recent block added to the blockchain of the blockchain network. A group of nodes processing failsafe activation requests may be configured to ignore failsafe activation requests that are deemed expired based on the timestamp. For example, if the timestamp is expressed as the most recent block number, the group may ignore failsafe activation requests that are deemed expired based on the block number specified in the failsafe activation request and the current block number of the most recent block added to the blockchain. That is, the group may evaluate the freshness of a failsafe activation request based on the number of blocks that have elapsed since the failsafe activation request was issued.

[0084] A node performing Method 300 may be configured to reissue a failsafe activation request (in Operation 314) if it has expired (as determined by the node in Operation 312), and if failsafe mode is not being executed, and the payment channel has not been provisionally restored. That is, if a group is not executing failsafe mode and the payment channel remains unenforceable, an expired failsafe activation request may be reissued in Operation 314. More specifically, another failsafe activation request may be issued to the group. The other failsafe activation request includes new freshness information, such as the block number for the newest block added to the blockchain.

[0085] After failsafe mode is activated by Congress (in response to observing sufficient failsafe activation requests, as will be described in detail below), Congress can close the payment channel. For example, Congress nodes can coordinate to generate signatures for transactions affecting restricted digital assets in Operation 304. The signatures are valid against the third public key described above in the description of Operation 304; that is, the signatures are valid against the group / Congress public key that restricted the digital assets. Since the payment channel was configured to allow Congress to assume control over the assets included in the funding transaction, if the payment channel fails, Congress can facilitate closing the transaction.

[0086] In at least some examples, a temporary sidechain may be deployed in response to a failsafe activation request (and more specifically, in response to a sufficient number of failsafe activation requests to trigger a failsafe mode) before the channel is closed by broadcasting a closing transaction to the blockchain network. A temporary sidechain may also be referred to as a ghost chain, which will be described in detail below. A temporary sidechain may be used by a node in operation 316 of method 300 to exchange value with other nodes via the sidechain (e.g., to transfer or receive). For example, a node can transfer value to another node by broadcasting a sidechain transaction to the miners of a sidechain deployed in response to a failsafe activation request. A sidechain transaction transfers value to or from another node; that is, a sidechain transaction effectively updates the balance of digital assets associated with a node. A sidechain may be used to transfer or receive value via other “spokes” (i.e., other payment channels) with other nodes that previously established a payment channel with the failed hub. Therefore, the sidechain allows nodes that were previously connected to the hub to continue trading with each other, while they wait for their respective channels to be closed. No further requests to close channels are required after the failsafe is activated; all channels that issued a failsafe activation request are closed when the sidechain terminates.

[0087] If a sidechain is deployed, a node may subsequently issue a request to the Congress to assume the state of the payment channel to the main blockchain (which may also be referred to as the main chain). The nodes in the Congress can then coordinate to generate a valid signature to close any sidechain transactions that affect the balance. Thus, if a payment channel fails (for example, due to a hub failure), a group of nodes that are members of the Congress may cooperate to facilitate the closing of the payment channel. The Congress and its various functions are described in detail below.

[0088] Congress and Threshold Signatures Congress 110 may be a group of authorized or unauthorized nodes 102 operating on a blockchain network. That is, any node 102 (Figure 1) in the blockchain network 100 (Figure 1) (for example, any node that monitors and stores at least some of the information in the blockchain) can join Congress 110. To join Congress 110, a 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, associated with other members of Congress). This digital asset pool may be referred to as the Congress Pool. For example, a 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 called a public group address). The digital assets are under the management of a group threshold signature by a single public key called the Congress Public Key. Congress members hold private key shares generated by distribution (i.e., private key shares generated by various nodes that hold such private key shares). The number of shares held may be proportional to the amount deposited in the pool.

[0089] Digital assets managed by Congress 110, including any digital assets transferred to the Congress address (i.e., the Congress Public Key, which is the public key associated with Congress), are subject to the management of a threshold signature scheme. Under the threshold signature scheme, member groups whose total private key holdings exceed a threshold are required to generate a valid signature that allows digital assets to be transferred away from the management of Congress 110. That is, at least a threshold number of private key shares must be used to generate a valid signature for any outgoing transfer of digital assets managed by Congress 110.

[0090] The Congress Public Key restricts digital assets deposited in the Congress Pool by members of Congress 110 in exchange for private key shares, and any digital assets deposited in addresses associated with the Congress Pool by members and non-members of Congress 110 for reasons other than acquiring private key shares (i.e., restricted by the Congress Public Key) (i.e., placed under the full, partial, or conditional control of Congress). Non-members or members may restrict digital assets with the Congress Public Key for various reasons. For example, as described above with reference to Figure 3, a funding transaction for a payment channel may restrict digital assets using the Congress Public Key. By restricting such digital assets (i.e., digital assets used to open a payment channel) with the Congress Public Key, Congress can implement a fail-safe mode in the event of a payment channel failure (e.g., if the hub associated with the payment channel becomes unresponsive).

[0091] Since the same Congress Public Key may restrict both member deposits (i.e., digital assets provided by Congress members in exchange for private keys) and digital assets provided by members or non-members for other purposes, at least some deposits to the Congress Public Key may be signaled with a special flag to indicate the type of deposit. For example, a transaction transferring digital assets to a Congress address may include a flag, identifier, or other attribute indicating the nature of the deposit made. For example, a transaction transferring digital assets to a Congress address that is not intended to participate in the Congress or increase the amount of contribution to Congress membership may include a special identifier indicating that the deposit is being made for another purpose. Such identifiers may be used by node 102 associated with Congress 110 when managing private key share generation (as described in detail below). More specifically, a node 102 that deposits / restricts digital assets for the purpose of joining the group will be allocated a private key share relating to Congress 110 (as a result of depositing the digital assets), while other nodes 102 that restrict digital assets for other purposes (e.g., to open a payment channel) may not hold a Congress private key (i.e., the equivalent of a Congress public key) relating to Congress.

[0092] Congress110 may behave as an autonomous group where cooperative behavior is coerced by the threat of forfeiting all or part of a member's deposit. Uncooperative or malicious members may have such digital assets forfeited by participation in cooperative protocols by a majority of honest members. Furthermore, if a Congress member wishes to leave Congress110, they can withdraw their member deposit (i.e., require Congress110 to transfer the member's deposit back to that member's personal address). However, withdrawal of funds will only be carried out if a number of private key shares exceeding the threshold required to generate a valid digital signature are used by the TEEs (i.e., Congress) associated with the group's members to generate a partial signature to authorize the withdrawal.

[0093] The threshold signature schemes implemented by Congress 110 can be of various types. A threshold signature scheme allows for the distribution of signing authority among n parties, insofar as at least a threshold number of private key shares contribute to generating a valid signature. Any subset smaller than the threshold cannot generate a valid signature, nor can it generate any useful information about the signature. More specifically, each party manages a share of the private signing key, and a threshold number of key shares must be used to generate a valid signature through a combination of partial signatures. Any subset of key shares below the threshold cannot generate a valid signature through a combination of partial signatures.

[0094] The threshold signature scheme may be an elliptic curve digital signature algorithm (ECDSA) scheme. For example, the ECDSA scheme may be of the type proposed by Ibrahim et al. in the following document: “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”, 2003 EIII 46th Midwest Symposium on Circuits and Systems, 1:276-280 (2003). This threshold signature scheme is an extension of the digital signature scheme, which is an elliptic curve cryptography-based algorithm, requiring t+1 key shares from n key share holders to reconstruct the private key. This scheme can be used to construct a valid signature without the need to reconstruct the private key, and without anyone needing to reveal their key shares to others.

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

[0096] Ibrahim et al.'s ECDSA model is robust against halting adversaries (t <= n / 3). A halting adversary can either allow the acquired party to join the protocol or withdraw from it midway.

[0097] This ECDSA scheme includes various mechanisms that can be used by node 102 to identify malicious or uncooperative individuals. For example, verifiable secret sharing (VSS) can be used to share the polynomials required for Shamir's secret sharing (SSS). SSS is a form of secret sharing in which the secret is divided into multiple parts, each participant receiving their own unique portion. These parts can be used to reconstruct the secret. VSS can be used by node 102 to identify a malicious node 102 or member if conflicting shares are provided to different nodes 102, or if a share is secretly sent to a node different from a blind share broadcast to all nodes. Conflicting shares can be identified by any of the nodes 102. Secret sharing can be made verifiable by including auxiliary information that enables node 102 to verify their respective shares as consistent.

[0098] The transmission of erroneous shares to individual nodes (i.e., shares different from the broadcasted blind shares) can be identified by the intended receiving node of that share. Identification of erroneous shares sent secretly to nodes can be made publicly verifiable using Publicly Verifiable Secret Sharing (PVSS) techniques. Such techniques can avoid the possible delays in identifying the rogue sender that may occur when PVSS is not used and the recipient of the erroneous share is offline or disconnected from a significant portion of the network when the erroneous share is transmitted.

[0099] Inappropriate behavior, such as providing incorrect shares to different nodes, can be addressed by Congress 110 to deter malicious activity. For example, if node 102 (Figure 1) is identified as malicious by other nodes 102, a number of nodes 102 exceeding a threshold (e.g., t+1) (i.e., nodes associated with Congress members) can cooperate to penalize the malicious party. For example, node 102 can take action regarding digital assets (e.g., digital currency, tokens, or other stake or value) deposited with Congress by a malicious party. For example, Congress can burn digital currency, tokens, stake, or value by moving them to an unspendable address, or it can confiscate such digital assets by reaching an agreement not to allow their return to the malicious party. Furthermore, node 102, which is not a node that is behaving erroneously, can also stop the erroneous behavior by cooperating to eliminate the node that is behaving erroneously (for example, by effectively disabling key sharing; for example, by excluding the node from participating in the Congress protocol, or by resharing the private key and not assigning a share to the node that is behaving erroneously).

[0100] The ECDSA technology described above can be enhanced by the use of TEEs. For example, the threshold ECDSA signature technology based on Ibrahim et al. assumes a powerful form of adversary, here referred to as the Byzantine adversary. This type of adversary may act tyrannically, for example, by refusing to participate in or stopping the signing process midway, or by pretending to participate honestly and sending false information. However, additional security can be provided by using TEEs and generating the data used for signing within the TEE enclave where the secret private key share is stored, because the likelihood of numerous enclaves being compromised is extremely low. If each TEE is assigned only one key share, then, for example, the number of potentially compromised TEEs can be reasonably expected not to approach the robustness threshold against the Byzantine adversary, assuming n is sufficiently large. This allows the protocol to be secure if it is resistant to a small number of malicious adversaries relative to the total number of key shares.

[0101] For example, if all nodes in a congress possess a TEE, acquiring the secrets stored in the enclave would only be possible with physical access to the nodes and with considerable effort and expense, unless the TEE's producer is acquired. Such a producer-level acquisition would be relatively easy to handle. For instance, if a producer falsely claims that many public keys correspond to a true TEE, they could gain direct access to private key shares and potentially launch an attack. However, such an attack would require a sufficient number of key shares to allow the producer to generate valid signatures without the support of other nodes. This would mean accumulating a large portion of the total stake, which could be prohibitively expensive. Furthermore, carrying out such an attack would inevitably result in the loss of a significant portion of the value of their enormous holdings.

[0102] When a TEE is used, it is useful to consider the protocol's robustness against a "corrupted node." A corrupted node is one in which the external hardware of the TEE is damaged, but the integrity of the TEE itself is not compromised. A corrupted node may have control over which information the enclave receives and which it does not. In particular, a corrupted node may shut down, i.e., it may refrain from participating in the protocol. If the information provided to the protocol is required to be signed by a private key kept secret in the enclave (the corresponding public key is authenticated during the authentication process), the private key is as trustworthy as the enclave itself. Therefore, a corrupted node cannot send arbitrary (authenticated) information to the protocol and can only attempt to disrupt it by shutting down the enclave or attempting to deceive the enclave into operating improperly, for example by providing outdated information. As a result, with respect to a corrupted node, a successful attack requires collecting a sufficient number of partial signatures to generate a complete signature. Regarding TEE, the protocol by Ibrahim et al. is robust to 2t of damaged nodes. Since a signature can be generated when n-2t >= 2t+1, it is sufficient to have a qualified subset of key shares of size 2t+1 <= (n+1) / 2. Therefore, when TEE is used, the threshold of the threshold signature scheme can be set to a number greater than or equal to 50% of the key shares in order to generate a valid signature in the presence of damaged nodes.

[0103] Other threshold signature schemes may be used. For example, the threshold signature scheme may be an ECDSA threshold scheme of the type proposed in the following document: Goldfeder et al., “Securing Bitcoin Wallets Via a New DSA / ECDSA threshold signature scheme”, (2015). This protocol allows t+1 parties to generate a valid signature. As a result, the number of key shares that an adversary must control to generate a valid signature is equal to the number of key shares that the adversary must own to reconstruct the private key. This technique can provide an efficient scheme when unanimity is required to generate a valid signature. In most common cases, this scheme imposes space requirements that increase exponentially with the number of congress members because, for any threshold, the entire protocol must be repeated for any possible subset of t+1 players out of n. Therefore, if both n and t are large values, 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, digital assets can be locked using multi-signatures, such that each private key is divided into multiple shares. This technique would make large-scale congresses more efficient in terms of space requirements. Scaling characteristics can also be improved by iteratively configuring schemes for a large number of participants, starting from smaller party sizes and at multiple levels. For example, threshold signature schemes can be combined with the techniques described in the following literature: Cohen et al., Efficient Multiparty Protocols via Log-Depth Threshold Formulae (2013), Advances in Cryptology - CRYPTO 2013 pp 185-202.

[0104] Other thresholding schemes, including non-ECDSA signature schemes, may be used. For example, a thresholding scheme based on the Schnorr scheme may be used by node 102 to implement Congress 110.

[0105] Node 102 in the blockchain network 100 (Figure 1) can implement the Congress Protocol based on a selected threshold signature scheme. Such a node 102 may include computer-executable instructions stored in memory 220 (Figure 2) that implement the Congress Protocol. When such instructions are executed by a processor 210 (Figure 2), they cause node 102 (such as an electronic device 200 of the type described with reference to Figure 2) to execute one or more methods of the Congress Protocol. Such methods may include any one or a combination of methods 400, 500, 600, 700, 800, and 900 in Figures 4-9. Thus, the Congress Protocol may include one or more of methods 400, 500, 600, 700, 800, and 900 in Figures 4-9. This method may be executed by a node cooperating with other nodes associated with other Congress members.

[0106] Joining the Congress Next, refer to Figure 4, which shows method 400 for joining a congress. This method can be performed to join an existing congress; that is, method 400 may be used to join a congress that has been started previously.

[0107] Method 400 in Figure 4 includes obtaining a Congress Public Key in Operation 402. The Congress Public Key may be obtained from an existing member of the Congress, or from a third party, including, for example, a third-party system operating outside the blockchain network 100 (Figure 1). For example, the Congress Public Key may be obtained from a public web server accessible via the public internet. As a further example, the Congress Public Key can be monitored on the blockchain; for example, it may be monitored based on metadata contained in at least a number of transactions that transfer digital assets to the Congress Public Key.

[0108] Node 102, executing Method 400, makes a payment to the Congress Public Key in Operation 404 by broadcasting a transaction of digital assets from a private account associated with Node 102 to the Congress address (i.e., the address associated with the Congress Public Key). More specifically, Node 102 broadcasts a transaction to transfer one or more digital assets to the Public Group Address associated with the Congress Public Key. The Public Group Address is the address of the Congress Pool. The Congress Pool contains other digital assets related to other members of the Congress. Thus, the transaction in Operation 404 is first added to a block by Miner 104 (Figure 1), and after the block is confirmed, it is transferred to the Congress Pool, which contains digital assets from other members. The Public Group Address can receive transfers from both those who wish to join the Congress and those who do not wish to join the Congress. Those who do not wish to participate in the Congress may transfer their digital assets to the Congress Pool, thereby allowing such digital assets to be managed in whole, partially, or conditionally using the threshold signature scheme used by the Congress. For example, as described above with reference to Figure 3, the Congress Public Key can restrict the digital assets associated with funding transactions that open payment channels.

[0109] Transactions in Operation 404 may include flags, identifiers, or other attributes indicating that the person transferring the digital assets wishes to participate in the Congress and that the deposit is being made for such purposes.

[0110] After depositing digital assets into the Congress Pool, node 102, which is executing method 400, receives the private key share in operation 406. Next, node 102 regenerates the private key share in operation 408 by executing a single instance of the protocol. The generation of the private key share may be performed within the TEE of node 102.

[0111] In Operation 408, Node 102 generates private key shares to be used in a threshold signature scheme, which requires that at least a threshold number of private key shares be used to generate valid signatures for transactions on behalf of Congress. Other holders of private key shares are other members of Congress who participate in Congress in permitted or unauthorized ways by transferring their digital assets to a public group address.

[0112] In Operation 407, existing congress members can cooperate to update the key share in order to regenerate the private key share. For example, node 102 can use a random polynomial f of degree t with zero constant term. 0 n+1 (x) can be generated. Then node 102 can generate point f 0 n+1 (n+1) can be calculated and set as their private key share. Then node 102 can use this polynomial (i)f 0 n+1The points in (i) can be allocated to each of the existing congress members (i=1,...,n). Then, each existing congress member (i=1,...,n) adds the received value to its existing private key share in order to obtain a new private key share. Now node 102 has the same private key share as all other members, and the corresponding public key remains unchanged. As described above, the threshold signature scheme may be of various types, including threshold schemes based on the elliptic curve digital signature algorithm or the Schnorr scheme.

[0113] A private key share can be generated within TEE250 (Figure 2) and securely stored on node 102. For example, the private key share may be stored in TEE250.

[0114] After each node has generated a private key share, 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) may be transferred to a new Congress Public Key associated with the new private key share (through the cooperation of enough group nodes to generate a valid signature under a threshold signature scheme). However, in other embodiments, nodes may join the Congress in a manner that does not require a new Congress Public Key to be defined. Instead, the same Congress Public Key may be used, and a TEE associated with the Congress node may be used to coordinate the nodes joining the Congress so that they can generate private key shares corresponding to the existing Congress Public Key.

[0115] After a private key share is generated in operation 408, it can be used in operation 410 of method 400. The private key share can be used to collaboratively generate a valid signature for a transaction from a public group address that can be broadcast by members. That is, the private key share can be used in a threshold signature scheme to contribute to signature generation. Under a threshold signature scheme, a threshold number of private key shares of the Congress are required to be used by each member to generate a valid signature that allows digital assets to be transferred far away from the Congress. Node 102, performing method 500, can retrieve the private key share from storage and use it to contribute to signature generation. If a sufficient number of other Congress members also use their respective private keys to contribute to signature generation, a signature may be generated and a valid outgoing transaction may be broadcast. Miner 104 (Figure 1) of blockchain network 100 adds a transaction to a mined block that is added to the blockchain by consensus of node 102 within blockchain network 100, and once the block is confirmed, the outgoing transaction is complete. At this point, the digital assets represented by the transaction may no longer be restricted by the Congress Public Key. That is, such digital assets may no longer be restricted by the Congress Public Key.

[0116] The use of private key shares in Operation 408 may be performed within the TEE of node 102. The TEE protects the private key shares, thereby preventing other parts of the system or the members themselves from accessing any data stored in the enclave, such as the private key shares. Furthermore, assuming the integrity of the TEE is maintained, the TEE protects the private keys in such a way that members cannot retain a copy of the private keys if they wish to have their deposits returned, as the deletion of the private keys must be proven before the member's deposit is returned. Additionally, using the TEE when the Congress acts as a bonded validator set for proof-of-stake sidechains can also guarantee that a partial signature will be provided (by the TEE to the node) only if a consensus is reached regarding the sidechain to which the transaction should actually be signed.

[0117] Transactions in Operation 410 can transfer the digital assets back to the person who originally deposited them in the Congress Pool. That is, the transfer can return the digital assets to the depositor. The transfer can also move the digital assets to another location. For example, the digital assets may be moved to a third party or to an unusable address. In some cases, in a funding transaction to open a payment channel, one or more digital assets that were restricted by the Congress Public Key may be redistributed by the transaction with Congress approval.

[0118] Confiscation of digital assets Next, referring to Figure 5, an exemplary method 500 for confiscating digital assets is shown. Method 500 in Figure 5 may be performed by a node 102 that previously participated in the Congress, and this node may be the same node that performs Method 400 in Figure 4. Method 500 can be performed after operation 408 of Method 400 in Figure 4, so that node 102 performing Method 500 already has access to the private key share when Method 500 in Figure 5 is performed.

[0119] In Operation 502, Node 102 detects malicious activity by a malicious party, which is another member of the Congress. Malicious activity is detected when Node 102 determines that a member of the Congress is violating a predetermined protocol or standard. For example, if a node that is a member of the Congress reports bad information (i.e., false, contradictory, or unacceptable information) to other members of the Congress, that member may be considered a malicious member. As a further example, if a node that is a member of the Congress proposes a transaction that fraudulently transfers digital assets restricted by the Congress Public Key (such as digital assets restricted by the Congress Public Key in a funding transaction to open a payment channel) to another location, other honest nodes may act to penalize the member deposit of the fraudulent node.

[0120] In Operation 503, in response to detecting malicious activity, Node 102 can work with other nodes in the Congress to suspend the member who is malicious. In other words, the Congress can exclude the malicious individual from further participation in the Congress.

[0121] To ensure that all nodes 102 operate in accordance with pre-defined protocols or standards, member deposits to the Congress pool may be subject to confiscation. Confiscation means permanently preventing the return of member deposits deemed to have been confiscated. Digital assets forming member deposits that are not returned due to malicious activity may remain in the Congress pool but will not be returned, and may be transferred to another unusable address immediately or in the future, or confiscated, the nature of which depends on whether Congress acts as a guarantee validator (approver) set up on the sidechain. For example, in Operation 504, Node 102, which executes Method 500 in response to detecting malicious activity by a malicious party, may use a private key share to provide a partial signature in the confiscation transaction. That is, the node cooperates with other nodes in Congress to confiscate at least a portion of digital assets previously transferred by a malicious party to a public group address (i.e., to the Congress pool). In other words, in response to a group member becoming aware of a violation of a predetermined protocol or standard, a private 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 in the Congress Pool.

[0122] The threshold signature scheme is used in conjunction with the Congress public key, so that individual nodes acting independently cannot transfer deposits of other Congress members' digital assets from the Congress pool to another location (e.g., an unusable address). Rather, digital assets can be forfeited by transfer only if each member uses a threshold number of private key shares to generate a valid signature for transferring the digital assets to another address, or if a group of members with at least a threshold number of private key shares reaches a consensus (in Operation 503) to suspend the member. This results in any withdrawal requests from the suspended member being automatically ignored. If digital assets are forfeited by transfer, the other address to which the digital assets may be transferred may be associated with an unusable address. For example, the other address may be an address to which no private key exists, so that no one can access the digital assets associated with the public key of that address. When digital assets are moved to an unusable address, they can be considered destroyed, as they are no longer usable by any member of the Congress, or by any node within the blockchain network 100.

[0123] Therefore, in Operation 504, a node can confiscate digital assets by using a private key share in cooperation with other members of the Congress to generate a valid signature for a transaction to an unusable address.

[0124] Furthermore, in some implementations, the Congress can function as a set of guaranteeing approvers, ensuring proof-of-stake sidechains (including ghost chains, which are described in more detail below), and these sidechains can be used as broadcast channels. For example, a consensus that a member has acted maliciously may be reached by Congress members on a sidechain. This consensus may correspond to the confirmation of a sidechain transaction containing evidence of guilt for malicious activity. If a consensus is reached, any request to withdraw member deposits made by a malicious member is rejected, and the deposits are deemed forfeited. All or part of the forfeited digital assets may be burned at some point in the future. That is, at a later point, a threshold number of members (excluding malicious members) may cooperate to approve the transfer of the forfeited digital assets to an unusable address. Alternatively, some or all of the digital assets may be sent as a reward to the node that provided evidence of the member's misconduct.

[0125] Since the Congress is an open group that can be joined by any node 102 of the blockchain network 100 through the deposit of digital assets, group membership may change periodically. When such changes occur, the allocation of private key shares may be updated.

[0126] Renewal of private key share allocation using new public addresses Referring to Figure 6, an example method 600 for updating the private key share allocation is shown. Method 600 may be performed by node 102 of blockchain network 100 in coordination with other nodes of the blockchain network.

[0127] In operation 602 of method 600, node 102 detects a redistribution request, which is a request and requires the redistribution of key shares to satisfy that request. For example, node 102 may detect that a new future member has moved digital assets to a public group address, or that an existing member has requested to withdraw a member deposit.

[0128] Digital assets may be transferred to a public group address (i.e., the Congress Pool) by nodes requesting to join or increase their involvement in the Congress, and by other nodes that are transferring digital assets to the Congress for other purposes (e.g., transferring digital assets to a sidechain, as described below), even though they are not requesting to join the Congress. In Operation 602, node 102 can use one or more attributes included in at least some transactions of digital assets to the public group address to identify Congress members (i.e., those transferring digital assets to the Congress Public Key to join the Congress and not for other purposes). For example, a particular transaction may be flagged as a special transaction that utilizes an attribute in the transaction. Such an attribute (or the presence or absence of an attribute) may indicate the purpose for which the transfer is being made. For example, if the transfer does not request to join the Congress, the flag may be included in the transaction.

[0129] In response to detecting the request in Operation 602, its implementation requires the redistribution of key shares in Operation 604, and a new private key share is generated by Node 102 in a similar manner to how the private key share was generated in Operation 408 of Method 400 in Figure 4. Other member nodes of the Congress also generate their own private key shares. These private key shares can be used with the threshold signing scheme of the new Congress public key. Members leaving the Congress at this point do not generate new private key shares during Operation 604, and they are not assigned private key shares to use with the new Congress public key; therefore, they lose their eligibility to participate in the Congress and are no longer considered Congress members.

[0130] Furthermore, in response to detecting a redistribution request (which is a request and requires the redistribution of key shares to be fulfilled), in Operation 606, Node 102, in cooperation with other Congress members, transfers all digital assets within the public group address to a new public address associated with the new public key (which subsequently becomes the new Congress public key).

[0131] Therefore, according to Method 600 in Figure 6, if the allocation of deposits changes, or if a request is received from a member to withdraw a deposit, the private key share can be regenerated, and all digital assets under the control of the Congress can be transferred to the new public key. The frequency with which Congress membership can be renewed is limited by the block time of the blockchain network 100. Many applications will only need to rebalance (or reallocate assets) infrequently (i.e., less frequently than the frequency with which blocks are mined in the proof-of-work mechanism).

[0132] Updating private key share reallocation while maintaining existing public group addresses. Next, referring to Figure 7, another exemplary method 700 for updating the private key share allocation is shown. Method 700 may be performed by node 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0133] In method 700 of Figure 7, the Congress public key remains unchanged each time the distribution of member deposits changes. When a request to allocate new key shares is detected (operation 702, which may occur due to the deposit of digital assets to the public group address), node 102 collaborates with other members of Congress to issue new private key shares for the same public key to the new member of the group (in operation 704). The number of collaborating nodes is at least the threshold number required to generate digital signatures under the threshold signature scheme. In operation 704, additional key shares may be allocated while other key shares remain the same. This may require a change in the threshold (of the threshold signature scheme), but in practice, the change will be minor. Alternatively, in operation 804, additional key shares may be allocated while other key shares are renewed. Such updates are required to be achieved by proof against the deletion of any key shares from the previous generation. In this case, the same threshold may be maintained while new shares are assigned (in the case of SSS, this involves shares in a new polynomial for the increased degree).

[0134] In Operation 702, Node 102 can identify Congress members (i.e., those who have transferred digital assets to the Congress Public Key in order to participate in Congress and not for any other purpose) by using one or more attributes contained in at least some of the transactions of digital assets to a public group address. For example, a particular transaction may be flagged as a special transaction using an attribute in the transaction. Such an attribute (or its presence or absence) may indicate the purpose for which the transfer is being made. For example, a flag may be included in a transaction if the transfer does not require participation in Congress.

[0135] If members leave a congress using Method 700, they can ensure that their respective private key shares are deleted. To ensure that the private key shares of former members are unavailable, members of the congress may be required to use node 102, which has a special TEE. The TEE is a hardware-level architecture that ensures that instructions and data executed within it are protected from access and manipulation from the rest of the system. The TEE may use a hardware mechanism that responds to remote authentication challenges, which can be used to verify the integrity of the system against external parties, such as other nodes in the congress.

[0136] Each member node may use an authenticated TEE configured to generate one or more random secret values ​​that remain inaccessible to the host system without compromising hardware at the integrated circuit level. These secret values ​​are used in the distributed generation of private key shares (e.g., operation 410 of method 400 in Figure 4). These secret values ​​may also be used to establish a shared public key during the congress setup phase. Since the calculations related to the setup protocol are performed within the TEE enclave, no member or former member can derive information about themselves or other private key shares from inter-member communications or any other means. The enclave within the TEE allows for the execution of a remote authentication protocol that can be used to prove to other nodes that the TEE enclave is authentic and executing authorized computer-readable instructions.

[0137] Calculations related to group changes are performed within the TEE enclave. For example, the generation of new secure random secrets, which may be used when calculating new polynomials for SSS purposes, is performed within the TEE enclave.

[0138] The TEE enclave also aims to ensure that any previously unused secrets and key shares are deleted before the member deposit can be returned. More specifically, in order to return the member deposit, the authentication protocol may require the TEE enclave to publicly certify the deletion of the key shares. Each node 102 can interpret such authentication as confirmation that the necessary deletion has occurred on other nodes via a remote authentication protocol. Thus, method 800 may also include verifying that any private key shares previously held within the TEE of a member who has left Congress have been deleted from the nodes associated with that member. This verification may be performed by obtaining authentication for the deletion of the private key shares. Thus, a remote authentication protocol may be used to obtain authentication for the deletion of any private key shares previously held within the TEE of a member who has left Congress.

[0139] Method 600 in Figure 6 and Method 700 in Figure 7 offer various advantages, respectively. For example, Method 600 in Figure 6 does not rely on secure deletion and does not require trusted hardware. However, Method 600 in Figure 6 can benefit from such hardware because, in certain situations, such hardware can make malicious pooling of key shares less likely.

[0140] Method 700 in Figure 7 avoids the need to relock digital assets under a new Congress Public Key each time membership changes. Furthermore, in certain circumstances, Method 700 may renew membership earlier than Method 600 in Figure 6 because, under Method 700 in Figure 7, digital assets are not transferred to a new Public Key, and therefore transactions do not need to be added to the blockchain to move all digital assets to the new Public Key. In other words, since the Public Key does not change, membership can be renewed using Method 700 in Figure 7 without having to wait for several blocks to be generated to confirm the transfer of digital assets to a new Public Key.

[0141] Withdrawal from Congress As mentioned earlier, group members may occasionally request to leave the Congress, and if a group member leaves the Congress, the digital assets they have deposited in the Congress pool may be returned to them. Referring here to Figure 8, an exemplary method 800 for returning the deposit is shown in flowchart form. This method may be performed by node 102 in cooperation with other nodes 102 of the Congress.

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

[0143] In response to receiving the request, node 102 evaluates the request against predetermined criteria in operation 804. Such criteria may be predetermined. If the congress operates according to a congress protocol in which the congress public key is not changed whenever group membership changes, node 102 can verify in operation 804 that the private key share has been deleted by the requester. Such verification may be obtained using a remote authentication protocol associated with the TEE.

[0144] If the Congress protocol stipulates that the Congress Public Key changes when membership changes, then the Private Key Share is no longer valid, and Node 102 may not confirm the deletion of the Private Key Share. Instead, a new Congress Public Key may be used, or other digital assets under Congress's control may be transferred to the new Congress Public Key.

[0145] In Operation 804, the assessment may also consider whether a ghost chain is currently deployed. If a ghost chain is deployed, withdrawal requests may not be satisfied until the ghost chain has ceased operation. That is, Congress members mining on a ghost chain will be prevented from withdrawing their "stake" in digital assets at least until the ghost chain has terminated.

[0146] If node 102 approves the withdrawal request based on its evaluation, in operation 806, the node facilitates the withdrawal of the digital assets. Specifically, node 102 uses its private key share to collaboratively generate a digital signature and also uses the digital signature to transfer the digital assets previously deposited by the requester to the requester. For example, the digital assets may be returned to an address from which they were previously received. Operation 806 is executed according to a threshold signature scheme, and as a result, the withdrawal is only completed if at least a threshold number of Congress members approve the withdrawal. Operation 806 is executed after a member who wishes to withdraw has ceased activity for a certain period. This waiting period prevents members from engaging in erroneous actions when protocols for the return of their member deposits are in operation.

[0147] Congress protocols can be used for a variety of purposes. Congress provides a secure mechanism for performing various functions. Congress can function without losing trust and can manage ownership of digital assets.

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

[0149] Congress as a hub fail-safe Next, referring to Figure 9, an exemplary method 900 for implementing fail-safe mode is shown in flowchart form. Method 900 can be executed by node 102, which is a member of Congress 110, in cooperation with another node 102, which is a member of Congress 110. That is, method 900 is executed by node 102, which is already a member of Congress, by depositing member deposits into the Congress pool, as described above. Thus, node 102 executing method 900 has acquired private key shares, as described above, before executing method 900 in Figure 9.

[0150] In Operation 902, Node 102 detects one or more fail-safe activation requests issued by one or more nodes participating in a payment channel with the hub. The payment channel allows commitments for the exchange of value related to the blockchain network to be exchanged outside the blockchain network. For example, as described above, value can be exchanged using commitment transactions, and the value (for potential breach relief transactions) can be transferred to the blockchain at any time.

[0151] A fail-safe activation request is a request issued by a node that previously opened a payment channel by broadcasting a funding transaction as described above, particularly in relation to operation 304 of the method in Figure 3. The funding transaction restricts the digital asset with a Congress public key (i.e., with a public key associated with the group of nodes forming the Congress). More specifically, as described above in relation to Figure 3, each funding transaction restricts the digital asset with three separate public keys, thereby allowing the restriction to be removed by both nodes involved in the payment channel working together, or by the Congress operating independently.

[0152] The failsafe activation request may be of the type described in relation to operation 310 of method 300 in Figure 3. As mentioned in the description of Figure 3, the failsafe activation request may be submitted to a web server acting as a central repository for failsafe activation requests. Thus, the node performing method 900 in Figure 9 may monitor the web server for failsafe activation requests.

[0153] Each failsafe activation request is generated within the enclave in the request of a node connected to a failed hub and signed using the enclave private key associated with the enclave public key. A failsafe activation request may specify the state of a payment channel. The state of a payment channel is the balance of the payment channel, and the state or balance determines the allocation of digital assets, given that the most recent state of the payment channel is considered (as reflected by the most recent commitment transaction). A failsafe activation request may also contain other information. For example, a failsafe activation request may specify the fee to be presented by the node to close the payment channel. A failsafe activation request may also contain freshness data, such as a timestamp. The timestamp or other freshness data may specify the date and / or time the failsafe activation request was generated or issued. Alternatively, the timestamp may specify the block number of the most recent block added to the blockchain of the blockchain network.

[0154] In Operation 904, the node executing Method 900 evaluates the failsafe activation requests. For example, the node may evaluate the freshness of each failsafe activation request. The nodes of the Congress can be configured to ignore failsafe activation requests that have expired (i.e., are not considered sufficiently current), and each failsafe activation request may include freshness information such as a timestamp, which allows the node to determine whether an individual failsafe activation request has expired. For example, the freshness information may be the most recent block number observed by the node that submitted the failsafe activation request, and the group can ignore failsafe activation requests that it determines to be expired based on the block number specified in the failsafe activation request and the current block number of the most recent block added to the blockchain. In other words, each failsafe activation request can specify the individual block number of the most recent block added to the blockchain of the blockchain network when the failsafe activation request was generated, and the group (i.e., the Congress nodes) is configured to ignore failsafe activation requests that are determined to have expired based on the block number specified in the failsafe activation request and the current block number of the most recent block added to the blockchain. A node performing method 900 can therefore access the freshness of a failsafe activation request based on the number of blocks that have elapsed since the failsafe activation request was issued. This number can be compared to a predetermined threshold or other criterion to determine whether a given failsafe activation request has expired. For example, the criterion is that the failsafe activation request was issued a small number of blocks earlier than the "waiting period", and the TEE does not process payments in the payment channel during the waiting period after the failsafe activation request is issued.

[0155] Each failsafe activation request may be mapped by the node executing this method to a specific payment channel, and more specifically, to a funding transaction used to open the payment channel. The node can identify the funding transaction associated with a given failsafe activation request because the funding transaction contains an enclave public key corresponding to the enclave private key used to sign the failsafe activation request.

[0156] In operation 904, the node executing method 900 may determine that the failsafe activation request satisfies predetermined criteria and, accordingly, implement failsafe mode in operation 906.

[0157] A given criterion may require that a sufficient number of failsafe activation requests (i.e., a sufficient number of failsafe activation requests that have not yet expired) are received. The sufficiency of failsafe activation requests may be determined by referring to a threshold. For example, a given criterion may require that a sufficient number of failsafe activation requests (weighted by the balance of each node issuing such requests) exceed a given threshold.

[0158] In Operation 906, the node executing Method 900, in cooperation with other nodes in Congress, implements a fail-safe mode. In doing so, the node, in cooperation with other nodes in Congress, closes the payment channel associated with the fail-safe activation request. To close the payment channel, a mainchain transaction is prepared and proposed, and partial signatures are added to the proposed transaction by several nodes in Congress sufficient to generate valid signatures on behalf of Congress. The transaction is broadcast to the blockchain network. This transaction redistributes the digital assets that were previously restricted by the Congress public key in the funding transaction that opened the payment channel. More specifically, the digital assets are redistributed based on the state of the payment channel, as indicated in the associated fail-safe activation request.

[0159] A transaction that closes a payment channel can close multiple payment channels associated with multiple fail-safe activation requests. That is, a Congress node can perform batch closures of multiple payment channels in a single transaction. Such batch closures reduce the burden on the main blockchain network (i.e., the main chain). A Congress node can implement other load balancing measures for the blockchain network, including staggered closure transactions. For example, a Congress node might wait until it has broadcast at least a few transactions that close payment channels to ensure that the load does not increase beyond a level that could cause disruption to the main blockchain network.

[0160] To close a payment channel, multiple nodes in the congress collaboratively generate a valid signature for the transaction closing the payment channel. To facilitate this signing process, the congress nodes may deploy a temporary sidechain. This temporary sidechain may be called a ghost chain. In addition to facilitating the signing of the closing transaction, the ghost chain may also allow for further transfers of value between nodes that were previously parties to the payment channel connected to a failed hub. That is, a temporary sidechain called a ghost chain may be deployed before the congress nodes collaboratively generate a valid signature for the transaction closing the payment channel. The temporary sidechain may allow for further transfers of value between nodes connected to the hub. Thus, when the payment channel is finally closed, the transaction closing the payment channel is based on the initial balance in the payment channel and the value transferred in the sidechain, as described in the failsafe activation request.

[0161] Next, an example of a ghost chain will be described.

[0162] Ghost Chain Referring next to Figure 10, Blockchain 1002 and Ghost Chain 1004 are shown. Blockchain 1002 is a block-based distributed proof-of-work ledger. Ghost Chain 1004 is a block-based distributed proof-of-stake ledger which can be used to facilitate the closure of payment channels in the event that a hub associated with a payment channel fails.

[0163] Ghost Chain is a proof-of-stake blockchain where Ghost Chain miners are members of the Congress. That is, members of the Congress are permitted to mine on Ghost Chain. Their member deposits in the proof-of-work blockchain network act as their stake, enabling them to mine on Ghost Chain, and the probability of any member being selected to mine is proportional to the relative amount of their deposits.

[0164] Ghost chain 1004 is deployed in operation 906 of method 900 in Figure 9; that is, when fail-safe mode is implemented. The ghost chain can be instantiated (materialized) with a genesis block, which is the final block (also referred to as the terminal block) from a previous instantiation of the ghost chain. This block may contain information about a genesis payment. A genesis payment is the transfer of digital assets that has not yet occurred based on a previous deployment of the ghost chain.

[0165] Numerous blocks are added to the ghost chain by miners to generate a valid signature for the transaction, the effect of which is to close the payment channel or to transfer further value between nodes associated with a faulty payment channel (for example, these nodes may be connected to a failed hub via "spokes"). More specifically, nodes use their respective private key shares to add partial signatures to the proposed transaction until a valid signature is generated according to a threshold signature scheme.

[0166] To close a payment channel, a transaction (which may be referred to as a closing transaction) is constructed and signed (as described in detail below). The effect of this transaction will be to distribute funds on the main blockchain 1002 based on the state of the payment channel (and, in at least some cases, based on some further transactions of value generated on the ghost chain). The transaction also distributes funds to reward miners on the ghost chain and to make genesis payments.

[0167] Ghost Chain 1004 terminates after all payment channels have been closed. Because Ghost Chain 1004 terminates, unlike a typical blockchain, it has a termination block. The termination block may be prepared to include a record of a genesis payment to be made in the next iteration of the Ghost Chain. Genesis payments incentivize participants. More specifically, nodes that participated in the closure of payment channels but have not received a transfer of digital assets in return for their participation during that iteration of the Ghost Chain (for example, since the closure transaction is prepared before their participation) may be referenced in the terminal block, thereby ensuring they receive the digital assets in the next iteration of the Ghost Chain.

[0168] While the above example refers to the operation codes available in Bitcoin, the methods described herein can also be used with other types of blockchain networks.

[0169] Although the methods described above have generally been explained as running on a node, a key feature of these methods is that they rely on coordination with other nodes and can be executed elsewhere.

[0170] It should be noted that the embodiments described above are illustrative and not limiting to the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. No reference numerals placed in parentheses in the claims should be construed as limiting the claims. The words “having” and “having” do not preclude the existence of any elements or steps other than those enumerated in any claim or throughout the specification. In this specification, “having” means “including or consisting of,” and “having” means “including or consisting of.” A single reference to an element does not preclude a reference to multiple such elements, and vice versa. The present invention may be carried out by hardware comprising several distinct elements and by a appropriately programmed computer. In an apparatus claim enumerating several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain items are referenced in different dependent claims does not imply that combinations of these items cannot be usefully used.

[0171] (Note 1) Steps to provide the hub with the enclave public key from the enclave associated with the trusted execution environment on the node; Steps to establish a channel with a hub by broadcasting a funding transaction to the blockchain network that restricts a digital asset using a first public key, a second public key, and a third public key, wherein the restriction on the digital asset can be released by: 1) a first signature generated from a first private key corresponding to the first public key and a second signature generated from a second private key corresponding to the second public key; or 2) a third signature valid for the third public key, the third public key being associated with a group; A step in which the enclave receives a commitment transaction from the hub, wherein the commitment transaction is encrypted with the enclave public key; Steps to detect a malfunction in the hub; and A step of issuing a fail-safe activation request to the group using data from the enclave and data based on the commitment transaction; A method of having. (Note 2) The method according to Appendix 1, wherein the failsafe activation request specifies the block number of a recent block added to the blockchain of the blockchain network, and the group is configured to ignore failsafe activation requests that are determined to have expired based on the block number specified in the failsafe activation request and based on the current block number of a recent block added to the blockchain. (Note 3) A step of determining that failsafe mode is not being executed and that the failsafe activation request has been fulfilled; and A step of issuing another failsafe activation request to the group, wherein the other failsafe activation request includes a new block number for a new recent block added to the blockchain; The method described in Appendix 2, including the method described in Appendix 2. (Note 4) The method according to any one of Appendix 1-3, wherein the step of issuing the failsafe activation request includes the step of automatically sending the failsafe activation request online in response to the detection of a malfunction in the hub. (Note 5) The method according to any one of the items in Appendix 1-4, wherein the failsafe activation request specifies the fee to be presented by the node in order to close the channel. (Note 6) The method according to any one of the appendices 1-5, further comprising the step of the group deploying a sidechain in response to the failsafe activation request and then exchanging value with other nodes using the sidechain. (Note 7) The method according to any one of the items in Appendix 1-6, wherein the failsafe activation request is generated within the enclave and signed using the enclave private key associated with the enclave public key. (Note 8) The method of any one of Appendix 1-7, further comprising the steps of deciphering the commitment transaction, determining the balance associated with the channel, and determining the value associated with the breach relief transaction, wherein the value is a previous secret value associated with a previous commitment transaction. (Note 9) The method according to any one of Appendix 1-8, further comprising the step of broadcasting a sidechain transaction to a miner of a sidechain deployed in response to the failsafe activation request, wherein the sidechain transaction transfers value. (Note 10) Steps include detecting one or more failsafe activation requests issued by one or more nodes participating in one or more channels with a hub, wherein the channels allow commitments for trading value related to the blockchain network to be exchanged outside the blockchain network, and the failsafe activation requests are issued by a node that previously opened the channel by broadcasting a funding transaction that restricts digital assets with a public key related to the group; A step of confirming that one or more of the aforementioned failsafe activation requests satisfy predetermined criteria; and A step of generating a valid signature for a transaction to close one or more of the aforementioned channels, in cooperation with other nodes in the group; A method of having. (Note 11) The method according to Appendix 10, wherein the step of confirming that the failsafe activation request satisfies predetermined criteria includes the step of confirming that the number of failsafe activation requests, weighted by the balance of the individual nodes issuing the request, exceeds a threshold. (Note 12) The method according to Appendix 10 or 11, wherein each failsafe activation request specifies an individual block number of a recent block added to the blockchain of the blockchain network when each failsafe activation request is generated, and the group is configured to ignore failsafe activation requests that are determined to have expired based on the block number specified in the failsafe activation request and based on the current block number of a recent block added to the blockchain. (Note 13) The method according to Appendix 10, 11, or 12, further comprising the step of deploying a temporary sidechain after confirming that one or more failsafe activation requests satisfy predetermined criteria and before collaborating to generate the valid signature, wherein the temporary sidechain allows further transfer of value, and the transaction closing one or more channels is also based on the value transferred on the sidechain. (Note 14) A computer-readable storage medium having computer-executable instructions that, when executed, construct a processor to perform the method described in any one of the items in Appendix 1-13. (Note 15) Interface devices; A processor coupled to the aforementioned interface device; A memory coupled to the processor, the memory storing computer executable instructions that, when executed, construct the processor to perform the method described in any one of the appendices 1-13; An electronic device having (Note 16) The electronic device described in Appendix 15, wherein the processor includes a trusted execution environment, and the computer executable instructions are executed in the trusted execution environment.

Claims

1. A computer execution method performed by processing resources to update private key share allocation, Steps to detect requests for new private key share allocations, A step of identifying a congress member using one or more attributes included in at least a portion of a transaction for a public group address associated with the congress, wherein the public group address is associated with a congress public key. The steps include: detecting a request for the allocation of the new private key share, generating a new private key share associated with the Congress Public Key; and A method that includes this.

2. The method according to claim 1, wherein the processing resource is a node associated with a blockchain network.

3. The method according to claim 2, wherein the node is associated with a congress.

4. A method according to claim 1, wherein the request for the allocation of the new private key share includes detecting that a future new member has transferred a digital asset to the public group address.

5. A method according to claim 1, wherein the request for the allocation of the new private key share includes determining that a member of the group associated with the public group address has requested the withdrawal of a member deposit.

6. A method according to claim 4, wherein a future new member transfers digital assets by a node that requests to participate in the relevant Congress.

7. A method according to claim 1, wherein the congress member is identified by utilizing the presence or absence of an attribute indicating the purpose of the transfer.

8. A method according to claim 7, wherein the transaction includes a flag if the transferor has not requested to participate in the Congress.

9. The method according to claim 1, wherein the generation of the private key share is performed in a trusted execution environment.

10. A method according to claim 1, further comprising the step of changing the threshold number of private key shares required to generate a valid signature for a transaction on behalf of Congress.

11. A method according to claim 1, further comprising the step of renewing a private key share associated with the Congress public key for other Congress members.

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

13. Interface device; A processor coupled to the aforementioned interface device; A memory coupled to the processor, which stores computer executable instructions that, when executed, construct the processor to perform the method described in any one of claims 1 or 11; An electronic device having

14. An electronic device according to claim 13, wherein the processor includes a trusted execution environment, and the computer executable instructions are executed in the trusted execution environment.

Images