Method and system for consistent distributed memory pool in a blockchain network

Abstract

To provide a method and system for a consistent distributed memory pool in a block chain network.SOLUTION: In a block chain network 100, a memory pool node 104 of a distributed memory pool network (DMP) 106 on which a distributed hash table (DHT) is mounted receives a request for updating routing information of the memory pool node, and initializes one set of random walks in a key space of the DHT, and, at least partially based on first identification information stored in a second table of long-distance table type, generates a first record in a first table, and executes at least a first random walk out of the one set of random walks, and generates a third record in a fourth table of short-distance table type from the table maintained by a second memory pool node of the DMP network.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to computer-based storage and transfer technologies. The present invention also relates to distributed hash tables, and more particularly to methods and devices for improving security and integrity for the storage and retrieval of shared information. The present invention is particularly suitable for, but not limited to, use in blockchain applications and blockchain-implemented transfers. The present invention also relates to improving the speed of operations over blockchain networks by enabling faster read and write operations, and to improving security mechanisms for blockchain-implemented systems by preventing or mitigating attacks and / or malicious activity, such as routing and storage attacks, in distributed memory pools. [Background technology]

[0002] This document uses the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, private (permissioned) and public (un-permissioned) 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 also within the scope of the present invention.

[0003] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to consider using both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency realm. Such a solution would be able to take advantage of the benefits of blockchain (e.g., permanent, tamper-proof record of events, decentralized processing, etc.) while making it more versatile in these applications.

[0004] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system composed of blocks, which result in blockchain transactions. Each blockchain transaction is a data structure that encodes the transfer of control of a digital asset or chain of record 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, thereby chaining blocks together to create a permanent, immutable record of all blockchain transactions written to the blockchain since the blockchain's inception. Blockchain transactions contain small programs known as scripts embedded in the blockchain transaction's inputs and outputs, which specify how the blockchain transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a scripting language based on Stack.

[0005] In order for a blockchain transaction to be written to the blockchain, it must be "validated." Network nodes (miners) work to ensure each blockchain transaction is valid, and invalid blockchain transactions are rejected from the network. A software client installed on a node performs this validation operation on unspent blockchain transactions (UTXOs) by executing lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the blockchain transaction is valid and the blockchain transaction is written to the blockchain. Thus, for a blockchain transaction to be written to the blockchain, it must i) be approved by the first node that received the blockchain transaction; if the blockchain transaction is approved, the node relays it to other nodes in the network; ii) it must be added to a new block constructed by miners; and iii) it must be mined, i.e., added to the public ledger of past blockchain transactions.

[0006] A network node that receives a new blockchain transaction attempts to quickly push the blockchain transaction to other nodes in the network. Before a new blockchain transaction can be sent to other nodes, it is "validated," meaning that it is checked against a set of criteria to ensure that it meets the basic requirements for a proper blockchain transaction according to the applicable blockchain protocol.

[0007] To be written to the blockchain, blockchain transactions are assembled into blocks by nodes ("miners") designed to collect blockchain transactions and form them into blocks. Miners then attempt to complete a "proof of work" for their nodes. Miners across the blockchain network compete to be the first to assemble a block of blockchain transactions and compete for that block's associated proof of work. Successful miners add their confirmed block to the blockchain, and the block is propagated through the network so that other nodes that maintain copies of the blockchain can update their records. Those nodes that receive the block also "validate" the block and all of the blockchain transactions within it to ensure compliance with the formal requirements of the protocol.

[0008] One of the bottlenecks associated with blockchain implementations is the delay associated with waiting for miners to complete the proof-of-work that results in confirming a block of blockchain transactions and adding the block of blockchain transactions to the blockchain. Using the Bitcoin system as an example, the system, by design, takes approximately 10 minutes for a block to be confirmed and added to the blockchain. Meanwhile, unconfirmed blockchain transactions are accumulated in a memory pool (referred to here as a "mempool"), a near-perfect copy of which is maintained at each node in the network. Analysis of the Bitcoin architecture indicates that at a 10-minute block confirmation throughput, the system can handle a transaction throughput of approximately 3 new unconfirmed blockchain transactions per second, based on the size of typical blockchain transactions and blocks and the rate at which these accumulated unconfirmed blockchain transactions can be incorporated into new blocks.

[0009] It would be advantageous to use a blockchain-based network such as Bitcoin to enable or facilitate the use of widely available cryptographically secure exchanges. Such exchanges may involve, for example, payment processing, such as credit card transactions, although the present invention is not limited to financially oriented applications. However, a transaction throughput of approximately 3 transactions per second is insufficient to process such electronic payments, which currently operate at a transaction volume of approximately 50,000 per second. Therefore, it is desirable to find a solution to the speed and scalability constraints that currently limit the ability of blockchains to process large volumes of transactions. Summary of the Invention

[0010] Such a solution is currently contemplated.According to the present invention, there is therefore provided a method and apparatus as defined in the accompanying claims.

[0011] According to the present invention, as described in more detail below, methods and devices may be provided that enable high-speed propagation (including storage and retrieval) of blockchain transactions or other data through a network of memory pool nodes (distributed memory pools or DMPs) designed to implement the functionality of a distributed hash table (DHT). A DMP that implements a DHT may include multiple memory pool nodes distributed over a network (e.g., a DMP network), such as a merchant network or other network. In some embodiments, the DMP network stores data as records containing keys and values.

[0012] As described in more detail below, the memory pool nodes form a distributed system that provides storage and retrieval of (key, value) pairs, allowing any participating memory pool node to efficiently look up the value associated with a particular key. In some embodiments, the memory pool nodes are also responsible for determining routing information to establish paths and / or connections between memory pool nodes. The data stored as the "value" of a (key, value) pair may include any data that can be stored by a computer system that includes blockchain transactions, as described in this disclosure.

[0013] In a further or alternative aspect, the present disclosure describes a memory pool network node for facilitating rapid distribution of blockchain transactions over a network of interconnected nodes used to implement a DHT of blockchain transactions, a subset of which are memory pool network nodes interconnected by an overlay network. Hereinafter, the term "mempool network node" may be used interchangeably with the term "mempool node" for convenience only.

[0014] Thus, in accordance with the present invention, there may be provided a computer-implemented method (and corresponding system) as defined in the appended claims.

[0015] The method may be described as a method for implementing a DHT using memory pool nodes. The computer-implemented method includes, at a mempool node of a distributed mempool network (DMP) implementing a distributed hash table (DHT), receiving a request to update routing information for the mempool node; initializing a set of random walks within a key space of the DHT, the set of random walks being used to generate a set of key-value records to be stored by the mempool node; generating a first record in the first table based at least in part on first identification information stored in a second table of a long-distance table type by performing at least the first random walk of the set of random walks, the second record including the second identification information and an address associated with the second identification information; and generating a second record in a third table of a short-distance table type by at least retrieving a record from a table maintained by the second mempool node of the DMP network. and generating a third record in a fourth table of type.

[0016] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0017] [Figure 1] 1 illustrates an exemplary network of nodes having an overlay network of memory pool nodes according to an embodiment. [Figure 2] 1 illustrates an exemplary network of memory pool nodes implementing a DHT according to an embodiment. [Figure 3] 1 illustrates an exemplary network of memory pool nodes implementing operations for updating routing information of memory pool nodes of a DMP network according to an embodiment. [Figure 4] 1 illustrates an exemplary network of memory pool nodes implementing search operations for a DMP network according to an embodiment. [Figure 5] 1 illustrates a flowchart of an exemplary process for updating routing information of a memory pool node of a DMP network, according to an embodiment. [Figure 6] 1 illustrates a flowchart of an exemplary process for retrieving information from a memory pool node of a DMP network, according to an embodiment. [Figure 7] 1 illustrates an example environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0018] Reference is first made to FIG. 1 , which illustrates in block diagram form an exemplary network related to a blockchain, which may be referred to herein as blockchain network 100. Blockchain network 100 is a peer-to-peer, open membership network, and anyone may join without an invitation and / or consent from other members. Distributed electronic devices running an instance of the blockchain protocol on which blockchain network 100 operates may participate in blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrency. In yet other embodiments, blockchain network 100 may be a storage network running an instance of the DHT protocol, which is described in more detail with respect to FIG. 2.

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

[0020] The nodes 102 of the blockchain network 100 are coupled to one another using suitable communication technologies, which may include wired and wireless communication technologies. Often, the blockchain network 100 is implemented at least in part over the Internet, and some of the nodes 102 may be located in geographically dispersed locations.

[0021] Nodes 102 maintain a global ledger of all blockchain transactions on the blockchain, grouped into blocks, each containing a hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 102 may store a full or partial copy of the global ledger. Blockchain transactions by nodes 102 that affect the global ledger are verified by other nodes 102 to ensure the validity of the global ledger is maintained. The details of the implementation and operation of blockchain networks, such as those using the Bitcoin protocol, are recognized by those skilled in the art.

[0022] Each blockchain transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how the blockchain transaction's outputs can be accessed and by whom. An output of a blockchain transaction may be an address to which a value is transferred as a result of the blockchain transaction. This value is then associated with that output address as an unspent blockchain transaction output (UTXO). Subsequent blockchain transactions may then reference that address as an input to unlock that value.

[0023] Nodes 102 may be of different types or categories depending on their function. It has been suggested that there are four basic functions associated with nodes 102: wallet, mining, full blockchain maintenance, and network routing. Variations of these functions may exist. Nodes 102 may have more than one function. For example, a "full node" provides all four functions. A lightweight node may be implemented, for example, as a digital wallet and may feature only wallet and network routing functions. Rather than storing the complete blockchain, a digital wallet may track block headers, which serve as an index when querying blocks. Nodes 102 communicate with each other using a connection-oriented protocol such as TCP / IP (Transmission Control Protocol). In various embodiments, memory pool nodes 104 are not members of the blockchain network and are not responsible for implementing the Bitcoin / blockchain protocol.

[0024] This application proposes and describes a further type or category of node: memory pool nodes 104. In various embodiments, memory pool nodes 104 provide fast propagation and retrieval of blockchain transactions. In such embodiments, memory pool nodes 104 do not store the complete blockchain or perform mining functions. In that sense, they are similar to lightweight nodes or wallets, but they include additional functionality to enable fast propagation and retrieval of blockchain transactions. The operational focus of memory pool nodes 104 is the propagation and retrieval of data stored in the DHT implemented by the DMP network, and, in the case of a blockchain implementation in particular, the propagation of unconfirmed blockchain transactions to other memory pool nodes 104, which then quickly push the unconfirmed blockchain transactions to other nodes 102 in the blockchain network 100.

[0025] The memory pool nodes 104 are collectively referred to as DMPs 106. In various embodiments, the memory pool nodes 104 and DMPs 106 are implemented as part of a merchant network, as described in this disclosure. As shown, for ease of illustration, the memory pool nodes 104 may be integrated into the blockchain network 100 as a physically separate network in FIG. 1 . That is, the DMPs 106 may be considered sub-networks within and distributed throughout the blockchain network 100. The memory pool nodes 104 may perform one or more dedicated functions or services.

[0026] To ensure that the DMP 106 operates reliably and can provide service at a particular security level, the memory pool node 104 needs to maintain a good overview of the DMP 106, and therefore an efficient routing protocol needs to be in place. As explained in more detail below, each time a memory pool node 104 receives an update or receives a request, the memory pool node 104 may need to broadcast the information to several other memory pool nodes 104, as well as other nodes 102. With respect to the DMP 106, this corresponds to finding a solution to the multiple traveling salesman problem (MTSP). There are multiple solutions to this problem, any one of which may be used by the DMP 106. Each memory pool node 104 performs some modern form of routing optimization.

[0027] In some implementations, the DMP 106 is implemented as a decentralized IP multicast type network.

[0028] In one exemplary situation, an ordinary node 102 on the blockchain network 100 generates a blockchain transaction to be stored by a DMP 106. It may send the blockchain transaction to a memory pool node 104, which may then broadcast it to other memory pool nodes 104, or may send the blockchain transaction directly to multiple memory pool nodes 104 if it knows the IP addresses of the memory pool nodes 104. In some examples, all memory pool nodes 104 of a DMP 106 are members of a single address, and therefore, all blockchain transactions sent to that address are received by all memory pool nodes 104. However, in some cases, there may be more than one address associated with a DMP 106, and the receiving memory pool node 104 may evaluate from routing information whether further broadcasting of the blockchain transaction to other addresses is necessary to propagate the blockchain transaction to the complete DMP 106.

[0029] Each node 102 in the network 100 typically maintains a separate memory pool containing unconfirmed blockchain transactions that it has recognized and that have not yet been incorporated into the blockchain by miners completing proof-of-work. The significant increase in the number of blockchain transactions resulting from use in payment processing increases the amount of blockchain transactions stored in each memory pool. Thus, although nodes in the DMP 106 can receive new blockchain transactions nearly simultaneously, they may have storage capacity limitations for large, rapidly changing memory pools.

[0030] To address this issue, the present application proposes that the memory pool node 104 use a shared memory pool implemented by the DMP 106.

[0031] Assuming an average blockchain transaction (TX) size of 500 bytes and a transaction rate of ~10 TX / s, the DMP 106 may receive ~400 GB of incoming data daily. This data is stored in a memory pool of unconfirmed blockchain transactions for a variable amount of time. Therefore, the DMP 106 requires significant storage and capacity to store data quickly. To avoid placing too many requirements on each individual memory pool node 104, the memory pool nodes 104 implement a shared memory pool, e.g., the DMP 106. Instead of having each memory pool node 104 keep all incoming TX in its own memory pool, each memory pool node 104 stores only a specific portion of the total and hashes the associated key-values ​​of the remaining portion.

[0032] A DMP is a type of decentralized distributed system that allows for the division of key set membership among nodes and can send messages only to owners of given keys in an efficient and optimized manner. Each node in the network can be viewed as a cell in a hash table array. DMPs are designed to manage multiple nodes, allowing new nodes to join the network and old nodes to leave and crash without compromising the integrity of the shared data. DMPs ensure decentralization (there is no central authority or central coordination), scalability (the system operates efficiently with millions of nodes), and fault tolerance (the system is reliable and can manage nodes joining and leaving the network or crashing). Each node in the network may maintain contact with only a small number of other nodes, so the network does not become overloaded when data changes or new data exists.

[0033] The same concept may be applied to a UTXO database, i.e., a database containing the set of all unspent outputs on a blockchain. A UTXO database may be constructed using a DMP that implements a DHT to share its contents among a set of nodes.

[0034] The DHT protocol, described in more detail below, provides a solution to the above problems. Specifically, the DHT protocol provides global consensus on the validity of blockchain transactions stored in memory pool nodes 104, the consistency and integrity of the stored data, provides fast propagation and lookup operations, and prevents routing and storage attacks on memory pool nodes 104.

[0035] One factor to consider when determining the size of a robust DHT is the number of replicas required to ensure the robustness and reliability of the entire network. As mentioned above, nodes can join and leave the network, and this fact should not affect data availability. If a node that stores blockchain transaction A leaves the network, it will be necessary to find blockchain transaction A in another part of the network. For example, in existing blockchain networks such as Bitcoin, the network has a number of blockchain replicas equal to the total number of nodes in the network (5,000 replicas on average), which affects scalability.

[0036] In the currently proposed DMP 106, the memory pool is not fully replicated on each memory pool node 104, but instead is implemented by the DMP 106. To provide reliability, the DMP 106 may be implemented to have some duplication, i.e., each blockchain transaction data item is replicated on more than one, but not all, memory pool nodes 104. As an example, the DMP may be implemented to specify a minimum number of two replicas. This is because, assuming complete independence between the nodes, the probability that two nodes will simultaneously fail at any given time is

[0037]

number

[0038] FIG. 2 illustrates, in diagrammatic form, an exemplary blockchain network 200 including a validator node 208 (e.g., a node such as one of the nodes 102 shown in connection with FIG. 1) and a memory pool node 204 according to an embodiment. In various embodiments, a particular blockchain transaction (T i ) 202 is processed by one or more validator nodes 208 and stored in one or more memory pool nodes 204. i Store 202. Blockchain transaction T i 202 may include blockchain transactions as described above. However, storing transaction information is only one embodiment of the DHT protocol described in this disclosure. The protocol described in this disclosure can be used for consistent and secure storage and retrieval of any data suitable for storage in a DMP.

[0039] The validator node 208 receives the incoming T i Various criteria for the approval of validator nodes 202 may be applied, such as the computational parallelism and / or T provided by the computational resources running validator nodes 208. iDepending on the ordering requirements of 202, new blockchain transactions may be buffered before a complete batch of any size is scheduled for approval. Additionally, validator node 208 may be responsible for approving the format of blockchain transactions or other requests directed to memory pool node 204. In yet other embodiments, validator node 208 may be responsible for approving the format of blockchain transactions or other requests directed to memory pool node 204. i 202 determines whether it has been approved by one or more other computer systems (e.g., whether it has been approved based at least in part on a blockchain protocol).

[0040] The memory pool node 204 provides a decentralized storage service that enables various operations, such as a lookup operation, where the operation "lookup(k)" returns data associated with key "k." Furthermore, the memory pool node 204 implements a peer-to-peer system according to the DHT protocol to implement the DMP 106. The DMP 106 provides a common identifier space (e.g., a key space or the set of all possible results of a hash function) for both the memory pool node 204 and the keys, where each key k is stored in the memory pool node 204 and the identifiers closest to k are determined according to a distance function. As described in more detail below, keys are not stored in the shared space using a deterministic function (e.g., a hash function). In various embodiments, this may prevent or reduce the effectiveness of a malicious node performing a brute force attack generating an output that results in a malicious key being between two keys.

[0041] In some embodiments, to find a particular memory pool node associated with k, the memory pool node 204 forwards the search request to other peers whose identifiers are close to k according to a distance function. Additionally, the memory pool node 204 may maintain links to a subset of other memory pool nodes 204. As described in more detail below with respect to Figure 6, the search request is forwarded by the memory pool node 204 until a memory pool node associated with k is found or until no nodes with identifiers closer to the requested key are found according to the routing protocols presented in this disclosure.

[0042] In a DMP 106, keys are distributed across a potentially large number of memory pool nodes 104. In various embodiments, each memory pool node 204 contains information that can identify a subset of the other memory pool nodes 204 (e.g., network addresses, key information, physical locations, etc.), so that searches can be deterministically routed to the memory pool node 204 responsible for the requested key. This limited view of the membership of a DMP 106 may provide greater scalability to the system.

[0043] The DMP 106 is implemented using the DHT protocol described in this disclosure, which in various embodiments provides two operations: 1) a store operation and 2) a lookup operation. i Given an identifier id(T i ) is the id i =H(T i ), where H represents a hash function. In various embodiments, an identifier (id i ) is used as a key in the DMP 106. Additionally, as noted above, a specific address may be used so that a blockchain transaction can be received from multiple validator nodes 208. Each validator node 208 then receives the blockchain transaction T i may be independently verified.

[0044] As shown in Figure 2, each validator node 208 maintains a local database 214. In the embodiment shown in Figure 2, entries in the local database 214 include an identifier id for the blockchain transaction. i And, T i The validator nodes 208 may use the information to quickly respond to validation or search queries. In some embodiments, multiple validator nodes 208 may use the information to validate T. i Then, multiple validator nodes 208 independently verify T i Based at least in part on the results of verifying i ,id i ) request or reject (id i ) request to the DMP 106. In these embodiments, the store message is i ID i and the rejection message is stored in the memory pool node 204 associated with id i Furthermore, the memory pool node 204 has N / 2+1 memory (T i ,id i ) request is received, and only then i where N is the number of validator nodes 208.

[0045] In yet another embodiment, no rejection message is used and the memory pool node 204 stores the first memory (T i ,id i Upon receiving N / 2 stored messages, the memory pool node 204 starts a timer for receiving more than N / 2 stored messages. In such an embodiment, if enough stored messages are not received beyond the timeout, the blockchain transaction is discarded. Additionally, each memory pool node 204 starts a timer for receiving more than N / 2 stored messages. iThe memory pool node 204 may maintain a number of memorized messages received for a given blockchain transaction greater than N / 2+1. These mechanisms may be used to maintain quorum requirements and / or ensure that a quorum is reached. In some embodiments, the memory pool node 204 maintains a database 210 or other data structure used to store the number of confirmations received from validator nodes 208 for a given blockchain transaction.

[0046] In various implementations of the DHT protocol described in this disclosure, a confirmed blockchain transaction T i Search for id i id is sent to at least one memory pool node 204. i The particular memory pool node responsible for storing the id i In this implementation, a message containing data related to T is sent to the query node. i If M memory pool nodes are required to store id for the stored blockchain transactions to be considered consistent, i At least M / 2+1 messages containing data related to T are received by the query node. Furthermore, the query node determines T according to information stored in the local database 214 of the validator node 208. i To determine the validity of , N / 2+1 random validator nodes 208 may be queried.

[0047] As described in more detail below with respect to FIG. 3, the key-value pairs of the DMP 106 may be stored in a table 210 maintained by the memory pool node 204. The table 210 may include information related to the DHT protocol, such as the separate functions described above. While the validator node 208 and the memory pool node 204 are shown as separate entities in FIG. 2, in various embodiments, one or more of the memory pool node 204 and / or the validator node 208 may be implemented by the same entity, such as a computer system. For example, as described above with respect to FIG. 1, a merchant node may implement multiple components of the blockchain protocol. In yet other embodiments, the DMP 206 is implemented without a validator node 208. In one example of such an embodiment, the T i 202 is stored directly by the memory pool node 204 without performing any validation action. In another example, the memory pool node 204 itself stores T i An authorization action may be performed before processing 202.

[0048] 3 illustrates in diagram form an exemplary embodiment 300 of an update to routing information for a set of memory pool nodes in a DMP network. The exemplary embodiment 300 illustrated in FIG. 3 includes an update to routing information for a new memory pool node S x 304 and the existing memory pool node S y 308 and other existing memory pool nodes S z As mentioned above, the DHT protocol relies on a network of individual trust relationships between memory pool nodes. x ) may be generated based at least in part on a collection of both routing information and application-level information. In various embodiments, no central authority is involved in releasing or storing trust certificates. In such embodiments, each memory pool node maintains a record of peers trusted with respect to the memory pool node. In various other embodiments, memory pool node S x304, for example, does not become a new memory pool node during the update procedure.

[0049] Given the number n of memory pool nodes in a network (e.g., DMP 106), the number r of routing table records per memory pool node is given by:

[0050]

number

[0051] As noted above, the DHT protocol defines two functions and / or operations: an update operation and a get operation. In various embodiments, the update operation is used to build a routing table and insert a key at each memory pool node. As described in more detail below with respect to FIG. 4, the get operation calls a particular node (e.g., S ) to find a target key-value pair (e.g., a record in the DHT) represented by key k. x ) used by

[0052] In various embodiments, a particular memory pool node (e.g., S x ) is identified by a public key. For example, memory pool node S x The identification information of 304 is the public key P x and S x 304 current IP address addr x These are represented by Sign x (P x ,addr x ) are securely linked using the following records defined by x () is S x 304. The node identity may then be stored in the DMP using the signed record. In some embodiments, the message is sent to peer S y 308, the memory pool node S x304 is the identifier P y Then, the memory pool node S x 304 is S y 308 public key P y Any records returned in response to a query using y ,addr y )) signature verification. Memory pool node S x Once the 304 verifies the information, S x 304 S message y Addr 308 y In such an embodiment, when a memory pool node changes location or receives a new network address, a new record is created and stored in the DMP.

[0053] A DHT protocol may be considered robust against Sybil attacks if the above get operation is likely to return the correct value (compared to other protocols) despite malicious activity on both the update and get operations. In various embodiments, the DHT protocol has the following properties to reduce the effectiveness of Sybil or other attacks: The routing table information is minimized to reduce space complexity to avoid problems such as overload created by a large number of fake nodes. New nodes generate their own routing information by collecting information from peers, thereby reducing the impact of malicious nodes that repeatedly send false information. The key space is not deterministic to avoid clustering attacks.

[0054] Data routing within the DMP can be represented by an undirected graph. In some embodiments, given the number g of malicious edges and the number n of memory pool nodes, the property g << n (g is much smaller than n) guarantees the operation network of the DMP106. An attacker may create any number of malicious nodes, but it can be difficult for a malicious node to create an edge (e.g., a network connection or relationship) with a memory pool node. For example, a random walk starting from a memory pool node is likely to end at another memory pool node rather than a malicious node. However, since the starting memory pool node may not be able to determine which reply messages originated from malicious nodes, assumptions about the authenticity of messages may not be necessary. These properties are described in Haifeng Yu et al. SybilLimit: A Near-Optimal Social Network Defense Against Sybil Attacks, IEEE / ACM Transactions on Networking, vol. 18, no. 3 (2010) and F. R. K. Chung Spectral Graph Theory Conference Board of the Mathematical Sciences, no. 92 (1994), and are hereby incorporated by reference in their entirety as if each citation were individually and specifically set forth herein and fully described in this disclosure.

[0055] As shown in FIG. 3, S x 304 may generate routing information by executing a random walk 332. In an embodiment, the routing table of S x 304 is generated by starting r independent random walks of length w within the DMP. r independent random walks of length w may be generated, and the information retrieved from the random walks is stored in the table Tab_RND(S x )316. Using these random walks, Sx 304 may collect one or more random key-value records from the receiving memory pool node of each random walk. This information is then stored in a table Tab_DIST(S x , i) 312, where i represents the routing iteration.

[0056] As explained in more detail below, this routing information is used during lookup operations such as get. x Tab_CLOSE(S of local table 304 x ,i) If the 314 table does not contain the key, the search message is x 304 routing table (e.g., Tab_DIST(S x ,i)312) to r nodes. Depending on the value of r, one or more memory pool nodes may store the queried key-value record locally (e.g., in the Tab_CLOSE table of a particular node). Furthermore, the protocol n , r d or r c may be defined, and r n Tab_RND(S x )316 is the number of elements in r d Tab_DIST(S x ,i)312 is the number of elements, and r c Tab_CLOSE(S x , i) 314. In various embodiments, the value r n , r d or r c may be the same as r.

[0057] In various embodiments, routing information is generated only by performing a plurality of random walks. Further, due to different numbers of edges between different memory pool nodes, the random walk distribution may be balanced. Thus, if each physical memory pool node replicates itself according to a plurality of edges, the total number of keys stored in the system is mK, where m is the number of fair edges and K is the number of keys stored per memory pool node, and the number of independent random walks is determined to be of size O(√mK).

[0058] In some embodiments, a global circular lexicographical ordering for keys is used. For example, given any indices a < i < b, the key k<* i is located in a portion of the space between two nodes x a and x b . As described above, to prevent malicious nodes from brute-forcing a desired output and inserting an incorrect key between two fair keys, keys are not stored in the shared key space using a deterministic function (e.g., a hash function).

[0059] As shown in FIG. 3, the node S x 304 generates a long-distance routing table Tab_DIST(S x ,i)312 that includes r pointers to other memory pool nodes having identification information uniformly distributed over the key space. In such an embodiment, the pointers are stored by starting r random walks and collecting random identification information from the ending memory pool nodes. The short-distance routing table Tab_CLOSE(S x ,i)314 includes r key-value records. These keys are the closest ones following the identification information of S x in lexicographical order.

[0060] According to this routing model, each node uses a random walk to select a random key, thereby providing a uniform distribution of pointers over the key space. Furthermore, clustering attacks can be prevented by recursively extending this routing model. In various embodiments, at a given iteration i, each memory pool node searches the previous (i-1)th long distance table 336 (e.g., Tab_DIST(S x ,i-1)) and select a random entry from Tab_ID(S x ) 310. A degree of recursion of α may ensure that each memory pool node resides in α positions and collects short-distance tables for α different identities in the key space. Thus, the degree of recursion is O(log mK ) and the size can be determined according to

[0061] As shown in Figure 3, the update operation consists of two phases. During the first phase, node S x 304 is Tab_RND(S x ) 316. During the second phase, for iteration i<α of the update operation, the random walk for the collection of key-value records to be stored in the other routing tables Tab_ID(S x )310, Tab_DIST(S x ,i)312 and Tab_CLOSE(S x , i) 314 is generated. In various embodiments, the number of entries in each table may be limited to a particular number of total entries. Returning to Figure 3, during a routing iteration, memory pool identification information may be recursively selected based at least in part on the current routing iteration.

[0062] Additionally, as shown above, Tab_ID(S x )312 records are S x In some embodiments, the first entry may be created by selecting a random identifier from the records in the (i-1)th TAB_DIST table of 304. In some embodiments, the first entry may be created by selecting a random identifier from the records in the (i-1)th TAB_DIST table of 304. x) 316 table. x ,i) 312 records are stored in memory pool nodes 334 (e.g., node S y 308) and collects the address of the resulting memory pool node and its ith identification information from the Tab_ID table 320. Finally, Tab_CLOSE(S x ,i)314 is Tab_RND(S x ) 316, which may be generated by at least requesting records in Tab_RND 318 that are lexicographically close to at least one other key that follows the identifying information at a given iteration i.

[0063] In various embodiments, the queries required to gather routing information are independent and randomly distributed within the space of keys close to a particular identity.

[0064] 4 illustrates, in diagram form, an exemplary embodiment 400 of a get operation performed by a memory pool node of a DMP that implements a DHT. z 406 to find the target record maintained by the memory pool node S x 404 is an existing memory pool node S y 408 and memory pool node S z 406. As mentioned above, the DHT protocol relies on a network consisting of individual trust relationships (e.g., connections) between memory pool nodes. x ) may include a table (e.g., Tab_DIST412) containing a set of records indicating memory pool nodes distributed across the key space and network addresses associated with the memory pool nodes, generated as described above.

[0065] In various embodiments, the search for the target record consists of finding a routing pointer in a long-distance routing table that has the target memory pool node in its short-distance routing table 418. As described in more detail below with respect to Figure 6, this process may be iterative, such that a get operation results in the computational resource performing the get operation following multiple routing pointers to successive long-distance routing tables to the target memory pool node that has the target record in its short-distance routing table 418.

[0066] As described above, the update operation may ensure that some long-range pointers within the entire key space maintain routing information for the target record and / or target key. Furthermore, it is likely that at least some of the long-range pointers are not associated with malicious entities. As shown in Figure 4, node S x A key-value lookup procedure (e.g., a get operation) initiated from a 404 request first looks for a routing pointer. x It starts by scanning the Tab_DIST 412 table at 404. If the target record cannot be reached (e.g., if the routing pointer or other information is not contained in Tab_DIST 412), it returns to node S to repeat the procedure. y A random walk 432 to 308 may be performed. As shown in Figure 4, the random walk 432 is shown as a solid line between memory pool nodes, and other possible random walks are shown by dashed lines.

[0067] During the iteration of the get operation, node S y The Tab_DIST table 414 of 408 may be searched for the closest identifying information (shown as "id*" in FIG. 4) to the target record (e.g., key) being searched. In various embodiments, given a random iteration i, Tab_DIST(S y ,i) Node S in 416 z406. In such an embodiment, a random pointer to node S z The selected long-range pointer to 406 must be within the range given by id* and k. For example, node S z The identification information of 406 satisfies the following condition 422: id*≦node S z The identity information in 406 must satisfy the condition k≦k.

[0068] Then, the selected node (e.g., node S in the example shown in FIG. 4) z 406) is queried for records associated with key k. If there is a hit (k,i) in record 424 (e.g., the record is in node S z 406 in the i-th instance of the Tab_CLOSE table 418), node S z 406 is the memory pool node responsible for sending the query, i.e., node S in the example shown in FIG. y It may return a 408 record. y 408 is Node S x 404 to Node S y Node S based at least in part on the query sent to 408 x The record may be returned in a 404. For example, the record may be returned based on following the same path that was taken to find the record. If there is no hit for the record, the get operation may continue and the next iteration may be performed.

[0069] In various embodiments, signed messages are exchanged between peers in the DMP (e.g., memory nodes connected by a single hop in the network) to discover trusted connections between memory pool nodes of other nodes. For example, node S y 408 and Node S x 404 are peers (e.g., connected by a trusted connection), and nodes x1, x2, and x3 are nodes S x If it is a peer of 404, node S y408 requests direct connections to nodes x1, x2, and x3. Additionally, for an added level of security, nodes x1, x2, and x3 may be directly queried to verify their current connections. If connections are confirmed, node S y 408 is Node S x It may decide to create a new connection to one of the peers at 404, for example, node x2. In such an embodiment, the new connection is only allowed if node x2 responds affirmatively to the connection request.

[0070] In yet another embodiment, memory pool nodes may assign different weights β to trusted connections between particular memory pool nodes. x,i For example, node S x 404 may assign weights to peer node x1, node x2, and node x3 based at least in part on the following constraints:

[0071]

number

[0072] In such an embodiment, each memory pool node is responsible for maintaining weight information relative to other memory pool nodes. x For 404, Node S x 404 includes at least a weight, e.g., a weight β x,y Decrease by a value ε and reduce at least one of the other weights to ε / (m x For example, node S may update the weight value of a peer by increasing it by −1. y 408, key is node S y If you do not provide a valid key-value record, you will get a 408 Tab_CLOSE. x 404 may decide to reduce the weight associated with the peer.

[0073] 5 illustrates, in flowchart form, an exemplary process 500 for performing update operations to generate routing information for memory pool nodes of a DMP according to an embodiment. Part or all of process 500 may be performed under the control of one or more computer systems configured with executable instructions and / or other data and may be implemented as executable instructions executing together on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on a magnetic, optical, or flash medium). The exemplary process 500 may be performed by a memory pool node, such as one of the memory pool nodes 204 described in connection with FIG. 2, of the DMP 206 described in connection with FIG. 2.

[0074] That is, a memory pool node, such as one of the memory pool nodes 204 described with respect to Figure 2, may execute the exemplary process 500 for performing the update operation described with respect to Figure 5. Such a memory pool node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device). Furthermore, process 500 may be executed periodically or aperiodically in response to a triggering event (e.g., in response to a new memory pool node joining the DMP or the failure of an existing memory pool node) or for other suitable reasons to update routing information.

[0075] Exemplary process 500 includes a series of actions by which a system executing exemplary process 500 performs an update operation of the DHT protocol, as described above. In step 502 of exemplary process 500, the system receives a set of trusted connections and a set of key-value records. The set of trusted connections and the set of key-value records may be received as input to the update operation. In various embodiments, this information may be omitted or may otherwise be null (e.g., there may be no trusted connections and / or key-value records stored by the memory pool node).

[0076] In step 504, the system initializes a random walk for the set of key-value records. As described above, a set of random walks may be initialized, which is used to generate a set of distances distributed within the key space. The generation of the random walk may be part of the initial stage of the update operation, as described above. Furthermore, the random walk may be generated randomly or pseudo-randomly. In step 506, the system then selects the first / next routing iteration i. As described above, the update operation may recursively generate routing information across multiple routing iterations from 1 to α.

[0077] In step 508, the system calculates Tab_DIST(S x , i-1) based at least in part on the identification information obtained from Tab_ID(S x ,i) to generate the i-th record. x , i-1) does not exist (e.g., when there is only one table in Tab_DIST, such as a new memory pool node), a random key is selected from the location of the Tab_RND table into the system (e.g., memory pool node).

[0078] In step 510, the system y ) table containing the node address and identification information. x ,i) records are generated. As described above with respect to Figure 3, a random walk is performed and address information is obtained from the memory pool nodes that are contacted as a result of performing the random walk. This identification and address information of the memory pool nodes is then used to generate a Tab-DIST(S x ,i) Stored as records in a table.

[0079] In step 512, the system executes a Tab_CLOSE(S x ,i) Generate Records.,As described above with respect to Figure 3, the memory pool node ,sends the local record (to the memory pool node) of the Tab_RND ,that is lexicographically closest to the identity during a particular iteration of the ,update operation.

[0080] In step 514, the system determines whether more iterations remain. For example, process 500 may have a set number of iterations. In another example, the system executing process 500 determines the number of iterations in step 504 during initialization of the update operation. In yet another example, the system may continue to iterate process 500 until a certain amount of routing information is obtained. If the number of iterations has not been reached, the system returns to step 506. If the number of iterations has been reached, the system proceeds to step 516 and completes the update operation.

[0081] It should be noted that one or more of the operations performed in the example process 500 shown in Figure 5 may be performed in various orders and combinations, including in parallel. Additionally, one or more of the operations performed in the example process 500 shown in Figure 5 may be omitted.

[0082] 6 illustrates, in flowchart form, an exemplary process 600 for performing a get operation to obtain data associated with a key for a memory pool node of a DMP network according to an embodiment. Part or all of process 600 may be performed under the control of one or more computer systems configured with executable instructions and / or other data and may be implemented as executable instructions executing together on one or more processors. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on a magnetic, optical, or flash medium). The exemplary process 600 may be performed by a memory pool node, such as one of the memory pool nodes 204 described in connection with FIG. 2, of a DMP, such as DMP 206 described in connection with FIG. 2.

[0083] That is, a memory pool node, such as one of the memory pool nodes 204 described with respect to Figure 2, may execute the example process 600 for performing a get operation described with respect to Figure 6. Such a memory pool node may comprise any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device).

[0084] Exemplary process 600 includes a series of acts in which a system executing exemplary process 600 performs a get operation of the DHT protocol, as described above. In step 602 of exemplary process 600, the system receives a request for a value associated with key k. The request may be received from a system external to the DMP network or from a memory pool node that is a member of the DMP network.

[0085] In step 604, the system performs a lookup operation in table Tab_CLOSE to determine whether a value associated with key k exists within a record in the table. In step 606, if the record exists in the table, the system returns the value associated with the key. However, if the record does not exist in table Tab_CLOSE, the system may proceed to step 608.

[0086] In step 608, the system determines the closest identification (id*) to key k contained in the Tab_DIST table. As noted above, the distance may be determined based at least in part on the update operation described above with respect to FIG.

[0087] In step 610, the system may select an iteration i. The iteration may be selected randomly or pseudo-randomly. Furthermore, the iteration may represent a particular table generated during an iteration of the update operation, as described above.

[0088] In step 612, the system calculates the distance between the table Tab_DIST(S x ,i) select a random pointer z from the list. As mentioned above, the pointer may be an address to another memory pool node in the DMP network that implements the DHT. In this way, the system may move in the key space during successive iterations of the get operation towards a particular memory pool node associated with a key containing a value in the particular memory pool's table Tab_CLOSE.

[0089] In step 614, the system queries the memory pool node at pointer z. In various embodiments, the query includes key k. Additionally, the query may include additional information, such as an address associated with the requestor. In various embodiments, the additional information allows the memory pool node associated with key k and containing the value to send the value directly to the address associated with the requestor. This is in contrast to sending a response to the memory pool node that is responsible for sending the query and potentially avoiding additional network traffic, as the information is returned along the same network path through the DMP network.

[0090] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, but it will be apparent that various modifications and changes may be made therein without departing from the broader spirit and scope of the invention as set forth in the appended claims.

[0091] It should be noted that one or more of the operations performed in the example process 600 shown in Figure 6 may be performed in various orders and combinations, including in parallel. Additionally, one or more of the operations performed in the example process 600 shown in Figure 6 may be omitted. In various embodiments, there is a maximum number of iterations that the process 600 will perform, and if no value is returned, the process 600 terminates.

[0092] FIG. 7 illustrates, in diagrammatic form, an exemplary computing device 700 on which various embodiments of the present invention may be implemented. FIG. 7 illustrates a simplified diagram of an exemplary computing device 700 that may be used to practice at least one embodiment of the present disclosure. In various embodiments, the exemplary computing device 700 may be used to implement any of the systems or methods illustrated and described herein. For example, the exemplary computing device 700 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 7 , the exemplary computing device 700 may include one or more processors 702 configured to communicate with and operably coupled to multiple peripheral subsystems via a bus subsystem 704. The processors 702 may be utilized to implement methods described herein. These peripheral subsystems may include a storage subsystem 706, including a memory subsystem 708 and a file storage subsystem 710, one or more user interface input devices 712, one or more user interface output devices 714, and a network interface subsystem 716. Such a storage subsystem 706 may be used for temporary or long-term storage of information related to blockchain transactions or operations described herein.

[0093] The bus subsystem 704 may provide a mechanism for allowing the various components and subsystems of the exemplary computing device 700 to communicate with each other as intended. While the bus subsystem 704 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 716 may provide an interface to other computing devices and networks. The network interface subsystem 716 may serve as an interface for receiving data from other systems and transmitting data from the exemplary computing device 700 to other systems. For example, the network interface subsystem 716 may allow a user to connect the device to a wireless network or other network, such as those described herein. The bus subsystem 704 may be utilized to communicate data related to blockchain transactions or operations described in this disclosure to one or more processors 702 and / or other entities external to the system via the network interface subsystem 716.

[0094] The user interface input devices 712 may include one or more user input devices, such as a keyboard; a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touchscreen integrated into a display; an audio input device, such as a voice recognition system; a microphone; and other types of input devices. In general, the use of the term "input device" is intended to encompass all possible types of devices and mechanisms for inputting information into the computing device 700. The one or more user interface output devices 714 may include a display subsystem, a printer, or a non-visual display, such as an audio output device. The display subsystem may be a cathode ray tube (CRT), a flat panel device, such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, the use of the term "output device" is intended to encompass all possible types of devices and mechanisms for outputting information from the computing device 700. One or more output devices 714 may be used to present a user interface, for example, to facilitate user interaction with applications that perform the processes described herein and variations thereof, where user interaction may be appropriate.

[0095] The storage subsystem 706 may provide a computer-readable storage medium for storing basic programming and data structures that may provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) that, when executed by one or more processors, may provide the functionality of one or more embodiments of the present disclosure may be stored in the storage subsystem 706. These application modules or instructions may be executed by one or more processors 702. The storage subsystem 706 may also provide a repository for storing data used in accordance with the present disclosure. The storage subsystem 706 may include a memory subsystem 708 and a file / disk storage subsystem 710.

[0096] The memory subsystem 708 may include multiple memories, including a main random access memory (RAM) 718 for storing instructions and data during program execution, and a read-only memory (ROM) 720 in which fixed instructions may be stored. The file storage subsystem 710 may provide non-transient, persistent (non-volatile) storage for program files and data files, and may include hard disk drives, floppy disk drives with associated removable media, compact disk read-only memory (CD-ROM) drives, optical drives, removable media cartridges, and other similar storage media.

[0097] The exemplary computing device 700 may include at least one local clock 724. The local clock 724 may be a counter representing the number of ticks that have occurred since a particular start date and may be integrally located within the exemplary computing device 700. The local clock 724 may be used to synchronize data transfers among the processors and all of the included subsystems for the exemplary computing device 700 at a particular clock pulse, and may also be used to coordinate synchronous operations between the exemplary computing device 700 and other systems within a data center. In one embodiment, the local clock 724 is an atomic clock. In another embodiment, the local clock is a timer with a programmable interval.

[0098] The exemplary computing device 700 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described herein. Additionally, the exemplary computing device 700 may include other devices that may be connected to the exemplary computing device 700 through one or more ports 726 (e.g., USB, headphone jack, Lightning connector, etc.). Devices that may be connected to the exemplary computing device 700 may include multiple ports configured to accept fiber optic connectors. Accordingly, devices that may be connected to the exemplary computing device 700 may be configured to convert optical signals into electrical signals, which may be transmitted through ports connecting the devices to the exemplary computing device 700 for processing. Due to the ever-changing nature of computers and networks, the description of the exemplary computing device 700 shown in FIG. 7 is intended only as a specific example for purposes of describing device embodiments. Many other configurations are possible, having more or fewer components than the system shown in FIG. 7 .

[0099] One or more embodiments of the present invention may be described as providing improved blockchain implementation methods and systems. They may provide improved operational speeds by enabling faster read and write operations over a blockchain network. They may also provide improved security for blockchain-implemented systems in terms of preventing attacks or malicious activity, such as routing and storage attacks, within the distributed memory pool. Thus, the present invention may provide a more secure blockchain solution. They may also provide a mechanism for ensuring network-wide consensus on the validity of blockchain transactions stored in the distributed memory pool, thus improving the overall performance, reliability, and security of the network. They may also provide an improved architecture, providing improved storage resources and capabilities for blockchain systems. Other advantages of the present invention may also be provided.

[0100] It should be noted that in the context of describing embodiments of the disclosure, unless otherwise specified, the use of the phrase "instructions" in reference to executable instructions (also called code, applications, agents, etc.) that perform actions that they would not normally perform unassisted (e.g., transmitting data, performing calculations, etc.) means that the instructions are executed by a machine, thereby causing the machine to perform the specified actions.

[0101] It should be noted that the above-described embodiments are illustrative rather than limiting of the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the scope of the claim. The use of terms such as "comprising" and "comprises" does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes or consists of," and "comprising" means "comprising or consisting of." A reference to a singular element does not exclude a reference to a plural of such elements, and vice versa. The present 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 measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0102] With respect to the above embodiment, the following items are disclosed.

[0103] (1) receiving, at a memory pool node of a distributed memory pool network (DMP) implementing a distributed hash table (DHT), a request to update routing information of the memory pool node; initializing a set of random walks within the key space of the DHT, the set of random walks being used to generate a set of key-value records to be stored by the memory pool nodes; generating a first record in the first table based at least in part on first identification information stored in a second table of a long distance table type; generating a second record in a third table of the long distance table type by performing at least a first random walk of the set of random walks, the second record including second identification information and an address associated with the second identification information; generating a third record in a fourth table of a short distance table type by at least retrieving a record from a table maintained by a second memory pool node of the DMP network; 20. A computer-implemented method comprising:

[0104] (2) receiving, at the memory pool node, a request for a value associated with a key; selecting, from a fifth table of the long distance table type, a third identification relative to at least some other identifications contained in said fifth table; selecting a particular iteration of a long distance table from a set of long distance tables of which the third table is a member; selecting a pointer from the particular iteration of the long distance table within the range between the third identification and the key; sending a query to a third memory pool node associated with said pointer; 2. The computer-implemented method of claim 1, further comprising:

[0105] (3) The computer-implemented method of (2), wherein the request to update routing information is part of an update operation that is performed in multiple iterations.

[0106] (4) The computer-implemented method of (2) or (3), wherein the update operation terminates after a number of iterations is completed, the number of iterations being defined by the DHT protocol.

[0107] (5) The computer-implemented method of any one of (1) to (4), further comprising the step of creating, at the memory pool node, a set of trusted connections with a set of other memory pool nodes.

[0108] (6) The computer-implemented method of any one of (2) to (5), wherein the second record in the second table is selected pseudo-randomly.

[0109] (7) The computer-implemented method of any one of (2) to (6), wherein the first record in the ID table is selected from information generated during initialization of the set of random walks.

[0110] (8) The computer-implemented method of any one of (2) to (7), wherein the step of selecting the pointer from the particular iteration of the long-distance table within the range between the third identification information and the key is performed randomly.

[0111] (9) The computer-implemented method of any one of (2) to (8), wherein the request to update the routing information of the memory pool node is the result of instantiating a new memory pool node.

[0112] (10) The computer-implemented method of any one of (2) to (9), wherein the set of trusted connections is modified.

[0113] (11) The computer-implemented method of any one of (2) to (10), wherein the request to update the routing information of the memory pool node is the result of at least one memory pool node failing.

[0114] (12) A computer-implemented method according to any one of (2) to (11), wherein the request to update the routing information of the memory pool node is the result of changing a set of keys associated with the DMP.

[0115] (13) The computer-implemented method of any one of (2) to (12), wherein the request to update routing information of the memory pool node is the result of a change to the set of trusted connections.

[0116] (14) The computer-implemented method of any one of (2) to (13), wherein the DMP receives multiple storage requests from a set of validator nodes.

[0117] (15) The computer-implemented method of any one of (2) to (14), wherein the memory pool node maintains a set of weights associated with a set of connections to a set of other memory pool nodes.

[0118] (16) The computer-implemented method of any one of (2) to (15), wherein the memory pool node updates a weight in the set of weights as a result of at least one memory pool node failing to provide a valid key-value record.

[0119] (17) The computer-implemented method of any one of (2) to (16), wherein the memory pool node of the DMP implements a consensus protocol to provide consensus among multiple memory pool nodes of the DMP on a set of values ​​included in the fourth table.

[0120] (18) The computer-implemented method of any one of (2) to (17), wherein the memory pool node stores a second value that is also stored in at least one other memory pool node of the DMP.

[0121] (19) A system including a processor and a memory, The memory includes executable instructions that, when executed by the processor, cause the system to perform the computer-implemented method of any one of (1) to (18).

[0122] (20) A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processor, cause a computer system to perform at least one of the computer-implemented methods described in any one of (1) to (18).

Claims

1. A method of obtaining data associated with a key for a memory pool node of a distributed memory pool network, the method being performed by another memory pool node of the distributed memory pool network, comprising: receiving a request for a value associated with a key, wherein a global circular lexicographical order is used for the keys; performing a lookup operation in a short distance table to determine whether the value associated with the key is in a record in the short distance table; If the record is in the short distance table, returning the value associated with the key; if the record is not in the short-distance table, returning the identity closest to the key contained in a long-distance routing table, the closeness of the identity to the key being determined by distance; selecting an iteration, the iteration representing a particular table generated during an iteration of the update operation; selecting a random pointer from the long distance routing table based on a position between the key and an identification closest to the key; querying the memory pool node at the random pointer; A method comprising:

2. The method of claim 1 , wherein the request is received from a system external to the distributed memory pool network or a memory pool node that is a member of the distributed memory pool network.

3. The method of claim 1 , wherein the distance is based on an update operation.

4. The method of claim 1 , wherein the iterations are selected randomly or pseudo-randomly.

5. The method of claim 1 , wherein the random pointer is an address to another memory pool node in the distributed memory pool network.

6. 2. The method of claim 1, wherein the query includes further information including at least one of an address associated with a requestor, and information that enables a memory pool node associated with the key and containing the value to send the value directly to the address associated with the requestor.

7. A system including a processor and a memory, The memory includes executable instructions that, upon execution by the processor, cause the system to perform the method of claim 1.

8. A non-transitory computer-readable storage medium having stored thereon executable instructions that, upon execution by a processor of a computer system, cause the computer system to perform at least the method of claim 1.

Images