Optimizing network parameters for network coding

Abstract

A method and apparatus for propagating transactions in a network of nodes, each node having one or more connections with other nodes. The method includes: receiving a plurality of incoming transactions in a time period; combining the plurality of incoming transactions by network coding to generate a composite message; sending the composite message to one or more nodes in the network; and determining an adjusted time period based on a balance constant parameter and the number of transactions in the plurality of incoming transactions received in the time period.

Description

Technical Field

[0001] The present invention generally relates to propagating transactions in a network, and more particularly to methods and apparatus for increasing the speed at which transactions are processed. Background Art

[0002] In this document, the term "blockchain" is used to include all forms of computer-based electronic distributed ledgers. These include, but are not limited to, consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. It should be noted that alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0003] Blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed computer-based system consisting of blocks, which in turn consist of transactions. Each transaction (Tx) is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system, and the transaction includes at least one input and at least one output. Each block contains a hash of the previous block, so the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its creation. Transactions include small programs embedded in their inputs and outputs, which are called scripts, which specify how and by whom the output of the transaction can be accessed. On some platforms, these scripts are written using a stack-based scripting language.

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

[0005] To write a transaction to the blockchain, a node that is designed to collect transactions and form them into blocks incorporates the transaction into a block. The node then attempts to complete a "proof of work" for the node.

[0006] Nodes throughout the blockchain network compete to be the first to assemble a block of transactions and complete the proof of work associated with that block. The successful node adds its confirmed block to the blockchain, and the block propagates through the network so that other nodes that maintain a copy of the blockchain can update their records. The node that receives the block also "validates" the block and all the transactions in it to ensure that it meets the formal requirements of the protocol.

[0007] It would be advantageous to use a blockchain-based network to enable or facilitate the use of a wide range of cryptographically protected exchanges. Such exchanges may involve, for example, payment processing for credit card transactions. However, a transaction throughput of approximately 3 per second is insufficient to handle such electronic payments, which currently account for approximately 50,000 transactions per second. One of the bottlenecks associated with the speed of blockchain networks is the propagation of transactions. Each node that receives a transaction verifies the transaction and then sends it to a peer node. In practice, in some protocols, a node will send an INV message containing a list of transactions to a peer node and receive a GETDATA response message that selects a subset of the transactions published in the INV message. The node then sends the requested transaction to the peer node. This process is performed for each peer node to which the node is connected.

[0008] Therefore, it is hoped that a solution to the speed and scalability constraints that currently limit the ability of blockchains to handle large numbers of transactions can be found by increasing the speed of transaction propagation. It is also hoped that a solution that is more generally applicable to transaction propagation in a network of nodes, whether related to blockchain or other applications, can be found. Summary of the invention

[0009] Such a solution has now been devised.

[0010] Thus, according to the present invention, there is provided a method and apparatus as defined in the appended claims.

[0011] The present application describes and discloses methods and devices for facilitating rapid propagation of transactions (TXs). In some examples, nodes selectively use network coding to merge transactions into a single message to send to peer nodes. Network coding can be selectively used based on determining whether the node is a potential bottleneck. In some embodiments, the solution can be applied in a blockchain network environment.

[0012] In additional or alternative aspects, the present application describes a computer-implemented method for propagating transactions among a network of nodes, each node having one or more connections to other nodes.

[0013] The method comprises: determining that one of the nodes is a bottleneck for transaction propagation; within a first time period,

[0014] One or more first nodes in the node network receive multiple new transactions; merge these multiple new transactions through network coding and local coding vectors to generate a message; send the message and the global coding vector to one or more second nodes in the node network instead of sending these multiple new transactions to the one or more second nodes.

[0015] In additional or alternative aspects, the present application describes a node comprising a processor, a memory, a network interface, and an application program comprising instructions that, when executed by the processor, perform one or more of the methods described herein.

[0016] In some embodiments, the method or node determines whether the node is a bottleneck by evaluating the number of inbound links and the number of outbound links of the node. If the number of inbound links is greater than the number of outbound links, the node is determined to be a bottleneck. The evaluation may be performed upon receiving a first transaction of a plurality of new transactions. In another embodiment, the evaluation may be performed by tracking the number of inbound links and the number of outbound links over a period of time, where both the inbound number and the outbound number are averages. In some example embodiments, in response to receiving a first transaction of a plurality of new transactions, the node begins to determine whether it is a bottleneck.

[0017] In some embodiments, the merging and sending are performed in response to determining that a stop condition has been met. In one example, the stop condition is the expiration of a duration since receiving a first transaction in the plurality of new transactions or a determination that one of the nodes is a bottleneck. In another example, the stop condition is that the plurality of new transactions has reached a maximum number of new transactions.

[0018] In some embodiments, the length of the message is no greater than the longest transaction in the multiple new transactions.

[0019] In additional or alternative aspects, the present application describes a node for propagating transactions in a network of nodes, each node having one or more connections to other nodes. The node includes a processor, a memory, a network interface, and an application program containing processor-executable instructions. The instructions, when executed by the processor, cause the processor to: receive multiple incoming transactions within a time period; combine the multiple incoming transactions using network coding to generate a composite message; send the composite message to one or more nodes in the network; and determine an adjusted time period based on a balance constant parameter and the number of transactions in the multiple incoming transactions received within the time period.

[0020] In yet another additional or alternative aspect, the present application describes a computer-implemented method for

[0021] The transaction is propagated across a network of nodes, each of which has one or more connections to other nodes.

[0022] The method is performed by a node in the network, comprising: receiving a plurality of incoming transactions within a period of time; combining the plurality of incoming transactions using network coding to generate a composite message; sending the composite message to one or more nodes in the network; and determining an adjusted time period based on a balance constant parameter and the number of transactions in the plurality of incoming transactions received within the time period.

[0023] Some embodiments include iteratively repeating the receiving, combining and transmitting operations using the adjusted time period and determining a further adjusted time period after each iteration for use in a subsequent iteration.

[0024] In some embodiments, determining the adjusted time period includes determining the adjusted time period based on a balance constant parameter divided by the number of transactions. In some cases, such determination is subject to a minimum time period that the adjusted time period cannot be below and a maximum time period that the adjusted time period cannot be above.

[0025] Some embodiments include determining an average time period based on a plurality of adjusted time periods and storing the average time period in a memory at one of the nodes. In some cases, the average time period is sent to one or more neighboring nodes in the network of nodes.

[0026] Some embodiments include initializing the balance constant parameters based on one or more throughput estimates for one or more links connected to the one of the nodes, but other embodiments may include initializing the balance constant parameters based on an estimated initial time period and an estimated initial number of transactions.

[0027] Some embodiments include determining that a number of transactions received within the time period exceeds a minimum number of times using network coding, and wherein the combining and sending is dependent upon the determination.

[0028] In additional or alternative aspects, the present application describes a non-transitory processor-readable medium storing processor-executable instructions to propagate transactions in a network of nodes, wherein when a processor of one of the nodes executes the processor-executable instructions, the executable instructions cause the processor to perform one or more methods described herein.

[0029] In the various example embodiments described herein, specific reference is made to blockchain transactions. However, it should be understood that the methods and apparatus described herein may be implemented and applied in conjunction with non-blockchain transaction propagation. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] These and other aspects of the invention will become apparent with reference to the embodiments described herein.

[0031] Embodiments of the present invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0032] Figure 1 An example network associated with a blockchain is shown.

[0033] Figure 2 An example node with an input buffer and an output buffer is schematically shown.

[0034] Figure 3 A simplified example network of nodes in the network is shown.

[0035] Figure 4 Shows Figure 3 A network from another time.

[0036] Figure 5 A portion of an example network is schematically shown.

[0037] Figure 6 A node is shown with inbound links and one outbound link.

[0038] Figure 7 An example process for propagating a transaction among a network of nodes is shown in flowchart form.

[0039] Figure 8 Another example process for propagating a transaction among a network of nodes is shown in flow chart form.

[0040] Fig. 9 An example of a network of nodes propagating transactions is shown.

[0041] Fig.10 An example method for propagating transactions via network coding with adjustable time periods is shown in flowchart form.

[0042] Fig.11 An example method for selectively propagating transactions via network coding with adjustable time periods is shown in flowchart form.

[0043] Fig.12 An example blockchain node is shown in block diagram form. DETAILED DESCRIPTION

[0044] In the present application, the term “and / or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one element listed alone, in any sub-combination or all the elements, and does not necessarily exclude other elements.

[0045] In the present application, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one element listed alone, in any subcombination or all elements, and does not necessarily exclude any other elements, and does not necessarily require all elements.

[0046] First, refer to Figure 1 , which shows in block diagram form an example network associated with a blockchain, which may be referred to herein as a blockchain network 100. The blockchain network 100 is a peer-to-peer open membership network. Anyone can join without an invitation or consent from other members.

[0047] Distributed electronic devices running an instance of the blockchain protocol (under which the blockchain network 100 operates) can participate in the blockchain network 100. Such distributed electronic devices can be referred to as nodes 102.

[0048] The electronic devices that run the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including computers (e.g., desktop computers, laptops, tablet computers, servers), mobile devices (e.g., smartphones), wearable devices (e.g., smart watches), or other electronic devices.

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

[0050] Nodes 102 maintain a global ledger of all transactions on the blockchain, which is divided into multiple blocks, each of which contains a hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 102 may store a complete copy or a partial copy of the global ledger. Transactions of nodes 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. One of ordinary skill in the art will understand the details of implementing and operating a blockchain network.

[0051] 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 output of the transaction can be accessed. The output of a transaction can be a transfer address to a value that is the result of the transaction. The value is then associated with that output address as an unspent transaction output (UTXO). Subsequent transactions can then take that address as an input to spend or disperse that value.

[0052] Nodes 102 may be of different types or kinds depending on their functions. The basic functions associated with nodes 102 have been shown: wallet, full blockchain maintenance, and network routing. These functions may vary. Nodes 102 may have multiple functions. For example, a "full node" provides all functions. A lightweight node, such as a node that can be implemented in a digital wallet, may only have two functions: wallet and network routing. Digital wallets do not store the full blockchain, but instead track block headers, which are used as indexes when querying blocks. Nodes 102 communicate with each other via a connection-oriented protocol such as TCP / IP (Transmission Control Protocol).

[0053] In most blockchain networks, regardless of the governing protocol used, it will be beneficial to ensure that new transactions propagate quickly through the network so that all nodes that maintain a pool of unconfirmed transactions (often called a "memory pool") have an up-to-date and accurate database of transactions to be included in new blocks. Mining nodes utilize the pool of unconfirmed transactions to construct potential new blocks. In some cases, mining nodes maintain a full mempool locally so that mining nodes can group unconfirmed transactions into a single pool.

[0054] A new block can be mined. In some embodiments, the memory pool can be managed and maintained by a separate network of nodes (which may be called verification nodes, etc.), and these nodes can send a set of unconfirmed transactions from the memory pool to the mining node, so that the mining node attempts to mine the block. In some embodiments, the memory pool can be stored in a distributed hash table between multiple nodes. Regardless of the structure, it is hoped that any new transaction will be propagated through the network to reach the necessary nodes as quickly as possible. It is also hoped that any successfully mined new block will be propagated through the network as quickly as possible to reduce the occurrence of orphan blocks.

[0055] For example, in some current implementations, each node that receives a new transaction verifies the transaction and then sends it to all nodes connected to it (if those nodes have not already received the new transaction). The nodes use TCP / IP (Transmission Control Protocol). The node that receives the new transaction sends an INV message to each peer node, containing data about the new transaction available, and receives a GETDATA message from each node that is interested in receiving the new transaction. The node then sends the transaction to each node that requested the transaction via a (separate) TCP message.

[0056] Reference Figure 2 , which schematically shows an example node 200 with an input buffer 202 and an output buffer 204. The example node 200 has a network interface including multiple peer nodes, which are called intA, intB, intC, intD, etc. The input buffer 202 shows the incoming transactions from the various peer nodes, while the output buffer 204 shows the transmission of certain received transactions to the peer nodes on the various interfaces. Network packets are sent and received in sequence at the application layer according to the primitives provided by the operating system of the node 202. Assuming that transaction x fits in a single Ethernet / IP packet, its transmission to m peer nodes requires buffering of m different output packets. The input and output network packets, as well as other information, will contain serialized transactions and a logical interface ID that represents the TCP / IP connection with the sending / receiving peer.

[0057] The expected processing time of an incoming transaction depends on the input queue L iThe average length (in packets) of the output queue L, and the expected time for correctly transmitting the processed transaction depends on o Therefore, the effective relay of transactions depends on reducing L i and L o However, the probability model used to selectively relay transactions to peers directly affects L o , and affects L by induction i .

[0058] In some current implementations, INV and GETDATA message packets are queued in the I / O buffer in the same manner as transactions, causing severe impact on transmission and reception delays.

[0059] Blockchains are proposed for use in large volumes of fast transactions. For example, blockchains are being considered for processing payments. Payment processing may include, for example, credit card transactions, etc. The number of such transactions is enormous for current blockchain network implementations. Therefore, it would be advantageous to provide methods and apparatus for improving the ability of blockchain networks to handle communications (e.g., sending transactions between nodes).

[0060] According to one aspect of the present application, a blockchain node buffers new transactions for a specific period of time, combines the transactions into a single message using network coding, and then sends the message to one or more other blockchain nodes. Such a blockchain node encodes the new transaction to generate a message that mixes the new transaction in a decomposable manner, but generates a combined message. The combined message has the size of the maximum transaction and a small overhead.

[0061] If a blockchain node uses network coding, then the node can also no longer rely on TCP / IP INV and GETDATA messages because the node will send all new transactions in the form of encoded messages, rather than having nodes pick and choose which subset of new transactions they want to receive.

[0062] Reference now Figure 3 , Figure 3 A simplified example network of nodes in a blockchain network 300 is shown. Each node represents a network terminal (i.e., a blockchain node), and edges represent links between nodes. For the purposes of the drawing, a single bit is expected to be sent or received at a time for each link.

[0063] Two of the nodes are labeled as sources S1 and S2, and sources S1 and S2 receive two new transactions tx1 and tx2. In this example blockchain network 300, both nodes maintain memory pools of unconfirmed transactions, so when a node receives a new transaction, it propagates it to all other nodes through the network. Each node will verify and store the new transaction in its own local memory pool and forward the new transaction 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 will not receive new transactions at the same time, that is, it takes some time for new transactions to reach all nodes in the network 300. For example, in some current network implementations, it takes an average of 3.5 seconds for a new valid transaction to reach 90% of the nodes in the network. In theory, if transaction transmission is instant, such as the time for the transaction to reach all nodes in the network is 0, that is, t = 0, the network will be protected from the possibility of repeated payment attacks. Therefore, improving the throughput of the blockchain network is a key factor in achieving scalability and reliability of the entire system.

[0064] Two nodes of the blockchain network 300 are labeled as receiving nodes R1 and R2.

[0065] Nodes I1 and I2 represent intermediate nodes, which may or may not store a copy of the memory pool, but more importantly represent the bottleneck of the network 300 at time T. Node I1 receives Tx1 and Tx2.

[0066] When two new transactions are sent, they must decide which one to send first almost simultaneously. That is, the outgoing edge from I1 to I2 is a bottleneck at least at time T.

[0067] Node I1 can use network coding to combine new transactions Tx1 and Tx2 into a composite message M, which is the same size as the larger of Tx1 and Tx2. Node I1 sends message M to node I2, and node I2 forwards message M to receiving nodes R1 and R2. Receiving nodes R1 and R2 can recover the individual transactions Tx1 and Tx2. For example, receiving node R1 will receive Tx1 and M. M is based on the combination of Tx1 and Tx2, so R1 only needs to solve the equation (Tx1, Tx1+Tx2) to get Tx2. Conversely, R2 will receive Tx2 and needs to solve the equation (Tx2, Tx1+Tx2) to get Tx1.

[0068] Bottlenecks may appear or disappear over time, depending on the configuration of the network and where transactions are generated at any given time. Bottlenecks are links (edges) between nodes that severely limit the performance of the network, especially slowing down the transmission of transactions (or blocks) in the case of blockchain networks. But the source of bottlenecks (links between nodes) is the node.

[0069] Reference now Figure 4, which shows the same blockchain network 300 at time T'. In this example, transaction Tx1 is received at node R1 and transaction Tx3 is received at node I2. In this case, a bottleneck occurs again at node I1, but this time a link between node I1 and node S1 occurs because Tx2 and Tx3 arrive at node I1 at the same time. Node I1 can use network coding to combine Tx2 and Tx3 into message M'.

[0070] One option is to have each node apply network coding in all cases. However, performance may be further improved by selectively applying network coding at specific nodes where it may be advantageous. For example, if a node can determine whether it represents a bottleneck at any given point in time, the node may selectively or adaptively apply network coding to the transmission of messages, while if it is not a bottleneck, the node transmits the transaction normally.

[0071] Therefore, a node can be used to evaluate or determine whether it is a possible bottleneck at a given point in time. In a sense, this can be determined based on the balance between inbound links and outbound links. That is, at a given point in time, a node can receive transactions on one or more links and plans to send those transactions on one or more links. The connections (i.e., edges) between nodes can act as inbound links or outbound links at any given point in time depending on the traffic in the network. In some cases, the number of inbound links can be called "fan-in" and the number of outbound links can be called "fan-out".

[0072] In one embodiment, at least some nodes in a blockchain network maintain a table or other data structure that tracks the relative number of fan-in links and fan-out links to primary neighboring nodes. Figure 5 A portion of an example network is schematically shown, where a first node I1 and a second node I2 both locally store a table or other data structure that is used to determine the fan-in and fan-out of the node at any given time. Based on the relative amounts of fan-in and fan-out, the node can determine whether it is a possible bottleneck. Typically, this can be determined based on whether the number of inbound links (fan-in) exceeds the number of outbound links (fan-out), in which case the node is likely a bottleneck at this time.

[0073] In an example embodiment, whether a node is a bottleneck is evaluated within a time period ΔT. The quantities in the table may be the average fan-in and fan-out within the time period ΔT.

[0074] In some embodiments, the determination may also be based in part on knowledge of the network topology. For example, at least in some cases, a node that is a peripheral node is less likely to become a bottleneck, while a node that is an intermediate node is more likely to become a bottleneck.

[0075] In other embodiments, whether a node is a bottleneck may be determined based on the state of the output queue or an evaluation of the backlog in the output queue over time.

[0076] In some embodiments, determining or identifying a bottleneck includes a combination or sub-combination of the factors described above.

[0077] Network coding was developed less than two decades ago as an alternative to the then-dominant packet switching networks. Network coding models a network as a directed graph (N, L) with link capacities, indicating that a node n (n∈N) can deliver information to a set of receivers at a rate that reaches the broadcast capacity h. where h is the minimum cut set between s and any r (r∈R) encoded by a node inside the network.

[0078] A cut C is defined as the partition of the vertices V of the graph G = (V, E) into two disjoint subsets S and T. The cut set of a cut C = (S, T) is the set of edges {(u, v) ∈ E | u ∈ S, v ∈ T} whose endpoints are in S and T respectively.

[0079] In "Practical Network Coding", Proceedings of the annual Allerton conference on communication control and computing, v. 41, pp. 40-49, The University (2003), PAChou, Y. Wu, and K. Jain describe an example approach to network coding, which is incorporated herein by reference. This approach removes any decentralized knowledge of the network topology or the encoding or decoding functions. Chou shows that a network N can be represented as having unit capacity edges (e), senders s (s ∈ V), and a certain number of receivers T The acyclic graph G = (V, E) of node v = in(e) has a symbol y(e) at its output that is a linear combination of the symbols y(e′) on the edges e′ that enter node v. Figure 6 The node v and the output y(e) are shown. In particular, the output is represented as:

[0080] y(e)=∑ e′:out(e′)＝v m e (e′)y(e′)

[0081] Among them, y(e′ i)=x i ,i=1,…,h, and vector m e is the local encoding vector, represents the encoding function of edge e at node v, and h represents the broadcast capacity of the minimum number of edges for any cut between the sender and the receiver.

[0082] Chou pointed out that the output y(e) on any edge e(e∈E) is a linear combination of the source symbols And the coefficient g(e)=[g1(e),…,g h The h-dimensional vector of (e)] can be expressed by g(e)=∑ e′:out(e′) m e (e′)g(e′) is obtained by recursion, where the edge e i g(e i ′) is implemented to the i-th unit vector. g(e) can be called the global encoding vector along e. For any node t that receives symbols along h incoming edges:

[0083]

[0084] If the matrix G of the global encoding vector t If the level is h, then node t can recover the source symbols x1,…,x h In the above example, when applied to blockchain transaction network coding, the transactions are stored in the array [x1,…,x h ]. For more information, see Chou.

[0085] The global encoding vector of the output edge e can be described as a local encoding based on the global encoding vector of the input edge e'.

[0086] It will be appreciated that network coding can be used to propagate transactions through a network. Network coding is also used in an overlay network for implementing a distributed hash table of unconfirmed transactions, where each transaction is stored by at least two nodes to ensure redundancy within the distributed hash table. In this case, network coding can be used when sending transactions to two or more nodes for storage. However, the use of network coding can provide the additional advantage of being able to recover from the loss of two or more nodes storing transactions. Because the intermediate node has received one or more messages containing combined data about the transaction, the lost transaction can be recovered from the network coded message.

[0087] Reference now Figure 7, which shows in flowchart form an example process 700 for propagating transactions in a blockchain network. Process 700 is implemented by a node in a blockchain network. In this context, a node can be understood to refer to a mining node, a full node, a verification node, or other types of discrete blockchain nodes in a blockchain network. The node is a computing device with a network connection, computing resources, and execution software that implements the blockchain protocol.

[0088] In operation 702, the node determines that it is a potential bottleneck in the network at time T. As described above, the determination may be based on a comparison of fan-in and fan-out at time T. For example, if fan-in exceeds fan-out at time T, the node may determine that it is a bottleneck. Other factors may alternatively or additionally be considered in determining whether the node is a bottleneck. For example, average fan-in and fan-out over a period of time, the node's location in the network topology, the current or historical state of the node's output queue, or any other factor related to the node's capacity to propagate received transactions.

[0089] In operation 704, after being determined as a bottleneck, the node accumulates transactions for a time period ΔT. The time period may be a predetermined length of time. In some example implementations, the time period may vary based on network traffic measurements, geographic information, or both. The time period is not a fixed time, but rather until a minimum number of transactions are received, accumulation of transactions may occur. This may be further affected by a maximum time so that accumulated transactions are not kept for too long.

[0090] In operation 706, multiple transactions that the node has accumulated are combined into a single message using network coding. In some implementations, the length of the message can be as long as the longest transaction among the transactions. In some implementations, the length of the message (in bits) can be no longer than the longest length among the transactions. The message is generated by a local coding vector and a network coding algorithm.

[0091] The node then sends the message and the global encoding vector to one or more nodes in operation 708. The message is sent instead of sending the actual transaction. That is, instead of sending multiple accumulated transactions, the node sends the message and the global encoding vector to peer nodes on all of its outbound links.

[0092] Now refer to Figure 8 , which shows in flowchart form an example method 800 for propagating transactions in a blockchain network. As described above, the method 800 can be performed at a blockchain node having multiple inbound links and outbound links.

[0093] In operation 802, a blockchain node receives a transaction. The received transaction is received via an inbound link. The blockchain may verify the transaction according to protocol requirements to ensure that the transaction is legitimate. In operation 804, the node may determine whether it is a bottleneck related to the transaction. The determination may be made based on evaluating the balance between inbound (fan-in) and outbound (fan-out) at the time. As described above, the determination may also be based on other factors.

[0094] If the node determines that it is not a bottleneck, then the node sends the transaction on its outbound link to one or more peer nodes in the blockchain network in a normal manner in operation 806. However, if the node determines that it is a possible bottleneck, then in operation 807, the node stores the transaction in memory (such as in a buffer or other storage element).

[0095] Then, as shown in operation 808, the node continues to receive transactions and store them until it determines that a stop condition has been met. In this example, the stop condition is the passage of a duration ΔT. For example, the duration may start from determining that the node is a bottleneck, or from receiving the first transaction in operation 802. Other conditions may be used instead of the duration; for example, accumulating a maximum number of transactions in memory, or any combination of these factors.

[0096] Once the stop condition is met, such as in this case ΔT has passed, the node then constructs a message M from the stored transactions using the network coding and the local coding vector as shown in operation 812. The node then sends the message and the global coding vector to other nodes on all of its outbound links in operation 814.

[0097] Adjustable time period for network coding

[0098] In some embodiments, the time period ΔT may not be fixed. That is, the node may adjust ΔT from time to time, depending on the characteristics of the network or the transaction flow in and out of the node. In some embodiments, the time period ΔT may be adjusted after each ΔT expires, so that the time period is constantly adapted to the current traffic level. In some embodiments, any adjustment to the time period ΔT is limited to a minimum time period and a maximum time period. In some embodiments, the time period ΔT may only be adjusted periodically, such as after every 2, 5, 10, or other number of time periods, or only when the determined adjustment will change the time period by exceeding a certain threshold amount or percentage.

[0099] To adapt to traffic conditions, a node can use the concept of "throughput". The node can have inbound links and outbound links to multiple other nodes in the network. Now refer to Fig. 9, which schematically shows an example network of nodes 900. Node N3 has inbound links and outbound links to nodes N1, N2, N4, N5 and N6. These nodes can be characterized as (logical) primary neighbor nodes. Typically, a node knows its primary neighbor nodes. That is, the node can receive transactions from these nodes directly (without routing through another node in the network) or send transactions directly to these nodes. Note that "primary neighbor nodes" are not necessarily geographically close and can be obtained by traversing a large number of network elements and links (rather than through another node).

[0100] Node N3 can keep track of its primary neighbor nodes in a table stored locally on node N3, as shown in the following example table:

[0101] Table 1

[0102]

[0103] In the above example, node N3 keeps track of the size si of messages received from nodes in the table through each inbound link, and also keeps track of the size s of messages sent to nodes in the table through each outbound link. o Tracking. It can be assumed that the throughput of the link is evenly distributed between input and output, that is, the channel bandwidth is evenly distributed, although this assumption may not always hold. However, based on this assumption, the following formula can express the throughput Tr of the link or channel during the analysis period:

[0104] Tr≥∑s i +s o

[0105] That is, the throughput Tr must be greater than or equal to the total amount of data sent or received over the link.

[0106] It should be understood that the assumption of equal throughput on inbound and outbound may not be respected in actual implementations. So the balancing parameter γ∈[0,1] can be defined as the inbound / outbound throughput ratio, so:

[0107] (For input)

[0108] (For output)

[0109] In the above expression, the parameter ΔT represents the time period over which the size of the sent / received message is measured. It should be understood that the above expression does not indicate the actual maximum throughput Tr of the channel or link, but rather shows that the throughput Tr of the link or channel must be at least as large as the actual usage data (the size of the messages actually sent / received). Therefore, in some instances, the throughput Tr of the link can be estimated based on historical usage data, such as measuring the size of messages sent and received through the link.

[0110] The throughput Tr of the link can be estimated by some other empirical data. For example, in the case of a network running on TCP / IP, the TCP receive window (RWIN) and round-trip time (RTT) can be used to determine the throughput of the link. RWIN indicates the amount of data that a node can receive without sending any confirmation to the sender, and can be defined by the applicable communication protocol used by the network. RTT is a measurement of the time required for a message of negligible size to go from a node at one end of the link to a node at the other end of the link and back again, sometimes referred to as a ping message, etc.

[0111] Other mechanisms may also be used to determine the throughput Tr, including obtaining throughput information from neighboring nodes, using preset or predetermined throughput estimates, or other sources of throughput estimates.

[0112] In some embodiments of the present application, the node may maintain locally stored information about the throughput of various links of the estimated node. These links may be links connected to the primary neighboring nodes. For example, the above Table 1 may be modified to add columns related to the throughput estimation of each link:

[0113] Table 2

[0114]

[0115] A node may further determine the median or average throughput of its available links.

[0116] As described above, network coding may include combining a set of transactions received in a time period ΔT to generate a composite message M, which is then sent out through the node from the outbound link, rather than broadcasting a single message. In some embodiments of the present application, the time period ΔT may be based at least in part on the throughput and the number of transactions received.

[0117] As described above, the throughput may be set based on the median throughput or average throughput of the node's available links.

[0118] Alternatively, in some cases, based on some assumptions about the network, the node may initialize the throughput to a globally estimated throughput value. For example, the estimated throughput may be determined by first initializing the time period ΔT to a preset value and setting the number of transactions to the estimated preset value. In a specific example, the preset time period ΔT may be 3.5 seconds, since this is the approximate time required for a transaction to reach 90% of the nodes in the network. In other embodiments, the time period ΔT may be initialized to another value. The number of transactions that may be received within the time period ΔT may also be initially assumed to be a preset value. In a specific example, the number of transactions N is initialized to 500 based on the fact that an average block contains approximately 2000 transactions, and 2000 divided by 3.5 is approximately 500. Other initialization values ​​may also be used in other implementations.

[0119] After selecting the initial value of the time period ΔT and the number of transactions, the relationship between these parameters can be established as the product of the time period ΔT and the number of transactions.

[0120] K=ΔT0·N0

[0121] Where K is set to be an inversely proportional constant with respect to the time period ΔT and the number of transactions N. In the above formula, ΔT0 is the initial value of the time period ΔT, and N0 is the initial value of the number of transactions received. In other embodiments, as described above, the constant K can be initialized based on other assumptions or measurements. The constant K is related to the throughput Tr because the constant K is related to the inversely proportional relationship between N and ΔT. If each of the N transactions has a certain size, then the N transactions cumulatively represent a certain amount of data, such as s received in the ΔT time period. i In some cases, the constant K may be determined based in part on an estimated or target throughput Tr.

[0122] The relationship between the concept of throughput Tr and the constant K is expressed by the following expression:

[0123]

[0124] After determining the initial constant K, the node monitors the number of transactions actually received in its inbound link during ΔT and decides whether to adjust ΔT. In at least one implementation, ΔT is adjusted based on the number of transactions received within at least the previous ΔT and the constant K. For example, a method for determining ΔT i The method is as follows:

[0125]

[0126] Here, i represents the index. In this simplified example, the ΔT for time i is based on the number of transactions received in the immediately preceding ΔT, where K is a constant. In a sense, K can be labeled as the equilibrium constant, because it is based on the product of the time period and the number of transactions, and to the extent that too few transactions are received in a time period to satisfy the equilibrium constant, the equilibrium constant can be maintained by extending the time period.

[0127] In another example embodiment, the number of received transactions may not only be based on the previous time period ΔT i-1 , but may be based on an average of two or more previous time periods. In some cases, the average may be determined as a weighted average to give greater weight to more recent time periods.

[0128] In other example embodiments, the throughput may also be adjusted over time based on any of a number of factors. In one example, the constant K may be initialized based on an intermediate throughput or average throughput value from one or more neighboring nodes.

[0129] Reference now Fig.10 , which shows in flowchart form an example method 1000 for propagating transactions using network coding in a network of nodes. The method 1000 is implemented at a node in the network of nodes. In this example, the node is used to propagate transactions using network coding.

[0130] In operation 1002, certain parameters may be initialized. For example, an initial time period ΔT0 may be set to a predetermined value. As described above, in some cases, the initial time period ΔT0 may be set to a value derived from a current time period ΔT being used by a neighboring node. In some cases, the initial time period may be calculated based on a predetermined throughput value and an expected number of transactions. Other mechanisms, including those described above, may also be used to determine the initial time period ΔT0.

[0131] In addition, if the parameter N0 is used to determine the initial time period ΔT0 or the constant K, i.e. the equilibrium constant, then the number of transactions N0 can also be initialized. In some cases, the number of transactions N0 can be used to determine the constant K, for example using the following expression:

[0132] K=ΔT0·N0

[0133] In some cases, the initial time period ΔT0 may be determined based on the number of transactions N0 by using a predetermined constant K, such as using the following expression:

[0134]

[0135] The constant K may be determined based on the initial time period ΔT0 and the number of transactions N0, but in some other cases, the constant K may be set to a preset or predetermined equilibrium constant value. If changes to the network or the protocol used affect the possible characteristics of the link to the node, the node may update the predetermined value of the constant K as the network changes, which may affect the transaction volume and / or throughput. In some cases, the constant K may be determined empirically. For example, historical data on throughput may be used to determine the constant K. In another example, as described above, the constant K may be determined based on a round-trip time test. In another example, the constant K may be determined based on data about the throughput at one or more neighboring nodes. As an illustration, the current node may calculate an average throughput value associated with its neighboring nodes and use this value to estimate the equilibrium constant to derive the constant K.

[0136] In operation 1004, after at least the initial time period ΔT0 and the constant K have been initialized, the node receives transactions on its inbound link. The transactions are buffered in the node's storage. As indicated in operation 1006, the node continues to receive and retain transactions on its inbound link until the time period ΔT i As you can see, i is just an index and is initially set to 0.

[0137] Once the time period expires, the transaction is sent using network coding in operation 1008. This may include combining the transaction using network coding operations to generate a message M, and sending the message over the node outbound link.

[0138] In operation 1010, the index i is incremented, and then the node updates the time period ΔT in operation 1012. i In this example, the updated time period ΔT i Based on the constant K divided by the previous time period ΔT i-1 The actual number or number of transactions received during the period ΔT i The adjustment of may be subject to certain constraints, such as a maximum value that cannot be exceeded or a minimum value that cannot be lowered. In some embodiments, the adjustment may be based on more than one previous time period and the number of transactions received during those time periods. In some embodiments, the adjustment of the time period ΔT may be subject to certain constraints, such as a maximum value that cannot be exceeded or a minimum value that cannot be lowered. In some embodiments, the adjustment may be based on more than one previous time period and the number of transactions received during those time periods. i Different or additional constraints can be imposed on the adjustment of , for example, the change per iteration must not exceed a certain percentage.

[0139] In this example, nodes send transactions using network coding in each iteration. In another example embodiment, nodes may selectively use network coding if the volume of transactions in the time period justifies the use of network coding. Fig.11 , which illustrates, in flowchart form, an example method 1100 for propagating a transaction among a network of nodes.

[0140] Operations 1102, 1104, and 1106 correspond to the above Fig.10 In operation 1108, the node evaluates the i In some examples, this evaluation may involve evaluating the number of transactions received, N, during the period of time in which a sufficient number of transactions are received to justify the use of network coding. i and the minimum number of transactions N required to use network coding min If the minimum is met, the transaction is sent using network coding in operation 1112. If the minimum is not met, the transaction is sent using conventional non-network coding transmission in operation 1110.

[0141] Operations 1114 and 1116 correspond to the above Fig.10 Operations 1010 and 1012 in .

[0142] It is understood that the various operations or steps in the exemplary methods 1000 and 1100 can be changed, and in some cases can be omitted, but the operating principle of the process cannot be changed. Additional operations not shown can also be added without changing the operating principle of the process. All such changes are intended to be included in this article.

[0143] Each node can maintain a record of its current time period ΔT (or in some cases, a running average time period or a weighted average time period, etc.), and can periodically notify its neighboring nodes of its current time period ΔT. In this way, each node can track the time period ΔT that its neighboring nodes are using. Therefore, when a new node enters the network, the node can initialize its parameters based on the parameters of the neighboring nodes, rather than initializing the parameters of the node by making assumptions about the network. For example, the new node can obtain the time period ΔT (or average time period ΔT) used by its primary neighboring node, and can set its initial time period ΔT based on the average or other combination of the primary neighboring node time periods. This can speed up the adaptation of the new node to the characteristics of the network and increase the speed of adaptation.

[0144] Now refer to Fig.12 , which shows a simplified example of a participating node 1200 in block diagram form. The node 1200 includes a processor 1202, which may include one or more microprocessors, application specific integrated chips (ASICs), microcontrollers, or similar computer processing devices. The node 1200 also includes a memory 1204 and a network interface 1206, the memory 1204 may include permanent and non-permanent memory to store values, variables, and in some cases, program instructions executable by the processor, and the network interface 1206 provides a network connection through a wired or wireless network.

[0145] The node 1200 includes a processor-executable blockchain application 1208 that includes processor-executable instructions that, when executed, cause the processor 1202 to perform one or more of the functions or operations described herein.

[0146] It is understood that the devices and processes described herein, as well as any modules, routines, processes, threads, applications or other software components that implement the described methods / processes for configuring nodes, can be implemented using standard computer programming techniques and languages. The present application is not limited to a specific processor, computer language, computer programming specification, data structure or other implementation details.

[0147] It should be noted that the above embodiments illustrate rather than limit 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 numerals in brackets shall not be interpreted as limiting the claims. The words "comprising" and "comprise" and the like do not exclude the presence of other elements and steps as a whole, even though these elements and steps are not listed in any claim or specification. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consists of". The singular reference of an element does not mean to exclude the plural reference of these elements, and vice versa. The present invention can be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a device claim that lists several means, several of these means may be embodied by the same component of hardware. The indisputable fact that certain methods are listed in mutually different dependent claims does not mean that the combination of these methods cannot achieve beneficial effects.

Claims

1. A node for propagating transactions in a network of nodes, each node having one or more connections to other nodes, the node comprising: processor; Memory; Network interface; and An application program comprising processor-executable instructions which, when executed by the processor, cause the processor to: Receiving multiple incoming transactions within a certain time period; combining the plurality of incoming transactions by network coding to generate a composite message; sending the composite message to one or more nodes in the network; determining an adjusted time period based on a balance constant parameter and a number of transactions in a plurality of incoming transactions received during the time period; wherein the instructions, when executed, cause the processor to determine the adjusted time period by determining the adjusted time period based on the balance constant parameter divided by the number of transactions; wherein the balance constant is determined based on a throughput of a neighboring node; wherein the instructions, when executed, further cause the processor to determine an average time period based on the plurality of adjusted time periods, and store the average time period in the memory; and The averaging time period is sent to one or more neighboring nodes in the network of nodes.

2. The node according to claim 1, wherein: The instructions, when executed, will further cause the processor to iteratively repeat the receiving, combining, and transmitting operations using the adjusted time period and, after each iteration, determine a further adjusted time period for use in a subsequent iteration.

3. The node according to claim 1, wherein: Determining the adjusted time period is subject to a minimum time period that the adjusted time period cannot fall below and a maximum time period that the adjusted time period cannot rise above.

4. A node according to any one of claims 1 to 3, wherein: The instructions, when executed, cause the processor to initialize the balance constant parameter based on performing one or more throughput estimates for one of a plurality of links connected to the one of the nodes.

5. The node according to claim 1, wherein: When the instructions are executed, the processor initializes the balance constant parameter based on the estimated initial time period and the estimated number of initial transactions.

6. The node according to claim 1, wherein: The instructions, when executed, further cause the processor to determine that a number of transactions received within the time period exceeds a minimum number to use network coding, and wherein the combining and sending are dependent upon the determination.

7. A computer-implemented method for propagating transactions among a network of nodes, each node having one or more connections to other nodes, the method being performed at one of the nodes, comprising: Receiving multiple incoming transactions in one time period; combining the plurality of incoming transactions by network coding to generate a composite message; sending the composite message to one or more nodes in the network; as well as determining an adjusted time period based on a balance constant parameter and a number of trades in a plurality of incoming trades received during the time period; wherein determining the adjusted time period comprises determining the adjusted time period based on the balance constant parameter divided by the number of transactions; wherein the balance constant is determined based on a throughput of a neighboring node; determining an average time period based on the plurality of adjusted time periods and storing the average time period in a memory at one of the nodes; and The averaging time period is sent to one or more neighboring nodes in the network of nodes.

8. The method according to claim 7, further comprising: The receiving, combining and transmitting operations are iteratively repeated using the adjusted time period and after each iteration a further adjusted time period is determined for use in a subsequent iteration.

9. The method according to claim 7, wherein: Determining the adjusted time period is subject to a minimum time period that the adjusted time period cannot fall below and a maximum time period that the adjusted time period cannot rise above.

10. The method of claim 7, further comprising initializing the equilibrium constant parameter based on one or more throughput estimates for one of a plurality of links connected to the one of the nodes.

11. The method of claim 7, further comprising initializing the equilibrium constant parameter based on an estimated initial time period and an estimated number of initial transactions.

12. The method according to claim 7, further comprising: A determination is made that a number of transactions received within the time period exceeds a minimum number to use network coding, and wherein the combining and sending is dependent upon the determination.

13. A non-transitory processor-readable medium storing processor-executable instructions to participate in a transaction between a plurality of participating nodes, wherein: When the processor of one of the participating nodes executes the processor-executable instructions, the processor is caused to perform the method of any one of claims 7 to 12.

Images