System and method for propagating data packets in a node network

Abstract

To provide a method and a system for propagating data packets in a network of nodes.SOLUTION: A method includes the steps of collecting a set of first data packets during a first time period, determining an available bandwidth among links of a network node to a plurality of neighboring nodes connected to the network node, and determining a mapping that assigns each of the first data packets to one or more neighboring nodes for relaying. The determining the mapping uses the available bandwidth as a basis for setting at least one of a first number of peer nodes to which the first data packets are assigned for relaying, a first length of time of delay in relaying the first data packets to the one or more peer nodes, and a number of hops for the first data packets from the network node. The method also includes transmitting the first data packets to the plurality of neighboring nodes in accordance with the mapping.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] This invention relates, in general, to computer networks, and more particularly to methods and apparatus for propagating data within a network of nodes, electronic communications, and network technologies. The invention is particularly well-suited for use in connection with blockchain technology. In particular, the invention relates to secure data transmission and the mitigation of potential malicious events, i.e., attacks, by third parties. [Background technology]

[0002] In this specification, we use the term “blockchain” to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referenced here for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are included within the scope of the present invention. The term “user” here may represent a human or processor-based resource. The term “Bitcoin” is intended to include all versions and variations of protocols / implementations / platforms derived from the (original) Bitcoin protocol / implementation / platform.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset among participants in the blockchain system, and it contains at least one input and at least one output. Each block contains the hash of the previous block, and these blocks are concatenated together to produce a permanent, immutable record of all transactions written to the blockchain since its origin. A transaction contains a small program known as a script. The script embeds its inputs and outputs and specifies how and by whom the transaction's output is accessible. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be verified. Network nodes (miners) perform tasks to ensure that invalid transactions are rejected from the network and that each transaction is valid. Software clients installed on the nodes perform this verification on unspent transactions (UTXOs) by executing lock and unlock scripts for the UTXOs. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must (i) be verified by the first node that receives the transaction, and if the transaction is valid, the node relays the transaction to other nodes in the network, (ii) be added to a new block constructed by miners, and (iii) be mined, that is, added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to develop uses for both Bitcoin's underlying cryptographic security system and data that can be stored on the blockchain to implement new systems. Blockchain would be highly advantageous if it could be used for automated tasks and processes not limited to the cryptocurrency domain. Such solutions could diversify their applications while leveraging the benefits of blockchain (e.g., permanence, tamper resistance to event recording, decentralized processing, etc.).

[0006] One of the recognized advantages of blockchain technology like Bitcoin is the anonymity of transactions. Personal details of Bitcoin users are not officially and explicitly attached to Bitcoin addresses, and the Bitcoin ledger on the blockchain contains only public address information. However, because blockchain is structured as a decentralized peer-to-peer network operating on the internet, transaction anonymity is vulnerable to attacks that use IP (Internet Protocol) address information to link users to network activity. For illustrative purposes, deanonymization attacks, such as IP traffic analysis performed on blockchain-based networks, allow interested third parties to monitor transactions submitted to the network by users and link those transactions to their sources using publicly available information, for example, by linking a user's public key to their IP address.

[0007] Traffic analysis is particularly problematic in blockchain-based networks that rely on the propagation of transactions by and between network nodes. Each node in the network that receives a transaction verifies the transaction and subsequently sends it to its peer nodes. In the Bitcoin protocol, a node sends an "INV" message containing a list of transactions to its peer nodes and receives a "GETDATA" response message in which it selects a subset of the transactions advertised in the "INV" message. The node then sends the requested transactions to its peer nodes. This process is performed for each peer node to which the node is connected. An attacker could intercept and analyze the data transmitted as transactions propagate within the network to obtain information that can ultimately be used to link the source and destination of a transaction.

[0008] It is desirable to provide technologies for propagating transactions in blockchain-based networks that can reduce the potential for jeopardizing network anonymity or other types of deanonymization attacks through traffic analysis. More generally, it is desirable to provide technologies for relaying data between nodes in peer-to-peer networks to reduce vulnerability to deanonymization attacks.

[0009] This solution was devised here.

[0010] Accordingly, the present invention provides the methods and apparatus defined in the appended claims. [Overview of the project]

[0011] The present invention may provide a computer-implemented method for propagating data packets in a network of nodes. The method is: A step of collecting a set of first data packets at a network node during a first time period, wherein the set includes at least one first data packet received from one or more first nodes in the network. The steps include determining the available bandwidth among the links of the network node to a plurality of neighboring nodes connected to the network node, The steps of determining a mapping that assigns each of the first data packets to one or more neighboring nodes for relaying, wherein the mapping indicates the expected relay time for each of the first data packets. The determination of the mapping is as follows for each of the first data packets: The first number of peer nodes to which the first data packet is assigned by the mapping for relaying, The first time length of the delay when relaying the first data packet to one or more peer nodes, The number of hops for the first data packet from the network node, The method may include a step of using an updated instruction for available bandwidth as a basis for setting at least one of the following: The method may further include a step of sending the first data packet from the set to the plurality of neighboring nodes according to the determined mapping.

[0012] In some implementations, the step of determining the available bandwidth may include the step of obtaining an available bandwidth indicator in each of the links of the network node to at least one of the plurality of neighboring nodes.

[0013] In some implementations, the step of determining the mapping is: The steps include determining a range of possible values ​​for the number of peer nodes to which the first data packet is allocated by the mapping for relaying, based on the available bandwidth, The step may include selecting a number within the determined range in order to set it as a peer node of the first number.

[0014] In some implementations, the method, for at least one first data packet selected from the set of first data packets, does the following: A first set of peer nodes to which at least one first data packet is allocated for relaying, A second subset of the first set, the second subset comprising only peer nodes that, upon receiving the at least one first data packet from the network node, are designated to relay the at least one first data packet to their neighboring nodes. The step of identifying may further be included.

[0015] In some implementations, the step of sending the first data packet from the set to the multiple neighboring nodes according to the determined mapping is: For the at least one first data packet, The steps include sending the at least one first data packet to the peer node included in the second subset, The steps may include: sending a modified data packet to a peer node not included in the second subset, wherein the modified data packet includes the at least one first data packet modified to indicate that further relaying of the at least one first data packet to the peer node is prohibited.

[0016] In some implementations, the method may further include the step of setting additional bits in the at least one first data packet to indicate that further relaying of the at least one first data packet to a peer node is prohibited.

[0017] In some implementations, the at least one first data packet may be arbitrarily selected from the set of first data packets.

[0018] In some implementations, the at least one first data packet may be selected based on the determination that the at least one first data packet has been previously sent by the network node to one or more peer nodes.

[0019] In some implementations, the step of sending the first data packet from the set to the multiple neighboring nodes according to the determined mapping is: For each of the one or more first data packets in the aforementioned set, The steps include determining the next scheduled time for relaying the first data packet to a neighboring node, The steps may include relaying the first data packet at a time that is the first time length after the next scheduled time for relaying the first data packet.

[0020] In some implementations, the first time length may be inversely proportional to the available bandwidth.

[0021] In some implementations, the network node is configured to generate at least one first data packet, and the step of determining the mapping is: For each of the at least one generated first data packets, The steps include identifying a predetermined number of first data packets previously generated by the network node, A step of obtaining a list of relay node sets associated with the previously generated first data packet, wherein the relay node set includes neighboring nodes to which each of the previously generated first data packets is relayed. The process may include the step of selecting a first set of relay nodes based on identifying a set of neighboring nodes that is different from the relay node set in the acquired list.

[0022] In some implementations, the step of selecting the first set of relay nodes may include the step of arbitrarily selecting a set of two or more neighboring nodes that are not included in the obtained list.

[0023] In some implementations, the method may further include the step of detecting changes in the available bandwidth in the links of the network node to the plurality of neighboring nodes. The step of determining the mapping is as follows for each of the first data packets: The first number of peer nodes to which the first data packet is assigned by the mapping for relaying, The first time length of the delay when relaying the first data packet to one or more peer nodes, The number of hops for the first data packet from the network node, The step includes using updated instructions for available bandwidth as a basis for setting at least one of the following.

[0024] The present invention may provide a computer-implemented system for performing the methods described above or elsewhere in this specification.

[0025] The present invention may provide a non-temporary computer-readable storage medium that stores instructions for adapting a computer system to perform the methods described above or otherwise in this specification.

[0026] This application provides a technique for managing bandwidth during data propagation within a network of nodes. The forwarding of data packets by a node to its peers can be controlled to take into account bandwidth availability within the node's links to neighboring nodes. Thus, nodes may be able to adapt in real time to changes in their available bandwidth and update their data forwarding allocation accordingly. The techniques and discovery methods described herein result in a reduction of redundant forwarding in data propagation processing and improve network traffic and inter-node bandwidth utilization.

[0027] This application also describes a solution that provides node-level anonymity within a network. More specifically, the methods and systems described herein help obscure the function of nodes in data propagation schemes within a network. Even if an attacker attempts to monitor inter-node traffic within a network or gain access to neighboring nodes of a particular node, the methods of the present invention make it difficult for such an attacker to determine whether a particular node is a source or relay node for data packets propagating within the network. By obscuring the function / role of nodes within a blockchain network, the effectiveness of deanonymization attacks against the network can be reduced, and the security of data transmission on the blockchain can be improved.

[0028] Furthermore, the present invention enables a node to manage the bandwidth utilization of its link to neighboring nodes, while simultaneously helping to maintain the anonymity of the source and destination of data packets relayed by the node. By considering constraints on the node's resources (e.g., bandwidth), a more realistic and practical method for data propagation is obtained. This technology also provides entities controlling the nodes of a network with the ability to configure the parameters of the data propagation protocol as needed, according to their preferences and needs.

[0029] Many of the exemplary implementations described herein refer specifically to blockchain transactions. However, it is understood that the methods and apparatus described herein may be implemented and applied in connection with non-blockchain transaction propagation. More generally, the methods and apparatus described herein may be suitable for use when propagating various different types of data between nodes in a peer-to-peer network. [Brief explanation of the drawing]

[0030] Any feature described in relation to one aspect or embodiment of the present invention may be used in relation to another aspect / embodiment described above. The above and other aspects of the present invention are evident from and taught by reference to the embodiments described herein. Embodiments of the present invention are described below by mere examples and with reference to the accompanying drawings. [Figure 1] This illustrates an exemplary network related to blockchain. [Figure 2] A schematic diagram of an exemplary blockchain node with input and output buffers is shown. [Figure 3] This is a schematic diagram of the Diffusion Mixer Protocol (DMP), a protocol for propagating transactions in a network of example nodes. [Figure 4] This shows an example of transaction relay in a network of nodes that comply with DMP. [Figure 5] This flowchart illustrates an exemplary process for propagating data packets within a blockchain network that conforms to the DMP (Data Management Platform). [Figure 6] Another exemplary process for propagating data packets within a blockchain network compliant with DMP is shown in flowchart format. [Figure 7] Another exemplary process for propagating data packets within a blockchain network compliant with DMP is shown in flowchart format. [Figure 8] This flowchart illustrates an exemplary process of sending data packets generated or received by nodes within a blockchain network. [Figure 9] This flowchart illustrates an exemplary process for sending data packets generated by nodes within a blockchain network. [Figure 10] This flowchart illustrates an exemplary process for relaying data packets received by nodes within a blockchain network. [Figure 11]This shows an example of destination mixing when propagating data packets within a node network. [Figure 12] This shows an example of delayed relaying of data packets within a node network. [Figure 13] An exemplary process for determining data relay allocation based on node bandwidth constraints is shown in flowchart format. [Figure 14] Another exemplary process for determining data relay allocation based on node bandwidth constraints is shown in flowchart format. [Figure 15] A flowchart illustrates an exemplary process for updating data relay allocations based on changes in node bandwidth constraints. [Figure 16] An example blockchain node is shown in block diagram format. [Modes for carrying out the invention]

[0031] First, referring to Figure 1, Figure 1 shows an exemplary blockchain-related network, which may be referred to as Blockchain Network 100 in this specification, in block diagram form. Blockchain Network 100 is a peer-to-peer open member network that anyone can join without invitation or consent from other members. A decentralized electronic device running an instance of the blockchain protocol on which Blockchain Network 100 operates may participate in Blockchain Network 100. Such a decentralized electronic device may be referred to as a node 102. The blockchain protocol may be, for example, the Bitcoin protocol or another cryptocurrency.

[0032] The electronic devices that execute the blockchain protocol and form 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 smartwatches, or other electronic devices.

[0033] The nodes 102 of the blockchain network 100 are connected to one another using appropriate communication technologies, which may include wired and wireless communication technologies. In many cases, the blockchain network 100 is implemented at least partially via the internet, and some of the nodes 102 may be located in geographically separated locations.

[0034] Node 102 maintains a global ledger of all transactions on the blockchain. Transactions are grouped into blocks, each block containing the 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. Transactions by node 102 that affect the global ledger are verified by other nodes 102 to maintain 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.

[0035] Each transaction typically has one or more inputs and one or more outputs. A script embeds the inputs and outputs and specifies how and by whom the transaction's outputs are accessible. The transaction's output may be the address to which value should be transferred as a result of the transaction. This value is then associated with the output address as an unspent transaction output (UTXO). Subsequent transactions may therefore refer to the address as an input to use or distribute the value.

[0036] Node 102 can perform a number of different functions, from network routing to wallet services, in order to maintain a robust and secure distributed public ledger. A "full node" contains a complete and up-to-date copy of the blockchain and can therefore verify any transaction (used or unused) on the public ledger. A "lightweight node" (or SPV) maintains a subset of the blockchain and can verify transactions using "simplified payment verification" technology. Lightweight nodes only download the block header, not the transactions within each block. These nodes therefore rely on peers to verify their transactions. A "mining node" is either a full or lightweight node and is responsible for verifying transactions and generating new blocks on the blockchain. A "wallet node" is typically a lightweight node and handles the user's wallet services. Nodes 102 communicate with each other using connection-oriented protocols such as TCP / IP (Transmission Control Protocol).

[0037] When a node wants to send a transaction to a peer, an "INVENTORY" message is sent to the peer, sending one or more inventory objects known to the sending node. If the peer relies on a "GETDATA" message, i.e., a full transaction request, the transaction is sent using a "TRANSACTION" message. A node that receives a transaction, if it is a valid transaction, forwards it to its peer in the same manner.

[0038] Referring to Figure 2, an exemplary node 200 is illustrated, having an input buffer 202 and an output buffer 204. The exemplary node 200 has network interfaces with multiple peer nodes, referred to as intA, intB, intC, intD, etc. The input buffer 202 shows input transactions from various peer nodes. The output buffer 204 shows output network packets corresponding to transactions for transmission to the peer nodes via their respective interfaces. Network packets are sent and received sequentially at the application level according to primitives provided by the operating system of node 200. Assuming that transaction x fits into a single Ethernet / IP packet, sending transaction x to m peers requires buffering m different output network packets. Both input and output network packets, along with other information, contain the serialized transaction and a logical interface ID representing the TCP / IP connection to the sending / receiving peer.

[0039] When a Bitcoin transaction is generated, the source node broadcasts the transaction message across the network. Generally, when a client generates a transaction, it is placed in output buffer 204. The transaction may or may not be immediately forwarded to peers. In the current implementation of the Bitcoin network, transactions are propagated by a mechanism known as "diffusion propagation," where each transaction source sends the transaction to its neighbors with an independent exponential delay. The delay in propagation is random, which helps introduce uncertainty into time estimations by malicious attackers. When a peer receives a particular transaction, it does not have to accept future relays of the same transaction. For example, the transaction hash may be stored in the peer's memory pool, allowing the peer to reject identical transactions. The "diffusion" of transactions across the network is symmetrical. This means that the forwarding node does not use information about the IP addresses of neighboring nodes to influence the transaction broadcast. For example, in "standard" diffusion processing (used in the Bitcoin protocol), all peers of the broadcasting node receive the same transaction, and only one transaction per peer is relayed at each relay instance at a time. This "spread" symmetry can be exploited by malicious third parties with knowledge of the network's peer-to-peer graph structure when carrying out deanonymization attacks.

[0040] This disclosure provides alternative technologies for transaction relaying on blockchain networks to improve protection against traffic analysis attacks. More specifically, the proposed relay protocol may be used to disguise, conceal, or obfuscate connections between the source nodes of a transaction and their IP addresses.

[0041] A transaction relay protocol, DMP (Diffusion Mixer Protocol), is proposed. MDP includes two independent diffusion stages. The first stage ("random differential relay" or RDR) enables mixing of relayed transactions and obfuscation of transaction sources. During the random differential relay stage, each node waits for a predetermined amount of time to receive and collect multiple transactions from its peers before broadcasting the transactions to the network. The node then generates an output connection to its "entry nodes" and sends different transactions with nearly identical timestamps to an arbitrarily (e.g., randomly) selected subset of these entry nodes. An entry node is a neighboring node from which a direct output connection can be established. The randomness in the selection of entry nodes and the diversity of relayed transactions can make it even more difficult for an attacker to reconstruct the network topology.

[0042] The second stage ("standard diffusion") ensures the timely and reliable propagation of transactions within the network. In the standard diffusion stage, each node relays the same transaction to all of its entry nodes, and each relay instance relays only one transaction per entry node at a time.

[0043] It should be noted that in a node network such as a blockchain network, one or more nodes may be capable of implementing a DMP. Specifically, one or more nodes in the network may, by participating in a DMP, be able to relay their received data packets to their entry node. Participating nodes may, for example, choose between RDR processing and standard spreading processing to propagate a particular data packet. Nodes in the network may choose to participate in a DMP and join the protocol in a distributed manner or through inclusion in a group of participating nodes composed of a central authority. Participating nodes relay their outgoing network packets according to the DMP. In particular, when a participating node receives a data packet, the node may forward the received data packet according to the propagation mode selected for the node, using rules specified by the DMP.

[0044] The proposed DMP for transaction relay is described with reference to Figures 3-7. Figure 3 provides a schematic diagram of the DMP. An exemplary blockchain network 300 of nodes is shown. Each node represents a network terminal (i.e., a blockchain node), and the edges represent links between nodes. For the purposes of explanation, it is assumed that it is possible to send or receive a single bit at a time for each link.

[0045] In this exemplary network 300, each node maintains a set of pending transactions, and therefore, when a node receives a new transaction, it is propagated through the network to all other nodes. Each node verifies the new transaction, stores it in its own local set, and forwards the new transaction to any peer node that does not yet have it. Due to the peer-to-peer nature of blockchain network 300, not all nodes receive new transactions simultaneously. This means that it takes some time for a new transaction to reach all nodes in network 300.

[0046] Figure 3 shows the two stages of the DMP for propagating a specific transaction Tx1: random difference relay 302 and standard spreading 304 of Tx1. The source node 310 of transaction Tx1 may generate or receive transaction Tx1 from a peer node at time t1. According to the DMP, the source node 310 waits to receive at least one input transaction from its neighboring nodes before beginning to broadcast the received / queued transaction. In the example in Figure 3, once transaction Tx2 is received by the source node 310 at time t2, transactions Tx1 and Tx2 are sent at time t3 to an arbitrarily selected subset of the entry nodes of the source node 310. Transaction Tx1 is forwarded to entry nodes 310c and 310d, while transaction Tx2 is forwarded to entry nodes 310a and 310b. The example in Figure 3 is for illustrative purposes only, and in particular, source node 310 may wait to receive more than two input transactions before propagating any of its received transactions.

[0047] Entry nodes relay received transactions to their peers. For example, nodes 310b and 310d each forward transactions Tx2 and Tx1 to one or more of their neighboring nodes. In DMP, each recipient of a transaction independently selects the propagation mode of the received transaction. Node 320 is an example of a node that selects standard propagation as its propagation mode. As shown in Figure 3, node 320 forwards the same transaction Tx1 to all of its entry nodes, namely 320a, 320b, 320c, 320d, and 320e.

[0048] Referring to Figure 5, an exemplary method 500 for propagating data packets within the network during the RDR phase of the DMP is shown in flowchart form. Method 500 is implemented by nodes in a blockchain network, such as network 100. In this context, a node may be understood to represent a mining node, a full node, a verification node, or any other type of individual blockchain node within the blockchain network. A node is a computing device having network connectivity, computing resources, and execution software that implements the blockchain protocol.

[0049] In operation 502, a client associated with a node generates at least one data packet of type 1. In the context of a blockchain network, the data packet of type 1 may contain a blockchain transaction. That is, the client may generate a blockchain transaction that should be propagated to other nodes in the network.

[0050] In operation 504, a node collects a set of data packets of a first type for a first time period T. That is, the node accumulates data packets of a first type over the time period. The set includes at least one generated data packet and at least one data packet of a first type received from one or more peer nodes in the network. Thus, data packets generated by a node are mixed with data packets of the same type received from neighboring nodes. In a blockchain network, a node accumulates a set of transactions for a time period T by monitoring the network for input transactions to be relayed. The length of the time period T may be predetermined. In some exemplary implementations, the length of the time period may vary based on parameters such as the average connection time, the average number of transactions received per unit time, or the centrality of nodes in the network (i.e., the number of input connections to the node). During the time period T, a node may only be permitted to accumulate data packets of a first type and therefore may be deterred from sending any data packets of a first type during the time period T.

[0051] In operation 506, a node arbitrarily selects a subset of its own entry nodes to which different sets of collected data packets are forwarded. More specifically, for each data packet in the set of collected data packets, the node arbitrarily selects two or more of its own entry nodes (i.e., neighboring nodes with which the node has an outbound connection) and assigns the data packet to the selected entry nodes. For example, the entry nodes may be selected randomly. In some implementations, a node may query the network to obtain fresh addresses of its peers. In the Bitcoin network, a node may query one or more database source names (DSNs) embedded in Bitcoin Core, BitcoinJ, or other blockchain protocols and maintained by members of the Bitcoin (or other blockchain) community. In response, the node obtains one or more DSN records showing the IP addresses of available full nodes that accept inbound connections. A decentralized version of peer discovery may be implemented by having peers send an "ADDR" message containing their IP addresses and port numbers to new nodes joining the network.

[0052] In some implementations, as part of operation 506, one or more nodes in the network may maintain a table or other data structure that tracks its own allocation of each collected data packet to the entry node to which the data packet should be relayed. Figure 4 shows an example of transaction relaying by source node 410 in the RDR phase of a DMP in a blockchain network. Table 1 shows an exemplary allocation of collected transactions Tx1-Tx5 from source node 410 to the entry nodes. The entry nodes are shown as nodes A, B, C, D, E, F, G, and H. As shown in Figure 4 and Table 1, source node 410 relays each transaction to at least two entry nodes, and multiple transactions can be relayed through the same node. For example, transactions Tx3, Tx4, and Tx5 are all relayed through entry node E simultaneously. More generally, in the RDR phase, multiple data packets may be relayed simultaneously to the same peer node by a forwarding node. Not all entry nodes necessarily receive transactions from source node 410 in a given instance of the DMP. In the example in Table 1, entry nodes C and G do not receive transactions from source node 410. Table 1 [Table 1]

[0053] Referring again to Figure 5, for each collected data packet, in operation 508, the node sends the data packet to each of the entry nodes selected (arbitrarily or randomly). Each selected entry node is configured to relay the data packet to one or more second nodes in the network (e.g., peers of the entry node) using a data propagation mode randomly selected for that entry node. In other words, each selected entry node forwards the received data packet to one or more of its peers using a propagation mode independently selected for that entry node. In the exemplary transactions in Figure 4, each of transactions Tx1 to Tx5 is forwarded to the entry node to which the transaction is assigned.

[0054] Each node receiving a transaction from source node 410 then randomly selects a propagation / spreading mode to use when forwarding the received transaction to one or more of its peer nodes (if any). In particular, the entry node receiving the transaction randomly chooses to relay the transaction according to either standard spreading or RDR processing. The choice between the two options is random. Therefore, in DMP, the two spreading processes occur probabilistically alternately. In other words, there is no clear distinction between the RDR phase and the standard spreading phase. As a result of this mixing of spreading processes, it becomes even more difficult for an attacker to reconstruct the network topology based on identifying the separation between a set of nodes relaying a transaction by random data propagation or by standard spreading.

[0055] In some implementations, the random selection of the spreading mode by the entry node may include receiving a message in addition to the data packets relayed from the source node. The entry node may then generate a random value (e.g., a random number), append it to the received message, and hash the result using, for example, SHA-256. The entry node may then check the hash value and, as a result, obtain the spreading mode based on predetermined rules associated with the hash value (e.g., if the last character of the hash is a digit, select RDR as the spreading mode). Alternatively or additionally, the selection of the spreading mode can be performed using any randomization process (e.g., a random number generator). Here, the probability of selecting one mode may be greater than the probability of selecting the other mode, depending on factors such as the number of input and / or output connections and the average number of data packets received per unit time.

[0056] When propagating specific data packets, it is desirable to strike a balance between the level of anonymity protection at the propagation node and the overall propagation speed. If the means of guaranteeing a certain level of anonymity are very cumbersome (e.g., requiring a large amount of network resources, or intentionally underutilizing network nodes when relaying data packets, etc.), the efficiency of the network in spreading data in a timely manner may be compromised. Therefore, in some implementations, the random selection of propagation mode by relay nodes may be weighted. In particular, different probabilities may be assigned to each of two or more propagation modes (i.e., RDR, standard propagation, etc.). As a result, the probabilities reflect the proportional importance of anonymity to the data propagation speed. For example, in some instances, a higher probability may be associated with the RDR mode of a particular network node, with greater importance placed on protecting the anonymity of the data being propagated.

[0057] Method 500 in Figure 5 is implemented by a node, which generates its own first type of data packet. In particular, a node that participates in the DMP and generates data packets for propagation to the rest of the network performs Method 500. Figure 6 shows an exemplary process performed by a relay node, or a node that forwards or relays data packets generated by other nodes. That is, a relay node is a node that does not generate the data to be forwarded during the relay of a particular data packet, but instead provides a "relay" function for the data packets. In operation 550, the relay node independently selects its own data propagation mode. The relay node may select, for example, between RDR mode and standard spreading mode. If standard spreading mode is selected (which may be determined in operation 552), the relay node forwards the data packet to all of its entry nodes in operation 554. In the example in Figure 6, the selection of the propagation mode is between two possible options, and this example is not limiting; in other examples, there may be three or more possible propagation modes. In method 500, if the selected mode is RDR (which may be determined in operation 552), the relay node performs steps 556, 558, and 560, which correspond to operations 504, 506, and 508 in Figure 5.

[0058] Referring to Figure 7, an exemplary process 600 for propagating data packets within a network is shown in flowchart form. Process 600 may be implemented in a blockchain node having multiple input and output connections to other nodes in the blockchain network.

[0059] Operations 602, 604, 606, and 610 of process 600 correspond to operations 502, 504, 506, and 508 of method 500, respectively. In operation 608, the node determines whether the trigger condition is met before sending the data packets collected in operation 610 to its assigned entry node. In particular, the transmission of the data packets is performed in response to the detection that the appropriate trigger condition is met. If the trigger condition is not met, the node continues to collect data packets of type 1 without relaying any of the data packets to its entry / peer node.

[0060] Trigger conditions may be used to instruct a node to collect a sufficient number of input data packets and / or to collect input data packets for a sufficient amount of time. For example, satisfaction may be determined based on a predetermined threshold. For example, by collecting multiple input data packets before they are simultaneously propagated to peer nodes in the network, an attacker monitoring the relay traffic originating from a node cannot easily identify the node as the correct source of the relayed data packets.

[0061] In some implementations, the trigger condition may be the end of a predetermined period from the time when the node generated at least one data packet of a first type in operation 602. That is, the node may be designed to monitor and collect incoming data packets (e.g., transactions) for a predetermined period from the time the node generates a data packet of the same type until any of those data packets are propagated by the node. This condition may be useful when attempting to ensure that data packets generated by the node are propagated after collecting more data packets of the same type that can be broadcast simultaneously. This makes it difficult for an attacker to correctly identify the node as the source of the generated data packets.

[0062] In some implementations, the trigger condition may be the end of a predetermined period from the time the node receives the first data packet of at least one input data packet of a first type from a peer. That is, the node may be designed to monitor and collect input data packets for a predetermined period of time starting from when the first such input data packet is received. This condition is useful when you want to ensure that more data packets, i.e., data packets generated by the node itself or received from other peers, are collected before they are broadcast to the rest of the network.

[0063] In some implementations, the trigger condition may be that the number of collected data packets reaches a threshold number during the first time period. In particular, the node may be designed to monitor and collect input data packets until the end of the first time period, or until a predetermined threshold number of data packets have been collected by the node, whichever comes first.

[0064] <Method for discovering Random Differential Relays (RDRs)> As described above, random difference relay represents a new development from the “standard spreading” protocol for the propagation of transactions in a network of nodes. When implementing RDR, a propagating node relays different transactions simultaneously to a randomly selected subset of entry nodes. The propagating node may generate a data structure like the one shown in Table 1 by randomly assigning each collected transaction to one or more entry nodes to which the transaction should be relayed. More generally, a network node relaying data packets to its payer may maintain its own internal routing data structure that specifies the type of relay to perform for each of the multiple data packets collected (i.e., received or locally generated) by the node.

[0065] In the context of the Diffusion Mixer Protocol proposed in this specification, each node in a blockchain network implementing RDR may independently construct its own routing data structure, or "RDR table." The RDR table defines the transaction allocation scheme for each node adopting the RDR protocol. In other words, the RDR table of each node is used to manage which transactions should be relayed to which peer and when. The RDR table is defined by a given time quantity ΔT RDR All transactions received or generated during that time, and the source peers of those transactions, may be tracked. The RDR table may include additional information such as the arrival time of the first instance of a transaction ("ToA timestamp"), the time selected to relay the transaction ("ToR timestamp"), and / or a counter of the number of instances of the same transaction received by the node. An example RDR table is provided below. Table 2 [Table 2]

[0066] A node's local RDR table may be dynamically (i.e., in real time) updated as new information (timeouts, received or generated transactions) becomes available. This disclosure provides various heuristics, or “subsystems,” that contribute to the construction and updating of individual RDR tables. These subsystems can be thought of as sets of rules or guidelines that can be applied to update specified transaction allocations within the RDR tables. Policies included in these subsystems may help improve the obfuscation of transaction sources and balance the network traffic generated by the relay operations of individual nodes. The proposed set of subsystems, namely source mixing, relay mixing, destination mixing, arrival time mixing, and source control, can be used to merge collected transaction relay information and to provide optimal allocation of network resources.

[0067] Referring to Figure 8, an exemplary method 700 for transmitting data packets generated or received at nodes in the network is shown in flowchart form. Method 700 presents a technique for propagating data within a network according to a transaction allocation scheme that follows at least one rule from the proposed subsystems / discovery methods. Method 700 is implemented by nodes in a blockchain network, such as network 100 in Figure 1. More specifically, Method 700 is performed by nodes that participate in the DMP and are configured to generate or receive a first type of data packet (e.g., a transaction) for propagation to the rest of the network.

[0068] In operation 702, a client associated with a node generates at least one data packet of type 1. The data packet may include, for example, a blockchain transaction.

[0069] In operation 704, the node collects a set of data packets of type 1 for a first time period T. That is, the node accumulates data packets of type 1 over a time period. The set includes at least one generated data packet and at least one data packet of type 1 received from one or more peer nodes in the network. In this way, data packets generated by the node are mixed with data packets of the same type received from neighboring nodes.

[0070] In operation 706, the mapping of a set of data packets collected to a plurality of neighboring nodes connected to the node is determined. The mapping indicates the expected time for each data packet in the set to be relayed to a neighboring node. This “mapping” is used to construct the individual local RDR tables of the nodes in the network. One or more of the subsystems / discovery methods described herein may contribute (partially or independently) to the construction of the RDR tables. In particular, one or more different submappings may be applied when determining the mapping of collected data packets to neighboring nodes. The submappings may be of at least two different types. A first type of submapping assigns any two data packets having the same source (i.e., generating node) to different subsets of neighboring nodes for relaying. The “source mixing” and “relay mixing” subsystems, described in more detail below, are examples of this first type of submapping. A second type of submapping assigns different expected relay times to any two data packets generated at the node or received by the node from a peer node at the same time interval. The "Arrival Time Mixing" subsystem is an example of this second type of submapping.

[0071] In operation 708, once the mapping of data packets from the collected set to neighboring nodes is determined, the data packets are sent to the neighboring nodes according to the determined mapping.

[0072] It is understood that individual subsystems are implemented independently to update the transaction assignments defined within the RDR table. That is, each subsystem may separately adopt the RDR table independently of other subsystems. Therefore, individual subsystems may provide different ways of assigning transactions to relay nodes, and thus different techniques for propagating transactions.

[0073] <Source mixing> The principle underlying the source mixing subsystem is that transactions locally generated at a node should be sent to a non-overlapping subset of peers. For illustration, if node x generates two transactions tx i and tx i+1 , the set of peers selected for relaying these transactions are denoted as S(tx i ) and S(tx i+1 ) respectively, and satisfy S(tx i ) ≠ S(tx i+1 ).

[0074] That is, the set of peers for two consecutive transactions differs by at least one peer. This inequality can help complicate any malicious search for the initial relay pattern of transactions generated at a node. This concept can be extended to source mixing of degree δ SM as follows: S(tx i+a ) ≠ S(tx i+b ), ∀(a,b) ∈ [0, δ SM - 1], a ≠ b

[0075] Referring to Figure 9, an exemplary method 800 for transmitting data packets generated at nodes in the network is shown in flowchart form. Method 800 presents a technique for propagating data within the network according to a transaction allocation scheme that follows source mixing subsystem / discovery rules. Method 800 is implemented by nodes in a blockchain network, such as network 100 in Figure 1. More specifically, Method 800 is executed by nodes that participate in the DMP and are configured to generate a first type of data packet (e.g., a transaction) for propagation to the rest of the network.

[0076] In operation 802, a client associated with a node generates at least one data packet of type 1. The data packet may include, for example, a blockchain transaction.

[0077] The node determines a first mapping of at least one generated data packet to its neighboring nodes (i.e., peers). In particular, several subsets of peers are selected to relay data packets generated at the node. Each data packet is associated with a specific subset of relay nodes by the first mapping. For each data packet, operation 804 identifies a predetermined number of first data packets of a first type previously generated by the node. These may be data packets already sent by the node to peers, or data packets previously generated but not yet relayed to the node's peers.

[0078] In operation 806, a list of relay node sets associated with the first data packet is retrieved. Each relay node set contains the neighboring nodes (peers) to which each of the first data packets is relayed (or assigned for relaying). In other words, the relay node set represents a subset of the peers of the nodes to which each individual data packet in the first data packet is assigned.

[0079] In operation 808, the first set of relay nodes is selected based on identifying a set of neighbor nodes that are different from the relay nodes in the list obtained in operation 806. For example, the first set of relay nodes may be selected by arbitrarily selecting two or more sets of neighbor nodes that are not included in the obtained list of relay node sets. Some implementations may impose a requirement that the selected first set is different from the relay node sets in lists obtained by two or more peers. That is, the upper limit may be set to the number of elements that belong to the intersection set between the selected first set of relay nodes and any one of the relay node sets in the obtained list.

[0080] Method 800 may be performed by a node after a single data packet has been generated at the node, or after a node has collected multiple generated data packets. In particular, the node may generate and store a first type of data packet over a period of time (similar to the RDR stage of the DMP) and determine a first mapping of the stored data packets to a set of relay nodes. In these cases, each data packet may be assigned to an arbitrarily selected subset of relay nodes, ensuring that no two such subsets are equal to each other.

[0081] The number of neighboring nodes selected to be included in the first set of relay nodes may be determined arbitrarily. In at least some implementations, the number of peers selected for the first set is limited according to the bandwidth requirements of the propagation node (e.g., the cumulative amount of input and output data within a fixed time frame). In particular, the number of peers selected for relaying locally generated transactions may be adjusted to resolve network load issues or to improve source obfuscation. For example, the number of peers included in the first set may be defined as follows: m(tx i )=m SM ±rnd(ξ SM ) Here, m SMrnd(ξ) is a normalized value representing the average number of peers selected for relaying in the source mixing subsystem. SM ) is 0 and ξ SM Represents a random integer between -1 and -1.

[0082] The selection of the first set of relay nodes can then be configured in a first mapping in relation to each data packet. In other words, the first mapping may indicate that a data packet is associated with (i.e., assigned to) the first set of relay nodes. In operation 810, the data packet is transmitted according to the determined first mapping.

[0083] <Relay Mixing> The relay mixing subsystem assumes that transactions received by a node should be relayed to a non-overlapping subset of the node's peers. Using the parameter λ to represent the number of elements belonging to the intersection set between relay peers selected for two different transactions received by the same node, the idea behind relay mixing can be understood as follows:

number

number

[0084] Alternatively, in other implementations, the parameter λ is a time-varying parameter updated using a unique system parameter, a specific time window, and information stored in the RDR table. t , or a parameter λ that changes over time for each peer, updated using information stored in a specific time window and RDR table. t i That's fine.

[0085] The number of transaction allocation combinations for a typical peer is as follows:

number

[0086] Set the maximum number of iterations and select the minimum transaction allocation by cross-peer; • Set a maximum number of iterations, but terminate the process early if a given threshold for cross-peer connections is reached; Set a maximum number of iterations, increase the value of λ if the requirement is not met, and resume processing; Set a maximum number of iterations, change the value of x if the requirement is not met, and resume processing; Set a maximum number of iterations, and if the requirement is not met, decrement the value of m and resume processing.

[0087] The maximum number of iterations is fixed within the time window ΔT. RM If this is used as a substitute, a different set of approaches can be considered.

[0088] The number of neighboring nodes selected to be included in a set of relay nodes may be determined arbitrarily. In at least some implementations, the number of peers selected for the set is limited according to the bandwidth requirements of the propagation node (e.g., the cumulative amount of input and output data within a fixed time frame). In particular, the number of peers selected for relaying locally generated transactions may be adjusted to resolve network load issues or to improve source obfuscation. For example, the number of peers included in the first set may be defined as follows: m(tx i )=m RM ±rnd(ξ RM ) Here, m RM rnd(ξ) is a normalized value representing the average number of peers selected for relaying in the source mixing subsystem. RM ) is 0 and ξ RM Represents a random integer between -1 and -1. In some embodiments, ξ SM and ξ RM They may have the same value.

[0089] Referring to Figure 10, an exemplary method 900 for relaying data packets received at nodes in the network is shown in flowchart form. Method 900 presents a technique for propagating data within the network according to a transaction allocation scheme that follows the rules of a relay mixing subsystem / discovery method. Method 900 is implemented by nodes in a blockchain network, such as network 100 in Figure 1. More specifically, Method 900 is performed by nodes that participate in the DMP and are configured to receive a first type of data packet (e.g., a transaction) for propagation to the rest of the network.

[0090] In operation 902, a client associated with a node receives at least one data packet of type 1. The data packet may include, for example, a blockchain transaction.

[0091] The node determines a second mapping of at least one received data packet to its neighboring nodes (i.e., peers). In particular, several subsets of peers are selected to relay data packets generated at the node. Each data packet is associated with a specific subset of relay nodes by the second mapping. For each data packet, operation 904 identifies a predetermined number of second data packets of the first type that have recently been received by the node. These may be data packets already sent by the node to a peer, or data packets that were previously received but have not yet been relayed to the node's peers.

[0092] In operation 906, a first allocation of the second data packet to a fixed set of neighboring nodes is determined. In particular, the first allocation is selected from one or more allocations of the second data packet to neighboring nodes that satisfy a predetermined condition. This operation corresponds to an iterative search for a suboptimal solution to the inequality (1) described above. That is, a unique allocation (e.g., an allocation with the fewest traversal peers) is determined among the allocations of data packets to relay nodes that satisfy (1). As captured by (1), the allocation of the second data packet to a fixed set of neighboring nodes satisfies a predetermined condition if, for any two of the second data packets, the number of neighboring nodes to which both of the second data packets are allocated (for relaying) is less than or equal to a predetermined threshold.

[0093] The unique assignment of the second data packet to the neighboring node identified in operation 906 can then be set in a second mapping. In other words, the second mapping may indicate the relay nodes to which each second data packet (i.e., the data packet received by a node from its peer) is assigned. In operation 908, at least one received data packet is relayed according to the determined second mapping.

[0094] Method 900 may be performed by a node after a single data packet has been received at the node, or after the node has collected multiple received data packets. In particular, the node may receive and store first type data packets over a period of time (similar to the RDR stage of the DMP) and determine the mapping of the stored data packets to a set of relay nodes. In these cases, each data packet may be assigned to an arbitrarily selected subset of relay nodes, ensuring that no two such subsets are equal to each other.

[0095] <Destination Mixing> The destination mixing discovery method captures the idea that a node's outbound connections should execute transactions relayed by different peers. This discovery method can be considered a special case of the relay mixing subsystem, because the latter involves generating a non-overlapping subset of peers for relaying from the same source peer. In method 900, destination mixing may be implemented by operation 906 ensuring that for any two of the first nodes (i.e., nodes from which a node receives data packets), the entire set of second data packets received from those two first nodes is allocated in the first allocation to at least two different neighboring nodes. For example, Figure 11 shows an example of destination mixing for node i. The destination mixing subsystem is such that node a has a given time window ΔT DM This ensures that node i does not receive two transactions that were relayed by the same node c. Therefore, only one of the two transactions received by node i from node c is relayed to node a.

[0096] In some implementations, destination mixing is performed with a time window ΔT DM Each can be enabled for different subsets of peers. For example, the subset can be parameter (m DM , δ DM , ξ DM ) may be allocated in the same manner as described for source mixing. This strategy may contribute to the decorrelation of source and destination for a given transaction.

[0097] <Arrival time mixing> The arrival time mixing discovery method implements delayed relay of data packets to help decorrelate source and destination information regarding data packet relay. (For example, at the RDR stage of DMP) For example, a time window ΔT DM Data packets (e.g., transactions) collected (or generated) within are relayed via ΔT i It may be scheduled at the end (RDR in Figure 12) i The arrival time mixing subsystem is RDR. i This only delays the relay. In some implementations, the relay of data packets is delayed by a multiple of qΔT. i For example, RDR j , RDR j+1 , RDR j+2 Delays of only a certain amount are permitted. Therefore, according to the arrival time mixing discovery method, the relaying of data packets received (or generated) by a node includes determining the next scheduling time for relaying received data packets to neighboring nodes, and relaying a predetermined amount of data packets after the next scheduled time for relaying. ΔT i All transactions collected within are ΔT i It is relayed via +qΔT. Or, ΔT i Each transaction j collected within is given ΔT i +q j It will be broadcast via ΔT.

[0098] In some cases, the random variable q may have the following negative exponential probability density function: pdf q (x) = c × e -(x+g)

[0099] Here, c and g are multiplication and addition coefficients, respectively.

[0100] <Source control> A malicious peer may attempt to discover patterns in i's local relay strategy by pushing the same data packet (or a set of data packets) multiple times to a given node i. For example, a malicious peer node may create two connections to i and monitor how i's input and output traffic are related. The source control subsystem is implemented by setting a specific threshold for the number of data packets that can be received from each peer. If a peer exceeds the threshold for a given data packet, its connection is closed permanently or temporarily. The number of instances in which a node receives a given data packet, such as a blockchain transaction, may be stored in an RDR table.

[0101] <Load balance> Load balancing may be used to periodically shuffle data packets already allocated for forwarding to peers by other subsystems. The purpose of the load balancing module is to average the forwarding distribution among peers to avoid traffic overload or a single point of failure in several peer connections. Two different approaches may be implemented for load balancing.

[0102] Each data packet j has the same weight w, regardless of their size (i.e., the number of inputs, the number of outputs, and the size of the unlock and lock scripts). j Having; Each data packet j has its own weight w, which is proportional to its own size [in bytes]. j It holds.

[0103] For example, in method 800, a second allocation of the second data packets to a fixed set of neighboring nodes may be determined, the second allocation being a reconfiguration of the first allocation taking into account traffic balance at the node's output interface. Cumulative value c i n is the number of data packets scheduled to be relayed, as follows: i For each peer i, the following is calculated:

number

[0104] Next, the data packets to be relayed are shuffled and the average value for each peer is calculated c * An iterative method is executed to obtain the result.

number

[0105] Various different discovery methods may be available to resolve this shuffling of data packets. For example, different priorities may be assigned to different subsystems to anticipate the forwarding of subsets of data packets or to improve load balancing of outgoing traffic. Furthermore, the operation of different subsystems may introduce data packet duplication or mismatched assignments, which must be resolved before forwarding is activated.

[0106] <Node bandwidth and DMP> A diffusion mixer protocol may be configured to take into account the available bandwidth of a network node to its neighbors, among the various links / channels of the network node. Various aspects of data packet transmission between network nodes, including transmission quality and timing, may depend on the available bandwidth capacity between nodes.

[0107] In the context of data packet propagation within a node network, it is desirable to strike a balance between the ability to enhance the anonymity of the source and destination of data packets relayed by network nodes and the efficient use of the available bandwidth resources of the network nodes. In particular, algorithms that allocate data relay to peers of network nodes (e.g., Diffusion Mixer Protocol) are advantageously mitigated by the resource constraints of the network nodes. For example, in some cases, various constraints may be imposed on one or more parameters of the data relay allocation algorithm (e.g., setting upper and / or lower limits) based on the resource limitations of the network nodes.

[0108] As an explanation, when a node sends a data packet to one or more of its peers, the node needs to consider the available bandwidth within its links to neighboring nodes so that the data packet is allocated in a sensible way for relaying to the node's peers. Techniques that improve the anonymity of the source of the relayed data can result in high bandwidth utilization. For example, if a network node selects a large number of entry nodes to relay a data packet, the network node's output link capacity may be reduced to undesirable levels. As another example, delaying the relay of one or more data packets to implement arrival time mixing (in RDR) can occupy inter-node channels beyond acceptable levels. Algorithms that allow parameter control depending on the resource constraints of the network nodes can achieve both improved data relay performance and network traffic management.

[0109] Referring to Figure 13, an exemplary process 1000 for propagating data packets within a network is shown. More specifically, process 1000 represents a technique for determining data relay allocation based on the bandwidth constraints of network nodes. Method 1000 is implemented by nodes in a blockchain network, such as network 100 in Figure 1. In particular, method 1000 is performed by nodes that participate in the DMP and receive a first type of data packet (e.g., a transaction) for propagation to the rest of the network.

[0110] In operation 1002, the node collects a set of first data packets for a first time period T. That is, the node accumulates first data packets over a fixed time period. The set includes at least one first data packet received from one or more peer nodes in the network. In a blockchain network, during a time period T, the node accumulates a set of transactions by monitoring the network for input transactions to be relayed. The length of the time period T may be predetermined.

[0111] In operation 1004, a node (or an entity other than a node) determines the available bandwidth among its links to several neighboring nodes. The node may determine the bandwidth and throughput within each of its links / channels to neighboring nodes. In particular, a numerical value or indicator of the available bandwidth within each of at least one of the node's links may be obtained. In some implementations, a value / indicator representing the total available bandwidth across all of the node's outbound links may be obtained. For example, a value / indicator representing the ratio of the node's links available to participate in process 1000 for propagating data packets may be derived.

[0112] Furthermore, a parameter may be determined that represents the desired allocation of node bandwidth for data relay (i.e., the Diffusion Mixer Protocol). For example, the parameter may represent the maximum amount of bandwidth that can be allocated. The value of the parameter may be set manually, for example, by a node, a set of nodes, and / or an entity controlling the network containing the nodes. Alternatively, as further detailed below, the value of the parameter may be automatically updated based on detected changes in the available bandwidth of the node.

[0113] In operation 1006, a mapping is determined that assigns each of the first data packets to one or more neighboring nodes for relaying. In other words, the relay assignment of data packets to the node's peers is derived. The mapping indicates the expected relay time for one or more of the first data packets collected by the node in operation 1002.

[0114] The forwarding allocation of the first data packet is determined for each first data packet, using the available bandwidth information (obtained in operation 1004) as the basis for the setting. At least one of the various parameters of data forwarding includes a first number of peer nodes to which the first data packet is allocated by mapping for forwarding, a first time length of delay when forwarding the first data packet to one or more peer nodes, and the number of hops from the network node to the first data packet. In other words, one or more of these parameters of data forwarding processing may be set or adjusted based on the available bandwidth of the node in the link between the node and its neighboring nodes.

[0115] In some implementations, information about the node's available bandwidth may be used to set parameters for one or more of the subsystems described above (e.g., source mixing, relay mixing, etc.), or for other discovery methods used to control the relay allocation of data packets to peer nodes.

[0116] As mentioned above, the number of peers selected for data packet forwarding in RDR may be limited as follows: m min ≤m max ≤m Here, m represents the total number of peers in the network. ψ∈[0,1] is a parameter indicating the available bandwidth, and ΔT is a fixed window (e.g., ΔT). RM ΔT SM Given an average number of μ data packets relayed and / or generated within the peers, the configuration set for the peer boundary is derived as follows: If ψ=1, then m max =m and m min =max(0,2μ-m max ) If ψ=0, then m max =1 and m min =0 In other words, μ is [m min ,m max This corresponds to the midpoint of ]. The minimum and maximum boundaries can be expressed as functions of ψ:

number

[0117] 2 μm max If ≤ 0, then m min It is set to 0. Typically, the larger the values ​​of ψ and m, the larger the range [m min ,m max This means that the more available bandwidth and peer nodes there are, the greater the flexibility in determining the number of peer nodes that should be configured to receive the first data packet.

[0118] In some implementations, the average μ may be modeled to vary as a function of time. The value of μ (for source mixing and relay mixing) may be modeled, for example, using a trigonometric function:

Number

[0119] The range of possible values of the number of peers selected to receive the relay of the first data packet (m(tx i )) can be further refined. For example, in the scenario of the source mixing subsystem: m(tx i ) = m SM ± rnd(ξ SM ) where m SM is a normalized value representing the average number of peers selected for relay in the source mixing subsystem, and rnd(ξ SM ) represents a random integer between 0 and ξ SM - 1. An exemplary probability distribution function of ξ SM is a discrete Gaussian distribution having 95% of the energy within the range [-ξ SM , ξ SM . A more general "skew normal distribution" can be characterized as follows by the probability density function PDF ξ :

Number

[0120] Values on the right side of the mean value may be prioritized to assist in the initial propagation of data packets within the network, so in the case of source mixing, skew can be useful to represent the asymmetry between both sides of the distribution. The function has the following mean μ ξ and variance σ 2 ξ :

Number

[0121] In the above equation, ω, ρ, and α represent the scale, position, and shape of the curve, respectively. Therefore, μ ξ and σ 2 ξ may be configured according to (1) the range [m min [[ID=1十一]], m max , and (2) the nominal value representing the average number of peers selected for relay, that is, μ SM (t). In some implementations, the following configuration may be appropriately used when defining the mean and variance: [Number]

[0122] The third equation can be selected to solve for the unknown variables ω, ρ, α. For example, the correlation between α and ψ may be expressed as follows: α = 8ψ - 4, or α = 8.6tanh(ψ - 0.5)

[0123] Another parameter that can be controlled based on the available bandwidth of the network node is the delay time during the relay of data packets. Delayed relay (i.e., transmitting the data packet after a predetermined time length after the expected time of relay indicated by the relay assignment / mapping) can help decorrelate the source and destination information regarding the data packet. For example, data packets collected or generated within the time window ΔT may be relayed with a delay equal to a multiple qΔT of ΔT. Here, q is a random variable. To balance between the degree of decorrelation and the degree of delay in the relay, the random variable q may have a negative exponential probability density function.

[0124] Generally, the length of the delay in the relay may be inversely proportional to the available bandwidth of the node. In particular, the lower the value of ψ, the longer the relay delay. This relationship can be expressed using the following equation: [Number] Here, n represents an estimate of the number of data packets received in the previous time window, and ΔT * ΔT represents the nominal time window, i.e., the lower limit of the delayed relay. * The value of may vary based on the average connection time or the centrality of the node within the network (i.e., the number of incoming connections to the node).

[0125] In operation 1008, the first data packets of the collected set are sent to neighboring nodes of the network node according to the mapping determined in operation 1006. In some implementations, only a subset of the collected first data packets are sent according to the relay assignment specified by the mapping.

[0126] Referring to Figure 14, another exemplary process 1100 for propagating data packets within a network is shown. Method 1100 is implemented by a node in a blockchain network, such as network 100 in Figure 1. In particular, method 1100 is performed by a node that participates in the DMP and receives a first data packet (e.g., a transaction) to propagate to the rest of the network.

[0127] Process 1100 introduces a technique to set the number of hops a first data packet will travel once it has been propagated by a network node. In operation 1102, a set of first data packets is collected, and in operation 1104, the available bandwidth of a node is determined within the node's links to neighboring nodes. Next, in operation 1106, a mapping of the first data packets collected by the node is determined, which assigns each of the first data packets to one or more neighboring nodes for relaying.

[0128] In operation 1108, for at least one first data packet selected from the set of first data packets, a first set of peer nodes to which the at least one first data packet is allocated for relaying is identified. This identification is made by referring to the mapping determined in operation 1104.

[0129] In operation 1110, a second subset of the first set is identified. Peer nodes in the second subset are designated to forward at least one first data packet to their neighboring nodes when they receive at least one first data packet from a network node. In other words, the second subset of peer nodes contributes to the propagation of at least one first data packet across the network by forwarding it to their peers. Once at least one first data packet is forwarded to a peer node in the second subset, the propagation of at least one first data packet continues to further nodes in the network. On the other hand, if at least one first data packet is forwarded to a peer node in the first set that is not included in the second subset, these peer nodes do not forward at least one first data packet to any of their neighboring nodes.

[0130] In operation 1112, for at least one first data packet, the node sends at least one first data packet to peer nodes included in the second subset. In operation 1114, for at least one first data packet, the node sends at least one modified version of the first data packet to peer nodes in the first set not included in the second subset. The modified data packet contains at least one first data packet modified to indicate that further forwarding of at least one first data packet to peer nodes is prohibited. In this way, a group of peer nodes (i.e., peers in the second subset) is configured to continue propagating at least one first data packet, while a different group of peer nodes (i.e., peers not included in the second subset) only receive at least one first data packet from the network node and do not forward it to their peers. By distinguishing further propagated data packets from data packets that travel only a single hop from the network node, it is possible to reduce the number of redundant forwardings of data packets in the data propagation scheme within the network node.

[0131] For example, if two nodes have the same set of peers, data packets forwarded to those two nodes are redundant if they are further propagated to their peers by both nodes, as this results in duplication of the data packets sent to those peers. Unnecessary consumption of network bandwidth can be reduced or suppressed by limiting the number of hops traveled by data packets that may already be destined for other identifiable nodes in the network.

[0132] Data packets forwarded to peers in the first set that are not included in the second subset may be marked to distinguish them from data packets that should be propagated further (i.e., forwarded to peers in the second subset). For example, an additional bit may be set in at least one first data packet forwarded to a peer not included in the second subset to indicate that further forwarding of that data packet to other nodes is prohibited.

[0133] In some implementations, at least one first data packet may be arbitrarily selected from a collected set of first data packets. Alternatively, at least one first data packet may be selected based on the decision that it has been previously sent by a network node to one or more peer nodes. As another example, at least one first data packet may be n 1hop The data packets relayed each time may be selected by randomly setting them. 1hop The value of depends on both m and ψ. In particular, generally, the higher the values ​​of m and ψ, the better n 1hop The correlation increases. For example, the correlation can be modeled by a quadratic function as follows: n 1hop =(m-1)ψ 2 +1

[0134] Referring to Figure 15, another exemplary process 1200 for propagating data packets within a network is shown. Method 1200 is implemented by a node in a blockchain network, such as network 100 in Figure 1. In particular, method 1200 is performed by a node that participates in the DMP and receives a first data packet (e.g., a transaction) to propagate to the rest of the network.

[0135] In operation 1202, the node collects the first set of data packets, and in operation 1204, it determines the available bandwidth within the node's link to neighboring nodes. Then, in operation 1206, the mapping / relay allocation of the data packets to peers is determined.

[0136] In operation 1208, a change in the available bandwidth of a network node is detected. The available bandwidth may increase or decrease depending on other communication activities of the network node. The change may be detected in real time by the network node, and in operation 1210, an updated mapping of the data packet for relaying to peer nodes is determined in real time based on the updated indication of the available bandwidth. In particular, one or more parameters of the mapping may be set based on the updated information regarding the available bandwidth. The coefficients include a first number of peer nodes to which the first data packet is allocated by the mapping for relaying, a first time length of delay when relaying the first data packet to one or more peer nodes, and the number of hops from the network node to the first data packet.

[0137] In operation 1212, the first data packet is sent to the network node's neighboring nodes based on the updated mapping / relay assignment.

[0138] Information regarding the available bandwidth of a network node may influence the decision of which spreading mode should be used during DMP. More specifically, a network node may decide whether to switch to RDR mode or standard spreading mode based on the currently available bandwidth in its links to its neighbors. Switching between spreading modes may occur if the processing overhead generated by RDR is very high, if the available bandwidth does not require network optimization, and the local system is configured to periodically alternate between the two spreading modes.

[0139] Referring to Figure 16, a simplified example of a participating node 1600 is shown in block diagram form. Node 1600 includes a processor 1602 which may include one or more microprocessors, application-specific integrated circuits (ASICs), microcontrollers, or similar computer processing units. Node 1600 further includes memory 1604 which may include permanent and non-permanent memory for storing values, variables, and, in some examples, processor-executable program instructions, and a network interface 1606 which provides network connectivity over a wired or wireless network.

[0140] Node 1600 includes a processor-executable blockchain application 1608 which includes processor-executable instructions that, when executed, cause processor 1602 to perform one or more of the functions or operations described in this specification.

[0141] Any module, routine, process, thread, application, or other software component implementing the apparatus and processing described herein, and the described methods / processes for constituting a blockchain node, may be implemented using standard computer programming techniques and languages. This application is not limited to specific processors, computer languages, computer programming practices, data structures, or other details of such implementations.

[0142] It should be noted that the embodiments described above are illustrative, not limiting, of the invention, and that those skilled in the art can devise many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference numerals in parentheses are not intended to limit the claims. The terms “comprising,” “comprises,” etc., do not preclude the existence of elements or steps other than those enumerated in any claim or throughout the specification. In this specification, “comprising” means “having or comprising,” and “comprises” means “comprises or comprising.” A single reference to an element does not preclude multiple references to that element, and vice versa. The invention can be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In an apparatus claim enumerating several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously. [Explanation of Symbols]

[0143] 100 Blockchain Networks 102 nodes

Claims

1. A method performed by a computer for propagating data packets within a network of nodes, A step of collecting a set of first data packets at a network node during a first time period, wherein the set includes at least one first data packet received from one or more first nodes in the network. The steps include determining the available bandwidth to multiple neighboring nodes connected to the network node within the link of the network node, A step of determining a relay assignment to assign each of the first data packets to one or more neighboring nodes for relaying, wherein the relay assignment indicates the expected relay time for each of the first data packets, and the step of determining the relay assignment includes using the available bandwidth as a basis for setting at least one parameter that controls the relay of the at least one first data packet to a plurality of neighboring nodes, wherein the at least one parameter includes the maximum amount of bandwidth that can be allocated to the network node. The steps include transmitting the first data packet from the set to the plurality of neighboring nodes in accordance with the relay assignment determined above, A method that includes this.

2. The method according to claim 1, wherein the step of determining the available bandwidth includes obtaining an indicator of available bandwidth in each of the links of the network node to the plurality of neighboring nodes.

3. The at least one parameter includes at least a first number of peer nodes to which the first data packet is allocated by the relay allocation for relaying, and the step of determining the relay allocation is: The steps include determining a range of possible values ​​for the number of peer nodes to which the first data packet is allocated by the relay allocation for relaying, based on the available bandwidth, The steps include selecting a number within the determined range in order to set it as the first number of peer nodes, The method according to claim 1, including the method described in claim 1.

4. For at least one first data packet selected from the set of first data packets, the following applies: A first set of peer nodes to which at least one first data packet is allocated for relaying, A second subset of the first set, the second subset comprising only peer nodes that, upon receiving the at least one first data packet from the network node, are designated to relay the at least one first data packet to their neighboring nodes. The method according to claim 1, further comprising the step of identifying.

5. The step of transmitting the first data packet from the set to the plurality of neighboring nodes in accordance with the relay assignment determined above is: With respect to the at least one first data packet, The steps include transmitting the at least one first data packet to the peer nodes included in the second subset, A step of sending a modified data packet to a peer node of the first set that is not included in the second subset, wherein the modified data packet includes the at least one first data packet that has been modified to indicate that further relaying of the at least one first data packet to the peer node is prohibited. The method according to claim 4, including the method described in claim 4.

6. The method according to claim 5, further comprising the step of setting additional bits in the at least one first data packet to indicate that further relaying of the at least one first data packet to a peer node is prohibited.

7. The method according to claim 4, wherein the at least one first data packet is arbitrarily selected from the set of first data packets.

8. The method according to claim 4, wherein the at least one first data packet is selected based on the determination that the at least one first data packet has been previously transmitted by the network node to one or more peer nodes.

9. The step of transmitting the first data packet from the set to the plurality of neighboring nodes in accordance with the relay assignment determined above is: For each of the one or more first data packets in the aforementioned set, The steps include determining the next scheduled time for relaying the first data packet to a neighboring node, The steps include relaying the first data packet at a time that is the first time length of the delay when relaying the first data packet to one or more peer nodes, after the next scheduled time for relaying the first data packet, The method according to claim 1, including the method described in claim 1.

10. The method according to claim 9, wherein the first time length is inversely proportional to the available bandwidth.

11. The network node is configured to generate at least one first data packet, and the step of determining the relay assignment is: For each of the at least one first data packets that are generated, The steps include identifying a predetermined number of first data packets previously generated by the network node, A step of obtaining a list of relay node sets associated with the previously generated first data packet, wherein the relay node set includes neighboring nodes to which each of the previously generated first data packets is relayed. The steps include selecting a first set of relay nodes based on identifying a set of neighboring nodes that is different from the relay node set in the acquired list, The method according to claim 1, including the method described in claim 1.

12. The method according to claim 11, wherein the step of selecting the first set of relay nodes includes the step of arbitrarily selecting two or more sets of neighboring nodes that are not included in the acquired list.

13. The further step includes detecting changes in the available bandwidth in the links of the network node to the plurality of neighboring nodes, The method according to claim 1, wherein the step of determining the relay allocation includes using an updated indication of available bandwidth as a basis for setting the at least one parameter for each of the first data packets.

14. A computer-implemented system that performs the method described in claim 1.

15. A non-temporary computer-readable medium storing instructions for causing a computer system to perform the method described in claim 1.

16. The aforementioned at least one parameter is as follows: The first data packet is allocated to a first number of peer nodes by the relay allocation for relaying purposes, The first time length of the delay when relaying the first data packet to one or more peer nodes, The number of hops for the first data packet from the network node, The method according to claim 1, comprising at least one of the following.

17. The method according to claim 1, wherein the at least one parameter includes a first time length of delay when relaying the first data packet to one or more peer nodes, the first time length being a predetermined time length after the expected time of relay.

18. The method according to claim 1, wherein the step of collecting the set of first data packets during the first time period at the network node is to allow the network node to accumulate only first data packets of a first type during the first time period and to suppress the transmission of any first data packets of the first type during the first time period.

Images