Method and system for selectively using network coding to propagate transactions in a blockchain network

Abstract

A method and apparatus are provided that enable high-speed transaction propagation in a blockchain network. A process for propagating transactions in a blockchain network includes determining whether a node is a bottleneck for the propagation of transactions, receiving new transactions from one or more first nodes in the node's network via a network interface over a period of time ΔT if a determination is made that the node is a bottleneck, combining the new transactions using network coding and a local encoding vector to generate a message, and transmitting the message and the global encoding vector to one or more second nodes. If a determination is made that the node is not a bottleneck, using normal transmission of the transaction.

Description

[Technical field]

[0001] The present invention relates generally to propagating messages and data within a network, and more particularly to a method and apparatus for improving operation processing and transfer speeds. [Background technology]

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

[0003] A blockchain is a consensus-based electronic ledger, realized as a computer-based decentralized distributed system composed of blocks, which in turn are composed 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 contains at least one input and at least one output. Each block contains a hash of the previous block, so that blocks are chained together to create a permanent and immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs, which specify how and who can access the transaction's outputs. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

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

[0005] For a transaction to be written to the blockchain, it is assembled into a block by nodes ("miners" or "mining nodes") designed to collect transactions and organize them into blocks. Miners then attempt to complete a "proof of work" for the node. Miners 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. A successful miner adds its verified block to the blockchain, which is propagated through the network so that other nodes that maintain copies of the blockchain can update their records. A node that receives a block also "verifies" the block and all transactions within it to ensure that it complies with the formal requirements of the protocol.

[0006] It would be advantageous to use a blockchain-based network such as Bitcoin to enable or facilitate the use of a wide range of cryptographically secured exchanges. Such exchanges may be associated with payment processing, such as credit card transactions, for example. However, a throughput of approximately 3 transactions per second is insufficient to handle such electronic payments, which currently operate at a volume of approximately 50,000 transactions per second. One of the bottlenecks related to the speed of blockchain networks is the propagation of transactions. Each node that receives a transaction validates the transaction and then transmits it to a peer node. Indeed, in the Bitcoin protocol, a node sends an INV message containing a list of transactions to a peer node and receives a GETDATA response message selecting some subset of the transactions advertised in the INV message. The node then transmits the requested transactions to the peer node. This process is performed for each peer node to which the node is connected.

[0007] It is therefore desirable to find a solution to the speed and scalability constraints that currently limit the ability of blockchains to process large volumes of transactions by improving the speed of transaction propagation, and to find a solution that is more generally applicable to the propagation of transactions in a network of nodes, whether related to blockchain or other applications. Summary of the Invention

[0008] Such a solution is devised below.

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

[0010] This application describes and discloses methods and apparatus that enable rapid propagation of transactions (TX). In some examples, a node selectively enables the use of network coding to combine transactions into a single message for transmission to peer nodes. The selective use of network coding may be based on a determination that the node is a potential bottleneck. This solution may be applied in the context of a blockchain network in some implementations. When propagating a set of new transactions, a node that determines that it is a bottleneck may combine the new transactions using network coding and a local encoding vector to generate a message. The message is then transmitted to another node along with the global encoding vector.

[0011] In one aspect, the present application provides for selective use of network coding as blockchain network conditions change to dynamically determine whether a node is a bottleneck and, as a result, whether network coding should be used. The nature of blockchain networks and the importance of rapid propagation of transactions to all nodes in the network may make universal network coding unnecessary and computationally expensive, while selective use of network coding for nodes determined to be bottlenecks at the time may provide speed benefits without the unnecessary complexity and cost associated with blanket use of network coding for all node communications. The present application provides an efficient and effective mechanism for dynamically determining whether a node is a bottleneck in the context of a blockchain network.

[0012] In a further or alternative aspect, the present application describes a computer-implemented method for propagating transactions in a network of nodes, each node having one or more connections to other nodes, the method being implemented in one of the nodes and including the steps of determining that one of the nodes is a bottleneck for the propagation of transactions, receiving a plurality of new transactions from one or more first nodes in the network of nodes over a first time period, combining the plurality of new transactions using network coding and a local encoding vector to generate a message, and instead of sending the plurality of new transactions to one or more second nodes in the network of nodes, sending the message and the global encoding vector to the one or more second nodes.

[0013] In a further or alternative aspect, the present application describes a node including a processor, a memory, a network interface, and an application including instructions that, when executed by the processor, perform one or more of the methods described herein.

[0014] In some implementations, the method or node determines that a node is a bottleneck by evaluating the number of inlinks to the node and the number of outlinks from the node, and determining that the node is a bottleneck when the number of inlinks exceeds the number of outlinks. The evaluation may occur upon receipt of a first transaction of a number of new transactions. In another implementation, the evaluation may occur through tracking the count of inlinks and the count of outlinks over a period of time, where the number of inlinks is an average and the number of outlinks is an average. In some exemplary implementations, the node initiates the determination that it is a bottleneck in response to receiving the first transaction of a number of new transactions.

[0015] In some implementations, the combining and transmitting is performed in response to a determination that a stop condition has been met. In one example, the stop condition is the expiration of a time duration from either the receipt of the first of the new transactions or a determination that the one of the nodes is a bottleneck. In another example, the stop condition is that the number of new transactions has reached a maximum number of new transactions.

[0016] In some implementations, the message has a length no longer than the longest transaction among the new transactions.

[0017] In a further or alternative aspect, the present application describes a non-transitory processor-readable medium having stored thereon processor-executable instructions for propagating transactions within a network of nodes, the processor-executable instructions, when executed by a processor in one of the nodes, causing the processor to perform one or more of the methods described herein.

[0018] Many of the example implementations described herein make specific reference to blockchain transactions, however, it will be understood that the methods and apparatus described herein may also be implemented and applied in connection with non-blockchain transaction propagation. [Brief description of the drawings]

[0019] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment described hereinafter. One embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 illustrates an exemplary network associated with a blockchain. [Diagram 2] 1 illustrates a schematic diagram of an exemplary blockchain node having an input buffer and an output buffer. [Diagram 3] 1 illustrates a simplified exemplary network of nodes in a blockchain network. [Figure 4] 4 illustrates the blockchain network of FIG. 3 at a different time. [Diagram 5] 1 illustrates a schematic diagram of a portion of an exemplary blockchain network. [Figure 6] 1 shows a node with multiple inlinks and one outlink. [Figure 7] 1 illustrates, in flowchart form, an exemplary process for propagating transactions in a blockchain network. [Figure 8]1 illustrates, in flowchart form, another exemplary process for propagating transactions in a blockchain network. [Figure 9] 1 illustrates an exemplary blockchain node in block diagram form. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] In this application, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, without necessarily excluding additional elements.

[0021] In this application, the phrase "at least one of...or..." is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.

[0022] Reference is first made to Figure 1, which illustrates in block diagram form an exemplary 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 that anyone may join without an invitation or consent from other members. Distributed electronic devices running an instance of the blockchain protocol on which the blockchain network 100 operates may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol, or other cryptocurrency.

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

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

[0025] Nodes 102 maintain a global ledger of all transactions on the blockchain, grouped into 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 full or partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. The details of the implementation and operation of blockchain networks, such as those using the Bitcoin protocol, will be well understood by those skilled in the art.

[0026] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how and who can access the transaction's output. A transaction's output may be an address to which value is transferred as a result of the transaction. This value is associated with that output address as an unspent transaction output (UTXO). Subsequent transactions can then reference that address as an input to consume or disperse the value.

[0027] Nodes 102 may be of different types or categories depending on their functionality. It is suggested that there are four basic functions associated with nodes 102: wallet, mining, full blockchain maintenance, and network routing. There may be variations in these functions. A node 102 may have two or more of the functions. For example, a "full node" provides all four functions. A lightweight node, such as may be realized with a digital wallet, features only wallet and network routing functions. A digital wallet may keep track of block headers rather than storing the full blockchain. The block headers act as an index when querying blocks. Nodes 102 communicate with each other using a connection-oriented protocol such as TCP / IP (Transmission Control Protocol).

[0028] In most blockchain networks, regardless of the governance protocol, it is advantageous for new transactions to be propagated through the network quickly, thereby ensuring that all nodes that maintain a pool of unconfirmed transactions (typically called a "mempool") have an up-to-date and accurate database of transactions waiting to be included in a new block. Mining nodes utilize this pool of unconfirmed transactions to build potential new blocks. In some cases, mining nodes maintain a full mempool locally so that they can assemble unconfirmed transactions into new blocks for mining. In some embodiments, the mempool may be managed and maintained by a separate network of nodes (which may be called validator nodes), which can send a set of unconfirmed transactions from the mempool to the mining node to enable the mining node to attempt to mine the block. In some implementations, the mempool may be stored in a distributed hash table among multiple nodes. Regardless of the structure, it is desirable for any new transaction to be propagated through the network to reach the necessary nodes as soon as possible. Additionally, it is desirable for any new successfully mined blocks to be propagated as quickly as possible to reduce the occurrence of orphan blocks.

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

[0030] Reference is now made to Figure 2. Figure 2 diagrammatically illustrates 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 referenced as intA, intB, intC, intD, etc. The input buffer 202 represents incoming transactions from various peer nodes, and the output buffer 204 represents the transmission of a particular received transaction to a peer node through the respective interface. Network packets are sent and received serially at the application level according to primitives provided by the operating system of the node 202. Assuming that transaction x fits into a single Ethernet / IP packet, its transmission to m peers requires the buffering of m different output packets. Both input and output network packets contain, among other information, the serialized transaction and a logical interface ID representing the TCP / IP connection to the sending / receiving peer.

[0031] The expected time for an incoming transaction to be processed depends on the average length (in packets) of the input queue, Li, while the expected time for a processed transaction to be correctly transmitted depends on the average length of the output queue, Lo. Efficient relaying of transactions therefore depends on reducing the values ​​of both Li and Lo. However, a probabilistic model for selective relaying of transactions to peers directly affects Lo, and by induction also Li.

[0032] In the current Bitcoin implementation, INV and GETDATA message packets are queued in I / O buffers in the same way as transactions, severely impacting transmission and reception latency.

[0033] There are proposals to use blockchain for higher volume, high speed transactions. For example, the use of blockchain for processing payments is being considered. Payment processing may include, for example, credit card transactions. The volume of such transactions is overwhelming for current implementations of blockchain networks. It would therefore be advantageous to provide methods and apparatus that improve the capacity of blockchain networks to process communications, such as the transmission of transactions between nodes.

[0034] According to one aspect of the present application, a blockchain node buffers new transactions for a certain period of time and then uses network coding to combine the transactions into a single message, which is then sent to one or more other blockchain nodes. That is, the blockchain node generates a message that encodes the new transactions to generate a decomposable but combined message. The combined message has a size of the largest of the transactions plus a small overhead.

[0035] When blockchain nodes use network coding, they may stop relying on TCP / IP INV and GETDATA messages because they send all new transactions in the form of encoded messages, rather than forcing nodes to pick-and-choose which subset of new transactions they want to receive.

[0036] Reference is now made to Figure 3. Figure 3 illustrates a simplified exemplary network of nodes in a blockchain network 300. Each node represents a network terminal (i.e., a blockchain node), while edges represent links between nodes. For purposes of this illustration, it is assumed that for each link, it is possible to send or receive a single bit at a time.

[0037] Two of the nodes are labeled as sources S1 and S2, which receive two new transactions, tx1 and tx2. In this exemplary blockchain network 300, each node maintains a mempool of unconfirmed transactions, so when a node receives a new transaction, it is propagated through the network to all other nodes. Each node validates the new transaction, stores it in its respective local mempool, and forwards the new transaction to peer nodes that do not yet have the new transaction. Due to the peer-to-peer nature of the blockchain network 300, not all nodes receive the new transaction at the same time, which means that the new transaction takes some time to reach all nodes in the network 300. For example, in the current implementation of the Bitcoin network, a new valid transaction takes an average of 3.5 seconds to reach 90% of the nodes in the Bitcoin network. Theoretically, if the transmission of a transaction is instantaneous, e.g., t=0 to reach all nodes in the network, the network is protected from the possibility of double spending attacks. Therefore, improving the throughput of a blockchain network is a key factor in enabling scalability and reliability of the overall system.

[0038] Two of the nodes in the blockchain network 300 are labeled as receivers R1 and R2. Nodes I1 and I2 represent intermediate nodes that may or may not store a copy of the mempool, but more significantly represent a bottleneck in the network 300 at time T. When node I1 receives two new transactions Tx1 and Tx2 at approximately the same time, node I1 must decide which transaction to send first. That is, the outgoing edge from I1 to I2 is the bottleneck at least at time T.

[0039] Using network coding, node I1 can combine new transactions Tx1 and Tx2 into a composite message M that is the same size as the larger of Tx1 and Tx2. Node I1 sends message M to node I2, which forwards message M to receivers R1 and R2. Receivers R1 and R2 can 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 only needs to solve the equation (Tx1, Tx1+Tx2) to derive Tx2. Conversely, R2 receives Tx2 and needs to solve the equation (Tx2, Tx1+Tx2) to derive Tx1.

[0040] 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, which greatly limit the performance of the network and, specifically, in the case of blockchain networks, slow down the transmission of transactions (or blocks). However, the source of the bottleneck (links between nodes) is the node.

[0041] Reference is now made to Figure 4. Figure 4 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, there is again a bottleneck at node I1, but this time on the link between node I1 and node S1, due to the simultaneous arrival of both Tx2 and Tx3 at node I1. Node I1 can use network coding to combine Tx2 and Tx3 into a message M'.

[0042] One option is to have every node apply network coding in all circumstances. However, it may be possible to further improve performance by selectively applying network coding at certain nodes where it may be expected to be advantageous at that time. As an example, if a node can determine whether it represents a bottleneck at any given time, it may selectively or adaptively apply network coding to the transmission of messages, whereas if it is not a bottleneck, it may use normal transmission of transactions.

[0043] Thus, a node may be configured to assess or determine whether it is a possible bottleneck at a given time. In one sense, this may be determined based on a balance between in-links and out-links. That is, at a given time, a node may receive transactions on one or more links and may intend to send these transactions outward on one or more links. A connection (i.e., an edge) between nodes may act as an in-link or an out-link at any given time, depending on the flow of traffic in the network. In some cases, the number of in-links may be referred to as the "fan-in" and the number of out-links may be referred to as the "fan-out."

[0044] In one implementation, at least some of the nodes in a 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. FIG. 5 diagrammatically illustrates a portion of an example network, where a first node I1 and a second node I2 each locally store a table or other data structure that identifies the node's fan-in and fan-out quantities at any given time. A node can determine whether it is a possible bottleneck based on the relative fan-in and fan-out numbers. In general, the determination can be based on whether the number of inlinks (fan-in) exceeds the number of outlinks (fan-out), in which case the node may be a bottleneck at that time.

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

[0046] The determination may also, in some implementations, be based in part on an awareness of the network topology: for example, in at least some cases, a node that is a peripheral node is less likely to be a bottleneck, while a node that is an intermediate node is more likely to be a bottleneck.

[0047] In yet other implementations, the determination of whether a node is a bottleneck may be based on an evaluation of the status of an output queue, or the backlog in the output queue over time.

[0048] Determining or identifying a bottleneck may, in some implementations, involve a combination or sub-combination of the above factors.

[0049] Network coding was developed just under two decades ago as an alternative to the dominant packet-switched networks of the time. Network coding models the network as a directed graph (N,L) with link capacity and demonstrates that a node n∈N can communicate information to a set of receivers R⊆N at a rate that achieves broadcast capacity h, where h is the value of the minimum cut between s and any r∈R, subject to the encodings at the interior nodes of the network.

[0050] A cut C is defined as a partition of the vertices V of a graph G = (V, E) into two disjoint subsets S and T. A cutset of a cut C = (S, T) is the set of edges with one endpoint in S and the other endpoint in T {(u, v) ∈ E | u ∈ S, v ∈ T}.

[0051] One exemplary methodology for network coding is described by PAChou, Y.Wu, and K.Jain, "Practical Network Coding," 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 removes the need for any centralized knowledge of the network topology or encoding or decoding functions. Chou states that a network N can be represented as an acyclic graph G = (V, E) with unit capacity edges (e), senders s ∈ V, and a certain number of receivers T ⊆ E. The output v = in (e) of each edge e ∈ E of a node has a symbol y (e), which is a linear combination of the symbols y (e') on the edges e' entering v. Figure 6 shows a node v and its output y (e). In particular, the output is

number

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

number

number

number

[0053] The global encoding vector of an outgoing edge e may be characterized as being based on a local encoding of the global encoding vector of an incoming edge e'.

[0054] It will be appreciated that network coding may be used to propagate transactions through a network. It may also be used in overlay networks designed to implement a distributed hash table of unconfirmed transactions, where each transaction is stored by at least two nodes to ensure redundancy in the distributed hash table. In this case, network coding may be used in sending a transaction to more than one node for storage. However, the use of network coding may provide the additional advantage of being able to recover from the loss of more than one node that stores the transaction. Because intermediate nodes have received one or more messages containing combined data about the transaction, the missing transaction may be restored from the network coding message.

[0055] Reference is now made to Figure 7, which illustrates in flow chart form an example process 700 for propagating transactions in a blockchain network. Process 700 is implemented by a node of the blockchain network. In this context, a node may be understood to refer to a mining node, a full node, a validator node, or other type of individual blockchain node in a blockchain network. A node is a computing device having a network connection, computing resources, and running software that implements a blockchain protocol.

[0056] At operation 702, the node determines that it is a potential bottleneck in the network at time T. This determination may be based on a comparison of the 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 determine that it is a bottleneck. Other factors may alternatively or additionally be considered in determining whether a node is a bottleneck. Examples include the average fan-in and fan-out over a period of time, the node's position in the network topology, the current or past status of the node's output queue, or any other factors related to the node's capacity to propagate incoming transactions.

[0057] In operation 704, if a node determines that it is a bottleneck, it accumulates transactions for a period of time ΔT. The period may be a predetermined length of time. In some example implementations, the period may vary based on network traffic measurements, geographic information, or both. Rather than the period being a fixed amount of time, rather, accumulation of transactions may occur until a minimum number of transactions are received, which may further be subject to a maximum time imposed so that accumulated transactions are not held for too long.

[0058] In operation 706, the multiple transactions accumulated by the node are combined into a single message using network coding. The message may have a length as long as the longest of the transactions in some implementations. The message may have a length (in bits) not longer than the longest of the transactions in some implementations. The message is generated using a local encoding vector and a network coding algorithm.

[0059] The node then transmits the message and the global encoding vector to one or more nodes at operation 708. The message is transmitted in lieu of transmitting an actual transaction, i.e., the node does not transmit multiple accumulated transactions, but instead transmits the message and the global encoding vector to peer nodes on all of its outlinks.

[0060] Reference is now made to Figure 8, which illustrates in flow chart form an example method 800 for propagating transactions in a blockchain network. As discussed above, method 800 may be implemented in a blockchain node having multiple in-links and out-links.

[0061] At operation 802, a blockchain node receives a transaction. The incoming transaction is received via an in-link. The blockchain can validate the transaction against protocol requirements to ensure that the transaction is legitimate. At operation 804, the node can determine whether it is a bottleneck with respect to the transaction. The determination may be based on an evaluation of the balance between in-links (fan-in) and out-links (fan-out) at that time. The determination may also be based on other factors, as discussed above.

[0062] If the node determines that it is not a bottleneck, then it forwards the transaction to one or more peer nodes in the blockchain network on its outlinks as normal, in operation 806. However, if the node determines that it may be a bottleneck, then in operation 807 the node stores the transaction in memory (e.g., in a buffer or other memory element).

[0063] The node then continues to receive and store transactions until it determines that a stop condition has been met, as indicated by operation 808. In this example, the stop condition is that a duration ΔT has elapsed. The duration may, for example, last from the determination that the node is a bottleneck, or from the receipt of the first transaction in operation 802. Instead of a duration, other conditions may be used, such as the accumulation of a maximum number of transactions in memory, or any combination of such factors.

[0064] Once a stopping condition is met, e.g., in this case after ΔT has elapsed, the node then constructs a message M from the stored transactions using network coding and the local encoding vector, as indicated by operation 812. In operation 814, the node then transmits this message and the global encoding vector to other nodes through all its outlinks.

[0065] Reference is now made to Figure 9, which illustrates in block diagram form a simplified example of a participating node 900. The node 900 includes a processor 902, which may include one or more microprocessors, application specific integrated chips (ASICs), microcontrollers, or similar computer processing devices. The node 900 further includes a memory 904, which may include persistent and non-persistent memory for storing values, variables, and in some examples, processor-executable program instructions, and a network interface 906, which provides network connectivity over a wired or wireless network.

[0066] The node 900 includes a processor-executable blockchain application 908 that includes processor-executable instructions that, when executed, cause the processor 902 to perform one or more of the functions or operations described herein.

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

[0068] It should be noted that the above-described embodiments are illustrative rather than limiting of the invention, and 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. In the claims, any reference signs placed in parentheses shall not be construed as limiting the scope of the claims. The words "comprise" and "comprising", and the like, do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprise" means "comprises or consists of" and "comprising" means "comprises or consists of". A reference to a singular element does not exclude a reference to a plural of such element and vice versa. The invention may be realized by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A node for propagating transactions in a network of nodes, each node having one or more connections to other nodes, said node comprising: A processor; Memory, A network interface; an application including processor-executable instructions; The processor-executable instructions, when executed by the processor, cause the processor to: determining whether the node is a bottleneck for the propagation of transactions; if said determination is made that said node is a bottleneck, receiving a plurality of new blockchain transactions from one or more first nodes in the network of nodes via the network interface and over a first period of time; combining the plurality of new blockchain transactions using network coding and a local encoding vector to generate a message, the message having a length no longer than a longest blockchain transaction among the plurality of new blockchain transactions; instead of transmitting the new blockchain transactions to one or more second nodes in the network of nodes, transmitting the message and a global encoding vector to the one or more second nodes; if said determination is made that said node is not a bottleneck; Use normal transmission of transactions Let the node do that.

2. 2. The node of claim 1, wherein the instructions, when executed, cause the processor to determine that the one of the nodes is a bottleneck by evaluating a number of inlinks to the node and a number of outlinks from the node, and determining that the one of the nodes is a bottleneck when the number of inlinks exceeds the number of outlinks.

3. The node of claim 2 , wherein the evaluating comprises evaluating upon receipt of a first transaction of the plurality of new blockchain transactions.

4. 3. The node of claim 2, wherein said evaluating includes tracking a count of inlinks and a count of outlinks over time, said number of inlinks being an average and said number of outlinks being an average.

5. 5. The node of claim 1, wherein the instructions, when executed, cause the processor to initiate the determination that the one of the nodes is a bottleneck in response to receiving a first transaction of the plurality of new blockchain transactions.

6. 6. The node of claim 1, wherein the instructions, when executed, cause the processor to perform the combining and transmitting in response to determining that a stop condition is met.

7. 7. The node of claim 6, wherein the stopping condition comprises expiration of a duration from either receipt of a first of the plurality of new blockchain transactions or from the determination that the one of the nodes is a bottleneck.

8. The node of claim 6 , wherein the stopping condition includes the plurality of new blockchain transactions reaching a maximum number of new blockchain transactions.

9. 1. A computer-implemented method of propagating a transaction in a network of nodes, each node having one or more connections to other nodes, the method being implemented on one of the nodes; determining that the one of the nodes is a bottleneck for the propagation of transactions; if, based on the determination, the determination is that the one of the nodes is a bottleneck; receiving a plurality of new blockchain transactions from one or more first nodes in the network of nodes over a first time period; combining the plurality of new blockchain transactions using network coding and a local encoding vector to generate a message, the message having a length no longer than a longest blockchain transaction among the plurality of new blockchain transactions; instead of transmitting the new blockchain transactions to one or more second nodes in the network of nodes, transmitting the message and a global encoding vector to the one or more second nodes; if the determination is that the one of the nodes is not a bottleneck, using normal transmission of transactions; The method includes:

10. 10. The method of claim 9, wherein determining that the one of the nodes is a bottleneck comprises: evaluating a number of inlinks to the node and a number of outlinks from the node; and determining that the one of the nodes is a bottleneck when the number of inlinks exceeds the number of outlinks.

11. 11. The method of claim 10, wherein the evaluating step comprises evaluating upon receipt of a first one of the plurality of new blockchain transactions.

12. 11. The method of claim 10, wherein the evaluating step includes tracking an inlink count and an outlink count over time, the number of inlinks being an average and the number of outlinks being an average.

13. 13. The method of claim 9, wherein determining that the one of the nodes is a bottleneck is initiated in response to receiving a first transaction of the plurality of new blockchain transactions.

14. 14. The method of claim 9, wherein the combining and transmitting steps occur in response to a determination that a stop condition has been met.

15. 15. The method of claim 14, wherein the stopping condition comprises expiration of a duration from either receipt of a first of the plurality of new blockchain transactions or the determination that the one of the nodes is a bottleneck.

16. 15. The method of claim 14, wherein the stopping condition comprises the plurality of new blockchain transactions reaching a maximum number of new blockchain transactions.

17. 17. A non-transitory processor-readable medium having stored thereon processor-executable instructions for participating in a transaction between a plurality of participating nodes, the processor-executable instructions, when executed by a processor in one of the participating nodes, causing the processor to perform a method as recited in any one of claims 9 to 16.

Images