Secure transfer between blockchains

Abstract

To provide digital ledger methods and systems for providing decentralized control over digital assets associated with particular addresses in a plurality of digital ledgers.SOLUTION: A method includes: joining a congress by transferring, by a node operating in a proof-of-work blockchain network, one or more digital assets to a congress pool having one or more other digital assets associated with other members of a congress; detecting, by the node, a special transaction of digital assets on the proof-of-work blockchain network to an address associated with the congress pool, the special transaction satisfying determined criteria; and minting, by the node, one or more digital assets on a proof-of-stake blockchain network in response to detecting the special transaction.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] The present invention relates generally to distributed ledgers, and more particularly to methods and systems for providing distributed control over digital assets associated with particular addresses in multiple digital ledgers. The present invention is particularly, but not exclusively, suitable for use in coordinating transactions on a proof-of-work blockchain network with transactions on a proof-of-stake blockchain network. [Background technology]

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

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system composed of blocks. Blocks are in turn composed of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs. Scripts specify how and by whom the output of a transaction can be accessed. On the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be "verified." Some network nodes, acting as miners, perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on the node performs this verification work for transactions that reference unspent transaction outputs (UTXOs). The verification may be performed by executing its lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to true, and if certain other conditions are met, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, the transaction must i) be verified by the node that received the transaction, and if the transaction is verified, the node relays the transaction to other nodes in the network, ii) be added to a new block constructed by the miner, and iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed once a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

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

[0006] As blockchain technology is expanded to provide new features, it is important that the security of the blockchain and the digital assets represented therein is maintained. The expanded feature set that relies on the blockchain may be subject to attack from malicious parties. Therefore, it may be useful to provide methods and apparatus that provide additional security to the blockchain or new features of the blockchain, or control ownership rights to the digital assets to maintain the integrity of the blockchain.

[0007] Additionally, as new improvements or modifications to blockchains are developed, it would be useful to have a technique for transferring digital assets from one blockchain to another while maintaining the integrity of both blockchains. Accordingly, it would be desirable to provide improved methods and apparatus that enhance blockchain technology in one or more of the above-mentioned aspects.

[0008] For example, it has been recognized that in some applications it may be desirable to provide one blockchain associated with another blockchain. Such a blockchain is called a "side-chain" of another blockchain. As with any blockchain, side-chains need to be secured. Historically, blockchain systems such as Bitcoin have relied on mining to provide security. However, since side-chains are subordinate to the main blockchain, there is no easy opportunity to issue assets on the side-chain. Thus, the technical problem is how to secure side-chains through mechanisms other than mining. The literature recognizes that one possible approach is to secure side-chains via an asset, a "stake", drawn from the main blockchain. However, it is also unclear how to effectively provide such a "proof-of-stake" principle for side-chains. For example, the above problems are acknowledged (but not solved) by Vitalik Buterin, founder and chief scientist of the Ethereum blockchain project, in “Side Chains: The How, The Challenges and the Potential,” Bitcoin Magazine April 15, 2014, available at https: / / bitcoinmagazine.com / articles / side-chains-challenges-potential / , the contents of which are incorporated herein by reference in their entirety. It is therefore desirable to enable the principle of “proof-of-stake” for side chains. For example, it may be desirable to lock assets on a first blockchain, such as a proof-of-work blockchain, so that they can act as proof-of-stake for the side chain (the side chain is, in effect, a proof-of-stake blockchain).

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

[0010] As described in more detail below, a congress may be formed on the blockchain network. A congress may be an open membership group that may be joined by any node in the blockchain network by submitting a sufficient stake to a pool associated with the congress. For example, a node may join a congress through the transfer of a digital asset, such as a digital currency (such as Bitcoin), a token, or other stake or value, to an account associated with the congress.

[0011] Once formed, the council may be used to lock specific assets on the proof-of-work blockchain, so that corresponding assets may be provided and operated on the proof-of-stake blockchain. Additionally, the council may be used to lock assets on the proof-of-stake blockchain, so that corresponding assets may be released on the proof-of-work blockchain. Advantageously, in this manner, the council may operate to provide a distributed locking of assets across blockchains. In other words, the council may be used to provide a two-way peg between the proof-of-work blockchain and the proof-of-stake blockchain. Permissionless interaction with the proof-of-work protocol via digital signatures may be used to provide such a two-way peg.

[0012] Thus, according to the present invention, there may be provided a computer-implemented method, the computer-implemented method including: participating in a congress by a node operating within a proof-of-work blockchain network by transferring one or more digital assets to a congress pool having one or more other digital assets associated with other members of the congress, detecting, by the node, an ad hoc transaction of a digital asset on the proof-of-work blockchain network to an address associated with the congress pool, the ad hoc transaction meeting determined criteria, and creating, by the node, one or more digital assets on the proof-of-stake blockchain network in response to detecting the ad hoc transaction.

[0013] In some embodiments, a computer-implemented method includes: participating, by a node operating within a proof-of-work blockchain network, in a congress by transferring one or more digital assets to a congress pool having one or more other digital assets associated with other members of the congress; detecting, by the node, an ad-hoc transaction of digital assets on the proof-of-work blockchain network to an address associated with the congress pool, the ad-hoc transaction meeting determined criteria; locking the digital assets of the ad-hoc transaction against transfer other than by the congress pool; and in response to detecting the ad-hoc transaction, creating, by the node, one or more digital assets on the proof-of-stake blockchain network, the digital assets on the proof-of-stake blockchain network that are operational using the proof-of-stake blockchain network and correspond to the locked digital assets.

[0014] In some implementations, the computer-implemented method may further include determining, after detecting the special transaction, that at least a threshold number of blocks have been added to a blockchain of the proof-of-work blockchain network, and the producing step may be responsive to determining that at least the threshold number of blocks have been added.

[0015] In some implementations, joining a congress may further include generating private key shares to be used in a threshold signature scheme in which at least a threshold number of private key shares must be used to sign transactions on behalf of the congress, other holders of the private key shares being other members of the congress who are joining the congress on a permissionless or unauthorized basis by transferring their respective digital assets to the congress pool.

[0016] In some implementations, the computer-implemented method may further include detecting, on the proof-of-stake blockchain network, a request to transfer the digital asset on the proof-of-stake blockchain network back to the proof-of-work blockchain network, and cooperatively signing a transaction from the address associated with the congress pool using the private key share in response to detecting the request. The computer-implemented method may further include determining, after detecting the request, that at least a threshold number of blocks have been added to a blockchain of the proof-of-stake blockchain network. The using the private key share may be in response to determining that at least the threshold number of blocks have been added to a blockchain of the proof-of-stake blockchain network. In some implementations, the determination that at least the threshold number of blocks have been added to a blockchain of the proof-of-stake blockchain network may be performed within a trusted execution environment on a node.

[0017] In some implementations, the computer-implemented method may further include burning the digital asset associated with the claim on the proof-of-stake blockchain network with the claim.

[0018] In some implementations, the threshold signature scheme used in the computer-implemented method is an Elliptic Curve Digital Signature Algorithm.

[0019] In some implementations of the computer-implemented method, the steps of generating a private key share and using the private key share are performed in a trusted execution environment within the node.

[0020] In some implementations of the computer-implemented method, the step of creating on the proof-of-stake blockchain network is performed by a node selected by the proof-of-stake blockchain network, and the probability of the node being selected is based on the amount of digital assets the node has deposited in the congress pool.

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

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

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

[0024] [Figure 1] FIG. 1 illustrates a block diagram of an exemplary blockchain network. [Diagram 2] FIG. 1 illustrates a block diagram of an example electronic device that can function as a node in a blockchain network. [Diagram 3] 1 is a flow chart of an exemplary method for initiating a congress. [Figure 4] 1 is a flow chart of an exemplary method of participating in a council. [Diagram 5] 1 is a flowchart of an exemplary method for confiscating digital assets. [Figure 6]1 is a flow chart of an exemplary method for redistributing key shares. [Figure 7] 13 is a flow chart of a further exemplary method for redistributing key shares. [Figure 8] 1 is a flow chart of an exemplary method for returning a deposit. [Figure 9] FIG. 1 is a block diagram of a first and second blockchain network. [Figure 10] 1 is a flowchart of an exemplary method for providing a two-way peg. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] <Blockchain network> Reference is first made to Figure 1. Figure 1 illustrates, in block diagram form, an example blockchain network 100 associated with a blockchain. The blockchain network may be a public blockchain network, which is a peer-to-peer open membership network that anyone may join without invitation or approval from other members. The blockchain network 100 operates under a blockchain protocol, and distributed electronic devices running instances of the blockchain protocol may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol.

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

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

[0028] Nodes 102 maintain a global ledger of all transactions on the blockchain. The global ledger is therefore a distributed ledger. Each node 102 may store a full or partial copy of the global ledger. In the case of a proof-of-work secured blockchain, transactions by nodes 102 that affect the global ledger are verified by other nodes 102. As a result, the validity of the global ledger is maintained. When the blockchain is a proof-of-work based blockchain, blocks are also verified by checking the proof-of-work submitted with the block.

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

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

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

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

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

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

[0035] The council 110 is an open membership group that may be joined by any node 102 by submitting a sufficient stake to a pool associated with the council 110. For example, a node may join a council through the transfer of a digital asset, such as a digital currency (such as Bitcoin), token, or other stake or value, to an account associated with the council 110. Nodes 102 that join a council may be any node in the blockchain network, including both mining and non-mining nodes. In at least some applications of a council (such as when the council is implementing a two-way peg, as described below), nodes acting as council members monitor the blockchain, in the sense that they download (but do not necessarily hold) the complete blockchain.

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

[0037] <Electronic devices acting as nodes> 2 is a block diagram illustrating components of an example electronic device 200 that may function as a node 102 (FIG. 1) in a peer-to-peer blockchain network 100 (FIG. 1). The example electronic device 200 may also be referred to as a processing device. The electronic device may take a variety of forms, including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smart watch, or another type of form.

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

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

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

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

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

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

[0044] The TEE 250 may be used to attest to the secure deletion of private key shares when a member of the assembly 110 who has previously used private key shares on the electronic device 200 chooses to leave the assembly. The electronic device 200 may provide an attestation of the deletion to other assembly members through a remote attestation protocol provided within the TEE 250. The attestation of the deletion may be required before members are allowed to retrieve their member deposits; that is, the return of the deposit may be conditional on the attestation of the deletion of the private key shares held within the member's enclave.

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

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

[0047] The electronic device 200 may operate as a node 102 (FIG. 1) in the blockchain network 100 (FIG. 1) and may join or otherwise participate in a council 110 (FIG. 1). A council 110 is formed when a group of digital asset bearers pool digital assets, such as digital currency, tokens, or stakes or value, supported by the blockchain network 100 (FIG. 1).

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

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

[0050] The Congress public key encumbers digital assets deposited in the Congress pool by members of Congress 110 in exchange for private key shares, and any digital assets deposited in an address associated with the Congress pool by members or non-members of Congress 110 (i.e., fully, partially, or conditionally under Congress control) that are deposited for reasons other than obtaining private key shares. A non-member or member may deposit digital assets in an address associated with a Congress for a variety of reasons. In one example, detailed below, a member or non-member may deposit a digital asset with Congress 110 in order to move the digital asset to another blockchain, such as a side chain, sometimes referred to as an alternative chain (alt-chain). A side chain may be a blockchain that runs in parallel (i.e., in parallel with) the main blockchain.

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

[0052] The council 110 may operate as an autonomous group where cooperative behavior is enforced through the threat of confiscation of all or part of the member deposits. Non-cooperative or dishonest members may have such digital assets confiscated through participation in a cooperative protocol by a majority of honest members. That is, member deposits to the council pool may be subject to confiscation to ensure that all nodes 102 operate according to a predefined protocol or standard. Confiscation means permanently preventing the return of a member deposit deemed to be confiscated. Digital assets forming member deposits that are not returned due to misconduct may remain in the council pool but may not be returned (e.g., if a consensus is reached (on the alt-chain) that they should not be returned), may be transferred immediately or in the future to another unusable address, or may be otherwise confiscated. The nature of the confiscation may depend on whether the council acts as a combined validator set of the sidechain or not.

[0053] Additionally, when a council member wishes to leave council 110, they may withdraw their member deposit (i.e., request that council 110 transfer the member deposit back to their personal address). However, withdrawal of funds can only be performed if a number of private key shares exceeding a threshold number required to generate a valid digital signature are used by a member of the group (i.e., council) to authorize the withdrawal.

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

[0055] The threshold signature method may be an Elliptic Curve Digital Signature Algorithm (ECDSA) method. For example, the ECDSA method may be of the type proposed by Ibrahim et al. in "A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme", Midwest Symposium on Circuits and Systems, 1:276-280 (2003). This threshold signature method is an extension of a digital signature method that is an algorithm based on elliptic curve cryptography, where t + 1 key shares from n key share holders among the parties are required to reconstruct the private key. This method may be used to construct a valid signature without the need to reconstruct the private key and without any party having to disclose their key share to another party. th Since t + 1 key shares are sufficient to reconstruct the secret, the maximum number of permissible adversaries according to this technology is t. An adversary is a corrupted entity that holds secret shares and has access to the secret shares in the model of Ibrahim et al. Adversaries can be of various types. For example, a Byzantine adversary is an adversary that can participate in the protocol while actually sending incorrect information. The ECDSA method proposed by Ibrahim is robust against up to t <= n / 4 malicious adversaries. This robustness can be increased up to t < n / 3, but at the cost of greater complexity.

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

[0057]

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

[0059] The transmission of fraudulent shares to individual nodes (i.e., shares that are different from the broadcasted hidden shares) can be identified by the intended recipients of the shares. The identification of fraudulent shares being transmitted in secret to nodes can be made publicly verifiable using techniques known as Publicly Verifiable Secret Sharing (PVSS). Such techniques can avoid possible delays in identifying fraudulent senders that may occur if PVSS is not used and the recipients of the fraudulent shares are offline or disconnected from the root of the network when the fraudulent shares are transmitted.

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

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

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

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

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

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

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

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

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

[0069] The node 102 executing method 300 allows payments for the public key until one or more conditions are met, at operation 304. For example, the node may allow payments for the public key for a determined period of time or for a determined number of blocks. After the conditions are met (e.g., after the end of the period of time or after mining a number of blocks), the node 102 executing method 300 identifies the initial members of the council, at operation 306.

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

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

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

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

[0074] The transaction in operation 404 may include a flag, identifier, or other attribute that indicates that the party transferring the digital assets wishes to join the Congress and that a deposit is being generated for such purposes.

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

[0076] At operation 408, node 102 generates private key shares to be used in a threshold signature scheme in which at least a threshold number of private key shares must be used to generate a valid signature for a transaction on behalf of the congress. The other holders of the private key shares are other members of the congress who have joined the congress on an authorized or unauthorized basis by transfer of their respective digital assets to the public group address.

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

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

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

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

[0081] The use of the private key shares in operation 408 may be performed within the TEE of node 102. The TEE protects the private key shares. As a result, no other parts of the system or the member themselves can access any data stored in the enclave, such as the private key shares. Additionally, the TEE protects the private key in that no copy of the private key can be retained, since if a member wants to return their deposit and get their deposit back, they must prove the deletion of the private key before the member's deposit is returned.

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

[0083] The transaction in operation 410 may transfer the digital asset back to the party that originally deposited the digital asset in the Congress pool. That is, the transfer may return the digital asset to the depositor. The transfer may also transfer the digital asset elsewhere. For example, the digital asset may be transferred to a third party or to an unusable address.

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

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

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

[0087] To ensure that all nodes 102 operate according to a predefined protocol or standard, member deposits to the congress pool may be subject to confiscation. Confiscation means permanently preventing the return of a member deposit deemed to be confiscated. Digital assets forming a member deposit that are not returned due to misconduct may remain in the congress pool, but may not be returned (in response to a consensus that this action should be taken), transferred immediately or in the future to another unusable address, or otherwise confiscated. The nature of the confiscation may depend on whether the congress acts as a combined set of validators for the side chain. For example, in operation 504, in response to detecting misconduct by a fraudulent party, a node 102 executing method 500 may use a private key share to provide a partial signature for a confiscation transaction (which is a transaction that transfers digital assets to an unusable address or to another node as a reward for exposing the fraud). That is, the node cooperates with other nodes in the congress to confiscate at least a portion of the digital assets previously transferred by the fraudulent party to a public group address (i.e., to the congress pool). That is, in response to observing a group member violate a predetermined protocol or standard, the private key share is utilized to contribute to authenticating a transaction of one or more digital assets held within the congress pool associated with that group member.

[0088] Because a threshold signature scheme is used with the council public key, an individual node operating alone cannot transfer another council member's digital asset deposit away from the council pool (e.g., to an unusable address). Rather, a digital asset can only be confiscated by transfer when a threshold number of private key shares are used by those respective members to generate a valid signature to transfer the digital asset to another address, or when a group of members with at least the threshold number of private key shares reach a consensus to suspend the member (in operation 503), which causes a withdrawal request from the suspended member to be automatically ignored. When a digital asset is confiscated by transfer, the other address to which the digital asset may be transferred may be associated with the unusable address. For example, the other address may be an address for which no private key exists. As a result, no party can access the digital asset bound by the address's public key. Once a transaction is confirmed that transfers a digital asset to an unusable address, or once a consensus is reached on the sidechain that the digital asset should be confiscated, the digital asset may be considered burned, as it can no longer be used by any member of Congress or indeed by any nodes in the blockchain network 100.

[0089] Thus, in operation 504, the node may confiscate the digital assets by using its private key share in cooperation with other members of the council to generate a valid signature for a transaction to the unusable address. Some implementations may include reaching a consensus on a second blockchain that members should be permanently stripped of all or a portion of their deposits.

[0090] Additionally, in some implementations, the council may act as a joint set of validators that secure a proof-of-stake sidechain. This sidechain may be used as a broadcast channel. For example, a consensus may be reached by council members on a sidechain on which members have been acting dishonestly. This consensus may correspond to the confirmation of sidechain transactions that include denouncing evidence of dishonesty. Once consensus is reached, any request to recover member deposits made by dishonest members is denied, and the deposits are considered confiscated. The confiscated digital assets may be burnt at some future time; that is, at some later time, a threshold number of members (not including dishonest members) may cooperate to authorize the transfer of the confiscated digital assets to unusable addresses.

[0091] Since the council is an open group that may 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 private key share distribution may be updated. Referring to FIG. 6, an example method 600 for updating the private key share distribution is shown. The method 600 may be performed by a node 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

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

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

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

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

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

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

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

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

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

[0101] Each member node may use a certified TEE configured to generate one or more random secret values ​​that remain inaccessible to the host system without compromising integrated circuit level hardware. The secret value thus generated may be used in the distributed generation of secret key shares (e.g., in operation 410 of method 400 of FIG. 4). This secret value may also be used to establish a shared public key during the assembly establishment phase. The computations associated with the establishment protocol are performed within the TEE enclave. As a result, no member or former member can derive any information about their own or others' secret key shares from member-to-member communications or in any other manner. The enclave within the TEE allows a remote attestation protocol to be performed. The remote attestation protocol may be used to prove to other nodes that the TEE enclave is authenticated and is executing authorized computer-readable instructions.

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

[0103] The TEE enclave also aims to ensure that previous key shares and previous secrets that should no longer be used are securely deleted before the member deposit can be returned. In particular, to return the member deposit, the attestation protocol may require the TEE enclave to attest to the deletion of the key shares. Each node 102 may interpret such attestation as confirmation through the remote attestation protocol that the requested deletion occurred on the other node. Thus, the method 700 may further include the step of verifying that the private key shares previously held in the TEE of the member who has left the parliament have been deleted from the node associated with that member. This verification may be performed by receiving an attestation of the deletion of the private key shares. Thus, the remote attestation protocol may be used to obtain an attestation for the deletion of the private key shares previously held in the TEE of the member who has left the parliament.

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

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

[0106] <Removal from Parliament> As mentioned above, group members may request to leave the council from time to time. When group members remove themselves from the council, the digital assets they deposited in the council pool may be returned to them. Referring to Figure 8, an exemplary method 800 for returning a deposit is shown in flow chart form. The method may be performed by node 102 in cooperation with other nodes 102 of the council.

[0107] At operation 802 of method 800, node 102 receives a retrieval request from a requester who is a council member. The retrieval request may also be referred to as an expungement request. The retrieval request is a request to retrieve a digital asset previously deposited by the requester and now controlled by the council. The request may be broadcast by the requester to all council members.

[0108] In response to receiving the request, at operation 804, the node 102 evaluates the request against the determined criteria. Such criteria may be predefined criteria. If the council operates according to a council protocol in which the council public key is not changed whenever group membership changes, then at operation 804 the node 102 may verify that the private key share was deleted by the requester. Such verification may be obtained using a remote attestation protocol associated with the TEE.

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

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

[0111] The Council Protocol may be used for many different purposes. Councils provide a secure mechanism to perform a variety of functions. Councils do not have to operate trustlessly and provide control of ownership over digital assets.

[0112] The Congress Protocol may be used, for example, to implement a two-way peg between a secure permissionless proof-of-work blockchain and a secure permissionless proof-of-stake blockchain. A two-way peg is a mechanism that allows for the efficient transfer and return of digital assets from one blockchain to another. In particular, digital tokens may be transferred from a main blockchain network, which may be called the main chain, to a separate, secondary blockchain network, which may be called a side chain or alt-chain. This mechanism need not be a specially configured mechanism. Indeed, the technique described below works with existing protocols on the main chain (such as Bitcoin). This technique works with any mechanism that uses digital signatures to authenticate the transfer of digital assets. As described in more detail below, transfers from the main chain are accomplished by a side chain miner minting a corresponding digital asset on the side chain by a temporary locking of the digital asset on the main chain. Transfers from the side chain to the main chain may also be performed by burning the digital asset on the side chain when a mechanism exists whereby this action results in the unlocking of an equivalent amount of the digital asset on the main chain.

[0113] <System with multiple blockchain networks> Referring to Figure 9, a block diagram of exemplary first and second blockchain networks is shown. The first blockchain network 900 is a proof-of-work blockchain network. The first blockchain network 900 may be of the type described above with reference to Figure 1. The first blockchain network 900 includes a number of nodes 102a, 102b coupled to each other using suitable communication technologies, which may include wired and wireless communication technologies.

[0114] The nodes 102a, 102b of the first blockchain network 900 maintain a global ledger of all transactions on the first blockchain (which may be referred to as a main chain). At least some of the nodes 102a, 102b act as miners 104 of the first blockchain network 900.

[0115] The second blockchain network 902 is a proof-of-stake blockchain network. The second blockchain network 902 includes multiple nodes 102c, 102d coupled together to maintain a global ledger for the second blockchain network 902. The global ledger for the second blockchain network 902 is separate and distinct from the global ledger for the first blockchain network 900. The global ledger for the second blockchain network 902 may be referred to as a sidechain.

[0116] The second blockchain network 902 based on proof-of-stake 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 906 deposit security deposits of digital assets and the probability of being selected as a node to mine a block is proportional to the amount of digital assets provided as a security deposit. Proof-of-stake blockchain systems can be used to avoid the computational expense and energy required to mine on a proof-of-work blockchain. Additionally, proof-of-stake blockchains can allow for higher frequency and more regular block generation than proof-of-work blockchains.

[0117] The second blockchain network 902 also includes a number of nodes 102b, 102c that are coupled together using suitable communication technologies. These nodes 102b, 102c maintain a global ledger for the second blockchain network 902.

[0118] A number of nodes 102b act as miners 906 of the second blockchain network 902. Since the second blockchain network 902 is a proof-of-stake blockchain network, the miners 906 deposit digital assets to be included as miners. In particular, the sidechain miners 906 form a combined validator set to mine on the second blockchain network 902. These miners 906 are also members of the parliament 110 associated with the first blockchain network 900. That is, the nodes 102b that are part of both the first blockchain network 900 and the second blockchain network 902 act as miners 906 of the second blockchain network 902 and as members of the parliament 110 established on the first blockchain network 900. These miners 906 join and participate in the parliament 110 according to the methods described above. Their deposits into the parliament pool of digital assets are created in the main chain. That is, council members deposit their “stake” into the proof-of-work first blockchain network 900, become council members of the first blockchain network 900, and also act as miners 906 on the second blockchain network 902 by forming a joint verifier set. The member deposits into the first blockchain network 900 act as security deposits for the second blockchain network 902.

[0119] Also, because the number of private key shares held by a member is based on the amount of the member's security deposit, and because such deposits are subject to forfeiture for misconduct, members with greater influence on the council's activities (i.e., members holding more private key shares) must lose more than members with less influence. The council 110 is an open membership group that may be joined by any node by submitting a sufficient stake to a pool associated with the council 110. Because council members are miners on the second blockchain network 902, they can generate new digital assets on the second blockchain network 902, effectively transferring digital assets from the first blockchain network 900 to the second blockchain network 902. The council 110 may be used to provide a two-way peg between a proof-of-work blockchain and a proof-of-stake blockchain.

[0120] The nodes 102a, 102b, 102c shown in FIG. 9 may be electronic devices 200 of the type described above with reference to FIG.

[0121] <Two-way peg>

[0013] Referring now to Figure 10, Figure 10 illustrates in flow chart form an example method 1000 for providing a two-way peg. The method 1000 may be performed by a node 102b operating in both the first blockchain network 900 (i.e., a proof-of-work blockchain network) and the second blockchain network 902 (i.e., a proof-of-stake blockchain network). Computer readable instructions may be stored in a memory of such a node. These instructions, when executed by a processor of the node, configure the processor to perform the method 1000.

[0122] At operation 1002, node 102b joins a congress. A congress may be joined in the manner described above with reference to FIG. 4. For example, node 102b may transfer one or more digital assets to a public group address associated with a congress public key. The public group address has one or more other digital assets associated with other members of the congress (e.g., other nodes 102b). When node 102b joins a congress, node 102b generates private key shares for use in a threshold signature scheme in which at least a threshold number of private key shares must be used to generate a valid signature on behalf of the congress. As described above, the threshold signature scheme may be of various types, including threshold schemes based on Elliptic Curve Digital Signature Algorithms or Schnorr schemes.

[0123] The other holders of private key shares are other members of the Congress who have joined the Congress on an authorized or unauthorized basis by transferring their respective digital assets to the public group address.

[0124] At operation 1004, node 102b that joined the parliament forms a bonded verifier set with other members of the parliament on a proof-of-stake blockchain network (e.g., on the second blockchain network 902). That is, after depositing digital assets as security (this deposit may be referred to as "bonding"), the members of the parliament (formed on the first blockchain network 900 through the deposit) now act as miners on the second blockchain network and periodically generate new blocks for the second blockchain network 902.

[0125] After the parliament is formed, the parliament member node 102b may detect confirmation of a special transaction to the group public address of the digital assets on the proof-of-work blockchain network at operation 1006. The transaction is determined to be special if it meets certain criteria that distinguish the transaction from a transaction used to join the parliament. For example, a transaction may be determined to be special if it includes a specific flag, variable, or attribute. In particular, the special transaction transfers digital assets to the group public address, which has the effect of making these assets inaccessible to anyone other than the parliament pool. In other words, the transaction has the effect of locking the digital assets of the special transaction from transfer by anyone other than the parliament pool.

[0126] After detecting the special transaction, node 102b may wait until at least the threshold number of blocks are added to the blockchain of the proof-of-work blockchain network. This waiting period may reduce the risk of a possible reorganization of the blockchain in the proof-of-work blockchain network that may invalidate the transaction at operation 1006. Thus, although not shown in FIG. 10, the method may include an operation of determining that at least the threshold number of blocks are added to the blockchain of the proof-of-work blockchain network after detecting the special transaction.

[0127] After the threshold number of blocks are added to the proof-of-work blockchain, node 102b creates (at operation 1008) corresponding digital assets on the proof-of-stake blockchain network. These digital assets are created in response to detecting the special transaction and are created in an amount corresponding to the amount of digital assets in the special transaction detected in operation 1006.

[0128] The created digital assets are placed on the proof-of-stake blockchain network in an account associated with the owner of the public key that generated the special transaction detected in 1006. By definition, digital assets created on the proof-of-stake blockchain network are operational with the proof-of-stake blockchain network (e.g., can be transferred between addresses on the proof-of-stake blockchain). Moreover, because they were created in response to locking assets from the proof-of-work blockchain network, they correspond to locked digital assets. Thus, the party that transfers the digital assets to the council on the proof-of-work blockchain network regains control of the digital assets on the proof-of-stake blockchain network. This party is now free to use these digital assets in a variety of ways, including, for example, by transferring these digital assets to other accounts.

[0129] The creating step is performed by selected council members. In particular, council members who also act as miners 906 for the proof-of-stake blockchain network are selected to generate blocks by the proof-of-stake blockchain network. The probability of a node being selected is based on the amount of digital assets the node has staked. The probability may be proportional to the amount of digital assets the node has deposited in the council public key.

[0130] At some later time, the owner of the digital assets may wish to transfer them back to the proof-of-work blockchain network (i.e., to the main chain). To do so, they may issue a request to transfer the digital assets back to the proof-of-work blockchain network. Such a request may be issued in the form of a special transaction on the proof-of-stake blockchain network. This transaction may be special in that it is a transaction to a special unspent address. This address is the address to which funds should be sent when the sender wishes to transfer the funds back to the main chain. That is, the transaction may be special in that the address is a special address. At operation 1010, node 102b may detect a request to transfer the digital assets on the proof-of-stake blockchain network back to the proof-of-work blockchain network. For example, at operation 1010, there may be mining of a transaction that sends funds to the special address.

[0131] To prevent reorganization, node 102b may wait until at least a threshold number of blocks have been added to the blockchain of the proof-of-stake blockchain network after detecting the request at operation 1010. Thus, although not shown in FIG. 10, method 1000 may include an operation of determining that at least a threshold number of blocks have been added to the blockchain of the proof-of-stake blockchain network after detecting the request.

[0132] In response to detecting such a request and determining that a threshold number of blocks have been added to the proof-of-stake blockchain, node 102b uses its private key share for the council to collaboratively generate a valid signature for the transaction from the public group address at operation 1012. For example, the transaction may be circulated among members of the council directly or via a sidechain by including necessary information in the transaction on the sidechain. Members may add their partial signatures until a valid signature is obtained, at which point the transaction can be broadcast to miners 104 of the proof-of-work blockchain network. The transaction transfers the digital asset to an address on the proof-of-work blockchain network, which may be an address associated with the node that issued the request detected in operation 1010.

[0133] The special address to which the digital asset is transferred in operation 1010 is an unusable address. Thus, the transfer of the digital asset in operation 1010 burns the digital asset on the proof-of-stake blockchain to prevent double-spending (i.e., duplication of the digital asset across two blockchains).

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

[0135] <Protection against one-way bet attacks> To further improve security, the protocol may include one or more protections against unidirectional bet attacks. An example of a unidirectional bet attack occurs when an impostor (i.e., a node associated with a fraudulent party) composes a transaction on the main chain that uses all or part of a digital asset under the control of the congress (i.e., blocked by the congress public key). The impostor may provide the transaction to other members to add partial signatures. A valid signature can be generated if a threshold number of private key shares associated with the members participate. If the threshold signature scheme used within the protocol is not an aggregate signature scheme (e.g., when ECDSA is used), it may be difficult to identify the members who contributed partial signatures. Members who would pay if the fraud was successful may add their partial signatures to the transaction and pass the transaction on without risking exposure as participants in the fraud. Thus, the addition of partial signatures may be seen as a unidirectional bet, since the worst that can happen is that enough partial signatures are collected to obtain a full signature.

[0136] The protocol may therefore include one or more features that protect the protocol from unidirectional bets. For example, the TEE of each node may be configured to periodically attest all transactions that they have partially signed and / or that they may be required to broadcast, as attestations before their deposits are reclaimed. If a node attests that it added a partial signature to a transaction that is later determined (by a threshold number of council members) to be a fraudulent transaction, such fraud may be detected (e.g., at operation 502 of method 500 of FIG. 5 ) by other honest member nodes. If such fraud is detected, the honest member nodes may cooperate to suspend the member (as described above with reference to operation 503 of method 500 of FIG. 5 ) and / or confiscate the member's digital assets (as described above with reference to operation 504 of method 500 of FIG. 5 ). While this technique is useful in helping to protect the protocol from unidirectional bets, it may introduce overhead when periodic attestations are used. Furthermore, fraud may go undetected for an extended period of time if attestations are required before the return of a deposit.

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

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

[0139] The BGLS can provide secure protection against one-way bets in the following way: When a node pays the parliament public key to join (which may occur at operation 404 of method 400 of FIG. 4), the join transaction may include i) the number and hash of the most recent blocks on the main chain that the enclave has seen, as well as the number and hash of the most recent blocks on a second blockchain (i.e., the side chain), and ii) a quote (a hash of the initial contents of memory in the enclave, signed by the TEE's attestation key, and binding to a SID).

[0140] Before requesting the TEE to provide the necessary data for a join transaction, members must send all blocks on the main chain and the secondary blockchain to their TEE, sequentially, starting from the genesis block of each blockchain. The TEE is configured to keep a record of the current membership, which can be obtained by checking the proof-of-work on the main chain and analyzing join and remove transactions. This allows the TEE to establish the current SID independently (e.g., from its owner). That is, this allows the TEE to establish SIDs corresponding to all current members of the parliament.

[0141] To join (e.g., during operation 404 of method 400 of FIG. 4), a (prospective) member constructs, signs, and broadcasts a join transaction payable to the council's public group address to the main chain blockchain network (e.g., to the first blockchain network 900 of FIG. 9). The join transaction references sufficient UTXOs for at least one key share. Once the join transaction is confirmed on the main chain, the council members may cooperatively issue new key shares to the joining member's TEE (e.g., as described above with reference to operation 704 of method 700 of FIG. 7).

[0142] When the council wants to initiate a digital asset transaction secured by the council public key, a node in the council may propose transaction T(M) on the second blockchain network (i.e., on an alt-chain such as a sidechain). Transaction T(M) is now an unsigned transaction proposed on sidechain A that is intended to transfer the digital asset on the main chain M. That is, the second blockchain network (i.e., the sidechain) may be used as a broadcast channel. When one member wants to communicate some information to all other members, they may put it on a transaction and send it to the sidechain.

[0143] A transaction T(M) is considered ratified on the second blockchain network (sidechain) once at least a threshold number of blocks have been mined on it. When the TEEs observe that a transaction has been ratified (i.e., proposed and confirmed) on the second blockchain network (i.e., on an alt-chain such as a sidechain), they broadcast a precommit. The precommit consists of the BGLS signature on transaction T(M) and a SID corresponding to the BGLS signature. The precommit is sent to the second blockchain network and thus shared with other council members. That is, the precommit may be encapsulated within a transaction on the second blockchain network.

[0144] Once a threshold number of pre-commits have been observed by the node, and in particular by the TEE into which blocks from both the main chain and the second blockchain network are input, the node outputs a commit (partial signature) on the pre-committed transaction T(M). The threshold may be set, for example, to a simple majority of all current SIDs. The commit is included in the transaction and sent onto the second blockchain network including a partial signature for T(M) referencing T(M).

[0145] Once at least a threshold number of commits have been observed in the second blockchain network to constitute a full signature, a signed transaction T(M) is constructed and broadcast to the first blockchain network (e.g., to the main chain).

[0146] The use of pre-commit can provide additional security, since the properties of the aggregate signature scheme mean that members cannot contribute to the pre-commit without disclosing their identity, in the form of a SID that is associated with the member deposit during the join procedure.

[0147] In addition to the above measures, the TEE associated with the node may be further configured to commit or pre-commit a transaction only if it is ratified on the second blockchain network. For example, every block may be configured in the TEE such that the block always includes a pre-commit or commit to a ratified transaction that requires the block (corresponding to the SID of the configured TEE of the block). Thus, a member cannot be inhibited from sending a commit or pre-commit to a ratified transaction and continuing to mine on the sidechain.

[0148] A node observing a pre-commit to an unratified transaction on the second blockchain network may report such misconduct to other members of the combined validator set. Misconducting members (identified by their SIDs) may be penalized through suspension and / or confiscation of member deposits as described above. For example, in response to observing a pre-commit to an unratified transaction, the membership may cooperate and immediately suspend the SIDs. As a result, no further pre-commits are accepted and the guilty members are suspended from participating in the protocol. Furthermore, when a transaction containing incriminating evidence is confirmed in the second blockchain network, the guilty members' deposits may be considered forfeited and their deposits are burned. Honest members may cooperate and reward the nodes that reported the misconduct (e.g., by transferring at least a portion of the forfeited digital assets to the nodes that reported the misconduct). Thus, the application of an aggregate signature scheme in the pre-commit phase may enhance the security of the protocol, for example, by preventing one-way bet attacks.

[0149] To protect against a member attempting to deceive the TEE into determining that the current mining difficulty of the proof-of-work in the main chain is less than the TEE's own current mining difficulty, the TEE may be configured to take action when a sudden drop in the mining difficulty is observed. In particular, the mining difficulty may be established from the time interval between blocks when they arrive and are submitted to the TEE. A decrease in the mining difficulty is expected to be gradual, and a sudden drop (which may be determined to be "sudden" based on predetermined criteria) may be caused by a member attempting to deceive the TEE by not providing blocks as they arrive, making it appear as if the mining difficulty has dropped, making it easier to forge blocks in the proof-of-work mechanism. To provide further security, the TEE may be configured to respond to observing a sudden drop in the mining difficulty on the mechanism by outputting a pre-commit to the new mining difficulty to be mined (along with the hash of the block and the number of blocks) to the second blockchain network. The hash of the block is included to make it verifiable that the block corresponds to the new mining difficulty. The block number is included to allow other members to quickly compare the required mining difficulty / block hash with blocks at the same height on their copy of the blockchain.

[0150] It will readjust the mining difficulty of the main chain and accept new members who join the main chain since the sudden drop in mining difficulty was observed only when provided with blocks from the second blockchain that contain pre-commits to the same mining difficulty, corresponding to other members who placed deposits before the sudden drop in mining difficulty.

[0151] When an aggregate signature scheme such as BGLS is used, the procedure for the return of a member deposit may include additional requirements. For example, a node requesting return of a deposit may be required to attest (through its TEE) the deletion of both the private key share and the BGLS private key. If the recovering member attests that it has deleted both the private key share and the BGLS private key, other member nodes may only be configured to include their pre-commit or partial signatures in transactions returning the member deposit to the recovering member.

[0152] A collecting member node may be required to attest, through its TEE, to all transactions that it has pre-committed or committed. If the collecting member has not pre-committed any transaction that is determined to be unratified, other member nodes may simply be configured to include their pre-commit or partial signatures in transactions that return the member deposit to the collecting member.

[0153] The above procedure makes it unlikely that a fraudulent member would benefit from the withdrawal of a block from the TEE. The only pre-commits that the TEE could consider valid, other than those corresponding to confirmed SIDs, are those corresponding to BGLS private keys that no longer exist (this can happen with a high degree of probability only if the member has not provided the TEE with the latest block and the TEE has some members currently enrolled when in fact they had the Congress remove their key shares and reclaim their member deposits). Furthermore, as a result of the above, members cannot include their TEE in providing pre-commits to fraudulent (i.e., unratified) transactions and later be allowed to return their deposits by the Congress. Thus, members are incentivized to ensure that the TEE has an up-to-date copy of the blockchain (i.e., the main chain and the alt-chain).

[0154] Thus, the protocol may be secured by configuring nodes to operate according to a protocol that includes one or more of the following features: i) the TEE may be configured to require a threshold number of pre-commits to be observed on a second blockchain network (e.g., a proof-of-stake sidechain) before it outputs a partial signature for the pre-committed transaction; ii) a member may verify that its TEE a) proves the deletion of its private key shares and BGLS private key, and b) all transactions it pre-committed and none of them are determined (by consensus on the second blockchain network) to be unratified; iii) any block constructed in the TEE always contains (pre-)commits to ratified transactions that require them (i.e., ratified / pre-committed transactions that have not yet attracted the threshold (pre-)commits); iv) the TEE may be configured to respond to a sudden decrease in the mining difficulty observed on the main chain by outputting a pre-commit to the new mining difficulty (along with a hash of the block) to be mined on the second blockchain network. It will readjust the mining difficulty of the main chain and accept new members who join the main chain since the sudden drop in mining difficulty was observed only when provided with blocks from the second blockchain that contain pre-commits to the same mining difficulty, corresponding to other members who placed deposits before the sudden drop in mining difficulty.

[0155] The protocol supporting the second blockchain network described herein may be permissionlessly layered on top of an existing proof-of-work public blockchain protocol such as Bitcoin. This is because it interacts through the composition of digital signatures with a multi-party protocol that is external to the main chain (e.g., Bitcoin), which means that it may operate without the consent of the main chain's miners and developers. Thus, the protocol may be implemented "on top of" an existing public proof-of-work blockchain and is not subject to changes to the protocol of that public proof-of-work blockchain. In this sense, the protocol may be permissionlessly added to a blockchain (as the blockchain protocol itself does not need to be modified to accommodate the additional protocol). For example, the protocol may be used with any proof-of-work blockchain that authorizes transactions through a digital signature scheme. Currently, known implementations of public blockchains authorize transactions using digital signature schemes.

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

[0157] Although the above description has generally described the council as being implemented on a proof-of-work blockchain network, the council may instead be implemented on a proof-of-stake blockchain network.

[0158] In addition to the specific benefits and features already mentioned, the techniques described herein may provide additional benefits. For example, two-way pegs allow Turing-complete smart contract functionality to be added to a binary blockchain system that is composed of an existing proof-of-work blockchain (such as Bitcoin) and a proof-of-stake sidechain. More specifically, such functionality may be achieved by contributing to the proof-of-stake sidechain with a Turing-complete scripting language. Furthermore, at least some of the techniques described herein may provide a proof-of-stake blockchain that does not suffer from the nothing-at-stake problem of previous proposed implementations of proof-of-stake blockchains, and the benefits of faster and more regular block generation associated with traditional proof-of-stake schemes. Furthermore, at least some of the techniques described herein provide an incentive for miners of the proof-of-stake mechanism to hold a significant number of digital assets, which improves the security of the proof-of-work mechanism.

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

[0160] 100 Blockchain Networks 102 nodes 104 Minor 110 Parliament

Claims

1. A method implemented by nodes operating in a proof-of-work blockchain network and in a proof-of-stake blockchain network, the method comprising: participating in a parliament of members by transferring, by the node, one or more digital assets to a parliament pool having one or more other digital assets associated with other members of the parliament, where participating by transferring the one or more digital assets to the parliament pool includes adding the one or more digital assets to a proof-of-work blockchain; detecting, by the node, an ad hoc transaction of a digital asset on the proof-of-work blockchain network to an address associated with the congress pool, the ad hoc transaction meeting determined criteria; creating, by a node among the members of the assembly, one or more digital assets from the proof-of-work blockchain on a proof-of-stake blockchain network in response to detecting the extraordinary transaction; generating private key shares to be used in a threshold signature scheme, in which at least a threshold number of private key shares must be used to sign transactions on behalf of the congress, other holders of the private key shares being the other members of the congress who have joined the congress without permission by transferring their respective digital assets to the congress pool; The method includes:

2. 2. The method of claim 1, further comprising the step of determining that at least a threshold number of blocks have been added to a blockchain of the proof-of-work blockchain network after detecting the special transaction, and wherein the creating step is responsive to determining that at least the threshold number of blocks have been added.

3. Detecting, on the proof-of-stake blockchain network, a request to transfer the digital asset on the proof-of-stake blockchain network back to the proof-of-work blockchain network; responsive to detecting the request, using the private key share to cooperatively sign a transaction from the address associated with the congress pool; The method of claim 1 further comprising:

4. 4. The method of claim 3, further comprising determining, after detecting the request, that at least a threshold number of blocks have been added to a blockchain of the proof-of-stake blockchain network, and wherein using the private key share is responsive to determining that at least the threshold number of blocks have been added to a blockchain of the proof-of-stake blockchain network.

5. 5. The method of claim 4, wherein the determination that at least the threshold number of blocks have been added to a blockchain of a proof-of-stake blockchain network is performed within a trusted execution environment on the node.

6. 6. The method of claim 4 or 5, further comprising the step of validating the request in a trusted execution environment prior to the step of using the private key share.

7. 7. The method of claim 3, further comprising burning the digital asset associated with the request on the proof-of-stake blockchain network by the request.

8. The method of claim 1 , wherein the threshold signature scheme is an Elliptic Curve Digital Signature Algorithm.

9. The method of claim 1 , wherein the steps of generating a private key share and using the private key share are performed in a trusted execution environment within the node.

10. The method of any one of claims 1 to 8, wherein the step of creating on the proof-of-stake blockchain network is performed by a node selected by the proof-of-stake blockchain network, and the probability of the node being selected is based on the amount of digital assets the node has deposited in the congress pool.

11. A computer readable storage medium storing computer executable instructions which, when executed by a processor of an electronic device, cause the electronic device to perform the method of any one of claims 1 to 10.

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

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

Images