Method and special network node for fast propagation in a blockchain network

Abstract

To provide a method and a special network node for high-speed transmission in a blockchain network.SOLUTION: In a blockchain network 100, a merchant node 104 includes a memory for storing a specified portion of a distributed mempool structured as a distributed hash table, the distributed mempool including pending transactions awaiting approval. A processor is configured to: receive a transaction including a transaction identifier; hashing a new transaction identifier for obtaining a key; confirming whether or not the transaction is stored in the distributed mempool by using the key; storing the transaction to the distributed memory pool as a pending transaction in the case where it is not stored; and transmitting the transaction by using a peer-to-peer connection to a node group other than the merchant node.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to distributed ledger (blockchain) networks. In particular, the present invention may relate to cryptographically enforced methods and systems that improve the performance of a blockchain network and / or increase the speed at which transfers can be performed on the network. [Background technology]

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

[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system composed of blocks that are made up of transactions. Each transaction (Tx) encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, so that blocks are chained together to create a permanent, immutable record of all transactions that have been written to the blockchain since inception. Transactions contain small programs, known as scripts, that are embedded in the transaction's inputs and outputs, and the scripts specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

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

[0005] For a transaction to be written to the blockchain, it is incorporated into a block by a node (a "miner"), which is designed to collect transactions and form them into a block. The miner then attempts to complete a "proof of work" on the node. Miners in the blockchain network compete to be the first to assemble a block of transactions and complete the associated proof of work on the block. Successful miners add a verified block to the blockchain, which is propagated to the network so that other nodes that hold a copy of the blockchain can update their records. These nodes that receive the block also "verify" the block and all transactions within it to ensure that it follows the formal requirements of the protocol.

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

[0007] It would be beneficial to use a blockchain-based network such as Bitcoin to enable or facilitate the use of widespread cryptographically secured exchanges. Such exchanges may involve payment processing, for example, for credit card transactions. However, a transaction throughput of about 3 transactions per second is insufficient to handle such electronic payments, which currently operate at a transaction volume of about 50,000 transactions per second. It is therefore 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

[0008] Now such a solution has been invented.

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

[0010] This application describes and discloses a method and device that allows high speed propagation of blockchain transactions (TXs) by a network of dedicated merchant nodes designed to implement blockchain for faster / improved transaction processing. The term "transaction" may be interpreted to mean a "blockchain transaction" other than a trade in the financial sense (i.e., Tx). To minimize network traffic and mitigate storage limitations, a memory pool of pending transactions waiting to be incorporated into a block ("member pool") may be stored in the specialised (merchant) nodes as a distributed memory pool realised by a distributed hash table (DHT). A new transaction received by a merchant node may have its identifier hashed and the merchant node may evaluate whether it is already stored in the distributed member pool. If not, it may be stored in the distributed member pool at one or more appropriate merchant nodes using the applicable DHT protocol. The merchant node may then send the transaction Tx to normal non-merchant nodes using normal peer-to-peer connections; however, it is not required to send the transaction to every other merchant node.

[0011] In additional or alternative aspects, the present application describes specialized network nodes that facilitate (fast) distribution of blockchain transactions over a network of interconnected nodes used to implement the blockchain, a subset of the interconnected nodes being specialized network nodes interconnected in an overlay network. Hereinafter, the term "specialized network" may be used interchangeably with the term "SN" or "merchant node" for convenience purposes only.

[0012] In some implementations, using an overlay network of specialized network nodes to implement and manage the member pool in the form of a DHT can provide computational and propagation speed benefits over implementing the member pool at every network node. Furthermore, using specialized network nodes in an overlay network over a regular network of blockchain nodes avoids the expected speed and reliability complications of implementing a DHT member pool across the entire network of blockchain nodes, with each node storing and maintaining a very small portion of the DHT. This structure can allow non-specialized nodes to quickly query the member pool through one of the specialized nodes. It would be further beneficial for the specialized network nodes to initiate propagation to non-specialized networks outside the overlay network using peer-to-peer communication after updating the DHT to ensure that nodes outside the overlay network, such as mining nodes, can maintain partial or complete member pools as needed. Other speed and storage benefits can be realized by various aspects of the present application, as will become apparent from the description of exemplary implementations.

[0013] An SN node may include a processor; memory storing a designated portion of a distributed member pool structured as a distributed hash table, the distributed member pool including pending transactions awaiting confirmation; a network interface; and a blockchain SN node application including processor-executable instructions that, when executed, may cause the processor to: receive a transaction including a transaction identifier; hash the transaction identifier to obtain a (cryptographic) key; use the key to check whether the transaction is stored in the distributed member pool and, if not, store the transaction in the distributed member pool as a pending transaction; and transmit the transaction to nodes other than the SN node using a peer-to-peer connection.

[0014] In some implementations, the memory may further store data regarding a number of confirmations of a block that includes the transaction and is included in the blockchain, and the instructions cause the processor to remove the transaction from the distributed member pool if the number of confirmations reaches a minimum number. In some examples, the data regarding the number of confirmations may be either a count of the number of confirmations that is updated for each new block that is added to the blockchain, or the block number of the block in which the transaction is included.

[0015] In some implementations, the memory may further store an SN node reputation table, the SN node reputation table including an identifier for any detected new neighboring SN nodes and an associated score for the new neighboring merchant node based on the detected activity of the new neighboring merchant node. In some examples, the instructions cause the processor to update the score of the new neighboring SN node, determine that the score of the new neighboring SN node has fallen below a threshold, thereby designating the new neighboring SN node as a malicious node, and isolating the new neighboring SN node.

[0016] In some implementations, the designated portion of the distributed member pool partially overlaps with a second portion of the distributed member pool stored on another SN node.

[0017] In some implementations, each SN node stores its own designated portion of the distributed member pool, and the designated portions may partially overlap such that each pending transaction is stored in at least two SN nodes, but not all SN nodes. Alternatively, each pending transaction is included in no more than two designated portions of the distributed member pool.

[0018] Additionally or alternatively, the present application may provide a computer-implemented method for facilitating blockchain transfers (e.g., transactions) involving a plurality of nodes coupled to a network used to implement the blockchain, a subset of the plurality of nodes being SN nodes, the SN nodes storing a distributed member pool including pending transactions awaiting confirmation, the distributed member pool being implemented as a hash table distributed among the SN nodes. The method, which may be implemented in one of the SN nodes, may include receiving a transaction including a transaction identifier; hashing the transaction identifier to obtain a key; checking using the key whether the transaction is stored in the distributed member pool, and if not, storing the transaction in the distributed member pool as a pending transaction; and transmitting the transaction to nodes other than the SN nodes using a peer-to-peer connection.

[0019] Additionally or alternatively, the present application may provide a non-transitory processor-readable medium storing processor-executable instructions for participating in blockchain transactions among a plurality of participating nodes, the processor-executable instructions, when executed by a processor at one of the participating nodes, causing the processor to perform one or more methods described herein. [Brief description of the drawings]

[0020] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter, which are illustrated, by way of example only, in connection with the accompanying drawings, in which:

[0021] [Figure 1] Figure 1 shows an example network of nodes along with an overlay network of merchant (SN) nodes.

[0022] [Diagram 2] Figure 2 shows a sequence diagram illustrating the process of storing a new transaction in a distributed member pool.

[0023] [Diagram 3] Figure 3 shows in flowchart form one example of how a transaction may be propagated in a blockchain network.

[0024] [Figure 4] FIG. 4 illustrates in block diagram form a simplified exemplary M node.

[0025] [Diagram 5] FIG. 5 shows a sequence diagram illustrating an example of a new node joining M-Net.

[0026] [Figure 6] FIG. 6 illustrates an example of an M node registration table.

[0027] [Figure 7] Figure 7 shows an example member data entry. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0028] As used herein, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, without necessarily excluding additional elements.

[0029] As used herein, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, and does not necessarily require the exclusion of any additional elements, and does not necessarily require all elements.

[0030] Referring first to FIG. 1, FIG. 1 illustrates in block diagram form an example network related to blockchain, which may be referred to herein as blockchain network 100. Blockchain network 100 is a peer-to-peer open membership network that anyone may join without an invitation or consent from other members. Blockchain network 100 operates under a blockchain protocol, and distributed electronic devices running instances of the blockchain protocol 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.

[0031] The electronic devices that run the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including 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.

[0032] The nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies, which may include wired and wireless communication technologies. In many cases, the blockchain network 100 is implemented at least in part on the Internet, and some of the nodes 102 may be located in geographically distributed locations.

[0033] Nodes 102 maintain a global ledger of all transactions in the blockchain, which is grouped into blocks, with each block containing a hash of the block that precedes it 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. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. Details of the implementation and operation of blockchain networks, such as those using the Bitcoin protocol, will be understood by those skilled in the art.

[0034] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how the transaction's outputs can be accessed and by whom. A transaction's output may be an address to which a value is transferred as a result of the transaction. That value is then associated with the output address as an Unspent Transaction Output (UTXO). Subsequent transactions can then reference that address as an input to use or destroy that value.

[0035] Nodes 102 may be of various types or categories depending on their functions. 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. A node 102 may have more than one function. For example, a "full node" may provide all four functions. A lightweight node may be implemented, for example, with a digital wallet, and may only perform wallet and network routing functions. Rather than storing the complete blockchain, a digital wallet may keep track of block headers, which serve as an index when querying for blocks. Nodes 102 communicate with each other using a connection-oriented protocol, such as TCP / IP (Transmission Control Protocol).

[0036] This application proposes and describes an additional type or category of node, the merchant node 104 (sometimes referred to as "M-node" 104). M-nodes 104 are designed with a focus on rapid propagation of transactions. They do not store the complete blockchain and do not perform mining functions. In that sense, they are similar to lightweight nodes or wallets; however, they include additional functionality that allows for rapid propagation of transactions. Central to the discussion of the operation of M-nodes 104 is the rapid validation and propagation of unconfirmed transactions, particularly to other M-nodes 104, from which unconfirmed transactions are quickly pushed to other nodes 102 in the blockchain network 100. To facilitate this function, M-nodes 104 are allowed a large number of incoming and especially outgoing connections that may otherwise be allowed to nodes 102 under the governing protocol.

[0037] The M-nodes 104 may be collectively referred to as the merchant network 106 (or the "M-Net" 106). The term "merchant" may be interpreted as meaning "specialised". Although shown as a physically separate network in FIG. 1 for ease of illustration, the M-nodes 104 may be integrated into the blockchain network 100. Each M-node 104 is a specialized node in the blockchain network 100 and meets certain hardware and performance capabilities that ensure it can perform the functions of the M-node 104. That is, the M-Net 106 may be considered a sub-network within and distributed throughout the blockchain network 100. The M-nodes may be arranged and configured to perform one or more dedicated functions or services.

[0038] For the M-Net 106 to operate reliably and provide services at a given security level, the M-Nodes 104 need to maintain a good view of the entire M-Net 106, and therefore an efficient routing protocol needs to be deployed. Every time an M-Node 104 receives an initiation transaction, it needs to broadcast it to other Nodes 102 as well as to several other M-Nodes 104. In the M-Net 106 perspective, this is equivalent to finding a solution to the Multiple Traveling Salesman Problem (MTSP). There are numerous solutions that address this problem, and any one of them can be used in the M-Net 105. Each of the M-Nodes 104 performs some form of modern routing optimization.

[0039] In some implementations, the M-Net 106 is implemented as a decentralized IP multicast type network, i.e., to allow for rapid dissemination of incoming transactions across the blockchain network 100, multicast is used to ensure that transactions are quickly broadcast throughout the M-Net 106, allowing all M-Nodes 104 to focus on forwarding the transactions to other nodes 102 in the blockchain network 100.

[0040] Multicast network architecture allows the possibility of simultaneous distribution of data towards a group of destination nodes, without data duplication for each node interested in receiving the information. If a node wishes to receive a multicast transmission, it joins the multicast group (the registration phase) and will receive all data sent to the multicast group from then on. IP multicast is able to scale to a larger set of receivers without requiring a priori knowledge of how many receivers there are, and by requiring the source to send a packet only once, the network infrastructure is used efficiently. Due to the nature of multicast networks, the use of connection-oriented protocols (such as TCP) is impractical due to the simultaneous communication with many other nodes. Therefore, connectionless protocols are used.

[0041] Some blockchain networks, such as Bitcoin, use TCP node-to-node. Data packets sent using TCP have an associated sequence number that is used for ordering purposes. In addition to this, the TCP protocol includes a three-way handshake procedure both in the case of setting up a connection and in the case of its termination. Packets sent over TCP arrive with associated overhead, they have an associated sequence number, and there is a three-way handshake protocol. While setting up a connection, 128-136 bytes are sent, closing a connection costs 160 bytes. Thus, the handshake in packet transmission is costly, amounting to 296 bytes. Furthermore, when a node receives a new transaction, it notifies other nodes with an inventory (INV) message that contains the hash of the transaction. The node that receives the INV message checks if the hash of the transaction has been seen before; if not, the node will request the transaction by sending a GETDATA message. The time taken to send a transaction from node A to node B is T1=verification+TCP(inv+getdata+tx) where TCP() denotes the overhead introduced by the TCP handshake procedure.

[0042] An M-node 104 may be configured to use TCP for communication with other nodes 102, which is required by existing protocols. However, a node may use a connectionless protocol such as User Datagram Protocol (UDP) for M-node 104 to M-node 104 communication, or even more appropriately for M-node 104 to multiple M-nodes in a multicast situation. Unlike TCP, UDP does not include a handshake protocol, and therefore allows the M-node 104 to propagate transactions more quickly. This also prevents a malicious node from associating with another node by sending repeated INV messages without ever sending the actual transaction.

[0043] The lightweight nature of UDP comes with certain trade-offs: little error checking and no error recovery. In some implementations, these limitations of UDP can be overcome at the application level by implementing error recovery, ordering, and retransmission as application-layer functions. Placing error checking at the application level removes overhead from the network.

[0044] In one exemplary situation, a regular node 102 in the blockchain network 100 generates a transaction that it wishes to have processed by the M-Net 106, such as a merchant-based payment. The node may send the transaction to an M-node 104, which may broadcast it to other M-nodes 104 using multicast, or may send the transaction directly to multiple M-nodes 104 if the node knows the IP multicast addresses of the M-nodes 104. In some instances, all M-nodes 104 in the M-Net 106 are members of a single multicast address, and therefore all transactions sent to that address are received by all M-nodes 104; however, in some cases, there may be more than one multicast address associated with the M-Net 106, and the receiving M-node 104 may evaluate from the routing information whether further broadcasting of the transaction to other multicast addresses is required to propagate the transaction to the complete M-Net 106.

[0045] Multicast helps ensure a fast initial propagation of new transactions to all M-nodes 104; however, multicast solutions do not necessarily address the scalability problem of the blockchain network 100 that stems from increased transaction throughput. Each node 102 in the network 100 typically maintains a member pool that contains unconfirmed transactions that the node has discovered that have not yet been incorporated into the blockchain by miners who have completed the proof-of-work. A significant increase in the number of transactions resulting from their use in payment processing would require each member pool to store an increased amount of transactions. Thus, although nodes in the M-Net 106 are able to receive new transactions almost simultaneously, they may have limited storage capacity for large and rapidly changing member pools.

[0046] To address this issue, this application proposes that, as an alternative to using multicast, the M-node 104 utilize a shared member pool implemented by a Distributed Hash Table (DHT).

[0047] The average transaction (TX) size is 500 bytes, and the 4 Assuming a transaction rate of 100 TX / s, M-Net 106 can receive ~400GB of incoming data daily. All of this data needs to be stored for varying periods of time in the member pool of unconfirmed transactions. Thus, M-Net 106 requires significant storage and capacity to store data quickly. To avoid placing too many requirements on each individual M-Node 104, M-Node 104 implements a shared member pool that relies on the DHT. Instead of having each M-Node 104 maintain all incoming TXs in its own member pool, each M-Node 104 only stores a portion of the total and the hash of the remaining portion and the associated key value.

[0048] DHT is a class of decentralized distributed systems that allows membership partitioning of key sets among nodes and can send messages to only the owners of a given key in an efficient and optimized way. Each node in the network can be seen as a cell in an array of hash tables. DHTs are designed to manage a very large number of nodes, allowing new nodes to join the network and old nodes to leave and crash without compromising the integrity of the shared data. DHTs guarantee decentralization (there is no central authority, no central coordinator), scalability (the system acts efficiently for millions of nodes), and fault tolerance (the system is reliable and can manage nodes that join and leave the network or crash). Each node in the network may only remain in contact with a small number of other nodes, so the network does not become overloaded even when there are fluctuations or new pieces of data.

[0049] The same concept can be applied to a UTXO database, which contains the set of all unspent outputs in the blockchain. A UTXO database can be built using a DHT to share content among a group of nodes.

[0050] There are many possible DHT architectures and protocols that can be used to implement a shared member pool for the M-Net 106. One example is Pastry™, but there are many others. Pastry™ is a protocol designed to maintain an overlay network capable of storing and transferring information in a distributed system. Each node in a Pastry™ network is assigned a 128-bit identifier, which is stored in a rotating node ID space (0 to 2 128 The ID is used to specify the node's position within the network (range 1 to 1024). The ID is randomly assigned to a node when it enters the network. Each node maintains a routing table, a neighbor set, and a leaf set.

[0051] One factor to consider in sizing a robust DHT is the number of replicas needed to guarantee the robustness and reliability of the entire network. As already mentioned, nodes can join and leave the network, and this fact should not affect the availability of data. If a node storing transaction A leaves the network, it needs to find transaction A in other parts of the network. In existing blockchain networks, for example Bitcoin, the network has a number of blockchain replicas equal to the total number of nodes in the network (average 5000 replicas), which impacts scalability.

[0052] In the currently proposed M-Net 106, the member pool is not fully replicated on all M-nodes 104, but is instead implemented by a DHT. To provide reliability, the DHT can be implemented to have some overlap; that is, each transaction data item is replicated on more than one M-node 104 (but not on all M-nodes 104). As an example, the DHT may be implemented to specify a minimum number of two replicas. This results in the probability that at any given time, assuming complete independence between the nodes, two nodes will be down at once being:

number

[0053]

[0033] Referring now to Figure 2, Figure 2 shows a sequence diagram illustrating a process 200 of storing a new transaction in a distributed member pool 204. The distributed member pool 204 is implemented using a DHT. The process 200 includes a node 102 sending a transaction to an M-node 104. The M-node 104 hashes the transaction or a transaction ID, depending on the implementation, to obtain a key value. The key value indicates the M-node 104 or multiple M-nodes 104 (in the case of replicated data) where the transaction should be stored. The M-node 104 stores the transaction in the distributed member pool 204, which may include routing the transaction to the appropriate M-node 104 where the transaction should be stored based on the assigned ID and key value of the M-node 104 in the M-net 106. The M-node 104 may receive an acknowledgement depending on the associated DHT protocol.

[0054] Referring now also to Figure 3, Figure 3 illustrates in flow chart form an example method 300 for propagating a transaction in a blockchain network. The method 300 is implemented by the M-node 104 (Figure 1). The M-node 104 receives a new transaction from a legitimate node in operation 302. The M-node 104 may perform certain validation operations to verify the authenticity of the transaction.

[0055] As shown by operation 304, the transaction may be hashed to generate a key for the transaction. The key may indicate where in the DHT the transaction should be stored, which may be at a node other than the current M-node 104. The M-node 104 then evaluates in operation 306 whether the transaction is already in the DHT. Each M-node 104 has a portion of transactions stored based on a partition of the keyspace among the M-nodes 104 that make up the M-net 106 (FIG. 1). In some implementations, the keyspace is partitioned among participating M-nodes 104. The partition may include overlap to cause replication for resiliency of the network. In some implementations, such as using Pastry™, each M-node 104 is assigned a unique key or ID number, and transactions may be stored in the M-node 104, or in multiple M-nodes 104 (if replication is desired), based on proximity to the transaction's key value. The M-node 104 may have a locally stored portion of the transaction and a hash or key value of the remaining portion, so in operation 306 the node 104 may be able to evaluate whether the new data is in the DHT based on the local data.

[0056] If the transaction is in the DHT, in operation 308, the M-node 104 stores the transaction in the DHT based on its key value. In a general sense, this can take the form of a put(k,tx) operation, where k is the key value and tx is the transaction. The applicable DHT routing protocol ensures that the transaction is sent to the appropriate M-node 104 and stored there. The DHT may operate according to various protocols of a distributed hash table, depending on the implementation chosen. Using a DHT to store the transaction in the M-Net 106 avoids routing the transaction to all M-nodes 104 using INV / GETDATA messages within the M-Net 106.

[0057] In operation 310, the M-node 104 sends the transaction to a regular node 102 of the blockchain network 100, in this example according to a regular transaction transfer protocol of the blockchain network 100. For example, regular node communication may utilize TCP for node-to-node connections.

[0058] Referring now to FIG. 4, FIG. 4 illustrates in block diagram form a simplified example of an M-node 400. The M-node 400 in this example includes a processor 402, a network interface 404, and a memory 406. The M-node 400 may be implemented using any suitable computing hardware having network connectivity resources and sufficient processing and memory resources to perform the functions described herein. The M-node 400 may include processor-executable instructions that implement the functions described herein. In some cases, the processor-executable instructions may be referred to as a blockchain merchant node application 420, although it will be appreciated that the instructions may be implemented in one or more modules, applications, scripts, or other programming structures depending on the hardware and operating system. The processor 402 may include a multi-core processor and / or multiple processors.

[0059] The memory 406 stores data including a designated portion of the DHT-based member pool 410 based in part on the DHT key value (i.e., M-node ID). In this implementation, the memory 406 further stores a routing table 412, a neighbor set 414, and a leaf set 416. The routing table 412 includes a list of specific routing destinations in the M-net, and when a node receives a packet of data, the node consults the routing table to know where to send the data. The routing table 412 may also include information about how far each destination is from the M-node 400. The neighbor set 414 includes information about nearby M-nodes based, for example, on a proximity metric (ping latency). The leaf set 416 includes M-nodes that are numerically close. M-nodes are numerically close if their key values ​​(node ​​IDs) are numerically close. The memory 406 further includes an M-node reputation table 418, as described further below.

[0060] To provide scalability, in addition to implementing the member pool using the DHT, the M-Net allows nodes to join the M-Net. FIG. 5 shows a sequence diagram 500 illustrating an example of a new node 504 joining the M-Net where the member pool is implemented as a DHT 506. The new node 504 must have the address of at least one M-node that is already part of the M-Net so that the new node can direct a join request to any M-node. Signal diagram 500 shows an example of the new node 504 sending a "joinDHT(m-node.address) request" to M-node 502. M-node 502 performs a predefined verification action, which includes querying the new node 504. For example, the M-Net may have a set of minimum criteria associated with joining the M-Net specifying M-node 502. By way of example, the criteria may include minimum processing resources available, minimum free memory available, and connection requirements.

[0061] Assuming the M-node 502 has completed whatever verification operations it performs to validate the new node 504, it forwards the joinrequest() to the DHT 506 according to whatever DHT protocol governs the operation of the DHT 506. The DHT 506 then communicates with the new node 504, providing it with routing tables, key values ​​(node ​​IDs), and any other data that enables the new node 504 to function as a new M-node in the M-net.

[0062] It will be appreciated that the ease with which nodes may join an M-Net creates vulnerabilities in that malicious nodes may join the network. To identify and isolate potentially malicious nodes, the present application provides for M-nodes to store an M-node reputation table 418. Figure 6 illustrates diagrammatically one example of an M-node reputation table 418 used to track and update node behavior rankings.

[0063] As a new node joins the network, the node may be added to the M-node reputation table 418, as indicated by the node ID field 602. The table 418 may also include a joining time 604 in some implementations. The table 418 also includes a score 606 or rating for the M-node.

[0064] The score 606 may be adjusted up or down based on predefined behavioral metrics. For example, if an M-node fails to forward a transaction, remains silent for a period of time, floods M-Net with traffic that is determined to be non-transactional, or engages in other negative behavior, its ranking may be dropped or reduced. If a node's score falls below a predefined minimum, the node may be removed from M-Net.

[0065] The M-node reputation table 418 maintained at a particular M-node may be limited to tracking the scores of its neighbors, rather than the entire M-net. Thus, if a new M-node joins the network at time t, the neighbors' M-net reputation tables will not contain any information about the new node, but they will start building the reputation of the new node from time t, storing information in their node register tables. For example, if the new node is a silent node, meaning that it does not forward information it receives over the network, all neighbors will start recording its behavior in their respective M-node reputation tables, for example assigning a negative value to the new node's ID. If after a certain time (t+n) the M-node reputation tables of all nodes aware of the new node contain negative values, they may decide to isolate the new node and ban it from the network.

[0066] Referring now to Figure 7, Figure 7 illustrates an exemplary member pool data entry 700. Transactions in M-Net's distributed member pool may wait for significant periods of time before being confirmed, i.e., incorporated into a block that is added to the blockchain and approved. A block is considered "confirmed" once a sufficient number of subsequent blocks have been added to the blockchain upon it, such that it becomes computationally infeasible to remove the block in order to reverse the growth in the blockchain and turn it into a different branch or fork.

[0067] Due to the size and flexibility of the member pool, as well as the volume of transactions, it may be possible that a given transaction may not be confirmed for a longer period of time than in some blockchain implementations such as Bitcoin. In traditional Bitcoin implementations, a transaction is removed from the member pool as soon as it is included in a block. This means that if a block becomes an orphan block, all transactions in the block are resent on the network. This may be impractical and may result in long delays to confirm a given transaction in fast transaction networks.

[0068] Thus, in some implementations, the member pool may track the number of confirmations of the block in which the transaction was incorporated, i.e., the number of blocks added to the blockchain subsequent to the block in which the transaction was incorporated. A transaction is removed from the member pool only after a predetermined number of confirmations have occurred. The predetermined number may be 4, 5, 6, 7, or any number appropriate for a given implementation. As shown in FIG. 7, a member pool data entry 700 may be configured to include a transaction ID field 702, a transaction field 704, and a number of confirmations (NoC) field 706. In another implementation, rather than tracking the NoC, the member pool data entry 700 may simply record the block number. From the block number, it is possible to evaluate how many confirmations have occurred based on the current block number of the blockchain.

[0069] Once the required number of confirmations has occurred, the transaction can be safely removed from the member pool. This way, there is no loss of the transaction in case of an orphan block, and the transaction is permanently deleted after the required number of confirmations.

[0070] One or more embodiments of the present invention may be described as an improved blockchain implementation method and system that may provide improved speed of processing write operations, exchanges, transfers, etc., by a blockchain network. Other advantages of the present invention may also be provided.

[0071] It will be understood that the devices and processes described herein, as well as any modules, routines, processes, threads, applications, or other software components implementing the described methods / processes constituting a video feature extractor, may be implemented using standard computer programming techniques and languages, and this application is not limited to any particular processor, computer language, computer programming conventions, data structures, or other such implementation details.

[0072] It should be noted that the above embodiments illustrate rather than limit the invention, and that those skilled in the art may design many alternative embodiments without departing from the scope of the invention as defined in the appended claims. In the claims, any reference signs in parentheses shall not be construed as limiting the scope of the claims. Words such as "comprises" and "comprises" 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, "comprises" means "comprises or consists of" and "has" means "comprises or consists of". A single reference of an element does not exclude a plurality of references of such elements, and vice versa. The invention can be realized 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 items are recited in mutually different dependent claims does not indicate that a combination of these items cannot be used to advantage.

[0073] (Appendix 1) 1. A specialized network node configured to facilitate distribution of blockchain transactions over a network of interconnected nodes used to implement a blockchain, a subset of the nodes being specialized network nodes interconnected by an overlay network, the specialized network nodes comprising: Processor; a memory for storing a designated portion of a distributed member pool structured as a distributed hash table, the distributed member pool including pending transactions awaiting confirmation; Network interfaces; and Blockchain-specific network node applications, including processor-executable instructions; the instructions, when executed by the processor, cause the processor to: receiving a transaction including a transaction identifier; hashing the transaction identifier to obtain a key; determining whether the transaction is stored in the distributed member pool using the key, and if not, storing the transaction in the distributed member pool as a pending transaction; and Sending the transaction over a peer-to-peer connection to nodes other than the special network node; A special network node that performs this function. (Appendix 2) 2. The specialized network node of claim 1, wherein the memory further stores data regarding a number of confirmations of a block that includes the transaction and is included in the blockchain, and the instructions cause the processor to remove the transaction from the distributed member pool if the number of confirmations reaches a minimum number. (Appendix 3) 3. The specialized network node of claim 2, wherein the data regarding the number of confirmations is either a count of the number of confirmations that is updated for each new block added to the blockchain, or the block number of the block in which the transaction is included. (Appendix 4) A special network node as described in any one of claims 1-3, wherein the memory further stores a special network node reputation table including identifiers for any detected new neighboring special merchant nodes and associated scores for the new neighboring special network nodes based on the detected activity of the new neighboring special network nodes. (Appendix 5) The special network node of claim 4, wherein the instructions are configured to cause the processor to update the score of the new neighboring special network node and determine that the score of the new neighboring special network node has fallen below a threshold, thereby designating the new neighboring special network node as a malicious node and isolating the new neighboring special network node. (Appendix 6) A special network node as claimed in any one of claims 1-5, wherein the designated portion of the distributed member pool partially overlaps with a second portion of the distributed member pool stored in another of the special network nodes. (Appendix 7) A special network node as described in any one of claims 1-5, wherein each of the special network nodes stores a respective designated portion of the distributed member pool, the respective designated portions partially overlapping such that each of the pending transactions is stored in at least two of the special network nodes but not in all of the special network nodes, and optionally, each of the pending transactions is included in no more than two respective designated portions of the distributed member pool. (Appendix 8) 1. A computer-implemented method for facilitating a blockchain transfer involving a plurality of nodes coupled to a network used to implement the blockchain, a subset of the plurality of nodes being specialized network nodes, the specialized network nodes storing a distributed member pool including pending transactions awaiting confirmation, the distributed member pool being implemented within the specialized network nodes as a distributed hash table, the method comprising: receiving a transaction including a transaction identifier; hashing the transaction identifier to obtain a key; checking whether the transaction is stored in the distributed member pool using the key, and if not, storing the transaction in the distributed member pool as a pending transaction; and transmitting the transaction to nodes other than the special network node using peer-to-peer connections; The method includes: (Appendix 9) 9. The method of claim 8, further comprising determining a number of confirmations of a block that includes the transaction and is included in the blockchain, and removing the transaction from the distributed member pool if the number of confirmations reaches a minimum number. (Appendix 10) 10. The method of claim 9, wherein storing the transaction in the member pool comprises storing the transaction in relation to a confirmation number of a block in which the transaction is included, the confirmation number stored in the member pool for the transaction being updated as new blocks are added to the blockchain. (Appendix 11) 10. The method of claim 9, wherein storing the transaction in the member pool comprises storing the transaction in relation to a confirmation number of a block in which the transaction is included, and determining the confirmation number comprises ascertaining a current block number on the blockchain and comparing the current block number to a block number of the block in which the transaction is included. (Appendix 12) Detecting new nearby special network nodes; storing the identifier of the new neighbor special network node in a special network node reputation table; and updating a score of the new neighboring special merchant node in the special network node reputation table based on the detected activity of the new neighboring special network node; 12. The method of any one of claims 8-11, further comprising: (Appendix 13) The method of claim 12, further comprising determining that the score of the new neighboring special network node has fallen below a threshold, thereby designating the new neighboring special network node as a malicious node and isolating the new neighboring special network node. (Appendix 14) A method according to any one of claims 8-13, wherein one of the special network nodes stores a portion of the distributed member pool, and the portion of the distributed member pool stored in the one of the special network nodes partially overlaps with a second portion of the distributed member pool stored in another of the special network nodes. (Appendix 15) A method according to any one of claims 8-13, wherein each of the special network nodes stores a respective portion of the distributed member pool, the respective portions partially overlapping such that each of the pending transactions is stored in at least two of the special network nodes but not in all of the special network nodes, and optionally, each of the pending transactions is included in no more than two respective portions of the distributed member pool. (Appendix 16) A non-transitory processor-readable medium storing processor-executable instructions for participating in a blockchain transaction among a plurality of participating nodes, the processor-executable instructions, when executed by a processor in one of the participating nodes, cause the processor to perform the method of any one of claims 8-15.

Claims

1. A special network node: Processor; a memory for storing a designated portion of a distributed member pool structured as a distributed hash table, the distributed member pool including pending transactions awaiting confirmation; A network interface; and a blockchain-specific network node application including processor-executable instructions; the instructions, when executed by the processor, cause the processor to: The special network node participates in a node network in which the distributed member pool is implemented as a distributed hash table (DHT); Sending a request to a node in the node network to request that the node join the network; A specialized network node that responds to validation actions performed by the DHT and the existing nodes by receiving from the DHT routing tables, key values, and any other data necessary to function as a new node in the node network.

2. In the special network node according to claim 1, the request is sent to a participating DHT (m-node A special network node that is a strict (non-interface address) request.

3. 3. The special network node according to claim 1 or 2, wherein the node network is a non-centralized IP multicast type network.

4. 4. A special network node as claimed in any one of claims 1 to 3, wherein the existing nodes inquire about a set of minimum criteria associated with joining the node network.

5. 5. The specialized network node of claim 4, wherein the set of minimum criteria includes a minimum processing resource available, a minimum free memory available, or a connection requirement.

6. A special network node as claimed in any one of claims 1 to 5, wherein the existing node forwards a joinrequiset() to the DHT in accordance with a DHT protocol governing the operation of the DHT.

7. 7. A special network node as claimed in any one of claims 1-6, wherein the special network node is added to a reputation table indicated by a node ID field.

8. 1. A computer-implemented method for facilitating a blockchain transfer involving a plurality of nodes coupled to a network used to implement the blockchain, a subset of the plurality of nodes being specialized network nodes, the method comprising: A special network node among the plurality of nodes participates in a node network in which a distributed member pool is implemented as a distributed hash table (DHT); Sending a request to a node in the node network to request that the node join the network; In response to validation actions performed by the DHT and the existing node, by receiving from the DHT a routing table, key values, and any other data necessary to function as a new node in the node network.

9. The method of claim 8, wherein the request is made to a participating DHT (m-node address) request, method.

10. 10. The method according to claim 8 or 9, wherein the node network is a non-centralized IP multicast type network.

11. 11. The method of any one of claims 8-10, wherein the existing nodes query a set of minimum criteria associated with joining the node network.

12. 12. The method of claim 11, wherein the set of minimum criteria includes a minimum processing resource available, a minimum free memory available, or a connection requirement.

13. A method according to any one of claims 8-12, wherein the existing node forwards a joinrequiset() to the DHT according to a DHT protocol governing the operation of the DHT.

14. The method of any one of claims 8-13, wherein the special network node is added to a reputation table indicated by a node ID field.

15. 15. A non-transitory processor-readable storage medium storing processor-executable instructions for participating in a blockchain transaction among a plurality of participating nodes, the processor-executable instructions, when executed by a processor in one of the participating nodes, cause the processor to perform the method of any one of claims 8 to 14.

Images