Optimizing network parameters to enable network coding.

Abstract

The present invention provides a method and apparatus for propagating transactions in a network of nodes. [Solution] Each node has one or more connections to other nodes. This method includes: receiving a plurality of incoming transactions over 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 adjustment period based on a balance constant parameter and the number of transactions of the plurality of incoming transactions received over the period.

Description

[Technical Field]

[0001] The present invention relates, in general terms, to the propagation of transactions in a network, and more specifically, to a method and apparatus for improving the processing speed of transactions.

[0002] This document uses the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These forms include, but are not limited to, consensus-based blockchain and transaction chain technologies, permitted and unauthorized ledgers, shared ledgers, and their variations. While the most widely known application of blockchain technology is the Bitcoin ledger, other blockchain embodiments have been proposed and developed. For convenience and illustrative purposes, Bitcoin may be referenced herein, but it should be noted that the present invention is not limited to use in the Bitcoin blockchain, and alternative blockchain embodiments and protocols are also within the scope of the invention. [Background technology]

[0003] A blockchain is a consensus-based electronic ledger, implemented as a computer-based, decentralized system composed of blocks, each block consisting of a transaction. Each transaction (Tx) is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and each transaction contains at least one input and at least one output. Each block contains the hash of the previous block, so these blocks are chained together to create a persistent, immutable record of all transactions written to the blockchain from its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs, which specify who can access the transaction's output and how. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] When a network node receives a new transaction, it attempts to quickly push that transaction to other nodes in the network. Before sending a new transaction to other nodes, it is "validated." In other words, validation means that the transaction is checked against a set of criteria to ensure that the transaction meets the basic requirements of a proper transaction according to the applicable blockchain protocol.

[0005] To write a transaction to the blockchain, the transaction is incorporated into a block by nodes designed to collect transactions and form the collected transactions into blocks ("miners" or "mining nodes"). Next, the miners attempt to complete a "proof of work" with respect to the node. Multiple miners across 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 miner adds their verified block to the blockchain, and this block propagates through the network, thereby allowing other nodes holding copies of the blockchain to update the record. Those nodes receiving the block "verify" the block and all the transactions within it to ensure that it conforms to the formal requirements of the protocol.

[0006] It is beneficial to enable or promote the use of widely cryptographically secure exchanges using blockchain-based networks like Bitcoin. Such exchanges may relate to payment processing, such as credit card transactions. However, a transaction throughput of approximately 3 transactions per second is insufficient to handle such electronic payments, which currently operate at a transaction volume of approximately 50,000 per second. One bottleneck related to the speed of blockchain networks is transaction propagation. Each node receiving a transaction verifies the transaction and then sends the verified transaction to its peer node. In practice, in the Bitcoin protocol, a node sends an INV message containing a list of transactions to its peer node and receives a GETDATA response message that selects some subset of the transactions notified in the INV message. The node then sends the requested transactions to its peer node. This process is performed for each peer node to which the node is connected.

[0007] Therefore, it would be desirable to find solutions to the speed and scalability constraints that currently limit the capabilities of blockchain, thereby improving the speed of transaction propagation and enabling the processing of large volumes of transactions. It would also be desirable to find solutions that are more generally applicable to the propagation of transactions in a network of nodes, regardless of whether it is a blockchain or other application. [Overview of the project]

[0008] Such solutions are currently being proposed.

[0009] Thus, the present invention provides a method and apparatus as defined in the appended claims.

[0010] This application describes and discloses a method and apparatus for enabling the rapid propagation of transactions (Tx). In some examples, nodes selectively enable the use of network coding to combine transactions into a single message for sending to peer nodes. The selective use of network coding may be based on the determination that a node is a potential bottleneck. The solution can be applied in the context of a blockchain network in some embodiments.

[0011] In additional or alternative embodiments, the present invention describes a computer-implemented method for propagating transactions in a network of nodes, each node having one or more connections to other nodes. This method, implemented on one of the nodes, includes the steps of: determining that one of the nodes is a bottleneck in transaction propagation; receiving a plurality of new transactions from one or more first nodes in the network of nodes over a first period; combining the plurality of new transactions using network coding and local encoding vectors to generate a message; and sending the message and global encoding vectors to one or more second nodes in the network of nodes, instead of sending the plurality of new transactions to one or more second nodes.

[0012] In additional or alternative embodiments, the Application describes a node comprising a processor, memory, a network interface, and an application that includes instructions, which are executed by the processor and which perform one or more of the methods described herein.

[0013] In some embodiments, a method or node determines that a node is a bottleneck by evaluating the number of in-links to the node and the number of out-links from the node, and determines that the node is a bottleneck if the number of in-links exceeds the number of out-links. The evaluation may be performed when the first transaction of a group of new transactions is received. In another embodiment, the evaluation may be performed by tracking the in-link count and out-link count over time, with the number of in-links being average and the number of out-links also being average. In some exemplary embodiments, a node initiates the determination that it is a bottleneck in response to the receipt of the first transaction of a group of new transactions.

[0014] In some embodiments, the steps of joining and sending are performed in response to the determination that a termination condition has been met. In one example, the termination condition is the end of a period since either the reception of the first transaction among several new transactions or the determination that one of several nodes is a bottleneck. In another example, the termination condition is that several new transactions have reached the maximum number of new transactions.

[0015] In some embodiments, the message length is not longer than the longest transaction among multiple new transactions.

[0016] In additional or alternative embodiments, the present invention describes a node that propagates transactions in a network of nodes, each node having one or more connections to other nodes. A node includes a processor; memory; a network interface; and an application containing processor-executable instructions. When executed by the processor, the instructions cause the processor to: receive a plurality of incoming transactions over a period of time; combine the plurality of 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 adjustment period based on a balance constant parameter and the number of transactions of the plurality of incoming transactions received over that period.

[0017] In a further additional or alternative aspect, the present application describes a method implemented on a computer that propagates transactions in a network of nodes, where each node has one or more connections to other nodes. The method implemented at one of the nodes includes receiving a plurality of incoming transactions over a period of time; combining the plurality of incoming transactions using network coding to generate a composite message; transmitting the composite message to one or more nodes within the network; and determining an adjustment period based on an equilibrium constant parameter and the number of transactions of the plurality of incoming transactions received over that period.

[0018] In some embodiments, it includes repeating the receive, combine, and transmit operations using the adjustment period, and determining a further adjustment period after each iteration for use in subsequent iterations.

[0019] In some embodiments, the step of determining the adjustment period includes determining the adjustment period based on a value obtained by dividing the equilibrium constant parameter by the number of transactions. In some cases, the step of determining the adjustment period depends on a minimum period that should not be exceeded and a maximum period that should not be exceeded.

[0020] Some embodiments include determining an average period based on a plurality of adjustment periods and storing the average period in the memory of one of the nodes. In some cases, the average period is transmitted to one or more adjacent nodes within the network of nodes.

[0021] Some embodiments include initializing the equilibrium constant parameter based on one or more throughput estimates for one or more links to one of the nodes. Still other embodiments may include initializing the equilibrium constant parameter based on an estimated initial period and an estimated initial number of transactions.

[0022] Some embodiments include the step of determining that the number of transactions received within a period exceeds the minimum number required to use network coding, and the steps of combining and transmitting are conditional on that determination.

[0023] In additional or alternative embodiments, the present invention describes a non-transient processor-readable medium for storing processor-executable instructions for propagating transactions within a network of nodes, wherein, when executed by a processor on one of the nodes, the processor causes the processor to perform one or more of the methods described herein.

[0024] Many of the embodiments described herein specifically refer to blockchain transactions. However, it will be understood that the methods and apparatus described herein can be implemented and applied in relation to non-blockchain transaction propagation. [Brief explanation of the drawing]

[0025] These and other aspects of the present invention will be described with reference to the embodiments described herein, which will become apparent therefrom. Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings, merely as examples. [Figure 1] This diagram shows an exemplary network related to blockchain. [Figure 2] This diagram schematically shows an exemplary node having an input buffer and an output buffer. [Figure 3] This figure shows a simplified, illustrative network of nodes within a network. [Figure 4] This figure shows the network at a different point in time. [Figure 5] This diagram schematically illustrates a portion of an exemplary network. [Figure 6] This diagram shows a node with multiple in-links and one out-link. [Figure 7]This diagram, presented in flowchart format, illustrates an exemplary process of transaction propagation within a network of nodes. [Figure 8] This diagram, presented in flowchart format, illustrates another exemplary process of transaction propagation within a network of nodes. [Figure 9] This figure shows an example of a network of nodes for propagating transactions. [Figure 10] This diagram, in flowchart format, illustrates an exemplary method of propagating a transaction using network coding that includes an adjustable timeframe. [Figure 11] This diagram, in flowchart form, illustrates an exemplary method of selectively propagating transactions using network coding that includes adjustable timeframes. [Figure 12] This diagram shows an exemplary blockchain node in block diagram format. [Modes for carrying out the invention]

[0026] In this application, the term "and / or" is intended to encompass all possible combinations and subcombinations of the enumerated elements, and may include only one of the enumerated elements, a subcombination, or all of the elements, but may not necessarily exclude additional elements.

[0027] In this application, the phrase "at least one of... or..." is intended to encompass any one or more of the enumerated elements, and may include only one of the enumerated elements, a subcombination, or all of the elements, without necessarily excluding additional elements, and without necessarily requiring all of the elements.

[0028] First, we refer to Figure 1, which shows an exemplary network related to a blockchain, which may be referred to herein as Blockchain Network 100, in block diagram form. Blockchain Network 100 is a peer-to-peer open membership network that anyone can join without invitation or consent from other members. Distributed electronic devices running 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.

[0029] The electronic devices that execute the blockchain protocol and form a node 102 of the blockchain network 100 may be of various types, including computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or other electronic devices.

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

[0031] Node 102 maintains a global ledger on the blockchain of all transactions grouped into blocks, with each block containing the hash of the previous block within 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 node 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. Details of the implementation and operation of blockchain networks, such as those using the Bitcoin protocol, will be understood by those skilled in the art.

[0032] Typically, each transaction has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify who can access the transaction's outputs and how. A transaction's output may be an address to which a value is transferred as a result of the transaction. That value is associated with the output address as an unused transaction output (UTXO). Subsequent transactions may reference that address as input to use or distribute that value.

[0033] Node 102 can be of different types or categories depending on their functions. It is suggested that Node 102 has four basic functions associated with it: wallet, mining, full blockchain maintenance, and network routing. Variations of these functions are possible. Node 102 can have multiple functions. For example, a "full node" provides all four functions. For example, a lightweight node, which can be implemented in a digital wallet, may only have wallet and network routing functions. A digital wallet can keep track of block headers rather than storing the entire blockchain, and the block headers act as an index when a block is queried. Node 102 communicate with each other using connection-oriented protocols such as TCP / IP (Transmission Control Protocol).

[0034] In most blockchain networks, regardless of the management protocol, it is advantageous to ensure that new transactions propagate quickly across the network so that all nodes maintaining a pool of unconfirmed transactions (typically called a "mempool") have an accurate database of all transactions to date that are waiting to be included in a new block. Mining nodes utilize this pool of unconfirmed transactions to construct potential new blocks. In some cases, mining nodes maintain a complete mempool locally so that they can assemble unconfirmed transactions into a new block for mining. In some embodiments, a separate network of nodes (which may be called verification nodes, etc.) can manage and maintain the mempool, sending sets of unconfirmed transactions from the mempool to mining nodes so that the mining nodes can attempt to mine a block. In some embodiments, the mempool can be stored in a distributed hash table among multiple nodes. Regardless of the structure, it is desirable that new transactions propagate across the network and reach the necessary nodes as quickly as possible. It is also desirable that successfully mined new blocks propagate across the network as quickly as possible to reduce the occurrence of orphaned blocks.

[0035] For example, in the current implementation of the Bitcoin network, each node receiving a new transaction validates the transaction and, if the node has not yet received a new transaction, sends the validated transaction to all connected nodes. In the case of Bitcoin, nodes use TCP / IP (Transmission Control Protocol). A node receiving a new transaction sends an INV message to each peer node with data about the available new transaction and receives GETDATA messages from each node interested in receiving the new transaction. The node then sends the transaction in a (separate) TCP message to each node that requested the transaction.

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

[0037] The estimated time to process incoming transactions is the input queue (queues) L iWhile the average length (per packet) of the output queue L0 is the primary factor, the estimated time to correctly send a processed transaction depends on the average length of the output queue L0. Therefore, efficient transaction relay depends on L i It relies on the reduction of both the value and the L0 value. However, the probabilistic model for selectively relaying transactions to peers directly affects L0 and is induced by L i It also affects that.

[0038] In the current implementation of Bitcoin, INV and GETDATA message packets are queued in the I / O buffer in the same way as transactions, which has a serious impact on transmission and reception delays.

[0039] There are proposals for using blockchain for high-volume, high-speed transactions. For example, consider using blockchain for processing payments. Payment processing could include, for instance, credit card transactions. The volume of such transactions would overwhelm current embodiments of blockchain networks. Therefore, providing methods and devices to improve the communication processing capabilities of blockchain networks, such as sending transactions between nodes, would be beneficial.

[0040] According to one aspect of the present invention, a blockchain node buffers new transactions over a specific period of time, then uses network coding to combine the transactions into a single message, and then sends this combined message to one or more other blockchain nodes. In other words, the blockchain node generates a combined message that encodes the new transactions and mixes them in a way that allows the new transactions to be decoded. The combined message is the maximum size of the transactions plus a small overhead.

[0041] When a blockchain node uses network coding, the node sends all new transactions in encoded message form, rather than letting the node choose which subset of new transactions it wants to receive. This eliminates the need for the node to rely on TCP / IP INV and GETDATA messages.

[0042] Next, refer to Figure 3, which shows a simplified, exemplary network of nodes within blockchain network 300. Each node represents a network terminal (i.e., a blockchain node), while the edges represent links between nodes. For illustrative purposes, we assume that one bit can be sent and received at a time across each link.

[0043] Two nodes, labeled as sources S1 and S2, receive two new transactions, Tx1 and Tx2. In blockchain network 300 in this example, each node maintains a memory pool of unconfirmed transactions, so when a node receives a new transaction, that transaction is propagated across the network to all other nodes. Each node verifies and stores the new transaction in its local memory pool and forwards it to peer nodes that do not yet have the new transaction. Due to the peer-to-peer nature of blockchain network 300, not all nodes receive new transactions simultaneously, meaning it takes time for a new transaction to reach all nodes in network 300. For example, in the current embodiment of the Bitcoin network, it takes an average of 3.5 seconds for a new valid transaction to reach 90% of the nodes in the Bitcoin network. Theoretically, if transaction transmission were instantaneous, for example, t=0 to reach all nodes in the network, the network would be protected from potential double-use attacks. Therefore, improving the throughput of a blockchain network is a crucial element for achieving overall system scalability and reliability.

[0044] Two nodes in blockchain network 300 are labeled as receivers R1 and R2. Nodes I1 and I2 represent intermediate nodes that may or may not store copies of the memory pool, but more clearly represent the bottleneck in network 300 at time t. When node I1 receives two new transactions Tx1 and Tx2 nearly simultaneously, it needs to decide which transaction to send first. In other words, the outgoing edge from I1 to I2 becomes a bottleneck at least at time t.

[0045] Using network coding, node I1 can combine new transactions Tx1 and Tx2 into a composite message M of the same size as the larger of Tx1 and Tx2. Node I1 then sends message M to node I2, which forwards message M to receivers R1 and R2. Receivers R1 and R2 can then recover the individual transactions Tx1 and Tx2. For example, receiver R1 receives Tx1 and M. Since M is based on the combination of Tx1 and Tx2, R1 can derive Tx2 simply by solving the equation (Tx1, Tx1+Tx2). In contrast, R2 receives Tx2 and needs to solve the equation (Tx2, Tx1+Tx2) to derive Tx1.

[0046] Bottlenecks can appear or disappear over time, depending on the network configuration and where transactions are generated at a given time. A bottleneck is a link (edge) between nodes that significantly limits network performance, and in the case of blockchain networks in particular, it slows down the transmission speed of transactions (or blocks). However, the cause of the bottleneck (the link between nodes) lies within the nodes themselves.

[0047] Referring now to 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, node I1 again becomes a bottleneck, however this time because both Tx2 and Tx3 arrive at node I1 simultaneously with respect to the link between node I1 and node S1. Using network coding, node I1 can combine Tx2 and Tx3 into message M'.

[0048] One option is to apply network coding to all nodes in all situations. However, it is possible to further improve performance by selectively applying network coding to specific nodes that are expected to be advantageous at that time. For example, a node can selectively or adaptively apply network coding to message transmission if it can determine whether it represents a bottleneck at a given time, but if it is not a bottleneck, it can use normal transaction transmission.

[0049] Therefore, a node can be configured to evaluate or determine whether it may become a bottleneck at a given time. In a sense, this can be determined based on the balance between in-links and out-links. That is, at a given time, a node may receive transactions on one or more links and attempt to send those transactions on one or more links. Connections between nodes (i.e., edges) can function as in-links or out-links at a given time, depending on the flow of traffic in the network. The number of in-links is sometimes called "fan-in," and the number of out-links is sometimes called "fan-out."

[0050] In one embodiment, at least several nodes in the blockchain network maintain a table or other data structure that tracks the relative number of fan-in and fan-out links to first-neighbor nodes. Figure 5 schematically illustrates an exemplary portion of the network where a first node I1 and a second node I2 each locally store a table or other data structure, which identifies the amount of fan-in and fan-out for that node at a given point in time. Based on the relative number of fan-in and fan-outs, a node can determine whether it is potentially a bottleneck. Generally, this determination may be based on whether the number of in-links (fan-in) exceeds the number of out-links (fan-outs), in which case the node may be a bottleneck at that time.

[0051] In one embodiment, the evaluation of whether a node is a bottleneck is performed over a period ΔT. The quantities in the table may be the average fan-in and fan-out over the period ΔT.

[0052] In some embodiments, the determination may be partly based on an understanding of the network topology. For example, peripheral nodes are rarely bottlenecks, while intermediate nodes are more likely to become bottlenecks, at least in some cases.

[0053] In yet another embodiment, the determination of whether a node is a bottleneck may be based on the status of the output queue or an evaluation of the output queue backlog over time.

[0054] In some embodiments, determining or identifying a bottleneck may involve a combination or subcombination of the factors described above.

[0055] Network coding was developed less than 20 years ago as an alternative to the dominant packet-switched networks of the time. Network coding models a network as a directed graph (N,L) with link capacity, showing that a node n∈N can transmit information to a set of receivers R⊆N at a rate that achieves broadcast capacity h, where h is the minimum cut value between s and r∈R, provided that it is encoded at the internal nodes of the network.

[0056] A cut C is defined as dividing the vertex V of a graph G=(V,E) into two disparate subsets S and T. The cut set of cut C=(S,T) is the set of edges {(u,v)∈E|u∈S,v∈T}, where one endpoint is in S and the other endpoint is in T.

[0057] An example of a network coding methodology is described in PA Chou, Y. Wu, and K. Jain, “Practical Network Coding”, in Proceedings of the annual Allerton conference on communication control and computing, v.41, pp. 40-49, The University (2003) (hereinafter “Chou”), which is incorporated herein by reference. This methodology eliminates the need for intensive knowledge of network topology or encoding or decoding functions. Chou states that a network N can be represented as an acyclic graph G=(V,E) having unit capacity edges(e), a sender s∈V, and a certain number of receivers T⊆E. The output of each edge e∈E of node v=in(e) has the symbol y(e), which is a linear combination of symbols y(e') on the edges e' entering v. Figure 6 shows node v and output y(e). In particular, the output is given by the following equation:

number

[0058] Chou states that the output y(e) on any edge e ∈ E is a linear combination of source symbols

Number

Number

Number

[0059] The global encoding vector of the transmitting edge e may be characterized as being based on the local encoding of the global encoding vector of the receiving edge e’.

[0060] It will be understood that network coding can be used to propagate transactions across a network. Network coding can also be used within an overlay network designed to implement a distributed hash table of unconfirmed transactions where each transaction is stored by at least two nodes, ensuring redundancy within the distributed hash table. In this case, network coding can be used to send a transaction to two or more nodes for storage. However, using network coding may offer an additional advantage: the transaction can be recovered even if two or more nodes storing it are lost. Since the intermediate nodes receive one or more messages containing the combined data related to the transaction, they can recover the missing transaction from the network-coded messages.

[0061] Referring now to Figure 7, which shows an exemplary process 700 for propagating a transaction in a blockchain network in flowchart form. Process 700 is carried out by nodes in the blockchain network. In this context, a node may be understood to refer to a mining node, a full node, a verification node, or any other type of discrete blockchain node in the blockchain network. A node is a computing device that includes network connectivity, computing resources, and execution software that implements the blockchain protocol.

[0062] In operation 702, a node determines that it is a potential network bottleneck at time T. This determination may be based on a comparison of fan-in and fan-out at time T, as described above. For example, if the fan-in exceeds the fan-out at time T, the node may be determined to be a bottleneck. Other factors may be considered alternatively or additionally when determining whether a node is a bottleneck. Examples include average fan-in and fan-out over a period of time, the node's location in the network topology, the current or past status of the node's output queue, or other factors related to the node's capacity to propagate received transactions.

[0063] In operation 704, if a node is determined to be a bottleneck, it accumulates transactions over a period of ΔT. This period can be a predetermined length of time. In some implementations, the period may vary based on network traffic measurements, geographical information, or both. The period is not fixed; rather, transaction accumulation may occur until a minimum number of transactions are received, and since accumulated transactions may not be retained for long, it could potentially reach a maximum time.

[0064] In operation 706, multiple transactions accumulated by a node are combined into a single message using network coding. In some embodiments, the message may be the same length as the longest transaction. In some embodiments, the message length (in bits) may not exceed the longest transaction length. The message is generated using a local encoding vector and a network coding algorithm.

[0065] Next, in operation 708, the node sends the message and global encoding vector to one or more nodes. Instead of sending the actual transaction, the message is sent. That is, the node does not send multiple accumulated transactions, but instead sends the message and global encoding vector to all peer nodes on the outlink.

[0066] Referring now to Figure 8, which shows an exemplary method 800 for propagating transactions in a blockchain network in flowchart form. As described above, method 800 can be implemented on blockchain nodes having multiple in-link and out-link nodes.

[0067] In operation 802, the blockchain node receives a transaction. The received transaction is received via inlink. The blockchain validates the transaction against protocol requirements to confirm its legitimacy. In operation 804, the node may determine whether it is a bottleneck with respect to the transaction. This determination may be based on an assessment of the balance between inlink (fan-in) and outlink (fan-out) at that time. As mentioned above, the determination may also be based on other factors.

[0068] If the node determines that it is not a bottleneck, in operation 806, the node forwards the transaction via outlink to one or more peer nodes in the blockchain network as usual. However, if the node determines that it is likely to be a bottleneck, in operation 807, the node stores the transaction in memory (e.g., a buffer or other memory element).

[0069] As shown by operation 808, the node continues to receive transactions and stores them until it is determined that a termination condition has been met. In this example, the termination condition is the elapsed duration ΔT. The duration can begin, for example, from the determination that the node is a bottleneck, or from the reception of the first transaction in operation 802. Other conditions can be used instead of duration, such as the accumulation of the maximum number of transactions in memory, or a combination of such factors.

[0070] When the stop condition is met, for example, when ΔT has elapsed, the node constructs message M from the stored transactions using the network coding and local encoding vectors, as shown in operation 812. In operation 814, the node sends this message and global encoding vector to other nodes via all external links.

[0071] Adjustable period for network coding In some embodiments, the period ΔT may not be fixed; that is, a node may adjust ΔT from time to time based on network characteristics or transaction traffic entering or leaving the node. In some embodiments, the period ΔT is adjusted after each period ΔT has ended, so that the period is always adapted to the current traffic level. In some embodiments, adjustments to the period ΔT are constrained to a minimum and maximum period. In some embodiments, the period ΔT is adjusted only periodically, such as after every 2, 5, 10, or other periods, or only when the determined adjustment changes the period by more than a threshold amount or percentage.

[0072] To adapt to traffic conditions, nodes can operate in terms of "throughput." A node may have in-links and out-links to several other nodes in the network. Next, refer to Figure 9, which schematically shows an exemplary network of node 900. Node N3 has input / output links to nodes N1, N2, N4, N5, and N6. These nodes can be characterized as (logical) first neighbor nodes. Generally, nodes are aware of their first neighbor nodes; that is, these nodes directly receive transactions (without going through other nodes in the network) or directly send transactions. Note that a "first neighbor node" does not necessarily have to be geographically close and may be reachable by traversing many network elements and links (except via other nodes).

[0073] Node N3 tracks the first neighboring node of the table stored locally on node N3, as shown in the example in Table 1 below. [Table 1]

[0074] In the example above, node N3 receives messages of size s from the nodes in the table via each inlink. i This tracks the size s0 of messages sent to nodes in the table via each outlink. Link throughput can be assumed to be evenly allocated between input and output; that is, the channel bandwidth is evenly divided, but this assumption is not always true. However, based on this assumption, the throughput Tr of a link or channel over the analysis period is given by the following equation.

number

[0075] It will be understood that the assumption that in-link and out-link throughputs are equal may not be respected in actual embodiments. Therefore, the balance parameter γ∈[0,1] can be defined as the input / output throughput ratio as follows:

number

[0076] In the above formula, the parameter ΔT represents the period over which the size of messages sent and received is measured. It should be noted that the above formula does not represent the actual maximum throughput Tr of a channel or link; rather, the throughput Tr of a link or channel must be at least as large as indicated by the actual usage data (the size of messages actually sent / received). Therefore, in some cases, the throughput Tr of a link may be estimated based on historical usage data, such as measurements of the size of messages sent and received over the link.

[0077] Link throughput (Tr) can be estimated using several other empirical data points. For example, in the case of a network operating on TCP / IP (i.e., Bitcoin is one example), the TCP Receive Window (RWIN) and Round Trip Time (RTT) can sometimes be used to determine the link throughput. RWIN indicates the amount of data a node can receive without sending an acknowledgment to the sender and may be determined by the appropriate communication protocol used on the network. RTT is a measure of the time it takes for a negligible message to travel from a node at one end of a link to a node at the other end of the link and back, and may sometimes be called a ping message, etc.

[0078] Other mechanisms are also available to determine throughput Tr, including obtaining throughput information from neighboring nodes, using preset or predetermined throughput estimates, or using other sources of throughput estimates.

[0079] In some embodiments of the present application, a node may maintain locally stored information relating to throughput estimates for its various links. A link may be a link to a first neighboring node. For example, Table 1 above could be modified to include a column relating to the throughput estimate for each link. [Table 2] The node may further determine the median or average throughput of the available links.

[0080] As discussed above, network coding, instead of propagating individual messages, combines a set of transactions received over a period ΔT to generate a composite message M, which is then sent from the node via the outlink. In some embodiments of the present application, the period ΔT may be based at least in part on throughput and the number of transactions received.

[0081] Throughput can be set based on the median or average throughput of the available links on the node, as described above.

[0082] Alternatively, in some cases, a node may initialize its throughput to a global estimated throughput value based on several assumptions about the network. For example, the period ΔT may first be initialized to a preset value, the number of transactions to an estimated preset value, and from there the estimated throughput may be determined. In a particular example of the Bitcoin network, the preset period ΔT may be 3.5 seconds, because this is the approximate time required for a transaction to reach 90% of the nodes in the Bitcoin network. The period ΔT may be initialized to a different value in other embodiments. The number of transactions that can be received within the period ΔT may initially be assumed to be a preset value. In a particular example of the Bitcoin network, the number of transactions N may be initialized to 500, based on the fact that (in the current embodiment of Bitcoin) an average block contains approximately 2000 transactions, and 2000 divided by 3.5 is approximately 500. Other initialization values ​​may be used in other embodiments.

[0083] Once initial values ​​for the period ΔT and the number of transactions are selected, the relationship between these parameters can be established as the product of the period ΔT and the number of transactions. K = ΔT0·N0 Here, K is set as a constant inversely proportional to the period ΔT and the number of transactions N. In the above equation, ΔT0 is the initial value of the period ΔT, and N0 is the initial value of the number of transactions received. In other embodiments, as described above, the constant K may be initialized based on other assumptions or measurements. The constant K is related to the throughput Tr insofar as it relates to the inverse relationship between N and ΔT, and if each of the N transactions has a certain size, then the N transactions receive a certain amount of data over a period of ΔT, e.g., s i This represents the cumulative result. In some cases, the constant K may be determined in part based on the estimate or target throughput Tr.

[0084] The relationship between the throughput Tr concept and the constant K is expressed by the following equation. Tr i=N i-1 (Overall size / K)

[0085] Once an initial constant K is determined, the node monitors the number of transactions actually received in-link during the process of ΔT and decides whether to adjust ΔT. In at least one embodiment, the adjustment of ΔT is based on the number of transactions received in at least one previous ΔT and the constant K. For example, ΔT i One mechanism for determining this is given by the following equation. ΔT i =K / N i-1 Here, i is the index. In this simple example, ΔT at time i is based on the number of transactions received in the previous ΔT, and K is a constant. In a sense, K can be labeled as a balance constant as long as it is based on the product of the period and the number of transactions, and the period can be lengthened to try to maintain the balance constant, to the extent that too few transactions are received within the period to satisfy the balance constant.

[0086] In another exemplary embodiment, the number of received transactions is the previous period ΔT i-1 The calculation does not have to be based solely on one period; instead, it may be based on the average of two or more previous periods. In some cases, the average may be determined as a weighted average, giving greater weight to more recent periods.

[0087] In other exemplary embodiments, throughput may be adjusted over time based on one of several factors. For example, the constant K may be initialized based on the median or average throughput from one or more neighboring nodes.

[0088] Referring now to Figure 10, which shows in flowchart form one exemplary method 1000 for propagating a transaction in a network of nodes using network coding. Method 1000 is implemented on one of the nodes in the network of nodes. In this example, the node is configured to use network coding for transaction propagation.

[0089] In operation 1002, certain parameters may be initialized. For example, the initial period ΔT0 may be set to a predetermined value. As described above, in some cases, the initial period T0 may be set to a value derived from the current period ΔT used by the neighboring node. In some cases, the initial period may be calculated based on a predetermined throughput value and the expected number of transactions. The initial period ΔT0 may be determined using other mechanisms, including the above combinations.

[0090] Optionally, the number of transactions N0 can also be initialized if that parameter is used to determine the initial period ΔT0 or the constant K, i.e., the equilibrium constant. In some cases, the constant K can be determined using the number of transactions N0, for example, using the following formula: K = ΔT0·N0

[0091] In some cases, the number of transactions N0 can be used as a criterion for determining the initial period ΔT0 using a given constant K, for example, by the following formula: ΔT0 = K / N0

[0092] The constant K can be determined using the initial period ΔT0 and the number of transactions N0, but in other cases, it can be set to a preset or a predetermined equilibrium constant. When the network changes, the node may update a predetermined value of constant K if changes in the network or protocol used affect the possible properties of the links to the node, affecting the transaction volume and / or throughput. In some cases, the constant K can be determined empirically. For example, the constant K can be determined using historical data on throughput. In another example, as mentioned above, the constant K can be determined based on round-trip time testing. In yet another example, the constant K can be determined based on throughput data from one or more neighboring nodes. As an example, the current node may average the throughput values ​​related to its neighboring nodes, use that average value to estimate the equilibrium constant, and arrive at the constant K.

[0093] In operation 1004, after initializing at least the initial period ΔT0 and the constant K, the node receives a transaction in its inlink. The transaction is buffered in the node's memory. As shown by operation 1006, the node receives a transaction during the period ΔT i It continues to receive and hold transactions on that inlink until it finishes. It will be understood that i is simply an index, and i is initially set to 0.

[0094] When the period ends, operation 1008 sends the transaction using network coding. This involves using network coding operations to combine the transactions and generate message M, and sending this message through the node's outlink.

[0095] In operation 1010, index i is incremented, and the node, in operation 1012, for a period ΔT i Update the period ΔT. In this example, update the period ΔT. i This is a constant K, and the previous period ΔT i-1This is based on the actual number or count of transactions received during the period ΔT. i The adjustment may be subject to certain constraints, such as a maximum value that cannot be exceeded or a minimum value that cannot be fallen below. In some embodiments, the adjustment may be based on a number of previous periods and the number of transactions received within those periods. In some embodiments, different or additional constraints may be imposed on the period ΔT, such as a change of less than or equal to a certain percentage each iteration. i Adjustments may be required.

[0096] In this example, the node uses network coding to send a transaction in each iteration. In another exemplary embodiment, the node may selectively use network coding when the volume of transactions within a period justifies its use. Referring now to Figure 11, which shows an exemplary method 1100 for propagating a transaction in a network of nodes in flowchart form.

[0097] Operations 1102, 1104, and 1106 correspond to operations 1002, 1004, and 1006 in Figure 10 described above. In operation 1108, the node has enough transactions to justify using network coding ΔT i Evaluate whether a transaction was received. In some examples, this evaluation is based on the number of received transactions N. i The minimum number of transactions N specified for the use of network coding. min This includes making a comparison. If the minimum is met, in operation 1112, the transaction is sent using network coding. If the minimum is not met, in operation 1110, the transaction is sent using normal non-network coding transmission.

[0098] Operations 1114 and 1116 correspond to operations 1010 and 1012 in Figure 10 described above.

[0099] It will be understood that various operations or steps of exemplary methods 1000 and 1100 can be modified and, in some cases, omitted without changing the operating principle of the process. Additional operations not illustrated can also be added without changing the operating principle of the process. All such variations are intended to be included herein.

[0100] Each node may maintain a record of its current period ΔT (or, in some cases, a moving average period or a weighted average period, etc.) and periodically notify its neighboring nodes of its current period ΔT. In this way, each node can track the period ΔT used by its neighboring nodes. Thus, when a new node joins the network, instead of initializing its parameters using assumptions about the network, the node can initialize its parameters based on the parameters of its neighboring nodes. For example, a new node may take the period ΔT (or average period ΔT) used by its first neighboring node and set its initial period ΔT based on the average or other combination of periods of its neighboring nodes. This accelerates the adaptation of new nodes to the characteristics of the network and improves the rate of adaptation.

[0101] Next, referring to Figure 12, which shows a simplified example of a participating node 1200 in block diagram form, Node 1200 includes a processor 1202 which may include one or more microprocessors, application-specific integrated circuits (ASICs), microcontrollers, or similar computer processing units. Node 1200 further includes memory 1204 which may include persistent and non-persistent memory for storing values, variables, and possibly processor-executable program instructions, and a network interface 1206 which provides network connectivity via a wired or wireless network.

[0102] Node 1200 includes a processor-executable blockchain application 1208 which includes processor-executable instructions, and when an instruction is executed, causes processor 1202 to perform one or more of the functions or operations described herein.

[0103] It will be understood that the devices and processes described herein, as well as the modules, routines, processes, threads, applications, or other software components that implement the methods / processes described for configuring the nodes, can be implemented using standard computer programming techniques and languages. This application is not limited to specific processors, computer languages, computer programming conventions, data structures, or other details of such implementations.

[0104] The embodiments described above are illustrative, not limiting, of the present invention, and it should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. Reference numerals in parentheses in the claims should not be construed as limiting the claims. Words such as “comprising,” “composed” do not preclude the existence of elements or steps other than those enumerated throughout the claims or specification. In this specification, “comprises,” “composed” means “includes,” “including,” or “consists of,” “consisting of.” A singular reference to an element does not preclude a plural reference to such an element, and vice versa. The present invention can be carried out by hardware comprising several distinct elements and by a appropriately programmed computer. In apparatus claims that enumerate several means, some of these means are embodied by the same item of hardware. The mere fact that certain means are described in different dependent claims does not indicate that combinations of these means cannot be used advantageously.

[0105] The following is an example of the claims as originally filed. [Example 1] A node that propagates transactions in a network of nodes, where each node has one or more connections to other nodes, Processor and Memory and Network interface and, It includes applications that contain processor-executable instructions, When the aforementioned instruction is executed by the processor, the processor will: Receiving multiple incoming transactions over a certain period of time. Using network coding to combine the multiple incoming transactions and generate a composite message, Sending the composite message to one or more nodes in the network, and The system determines the adjustment period based on the balance constant parameter and the number of transactions of the multiple incoming transactions received over the aforementioned period. node. [Example 2] The node according to Embodiment 1, wherein, when the instruction is executed, the processor further causes the processor to repeatedly perform the receiving, combining, and transmitting operations using the adjustment period, and after each iteration to determine an additional adjustment period for use in subsequent iterations. [Example 3] The node according to Embodiment 1 or 2, wherein, when the instruction is executed, the processor determines the adjustment period by determining the adjustment period based on the value obtained by dividing the balance constant parameter by the number of transactions. [Example 4] The node according to Example 3, wherein determining the adjustment period depends on a minimum period that cannot be less than the adjustment period and a maximum period that cannot be more than the adjustment period. [Example 5] The node according to any one of Embodiments 1 to 4, wherein, when the instruction is executed, the processor further causes the processor to determine an average period based on a plurality of adjustment periods and to store the average period in memory. [Example 6] The node according to Embodiment 5, wherein, when the instruction is executed, the processor further causes the node to transmit the averaging period to one or more neighboring nodes in the node's network. [Example 7] The node according to any one of Examples 1 to 6, wherein, when the instruction is executed, the processor further initializes the balance constant parameter based on one or more throughput estimates for one or more links to one of the nodes. [Example 8] The node according to any one of Embodiments 1 to 6, wherein, when the instruction is executed, the processor further initializes the balance constant parameter based on the estimated initial period and the estimated initial number of transactions. [Example 9] The node according to any one of Embodiments 1 to 8, wherein, when the instruction is executed, the processor further determines that the number of transactions received within the period exceeds the minimum number required to use network coding, and the binding and transmission operation is conditional on that determination. [Example 10] A method for propagating transactions in a network of nodes, wherein each node has one or more connections to other nodes, and the method is performed on one of the nodes. A step of receiving multiple incoming transactions over a certain period of time, The steps include: combining the multiple incoming transactions using network coding to generate a composite message; The steps include sending the composite message to one or more nodes in the network, The process includes the step of determining an adjustment period based on a balance constant parameter and the number of transactions of the plurality of incoming transactions received over the said period, method. [Example 11] The method according to Example 10, further comprising the steps of repeatedly performing the receiving, combining, and transmitting operations using the adjustment period, and determining a further adjustment period after each iteration for use in subsequent iterations. [Example 12] The method according to Embodiment 10, wherein the step of determining the adjustment period includes determining the adjustment period based on the value obtained by dividing the balance constant parameter by the number of transactions. [Example 13] The method according to Example 12, wherein the step of determining the adjustment period depends on a minimum period that cannot be less than the adjustment period and a maximum period that cannot be more than the adjustment period. [Example 14] The method according to Embodiment 10, further comprising the steps of determining an average period based on a plurality of adjustment periods, and storing the average period in the memory of one of the nodes. [Example 15] The method according to Embodiment 14, further comprising the step of transmitting the averaging period to one or more neighboring nodes in the network of the node. [Example 16] The method according to Example 10, further comprising the step of initializing the equilibrium constant parameter based on one or more throughput estimates for one or more links to one of the nodes. [Example 17] The method according to Example 10, further comprising the step of initializing the balance constant parameter based on the estimated initial period and the estimated initial number of transactions. [Example 18] The method according to Embodiment 10, further comprising the step of determining that the number of transactions received within the period exceeds the minimum number required to use network coding, wherein the steps of combining and transmitting are conditional on that determination. [Example 19] A non-temporary processor-readable medium for storing processor-executable instructions for participating in a transaction between multiple participating nodes, wherein, when the processor-executable instructions are executed by the processor of one of the participating nodes, the processor causes that processor to perform the method described in any one of Examples 10 to 18.

Claims

1. A node that propagates transactions in a network of nodes, where each node has one or more connections to other nodes, Processor and Memory and Network interface and It includes applications that contain processor-executable instructions, When the aforementioned instruction is executed by the processor, the processor will: Receiving multiple incoming transactions over a certain period of time. Determining that the stopping condition has been met, Based on the fact that the aforementioned termination conditions have been met, The process involves combining the multiple incoming transactions using network coding to generate a composite message, wherein the length of the composite message is less than or equal to the length of the longest transaction among the multiple incoming transactions. To transmit the composite message to one or more nodes in the network, and The system determines the adjustment period based on the number of transactions in the multiple incoming transactions received over the aforementioned period and the balance constant parameter. node.

2. The node according to claim 1, wherein the balance constant is based on the product of the period and the number of transactions, and the adjustment period is determined based on maintaining the balance constant.

3. The node according to claim 1, wherein the termination condition includes the expiration of a period since the receipt of the first transaction of any of a plurality of incoming transactions.

4. The node according to claim 1, wherein the stop condition includes a determination that one of the nodes is a bottleneck.

5. The node according to claim 1, wherein the termination condition includes a plurality of new transactions exceeding the maximum number of incoming transactions.

6. When the aforementioned instruction is executed, the processor will: The node according to claim 1, wherein the receiving, coupling, and transmitting operations are iteratively repeated using the adjustment period, and further instructed to determine a further adjustment period for use in the next iteration after each iteration.

7. When the aforementioned instruction is executed, the processor will: The node according to claim 1, further instructed to determine the adjustment period by determining the adjustment period based on the value obtained by dividing the balance constant parameter by the number of transactions.

8. When the aforementioned instruction is executed, the processor will: The node according to claim 1, further instructing to determine an average period based on a plurality of adjustment periods and to store the average period in the memory.

9. When the aforementioned instruction is executed, the processor will: Initialize the equilibrium constant parameters based on one or more throughput estimates for one or more links to one of the nodes in question. Initialize the balance constant parameters based on the estimated initial period and the estimated initial number of transactions. The node according to any one of claims 1 to 8, further instructed to perform at least one of the following: determining that the number of transactions received within the period exceeds the minimum number required to use network coding, and that the joining and transmission are conditional on this determination.

10. A method for propagating transactions in a network of nodes, wherein each node has one or more connections to other nodes, and the method is performed on one of the nodes. Receiving multiple incoming transactions over a certain period of time. Determining that the stopping condition has been met, Based on the fact that the aforementioned termination conditions have been met, The process involves combining the multiple incoming transactions using network coding to generate a composite message, wherein the length of the composite message is less than or equal to the length of the longest transaction among the multiple incoming transactions. To transmit the composite message to one or more nodes in the network, and This includes determining an adjustment period based on the number of transactions in the plurality of incoming transactions received over the aforementioned period and a balance constant parameter, method.

11. The method according to claim 10, wherein the equilibrium constant is based on the product of the period and the number of transactions, and the adjustment period is determined based on maintaining the equilibrium constant.

12. The method according to claim 10, further comprising iteratively repeating the receiving, coupling, and transmitting operations using the adjustment period to determine a further adjustment period for use in the next iteration after each iteration.

13. The aforementioned method, Determining the adjustment period includes determining the adjustment period based on the value obtained by dividing the balance constant parameter by the number of transactions. Determining the aforementioned adjustment period includes being affected by the minimum period the adjustment period cannot be less than and the maximum period the adjustment period cannot be more than, or The method according to claim 10, further comprising determining an average period based on a plurality of adjustment periods and storing the average period in the memory of one of the nodes.

14. Initializing the equilibrium constant parameter based on one or more throughput estimates for one or more links to one of the nodes, or The method according to claim 10, further comprising at least one of initializing the balance constant parameter based on an estimated initial period and an estimated initial number of transactions.

15. The method according to claim 10, further comprising determining that the number of transactions received within the period exceeds the minimum number required to use network coding, and the joining and transmission are conditional on that determination.

16. A non-temporary processor-readable medium for storing processor-executable instructions for participating in a transaction between multiple participating nodes, wherein, when the processor-executable instructions are executed by the processor of one of the participating nodes, the processor causes that processor to perform the method according to any one of claims 10 to 15.

Images