System and method implemented by computer for data transmission and communication in network such as block chain network

Abstract

To disclose a method for transmitting data in a network having a plurality of nodes.SOLUTION: A method is implemented in one of a plurality of nodes, and includes: generation of at least one data packet of a first type; collection, in a first period, of a set of the data packet of the first type containing at least one generated data packet and at least one data packet of the first type received from one or more first nodes in the network; and transmission, by arbitrarily selecting two or more adjoining nodes connected to one of the plurality of nodes regarding each data packet contained in the set, of data packets to each of the two or more selected adjoining nodes. The two or more selected adjoining nodes are configured to relay the data packet to one or more second nodes in the network by using a data transmission mode randomly selected to the adjoining node. The present invention is especially suitable to implementation on a block chain network such as for example a bit coin block chain.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to methods and devices for communicating data in a computer network, and more specifically, in a network of multiple nodes. The present invention is suitable for use with blockchain networks, but is not limited thereto.

Background Art

[0002] In this specification, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include, but are not limited to, consensus-based blockchain and transaction chain technologies, permissioned and un-permissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin may be referred to herein for the sake of explanation, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is an electronic ledger based on consensus, which is implemented as a computer-based decentralized distributed system composed of blocks consisting of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets among participants within the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block so that the blocks are chained together to form a permanent and immutable record of all the transactions that have been written to the blockchain since its inception. Transactions include small programs known as scripts embedded in their inputs and outputs. The script specifies how and by whom the output of the transaction can be accessed. On the Bitcoin platform, those scripts are written using a stack-based scripting language.

[0004] A network node that receives a new transaction immediately attempts to push that transaction out to other nodes within the network. Before sending the new transaction to other nodes, it is "validated". That is, it is checked against a set of criteria to ensure that the transaction meets the basic requirements for a proper transaction according to the applicable protocol.

[0005] For a transaction to be written to the blockchain, it is incorporated into a block by a node (“miner” or “mining node”). Miners are designed to collect transactions and form them into blocks. Miners then attempt to complete a “proof of work” for the node. Multiple miners compete across the blockchain network to be the first to assemble a block of transactions and complete the associated proof of work for that block. The successful miner adds the approved block to the blockchain, and the block is propagated through the network. Thereby, other nodes that maintain a copy of the blockchain can update their records. Those nodes that receive the block also “validate” the block and ensure that all the transactions in it comply with the protocol's formal requirements.

[0006] One of the recognized advantages of blockchain technology such as Bitcoin is the anonymity of transactions. The personal details of Bitcoin users are not officially and explicitly attached to Bitcoin addresses, and the Bitcoin ledger of the blockchain contains only public address information. However, since the blockchain is configured as a decentralized peer-to-peer network operating on the Internet, the anonymity of transactions can be endangered by attacks that use Internet Protocol (IP) addresses to link users to network activities. As an example, de-anonymization attacks such as IP traffic analysis conducted against blockchain-based networks can enable interested third parties to monitor the transactions presented by users on the network and use publicly available information to link transactions to their originators, for example, by linking a user's public key to their IP address.

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

[0008] It is desirable to provide techniques for the propagation of transactions within a blockchain-based network that can reduce the likelihood of compromising network anonymity through traffic analysis or other types of deanonymization attacks. More generally, it is desirable to provide techniques for relaying data between nodes of a peer-to-peer network so as to reduce vulnerability to deanonymization attacks.

[0009] Such solutions are currently being devised. SUMMARY OF THE INVENTION

[0010] Accordingly, the present invention provides a method and device as defined in the appended claims.

[0011] This application describes a node for transmitting data in a network of multiple nodes. Each node in the network may have one or more connections to other nodes. The node includes a processor, a network interface providing network connectivity, and a memory. When executed by the processor, the memory causes the processor to generate at least one data packet of a first type, collect a set of data packets of the first type that preferably includes at least one generated data packet and at least one data packet of the first type received from one or more first nodes in the network during a first period, and for each data packet included in the set, randomly select two or more adjacent nodes connected to the node and transmit the data packet to each of the two or more selected adjacent nodes. The two or more selected adjacent nodes may be configured to relay the data packet to one or more second nodes in the network using a randomly selected data propagation mode for that adjacent node.

[0012] In some implementations, the first period has a predefined length.

[0013] In some implementations, when executed, the instructions cause the processor to transmit in response to a determination that a trigger condition is satisfied.

[0014] In some implementations, the trigger condition has an elapsed predetermined duration since the time of generation of at least one data packet of the first type by the node.

[0015] In some implementations, the trigger condition has an elapsed predetermined duration since the time of first reception of the at least one data packet of the first type from one or more first nodes.

[0016] In some implementations, the data propagation mode of adjacent nodes is arbitrarily selectable between a first mode and a second mode. In the first mode, data packets are relayed to an arbitrarily selected subset of the nodes connected to the adjacent nodes. In the second mode, data packets are relayed to all the nodes connected to the adjacent nodes.

[0017] In some implementations, the instruction, when executed, causes the processor not to send any data packets of the first type during a first period.

[0018] This application may be described as providing a computer-implemented method for transmitting data in a network of multiple nodes. Each node in the network may have one or more connections to other nodes. The method may be implemented at one of the multiple nodes and may include generating at least one data packet of a first type, collecting a set of data packets of the first type that desirably includes at least one generated data packet and at least one data packet of the first type received from one or more first nodes in the network during a first period, and for each data packet included in the set, arbitrarily selecting two or more adjacent nodes connected to the one of the multiple nodes and transmitting the data packet to each of the two or more selected adjacent nodes. The two or more selected adjacent nodes are configured to relay the data packet to one or more second nodes in the network using a randomly selected data propagation mode for the adjacent node.

[0019] This application may further describe a non-transitory processor-readable medium storing processor-executable instructions for participating in a process of transmitting data packets in a network of multiple nodes. The processor-executable instructions, when executed by a processor at one of the nodes participating in the process, cause the processor to perform one or more operations of the methods described herein.

[0020] In many of the examples described herein, blockchain transactions are specifically referenced. However, as will be apparent, the methods and devices described herein may be implemented and applied in connection with the propagation of non-blockchain transactions. More generally, the methods and devices described in this disclosure may be suitable for use in propagating data between nodes of a peer-to-peer network.

[0021] Any feature described with respect to one aspect or embodiment of the present invention may be used with one or more other aspects / embodiments. These and other aspects of the present invention will become apparent from the embodiments described herein and will be described with reference to those embodiments. Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings.

Brief Description of the Drawings

[0022]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 5A

Figure 6

Figure 7

Modes for Carrying Out the Invention

[0023] In the present application, the term "and / or" is intended to cover all possible combinations and sub - combinations of the recited elements, including any one of the recited elements alone, any sub - combination, or all of the elements, without necessarily excluding additional elements.

[0024] In the present application, the phrase "at least one of... or..." is intended to cover any one or more of the recited elements, including any one of the recited elements alone, any sub - combination, or all of the elements, without necessarily excluding additional elements and without necessarily requiring all of the elements.

[0025] First, refer to FIG. 1. FIG. 1 represents, in block diagram form, an example of a network related to a blockchain. The network may be referred to as blockchain network 100. Blockchain network 100 is a peer - to - peer open - membership network where anyone can participate without invitation or consent from other members. Distributed electronic devices that execute an instance of the blockchain protocol on which blockchain network 100 operates can participate in blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrency.

[0026] The electronic devices that execute the blockchain protocol and form nodes 102 of 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.

[0027] The nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies that may include wired and wireless communication technologies. In many cases, the blockchain network 100 is implemented at least partially over the Internet, and some of the nodes 102 may be located at geographically dispersed locations.

[0028] The nodes 102 each maintain a global ledger of all transactions on the blockchain grouped into blocks that each contain the hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 102 may store a complete or partial copy of the global ledger. Transactions by the nodes 102 that affect the global ledger are verified by other nodes 102 so that the integrity of the global ledger is maintained. Details of implementing and operating a blockchain network, such as using the Bitcoin protocol, will be well understood by those of ordinary skill in the art.

[0029] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how and by whom the outputs of the transaction can be accessed. The output of a transaction can be the address to which a value is transferred as a result of the transaction. That value is then associated with that output address as an unspent transaction output (UTXO). Subsequent transactions may then reference that address as an input in order to use or distribute that value.

[0030] Node 102 can satisfy a variety of functions from network routing to wallet services in order to maintain a robust and secure decentralized public ledger. "Full nodes" contain a complete and up-to-date copy of the blockchain and can thus verify any transaction (used or unused) on the public ledger. "Lightweight nodes" (or SPV) hold a subset of the blockchain and can verify transactions using "specified payment verification" technology. Lightweight nodes only download the headers of blocks and do not download the transactions within each block. Thus, such nodes rely on peers to verify their transactions. "Mining nodes" can be full or lightweight nodes and are involved in verifying transactions and generating new blocks on the blockchain. "Wallet nodes" are usually lightweight nodes and handle the user's wallet services. Nodes 102 communicate with each other using connection-oriented protocols such as TCP / IP (Transmission Control Protocol).

[0031] When a node wants to send a transaction to a peer, an "INVENTORY" message is sent to the peer that transmits one or more inventory objects known to the sending node. When the peer responds with a "GETDATA" message, i.e., a full transaction request, the transaction is sent using a "TRANSACTION" message. The node that receives the transaction similarly forwards it to its peers, assuming that it is a valid transaction.

[0032] Refer now to FIG. 2. FIG. 2 schematically shows an example of a node 200 with an input buffer 202 and an output buffer 204. The exemplary node 200 includes network interfaces with a plurality of peer nodes, referred to as IntA, IntB, IntC, IntD, etc. The input buffer 202 represents incoming transactions from various peer nodes, and the output buffer 204 represents output network packets corresponding to the transactions that are sent to the peer nodes via each interface. The network packets are sequentially transmitted and received at the application level according to primitives provided by the operating system of the node 200. If a transaction x fits into a single Ethernet / IP packet, its transmission to m peers requires buffering of m different output network packets. Both the input and output network packets include, among other information, a logical interface ID representing the TCP / IP connection to the sending / receiving peer and the serialized transaction.

[0033] When a Bitcoin transaction is generated, the originating node broadcasts the transaction message on the network. Generally, when a client generates a transaction, it is placed in the output buffer 204. The transaction may or may not be transferred immediately to a peer. In the current implementation of the Bitcoin network, transactions are propagated by a mechanism known as "diffusion propagation", whereby each transaction originator sends the transaction to its neighboring nodes with an independent exponential delay. The delay in propagation is random and useful for introducing uncertainty in time estimation against malicious attackers. When a peer receives a particular transaction, the peer does not accept future relaying of the same transaction. For example, the transaction hash may be stored in the peer's memory pool, enabling the peer to reject the same transaction. The "diffusion" of transactions through the network is symmetric. That is, the forwarding node does not use information about the IP addresses of neighboring nodes to affect the transaction broadcast. For example, in the "standard" diffusion process (used in the Bitcoin protocol), all peers of the node broadcasting receive the same transaction, and in each relay instance, only one transaction at a time is relayed per peer. This symmetry of "diffusion" can be exploited by malicious third parties with knowledge of the peer-to-peer graph structure of the network when conducting de-anonymization attacks.

[0034] The present disclosure provides alternative techniques for transaction relaying on a blockchain network to improve anonymity protection against traffic analysis attacks. More specifically, the proposed relay protocol may be used to disguise the connection between the originating nodes of transactions and their IP addresses.

[0035] According to one aspect of the present disclosure, nodes in a blockchain-based network buffer new transactions over a period of time to accumulate transactions to be propagated to their peer nodes. The node then sends different sets of the buffered / accumulated transactions to an arbitrarily selected subset of those peer nodes. The transactions are thus propagated across the network, and each receiving node independently selects a mode to relay the received transactions to its own peers.

[0036] The proposed relay protocol, the Diffusion Mixer Protocol (DMP), includes two independent diffusion stages. The first stage ("random differential relay") enables the mixing of relayed transactions and the obfuscation of transaction senders. During the random differential relay stage, each node waits for a predefined amount of time before broadcasting the transaction to the network in order to collect more transactions from its peers. The node then forms an outgoing connection to its "entry nodes" and sends different transactions to an arbitrarily (e.g., randomly) selected subset of those entry nodes at approximately the same timestamp. A node's entry nodes are adjacent nodes such that a direct outgoing connection can be established from the node. The randomness of the selection of entry nodes and the diversity of the relayed transactions can make it more difficult for an attacker to reconstruct the network topology.

[0037] The second stage ("standard diffusion") ensures 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 in each relay instance, only one transaction is relayed per entry node at a time.

[0038] In a network of multiple nodes such as a blockchain network, it should be noted that one or more of the multiple nodes may be capable of implementing a DMP. Specifically, one or more of the multiple nodes in the network may be able to relay its received data packet to its entry node by propagating in the DMP. The participating nodes may, for example, select between a random differential relay process and a standard diffusion process to propagate a particular data packet. The multiple nodes of the network may choose to participate in the DMP in a decentralized manner or through joining a group of participating nodes assembled by a central authority so as to participate in the protocol. The participating nodes relay their output network packets according to the DMP. In particular, when a participating node receives a data packet, the node may transfer the received data packet according to the propagation mode selected for that node using the rules defined by the DMP.

[0039] A schematic visualization of the DMP for transaction relay is given in FIG. 3. A blockchain network 300 of multiple nodes is illustrated. Each node represents a network terminal (i.e., a blockchain node), while the edges represent the links between the nodes. For this illustration, it is assumed that for each link, it is possible to transmit or receive one bit at a time.

[0040] In the example network 300, since each node holds a memory pool (mempool) of unconfirmed transactions, when a node receives a new transaction, it is propagated across the network to all other nodes. Each node validates the new transactions and stores them in their respective local memory pools, and should transfer new transactions to any peer node that does not yet have the new transaction. Due to the peer-to-peer nature of the blockchain network 300, all nodes receive new transactions simultaneously. That is, it takes some time for a new transaction to reach all nodes within the network 300. For example, in the current implementation of the Bitcoin network, a new valid transaction takes an average of 3.5 seconds to reach 90% of the nodes in the Bitcoin network.

[0041] Figure 3 depicts two stages of the DMP for propagating a specific transaction Tx1, namely, random differential relay propagation 302 and standard diffusion 304 for Tx1. The source node 310 of transaction Tx1 may generate transaction Tx1 or receive it from a peer node at time t1. According to the DMP, the source node 310 waits to receive at least one incoming transaction from its adjacent nodes before starting the broadcast of the received / pending transactions. In the example of Figure 3, when transaction Tx2 is received by the source node 310, transactions Tx1 and Tx2 are sent to an arbitrarily selected subset of the source node 310's entry nodes. Transaction Tx1 is transferred to entry nodes 310c and 310d, while transaction Tx2 is transferred to entry nodes 310a and 310b. The example of Figure 3 is merely illustrative, and in particular, the source node 310 waits to receive more than one incoming transaction before propagating any of its received transactions.

[0042] The entry nodes relay the received transactions to their own peers. For example, nodes 310b and 310d transfer transactions Tx2 and Tx1, respectively, to one or more of their adjacent nodes. In the DMP, each recipient of a transaction independently selects the mode of propagation of the received transaction. Node 320 is an example of a node that selects standard diffusion as its diffusion mode. As shown in FIG. 3, node 320 transfers the same transaction Tx1 to all its entry nodes, namely, 320a, 320b, 320c, 320d, and 320e.

[0043] Next, refer to FIG. 5. FIG. 5 shows, in flowchart form, an example of a process 500 for propagating data packets in a network. Process 500 is implemented by a node of a blockchain network, such as network 100, for example. A node may be understood to refer to a mining node, a full node, a validator node, or other type of individual blockchain node within the blockchain network in this context. A node is a computer device equipped with a network connection, computing resources, and execution software that implements a blockchain protocol.

[0044] In 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 data packet of the first type may include a blockchain transaction. That is, the client may generate a blockchain transaction to be propagated to other nodes of the network.

[0045] In operation 504, the node collects a set of data packets of a first type during a first period T. That is, the node accumulates data packets of the first type over a period of time. 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, the data packets generated by the node are mixed with data packets of the same type received from adjacent nodes. In a blockchain network, during period T, the node accumulates a set of transactions by monitoring the network for incoming transactions to be relayed. The length Δt of period T may be predefined. In some embodiments, the length of time 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 nodes in the network (i.e., the number of incoming connections to the node). Since the node may only be allowed to accumulate data packets of the first type during period T, it may be prevented from transmitting any data packets of the first type during the duration of period T.

[0046] In operation 506, the node arbitrarily selects a subset of those entry nodes to which different sets of the collected data packets will be forwarded. More specifically, for each data packet included in a set of the collected data packets, the node arbitrarily selects two or more of its entry nodes (i.e., the adjacent 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 randomly selected. The node may, in some implementations, query the network to obtain the new addresses of its peers. In the Bitcoin network, the node may query one or more database source names (DSNs) incorporated into 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 can accept incoming connections. A decentralized version of peer detection may be implemented by having the peers send an "ADDR" message containing their IP addresses and port numbers to new nodes joining the network.

[0047] In some implementations, as part of operation 506, one or more of the nodes in the network may maintain a table or other data structure that tracks the assignment of each collected data packet to an entry node to which the data packet should be relayed. FIG. 4 shows an example of transaction relay for a source node 410 in the random differential propagation phase of a DMP in a blockchain network. Table 1 is an example of the assignment of the collected transactions Tx1 - Tx5 from the 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 FIGS. 4 and 1, the source node 410 relays each transaction to at least two entry nodes, and multiple transactions may 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 random differential propagation process, multiple data packets may be relayed by the transfer nodes to the same peer node at the same time. In a given instance of the DMP, not all entry nodes receive transactions from the source node 410. In the example of Table 1, entry nodes C and G do not receive any transactions from the source node 410. [Table 1]

[0048] Referring back to FIG. 5, for each of the collected data packets, at operation 508, the node transmits the data packet to each of the randomly selected entry nodes. Each of the selected entry nodes is configured to relay the data packet to one or more second nodes in the network using a mode of data propagation randomly selected for that entry node. That is, each of the selected entry nodes transfers the received data packet to one or more of its peers using a propagation mode independently selected for that entry node. In the transaction relay of the example of FIG. 4, each of the transactions Tx1 - Tx5 is transferred to the entry node to which that transaction is assigned. In some implementations, as part of operation 508, the node may send an express command along with the data packet to the selected entry node (i.e., the receiving node) for transferring the data packet using a randomly selected propagation mode.

[0049] Next, each node that receives a transaction from the source node 410 randomly selects a mode of propagation / diffusion to use when transferring the received transaction to its peer nodes (if any). In particular, the entry node that receives the transaction randomly selects to relay the transaction according to either the standard diffusion process or the random differential propagation process. The choice between the two options is random. Thus, in DMP, the two diffusion processes occur probabilistically in an alternating manner. That is, there is no clear separation between the random differential propagation phase and the standard diffusion phase. As a result of this "mixing" of the diffusion processes, it becomes more difficult for an attacker to reconstruct the network topology based on identifying the separation between sets of nodes relaying via random data propagation or via standard diffusion.

[0050] In some implementations, random selection by the entry node in the diffusion mode may include receiving, from the source node, a message in addition to the data packet to be relayed. The entry node may then generate a random value (e.g., a random number), append it to the received message, and hash the result, e.g., using SHA-256. The entry node may then check the hash value and, based on a predetermined rule regarding the hash value, may request a diffusion mode (e.g., if the last character of the hash is an Arabic numeral, select random differential propagation as the mode of diffusion). Alternatively, or additionally, the selection of the diffusion mode may be performed using some randomized process (e.g., a random number generator). At this time, the probability of selecting one of the modes may be higher than the probability of selecting the other mode depending on factors such as the number of incoming and / or outgoing connections, the average number of data packets received per unit time, etc.

[0051] In propagating a particular data packet, it may be desirable to balance the level of anonymity protection of the propagating node with the overall speed of propagation. If the means for ensuring a certain level of anonymity are too cumbersome (e.g., require too many network resources, are not being intentionally utilized enough when network nodes relay data packets, etc.), the efficacy of the network in diffusing data in a timely manner may be impaired. Thus, in some implementations, the random selection of the propagation mode by the relay node may be weighted. In particular, different probabilities may be assigned to each of two or more propagation modes (i.e., random differential propagation, standard diffusion, etc.) such that the probabilities reflect the proportional significance of the speed and anonymity of data propagation. For example, a higher, predefined probability may be associated with the random differential propagation mode for the data of a particular network so as to reflect a proportionally greater emphasis on maintaining the anonymity of the data being propagated.

[0052] Method 500 of FIG. 5 is implemented by a node that generates its own data packets of a first type. In particular, a node that participates in the DMP and generates data packets for propagation to the rest of the network executes method 500. FIG. 5A shows an example of a process executed by a relay node, i.e., a node that transfers data packets generated by another node. That is, a relay node is a node that does not generate the data to be transferred during the relay of a particular data packet and simply provides the function of "relaying" the data packet. In operation 550, the relay node independently selects its own data propagation mode. The relay node may, for example, make a selection between a random differential propagation mode and a standard diffusion mode. When the standard diffusion mode is selected in operation 552, the relay node transfers the data packet to all of its entry nodes in operation 554. In the example of FIG. 5A, the selection of the propagation mode is between two possible options. This example is not limiting, and in other examples, there may be three or more possible propagation modes. In method 500, when the selected mode is random differential propagation, the relay node executes steps 556, 558, and 560 corresponding to operations 504, 506, and 508 of FIG. 5.

[0053] Now, refer to FIG. 6. FIG. 6 shows, in flowchart form, an example of a process 600 for propagating data packets in a network. Process 600 may be implemented in a blockchain node that has a plurality of incoming and outgoing connections to other nodes in the blockchain network.

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

[0055] The trigger condition may be used to instruct the node to collect a sufficient number of incoming data and / or to collect incoming data packets for a sufficient amount of time. By collecting multiple incoming data packets, for example, before simultaneously propagating them to peer nodes within the network, an attacker monitoring the relay traffic emitted from the node will not be able to easily identify the node as the exact source of the relayed data packets.

[0056] In some implementations, the trigger condition may be the elapse of a predetermined duration from the time of generation of at least one data packet of the first type 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 predetermined period starting when the node generates data packets of the same type before any of those data packets are propagated by the node. This condition can be useful when attempting to ensure that data packets generated by the node are propagated after collecting additional data packets of the same type that can be broadcast simultaneously, thereby making it difficult for an attacker to accurately identify the node as the source of the generated data packets.

[0057] In some implementations, the trigger condition may be the elapse of a predetermined duration from the time of receipt of the first incoming data packet of the first type from a peer of the node. That is, the node may be designed to monitor and collect incoming data packets for a predetermined period starting when the first of such incoming data packets is received. This condition can be useful when attempting to ensure that more data packets, whether generated by the node itself or received from other peers, are collected by the node before any broadcast to the rest of the network.

[0058] In some implementations, the trigger condition may be that the number of data collected during the first period reaches a threshold number. In particular, the node may be designed to monitor and collect incoming data packets until either the first period elapses or a predetermined threshold number of data packets are collected by the node, whichever occurs first.

[0059] Refer now to FIG. 7. FIG. 7 shows a simplified example of a participating node 700 in block diagram form. Node 700 includes a processor 702. Processor 702 may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Node 700 further includes a memory 706 that may include permanent and non-permanent memory for storing values, variables, and in some cases, processor-executable program instructions, and a network interface 704 that provides network connectivity over a wired or wireless network.

[0060] Node 700 includes a processor-executable blockchain application 708 that, when executed, causes processor 702 to perform one or more of the functions or operations described herein.

[0061] It will be understood that the devices and processes described herein, and any modules, routines, processes, threads, applications, or other software components for implementing the described methods / processes to configure blockchain nodes, may be implemented by standard computer programming techniques and languages. This application is not limited to a particular processor, computer language, computer programming convention, data structure, or other such implementation details.

[0062] It should be noted that the above embodiments are illustrative rather than restrictive of the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs within parentheses shall not be construed as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those recited in any claim or the entire specification. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consisting of". A single reference to an element does not exclude a plurality of references to such elements, and vice versa. The present invention may be implemented using hardware having several individual elements and, in addition, using a suitably programmed computer. In apparatus claims listing several means, several of those means may be embodied by the same item of hardware. The mere fact that certain means are recited in mutually different claims does not indicate that a combination of those means cannot be used advantageously.

Claims

1. A node communicating data packets in a network of multiple nodes, each node having one or more connections to other nodes in the network, the node comprising: A processor; a network interface for providing network connectivity; a memory containing processor-executable instructions; having The processor-executable instructions, when executed by the processor, cause the processor to: generating at least one data packet of a first type including at least one blockchain transaction; collecting a set of data packets of the first type during a first time period, the set including the at least one generated data packet and at least one data packet of the first type received from one or more first nodes in the network; for each data packet included in the set, randomly selecting two or more neighboring nodes connected to the node, and transmitting the data packet to each of the two or more selected neighboring nodes; Run the command, the two or more selected neighboring nodes are configured to relay the data packet to one or more second nodes in the network using a mode of data propagation randomly selected for the neighboring nodes by weighted random selection, the mode of data propagation for the neighboring nodes being randomly selected between a first mode in which the data packet is relayed to a randomly selected subset of nodes connected to the neighboring nodes, and a second mode in which the data packet is relayed to all nodes connected to the neighboring nodes. node.

2. The first period has a predefined length. The node of claim 1 .

3. The processor-executable instructions, when executed, cause the processor to perform the transmitting in response to determining that a trigger condition is satisfied. The node of claim 1 .

4. the trigger condition comprises the passage of a predetermined duration from the time of generation of the at least one data packet of the first type by the node; The node according to claim 3 .

5. the trigger condition comprises the passage of a predetermined duration from a time of first reception of the at least one data packet of the first type from the one or more first nodes. The node according to claim 3 .

6. the trigger condition comprises a number of data packets collected during the first time period reaching a threshold number. The node according to claim 3 .

7. The processor executable instructions, when executed, cause the processor to not transmit any data packets of the first type during the first period.

7. A node according to any one of claims 1 to 6.

8. 1. A computer-implemented method of communicating a data packet in a network of multiple nodes, each node in the network having one or more connections to other nodes, the method being performed on one of the multiple nodes, generating at least one data packet of a first type; collecting a set of data packets of the first type during a first time period, the set including the at least one generated data packet and at least one data packet of the first type received from one or more first nodes in the network; for each data packet included in the set, randomly selecting two or more neighboring nodes connected to that one of the plurality of nodes, and transmitting the data packet to each of the two or more selected neighboring nodes; having the two or more selected neighboring nodes are configured to relay the data packet to one or more second nodes in the network using a mode of data propagation randomly selected for the neighboring nodes by weighted random selection. method.

9. said transmitting is performed in response to determining that a trigger condition is satisfied. The method according to claim 8.

10. the trigger condition comprises the passage of a predetermined duration from a time of generation of the at least one data packet of the first type by the one of the plurality of nodes.

10. The method of claim 9.

11. the trigger condition comprises the passage of a predetermined duration from a time of first reception of the at least one data packet of the first type from the one or more first nodes.

10. The method of claim 9.

12. the trigger condition comprises a number of data packets collected during the first time period reaching a threshold number.

10. The method of claim 9.

13. and preventing transmission of any data packets of the first type during the first period. The method according to claim 8.

14. 1. A non-transitory processor-readable medium having stored thereon processor-executable instructions for participating in a process of communicating data packets in a network of a plurality of nodes, the non-transitory processor-readable medium comprising: The processor executable instructions, when executed by a processor in one of the nodes participating in the process, cause the processor to perform the method of any one of claims 8 to 13. A non-transitory processor-readable medium.

Images