Computer-implemented system and method for enabling secure storage of large blockchains across multiple storage nodes

Abstract

To provide secure storage of large block chains over multiple storage nodes.SOLUTION: A protocol is described which (i) allows a storage node to be rewarded to maintain a public block chain and (ii) verifies the integrity of a block chain using a proof-of-block chain storage (PoBS) scheme. This protocol provides a method of cryptographically checking if data files stored on a remote server using a challenge response method are intact. This protocol is secured against the man-in-the-middle attack. A malicious peer cannot pass the challenge to a third party storing data and return a response. The scheme is also publicly verifiable.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This specification generally relates to computer-implemented methods and systems suitable for implementation in nodes of a blockchain network. Modified blockchain node structures, network architectures, and protocols for handling large numbers of transactions and large transaction blocks are described. The present invention is particularly suited for, but not limited to, use with the Bitcoin blockchain. [Background technology]

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

[0003] A blockchain is a consensus-based electronic ledger, realized as a computer-based, decentralized, distributed system composed of blocks, which in turn are composed of transactions and other information. In 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 a hash of the previous block, allowing blocks to be chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs, which specify how and who can access the transaction's outputs. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

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

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptographic security system upon which Bitcoin is based and the data that can be stored on the blockchain to realize new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not purely limited to payments expressed in cryptocurrencies. Such solutions would be more versatile in their application while at the same time taking advantage of the benefits of blockchain (e.g., a permanent, tamper-proof record of events, distributed processing, etc.).

[0006] One area of research is the use of blockchain for the implementation of "smart contracts," which are computer programs designed to automate the fulfillment of the terms of machine-readable agreements or agreements. Unlike traditional contracts, which are written in natural language, smart contracts are machine-executable programs containing rules that can process inputs and generate results, which can then cause actions to be taken depending on those results.

[0007] Another area of blockchain-related interest is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. The tokens thus act as identifiers that allow real-world items to be referenced from the blockchain. Summary of the Invention

[0008] One of the key factors for measuring the health of a blockchain-based cryptocurrency is the number of nodes that actually memorize the blockchain. The blockchain grows according to the number of transactions per second. However, as the cryptocurrency gains popularity, the number of payments per second increases, and so does the blockchain's growth rate. This then makes the cost of memorization prohibitively expensive.

[0009] Thus, one technical problem is how to reconfigure a blockchain network so that it is adapted to store a significantly large blockchain. A further technical problem is how to achieve this without requiring all nodes on the blockchain network to store such a significantly large blockchain. Yet another technical problem is how to reconfigure a blockchain network so that specialized storage nodes can prove that they store at least a portion of such a significantly large blockchain. Yet another technical problem is how to reconfigure a blockchain network so that specialized storage nodes are incentivized to store at least a portion of such a significantly large blockchain.

[0010] An object of the present invention is to address these technical problems by providing the technical solution described herein. In particular, this specification describes a protocol that (i) allows storage nodes to be rewarded for maintaining a public blockchain, and (ii) proves the integrity of the blockchain using a Proof-of-Blockchain Storage (PoBS) scheme. The protocol provides a way to cryptographically check the integrity of data files stored on a remote server using a challenge-response method. The protocol is made secure against man-in-the-middle attacks: a malicious peer cannot pass a challenge to a third party storing the data and return a response. The scheme is also publicly verifiable.

[0011] Embodiments of the present invention may be provided in various forms. For example, a computer-readable storage medium may be provided that includes computer-executable instructions that, when executed, configure one or more processors to perform the methods described herein. Also provided may be an electronic device that includes an interface device, one or more processors coupled to the interface device, and memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, configure the one or more processors to perform the methods described herein. Furthermore, a node of a blockchain network may be provided, the node configured to perform the methods described herein. [Brief explanation of the drawings]

[0012] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment(s) described hereinafter. One embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] A diagram illustrating step 1 of the Proof of Blockchain Storage (PoBS) protocol is shown. [Figure 2] A diagram illustrating step 3 in the Proof of Blockchain Storage (PoBS) protocol is shown. [Figure 3] The distribution function f(T) is shown in the form of a bell curve. [Figure 4] An example of a transaction used in the Proof of Blockchain Storage (PoBS) protocol. [Figure 5] Demonstrates the use of random oracles in the Proof of Blockchain Storage (PoBS) protocol. DETAILED DESCRIPTION OF THE INVENTION

[0013] As described in the Summary of the Invention section, blockchains grow according to the number of transactions per second. However, as cryptocurrencies become more popular, the number of payments per second increases, and the blockchain growth rate also increases. Storage costs then become prohibitively expensive.

[0014] We describe a protocol that (i) allows storage nodes to be rewarded for maintaining a public blockchain and (ii) proves the integrity of the blockchain using a Proof-of-Blockchain Storage (PoBS) scheme. The protocol provides a way to cryptographically check the integrity of data files stored on a remote server using a challenge-response method. The protocol is made secure against man-in-the-middle attacks; a malicious peer cannot pass a challenge to a third party storing the data and return a response. The scheme is also publicly verifiable.

[0015] A system is provided, run by (for example) miners, where (for example) every minute each miner randomly samples transactions from the blockchain (miners are not necessarily synchronized).

[0016] A computer-implemented method is provided for a node of a blockchain network, the computer-implemented method comprising: selecting one or more transactions from the blockchain whose proof of storage is to be challenged, the selected one or more transactions having a transaction depth; creating a proof-of-blockchain storage transaction indicating the one or more selected blockchain transactions whose proof-of-storage should be challenged, and a proof-of-blockchain storage reward that can be unlocked by a storage node that stores the one or more selected transactions; sending the proof-of-blockchain storage transaction to one or more storage nodes on the blockchain network; Includes:

[0017] The method provides a means by which miners on a blockchain network can challenge storage nodes on the blockchain network to prove that they store the blockchain or at least a portion of it.

[0018] The one or more selected blockchain transactions have a transaction depth d corresponding to a depth of the one or more transactions in the blockchain, and the proof-of-blockchain storage reward can be set according to the transaction depth d, such that the greater the transaction depth d, the greater the reward.

[0019] This feature encourages storage nodes to store more of the blockchain because they receive a greater reward for storing deeper transactions.

[0020] The one or more blockchain transactions may be randomly selected from the blockchain. A list of blockchain transactions may be selected. Introducing random selection helps increase the security of the system. Security is further improved by ensuring that the one or more transactions are selected from one or more blocks that have received multiple confirmations on the blockchain.

[0021] The proof-of-blockchain storage transaction can include data associated with a newly mined block to be stored on the blockchain. The data associated with the newly mined block can be, for example, the block header data of the newly mined block. As such, miners can challenge a storage node on the blockchain when they have a newly mined block ready for storage on a storage node, with the challenge associated with the newly mined block to be stored.

[0022] The data associated with the newly mined block may be combined with data associated with the one or more blockchain transactions selected from the blockchain. For example, the data associated with the newly mined block may be combined with the data associated with the one or more blockchain transactions selected from the blockchain by XORing or concatenating. Further, the proof of blockchain storage transaction may include: a cryptographic function of data associated with said one or more selected blockchain transactions; a cryptographic function of data associated with the newly mined block combined with data associated with said one or more selected blockchain transactions; It may contain one of the following:

[0023] Such features set up a cryptographic function that can be computed by storage nodes that own one or more selected blockchain transactions to unlock rewards.

[0024] The proof-of-blockchain storage transaction further includes one or more blockchain network addresses associated with the one or more storage nodes on the blockchain network, which may be certified blockchain network addresses, where certification is achieved via a private key share scheme to increase the security of the system (as described in more detail below).

[0025] The method may further include generating a challenge prefix including an identification number of the one or more selected blockchain transactions, and the challenge prefix and the proof-of-blockchain storage transaction may be transmitted to the one or more storage nodes on the blockchain network. The challenge prefix may be used by one or more storage nodes to identify and extract the one or more selected blockchain transactions from their copies of the blockchain. To further increase the security of the system, a random oracle may be used to generate the challenge prefix and one of a cryptographic function of data associated with the one or more selected blockchain transactions and a cryptographic function of data associated with a newly mined block combined with the data associated with the one or more selected blockchain transactions. The challenge prefix may be digitally signed for integrity and authentication, or a challenge prefix message may be transmitted to the storage node in a non-transaction field.

[0026] Upon receiving the proof-of-blockchain storage transaction, the one or more storage nodes may access the one or more selected blockchain transactions stored on their nodes and use the one or more selected blockchain transactions to unlock the reward. For example, continuing with the previously described example, the reward may be: a cryptographic function of data associated with said one or more selected blockchain transactions; a cryptographic function of data associated with the newly mined block combined with data associated with said one or more selected blockchain transactions; It can be unlocked by calculating one of the following:

[0027] A computer-readable storage medium may be provided that contains computer-executable instructions that, when executed, configure one or more processors to perform the methods described herein.

[0028] There may further be provided an electronic device, the electronic device comprising: an interface device; one or more processors coupled to the interface device; a memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, configure the one or more processors to perform the methods described herein; and Includes:

[0029] Still further, a node of a blockchain network may be provided, the node being configured to perform the methods described herein.

[0030] Next, an example of a proof-of-blockchain storage protocol is described. In this section, we

number

number

[0031] [Protocol executed by each miner] 1. At time τ, a random set of transactions is selected from the blockchain (Figure 1). The list of transactions is stored locally (GenList function). 2. Upon successful mining of a new block, the successful miner creates a number of challenges (GenChal function). The challenge revenue is calculated, i.e., $R:=GetRew(d), where d is the transaction depth. 3. The miner broadcasts the newly mined block data, including the coinbase transaction with the challenge associated with the proof of storage (Figure 2).

[0032] Next, we define the functions used in PoBS construction.

[0033] Preprocessing: Set the PoBS reward function Rew that operates on transaction depth d. The deeper the transaction T is in the blockchain, the higher the PoBS reward.

[0034] GetReward Features: Let Rew be the reward function. Upon receiving depth d, GetReward(d): 1.Return Rew(d)

[0035] GenList Features: Let n be the total number of transactions required. Interrogating blockchain B produces a list L. GenList(n):

number

[0036] SETUP: Given a miner M holding (i) a newly mined block header Head and (ii) a list L of confirmed transactions, M generates a challenge Chal that indicates, among other things, a particular transaction T∈L for which M desires proof of possession. The transaction is recorded in a block that receives multiple confirmations.

[0037] GenChal Features: As defined previously, let Head be the block header, L be the list of confirmed transactions, and H be a cryptographic hash function. Let d be the depth of the transaction (the number of blocks or subsequent confirmations). The GenChal(Head,L) function is defined as follows: GenChal(Head,L):

number

[0038] Note that above we did not indicate the shape of the distribution function f(T): the function may be uniform or may follow a bell-shaped curve (see Figure 3).

[0039] PREPARE COINBASE TX: M completes the coinbase transaction using Chal and the recipient Bitcoin address of the storage node. For illustrative purposes, a simple example is given in Figure 4.

[0040] CHALLENGE: M is the challenge prefix pref=T containing the transaction identification number id The message may be (i) accompanied by a digital signature for integrity and authentication, or (ii) included in a non-transaction field, e.g., after OP_RETURN. M sends pref and chal to storage node S. Upon receiving Chal, the server calculates H(Head||T), which allows him / her to unlock the funds.

[0041] The above described approach can also benefit from adding a random oracle to the protocol. A random oracle is an oracle that responds to every query with a randomly chosen response (representing honesty). In this scenario, a miner M queries the random oracle (RO) for a block header Head. Upon receiving Head, the RO responds to every query with a truly random response H(Head||T), pref=T. id (See Figure 5.)

[0042] [certified bitcoin address] Furthermore, we propose using certified Bitcoin addresses to prevent collusion between miners and storage nodes for security purposes. In this regard, one of the challenges in a decentralized peer-to-peer system is ensuring that nodes can communicate with other nodes in the network in a trustworthy manner. As the network architecture of some implementations evolves, some nodes may take on more specialized tasks, while other nodes may rely on these specialized nodes as sources of specific data (as previously described) or as performers of specific functions. If a node intends to rely on another node for information or as a legitimate source, it must be able to establish a trusted relationship to communicate with that node. When multiple nodes may have different roles, it is advantageous to have a mechanism for determining and verifying a node's role. Furthermore, if a node is found to be illegitimate or malicious, other nodes should be able to remember this and ignore future communications from such a node. In a peer-to-peer system, the challenge is to solve these problems without compromising the peer-to-peer nature of the system by imposing a central authority.

[0043] Thus, methods and devices can be provided for managing the secure distribution of credentials from a group of autonomous specialized nodes to a requesting node. The secure distribution of credentials may use secret shares and a group private key that is not reconstructed or owned by any of the nodes. The credentials include the requesting node's identifier and a secret point, which the node assembles from portions of the secret point provided by each of multiple specialized nodes, the secret point being based on the group private key and a map-to-point hash of the requesting node's identifier. The nodes may be blockchain nodes in some implementations.

[0044] Two nodes may be certified by a group of autonomous specialized nodes and authenticate each other without involving the group or a centralized certification administrator or approver. The method may involve a first node and a second node deriving the same key using a bilinear pairing operation involving their respective identifiers and secret points. Provided the secret point and identifier were obtained from the group using the group private key, the bilinear pairing operation results in the generation of the same key at each of the two nodes, thereby authenticating their respective credentials and enabling trusted communication between the two nodes.

[0045] A node can obtain a credential from a group of specialized nodes, each of the specialized nodes having a private key share of a group private key. The method may include sending a request for a credential from the node to a plurality of specialized nodes, the node having an identifier; receiving from each node in the plurality of specialized nodes a portion of a secret point generated by the node from the identifier and the node's private key share; and generating the secret point by combining the received portions of the secret point, the secret point being the group private key times a map-to-point hash of the identifier, and the credential being the identifier and the secret point. Neither the specialized node nor any of the nodes may be required to obtain a complete copy of the group private key.

[0046] In some implementations, sending the request may include sending a separate request to each of a plurality of specialized nodes. The identifier may include an identifier string that identifies the node and a role string that identifies a role of the group of specialized nodes. In some cases, the identifier further includes an expiration time of the credential, and in some further cases, sending the request includes sending the identifier string and receiving includes receiving the identifier.

[0047] In some implementations, generating the secret point includes combining the received portions of the secret point, which may include summing in some example implementations.

[0048] In some implementations, the secret points are generated using secret shares and are based on the group secret key. In some of these cases, the secret shares use Lagrangian interpolation and the secret key shares of multiple specialized nodes without reconstructing the group secret key.

[0049] A computer-implemented method can also be provided for a first node to establish trusted communications with a second node, the second node having a second node identifier and a second secret point, the second secret point being a group private key multiplied by a map-to-point hash of the second node identifier, the group private key being associated with a group of nodes configured to grant credentials. The method can include obtaining a first secret point from the group of nodes, the first secret point being the group private key multiplied by the map-to-point hash of the first node identifier; sending the first node identifier to the second node; receiving the second node identifier; generating a first session key using a bilinear pairing operation with the map-to-point hash of the second node identifier and with the first secret point; and verifying that the first session key matches a second session key generated by the second node using a bilinear pairing operation with the second secret point and with the map-to-point hash of the first node identifier.

[0050] In some implementations, the bilinear pairing operation to generate the first session key is represented by the formula: K A =e(H1(id B ),s A ), and K A =e(s B ,H1(id A )) and the bilinear pairing operation that generates the second session key is characterized by the other of the equations, where e() is the bilinear pairing operation, H1() is a map-to-point hash, and id A and id B are the node identifiers of the first node identifier and the second node identifier, and s A and s B are the first secret point and the second secret point.

[0051] In some implementations, obtaining the first secret point includes obtaining a respective portion of the first secret point from each of a plurality of nodes in the group of nodes and combining the respective portions to form the first secret point without reconstructing the group secret key.

[0052] In some implementations, verifying includes sending a challenge encrypted with a first session key from the first node to the second node, receiving a response to the challenge, and determining, based on the response, that the second node validly decrypted the challenge using the second session key.

[0053] In some implementations, transmitting further includes transmitting the first nonce, receiving further includes receiving the second nonce and the calculated C0 value, where the C0 value comprises a hash of a concatenation of the second session key, the first nonce, and the second nonce. In some of these cases, the concatenation further comprises a first node identifier and a second node identifier. In some of these cases, generating includes generating a calculated C1 value comprising a hash of a concatenation of the first session key, the first nonce, and the second nonce, and verifying includes verifying that the calculated C0 value matches the calculated C1 value.

[0054] In some implementations, the second secret is the group secret key multiplied by a map-to-point hash of the second node identifier.

[0055] In some implementations, the first secret and the second secret are each provided by a group of nodes to the first node and the second node, respectively, using secret sharing.

[0056] For example, each node in a group of nodes receives a share k of private key k. i Secret sharing is used in threshold cryptosystems where a secret k is divided among n players, thereby requiring at least t+1 participants to cooperate to reconstruct k. Knowledge of any t pieces of the secret k leaves the latter secret k undetermined.

[0057] Secret sharing is based on polynomial interpolation, and the secret is assumed to be an element of a finite field F. This scheme consists of a dealer (a dealerless version also exists), a set of n participants U1, , U n In the protocol, any random secret is stored as f(0) in a t-th order polynomial f(x), and only node i knows its share f(x i ) can be calculated. When t+1 out of n nodes cooperate, they can calculate f(x1), f(x2), . . . , f(x n ) corresponding shares k1, k2, . . . , k (of key k) n Any point on f(x) can be reconstructed using Lagrange polynomial interpolation. Lagrange polynomial interpolation is the process of finding a function f(x) of degree t at t+1 points p={(x1,f(x1)),(x2,f(x2)),...,(x t+1 ,f(x t+1 ))},

number

number

[0058] In one implementation with dealerless share distribution, 1. Each node i has a known node x i Each x i must be unique. 2. Each node i is assigned a random polynomial f with degree t. i Generate (x). 3. Each node i can tell every other node its respective point f on the polynomial i (x j ) mod n secretly (encrypted with the recipient's public key). 4. Each node i receives all its f1(x i ),f2(x i ),···f p (x i ), all mod n(n is a function of the base field F n is a characteristic of (F n sums over GF(n), sometimes denoted z / nz) to find the k shares over the polynomial f(x) mod n i =f(x i ) mod n.

[0059] A node in the group of nodes obtains a secret point s for the requesting node. A They work together to generate the secret point s A is in the cyclic group G1, the importance of which will become clear from the following discussion of handshakes and pairings. The secret point is s A =k·H1(id A ) Associated with identifiers as id A is the identifier of the requesting node 504. The credentials are (id A ,s A), where H1 is a map-to-point hash function, as described in more detail below.

[0060] To generate a secret point without reconstructing the group secret key k, a group of nodes can use a form of Secret Share Joining to A The requesting node sends a credential request to at least t+1 nodes in the group of nodes. Each of these nodes sends s to the requesting node. A In detail, the secret point s A Each share of Ai is determined by node i and sent to the requesting node, which then converts them into a secret point s A In some instances, shares Ai are combined by summing them, and the secret point s A Get.

[0061] Next, an exemplary process for group-based distributed generation of credentials is described. The process is performed by a requesting node. It begins with the requesting node setting an index i to 1. The requesting node then requests a credential from node i, which is a specialized node in a group of nodes configured to perform an implementation of the credential granting procedure described herein. Node i receives a group private key share k i Using a part of , the secret point s A Determine the ith part of s Ai It may also be referred to as

[0062] The request node receives the part s from the i-th node. Ai , i.e., it receives partial credentials. The receiving node evaluates whether index i is t+1. If so, the receiving node has received t+1 partial credentials, otherwise it has received secret point sA If i is not yet equal to t+1, it is incremented by 1 and the process returns to request a further partial credential from another node in the group of nodes. If i is equal to t+1, then in operation 712 the requesting node obtains the secret point s A Assemble.

[0063] Once credentials are obtained through the collaboration of nodes within a group of nodes, it is advantageous to have a mechanism to check or verify the credentials without relying on a central authority or going back to the group for verification / authentication. In that way, two nodes from the same group of nodes that claim to have valid credentials can verify each other's credentials without incurring the time delays and communication overhead associated with having a group of nodes collaboratively attest and verify issued credentials.

[0064] As an overview, assume that the group private key k is a member of a finite field, i.e., k∈Z. q The requesting node that has acquired the credential sends the credential along with its identifier id A and the secret point s in the cyclic group G1 A In this exemplary embodiment, an identifier (or "pseudonym") id A is (Alice||role||expiration time), where || denotes the concatenation of two strings, and role is a string or other alphanumeric identifier associated with a group of nodes and / or their functions or roles. The requesting node can reveal its identifier to anyone, but s A Keep it a secret.

[0065] Another request node requests the identifier id as (Bob||role||expiration time) B and secret point s B and get.

[0066] secret point s A is, s A =k·H1(id A ) and the secret point s B is, s B =k·H1(id B )

[0067] When Alice and Bob want to establish trusted communication with each other, i.e., when one or both of them want to verify the other's credentials, the two nodes exchange their respective identifiers / pseudonyms without disclosing their secrets.

[0068] Then, node Alice receives the session key K A of, K A =e(H1(Bob||role||expiration time),s A ) e() is a bilinear map, i.e., a pairing operation, and node Bob generates the session key K B of, K B =e(s B ,H1(Alice||role||expiration time)) It is calculated by calculating:

[0069] The operation H1() is a map-to-point function, as explained further below. Due to the properties of pairing, the two keys are the same, i.e., K A =K B By sending a challenge value and getting a response, two nodes can prove that the protocol was successful, i.e., that they each hold credentials issued by the same node group representing the same role. Alternatively, one party can send the other some content, which will be successfully decrypted if, and only if, the handshake is successful.

[0070] The pairing operation in this example is s A and s B are from the same cyclic group G1 in this case. In other cases, the two can be used to compare values in different abelian groups. e:G1×G2→G T The two abelian groups G1 and G2 may be from different cyclic groups G1 and G2, which are related as T are cyclic groups of the same order.

[0071] There are certain parameters in the generation of credentials that are public. These may be generated by any node in the process and shared with other nodes. If E is a field F q Starting from the assumption that q is an elliptic curve containing n points above, if q is a power of a prime relatively prime to 2 and 3, then the public parameters are: params=(p,G1,G2,G T ,g1,g2,e,H1,H2) where g1 (resp. g2) is a generator of a group G1 (resp. G2) of prime order p with a bilinear mapping e(.,.). G1 is a generator of E(F q ) and e(g1, g2) is a cyclic subgroup of G T where H1 and H2 are map-to-point hashes for G1 and G2, respectively. As mentioned above, in some implementations, and in many of the examples described herein, only G1 may be used, because the same map-to-point hash function H1 generates the secret point s A and s B This means that it can be used for both

[0072] In some elliptic curve cryptosystems, hashing algorithms are used to map a password or other string of characters, which is an element of a finite field, to a point on a given elliptic curve. These are map-to-point hashes. More precisely, a map-to-point hash function H1 is a transformation that takes a message as input and returns a point P∈E(K). More specifically, H1 returns a point P∈E(K)[r], where E(K)[r] is a subgroup of E(K) generated by G1. In this scheme, the base field F q There is a one-to-one mapping from m to the curve, which allows hashing using f(H(m)), where H is a classical hash function and H(m)∈F q is.

[0073] Next, the message flow between two nodes A and B when establishing a trusted communication channel by verifying each other's credentials is described. In this exemplary implementation, node A has a trusted communication channel with its identifier id A Provides the Node B with the identifier id A is publicly available and in some cases may be obtained by node B from another source. From this, node B obtains the identifier of node A and the secret point s held by node B. B and a map-to-point hash function H1 defined by the group of nodes that issued the credential to generate a session key K B The session key K can be generated. B is a pairing operation e() similarly defined by a group of nodes, i.e., K B =e(s B ,H1(Alice||role||expiration time)) In this example, the Node B's identifier id B is (Alice||role||expiration time).

[0074] Node B receives the identifier id BNode A then receives the identifier of node B, its secret point s A , and the same pairing operation and map-to-hash function, i.e., K A =e(H1(Bob||role||expiration time),s A ) Using the session key K A can be generated similarly.

[0075] If the secret points are generated legally and collaboratively by a group of nodes using the same group secret key k and the identities of each node A and B, then the pairing operation is A =K B This may be tested in any number of ways. In this example implementation, node A obtains a session key K A Node B sends a challenge encrypted with its session key K B The response is sent using the session key K B Based on this, both nodes can verify that they have the same session key. That session key may be used to encrypt communications between the two nodes. In another implementation, the session key may be used to encrypt communications that lead to the setup of another key. In yet another implementation, communications between two nodes simply rely on the above procedure to verify / authenticate each other's credentials, and communications between the two nodes are either not encrypted or are encrypted using the nodes' regular public-private key pair.

[0076] Next, another exemplary implementation is described. In this example, node A generates a random nonce A It starts by generating an identifier id A and sends this nonce to Node B. Node B then receives its own nonce BNode B then generates a value C0 which, in this example, is a hash of the result of the pairing operation and other data, including the nonce. In this example, value C0 is C0=H(e(s B ,H1(id A ))||id A ||id B ||nonce A ||nonce B ) where H is a string-to-string collision-resistant hash function. In one example, H is SHA-256.

[0077] Node B then replies to node A with its identifier id B , that nonce B , and provides the value C0. Node A then performs a similar calculation to obtain the value C1, which in this example is C1=H(e(H1(id B ),s A )||id A ||id B ||nonce A ||nonce B ) It is expressed as:

[0078] Note that the only difference in the arguments in the formula for C1 relative to C0 is the pairing operation. Thus, if the bilinear pairing operation confirms that node A and node B's credentials were obtained from the same node group, the two values should match. Node A can verify that they match, and if so, sends C1 to node B, which also verifies that they match. In one implementation, the value C0 = C1 is then used as a session key to encrypt communications between node A and node B. In some implementations, the nodes simply rely on a regular public-private key pair to encrypt communications, and the operations described above are for authentication, not for establishing a session key.

[0079] In some example implementations, the data or strings that are concatenated and hashed to form the values C0 and C1 may include other data or strings, or may exclude some of the example strings listed above. For example, in one implementation, the values C0 and C1 are concatenated and hashed to form the identifier id A and id B However, it will be appreciated that the hash and nonce help protect the communication from man-in-the-middle attacks.

[0080] It should be noted that the above-described embodiments are illustrative rather than limiting of the invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. For example, while a transaction may transfer Bitcoin, it should be understood that users may instead exchange other resources, such as information, contracts, and tokens, using the methods and systems described herein. A token represents an asset or resource according to a smart contract associated with the token, whereby control of the token confers control of the asset or resource. The smart contract itself may be stored outside the blockchain, or it may be stored within one or more transactions.

[0081] In the claims, any reference signs placed between parentheses shall not be construed as limiting the scope of the claim. The words "comprise" and "comprises", and the like, do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprise" means "comprises or consists of", and "comprises" means "including or consists of". The singular reference of an element does not exclude the plural reference of such elements, and vice versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and 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. 1. A computer-implemented method for a first node to establish trusted communications with a second node, the second node having a second node identifier and a second secret, the second secret being a group secret key multiplied by a map-to-point hash of the second node identifier, the group secret key being associated with a group of nodes configured to grant credentials; The method comprises: obtaining a first secret point from the group of nodes, the first secret point being the group secret key multiplied by a map-to-point hash of a first node identifier; Obtaining the first secret from the group of nodes includes sending a request from the first node to a plurality of nodes in the group of nodes; receiving a respective portion of the first secret point from each node in the plurality of nodes of the group of nodes; and combining the received respective portions of the first secret point to generate the first secret point without reconstructing the group secret key; transmitting the first node identifier to the second node; receiving the second node identifier; generating a first session key using a bilinear pairing operation with a map-to-point hash of the second node identifier and with the first secret point; verifying that the first session key matches a second session key generated by the second node using the bilinear pairing operation with the second secret point and with a map-to-point hash of the first node identifier; sending the request from the first node to the plurality of nodes of the group of nodes includes sending an identifier string identifying the first node, and receiving from the plurality of nodes of the group of nodes includes receiving the first node identifier. method.

2. The bilinear pairing operation for generating the first session key is represented by the formula: K Ａ = e(H １ (id Ｂ ), s Ａ ), and K Ａ =e(s Ｂ ,H １ (id Ａ )) and the bilinear pairing operation for generating the second session key is characterized by the other of the equations, e() is the bilinear pairing operation, and H １ () is the map-to-point hash, and id Ａ and id Ｂ are the node identifiers of the first node identifier and the second node identifier, and s Ａ and s Ｂ are the first secret point and the second secret point, The method of claim 1.

3. The method of claim 1, wherein the first node identifier includes an expiration time for the credential.

4. 2. The method of claim 1, wherein verifying comprises sending a challenge from the first node to the second node encrypted with the first session key, receiving a response to the challenge, and determining based on the response that the second node validly decrypted the challenge using the second session key.

5. The transmitting further includes transmitting the first nonce, and the receiving further includes transmitting the second nonce and the calculated C ０ and receiving a value of C. ０ The method of claim 1 , wherein the value comprises a hash of a concatenation of the second session key, the first nonce, and the second nonce.

6. The method of claim 5 , wherein the link further comprises the first node identifier and the second node identifier.

7. The generating includes generating a calculated C session key that includes a hash of a concatenation of the first session key, the first nonce, and the second nonce. １ The verifying step includes generating a calculated C ０ The value was calculated as C １ The method of claim 5 , further comprising verifying that the value matches.

8. The method of claim 1 , wherein the second secret point is the group secret key multiplied by the map-to-point hash of the second node identifier.

9. 2. The method of claim 1, wherein the first secret and the second secret are each provided by the group of nodes to the first node and the second node, respectively, using secret sharing.

10. The method of claim 1, wherein the credentials include the first node identifier and the first secret point.

11. 11. A computer-readable storage medium containing computer-executable instructions that, when executed, configure one or more processors to perform the method of any one of claims 1 to 10.

12. an interface device; one or more processors coupled to the interface device; a memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, configure the one or more processors to perform the method of any one of claims 1 to 10; Electronic devices including:

13. A node of a blockchain network, the node being configured to perform the method of any one of claims 1 to 10.

Images