System and method for propagating data packets in network of node

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] The present invention relates generally to computer networks, and more particularly to methods and apparatus for propagating data among a network of nodes, electronic communications, and network technologies. The present invention is particularly suitable for use in conjunction with blockchain technology. In particular, the present invention relates to the secure transmission of data and the reduction of possible malicious events or 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. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referred to herein 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 within the scope of the present invention. The term "user" as used herein may refer to 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 distributed system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that 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, and these blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since origin. Transactions contain small programs, known as scripts, that embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be validated. Network nodes (miners) perform the work to ensure that invalid transactions are rejected from the network and that each transaction is valid. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing the UTXO's lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must be (i) validated 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) added to a new block constructed by miners, and (iii) mined, i.e., added to the public ledger of past transactions.

[0005] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to exploit the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such solutions could make their uses more diverse while taking advantage of the benefits of blockchain (e.g. permanence, tamper resistance of the record of events, decentralized processing, etc.).

[0006] One of the perceived advantages of blockchain technology such as Bitcoin is the anonymity of transactions. Bitcoin users' personal details are not officially and explicitly attached to their Bitcoin addresses, and the blockchain's Bitcoin ledger only contains public address information. However, since the blockchain is structured as a decentralized peer-to-peer network operating on the Internet, transaction anonymity is compromised by attacks that use Internet Protocol (IP) address information to link users to network activity. To illustrate, a de-anonymization attack such as IP traffic analysis performed on a blockchain-based network allows an interested third party to monitor transactions submitted to the network by users and use publicly available information to link transactions to their source, for example by linking users' public keys to their IP addresses.

[0007] Traffic analysis is especially 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 validates the transaction and later transmits it to peer nodes. In the Bitcoin protocol, a node sends an "INV" message containing a list of transactions to a peer node and receives a "GETDATA" response message selecting any subset of the transactions advertised in the "INV" message. The node then transmits the requested transactions to the peer node. This process is performed for each peer node to which the node is connected. An attacker can intercept and analyze the data transmitted as the transaction propagates through the network, ultimately obtaining information that can be used to link the source and destination of a transaction.

[0008] It would be desirable to provide techniques for propagating transactions in a blockchain-based network that can reduce the likelihood of compromising network anonymity through traffic analysis or other types of de-anonymization attacks, and more generally, to provide techniques for relaying data between nodes of a peer-to-peer network to reduce vulnerability to de-anonymization attacks.

[0009] Such a solution has been devised here.

[0010] Therefore, according to the present invention there is provided a method and apparatus as defined in the accompanying claims. Summary of the Invention

[0011] The present invention may provide a computer-implemented method for propagating data packets in a network of nodes, the method comprising: collecting, at a network node, a set of first data packets during a first time period, said set including at least one first data packet received from one or more first nodes in the network; determining available bandwidth among links of the network node to a plurality of neighboring nodes connected to the network node; determining a mapping that assigns each of the first data packets to one or more neighboring nodes for relaying, the mapping indicating an expected time for relaying each of the first data packets. a first number of peer nodes to which the first data packet is assigned by the mapping for relaying; a first amount of delay in relaying the first data packet to one or more peer nodes; the number of hops of the first data packet from the network node; using the updated indication of available bandwidth as a basis for setting at least one of the plurality of neighboring nodes. The method may further include transmitting the first data packet of the set to the plurality of neighboring nodes in accordance with the determined mapping.

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

[0013] In some implementations, determining the mapping comprises: determining a range of possible values ​​for a number of peer nodes to which the first data packet is assigned for relaying by the mapping based on the available bandwidth; and selecting a number within the determined range for configuration as the first number of peer nodes.

[0014] In some implementations, the method includes, for at least one first data packet selected from the set of first data packets, determining: a first set of peer nodes to which the at least one first data packet is assigned for relay; a second subset of the first set, the second subset including only peer nodes designated to relay the at least one first data packet to their neighboring nodes upon receiving the at least one first data packet from the network node; The method may further include identifying the

[0015] In some implementations, transmitting the first data packet of the set to the neighboring nodes in accordance with the determined mapping comprises: For the at least one first data packet, transmitting said at least one first data packet to peer nodes included in said second subset; sending a modified data packet to peer nodes not included in the second subset, the modified data packet including the at least one first data packet modified to indicate that further relaying of the at least one first data packet to peer nodes is prohibited.

[0016] In some implementations, the method may further include setting an additional bit 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 a determination that the at least one first data packet was previously transmitted by the network node to one or more peer nodes.

[0019] In some implementations, transmitting the first data packet of the set to the neighboring nodes in accordance with the determined mapping comprises: For each of one or more first data packets of the set, determining a next scheduled time for relaying the first data packet to a neighboring node; relaying the first data packet at a time that is the first length of time after the next scheduled time for relaying the first data packet.

[0020] In some implementations, the first amount of time 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 comprises: For each of the at least one generated first data packet, identifying a predetermined number of first data packets previously generated by the network node; obtaining a list of a relay node set associated with the previously generated first data packet, the relay node set including neighboring nodes through which the previously generated first data packet is respectively relayed; and selecting a first set of relay nodes based on identifying a set of neighboring nodes in the obtained list that is different from the set of relay nodes.

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

[0023] In some implementations, the method may further include detecting a change in the available bandwidth in a link of the network node to the plurality of neighboring nodes; The step of determining a mapping comprises, for each of the first data packets, determining: a first number of peer nodes to which the first data packet is assigned by the mapping for relaying; a first amount of delay in relaying the first data packet to one or more peer nodes; the number of hops of the first data packet from the network node; using the updated indication of available bandwidth as a basis for setting at least one of

[0024] The present invention may provide a computer-implemented system for carrying out the methods described above or elsewhere herein.

[0025] The present invention may provide a non-transitory computer readable storage medium having stored thereon instructions for adapting a computer system to perform a method as described above or otherwise herein.

[0026] This application provides techniques for managing bandwidth during data propagation in a network of nodes. Relaying of data packets by a node to its peers can be controlled to take into account bandwidth availability in the node's links to its neighboring nodes. Thus, a node may be able to adapt in real time to changes in its available bandwidth and update its data relay allocations accordingly. The techniques and heuristics described herein result in a reduction of redundant relays in the data propagation process, resulting in improved utilization of network traffic and inter-node bandwidth.

[0027] The present application also describes a solution for providing node-level anonymity in a network. More specifically, the method and system described herein help to obfuscate the function of a node in a data propagation manner in a network. Even if an attacker monitors the inter-node traffic in the network or tries to gain access to a particular node's neighbors, the method of the present invention makes it difficult for such an attacker to determine whether a particular node is a source or relay node of a data packet propagating in the network. By obfuscating the function / role of a node in a blockchain network, the effectiveness of de-anonymization attacks on the network can be reduced and the security of data transmission on the blockchain can be improved.

[0028] Furthermore, the techniques of the present application allow a node to manage the bandwidth utilization of its links to neighboring nodes while helping to maintain the anonymity of the source and destination of data packets relayed by the node. By taking into account the constraints on the nodes' resources (e.g., bandwidth), a more realistic and practical scheme for data propagation is obtained. The techniques also provide the entities controlling the nodes of the network with the ability to configure the parameters of the data propagation protocol as required according to their preferences and needs.

[0029] Many of the example implementations described herein make specific reference 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 disclosed herein may be suitable for use in propagating a variety of different types of data between nodes of a peer-to-peer network. [Brief description of the drawings]

[0030] Any feature described in relation to one aspect or embodiment of the invention may be used in relation to one or more other aspects / embodiments. The above-mentioned and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein. Embodiments of the invention are described below, by way of example only, and with reference to the accompanying drawings, in which: [Figure 1] 1 illustrates an exemplary network related to a blockchain. [Diagram 2] 1 illustrates a schematic diagram of an exemplary blockchain node having an input buffer and an output buffer. [Diagram 3] 1 is a schematic diagram of Diffusion Mixer Protocol (DMP), a protocol for propagating transactions in an exemplary network of nodes. [Figure 4] 1 shows an example of transaction relay in a network of nodes conforming to DMP. [Diagram 5] 1 illustrates, in flowchart form, an exemplary process for propagating data packets within a blockchain network conforming to a DMP. [Figure 6] 1 illustrates, in flowchart form, another exemplary process for propagating data packets within a blockchain network conforming to a DMP. [Figure 7] 1 illustrates, in flowchart form, another exemplary process for propagating data packets within a blockchain network conforming to a DMP. [Figure 8] 1 illustrates, in flowchart form, an example process for transmitting a data packet generated or received by a node in a blockchain network. [Figure 9] 1 illustrates, in flowchart form, an example process for transmitting a data packet generated by a node in a blockchain network. [Figure 10] 1 illustrates, in flowchart form, an exemplary process for relaying received data packets at a node in a blockchain network. [Figure 11]1 illustrates an example of destination mixing when propagating a data packet within a network of nodes. [Figure 12] 1 illustrates an example of delayed relay of a data packet within a network of nodes. [Figure 13] 1 illustrates, in flow chart form, an exemplary process for determining data relay allocations based on node bandwidth constraints. [Figure 14] 1 illustrates, in flow chart form, another example process for determining data relay allocations based on node bandwidth constraints. [Figure 15] 1 illustrates, in flow chart form, an exemplary process for updating data relay allocations based on changes in node bandwidth constraints. [Figure 16] 1 illustrates an exemplary blockchain node in block diagram form. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] Referring first to FIG. 1, FIG. 1 illustrates in block diagram form an example network related to a blockchain, which may be referred to herein as a blockchain network 100. The blockchain network 100 is a peer-to-peer open member network that anyone may join without an invitation or consent from other members. Distributed electronic devices running an instance of a blockchain protocol operating on the blockchain network 100 may participate in the 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.

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

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

[0034] Nodes 102 maintain a global ledger of all transactions on the blockchain. Transactions are grouped into blocks, with each block containing a hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 102 may store a full or partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102 to maintain the validity of the global ledger. The details of the implementation and operation of a blockchain network, such as one that uses the Bitcoin protocol, are 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 output is accessible. A transaction's output may be an 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 then reference that address as an input in order to use or disperse the value.

[0036] Nodes 102 can perform many 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 (spent or unspent) in the public ledger. A "lightweight node" (or SPV) maintains a subset of the blockchain and can verify transactions using "simplified payment verification" techniques. Lightweight nodes only download block headers, not the transactions within each block. These nodes therefore rely on peers to verify their transactions. A "mining node" is a full or lightweight node that is responsible for verifying transactions and generating new blocks on the blockchain. A "wallet node" is typically a lightweight node that handles wallet services for users. Nodes 102 communicate with each other using a connection-oriented protocol 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, transmitting one or more inventory objects known to the sending node. If the peer relies on a "GETDATA" message, i.e. a complete transaction request, the transaction is transmitted using a "TRANSACTION" message. A node receiving a transaction forwards it to its peers in the same manner if it is a valid transaction.

[0038] Referring to FIG. 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, referenced as intA, intB, intC, intD, etc. The input buffer 202 represents incoming transactions from various peer nodes. The output buffer 204 represents outgoing network packets corresponding to transactions for transmission to peer nodes via their respective interfaces. The network packets are sent and received sequentially at the application level according to primitives provided by the operating system of the node 200. Assuming that transaction x fits into a single Ethernet / IP packet, sending the transaction x to m peers requires the buffering of m different outgoing network packets. Both the incoming and outgoing network packets contain, among other information, 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 a transaction message through the network. Generally, when a client generates a transaction, it is placed in the output buffer 204. The transaction may or may not be forwarded to peers immediately. In the current implementation of the Bitcoin network, transactions are propagated by a mechanism known as "diffusion propagation", whereby each transaction source sends the transaction to itself and its neighbors with an independent exponential delay. The delay in propagation is random, which helps introduce uncertainty into the time estimates by a malicious attacker. Once a peer receives a particular transaction, it may not 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 a transaction through the network is symmetric. This means that a forwarding node does not use information about the IP addresses of neighboring nodes to influence the transaction broadcast. For example, in a "standard" diffusion process (used in the Bitcoin protocol), all peers of the broadcasting node receive the same transaction, and only one transaction is relayed at a time per peer at each relay instance. This symmetric "spreading" property can be exploited by malicious third parties with knowledge of the network's peer-to-peer graph structure in conducting deanonymization attacks.

[0040] The present disclosure provides an alternative technique for transaction relaying on a blockchain network to improve protection against traffic analysis attacks. More specifically, the proposed relaying protocol may be used to disguise, hide, or obfuscate connections between source nodes of transactions and their IP addresses.

[0041] A transaction relay protocol, Diffusion Mixer Protocol (DMP), is proposed. MDP includes two independent diffusion phases. The first phase (random differential relay, or RDR) allows mixing of relayed transactions and obfuscating transaction sources. During the random differential relay phase, each node receives and collects multiple transactions from its peers, waiting a predefined amount of time before broadcasting the transactions to the network. The node then creates outgoing connections to its "entry nodes" and sends different transactions with approximately the same timestamp to an arbitrarily (e.g., randomly) selected subset of these entry nodes. A node's entry nodes are the neighbors to which a direct outgoing connection from the node can be established. The randomness in the selection of entry nodes and the diversity of relayed transactions can make it more difficult for an attacker to reconstruct the network topology.

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

[0043] Of note, in a network of nodes such as a blockchain network, one or more of the nodes may be capable of implementing a DMP. Specifically, one or more of the nodes of the network may be capable of relaying their received data packets to their entry nodes by participating in the DMP. Participating nodes may, for example, select between an RDR process and a standard diffusion process for propagating a particular data packet. A node of the network may choose to participate in the DMP and participate in the protocol in a distributed manner or through inclusion in a group of participating nodes configured by a central station. 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 relaying 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 edges represent links between the nodes. For purposes of illustration, we assume that it is possible to send or receive a single bit at a time per link.

[0045] In this example network 300, each node maintains a set of unconfirmed transactions, so when a node receives a new transaction, it is propagated through the network to all other nodes. Each node validates the new transaction, stores it in their respective local set, and forwards the new transaction to any peer nodes that do not already have the new transaction. Due to the peer-to-peer nature of the blockchain network 300, not all nodes receive the new transaction at the same time. This means that it takes some time for the new transaction to reach all nodes in the network 300.

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

[0047] Entry nodes relay received transactions to their own peers. For example, nodes 310b and 310d forward transactions Tx2 and Tx1, respectively, 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 spreading as its spreading mode. As shown in FIG. 3, node 320 forwards the same transaction Tx1 to all its entry nodes, namely 320a, 320b, 320c, 320d, and 320e.

[0048] 5, an exemplary method 500 for propagating data packets in a network during the RDR stage of a DMP is illustrated in flow chart form. The method 500 is implemented by a node of a blockchain network, such as the network 100. A node, in this context, may be understood to represent a mining node, a full node, a validator node, or any other type of individual blockchain node in a blockchain network. A node is a computing device having a network connection, computational resources, and running software that implements a blockchain protocol.

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

[0050] In operation 504, the 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 the first type over the time period. The set includes at least one generated data packet and at least one data packet of the first type 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. In a blockchain network, during the time period T, the node accumulates a set of transactions by monitoring the network for incoming transactions to be relayed. The time period length T may be predefined. In some example implementations, the time length may vary based on parameters such as the average connection time, the average number of transactions received per unit time, or the centrality of the node in the network (i.e., the number of incoming connections to the node). During the time period T, the node may only be allowed to accumulate data packets of the first type and may therefore be restrained from transmitting any data packets of the first type during the time period T.

[0051] At operation 506, the node randomly selects a subset of its entry nodes to which the different sets of collected data packets are forwarded. More specifically, for each data packet in the set of collected data packets, the node randomly selects two or more of its entry nodes (i.e., neighboring nodes to which the node has outgoing connections) and assigns the data packet to the selected entry nodes. For example, the entry nodes may be selected randomly. In some implementations, the node may query the network to obtain fresh addresses of its peers. In the Bitcoin network, the node may query one or more database source names (DSNs) embedded in Bitcoin Core, BitcoinJ, or other blockchain protocols and maintained by Bitcoin (or other blockchain) community members. In response, the node obtains one or more DSN records indicating the IP addresses of available full nodes that accept incoming connections. A decentralized version of peer discovery may be implemented by having peers send "ADDR" messages 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 assignment of each collected data packet to the entry node to which the data packet should be relayed. FIG. 4 illustrates an example of a source node 410's transaction relaying in the RDR phase of a DMP in a blockchain network. Table 1 illustrates an example assignment of collected transactions Tx1-Tx5 to entry nodes of the source node 410. The entry nodes are shown as nodes A, B, C, D, E, F, G, and H. As shown in FIG. 4 and Table 1, the 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 at the same time. More generally, in the RDR phase, multiple data packets can be relayed by a forwarding node to the same peer node at the same time. Not all entry nodes necessarily receive transactions from the source node 410 in a given instance of the DMP. In the example of Table 1, entry nodes C and G do not receive transactions from source node 410. Table 1 [Table 1]

[0053] Referring again to FIG. 5, for each collected data packet, in operation 508, the node transmits the data packet to each of the (arbitrarily or randomly) selected entry nodes. Each selected entry node is configured to relay the data packet to one or more second nodes (e.g., peers of the entry node) in the network using a data propagation mode randomly selected for that entry node. That is, 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 example transaction of FIG. 4, each of transactions Tx1-Tx5 is forwarded to the entry node to which the transaction is assigned.

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

[0055] In some implementations, the random selection by the entry node of the spreading mode 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, for example, using SHA-256. The entry node may then check the hash value and obtain the spreading mode based on a predefined rule associated with the hash value (e.g., if the last character of the hash is a number, select RDR as the spreading mode). Alternatively or additionally, the selection of the spreading mode may be performed using any randomization process (e.g., a random number generator). Here, depending on factors such as the number of input and / or output connections, the average number of data packets received per unit time, etc., the probability of selecting one of the modes may be greater than the probability of selecting the other of the modes.

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

[0057] The method 500 of FIG. 5 is implemented by a node that generates its own first type of data packet. In particular, a node that participates in a DMP and generates data packets for propagation to the rest of the network executes the method 500. FIG. 6 illustrates an exemplary process performed by a relay node, or a node that forwards or relays data packets generated by different nodes. That is, a relay node is a node that does not generate data to be forwarded during the relay of a particular data packet, but instead provides a "relay" function for the data packet. In operation 550, the relay node independently selects its data propagation mode. The relay node may, for example, select between an RDR mode and a standard spreading mode. If the 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 of FIG. 6, the selection of the propagation mode is made between two possible options, this example is not limited, and in other examples, there may be more than two 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 FIG.

[0058] 7, an example process 600 for propagating data packets within a network is illustrated in flow chart form. The 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. At operation 608, the node determines whether a trigger condition is met before transmitting the data packets collected at operation 610 to its assigned entry node. In particular, the transmission of the data packets is performed in response to detecting that the appropriate trigger condition is met. When the trigger condition is not met, the node continues to collect the first type of data packets without relaying any of the data packets to its entry / peer node.

[0060] The trigger condition may be used to instruct the 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, sufficiency may be determined based on a predefined threshold. For example, by collecting multiple input data packets before simultaneously propagating them to peer nodes in the network, an attacker monitoring relayed traffic originating from the node cannot easily identify the node as a legitimate source of relayed data packets.

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

[0062] In some implementations, the trigger condition may be the end of a predefined period from the time of receipt of a first data packet of at least one incoming data packet of a first type from a peer of the node. That is, the node may be designed to monitor and collect incoming data packets for a predefined period of time starting from when the first data packet of such incoming data packets is received. This condition is useful when trying to ensure that more data packets, either generated by the node itself or received from other peers, are collected before broadcasting them 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 a first time period. In particular, the node may be designed to monitor and collect incoming data packets until the end of the first time period or until a predefined threshold number of data packets has been collected by the node, whichever occurs first.

[0064] <Random Differential Relay (RDR) Discovery Method> As mentioned above, random difference relaying represents a departure from the "standard diffusion" protocol for the propagation of transactions in a network of nodes. When implementing RDR, a propagating node simultaneously relays different transactions to a randomly selected subset of entry nodes. The propagating node may generate a data structure such as that 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 that relays data packets to its payers may maintain its own internal routing data structure that specifies the type of relaying to be performed for each of multiple data packets collected (i.e., received or locally generated) by the node.

[0065] In the context of the Diffusion Mixer Protocol proposed herein, each node in a blockchain network that implements RDR may independently build its own routing data structure, or "RDR table." The RDR table defines the transaction allocation scheme for each node employing the RDR protocol. That is, the RDR table of each individual node is used to manage which transactions should be relayed to which peers and when. The RDR table is used to manage the time for which transactions are relayed to which peers over a given amount of time ΔT RDR The RDR table may track all transactions received or generated during a given period, and the source peers of the transactions. The RDR table may include additional information such as the arrival time of the first instance of the transaction (the "ToA timestamp"), the time the transaction was selected to relay (the "ToR timestamp"), and / or a counter of the number of instances of the same transaction received by the node. An exemplary 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, transactions received or generated) 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 the transaction allocations specified in the RDR tables. The policies contained in these subsystems can help improve transaction source obfuscation and balance the network traffic generated by the relaying activities 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 provide optimal allocation of network resources.

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

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

[0069] At operation 704, the 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 the first type over the time period. The set includes at least one generated data packet and at least one data packet of the first type 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, a mapping of the collected set of data packets to a number of neighboring nodes connected to the node is determined. The mapping indicates the expected time of relay of each data packet of the set to the neighboring node. This "mapping" is used to configure the individual local RDR table of the node of the network. One or more of the subsystems / heuristics described in this disclosure may contribute (partially or independently) to the configuration of the RDR table. In particular, one or more different sub-mappings may be applied when determining the mapping of the collected data packets to the neighboring nodes. The sub-mappings may be of at least two different types. A first type of sub-mapping assigns any two data packets having the same source (i.e., the generating node) to different subsets of the neighboring nodes for relaying. The "source mixing" and "relay mixing" subsystems described in further detail below are examples of this first type of sub-mapping. A second type of sub-mapping assigns different expected times of relaying to any two data packets generated at the node or received by the node from a peer node in the same time interval. The "arrival-time mixing" subsystem is an example of this second kind of sub-mapping.

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

[0072] It is understood that each subsystem may independently implement an RDR table to update the transaction allocations defined in the RDR table, i.e., each subsystem may employ the RDR table separately, independent of the other subsystems, and thus each subsystem may provide different methods of allocating transactions to relay nodes, and thus different techniques for propagating transactions.

[0073] <Source mixing> The principle underlying the source mixing subsystem is that transactions generated locally at a node should be sent to a non-overlapping subset of peers. To illustrate, consider a node x that generates two transactions tx i and tx i+1 , the set of peers selected to relay these transactions is S(tx i ) and S(tx i+1 ), and S(tx i ) ≠ S(tx i+1 ) is satisfied.

[0074] That is, the sets of peers of two subsequent transactions differ by at least one peer. This inequality can help complicate any malicious search for patterns of initial relaying of transactions generated at a node. This concept can be expressed as follows: SM This can be extended to the following degrees of source mixing: S(tx i+a ) ≠ S(tx i+b ), ∀(a,b)∈[0,δ SM -1], a ≠ b

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

[0076] At operation 802, a client associated with the node generates at least one data packet of a first type. 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, a subset of the peers is selected to relay the data packet generated at the node. Each data packet is associated with a particular subset of the relay nodes by the first mapping. For each data packet, a predetermined number of first data packets of a first type previously generated by the node are identified in operation 804. These may be data packets already sent by the node to a peer or data packets previously generated but not yet relayed to the node's peer.

[0078] At operation 806, a list of relay node sets associated with the first data packet is obtained. The relay node set includes neighboring nodes (peers) to which the first data packet is respectively relayed (or assigned for relaying). That is, the relay node set indicates a subset of the peers of the node to which each of the first data packets is assigned.

[0079] At operation 808, the first set of relay nodes is selected based on identifying a set of neighboring nodes that are different from the relay nodes in the list obtained at operation 806. For example, the first set of relay nodes may be selected by arbitrarily selecting a set of two or more neighboring nodes that are not included in the obtained list of relay node sets. In some implementations, a requirement may be imposed that the selected first set be different from the relay node sets in the lists obtained by two or more peers. That is, an upper limit may be set on 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] The method 800 may be performed by a node after a single data packet is generated at the node, or after the node collects multiple generated data packets. In particular, the node may generate and accumulate a first type of data packets over a period of time (similar to the RDR phase of a DMP) and determine a first mapping of the accumulated data packets to a set of relay nodes. In these cases, the data packets may be assigned to an arbitrarily selected subset of the relay nodes, respectively, 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 propagating 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 solve network load issues or improve source obfuscation. For example, the number of peers included in the first set may be defined by: m(tx i )=m SM ±rnd(ξ SM ) where m SMis a normalized value that represents the average number of peers selected for relaying in the source mixing subsystem, and rnd(ξ SM ) is 0 and ξ SM Represents a random integer between -1 and

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

[0083] <Broadcast mixing> The relay mixing subsystem is premised on the notion that a transaction 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 that belong to the intersection set between the relay peers selected for two different transactions received by the same node, the idea behind relay mixing can be captured as follows:

number

number

[0084] Alternatively, in other implementations, the parameter λ is a time-varying parameter λ that is updated using unique system parameters, specific time windows, and information stored in the RDR table. t , or a time-varying parameter λ per peer that is updated using a particular time window and the information stored in the RDR table. t i , may be.

[0085] The number of combinations of transaction allocations for a general peer is:

number

[0086] · Set the maximum number of iterations and select transaction allocation with the minimum number of traversal peers; · Set a maximum number of iterations, but abort the process early if a given threshold of traversal peers is reached; · Set a maximum number of iterations and increase the value of λ and restart the process if the requirement is not met; · Set a maximum number of iterations and if the requirement is not met, change the value of x and restart the process; Set a maximum number of iterations and if the requirement is not met, decrease the value of m and restart the process.

[0087] The maximum number of iterations is determined by a fixed time window ΔT RM If ,is substituted by ,another set of approaches is possible.

[0088] The number of neighboring nodes selected to be included in the 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 propagating 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 solve network load issues or improve source obfuscation. For example, the number of peers included in the first set may be defined by: m(tx i )=m RM ±rnd(ξ RM ) where m RM is a normalized value that represents the average number of peers selected for relaying in the source mixing subsystem, and rnd(ξ RM ) is 0 and ξ RM represents a random integer between ξ and −1. SM and ξ RM may have the same value.

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

[0090] At operation 902, a client associated with the node receives at least one data packet of a first type. 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, a plurality of subsets of peers are selected to relay data packets generated at the node. Each data packet is associated with a particular subset of relay nodes by the second mapping. For each data packet, a predetermined number of second data packets of the first type that have been recently received by the node are identified in operation 904. These may be data packets already sent by the node to a peer or data packets previously received but not yet relayed to the node's peer.

[0092] In operation 906, a first allocation of the second data packets 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 packets to neighboring nodes that satisfy a predetermined condition. This operation corresponds to an iterative search for a suboptimal solution to inequality (1) above. That is, among the allocations of the data packets to relay nodes that satisfy (1), a unique allocation (e.g., an allocation with the least traversal peers) is determined. As captured by (1), an allocation of the second data packets to a fixed set of neighboring nodes satisfies the 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 assigned (for relaying) is less than or equal to a predetermined threshold.

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

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

[0095] <Destination mixing> The destination mixing heuristic captures the idea that outgoing connections of a node should perform transactions that are relayed by different peers. This heuristic is considered a special case of the relay mixing subsystem, since the latter involves the generation of non-overlapping subsets of peers for relaying from the same source peer. In the method 900, destination mixing may be implemented in operation 906 by ensuring that for any two of the first nodes (i.e., nodes from which the node receives data packets), the set of all second data packets received from the two first nodes is assigned to at least two different neighboring nodes in the first allocation. For example, FIG. 11 shows an example of destination mixing for node i. The destination mixing subsystem determines whether node a should receive a set of second data packets from a given time window ΔT DM ,ensuring that node i does not receive two transactions relayed by the same node c.,Therefore, only one of the two transactions received at node i from,node c,is relayed to node a.

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

[0097] <Arrival time mixing> The arrival time mixing heuristic implements delayed relaying of data packets to help de-correlate source and destination information for data packet relaying (e.g., in the RDR stage of the DMP). For example, a time window ΔT DM Data packets (e.g., transactions) collected (or generated) in i (RDR in FIG. 12) i The arrival time mixing subsystem is the RDR i In some implementations, the relaying of a data packet is delayed by a factor qΔT i , for example R.D.R. j , R.D.R. j+1 , R.D.R. j+2 , etc. Thus, according to the arrival time mixing heuristic, relaying a data packet received (or generated) by a node includes determining the next scheduled time for relaying the received data packet to a neighboring node, and relaying the data packet a predetermined amount of time after the next scheduled time for relaying. i All transactions collected within ΔT i +qΔT or ΔT i Each transaction j collected in i +q j It is relayed at ΔT.

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

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

[0100] <Source Control> A malicious peer may try to push the same data packet (or a group of data packets) multiple times to a given node i, trying to discover patterns in i's local relaying strategy. For example, a malicious peer node may create two connections to i and monitor how i's input and output traffic correlates. The source control subsystem is implemented by setting a certain 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, the connection is closed, either permanently or temporarily. The number of instances that a node receives a given data packet, such as a blockchain transaction, may be stored in the RDR table.

[0101] <Load balance> Load balancing may be used to periodically perform a shuffling of data packets already assigned for relay to peers by other subsystems. The purpose of the load balancing module is to average the relay distribution among peers in order to avoid traffic overload or single points of failure in some peer connections. Two different approaches for load balancing may be implemented:

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

[0103] For example, in the method 800, a second allocation of second data packets to a fixed set of neighboring nodes may be determined, the second allocation being a rearrangement of the first allocation that takes into account the balancing of traffic at the output interfaces of the nodes. i is the number of data packets scheduled for relaying, n, as follows: i For each peer i, it is calculated as:

number

[0104] Next, we shuffle the data packets to be relayed and calculate the average value c * To obtain, an iterative method is performed.

number

[0105] A variety of different heuristics may be available to resolve this shuffling of data packets. For example, different priorities may be assigned to different subsystems to anticipate relaying of a subset of data packets or to improve load balancing of outgoing traffic. Furthermore, the execution of different subsystems may introduce duplication or inconsistent allocation of data packets, which needs to be resolved before activation of relaying.

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

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

[0108] By way of explanation, when a node transmits a data packet to one or more of its peers, the node needs to consider the available bandwidth in its links to neighboring nodes so that the data packet is allocated in a wise manner for relay to the node's peers. Techniques that improve the anonymity of the source of the relayed data may result in high bandwidth utilization. For example, if a network node selects a large number of entry nodes to relay a data packet, the output link capacity of the network node may decrease to an undesirable level. As another example, delaying the relay of one or more data packets to perform arrival time mixing (in the RDR) may occupy the inter-node channel beyond an acceptable level. Algorithms that allow control of parameters 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 in a network is shown. More specifically, the process 1000 represents a technique for determining data relay allocation based on bandwidth constraints of network nodes. The method 1000 may be implemented by nodes of a blockchain network, such as the network 100 of Figure 1. In particular, the method 1000 may be performed by a node that participates in a DMP and receives a first type of data packet (e.g., a transaction) for propagation to the rest of the network.

[0110] At operation 1002, a 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 the time period T, the node accumulates a set of transactions by monitoring the network for incoming transactions to be relayed. The time period length T may be predetermined.

[0111] At operation 1004, the node (or an entity different from the node) determines the available bandwidth in its links to its multiple neighboring nodes. The node may determine the bandwidth and throughput in each of its links / channels to the neighboring nodes. In particular, a numerical value or indicator of the available bandwidth in each of the node's at least one link may be obtained. In some implementations, a value / indicator may be obtained that represents the total available bandwidth in all of the node's outgoing links. For example, a value / indicator may be derived that represents the proportion of the node's links that are available to participate in the process 1000 of propagating data packets.

[0112] Additionally, a parameter may be determined that represents a desired allocation of the node's bandwidth for data relay (i.e., a Diffusion Mixer Protocol). For example, the parameter may represent a maximum amount of allocable bandwidth. The value of the parameter may be set manually, for example, by an entity that controls the node, a collection of nodes, and / or a network that includes the node. Alternatively, as described in more detail below, the value of the parameter may be automatically updated based on detected changes in the node's available bandwidth.

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

[0114] A relay assignment for the first data packet is determined for each first data packet using the available bandwidth information (obtained in operation 1004) as a basis for setting. At least one of various parameters of the data relaying includes a first number of peer nodes to which the first data packet is assigned for relaying by the mapping, a first length of delay in relaying the first data packet to one or more peer nodes, and a number of hops from the network node of the first data packet. That is, one or more of these parameters of the data relaying process may be set or adjusted based on the available bandwidth of the node in its links to neighboring nodes.

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

[0116] As mentioned above, the number of peers selected for data packet relay in the RDR may be limited as follows: m min ≦m max ≦m Here, m represents the total number of peers of the network node. The parameter ψ ∈ [0,1] represents the indication of available bandwidth, and the fixed window (e.g., ΔT RM , ΔT SM Given the average number μ of data packets relayed and / or generated in a network, a configuration set for bounds on the number of peers 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 ]. The minimum and maximum bounds can be expressed as functions of ψ:

number

[0117] 2μm max If ≦0, then m min is set to 0. Typically, the larger the values ​​of ψ and m, the smaller the range [m min ,m max ] is larger. That is, the more available bandwidth and peer nodes there are, the more flexibility there is in the number of peer nodes that should be configured to receive the relay of 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 and relay mixes) 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 a source mixing subsystem scenario: m(tx i )=m SM ±rnd(ξ SM ) where m SM is a normalized value that represents the average number of peers selected for relaying in the source mixing subsystem, and rnd(ξ SM ) is 0 and ξ SM represents a random integer between -1 and ξ SM An example probability distribution function for is in the range [-ξ SM ,ξ SM ]. The more common "skew normal" distribution has a probability density function PDF ξ can be characterized as follows:

number

[0120] In the case of source mixing, the skew can serve to represent the asymmetry between the two sides of the distribution, since values ​​to the right of the mean may be favored to aid in the initial propagation of data packets in the network. ξ and variance σ 2 ξ Having:

number

[0121] In the above equation, ω, ρ, and α represent the magnitude, position, and shape of the curve, respectively. ξ and σ 2 ξ (1) Range [m min ,m max ], and (2) a nominal value representing the average number of peers selected for relaying, i.e., μ SM (t). In some implementations, the following constructions may be used as appropriate when defining the mean and variance:

number

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

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

[0124] In general, the length of the relay delay 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 may be expressed using the following equation:

number

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

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

[0127] Process 1100 implements a technique for establishing the number of hops a first data packet will travel once the first data packet has been propagated by a network node. At operation 1102, a set of the first data packets is collected, and at operation 1104, the available bandwidth of the node among the node's links to neighboring nodes is determined. Then, at operation 1106, a mapping of the first data packets collected by the node is determined, the mapping assigning each of the first data packets to one or more neighboring nodes for relaying.

[0128] At 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 assigned for relaying is identified with reference to the mapping determined at operation 1104.

[0129] In operation 1110, a second subset of the first set is identified. The peer nodes of the second subset are designated to relay the at least one first data packet to their neighboring nodes upon receiving the at least one first data packet from the network node. That is, the second subset of peer nodes contribute to the propagation of the at least one first data packet through the network by forwarding the at least one first data packet to their peers. Once the at least one first data packet is relayed to a peer node of the second subset, the propagation of the at least one first data packet continues to further nodes of the network. On the other hand, once the at least one first data packet is relayed to peer nodes of the first set that are not included in the second subset, these peer nodes do not forward the at least one first data packet to any of their neighboring nodes.

[0130] At operation 1112, for at least one first data packet, the node transmits the at least one first data packet to peer nodes included in the second subset. At operation 1114, for at least one first data packet, the node transmits a modified version of the at least one first data packet to a first set of peer nodes not included in the second subset. 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 peer nodes is prohibited. In this way, a group of peer nodes (i.e., peers in the second subset) is configured to continue propagating the at least one first data packet, while a different group of peer nodes (i.e., peers not included in the second subset) only receives the at least one first data packet from the network node and does not relay it to their peers. By distinguishing data packets that are further propagated from data packets that travel only a single hop from the network node, it is possible to reduce the number of redundant relays of data packets in the data propagation scheme among the network nodes.

[0131] For example, if two nodes have the same set of peers, for a data packet relayed to the two nodes, further propagation by both of the two nodes to their peers is redundant since it would result in duplication of the data packet sent to those peers.By limiting the number of hops traveled by a data packet that may already be destined for another identifiable node in the network, unnecessary consumption of network bandwidth can be prevented or reduced.

[0132] Data packets forwarded to the first set of peers not included in the second subset may be marked to distinguish them from data packets to be propagated further (i.e., forwarded to peers of 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 relaying of the data packet to other nodes is prohibited.

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

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

[0135] A node collects a first set of data packets in operation 1202 and determines the available bandwidth in the node's links to neighboring nodes in operation 1204. Then, in operation 1206, a mapping / relay assignment of the data packets to peers is determined.

[0136] At operation 1208, a change in available bandwidth of the 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 at operation 1210, an updated mapping of data packets for relaying to peer nodes is determined in real-time based on the updated indication of 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 assigned by the mapping for relaying, a first length of time of delay in relaying the first data packet to one or more peer nodes, and a number of hops from the network node of the first data packet.

[0137] At operation 1212, the first data packet is transmitted to a neighboring node of the network node based on the updated mapping / relay assignment.

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

[0139] 16, a simplified example of a participating node 1600 is shown in block diagram form. The node 1600 includes a processor 1602, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The 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 that provides a network connection over a wired or wireless network.

[0140] The node 1600 includes a processor-executable blockchain application 1608 that includes processor-executable instructions that, when executed, cause the processor 1602 to perform one or more of the functions or operations described herein.

[0141] Any modules, routines, processes, threads, applications, or other software components implementing the apparatus and processes described herein, and the described methods / processes for configuring a blockchain node, may be implemented using standard computer programming techniques and languages, and the present application is not limited to any particular processor, computer language, computer programming conventions, data structures, or other such implementation details.

[0142] It should be noted that the above-described embodiments illustrate, rather than limit, 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 signs in parentheses are not intended to limit the claims. The terms "comprising" and "including" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "having or consisting of" and "comprising" means "comprising or consisting of". A singular reference of an element does not exclude a plural reference of such an element. Vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage. [Explanation of symbols]

[0143] 100 Blockchain Networks 102 nodes

Claims

1. 1. A computer-implemented method for propagating data packets in a network of nodes, comprising: collecting, at a network node, a set of first data packets during a first time period, said set including at least one first data packet received from one or more first nodes in the network; determining available bandwidth among links of said network node to a plurality of neighboring nodes connected to said network node; determining a mapping that assigns each of the first data packets to one or more neighboring nodes for relaying, the mapping indicating an expected time for relaying each of the first data packets, the determining the mapping including, for each of the first data packets, using the available bandwidth as a basis for setting at least one parameter that controls relaying of the at least one first data packet to the one or more neighboring nodes, the at least one parameter including a maximum amount of bandwidth allocable to the network node; transmitting the first data packet of the set to the plurality of neighboring nodes in accordance with the determined mapping; The method includes:

2. 2. The method of claim 1, wherein determining the available bandwidth comprises obtaining an indication of available bandwidth in each of the network node's at least one link 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 assigned for relaying according to the mapping, and the step of determining the mapping further comprises: determining a range of possible values ​​of a number of peer nodes to which the first data packet is assigned for relaying by the mapping based on the available bandwidth; selecting a number within the determined range for configuration as the first number of peer nodes; The method of claim 1 , comprising:

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

5. transmitting the first data packet of the set to the plurality of neighboring nodes in accordance with the determined mapping, For the at least one first data packet: transmitting said at least one first data packet to peer nodes included in said second subset; sending a modified data packet to the first set of peer nodes not included in the second subset, the modified data packet including the at least one first data packet modified to indicate that further relay of the at least one first data packet to peer nodes is prohibited; The method of claim 4 , comprising:

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

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

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

9. transmitting the first data packet of the set to the plurality of neighboring nodes in accordance with the determined mapping, for each of one or more first data packets of the set, determining a next scheduled time for relaying the first data packet to a neighboring node; relaying the first data packet at a time that is a first length of delay in relaying the first data packet to one or more peer nodes after the next scheduled time for relaying the first data packet; The method of claim 1 , comprising:

10. The method of claim 9 , wherein the first amount of time 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 mapping comprises: For each of the at least one first data packet generated, identifying a predetermined number of first data packets previously generated by the network node; obtaining a list of a set of relay nodes associated with the previously generated first data packet, the set of relay nodes including neighboring nodes through which the previously generated first data packet is respectively relayed; selecting a first set of relay nodes based on identifying a set of neighboring nodes in the obtained list that is different from the set of relay nodes; The method of claim 1 , comprising:

12. The method of claim 11 , wherein selecting the first set of relay nodes comprises arbitrarily selecting a set of two or more neighboring nodes not included in the obtained list.

13. detecting a change in the available bandwidth in links of the network node to the plurality of neighboring nodes; 2. The method of claim 1, wherein determining the mapping comprises 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. 13. A computer-implemented system for performing the method of claim 1.

15. A non-transitory computer readable medium having stored thereon instructions for causing a computer system to perform the method of claim 1.

16. The at least one parameter is: a first number of peer nodes to which the first data packet is assigned by the mapping for relaying; a first amount of delay in relaying the first data packet to one or more peer nodes; the number of hops of the first data packet from the network node; The method of claim 1 , comprising at least one of:

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

18. 2. The method of claim 1, wherein collecting, at the network node, the set of first data packets during the first time period comprises the network node being permitted to only accumulate first data packets of a first type during the first time period and being inhibited from transmitting any first data packets of the first type during the first time period.

Images