Secure Blockchain-Based Consensus

Abstract

To provide a method and system for activating a script related to a distributed ledger.SOLUTION: A method includes: broadcasting a transaction, by a node in a blockchain network, to a congress pool to join a congress formed of a group of nodes; after the congress accepting a request from a requester to activate a script, preparing, by the node, a blockchain transaction cryptographically locked with a public key associated with the congress pool; cooperatively generating, by the node cooperating with other nodes of the group, a valid cryptographic signature for the transaction to spend the transaction; after the blockchain transaction being unlocked, receiving data from a plurality of information providing systems; determining a center point for the data received from the plurality of information providing systems; and activating, by the node in cooperation with other nodes of the congress, the script based on the center point.SELECTED DRAWING: None

Description

Technical Field

[0001] The present invention generally relates to distributed ledgers, and more specifically, to a method and system for launching a script related to such a distributed ledger. The present invention is particularly suitable for launching such a script based on information not available in a distributed ledger, but is not limited thereto.

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

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, where blocks are 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 each transaction includes at least one input and at least one output. Since each block contains the hash of the previous block, these blocks are chained together to create a permanent and immutable record of all transactions written to the blockchain from its start. Transactions include a small program known as a script embedded in their inputs and outputs, and the script specifies who can access the output of the transaction and how. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

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

[0005] Blockchain technology is most widely known for its use in cryptocurrency implementations, but digital entrepreneurs are beginning to explore the use of both the Bitcoin-based cryptographic security system and the data that can be stored on the blockchain to implement new systems. It would be very advantageous if the blockchain could be used for automated tasks and processes not limited to the cryptocurrency realm. Such solutions could expand the application's uses while leveraging the advantages of the blockchain (such as a permanent tamper-proof record of events, distributed processing, etc.).

[0006] Blockchain technology has been used to provide a platform for smart contracts (automation of contracts). A smart contract is a computerized transaction protocol that executes the terms of a contract. When implemented on a blockchain, a smart contract is a computerized protocol that is stored on the blockchain and triggered by blockchain transactions, and this protocol can write data to the blockchain at runtime. When implemented on a blockchain, a smart contract can be displayed to all users of the blockchain network.

[0007] In most cases, smart contracts need to be activated by a message or a transaction. That is, a smart contract typically needs to be poked by an external agent with respect to the code to be executed. Furthermore, a smart contract typically cannot access information outside of the blockchain itself. Without access to such information, a smart contract may not be able to determine which terms of the contract should be executed / enforced. To obtain such external information, a trusted external agent is sometimes used to provide access to information outside of the blockchain and required by the smart contract. Relying on a trusted external agent reduces the autonomy and self-executing nature of the smart contract. Relying on a trusted external agent may reduce the security and usefulness of the smart contract. SUMMARY OF THE INVENTION

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

[0009] As will be described in more detail below, a congress can be formed on a blockchain network. A congress is an open membership group where any node within the blockchain network can participate upon submitting sufficient stake to a pool associated with the congress. For example, a node can participate in the congress by transferring digital currency (such as Bitcoin), tokens, or other digital assets such as stake or consideration to an account associated with the congress. Advantageously, a congress can be used to securely launch scripts such as smart contracts. For example, a congress can be used to reliably provide data from an external source to a script. A congress can be used to securely reach consensus in a distributed system where message exchange between nodes is not secure. For example, a congress can reliably provide data from an external source to a script and can provide the data securely even if communication between nodes within the congress is not secure.

[0010] Therefore, according to the present invention, a method implemented by a computer can be provided. The method implemented by a computer includes: i) a step of broadcasting a transaction to a congress pool by a node in a blockchain network to participate in a congress formed by a group of nodes; ii) a step of preparing a transaction to pay to the congress pool by a node after the congress accepts a request to activate a script from a requester, wherein the transaction is configured such that a plurality of information providing systems can add an input to the transaction; iii) a step of cooperatively generating a valid signature for spending the transaction related to the transaction by a node cooperating with other nodes in the group after the input is added to the transaction; iv) a step of receiving data from a plurality of information providing systems after the transaction is spent; v) a step of determining a centre point of the data received from the plurality of information providing systems; and vi) a step of activating a script based on the centre point by a node cooperating with other nodes in the congress.

[0011] In some embodiments, a computer-implemented method is provided. The computer-implemented method includes: i) a step of broadcasting, by a node in a blockchain network, a transaction to a congress pool to participate in a congress formed by a group of nodes; ii) a step of preparing, by the node, a blockchain transaction encrypted and locked with a public key associated with the congress after the congress accepts a request to activate a script from a requester, wherein the blockchain transaction is configured such that a plurality of information providing systems can add inputs to the blockchain transaction; iii) a step of cooperatively generating, by a node cooperating with other nodes in the group, a valid cryptographic signature of the blockchain transaction and unlocking the blockchain transaction after the input is added to the blockchain transaction; iv) a step of receiving data from a plurality of information providing systems after the transaction is unlocked; v) a step of determining a central point of the data received from the plurality of information providing systems; and vi) a step of activating a script based on the central point by a node cooperating with other nodes in the congress.

[0012] In some embodiments, the computer-implemented method includes: i) a step of identifying, by a node based on the central point, a subset of information providing systems that provided data near the central point; and ii) a step of permitting, by a node cooperating with other nodes in the group, a transfer of digital assets (i.e., tokens) to each information provider (i.e., each information providing system in the subset) within the subset.

[0013] In some embodiments, the digital assets (i.e., tokens) included in the transfer include one or more digital assets (i.e., tokens) received from the requester to the congressional pool. In some embodiments, the request includes a threshold indicator, and the subset is identified based on the threshold indicator. The threshold indicator can be received from the requester.

[0014] In some embodiments, the input to the transaction (i.e., the input to the blockchain transaction) includes respective proof of solution data, and the method includes determining, based on the proof of solution data, that the data received from at least one of the information providing systems corresponds to the committed solution.

[0015] In some embodiments, the input to the transaction (i.e., the input to the blockchain transaction) includes respective proof of solution data, and the method further includes: i) determining that the data received from at least one of the information providing systems does not correspond (match) to the proof of solution data received from that information providing system; and ii) discarding the data if it is determined that the data received from at least one of the information providing systems does not correspond to the committed solution based on the proof of solution data.

[0016] In some embodiments, the input to the transaction includes digital assets (i.e., tokens) held as collateral (i.e., locked for security).

[0017] In some embodiments, the information providing system includes, in a transaction (i.e., a blockchain transaction), a public key, a solution to a request, and a hash based on a salt. In some embodiments, the data received from multiple information providing systems includes a public key, a solution to a request, and a salt. This method can further include: i) generating a hash based on the public key, the solution to the request, and the salt; and ii) comparing the generated hash with the hash included in the transaction (i.e., the blockchain transaction).

[0018] In some embodiments, the computer-implemented method further includes: i) detecting malicious activities by a malicious party, where the malicious party is one of the nodes of the congress; and ii) using a secret key share to confiscate at least a portion of the digital assets (i.e., tokens) previously transferred to the congress pool by the malicious party. The step of confiscating may include transferring to an unspendable account.

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

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

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

DETAILED DESCRIPTION OF THE INVENTION

[0022] Blockchain network Referring initially to FIG. 1, this figure shows in block diagram form an exemplary blockchain network 100 related to a blockchain. The blockchain network can be a public blockchain network, which is a peer-to-peer open membership network where anyone can participate without an invitation or the consent of other members. Distributed electronic devices that execute an instance of the blockchain protocol on which the blockchain network 100 operates can participate in the blockchain network 100. Such distributed electronic devices can be referred to as nodes 102. The blockchain protocol can be, for example, the Bitcoin protocol.

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

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

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

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

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

[0028] In the case of bitcoin, there is a one-to-one correspondence between the public key and the address. That is, each public key is associated with a single address. Thus, references here to the transfer of digital assets between public keys (e.g., payments to public keys) and to the transfer of digital assets to the address associated with that public key refer to general operations.

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

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

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

[0032] Congress 110 is an open membership group in which nodes 102 can participate upon submitting sufficient contributions to a pool associated with Congress 110. For example, a node can participate in the Congress by transferring digital currency (such as Bitcoin), tokens, or other digital assets such as contributions or consideration to an account associated with Congress 110. Nodes 102 participating in the Congress can be nodes within a blockchain network, including both mining nodes and non-mining nodes. In at least some applications of the Congress, nodes functioning as Congress members monitor the blockchain in the sense of downloading (but not necessarily retaining) the complete blockchain.

[0033] The methods of joining, leaving, and participating in Congress 110 will be described in more detail below.

[0034] An electronic device operating as a node FIG. 2 is a block diagram showing components of an exemplary electronic device 200 that can function as node 102 (FIG. 1) in a peer-to-peer blockchain network 100 (FIG. 1). The exemplary electronic device 200 may also be referred to as a processing device. The electronic device can take various forms, including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smartwatch, or another type of form.

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

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

[0037] In FIG. 2, the memory 220 is shown as a single block, but in reality, the electronic device 200 may include a plurality of 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. Further, although the memory 220 is shown separately from the processor 210, the processor 210 may include embedded memory.

[0038] As shown in FIG. 2, the processor 210 can include a secure area such as a Trusted Execution Environment (TEE) 250. The TEE 250 is an isolated execution environment that provides additional security such as execution in an isolated state, integration of trusted applications, and confidentiality of assets to the electronic device 200. The TEE 250 provides an execution space that guarantees that the computer instructions and data loaded within the TEE 250 are protected from a confidentiality and integrity perspective. The TEE 250 can be used to protect the integrity and confidentiality of important resources such as keys. Since the TEE 250 is implemented at least partially at the hardware level, the instructions and data executed within the TEE 250 are protected against access and manipulation from the rest of the electronic device 200 and external parties such as the owner of the electronic device. The data and calculations within the TEE 250 are security protected from the parties operating the node 102 including the TEE 250.

[0039] The TEE 250 can operate to instantiate an enclave while hashing cumulatively and adding memory pages one by one at a time. Since the same operation can be performed on a remote machine (which can be a development machine or another machine), the remote machine determines and stores the expected hash. Therefore, the content of the enclave can be verified on the remote machine to confirm that the enclave is executing an approved algorithm. This verification can be performed by comparing the hashes. Once the enclave is fully constructed, the enclave is locked down. It is possible to execute code and send secrets to the code in the TEE 250, but the code cannot be changed. The final hash can be signed by an authentication key and the data owner can be allowed to utilize the authentication key to verify it before sending the secret to the enclave.

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

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

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

[0043] The TEE250 can be implemented using various platforms such as the Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). For example, SGX supports remote attestation. This allows the enclave to obtain a signed statement, called a quote, from a given member of the processor on which a particular enclave is running. A third-party attestation service such as the Intel Attestation Service (IAS) can prove that these signed statements are from a genuine CPU compliant with the SGX specification.

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

[0045] Congress and Threshold Signatures Congress 110 can be either an authorized group or an unauthorized group. That is, any node 102 (Figure 1) within the blockchain network 100 (Figure 1) can participate in Congress 110 (i.e., any node that monitors and stores at least a portion of the information within the blockchain). To participate in Congress 110, a node 102 transfers one or more digital assets to a digital asset pool associated with Congress 110 (i.e., to a public group address associated with one or more digital assets and then associated with other members of the Congress). This digital asset pool can be referred to as the Congress pool. For example, a node 102 can participate in Congress 110 by transferring (i.e., depositing) such digital assets to an address associated with the Congress pool (i.e., a "Congress address" which can also be referred to as a public group address). The digital assets are placed under the management of a group threshold signature with a single public key called the Congress public key. Congress members hold distributively generated secret key shares. The number of shares held can be proportional to the amount deposited in the pool.

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

[0047] The Congressional public key encumbers digital assets deposited into the Congressional pool by members of the 110th Congress in exchange for secret key shares, and digital assets deposited into addresses associated with the Congressional pool by members or non-members of the 110th Congress (i.e., placed under the complete, partial, or conditional control of Congress) (deposited for reasons other than obtaining secret key shares). Non-members or members can deposit digital assets into addresses associated with Congress for various reasons. In one example described in more detail below, a member or non-member can deposit digital assets with the 110th Congress to move such assets to another blockchain (which may be referred to as an alternative chain such as a side chain). A side chain can be a blockchain that runs in parallel with the main blockchain (i.e., alongside the main chain).

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

[0049] Congress 110 can function as an autonomous group that enforces cooperative behavior by threatening to confiscate all or part of the member deposits. By having many honest members participate in a cooperative protocol, such digital assets of non - cooperative or malicious members can be confiscated. That is, to ensure that all nodes 102 operate in accordance with a predefined protocol or standard, member deposits to the Congress pool can be subject to confiscation. Confiscation means permanently preventing the return of the member deposits deemed to be confiscated. The digital assets that form the member deposits and are not returned due to malicious activities can be left in the Congress pool, but if not returned (e.g., if a consensus is obtained (on the Alt - chain) that they should not be returned), they are transferred to an immediately or future - in - accessible address, or otherwise may be confiscated. The nature of the confiscation can vary depending on whether Congress functions as a bonded validator set of the side - chain.

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

[0051] The threshold signature scheme implemented by Congress 110 can be of various types. A threshold signature scheme enables sharing of signature capabilities among n parties as long as at least the threshold number of secret key shares contribute to the generation of a valid signature. A subset smaller than the threshold cannot generate a valid signature. More specifically, each party manages the sharing of the secret signature key, and to combine partial signatures to generate a valid signature, the threshold number of key shares must be used. A subset of key shares less than the threshold cannot generate a valid signature.

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

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

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

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

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

[0057] Malicious acts such as providing inconsistent shares to different nodes can be addressed by Congress 110 to prevent malicious behavior. For example, if a certain node 102 (Figure 1) is identified as a malicious party by other nodes 102, a number of nodes 102 (i.e., nodes associated with Congress members) exceeding a threshold (e.g., t + 1) can cooperate to punish the malicious party. For example, node 102 can act in relation to digital assets (digital currency, tokens, or other contributions and considerations, etc.) deposited with Congress by a malicious party. For example, Congress can transfer digital currency, tokens, contributions, and considerations to an unspendable address and burn them, or Congress can confiscate such digital assets by obtaining consensus with other nodes and denying approval for return to the malicious party. Nodes 102 that are not the nodes performing malicious acts can also prevent malicious acts by cooperating to exclude the nodes performing malicious acts (e.g., by effectively invalidating key shares, e.g., by excluding nodes from participation in the Congress protocol, or by re-sharing the secret key and not allocating shares to the nodes performing malicious acts).

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

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

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

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

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

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

[0064] Starting the Congress Referring now to FIG. 3, a method 300 for starting a congress 110 is shown. Method 300 can be initially executed by a trusted party to set up the congress 110. That is, a node 102 associated with the initially trusted party can execute method 300.

[0065] Method 300 includes, in operation 302, providing a congress public key. The congress public key is provided to other nodes 102 and can enable these other nodes to make payments to the congress public key if they wish to participate in the congress. That is, other nodes can transfer digital assets to an address associated with the congress public key to participate in the congress.

[0066] The node 102 that executes method 300 permits payment to the public key in operation 304 until one or more conditions are met. For example, the node may permit payment to the public key for a determined period or number of blocks. After the conditions are met (e.g., after the expiration of this period or after the mining of the number of blocks), the node 102 that executes method 300 identifies the initial members of the congress in operation 306.

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

[0068] During operation 308, the node 102 identified as a congressional member cooperates to generate a new secret key share and a new public key. The original key share sent to such a node by the initially trusted party may be used to sign and broadcast a transaction that sends all the digital assets in the congressional pool to the new public key, which then becomes the congressional public key. That is, during operation 308, a new public group address is established, and the digital assets under the control of the congress are transferred to this new address, which becomes the new address of the group and is associated with the congressional public key. After this transfer is confirmed, the congress can operate trustlessly (a mechanism exists for all parties within the system to reach a consensus on what to consider as legitimate truth). The new public group address is formed so that other nodes wishing to join the congress or for other purposes as described above can receive future deposits of digital assets. Here, the congressional members are considered to be registered with the congress, and these nodes can operate without the assistance of the initially trusted party. Further, the initially trusted party is no longer involved in any part of the congress's operation.

[0069] Participation in Congress after Congress has been initiated Referring now to FIG. 4, this figure shows a method 400 for participating in a congress. The method 400 of FIG. 4 may operate in relation to the method 300 of FIG. 3, but the method 400 of FIG. 4 is executed by a different one of the nodes 102 operating in the same blockchain network 100 (FIG. 1) that is operated by the node executing the method 300 of FIG. 3. The method 400 of FIG. 4 includes, in operation 402, the step of obtaining a congress public key. The congress public key can be obtained directly from a person starting the congress, such as the node executing the method 300 of FIG. 3, or can be obtained from a third party, including, for example, a third party system operating outside the blockchain network 100 (FIG. 1). For example, the congress public key can be obtained from a public web server accessible via the public internet.

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

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

[0072] After depositing the digital asset into the congress pool, in operation 406, node 102 that executes method 400 receives a secret key share. Next, in operation 408, node 102 regenerates the secret key share by executing a single instance of the protocol. The generation of the secret key share may be executed within the TEE of node 102.

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

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

Number

Number

Number

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

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

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

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

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

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

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

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

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

[0084] To ensure that all nodes 102 operate in accordance with pre - defined protocols or criteria, the member deposits into the congress pool can be subject to forfeiture. Forfeiture means permanently preventing the return of the member deposits deemed to be forfeited. Digital assets that form the member deposits and are not returned due to malicious activities can be left in the congress pool, but (depending on the consensus that this measure should be taken) may not be returned, and may be immediately or in the future transferred to another unspendable address or forfeited. The nature of the forfeiture may depend on whether the congress functions as a side - chain hold - back verification set. For example, in operation 504, in response to detecting malicious activities by a malicious party, the node 102 executing method 500 can use the secret key share to provide a partial signature for a forfeiture transaction (a transaction that transfers digital assets to another node as a reward for exposing the unspendable address or malicious activities). That is, the node cooperates with other nodes in the congress to forfeit at least a portion of the digital assets previously transferred to the public group address (i.e., the congress pool) by the malicious party. That is, in response to confirming that a group member has violated the pre - defined protocol or criteria, the secret key share is utilized to contribute to the approval of a transaction of one or more digital assets associated with that group member and held within the congress pool.

[0085] Since the threshold signature scheme is used with the congress public key, an individual node acting alone cannot transfer the deposits of another congress member's digital assets to a location separate from the congress pool (e.g., to an unspendable address). Rather, the digital assets are forfeited by transfer only when each member uses a threshold number of secret key shares to generate a valid signature for transferring the digital assets to another address, or when at least a group of members that amounts to the threshold number of secret key shares reaches a consensus to put a member on hold (in operation 503). Withdrawal requests from the put-on-hold member are automatically ignored. When digital assets are forfeited by transfer, the other address to which the digital assets can be transferred can be associated with an unspendable address. For example, this other address may be an address without a secret key, and access to the digital assets associated with the public key of this address can be made inaccessible to anyone. When a transaction transferring digital assets to an unspendable address is confirmed, or when a consensus that the digital assets should be forfeited is obtained on the side chain, the digital assets can be considered burned because they are no longer on hold by any member of the congress or actually by any node within the blockchain network 100.

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

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

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

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

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

[0091] In response to the detection of a request in operation 602, its fulfillment involves the re - distribution of key shares. In operation 604, a new secret key share is generated by node 102 in the same way as the method in which the secret key share was generated in operation 408 of method 400 in FIG. 4. Other member nodes of the congress also generate their respective secret key shares. These secret key shares can be used in the threshold signature scheme of the new congress public key. At this point, a member who withdraws from the congress does not generate a new secret key share during operation 604, and since the member who withdraws is not assigned a secret key share for use with the new congress public key, the member who withdraws loses the ability to participate in the congress and is no longer regarded as a congress member.

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

[0093] Thus, according to method 600 of FIG. 6, when the deposit distribution is changed or when a request to withdraw a deposit from a member is received, the secret key shares are regenerated and all digital assets under the management of the congress can be moved to the new public key. The frequency with which the congress members can be updated can be limited by the block time of the blockchain network 100. In many applications, only low-frequency rebalancing may be required.

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

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

[0096] In operation 702, node 102 can use one or more attributes included in at least a portion of a transaction to the public group address of the digital assets to identify congress members (i.e., those who transfer digital assets to the congress public key to participate in the congress and not for other purposes). For example, a particular transaction may be flagged as a special transaction using the attributes of the transaction. Such attributes (or the presence or absence thereof) may indicate the purpose of the transfer. For example, a transaction may include a flag if the transferor is not requesting to participate in the congress.

[0097] When a member withdraws from the congress using method 700, the member can securely delete their secret key share. To ensure that the old member's secret key share cannot be used, members of the congress may be required to use node 102 with a special TEE. A TEE is an architecture implemented at the hardware level that ensures that the instructions and data executed within the TEE are protected from access and manipulation by the rest of the system. The TEE can use hardware mechanisms to address the issue of remote authentication that can be used to verify the integrity of the system to external parties such as other nodes of the congress.

[0098] Each member node can use an authenticated TEE configured to generate one or more random secret values that remain inaccessible to the host system without damaging the hardware at the integrated circuit level. The secret values generated in this way are used in the distribution generation of the secret key share (e.g., in operation 410 of method 400 in FIG. 4). This secret value can also be used to establish a shared public key that is shared during the setup phase of the congress. Since the calculations associated with the setup protocol are executed within the enclave of the TEE, a member or a former member cannot obtain information about their own or other secret key shares from member - to - member communication or other means. The enclave within the TEE enables the execution of a remote authentication protocol that can be used to prove to other nodes that the TEE enclave is genuine and executing approved computer - readable instructions.

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

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

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

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

[0103] Unregistration from the Congress As described above, group members may sometimes request to withdraw from the Congress, and when unregistering a group member from the Congress, the digital assets deposited in the Congress pool may be returned to that group member. Referring to FIG. 8 here, an exemplary method 800 for returning the deposit is shown in flowchart form. This method may be executed by node 102 in cooperation with other nodes 102 of the Congress.

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

[0105] In response to receiving the request, node 102 evaluates the request against the determined criteria in operation 804. Such criteria may be pre-specified criteria. When the Congress operates according to a Congress protocol in which the Congress public key is not changed each time the group membership is changed, in operation 804, node 102 can confirm that the secret key share has been deleted by the requester. Such confirmation can be obtained using a remote authentication protocol related to the TEE.

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

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

[0108] Trustless agent with respect to smart contracts (trustless: not relying on a centralized system) The congress provides a secure mechanism for performing various functions, and the congress protocol can be used for various purposes. Generally, the congress operates in a trustless manner and manages the ownership of digital assets.

[0109] The Congress Protocol can be used, for example, to provide a trustless agent with respect to a smart contract. More specifically, the Congress Protocol can be used to initiate a script such as a smart contract. Activating a smart contract can "poke" (activate) the smart contract to execute one or more functions of the smart contract, or activating a smart contract can provide external data to the smart contract. That is, data outside the blockchain network in which the smart contract is executed can be securely obtained and used in combination with the smart contract using the Congress Protocol. Accordingly, the Congress Protocol can be used to provide autonomous initiation (i.e., "poke") of blockchain scripts related to smart contracts, or to provide access to external data (i.e., data that was not previously available on the blockchain) to such blockchain scripts. As will be described in detail below, the Congress Protocol can be used to provide pokers of smart contracts and data feeds of smart contracts on a blockchain network.

[0110] Referring now to FIG. 9, a system for initiating a script on a blockchain network 900 is shown in block diagram form. The system includes a plurality of nodes 102a, 102b, 102c that can be nodes of a blockchain network such as the blockchain network of FIG. 1. The nodes 102 include a plurality of Congress nodes 102a. The Congress nodes are nodes that have joined a group of the blockchain network 900, referred to herein as Congress 110. The Congress nodes may have joined the group in the manner described above with reference to FIG. 4.

[0111] At least one of the nodes within the system of FIG. 9 is the requester node 102b. The requester node 102b is the node that issues a startup request for a script. Such a request may be accompanied by the deposit of a digital asset that functions as a reward. More specifically, the digital asset is held between nodes for distribution and can facilitate the fulfillment of the request. For example, the reward is distributed between information providing systems that support the fulfillment of the request and between congress members who provide security and reliability to the protocol by participating.

[0112] The request is a request to obtain external data (i.e., data not yet available in the blockchain network) and provide such data to a script such as a smart contract, or alternatively, it can be a request to start such a script. For example, the request is a request to trigger a smart contract when specified conditions are met (e.g., activate the smart contract at a specific time or when external data meets the specified conditions).

[0113] The nodes of the blockchain network 900 also include a plurality of information providing systems that may also be referred to as information providing nodes 102c. These information providing nodes 102c are electronic devices aimed at fulfilling or assisting in the fulfillment of requests issued by the requester node 102b. For example, the information providing node 102c can be operated to search for data from an external data source such as a web server.

[0114] As will be described in more detail below, the information providing node generally functions to satisfy requests issued by the requester node, while the congress node cooperates to provide security and reliability. For example, the congress node can be operated to enhance the accuracy of information or actions executed or provided by the information providing node for the purpose of fulfilling the request.

[0115] Accordingly, a node 102 (FIG. 1) within the blockchain network 100 (FIG. 1) can implement a trustless agent protocol to launch or facilitate the launch of a script such as a smart contract. Such a node 102 can include computer-executable instructions stored in a memory 220 (FIG. 2) that implement such a protocol. When executed by a processor 210 (FIG. 2), such instructions cause a node 102 (such as an electronic device 200 of the type described with reference to FIG. 2) to execute one or more ways of the protocol. Such ways can include any one or a combination of the ways 300, 400, 500, 600, 700, 800, 1000, or 1100 of FIGS. 3-8, 10, and 11.

[0116] Referring now to FIG. 10, this figure shows a method that can be performed by a requester node 102b (FIG. 9). The method of FIG. 10 can be referred to as a requester method 1000. The requester node 102b can be a node associated with a script, such as a party to a smart contract on a blockchain network.

[0117] In operation 1002 of method 1000 (FIG. 10) by the requester, the requester node 102b issues a request. The request is a request to start a script such as a smart contract. Instead of making the script safely and surely active, the request provides a reward in the form of a digital asset associated with the blockchain network 100. The request may include various information including one or more of: an identifier of the script associated with the request, such as a public key associated with the script state; minimum participant information that may specify the minimum number of information providing systems to be used to start the script; fee information such as a mining fee provided to the congress to facilitate the start of the script; and / or a threshold indicator that defines an acceptable amount of variation from the consensus data and / or information regarding external data used in the start of the script. Instead of or in addition to the above-described data, other data may be included in the request.

[0118] The request may be issued from outside the blockchain (i.e., "off-chain"). For example, the request can be issued from a web server accessible via the Internet. For example, the request can be issued from an exchange. The exchange can be a server where multiple requests from multiple requester nodes are published.

[0119] In operation 1004 of method 1000 by the requester, the requester node 102b determines that one or more congresses have accepted the request. That is, the requester node 102b determines that the congress (composed of a plurality of congress nodes 102a) has offered to start the script according to the request.

[0120] In operation 1006, the claimant node 102b can select one or more congresses that have accepted the request. The claimant node 102b may, for example, evaluate the reputation data of each congress against one or more thresholds. The reputation data may be based on, for example, ratings or other metrics provided by other claimant nodes 102b that have previously participated in the relevant congress to facilitate the completion of the request.

[0121] The claimant node 102b may select a single congress among the congresses that have accepted the request, or the claimant node 102b may select a plurality of such congresses. The claimant node 102b may select all of the congresses that have accepted the request or a subset of such congresses. By selecting a plurality of congresses, the selected congresses can be effectively made to compete with each other.

[0122] In operation 1008 of the method by the claimant, the claimant node broadcasts a transaction (which may be referred to as a blockchain transaction) to be paid to the congress pool associated with the selected congress. The transaction includes, in the form of digital assets, a reward to be paid to the public group address associated with the congress that has accepted the request and was selected in operation 1006. The transaction may include a link to the data related to the request. For example, the link may be a link to a server that stores information about the request. Such information may include, for example, an identifier of the script related to the request, such as a public key related to the script state; minimum participant information that may specify the minimum number of information providing systems used to activate the script; fee information such as a mining fee provided to the congress to facilitate the activation of the script; a threshold indicator that defines an acceptable amount of variation from the consensus data and / or information about external data used in the activation of the script, or other information, conditions, requirements.

[0123] Transactions that include a reward are time-locked, so the transaction becomes valid only at a specified future time. Due to the time lock, the transaction may not be added to the blockchain until the specified time has elapsed.

[0124] If multiple congresses are selected (in operation 1006) to facilitate the completion of the request, the transaction locks the reward, so that only the congress that completed the request the fastest can claim the reward.

[0125] Referring now to FIG. 11, a congress method 1100 is shown. The congress method 1100 can be executed by a congress node in cooperation with other nodes of the congress. That is, the congress node may be composed of computer-executable instructions for executing method 1100 in cooperation with other nodes of the congress. That is, the congress method 1100 can be executed by one or more nodes that participate in the congress and become congress nodes. More specifically, a node in the blockchain network can participate in a congress formed by a group of congress nodes by broadcasting a transaction to the congress pool. The transaction transfers (transfers) the control (management) of one or more digital assets to the congress. Such digital assets function as member deposits of the depositing members and are subject to confiscation as described above with reference to FIG. 5. The technology for participating in the congress is described in more detail above, particularly with reference to FIG. 4.

[0126] After a node participates in the congress and becomes a congress node, the method 1100 of FIG. 11 can be executed by that congress node in cooperation with other congress nodes of the same congress.

[0127] In operation 1102, the congress node identifies a request. The request can be a request issued by the requester in operation 1002 of method 1000 of FIG. 10.

[0128] In operation 1104, the Congress node, in cooperation with other nodes of the Congress, accepts a request. The acceptance of the request may be notified to the requester node that issued the request. The Congress nodes can be configured to cooperate with each other before accepting the request to determine whether to accept the request. For example, the Congress nodes may obtain a consensus on whether to accept the request. For example, a consensus may be obtained by using secret key sharing. That is, the Congress members can effectively vote on whether to accept the request by using secret key sharing. The request is accepted by the Congress when at least a threshold number of secret key sharings are effectively used to vote to accept the request. This voting procedure may occur, for example, in a side chain (i.e., a blockchain other than the main blockchain).

[0129] After the Congress accepts a request from a requester and launches a script, the Congress node can detect, in operation 1106, a transaction from the requester that includes a reward related to the request. That is, the Congress node can determine that the transaction broadcast by the requester in operation 1008 of method 1000 has been added to the blockchain. As described above, the transaction broadcast in operation 1008 may be time-locked so as not to add the transaction to the blockchain until a specific time. In such a case, operation 1106 is executed after that time.

[0130] When a transaction broadcast in operation 1008 (which may be referred to as the "first transaction") is determined by the Congress node to be confirmed (which may occur after at least a threshold number of blocks are created on top of that first transaction), the node prepares (in operation 1108) a transaction (which may be referred to as the "second transaction") to be paid to the Congress pool (i.e., the public group address associated with the Congress), and publishes that transaction.

[0131] The second transaction may be configured such that a plurality of information providing systems (e.g., the information providing node 102c of FIG. 9) can add inputs to the transaction. For example, the second transaction can be signed with SIGHASH_ALL|SIGHASH_ANYONECANPAY. SIGHASH_ALL is the default signature hash type that signs the entire transaction except for the signature script, preventing changes to the signed parts. SIGHASH_ANYONECANPAY is a signature hash type that signs only the current inputs.

[0132] Next, an information providing system such as the information providing node 102c can commit to the completion of the request. To do so, the information providing system adds to the second transaction. For example, the information providing system adds digital assets held by the information providing system as an input to the second transaction. Such digital assets are provided by the information providing system as security to ensure that the information providing system operates in accordance with the request and the protocol (i.e., those digital assets are held as a security deposit).

[0133] In addition, the information providing system adds proof of solution data as metadata to the second transaction. For example, a hash based on the solution to the request can be added to the second transaction. The solution can be external data such as data available via the Internet or from another data source required for the operation of the script. In such a case, the proof of solution data can be a hash based on the external data. The hash may be based on the public key of the information providing system and / or a salt for security. A salt is random data used as an additional input to the hash function. As an example, the second transaction is updated by the information providing system to include metadata determined as HASH(q+PK+s), where q is the solution, PK is the public key of the information providing system, and s is the salt.

[0134] The Congress may keep participation in the second transaction open until one or more predefined conditions are met. The predefined conditions may be, for example, time-based conditions. For example, the predefined conditions may include ending participation when at least a threshold amount of time has elapsed since the issuance of the second transaction. That is, a certain period of time during which the information providing system can participate may be provided. When that period expires, the information providing system (node) may no longer be permitted to participate.

[0135] The predefined conditions may require participation of at least a threshold number of information providing systems. That is, participation in the second transaction can be kept open until at least a threshold number of information providing systems commit to completing the request by adding their respective deposits as inputs to the second transaction.

[0136] The predefined conditions for keeping the participation open may be specified by the congress or by the requester. For example, the requester can include the predefined conditions in the request.

[0137] In operation 1110, after determining that the predefined conditions are met (e.g., after an input is added to a transaction by the information providing system), the congress locks the participation of the information providing system. That is, the congress node executing method 1100 can cooperate with other congress nodes to prevent additional commitments from being added to the second transaction. The congress node can do so by cooperating with other congress nodes to use the second transaction (i.e., unlock the lock of the second transaction). More specifically, the congress node can cooperate with such other congress nodes to jointly generate a valid cryptographic signature for using the transaction regarding the transaction using the secret key share held by the congress node. Such a congress node may cooperate by adding partial signatures generated based on each secret key share until a valid signature is generated according to a threshold signature scheme. When the second transaction is mined and a sufficient number of blocks are added on top of that second transaction and it is confirmed, the transaction is considered spent.

[0138] The second transaction functions as a register of the information providing system that has committed to the completion of the request. That is, the second transaction indicates that there is a solution to the request and functions as a register of the information providing system that has committed to providing the solution. The second transaction also functions to collect deposits from each participating information providing system and to provide the proof of solution that the information providing system is trying to send, thereby making the value unchangeable later and preventing the value from being copied by other participants.

[0139] After the second transaction is used, in operation 1112, the congress node can receive data from a plurality of information providing systems that added the input to the second transaction. For example, the solutions proposed by each information providing system are provided to the congress node by the information providing system here. Solution q can be sent together with other information used in the hash added to the second transaction by the information providing system. For example, solution q can be provided together with the public key PK of the information providing system and the salt s.

[0140] After receiving the data in operation 1112, the congress node may confirm that solution q corresponds to the solution that was committed (i.e., the solution identified by the proof of solution data of the second transaction). For example, the congress node can perform a hash (i.e., HASH(q+PK+s)) on solution q, the public key PK, and the salt s. This hash can be compared with the hash of the second transaction to determine whether the solution corresponds to the solution that was committed. If the solution does not correspond to the solution that was committed (e.g., if the generated hash does not correspond to the hash of the second transaction), the solution (i.e., the data representing that solution) is discarded and the following operations of method 1000 are not used.

[0141] In operation 1114, the Congress node cooperates with other Congress nodes to identify the correct data (e.g., the correct solution) for the request. The Congress node can, for example, determine the central point of the data received from multiple information providing systems. For example, when the data represents numerical values, the central point can be the average value of all the values received from the information providing systems in operation 1112 (i.e., the central point can be determined as the average of all the received values). As a further example, in some embodiments, the central point can be the most common value or solution received from the information providing systems (i.e., the central point can be determined as the mode (most frequent value) of all the received values). As a further example, in some embodiments, the central point can be the median value received from the information providing systems (i.e., the central point can be determined as the median of all the received values). The central point can be determined based on the data received from the requester. For example, the requester can specify the technique to be used to identify the central point, and in operation 1114, the Congress can use the specified technique.

[0142] The central point can be selected by consensus of the Congress nodes. As an example, the determination of the central point can be performed on a side chain, and the Congress nodes can cooperate to generate a valid signature for the transaction representing the central point using their respective secret key shares. Once a valid signature is generated, this indicates that the Congress has reached an agreement regarding the central point.

[0143] In operation 1116, the Congress node, in cooperation with other nodes of the Congress, identifies the information providing systems that provided correct data. That is, the Congress node can identify a subset of the information providing systems that provided data with the intention of fulfilling the request. The subset consists of information providing systems that provided data that is close enough to the correct data identified in operation 1114. For example, the node can identify, as the subset, the information providing systems that provided data near the center point identified in operation 1114. Depending on the situation, all of the information providing systems that provided data may have provided correct data, and in other situations, only some of such information providing systems may have provided correct data.

[0144] To identify the information providing systems that provided data close enough to the correct data, a threshold may be used. The threshold can be specified by the requester. For example, the request issued by the requester may include a threshold indicator. The threshold indicator can be included in the request itself or linked to the request. That is, the request may be linked to data such as data on the server that defines the threshold indicator. The threshold indicator defines the required accuracy and can be used to identify a subset of the information providers that are considered to have sent correct information. For example, the threshold indicator may specify a percentage or other metric used to determine whether the given data is close enough to the correct data to be determined as correct. An information providing system that provided data within the threshold amount from the correct data is determined to have provided sufficiently correct data in operation 1116 and is identified as having provided correct data.

[0145] In some cases, only data that matches the correct data is considered correct. That is, in some cases, the threshold indicator may be set to zero so that only data that matches the correct data is considered to be close enough to the correct data to be judged as correct. That is, when the threshold indicator is set to zero, the data must be the same as the correct data so as to be considered valid.

[0146] In operation 1118, the congress node cooperates with other congress nodes to start a script related to the request. The congress node can start the script based on the correct data. For example, the congress node can start the script based on the center point of the data determined in operation 1114. The congress node cooperates to send a transaction to the blockchain network to unlock the script related to the request. The transaction contains the correct data, and the transaction can use this data according to the code in the script.

[0147] In operation 1120, the congress node, in cooperation with other nodes of the congress, distributes the rewards received in the transaction detected in operation 1106. More specifically, the transaction can broadcast and transfer a portion of the rewards to each information providing system that is determined to have provided sufficiently correct data (which can be a subset of all information providing systems that provide data upon request, or all information providing systems if all such systems provide correct data upon request). For example, the congress node, in cooperation with other congress nodes of the group of nodes forming the congress, may permit the transfer of digital assets to each information providing system within the subset. The transaction transfers digital assets restricted by the congress public key to the public key associated with the information providing system that transmitted sufficiently correct data. To sign the transaction, the congress node, using its secret key share, cooperates with other congress nodes (using each secret key share sufficient to generate a valid signature according to the threshold signature scheme) to generate a valid signature. The transaction can also distribute a portion of the rewards to one or more congress members.

[0148] The congress node may, in cooperation with other nodes of the congress, also return at least a portion of the deposits provided by the information providing system. For example, the congress node can broadcast a transaction that includes a valid signature generated in cooperation with other congress nodes according to the threshold signature scheme. Upon request, the deposit may be returned to the information providing system that has provided sufficiently correct data. The deposits of information providing systems that have not provided sufficiently accurate data may be confiscated. That is, such deposits may not be returned. For example, the deposits of nodes that have not provided sufficiently correct data can be distributed among the nodes that have provided sufficiently correct values.

[0149] Although the method described above has been generally described as being executed at a node, the functions of this method depend on cooperation with other nodes and can be executed elsewhere.

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

[0151] Hereinafter, the content of the claims at the time of the original application will be described as an example. [Example 1] A method implemented by a computer, the method implemented by the computer comprising: a step of broadcasting a transaction to a congress pool by a node in a blockchain network to participate in a congress formed by a group of nodes; After the Congress accepts a request to start a script from a requester, a step of preparing, by the node, a blockchain transaction encrypted and locked with a public key associated with the Congress pool, wherein the blockchain transaction is configured such that a plurality of information providing systems can add inputs to the blockchain transaction After the input is added to the blockchain transaction, a step of cooperatively generating a valid cryptographic signature of the blockchain transaction by the node cooperating with other nodes of the group and unlocking the blockchain transaction After the transaction is unlocked, a step of receiving data from the plurality of information providing systems A step of determining a center point of the data received from the plurality of information providing systems A step of starting the script based on the center point by the node cooperating with other nodes of the Congress A method implemented on a computer [Example 2] Based on the center point, a step of identifying, by the node, a subset of the information providing systems that provided data near the center point A step of permitting transfer of tokens to each information providing system within the subset by the node cooperating with other nodes of the group, the computer-implemented method according to claim 1 [Example 3] The token included in the transfer includes one or more tokens received from the requester to the Congress pool, the computer-implemented method according to claim 2 [Example 4] The request includes a threshold indicator, and the subset is identified based on the threshold indicator, the computer-implemented method according to claim 2 or 3 [Example 5] The threshold indicator is a method implemented on a computer according to claim 4, received from the requester. [Example 6] The input includes respective proof of solution data, The method further includes, based on the proof of solution data, determining that the data received from at least one of the information providing systems corresponds to a committed solution, the method implemented on a computer according to any one of claims 1 to 5. [Example 7] The input includes respective proof of solution data, The method determining that the data received from at least one of the information providing systems does not correspond to the proof of solution data received from that information providing system, and when it is determined that the data received from the at least one of the information providing systems does not correspond to a committed solution based on the proof of solution data, discarding the data, the method implemented on a computer according to any one of claims 1 to 5. [Example 8] The input includes a token locked for guarantee, the method implemented on a computer according to any one of claims 1 to 7. [Example 9] The information providing system includes, in the blockchain transaction, a public key, a solution to the request, and a hash based on a salt, the method implemented on a computer according to any one of claims 1 to 8. [Example 10] The data received from the plurality of information providing systems includes a public key, a solution to the request, and a salt, The method Generating a hash based on the public key, the solution to the request, and the salt; The method implemented on a computer according to claim 9, further comprising comparing the generated hash with the hash included in the blockchain transaction. [Example 11] Detecting malicious activities by malicious parties, where the malicious party is one of the nodes of the congress; The method implemented on a computer according to any one of claims 1 to 10, further comprising confiscating at least a portion of the tokens previously transferred to the congress pool by the malicious party using a secret key share. [Example 12] The method implemented on a computer according to claim 11, wherein the confiscating step includes transferring to an insolvent account. [Example 13] A computer-readable storage medium including computer-executable instructions that, when executed, configure a processor to execute the method according to any one of claims 1 to 12. [Example 14] An electronic device, the electronic device comprising: An interface device; A processor coupled to the interface device; A memory coupled to the processor, the memory storing computer-executable instructions that, when executed, configure the processor to execute the method according to any one of claims 1 to 12. An electronic device. [Example 15] The electronic device according to claim 14, wherein the processor includes a trusted execution environment and the computer-executable instructions are executed within the trusted execution environment.

Claims

1. A computer-implemented method, the computer-implemented method comprising: After the congress accepts a request from a requester to launch a script, A node preparing a blockchain transaction cryptographically locked with a public key associated with a congress pool, the blockchain transaction configured to allow multiple information providers to add inputs to the blockchain transaction; determining a center point of data received from the plurality of information providing systems; and the node initiating the script based on the central point in cooperation with other nodes of the congress. A computer-implemented method.

2. Based on the center point, the node identifies a subset of the information providing systems that contributed data about the center point; 2. The computer-implemented method of claim 1, further comprising the step of the node cooperating with other nodes in a group to authorize transfer of the token to each information provider system in the subset.

3. The computer-implemented method of claim 2 , wherein the tokens included in the transfer include one or more tokens received by the congress pool from the requestor.

4. 4. The computer-implemented method of claim 2 or 3, wherein the request includes a threshold indicator, and the subset is identified based on the threshold indicator.

5. The computer-implemented method of claim 4 , wherein the threshold indicator is received from the requestor.

6. The inputs include respective proof of solution data; 6. The computer-implemented method of claim 1, further comprising determining, based on the proof of solution data, that the data received from at least one of the information providing systems corresponds to a committed solution.

7. The inputs include respective proof of solution data; The method comprises: determining that the data received from at least one of the information providing systems does not correspond to the proof of solution data received from that information providing system; 6. The computer-implemented method of claim 1, further comprising: discarding the data received from the at least one of the information provision systems in response to determining that the data does not correspond to a committed solution based on the proof of solution data.

8. The computer-implemented method of claim 1 , wherein the input includes a token that is locked for security purposes.

9. 9. The computer-implemented method of claim 1, wherein the information providing system includes in the blockchain transaction a hash based on a public key, a solution to the challenge, and a salt.

10. the data received from the plurality of information providing systems includes the public key, the solution to the request, and the salt; The method comprises: generating a hash based on the public key, the solution to the challenge, and the salt; 10. The computer-implemented method of claim 9, further comprising: comparing the generated hash with the hash included in the blockchain transaction.

11. detecting malicious activity by a malicious party, the malicious party being one of the nodes of the congress; 11. The computer-implemented method of claim 1, further comprising: confiscating at least a portion of the tokens previously transferred by the malicious party to the congress pool using a secret key share.

12. 12. The computer-implemented method of claim 11, wherein the step of confiscating includes transferring to a non-spendable account.

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

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

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

Images