Consensus Based on Secure Blockchain

Abstract

A computer-implemented method can be provided. The computer-implemented method includes: i) broadcasting a transaction by a node in a blockchain network to a meeting pool to join a meeting formed by a group of nodes; ii) after the meeting has accepted a request for an activation script from a requester, preparing, by the node, a blockchain transaction encrypted and locked with a public key associated with the meeting; iii) cooperatively generating, by the node in cooperation with other nodes in the group of nodes, a valid cryptographic signature for the transaction to consume the transaction; iv) receiving data from multiple information providing systems after the blockchain transaction has been unlocked; v) determining a central point of the data received from the multiple information providing systems; and vi) activating a script based on the central point by the node in cooperation with other nodes in the group of nodes.

Description

[0001] This application is a divisional application of the Chinese patent application No. 201880026072X (corresponding to the PCT international application No. PCT / IB2018 / 052619), with an application date of April 16, 2018 and an invention title of "Consensus Based on Secure Blockchain". Technical Field

[0002] The present invention generally relates to distributed ledgers, and more particularly, to methods and systems for activating scripts associated with such distributed ledgers. The present invention is particularly suitable for activating such scripts based on information not available on the distributed ledger, but is not limited thereto. Background Art

[0003] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. They include blockchain and transaction chain technologies, permissioned ledgers and permissionless ledgers, shared ledgers and their variants. The most well-known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have also been proposed and developed. Although Bitcoin may be referenced herein for convenience and illustration purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols also fall within the scope of the present invention.

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

[0005] In order to write a transaction to the blockchain, it must be "verified". Certain network nodes act as miners and work to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, the software client installed on the node performs this verification work on the referenced transaction as well as the unspent transaction outputs (UTXOs). Verification can be performed by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE and if certain other conditions are met (such as including sufficient mining fees), then the transaction is valid and can be written to the blockchain. Therefore, in order to write a transaction to the blockchain, the transaction must i) be verified by the node receiving the transaction - if the transaction is verified, the node relays it to other nodes in the network; ii) be included in a new block built by miners; iii) be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

[0006] Although blockchain technology is well-known due to its use in cryptocurrency implementations, digital entrepreneurs have started to explore the use of both the cryptographic security system underlying Bitcoin and the data that can be stored on the blockchain to enable new systems. It would be highly beneficial if the blockchain could be used for automated tasks and processes not limited to the cryptocurrency domain. Such a solution would be able to leverage the benefits of the blockchain (e.g., permanence of events, tamper-proof records, distributed processing, etc.) while being more general in its applications.

[0007] Blockchain technology has been used to provide a platform for smart contracts. A smart contract is a computerized transaction protocol that enforces the terms of a contract. When implemented on the blockchain, a smart contract is a computerized protocol stored on the blockchain and triggered by a blockchain transaction, which can cause data to be written to the blockchain when executed. When implemented on the blockchain, the smart contract is visible to all users of the blockchain network.

[0008] Smart contracts typically must be activated by a message or a transaction. That is, smart contracts typically must be "poked" by an external agent for the code to be executed. Additionally, smart contracts typically cannot access information outside of the blockchain itself. Without accessing such information, a smart contract may not be able to determine which terms of the contract will be enforced / implemented. To obtain such external information, a trusted external agent is sometimes used to provide access to information outside of the blockchain and required for the smart contract. The reliance on a trusted external agent reduces the autonomy and self-executing nature of the smart contract. The reliance on a trusted external agent may reduce the security and usability of the smart contract. SUMMARY OF THE INVENTION

[0009] Accordingly, the present invention provides a method as defined in the appended claims.

[0010] As described in more detail below, a congress can be formed on a blockchain network. The congress can be an open membership group, and any node in the blockchain network can join the open membership group when submitting sufficient stake to a pool associated with the congress. For example, a node can join the congress by transferring a digital asset such as a digital currency (e.g., Bitcoin), a token, or other stake or value to an account associated with the congress. Advantageously, the congress can be used to securely activate a script such as a smart contract. For example, the congress can be used to reliably provide data from an external source to the script. The congress can be used to securely reach a consensus in a distributed system where message transfer between nodes is not secure. For example, the congress can reliably provide data from an external source to the script, and the data can be securely provided even if communication between nodes in the congress may not be secure.

[0011] Accordingly, a computer-implemented method can be provided according to the present invention. The computer-implemented method can include: i) a node in a blockchain network broadcasting a transaction to a congress pool to join a congress formed by a group of nodes; ii) after the congress has accepted a request to activate a script from a requester, the node preparing a transaction payable to the congress pool, the transaction being configured to allow multiple information providing systems to add inputs to the transaction; iii) after the inputs have been added to the transaction, the node cooperating with other nodes in the group of nodes to cooperatively generate a valid signature for the transaction to consume the transaction; iv) after the transaction has been consumed, receiving data from multiple information providing systems; v) determining a center point of the data received from the multiple information providing systems; vi) the node cooperating with other nodes in the group of nodes to activate the script based on the center point.

[0012] In some embodiments, a computer-implemented method is provided. The computer-implemented method can include: i) a node in a blockchain network broadcasting a transaction to a congress pool to join a congress formed by a group of nodes; ii) after the congress has accepted a request to activate a script from a requester, the node preparing a blockchain transaction encrypted and locked with a public key associated with the congress, the blockchain transaction being configured to allow multiple information providing systems to add inputs to the blockchain transaction; iii) after the inputs have been added to the blockchain transaction, the node cooperating with other nodes in the group of nodes to cooperatively generate a valid signature for the transaction to unlock the blockchain transaction; iv) after the transaction has been unlocked, receiving data from multiple information providing systems; v) determining a center point of the data received from the multiple information providing systems; vi) the node cooperating with other nodes in the group of nodes to activate the script based on the center point.

[0013] In some embodiments, the computer-implemented method includes: i) identifying, by the node, a subset of information-providing systems that provide data close to the center point based on the center point; and ii) authorizing, by the node in cooperation with other nodes of the group, the transfer of digital assets (i.e., tokens) to each information provider in the subset (i.e., to each information-providing system in the subset).

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

[0015] In some embodiments, the input to the transaction (i.e., the input to the blockchain transaction) includes a corresponding 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 submitted solution.

[0016] In some embodiments, the input to the transaction (i.e., the input to the blockchain transaction) includes a corresponding 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 to the proof of solution data received from the information-providing system; and discarding the data in response to determining, based on the proof of solution data, that the data received from the at least one of the information-providing systems does not correspond to the submitted solution.

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

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

[0019] In some embodiments, the computer-implemented method further includes: i) detecting malicious behavior of a malicious party, the malicious party being one of the nodes of the meeting; and ii) using a private key share to forfeit at least a portion of the tokens previously transferred by the malicious party to the meeting pool. The forfeiture can include transfer to a non-consumable account.

[0020] 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. Computer-executable instructions are stored on the memory, and the computer-executable instructions, when executed, configure the processor to perform the methods described herein.

[0021] According to the present invention, a computer-readable storage medium can be provided. The computer-readable storage medium includes computer-executable instructions, and the computer-executable instructions, when executed, configure the processor to perform the methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] With reference to the embodiments described herein, these and other aspects of the present invention will become apparent and be elucidated. The embodiments of the present invention will be described hereinafter only by way of example and with reference to the drawings, wherein:

[0023] Figure 1 A block diagram showing an exemplary blockchain network is shown.

[0024] Figure 2 A block diagram showing an exemplary electronic device that can act as a node in a blockchain network is shown.

[0025] Figure 3 A flowchart of an exemplary method for initiating a meeting is shown.

[0026] Figure 4 A flowchart of an exemplary method for joining a meeting is shown.

[0027] Figure 5 A flowchart of an exemplary method for seizing digital assets is shown.

[0028] Figure 6 A flowchart of an exemplary method for reallocating key shares is shown.

[0029] Figure 7 A flowchart of another exemplary method for reallocating key shares is shown.

[0030] Figure 8 A flowchart of an exemplary method for returning a deposit is shown.

[0031] Figure 9 A block diagram of an example blockchain network is shown.

[0032] Figure 10 A flowchart of an example method for requesting an activation script is shown.

[0033] Figure 11 A flowchart of an example method for facilitating the activation of a script is shown. DETAILED DESCRIPTION

[0034] Blockchain network

[0035] First, refer to Figure 1 . Figure 1 An exemplary blockchain network 100 associated with a blockchain is shown in block diagram form. The blockchain network can be a public blockchain network, which is a peer-to-peer open membership network where anyone can join without an invitation or the consent of other members. Distributed electronic devices running an instance of the blockchain protocol (under 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.

[0036] The electronic devices of the nodes 102 that run the blockchain protocol and form the blockchain network 100 can be various types of devices, such as including desktop computers, laptop computers, tablet computers, servers, mobile devices such as smart phones, wearable computers such as smart watches, or other electronic devices.

[0037] The nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies, which can include wired and wireless communication technologies. Such communication follows the protocol associated with the blockchain. For example, in the case where the blockchain is a Bitcoin blockchain, the Bitcoin protocol can be used.

[0038] The nodes 102 maintain 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. For a blockchain protected by proof-of-work, the transactions of the nodes 102 that affect the global ledger are verified by other nodes 102, thus maintaining the validity of the global ledger. When the blockchain is a proof-of-work based blockchain, the blocks are also authenticated by checking the proof-of-work submitted with the blocks.

[0039] At least a portion of the nodes 102 operate as miners 104 of the blockchain network 100. Figure 1The blockchain network 100 is a proof-of-work blockchain, where miners 104 perform expensive computations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve cryptographic problems. In Bitcoin, miners 104 find a nonce such that the block header hashes to a number less than the value defined by the current difficulty via SHA-256. The hash power required by the proof-of-work algorithm means that after a certain number of blocks are mined on top of it, transactions are considered effectively irreversible. Miners 104 that solve the cryptographic problems create new blocks for the blockchain and broadcast the new blocks to other nodes 102. Before accepting that a block should be added to the blockchain, other nodes 102 verify that miners 104 have actually solved the cryptographic problem and thus demonstrated sufficient proof of work. The block is added to the blockchain (i.e., added to the distributed global ledger) through the consensus of nodes 102.

[0040] The blocks created by miners 104 include transactions that have been broadcast to the blockchain by nodes 102. For example, a block may include a transaction from an address associated with one of the nodes 102 to an address associated with another one of the nodes 102. In this way, the block serves as a record of the transaction from one address to another. The party requiring the transaction to be included in the block proves that they are authorized to initiate the transfer (e.g., spend Bitcoin in the case of Bitcoin) by signing the request with the private key corresponding to their public key. If the request is effectively signed, only then is the transfer added to the block.

[0041] For 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, any reference in this document to transferring digital assets to or from a public key (e.g., paying to a public key) and transferring digital assets to or from the address associated with the public key refers to the same operation.

[0042] Some nodes 102 may not operate as miners but participate as validation nodes. Transaction validation may involve checking the signature(s), confirming references to valid UTXOs, etc.

[0043] Figure 1 An example includes five nodes 102, three of which participate as miners 104. In practice, the number of nodes 102 or miners 104 can be different. In many blockchain networks, the number of nodes 102 and miners 104 can be much larger than Figure 1 the number shown.

[0044] As described below, various nodes 102 can cooperate to form a group that will be referred to herein as a session 110. In the example shown, three nodes 102 are shown as participants in the session 110. However, the actual number of session 110 members may be much larger.

[0045] Session 110 is an open - membership group that can be joined by any node 102 when sufficient stake is submitted to a pool associated with the session 110. For example, a node can join the session by transferring digital assets (such as digital currency (e.g., Bitcoin), tokens, or other stakes or values) to an account associated with the session 110. The nodes 102 that join the session can be any node in the blockchain network, including mining nodes and non - mining nodes. In at least some applications of the session, the nodes acting as session members monitor the blockchain in the sense that they download (but do not necessarily retain) the full blockchain.

[0046] The techniques for joining, leaving, and participating in session 110 are discussed in more detail below.

[0047] Electronic devices operating as nodes

[0048] Figure 2 is a block diagram showing the components of an exemplary electronic device 200 that can act as a node 102 ( Figure 1 ) in a peer - to - peer blockchain network 100 ( Figure 1 ). The exemplary electronic device 200 can also be referred to as a processing device. The electronic device can take various forms, such as including 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 other types of forms.

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

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

[0051] Although the memory 220 is shown as a single block in Figure 2 reality, the electronic device 200 may include multiple memory components. The memory components may be of various types, such as including RAM, HDD, SSD, flash drives, etc. Different types of memory may be suitable for different purposes. In addition, although the memory 220 is shown separately from the processor 210, the processor 210 may also include embedded memory.

[0052] As Figure 2 shown, the processor 210 may include a secure area such as a Trusted Execution Environment (TEE) 250. The TEE 250 is an isolated execution environment that provides additional security for the electronic device 200, such as isolated execution, integrity of trusted applications, and asset confidentiality. The TEE 250 provides an execution space that ensures that the computer instructions and data loaded within the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 can be used to protect the integrity and confidentiality of important resources (such as keys). The TEE 250 is at least partially implemented at the hardware level, so that the instructions and data executed within the TEE 250 are protected from access and manipulation by the rest of the electronic device 200 and external parties such as the owner of the electronic device. The data and computations within the TEE 250 are protected from the party operating node 102 that includes the TEE 250.

[0053] The TEE 250 can operate to instantiate an enclave, then add pages of memory one at a time while hashing cumulatively. Similar operations can also be performed on a remote machine (which can be a developer machine or another machine) so that the remote machine determines and stores the expected hash. Thus, the content of the enclave can be verified by any remote machine to ensure that the enclave runs an approved algorithm. Verification can be performed by comparing the hashes. Once the enclave is fully built, it is locked. Code can be run in the TEE 250 and secrets can be sent to the code, but the code cannot be changed. The final hash can be signed with a proof key and made available to the data owner to verify it before the data owner sends any secrets to the enclave.

[0054] The TEE 250 can be used to protect the Figure 1)Confidentiality and integrity of the private key shares associated with the conference public key used. For example, the TEE 250 can be used for the generation and storage of private key shares. The purpose of the TEE 250 is to ensure that no member can directly obtain the private key shares maintained within the enclave of the TEE 250, or obtain information about other private key shares through member-to-member communication or cross-enclave communication. The protocol is also robust against enclave threshold compromises. Additionally, the TEE 250 can enable remote attestation, which can be used by node 102( Figure 1 )to prove to other nodes 102 that the TEE 250 is trustworthy and running approved computer-executable instructions for the protocol implemented for conference 110. The remote attestation can be provided by the TEE 250 by running a specific code segment and sending the hash of the code within the enclave, and the hash of the code is signed by an internal attestation key for the enclave.

[0055] When a member of conference 110 who previously used a private key share on the electronic device 200 chooses to leave the conference, the TEE 250 can be used to prove the secure deletion of the private key share. The electronic device 200 can provide a deletion proof to other conference members through the remote attestation protocol provided in the TEE 250. The deletion proof may be required before allowing a member to withdraw their member deposit. That is, the return of the deposit can be conditional on proving the deletion of the private key share within the member's enclave.

[0056] The TEE 250 can be equipped with a secure random number generator, which is inside the enclave of the TEE and can be used to generate private keys, random challenges, or other random data. The TEE 250 can also be configured to read data from external memory and can be configured to write data to external memory. This data can be encrypted with a secret key maintained only within the enclave.

[0057] Various platforms (such as Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX)) can be used to implement the TEE 250. For example, SGX supports remote attestation, which enables an enclave to obtain a signed statement from the processor executing a specific enclave, where the specific enclave has a given member called a reference. A third-party attestation service such as Intel Attestation Service (IAS) can attest that these signed statements originate from a trusted CPU that complies with the SGX specification.

[0058] The electronic device 200 acts as a node 102( Figure 1 )in the blockchain network 100( Figure 1 )and can join or otherwise participate in the conference 110( Figure 1 ). When a group of digital asset holders pool their digital assets (such as digital currencies, tokens, or the blockchain network 100( Figure 1) other interests or values supported by the meeting 110 is formed.

[0059] Conferences and Threshold Signatures

[0060] The conference 110 can be a permissioned or permissionless group. That is, the blockchain network 100 ( Figure 1 ) any node 102 ( Figure 1 ) (i.e., by monitoring and storing at least a portion of the information in the blockchain) can join conference 110. To join conference 110, node 102 transfers one or more digital assets to a pool of digital assets associated with conference 110 (i.e., to a public group address associated with one or more digital assets, which are in turn associated with other members). This pool of digital assets may be referred to as a conference pool. For example, node 102 may join conference 110 by transferring (i.e., depositing) such digital assets to an address associated with the conference pool (i.e., to a "conference address," which may also be referred to as a public group address). The digital assets are placed under the control of a group threshold signature with a single public key (referred to as the conference public key). Conference members hold shares of a distributedly generated private key. The number of shares held may be proportional to the amount deposited in the pool.

[0061] Digital assets controlled by conference 110 (including any digital assets transferred to the conference address) are placed under the control of a threshold signature scheme. Under the threshold signature scheme, a group of members holding a total private key share exceeding a threshold is required to generate a valid signature that allows the digital asset to be transferred out of the control of conference 110. That is, at least a threshold number of private key shares must be used to generate a valid signature for any outbound transfer of digital assets controlled by conference 110.

[0062] The conference public key blocks digital assets deposited in the conference pool by members of conference 110 in exchange for a share of the private key, as well as any digital assets deposited at addresses associated with the conference pool by members or non-members of conference 110 (i.e., placed under the full, partial, or conditional control of the conference) (any digital assets that have been deposited for reasons other than obtaining a share of the private key). Non-members or members can deposit digital assets at addresses associated with the conference for various reasons. In an example explained in more detail below, a member or non-member can deposit digital assets into conference 110 to move those assets to another blockchain, which can be called an alternative chain, such as a side chain. A side chain can be a blockchain that runs parallel to the main blockchain (i.e., parallel to the main chain).

[0063] Because the same conference public key can control both member deposits (i.e., digital assets provided by conference members in exchange for private key shares) and digital assets provided by members or non-members for other purposes, at least a portion of the deposits to the address associated with the conference may be specially marked to indicate the type of deposit. For example, a transaction transferring digital assets to the conference address may include a tag, identifier, or other attribute indicating the nature of the deposit being made. For instance, a transaction transferring digital assets to the conference address that is not for the purpose of joining the conference or increasing one's stake in the conference membership may include a special identifier to indicate that the deposit is being made for other purposes. These identifiers can be used by node 102 associated with conference 110 when managing private key generation. More specifically, a node 102 that deposits digital assets to join a group is assigned a private key share for conference 110 (as a result of making the digital asset deposit), while other nodes 102 that deposit digital assets for other purposes (e.g., transfer to a side chain) do not necessarily hold the conference private key share (i.e., corresponding to the conference public key).

[0064] Conference 110 can act as an autonomous group where cooperative behavior is enforced by the threat of forfeiting all or part of the member deposits. Non-cooperative or malicious members may have such digital assets forfeited for joining a cooperative agreement in which many honest members participate. That is, to ensure that all nodes 102 operate according to a predefined protocol or guidelines, member deposits entering the conference pool may be forfeited. Forfeiture means permanently preventing the return of the member deposits deemed forfeited. The (one or more) digital assets forming the member deposits that are not returned due to malicious activity can remain in the conference pool but not be returned (e.g., if consensus is reached (on an alternative chain) that they should not be returned), be transferred immediately or in the future to another non-spendable address, or otherwise forfeited, and the nature of the forfeiture may depend on whether the conference acts as a bonded validator set for a side chain.

[0065] In addition, when conference members wish to leave conference 110, they can withdraw their member deposits (i.e., request that conference 110 transfer the member deposits back to the member's personal address). However, the funds are only withdrawn if the group members (i.e., the conference) use multiple private key shares (the number of which exceeds the threshold required to generate a valid digital signature) to approve the withdrawal.

[0066] The threshold signature scheme implemented by Conference 110 can be of various types. A threshold signature scheme allows the sharing of the signature right among n parties, as long as at least the threshold number of private key shares contribute to generating a valid signature. Any subset smaller than the threshold cannot generate a valid signature. More specifically, each party controls a share of the private signature key and must use the threshold number of key shares to generate a valid signature by combining partial signatures. Any subset of key shares smaller than the threshold cannot generate a valid signature.

[0067] 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 46th Midwest Symposium on Circuits and Systems, 1:276 - 280 (2003). This threshold signature scheme is an extension of the digital signature scheme, which is an algorithm based on elliptic curve cryptography, where t + 1 key shares from one of the n key share holders are required to reconstruct the private key. This scheme can be used to construct a valid signature without reconstructing the private key, and no party has to disclose its key share to another party.

[0068] Since t + 1 key shares are sufficient to reconstruct the secret, the maximum number of allowed adversaries according to this technique is t. In the model of Ibrahim et al., an adversary is an entity that compromises a party holding a secret share and can access that secret share. Adversaries can be of various types. For example, Byzantine adversaries are those who may pretend to participate in the protocol while actually sending incorrect information. The ECDSA scheme proposed by Ibrahim is robust against up to t <= n / 4 malicious adversaries. This robustness can be increased to t <= n / 3, but at the cost of higher complexity.

[0069] The ECDSA scheme of Ibrahim et al. is robust against t <= n / 3 stopping adversaries. Stopping adversaries can prevent a compromised party from participating in the protocol or from stopping participation midway.

[0070] This ECDSA scheme includes various mechanisms that can be used by node 102 to identify malicious or uncooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomials required for Shamir secret sharing (SSS). SSS is a form of secret sharing in which a secret is divided into several parts and each participant is provided with its unique part. These parts can be used to reconstruct the secret. In the case where inconsistent shares are provided to different nodes 102, or in the case where shares different from the blind shares broadcast to all nodes are secretly sent to a node, node 102 can use VSS to identify malicious nodes 102 or members. Inconsistent shares can be identified by any one of the nodes 102. Verifying the sharing of the secret can be enabled by including auxiliary information that allows node 102 to verify its share as consistent.

[0071] Sending incorrect shares (i.e., shares different from the broadcast blind shares) to individual nodes can be identified by the intended recipient nodes of the shares. The identification of incorrect shares secretly sent to a node can be publicly verified using publicly verifiable secret sharing (PVSS) techniques. Such techniques can avoid the possible delays that may occur in the identification of cheating senders when not using PVSS, and when incorrect shares are sent, the recipients of the incorrect shares are offline or cut off from a substantial part of the network.

[0072] Misconduct such as providing inconsistent shares to different nodes can be addressed by the conference 110 to deter malicious behavior. For example, when a node 102 ( Figure 1 ) is identified as a malicious party by other nodes 102, multiple nodes 102 (i.e., nodes associated with conference members) exceeding a threshold (e.g., t + 1) can cooperate to punish the malicious party. For example, node 102 can take actions involving digital assets (such as digital currency, tokens, or other rights or values) deposited into the conference by the malicious party. For example, the conference can burn them by transferring digital currency, tokens, rights, or values to an unspendable address, or the conference can confiscate these digital assets by reaching a consensus with other nodes to deny authorization for the return of these digital assets to the malicious party. Nodes 102 that are not misbehaving can also deter misconduct by cooperating to exclude the misbehaving node (e.g., by effectively invalidating the key shares; e.g., by excluding the node from participating in the conference protocol, or by resharing the private key instead of allocating shares to the misbehaving node).

[0073] The above ECDSA technology can be enhanced by using a TEE. For example, consider a powerful form of adversary, called a Byzantine adversary here, based on the threshold ECDSA signature technology of Ibrahim et al. This type of adversary can act arbitrarily. For example, they can not only refuse to participate in the signature process or stop participating midway, but may also pretend to participate honestly and send incorrect information. However, by using a TEE and generating data for signing within the enclave of the TEE that stores the secret private key shares, additional security can be provided because it is extremely unlikely that a large number of enclaves will be compromised. For example, if each TEE is assigned no more than one key share, then it can be reasonably expected that the number of TEEs that may be compromised will not be close to the robustness threshold of the Byzantine adversary, assuming n is large enough. This allows the protocol to be secure if it can tolerate a small fraction of malicious adversaries relative to the total number of key shares.

[0074] For example, if all nodes have a TEE, then access to the secrets stored within the enclave can only be achieved through physical access to the nodes with great effort and expense, and only if the manufacturer of the TEE has not been compromised. This type of manufacturer-level compromise is expected to be manageable. For example, if the manufacturer falsely claims that many public keys correspond to genuine TEEs, they can directly access the private key shares and potentially launch an attack. However, such an attack would require a sufficient number of key shares to allow the manufacturer to generate a valid signature without the help of other nodes. This would mean accumulating a large portion of the total stake, which would be very expensive. Additionally, by carrying out the attack, most of the value of the stake holdings would be destroyed.

[0075] When using a TEE, it is useful to consider the robustness of the protocol against "compromised nodes". A compromised node causes the hardware outside the TEE to be compromised, but the integrity of the TEE remains uncompromised. A compromised node can control what information the enclave receives and does not receive. Specifically, a compromised node can stop, i.e., refrain from participating in the protocol. If the information provided to the protocol is signed with a private key secretly held in the enclave (where the corresponding public key is authenticated during the proof), the private key is as trustworthy as the enclave itself. Thus, a compromised node cannot send arbitrary (authenticated) information to the protocol and can only attempt to interfere by stopping or trying to deceive the enclave into acting incorrectly (e.g., by providing it with outdated information). Therefore, for a compromised node, a successful attack would require collecting a sufficient number of partial signatures to produce a complete signature. With a TEE, the protocol by Ibrahim et al. is robust against 2t compromised nodes. Because if n - 2t >= 2t + 1 can produce a signature, then any eligible subset of key shares of size 2t + 1 <= (n + 1) / 2 suffices. Thus, when using a TEE, the threshold of the threshold signature scheme can be configured to a number greater than or equal to 50% of the key shares, thereby producing a valid signature in the presence of compromised nodes.

[0076] Other threshold signature schemes can also be used. For example, the threshold signature scheme can be of the type of ECDSA threshold scheme proposed by Goldfeder et al. in "Securing Bitcoin Wallets Via a New DSA / ECDSA threshold signature scheme", (2015). This protocol allows t + 1 parties to generate a valid signature. Thus, the number of key shares that an adversary must control to generate a valid signature is equal to the number of key shares that the adversary must possess to reconstruct the private key. In cases where unanimous consent is required to generate a valid signature, this technique can provide an effective solution. In the most general case, this scheme imposes a space requirement that scales exponentially with the number of meeting members, because for any threshold, the entire protocol needs to be repeated for any possible subset of t + 1 players out of n players. Thus, for large values of both n and t, a large amount of key shares will need to be stored. To mitigate this storage requirement, standard Bitcoin multisignature can be combined with threshold signature. Specifically, multisignature can be used to lock digital assets, thereby dividing each private key into multiple shares. In terms of space requirements, this technique will make larger meetings more efficient. The scalability property can also be improved by composing the scheme for a large number of participants from smaller-sized participants in a recursive manner at multiple levels. For example, the threshold signature scheme can be combined with the technique proposed by Cohen et al. in "Efficient Multiparty Protocols via Log-Depth Threshold Formulas (2013), Advances in Cryptology - CRYPTO 2013 pp 185 - 202".

[0077] Other threshold schemes can be used, including non-ECDSA signature schemes. For example, node 102 can use a threshold scheme based on the Schnorr scheme to implement session 110.

[0078] A node 102 ( Figure 1 ) in the blockchain network 100 ( Figure 1 ) can implement a session protocol based on the selected threshold signature scheme. Such a node 102 can include computer-executable instructions stored in the memory 220 ( Figure 2 ) that implement the session protocol. When executed by the processor 210 ( Figure 2 ), such instructions cause the node 102 (such as an electronic device 200 of the type described with reference to Figure 2 ) to perform one or more methods of the session protocol. These methods can include Figures 4 to 8 and Figure 10Any one or combination of the methods 300, 400, 500, 600, 700, 800, 1000. Thus, the conference protocol may include Figures 4 to 8 and Figure 10 A combination of one or more of the methods 300, 400, 500, 600, 700, 800, 1000. These methods can be carried out by a node cooperating with other nodes associated with other conference members.

[0079] Conference startup

[0080] The following refers to Figure 3 to illustrate the method 300 for starting the conference 110. The method 300 can be carried out by an initial trust party to establish the conference 110. That is, the node 102 associated with the initial trust party can carry out the method 300.

[0081] The method 300 includes providing a conference public key in operation 302. The conference public key can be provided to other nodes 102 to allow other nodes to pay to the conference public key when they wish to join the conference. That is, others can transfer digital assets to the address associated with the conference public key, thereby joining the conference.

[0082] In operation 304, the node 102 carrying out the method 300 allows payments to the public key until one or more conditions are met. For example, for a determined time period or a determined number of blocks, the node can allow payments to the public key. After the conditions are met (e.g., after the time period expires or the said number of blocks are mined), the node 102 carrying out the method 300 identifies the initial members of the conference in operation 306.

[0083] After identifying the parties including the initial membership of the conference, in operation 307, the private key is divided into private key shares according to a threshold signature scheme. Then in operation 308, the private key shares are distributed from the node 102 carrying out the method 300 to the identified parties. The private key shares are associated with a threshold signature scheme, which can be of the type described herein.

[0084] During operation 308, the nodes 102 identified as meeting members cooperate to generate a new private key share and a new public key. The original key shares sent to these nodes by the initial trustor can be used to sign and broadcast transactions to send all digital assets in the meeting pool to the new public key, which then becomes the meeting public key. That is, during operation 408, a new group public address is established, and the digital assets under the control of the meeting are transferred to this new address, which becomes the new address of the group and is associated with the meeting public key. After confirming this transfer, the meeting can operate without trust. The new group public address is formed as an address where deposits of digital assets can be received in the future from other nodes that wish to join the meeting 110, or for other purposes as described above. Now the meeting members are considered to have joined the meeting, and these nodes can now operate without the help of the initial trustor. Additionally, the initial trustor no longer plays any role in the operation of the meeting.

[0085] Joining the meeting after the meeting has started

[0086] The following refers to Figure 4 , Figure 4 illustrates a method 400 for joining a meeting. Figure 4 The method 400 of Figure 3 can be operated in combination with Figure 4 the method 300 of Figure 3 , however, Figure 1 the method 400 of Figure 4 is performed by different nodes among the nodes 102 operating in the same blockchain network 100 ( Figure 3 ) that operate the method 300 of Figure 1 .

[0087] The nodes 102 performing the method 400 pay to the meeting public key in operation 404 by broadcasting a transaction of digital assets from a private account associated with the node 102 to the meeting address (i.e., the address associated with the meeting public key). More specifically, the node 102 broadcasts a transaction to transfer one or more digital assets to the public group address associated with the meeting public key. The public group address is the address of the meeting pool. The meeting pool includes other digital assets associated with other members of the meeting. Thus, once the transaction in operation 404 is mined by the miner 104 ( Figure 1)When added to the block, the digital assets are transferred to a conference pool of digital assets including those of other members. The public group address can receive transfers from parties who wish to join the conference and also from parties who do not wish to join the conference. The parties who do not wish to join the conference transfer digital assets to the conference pool so that the conference can exercise full, partial or conditional control over these digital assets by using the threshold signature scheme adopted by the conference.

[0088] The transaction at operation 404 may include a tag, identifier or other attribute that indicates that the party transferring the digital assets wishes to join the conference and that the deposit is made for this purpose.

[0089] After depositing the digital assets through the conference pool, node 102 of method 400 receives a private key share at operation 406. Then, node 102 regenerates the private key share at operation 408 by running a single instance of the protocol. The generation of the private key share can be performed within the TEE of node 102.

[0090] At operation 408, node 102 generates a private key share to be used in the threshold signature scheme, where at least a threshold of private key shares must be used to represent the conference to generate a valid signature for the transaction. The holders of the other private key shares are the other members of the conference who join the conference on a permitted or unpermitted basis by transferring the corresponding digital assets to the public group address.

[0091] To regenerate the private key share, at operation 408, the existing conference members can cooperate to update the key share. For example, node 102 can generate a random polynomial of degree t with a zero constant term Then, node 102 can compute the points and set them as their private key shares. Then, node 102 can distribute the points on the polynomial to each existing conference member i = 1,..., n. Then, each existing conference member (i = 1,..., n) adds the received value to its existing private key share to obtain a new private key share. Node 102 now has a private key share equivalent to that of all other members, and the corresponding public key remains unchanged. As described above, the threshold signature scheme can be of various types, including the elliptic curve digital signature algorithm or a threshold scheme based on the Schnorr scheme.

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

[0093] After each node generates a private key share, funds under the control of the previous session public key, e.g., funds transferred to a common group address associated with the original session public key (through the cooperation of multiple group nodes sufficient to generate a valid signature under a threshold signature scheme), can be transferred to a new session public key associated with the new private key share.

[0094] After the private key share is generated in operation 408, it can be used under operation 410 of method 400. The private key share can be used to cooperatively generate a valid signature for a transaction from a common group address that can be broadcast by members. That is, the private key share can be used to assist in signature generation in a threshold signature scheme. Under a threshold signature scheme, a threshold number of private key shares of the session need to be used by each member to produce a valid signature, and the signature allows digital assets to be transferred out of the session. Node 102 performing method 400 can retrieve the private key share from storage and use the private key share to assist in signature generation. If a sufficient number of other session members also use their respective private keys to assist in signature generation, then the signature is generated and a valid outgoing transaction can be broadcast. When miner 104 ( Figure 1 ) of blockchain network 100 adds the transaction to a mined block added to the blockchain through the consensus of nodes 102 in blockchain network 100 and the block is confirmed, the outgoing transaction is complete. At this time, the digital assets represented in the transaction can no longer be under the control of the session. That is, such digital assets can no longer be blocked by the session public key.

[0095] The use of the private key share in operation 408 can be performed within the TEE of node 102. The TEE protects the private key share such that no other part of the system or the members themselves can access any data stored in the enclave, such as the private key share. Additionally, the TEE protects the private key because if a member wants to get their deposit back and withdraw their deposit, it cannot retain a copy of the private key as it must delete the private key before proving the return of the member's deposit.

[0096] Figure 4 Method 400 can be performed during or after the initial setup phase. That is, method 400 can be performed before the initial key shares are allocated (e.g., during operation 308 of method 300 Figure 3 ) or after (e.g., during rebalancing which will be discussed in more detail below).

[0097] At operation 410, the transaction can transfer the digital assets back to the party that initially deposited these digital assets into the session pool. That is, the transfer can return the digital assets to the depositor. The transfer can also transfer the digital assets elsewhere. For example, the digital assets can be transferred to a third party or an unspendable address.

[0098] Confiscating digital assets

[0099] Refer to the followingFigure 5 , showing an exemplary method 500 for seizing digital assets. Figure 5 The method 500 can be performed by node 102, which can be the same node as the node performing Figure 4 method 400. Method 500 can be performed after operation 408 of Figure 4 method 400, so that when performing Figure 5 method 500, the node 102 already has access to the private key share.

[0100] At operation 502, node 102 detects malicious activity by a malicious party. The malicious party can be another member of the meeting. Malicious activity is detected when node 102 determines that a member of the meeting has violated a predetermined protocol or guideline. For example, when a node that is a member of the meeting reports incorrect information (i.e., errors, inconsistencies, or other unacceptable information) to other members of the meeting, that member can be considered a malicious member.

[0101] At operation 503, in response to detecting malicious activity, node 102 can cooperate with other nodes in the meeting to suspend the member that is the malicious party. That is, the meeting can exclude the malicious party from further participating in the meeting.

[0102] To ensure that all nodes 102 operate in accordance with a predetermined protocol or guideline, the member deposits entering the meeting pool can be seized. Seizure means permanently preventing the return of the member deposits considered to be seized. The digital asset(s) that constitute the member deposits not returned due to malicious activity can remain in the meeting pool but not be returned (in response to a consensus that such action should be taken), be transferred immediately or in the future to another non-spendable address, or otherwise seized, and the nature of the seizure can depend on whether the meeting acts as a set of collateral verifiers for a side chain. For example, at operation 504, in response to detecting malicious activity by a malicious party, node 102 performing method 500 can use the private key share to provide a partial signature on a seizure transaction (which is a transaction that transfers digital assets to a non-spendable address or to another node as a reward for exposing malicious activity). That is, the node cooperates with other nodes in the meeting to seize at least a portion of the digital assets previously transferred by the malicious party to a public group address (i.e., transferred to the meeting pool). That is, in response to observing that a group member has violated a predetermined protocol or guideline, the private key share is used to assist in authorizing a transaction for one or more digital assets associated with that group member and held in the meeting pool.

[0103] Because the threshold signature scheme is used with the conference public key, an individual node acting alone cannot transfer the deposit of the digital assets of another conference member out of the conference pool (e.g., transfer to an unspendable address). Instead, digital assets can only be forfeited by transfer when a threshold number of private key shares are used by their respective members to generate a valid signature to transfer the digital assets (s) to another address, or when a group of members having at least the threshold number of private key shares reach a consensus to suspend a member (at operation 503), which causes any withdrawal requests from the suspended member to be automatically ignored. When digital assets are forfeited by transfer, the other address(es) to which the (one or more) digital assets can be transferred can be associated with an unspendable address. For example, another address can be an address for which there is no private key, so that no party can access the digital assets bound by the public key of that address. When a transaction transferring digital assets to an unspendable address is confirmed or when a consensus is reached on the side chain that the digital assets should be forfeited, the digital assets may be considered burned because they can no longer be spent by any member of the conference or indeed by any node in the blockchain network 100.

[0104] Accordingly, at operation 504, a node can forfeit digital assets by cooperatively using private key shares with other members of the conference to generate a valid signature for a transaction to an unspendable address and, in some embodiments, can involve reaching a consensus on a second blockchain that all or part of a member's deposit should be permanently forfeited.

[0105] In addition, in some embodiments, the conference can act as a set of surety verifiers to secure the proof-of-stake side chain, and the side chain can be used as a broadcast channel. For example, conference members can reach a consensus on the side chain that a member has acted maliciously. This consensus can correspond to the confirmation of a side chain transaction that includes evidence of the accusation of malicious activity. After the consensus is reached, any request by the malicious member to withdraw the member's deposit will be rejected and the deposit will be considered forfeited. The forfeited digital assets may be burned at some future time. That is, at some later time, a threshold number of members (excluding the malicious member) can cooperate to authorize the transfer of the forfeited digital assets to an unspendable address.

[0106] Because the conference is an open group that can be joined by any node 102 of the blockchain network 100 by storing digital assets, the group membership can change periodically. When such a change occurs, the private key share distribution can be updated. Referring below to Figure 6 , an exemplary method 600 for updating the private key share distribution is shown. Method 600 can be performed by a node 102 of the blockchain network 100 in cooperation with other nodes of the blockchain network 100.

[0107] Updating Private Key Share Distribution Using a New Public Address

[0108] At operation 602 of method 600, node 102 detects a reallocation request, which is a request whose implementation involves reallocating key shares. For example, node 102 may detect that a potential new member has transferred a digital asset to a public group address or that an existing member has requested a withdrawal of member deposits.

[0109] Digital assets can be transferred to the public group address by nodes such as those that request to join a meeting or increase their participation in a meeting and other nodes that do not request to join the meeting but transfer digital assets to the meeting for other purposes (e.g., transferring digital assets to a side chain, as described below). At operation 602, node 102 can use one or more attributes included in at least a portion of the transaction of the digital asset to the public group address to identify meeting members (i.e., the parties that transfer the digital asset to the meeting public key to join the meeting rather than for other purposes). For example, certain transactions can be marked as special transactions using attributes in the transaction. These attributes (whether present or not) can indicate the purpose of the transfer. For example, a marker can be included in the transaction when the transferrer does not request to join the meeting.

[0110] In response to detecting, at operation 602, a request whose implementation involves reallocating key shares, at operation 604, node 102 generates new private key shares in a manner similar to Figure 4 the way private key shares are generated at operation 408 of method 400. Other member nodes of the meeting also generate corresponding private key shares. These private key shares can be used with a threshold signature scheme for the new meeting public key. Members who will leave the meeting at this time do not generate new private key shares during operation 604 and since they will not be assigned private key shares to be used with the new meeting public key, they lose the ability to participate in the meeting and are no longer considered meeting members.

[0111] In addition, in response to detecting a reallocation request (a request whose implementation involves reallocating key shares), at operation 606, node 102 cooperates with other meeting members to transfer all digital assets in the public group address to a new public address associated with a new public key (which will later become the new meeting public key).

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

[0113] Updating Private Key Share Allocation While Retaining Existing Public Group Address

[0114] Refer to the following Figure 7 to illustrate another exemplary method 700 for updating private key share allocation. Method 700 can be carried out in cooperation with other nodes of the blockchain network 100 by a node 102 of the blockchain network 100.

[0115] In Figure 7 method 700, the conference public key does not change each time the allocation of member deposits changes. When a request to allocate new key shares is detected (at operation 702, which can occur by depositing digital assets to the public group address), node 102 cooperates with the other members of the conference to (at operation 704) issue new private key shares for the same public key to the new members of the group. The number of cooperating nodes is at least the threshold number of nodes required to generate a digital signature under the threshold signature scheme. At operation 704, additional key shares can be allocated while other key shares remain unchanged. This may involve a change in the threshold (of the threshold signature scheme), but in practice the change may be small. Alternatively, at operation 704, additional key shares can be allocated while updating other key shares. Such an update requires proof of deletion of any previous generation key shares. In this case, new shares can be allocated while maintaining the same threshold (in the context of SSS, this involves sharing a new polynomial of a higher order).

[0116] At operation 702, node 102 can use one or more attributes included in at least a portion of the transaction of the digital assets to the public group address to identify conference members (i.e., the parties who transfer digital assets to the conference public key to join the conference rather than for other purposes). For example, certain transactions can be marked as special transactions using attributes in the transaction. These attributes (whether present or not) can indicate the purpose of the transfer. For example, a marker can be included in the transaction when the transferor does not request to join the conference.

[0117] When members leave a conference using method 700, they can securely delete their private key shares. To ensure that the private key shares of old members are not available, members of the conference can be required to use node 102 with a special TEE. TEE is an architecture implemented at the hardware level that guarantees the instructions and data executed therein are protected from access and manipulation by the rest of the system. TEE can employ hardware mechanisms to respond to remote attestation queries, which can be used to verify the integrity of the system to external parties (e.g., other nodes in the conference).

[0118] Each member node may use a proven TEE, which is configured to generate one or more random secret values that remain inaccessible to the host system without compromising the hardware at the integrated circuit level. The secret values generated in this way will be used for the distributed generation of private key shares (e.g., in operation 410 of method 400 of Figure 4 ). The secret values can also be used to establish a shared public key during the setup phase of the session. The computations associated with the setup protocol are performed within the TEE enclave, such that no member or former member can derive any information about their own or other private key shares based on member - to - member communication or any other means. The enclave within the TEE enables a remote attestation protocol, which can be used to prove to other nodes that the TEE enclave is trustworthy and that it is running approved computer - readable instructions.

[0119] The computations associated with group changes are performed within the TEE enclave. For example, the generation of a new secure random secret is performed within the TEE enclave, which can be used for computing a new polynomial for SSS purposes.

[0120] Furthermore, the purpose of the TEE enclave is to ensure the secure deletion of previous key shares and previous secrets that are no longer in use before returning member deposits. More specifically, in order to return member deposits, the attestation protocol may require the TEE enclave to prove the deletion of key shares. Through the remote attestation protocol, each node 102 can interpret such a proof as an acknowledgement that the required deletion has occurred on other nodes. Thus, method 700 may also include confirming that the private key shares previously held within the TEE of a member leaving the session have been deleted from the node associated with that member. This confirmation can be made by receiving a proof of the deletion of the private key shares. Thus, the remote attestation protocol can be used to obtain a proof of the deletion of the private key shares previously held within the TEE of a member leaving the session.

[0121] Figure 6 method 600 of Figure 7 and Figure 6 method 700 of Figure 6 both offer various benefits. For example,

[0122] Figure 7 method 600 of Figure 6 does not rely on secure deletion and does not need to rely on trusted hardware. However, Figure 6 method 600 of

[0122] Figure 7 can benefit from such hardware because in some cases, such hardware can make the malicious pooling of key shares less likely. method 700 of Figure 6 avoids having to relock digital assets under a new session public key every time there is a membership change. Additionally, in some cases, method 700 can update membership faster compared to Figure 6 method 600 of Figure 7Under method 700, there is no need to add transactions to the blockchain to move all digital assets to a new public key because the digital assets are not moved to the new public key. That is, method 700 can be used to update membership without waiting for several blocks to be generated to confirm the transfer of digital assets to the new public key because the public key has not changed. Figure 7 Method 700 can be used to update membership without waiting for several blocks to be generated to confirm the transfer of digital assets to the new public key because the public key has not changed.

[0123] Logout from the meeting

[0124] As described above, group members can sometimes request to leave the meeting, and when group members logout from the meeting, the digital assets they deposited in the meeting pool may be returned to them. Referring below to Figure 8 FIG. 8 shows an exemplary method 800 of returning deposits in the form of a flowchart. This method can be performed by node 102 in cooperation with other nodes 102 of the meeting.

[0125] In operation 802 of method 800, node 102 receives a withdrawal request from a requester who is a member of the meeting. The withdrawal request may also be referred to as a logout request. The withdrawal request is a request to withdraw digital assets that were previously deposited by the requester and are currently under the control of the meeting. The request may have been broadcast by the requester to all meeting members.

[0126] In response to receiving the request, node 102 evaluates the request in operation 804 against certain criteria. These criteria can be predefined criteria. If the meeting operates according to a meeting protocol in which the meeting public key does not change each time group membership changes, then in operation 804, node 102 can confirm that the requester has deleted the private key share. A remote attestation protocol associated with the TEE can be used to obtain such confirmation.

[0127] If the meeting protocol is a protocol in which the meeting public key is changed when membership changes, then node 102 may not confirm the deletion of the private key share because the private key share is no longer valid. Instead, a new meeting key can be used, and other digital assets under the control of the meeting can be transferred to the new meeting key.

[0128] If node 102 approves the withdrawal request based on the evaluation, then in operation 806, the node helps to withdraw the digital assets. That is, node 102 uses its private key share to cooperate in generating a digital signature and uses the digital signature to transfer the digital assets previously deposited by the requester back to the requester. For example, the digital assets can be sent back to the address from which they were previously received. Operation 806 is performed according to a threshold signature scheme such that the withdrawal is only made when at least a threshold number of meeting members authorize the withdrawal. Operation 806 is performed after a period of inactivity during which the member wishing to logout is suspended. This waiting period prevents members from engaging in improper behavior while conducting the protocol for the return of their member deposits.

[0129] Un-trusted Agent for Smart Contracts

[0130] The meeting provides a security mechanism for performing various functions, and the meeting protocol can be used for a variety of different purposes. Generally, the meeting operates un-trustedly and provides control over the ownership of digital assets.

[0131] For example, the meeting protocol can be used to provide an un-trusted agent for a smart contract. More specifically, the meeting protocol can be used to activate a script such as a smart contract. The activation of the smart contract may "poke" the smart contract so that one or more functions of the smart contract are executed, or the activation of the smart contract can provide external data to the smart contract. That is, by using the meeting protocol, data outside the blockchain network (on which the smart contract is executed) can be obtained securely, and this data can be used in combination with the smart contract. Thus, the meeting protocol can be used to provide autonomous activation (i.e., "poke") of a blockchain script associated with a smart contract or provide access to external data (i.e., data previously unavailable on the blockchain) to such a blockchain script. As will be described in more detail below, the meeting protocol can be used to provide a poke and data feed for smart contracts on a blockchain network.

[0132] Now referring to Figure 9 , a system for activating a script on a blockchain network 900 is shown in block diagram form. The system includes a plurality of nodes 102a, 102b, 102c, which can be nodes of a blockchain network (such as Figure 1 's blockchain network). The nodes 102 include a plurality of meeting nodes 102a. The meeting nodes are nodes of the blockchain network 900 that have joined a group (herein referred to as meeting 110). The meeting nodes may have joined the group in the manner described above with reference to Figure 4 .

[0133] Figure 9 At least one of the nodes in the system of

[0134] The request may be a request to obtain external data (i.e., data not yet available on the blockchain network) and provide such data to a script such as a smart contract, or the request may be another request to activate such a script. For example, the request may be a request to trigger a smart contract when a specified condition is met (e.g., to activate a smart contract at a specific time, or when external data meets a specified condition, etc.).

[0135] The nodes of blockchain network 900 also include a plurality of information providing systems, also referred to as information providing nodes 102c. These information providing nodes 102c are electronic devices that purport to fulfill or assist in fulfilling requests issued by requester nodes 102b. For example, information providing nodes 102c can be operated to retrieve data from external data sources, such as from a web server.

[0136] As will be explained in more detail below, while information providing nodes are typically used to fulfill requests issued by requester nodes, conferencing nodes collaborate to provide security and reliability. For example, conferencing nodes can operate to improve the accuracy of information or actions performed or provided by information providing nodes purportedly fulfilling the request.

[0137] Therefore, the blockchain network 100( Figure 1 ) in node 102( Figure 1 ) can implement an untrusted proxy protocol to activate or facilitate the activation of scripts such as smart contracts. Such a node 102 may include a Figure 2 ) in a computer executable instruction that implements such a protocol. Such instructions are executed by the processor 210 ( Figure 2 ) is executed so that node 102 (for example, reference Figure 2 An electronic device 200 of the type described herein executes one or more methods of a protocol. These methods may include Figures 3 to 8 、 Figure 10 and Figure 11 Any one or a combination of methods 300, method 400, method 500, method 600, method 700, method 800, method 1000 or method 1100.

[0138] Now refer to Figure 10 , which shows that the requester node 102b ( Figure 9 ) execution method. Figure 10 The method may be referred to as requester method 1000. Requester node 102b may be a node associated with a script, such as a party to a smart contract on a blockchain network.

[0139] In the requester method 1000 ( Figure 10) In operation 1002 of the requester method 1000, the requester node 102b issues a request. The request is a request to activate a script such as a smart contract. The request offers a reward in the form of a digital asset associated with the blockchain network 100 in exchange for securely and reliably activating the script. The request may include various information, including one or more of the following: an identification of the script associated with the request, such as a public key associated with the script state; minimum participant information, which may specify the minimum number of information-providing systems to be used to activate the script; fee information, such as a mining fee, which will be provided to the session to facilitate activation of the script; and / or a threshold indicator, which defines an acceptable amount of change relative to the consensus data and / or information about external data to be used in the activation of the script. Instead of or in addition to the above data, other data may also be included in the request.

[0140] The request may be issued off-chain (i.e., "off-chain") from the blockchain. For example, the request may be issued on a web server accessible via the Internet. For example, the request may be issued on a switch. The switch may be a server on which multiple requests from multiple requester nodes are issued.

[0141] In operation 1004 of the requester method 1000, the requester node 102b determines that one or more sessions have accepted the request. That is, the requester node 102b determines that the sessions (which include multiple session nodes 102a) have offered to activate the script in accordance with the request.

[0142] The requester node 102b may select one or more sessions that have accepted the request in operation 1006. The requester node 102b may evaluate the reputation data of each session for one or more thresholds, for example. The reputation data may be based on ratings or other metrics provided by other requester nodes 102b that have previously participated in associated sessions to facilitate completion of the request.

[0143] The requester node 102b may select a single session among the sessions that have accepted the request, or the requester node 102b may select multiple such sessions. The requester node 102b may select all sessions or a subset of these sessions that have accepted the request. By selecting multiple sessions, the selected sessions can effectively compete with each other.

[0144] In operation 1008 of the requester method, the requester node broadcasts a transaction (which may be referred to as a blockchain transaction) payable to the meeting pool associated with the selected meeting. The transaction includes a bonus in the form of a digital asset payable to the public group address associated with the meeting that accepts the request and is selected in operation 1006. The transaction may include a link to data associated with the request. For example, the link may be to a server storing information about the request. Such information may include, for example, the identification of a script associated with the request, a public key such as associated with the script status; minimum participant information, which may specify the minimum number of information providing systems to be used to activate the script; fee information such as mining fees, which will be provided to the meeting to facilitate the activation of the script; a threshold indicator, which defines an acceptable amount of change relative to the consensus data and / or information about external data to be used in the activation of the script, or other information, conditions or requirements.

[0145] The transaction including the bonus may be time-locked such that the transaction becomes valid only at a specified future time. The time-lock can prevent the transaction from being added to the blockchain until after the specified time.

[0146] In the case where multiple meetings are selected (in operation 1006) to facilitate the completion of the request, the transaction may lock the bonus such that only the meeting that completes the request fastest is allowed to claim the bonus.

[0147] Now referring to Figure 11 , a meeting method 1100 is shown. The meeting method 1100 may be executed by a node of the meeting in cooperation with other nodes of the meeting. That is, the nodes of the meeting may be configured with computer-executable instructions for cooperating with other nodes of the meeting to execute the method 1100. That is, the meeting method 1100 may be executed by one or more nodes that have joined the meeting to become meeting nodes. More specifically, nodes in the blockchain network may join a meeting formed by a group of meeting nodes by broadcasting a transaction to the meeting pool. The transaction transfers control of one or more digital assets to the meeting. Such digital assets act as (member deposits for members to deposit) and such digital assets are forfeited as described above with reference to Figure 5 . The techniques for joining a meeting are described in more detail above with particular reference to Figure 4 .

[0148] After a node joins the meeting to become a meeting node, Figure 11 the method 1100 of

[0149] In operation 1102, the meeting node identifies the request. The request may be in Figure 10The request issued in operation 1002 of requester method 1000.

[0150] In operation 1104, the meeting nodes cooperate with other nodes of the meeting to accept the request. The acceptance of the request can be conveyed to the requester node that issued the request. The meeting nodes can be configured to cooperate with each other before accepting the request to determine whether to accept the request. For example, the meeting nodes can reach a consensus on whether to accept the request. For example, consensus can be reached by using private key shares. That is, the meeting members can use their private key shares to effectively vote on whether to accept the request. If at least a threshold number of private key shares are used to effectively vote to accept the request, the request will be accepted by the meeting. For example, this voting procedure can occur on a side chain (i.e., on a blockchain that is not the main blockchain).

[0151] After the meeting has accepted the request for the activation script from the requester, in operation 1106, the meeting nodes can detect a transaction from the requester that includes a bonus associated with the request. That is, the meeting nodes can determine that the transaction broadcast in operation 1008 of requester method 1000 has been added to the blockchain. As previously mentioned, the transaction broadcast in operation 1008 can be time-locked so that the transaction is not added to the blockchain until a specified time. In this case, operation 1106 is performed after that time.

[0152] Once the transaction broadcast in operation 1008 (which can be referred to as the "first transaction") is determined by the meeting nodes to have been confirmed (which can occur after at least a threshold number of blocks have been created on top of the first transaction), the nodes can prepare (in operation 1108) and publish a transaction (which can be referred to as the "second transaction") that is payable to the meeting pool (i.e., the public group address associated with the meeting).

[0153] The second transaction can be configured to allow multiple information providing systems (e.g., Figure 9 information providing node 102c) to add inputs to the transaction. For example, the second transaction can be signed SIGHASH_ALL|SIGHASH_ANYONECANPAY. SIGHASH_ALL is the default signature hash type that signs the entire transaction except for any signature script, thus preventing modification of the signed portion. SIGHASH_ANYONECANPAY is a signature hash type that signs only the current input.

[0154] An information providing system such as information providing node 102c may then submit to complete the request. To this end, the information providing system adds to the second transaction. For example, the information providing system adds a digital asset held by the information providing system as an input to the second transaction. Such a digital asset is provided by the information providing system as a guarantee (i.e., such a digital asset will be held as a margin) to ensure that the information providing system operates in accordance with the request and in accordance with the agreement.

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

[0156] The session may keep participation in the second transaction open until one or more predetermined conditions are met. The predetermined conditions may be, for example, time-based conditions. For example, when at least a threshold amount of time has passed after the second transaction is announced, the predetermined condition may close participation. That is, the information providing system may be given a certain amount of time during which it can participate. After this time period expires, the information providing system may no longer be allowed to participate.

[0157] The predetermined condition may require participation of at least a threshold number of information providing systems. That is, participation in the second transaction may be kept open until at least a threshold number of information providing systems have submitted to complete the request by adding the corresponding deposits as inputs to the second transaction.

[0158] The predetermined conditions for keeping participation open may be defined by the session or may be defined by the requester. For example, the requester may include the predetermined conditions in the request.

[0159] In operation 1110, after determining that a predetermined condition has been met (e.g., after an input has been added to the transaction by the information providing system), the meeting locks the participation of the information providing system. That is, the meeting node executing method 1100 can cooperate with other meeting nodes to prevent further submissions from being added to the second transaction. The meeting node can accomplish this by cooperating with other meeting nodes to consume the second transaction (i.e., unlock the second transaction). More specifically, the meeting node can use the private key share held by the node to cooperate with other such meeting nodes to generate a valid cryptographic signature for the transaction to consume the transaction. Such meeting nodes can cooperate by adding partial signatures generated based on the respective private key shares until a valid signature is generated according to the threshold signature scheme. Once the second transaction has been mined and a sufficient number of blocks have been added thereto to confirm the second transaction, the transaction is considered to have been consumed.

[0160] The second transaction serves as a register of the information providing system that has submitted to complete the request. That is, the second transaction acts as a register of the information providing system that has indicated that it has a solution to the request and has submitted to provide the solution. The second transaction is also used to collect deposits from each participating information providing system, and the second transaction is used to provide proof of the solution that the information providing system intends to submit so that the value cannot be changed at a later time and so that the value cannot be copied from other participants.

[0161] After the second transaction has been consumed, in operation 1112, data can be received by the meeting node from the multiple information providing systems that added inputs to the second transaction. For example, the information providing systems now provide the solutions proposed by each information providing system to the meeting node. The solution q can be sent together with other information used in the hash, where the hash was added to the second transaction by the information providing system. For example, the solution q can be provided together with the public key PK for the information providing system and the salt value s.

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

[0163] In operation 1114, the conference nodes cooperate with other conference nodes to identify the correct data for the request (e.g., the correct solution). For example, the conference nodes may determine a central point of the data received from the plurality of information providing systems. For example, in the case where the data represents numerical values, the central point may be the average of all the values received from the information providing systems in operation 1112 (i.e., the central point may be determined as the average of all the received values). By way of another example, in some embodiments, the central point may be the most common value or solution received from the information providing systems (i.e., the central point may be determined as the mode of all the received values). By way of yet another example, in some embodiments, the central point may be the median value received from the information providing systems (i.e., the central point may be determined as the median of all the received values). The central point may be determined based on the data received from the requester. For example, the requester may specify the technique for identifying the central point, and the conference may use the specified technique in operation 1114.

[0164] The central point may be selected by consensus of the conference nodes. By way of example, the central point may be determined on a side chain, and the conference nodes may use their respective private key shares to cooperatively generate a valid signature for the transaction representing the central point. When a valid signature is generated, this is an indication that the conference has reached a consensus on the central point.

[0165] In operation 1116, the conference nodes cooperate with other nodes of the conference to identify the information providing systems that provide the correct data. That is, the conference nodes may identify a subset of the information providing systems that provide data in a manner that purports to achieve the requested implementation. The subset consists of the information providing systems that provide data that is sufficiently similar to the correct data identified in operation 1114. For example, the nodes may identify as the subset the information providing systems that provide data near the central point identified in operation 1114. It will be understood that in some cases, all of the information providing systems that provide data may have provided the correct data, while in other cases, only a portion of such information providing systems may have provided the correct data.

[0166] To identify an information providing system that provides data that is similar enough to the correct data, a threshold can be used. The threshold can be specified by a requester. For example, a request issued by the requester can include a threshold indicator. The threshold indicator can be included in the request itself, or the threshold indicator can be linked to the request. That is, the request can be linked to data that defines the threshold indicator, such as data on a server. The threshold indicator defines the requested precision and can be used to identify a subset of information providers that are considered to have submitted correct information. For example, the threshold indicator can specify a percentage or other metric for determining whether given data is similar enough to the correct data to be determined as correct. An information providing system that provides data within the threshold amount from the correct data in operation 1116 is determined to have provided enough correct data and is identified as having provided correct data.

[0167] In some cases, only data that matches the correct data will be considered correct. That is, in some cases, the threshold indicator can be set to zero such that only data that matches the correct data is considered to be similar enough to the correct data to be determined as correct. That is, if the threshold indicator is set to zero, the data must be the same as the correct data that is considered valid.

[0168] In operation 1118, the conference node cooperates with other conference nodes to activate a script associated with the request. The conference node can activate the script based on the correct data. For example, the conference node can activate the script based on the center point of the data determined in operation 1114. The conference nodes cooperate to send a transaction on the blockchain network to unlock the script associated with the request. The transaction can include the correct data and can utilize the data according to the code in the script.

[0169] In operation 1120, the conference node cooperates with other nodes of the conference to distribute the bonus received in the transaction detected in operation 1106. More specifically, the transaction can be broadcast so as to transfer a portion of the bonus to each information providing system that is determined to have provided enough correct data (which can be a subset of all information providing systems that provided data in response to the request, or can be all information providing systems when all such systems provided correct data in response to the request). For example, the conference node can cooperate with other conference nodes in a group of nodes that form the conference to authorize the transfer of digital assets to each information providing system in the subset. The transaction transfers digital assets that are blocked by the conference public key to the public key associated with the information providing system that submitted enough correct data. To sign the transaction, the conference node uses its private key share to cooperate with other conference nodes (which use their respective private key shares 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 bonus to one or more conference members.

[0170] The meeting node, in cooperation with other nodes of the meeting, can also return at least some of the deposits provided by the information providing system. For example, the meeting node can broadcast a transaction that includes a valid signature generated in cooperation with other meeting nodes according to a threshold signature scheme. The request can return the deposit to any information providing system that provides sufficient correct data. The deposit of any information providing system that does not provide sufficient correct data can be forfeited. That is, such a deposit may not be returned. For example, the deposit of a node that does not provide sufficient correct data can be distributed among the nodes that do provide sufficient correct values.

[0171] The methods described above are generally described as being performed at a node, but the features of the methods depend on cooperation with other nodes and can be performed elsewhere.

[0172] It should be noted that the above embodiments illustrate rather than limit the invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The terms "comprising" and "including" etc. do not exclude the presence of elements or steps other than those listed as a whole in any claim or specification. In this specification, "comprising" means "comprising or consisting of...", and "including" means "including or consisting of...". The singular reference to an element does not exclude the plural reference to these elements, and vice versa. The invention can be implemented by means of hardware including several different elements and by means of a suitably programmed computer. In a device claim listing several means, several of these means can be implemented 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 to advantage.

Claims

1. A computer-implemented method, comprising: Broadcasting, by a node in a blockchain network, a transaction to a meeting pool to join a meeting formed by a group of nodes; After the meeting has accepted a request for an activation script from a requester, preparing, by the node, a blockchain transaction encrypted and locked with a public key associated with the meeting pool, the blockchain transaction being configured to allow multiple information providing systems to add inputs to the blockchain transaction; After the inputs have been added to the blockchain transaction, generating, by the node in cooperation with other nodes in the group, a valid cryptographic signature for the blockchain transaction to unlock the blockchain transaction, the generation of the cryptographic signature being performed by the node in cooperation with other nodes in the meeting using multiple private key shares, wherein each of the multiple private key shares is generated in a trusted execution environment (TEE) of an individual node in the meeting; After the transaction has been unlocked, receiving data from the multiple information providing systems; Determining a central point of the data received from the multiple information providing systems; And Activating, by the node in cooperation with other nodes of the meeting, the script based on the central point.

2. The computer-implemented method according to claim 1, wherein, The public key associated with the meeting pool is associated with a private key distributed among multiple meeting members as multiple private key shares.

3. The computer-implemented method according to claim 2, wherein, The signature is generated by a threshold number of private key shares.

4. The computer-implemented method according to claim 3, wherein, The private key shares are generated using an elliptic curve digital signature algorithm.

5. The computer-implemented method according to any one of claims 2 to 4, wherein, Each private key share is stored in a trusted execution environment.

6. The computer-implemented method according to claim 1, further comprising: Identifying, by the node, a subset of the information providing systems that provide data close to the central point based on the central point; And Authorizing, by the node in cooperation with other nodes in the group, a transfer of tokens to each information providing system in the subset.

7. The computer-implemented method according to claim 6, wherein, The central point is determined by consensus of the meeting nodes.

8. The computer-implemented method according to claim 7, wherein, The determination of the central point is performed on a side chain.

9. The computer-implemented method according to claim 1, wherein, The input includes tokens to be locked for security.

10. The computer-implemented method according to claim 1, further comprising: Detecting malicious activities of a malicious party, wherein the malicious party is one of the nodes of the meeting; And Using the private key shares to forfeit at least a portion of the tokens previously transferred to the meeting pool by the malicious party.

11. The computer-implemented method according to claim 10, wherein, The forfeiture includes transferring to a non-consumable account.

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

13. An electronic device, comprising: An interface device; A processor coupled to the interface device; A memory coupled to the processor, the memory storing computer-executable instructions that, when executed, configure the processor to perform the method according to any one of claims 1 to 11.

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

Images