Flow control for probabilistic relaying in blockchain network

Abstract

To provide a method for adjusting the minimum and maximum numbers of peer nodes that nodes on a blockchain network connect to.SOLUTION: An adjustment takes into account the bandwidth and processing power of a node. A bandwidth capacity of the node is determined based on the maximum amount of data that can be processed by the node over a certain period of time. Data passing through node's interface to and from peer nodes is monitored and node profile coefficients are determined from differences between input data and output data. Over a plurality of periods of monitoring the data, analyzed data is used for setting the minimum and maximum numbers of peer nodes that can connect to the node according to the monitored data and the maximum number of peers that can connect to the node. The method allows the node to adjust the number of connections according to performance limiting factors such as bandwidth availability and processing power.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] This specification generally relates to computer-implemented methods and systems suitable for implementation in nodes of a blockchain network. Improved blockchain node structures, network architectures, and protocols for handling large numbers of transactions and large blocks of transactions are described. The present invention is particularly suited for, but not limited to, use with the Bitcoin blockchain. [Background technology]

[0002] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include 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 Bitcoin may be referred to herein for convenience and explanation, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. The term "user" may refer herein to a person or a processor-based resource.

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

[0004] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform the task of making sure that each transaction is valid, and invalid transactions are rejected from the network. A software client installed on the node performs this validation task by running its locking and unlocking scripts on the unspent transaction (UTXO). If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and the transaction can be written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be validated by the first node that receives the transaction, and if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block constructed by miners, and iii) be mined, i.e., appended to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptographic security system on which Bitcoin is based, and the data that can be held on the blockchain, to implement new systems. It would be highly advantageous if blockchain were used for automated tasks and processes that are not limited to the field of crypto assets. Such solutions could leverage the benefits of blockchains (e.g., permanent tamper-resistant recording of events, distributed processing, etc.) while broadening their applications.

[0006] According to Blockchain.info [Bitcoin transaction levels are available through Blockchain Luxembourg SARL and can be retrieved from http: / / blockchain.info], in April 2017, the average number of Bitcoin transactions per block was around 2000 units. In the near future, the constraint on the maximum block size may be relaxed and the number of transactions per block may increase significantly.

[0007] Competitive cryptocurrencies need to propagate large volumes of unconfirmed transactions as fast as possible. By comparison, Visa's electronic account settlement has a peak capacity of 56,000 transactions per second. [VISA transaction levels are summarized in a document published by Visa in June 2015, "Visa Inc. at a Glance," available at http: / / usa.visa.com / dam / VCOM / download / corporate / media / visa-fact-sheet-Jun2015.pdf.]

[0008] The current three-step messaging protocol for the exchange of new transactions in the Bitcoin network by inventory is insufficient to handle the rapid distribution of transaction volumes several orders of magnitude larger than the current standard (~5 transactions per second [Decker, Christian and Wattenhofer, Roger (2013). Information propagation in the bitcoin network. IEEE Thirteenth International Conference on Peer-to-Peer Computing (P2P), 2013]).

[0009] The Bitcoin network today is centered around mining in terms of computational work, which may not necessarily be feasible if transaction volumes increase significantly.

[0010] Not only is management of data flows essential, but the technical capacity or capabilities of nodes and networks must be taken into account.

[0011] The solutions described herein enable the Bitcoin network to handle the propagation of large volumes of transactions while respecting node and network limitations.

[0012] Known methods of sending data packets or transactions through the Bitcoin network, for example distributing new transactions by three-step messaging, result in slow propagation and distribution of data packets across the network. During the preparation phase, queues arise in and out of nodes. Such problems become severe when nodes are asked to operate above or around their nominal limits. Summary of the Invention

[0013] Overall, the present invention resides in a novel approach for the processing and propagation of increased transaction volumes, orders of magnitude greater than current blockchain capacities. This can be achieved by supporting faster propagation and distribution of data packets across the network by reducing communication between nodes. Long queues in and out of nodes caused by bottlenecks are suppressed by selectively relaying data packets according to correlation between interfaces. Additionally or alternatively, the present invention resides in a novel approach to managing data or traffic through a node's interface to peer nodes. This can take into account data transferred and local resources. The local resources can include at least one of bandwidth resources, data profile, number of connected peers, and node performance. Node capabilities can also be taken into account.

[0014] In this manner, a node can operate adaptively (i) independent of the number of interfaces connected to peer nodes, and (ii) independent of changes related to the node's interfaces, thereby taking into account new connections, disconnections, and malicious nodes, and maintaining the integrity of the network.

[0015] In this way, there is no limit to the number of interfaces on a node that can be managed, and the method adapts to the network and node environment, so network performance and size are not limited. Inefficient transmissions are minimized and malicious nodes are avoided.

[0016] According to this method, the minimum and maximum number of connected peers can be determined and the time window for performing critical tasks can be adjusted accordingly.

[0017] In this manner, the performance of the blockchain network is improved and the blockchain network or an overlay network that interfaces with the blockchain network is improved.

[0018] Thus, according to the present invention there is defined a method as defined in the appended claims.

[0019] Thus, there is provided a computer-implemented method for a node of a blockchain network, the node having a number of interfaces connecting to peer nodes, the method comprising: determining a bandwidth capacity of the node based on a maximum amount of data that can be processed by the node over a period of time; Monitor data including input data from peer nodes and output data to peer nodes through an interface of the node, and convert the input data to output data (d o determining a profile coefficient for said node from the difference between monitoring the data over a plurality of time periods; setting a minimum number and a maximum number of peer nodes that can be connected to the node according to the monitored data and a maximum number of peers that can be connected to the node; It is desirable to provide such a method, comprising:

[0020] The method allows a node to adjust the number of connections according to performance limiting factors such as bandwidth availability and processing power.

[0021] The monitored data over at least one period of time can be used to determine a ratio. Setting the minimum number of peer nodes and the maximum number of peer nodes that can connect to the node can be determined using the ratio. The ratio can be calculated from the data passing through the node and the maximum amount of data that can be processed by the node. The ratio can be non-linear.

[0022] The profile coefficients may be assigned values ​​according to the function of the node, with the profile coefficients having a value of 1 for nodes configured to forward data, values ​​greater than 1 for nodes that collect or aggregate data, and values ​​less than 1 for nodes that generate or supply data.

[0023] The node may have multiple interfaces connected to peer nodes, and a correlation matrix may be determined from correlation coefficients representing correlations between data processed at each interface of the node. The period may be determined from the length of time between changes to the correlation matrix. The changes may relate to the startup or activation of a node, or may relate to a node joining or leaving the network.

[0024] The node may receive information regarding activity of nodes on a blockchain network and determine the period according to the length of time between changes to the correlation matrix.

[0025] Average data having an average of data over the multiple time periods may be used to determine the minimum and maximum number of peer nodes that may connect to the node by determining a ratio of the average data to the maximum data.

[0026] The method may further include determining a distribution of the data over a number of time periods, applying a scaling factor to the distribution, and determining the minimum and maximum number of peer nodes that can connect to the node according to the scaled distribution.

[0027] The minimum and maximum number of peer node connections (m) are:

number

[0028] The scaling factor or dispersion parameter t is

number

[0029] The period may be temporarily adjusted by the node to a predetermined value to accommodate at least one of local parameter updates to the node, a starting period during which the node accumulates data, and a temporary relay of data to all peer nodes.

[0030] The period can be a flow control parameter that can be adjusted to alter traffic through the node.

[0031] With the determined number of peer node connections, the node may further determine a correlation matrix between the interfaces and the peer nodes to which it is connected. The correlation matrix may be compiled with correlation coefficients representing the correlation between the data processed at each interface of said node.

[0032] The node has a plurality of interfaces connected to peer nodes, the plurality being at least a minimum number (m min ), and the maximum number of interfaces connected to the peer node (m max ) or less, the method comprises: determining a correlation matrix having correlation coefficients representative of correlations between data processed at each interface of said node; receiving data at a receive interface of said node; Selecting at least one other interface from a plurality of other interfaces of the node and relaying the received data from the at least one other interface, the other interface being selected according to a set of correlation coefficients of the receiving interfaces; may have the following structure:

[0033] An indicator may be derived from the correlation matrix, and data is relayed if the correlation between the receiving interface and the at least one other interface is lower than the indicator.

[0034] The data may correspond to an object such as a transaction or a block. Relaying may alternatively occur if the correlation is higher than an indicator. The indicator may be a threshold. The indicator may represent a level of correlation between the interface receiving the data and a number of interfaces, such as an average value. The average value may be an average of correlation coefficients between the receiving interface and the other interfaces. The indicator may be used to determine a metric that sets the criteria for selecting which of the multiple other interfaces to select to relay data from. The metric may be considered as an instruction used to select from which interface the data should be relayed. The instruction may be set according to or depend on a threshold or indicator.

[0035] As an example, the instructions may require that an interface have a correlation index below the indicator. The instructions may determine which interface to relay data to depending on whether the correlation index is above or below the indicator.

[0036] An example of data relay when the index falls below the indicator may be a normal steady-state network condition. In 'steady-state' conditions, the number of interfaces and connected peers does not change and the correlation matrix does not change.

[0037] An example of data relay when the index exceeds the indicator may be a change of state, such as the addition of a new peer node connection to the node. Different instructions may be applied to different interfaces.

[0038] The data to be distributed may include data received from the blockchain network, including data from miners, peer nodes, and full nodes. The correlation between data processed at each interface of the node may take into account overlaps of data packets or objects received at the node. The indicator may be the average or median correlation index of each interface of the node. The indicator may define a point between the lowest and highest correlated interfaces. Data or objects may be relayed from an interface when the correlation index falls below the indicator. Interfaces with a low degree of correlation may be prioritized since it can be safely assumed that highly correlated interfaces will get the data.

[0039] Nodes process data through interfaces, which includes sending and receiving data or objects, such as transactions or blocks.

[0040] The data may be in a network packet representing a serialized transaction and an identification representing a connection to an adjacent or peer node. The interface may be a logical interface ID representing a TCP / IP connection to a sending / receiving peer.

[0041] The node may build the correlation matrix by monitoring (i) the data identifier of each packet of data processed through each interface, and (ii) the same transaction processed through a pair of interfaces, and then determine the correlation coefficient between any two interfaces. The correlation matrix may have m(m-1) elements, as follows:

number

[0042] The correlation matrix may have m(m−1) elements, as follows:

number

[0043] The indicator may be determined by determining, for each interface connected to a peer node, a set of correlation coefficients derived from the correlation matrix, the set having the correlation coefficients between each interface, and deriving an average or median from the set.

[0044] The indicator may be used by a set of instructions to determine which interface to relay the data through.

[0045] The indicator for determining the number of interfaces to relay data may further be based on at least one of a reset time, which is the time from node startup or start-up, and a change time, which is the time between change events including at least one of a new peer node connecting to an interface, a termination of a connection to an interface, and an interface connecting to a malicious node. The reset time may be used for new nodes. The change time may be used for existing nodes.

[0046] At node startup, the node may connect with peer nodes, such as nodes adjacent or directly connected to the node, and relay data via all interfaces during the reset time period during which the correlation matrix is ​​built, and after the period has elapsed, the node relays all objects from the node via interfaces having a correlation index below the indicator.

[0047] Upon detection of a change event, the correlation matrix may be reset and re-determined, which may occur when a periodic reset is required.

[0048] The invention also resides in a computer-readable storage medium having computer-executable instructions that, when executed, configure a processor to perform the claimed methods.

[0049] The invention also pertains to an electronic device having an interface device, one or more processors coupled to the interface device, and a memory coupled to the one or more processors, the memory storing computer-executable instructions that, when executed, configure the one or more processors to perform the claimed methods.

[0050] The invention also resides in a node of a blockchain network, said node being configured to perform the claimed method.The invention also resides in a blockchain network comprising the claimed node.

[0051] These and other aspects of the invention will be apparent from and will be elucidated with reference to the embodiments described hereinafter, which will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0052] [Figure 1]Represents network packets being sent and received serially at the application level through nodes on the Bitcoin network. [Diagram 2] It represents the rules that a single transaction between nodes across the Bitcoin network follows. [Diagram 3] 1 is an example of a correlation matrix showing correlation coefficients of interfaces connected to peer nodes. [Figure 4] A diagram showing nodes having different functions in a blockchain network. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0053] Described herein is a solution to the problem of processing and storing large gigabyte-sized blocks. Efficient transaction of data across a blockchain network can be improved by determining connectivity between nodes and relaying data accordingly. Furthermore, the specifications of the nodes and available bandwidth affect the flow of data across the network, and the number of connections a node has and the time period for determining connectivity can be adjusted or dimensioned to improve the flow.

[0054] [process] <Type of Blockchain Network and Validation Node> A blockchain network may be described as a peer-to-peer, open-membership network in which anyone can join without an invitation or consent from other members. Distributed electronic devices that run instances of the blockchain protocol on which the blockchain network operates may participate in a blockchain network. Such distributed electronic devices may be called nodes. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrency.

[0055] Some blockchain networks such as Bitcoin use TCP for node - to - node communication. The data packets transmitted using TCP have associated sequence numbers that are used for ordering.

[0056] In addition to this, the TCP protocol involves a three - way handshake procedure both when establishing a connection and when terminating a connection. The packets transmitted via TCP are associated with overhead, they have associated sequence numbers, and the three - way handshake protocol exists. When establishing a connection, 128 - 136 bytes are transmitted, while closing a connection takes 160 bytes. Thus, the handshake in packet transmission takes up to 296 bytes.

[0057] Furthermore, when a node receives a new transaction, it notifies other nodes with an inventory (INV) message that includes the hash of the transaction. The node receiving the INV message checks whether the hash of that transaction has been previously confirmed. If not, the node requests the transaction by sending a GETDATA message. The time required to send a transaction from node A to node B is T1 = validity check+TCP(INV + GETDATA+TX). Here, TCP() represents the overhead introduced by the TCP handshake procedure with respect to time.

[0058] <TCP Protocol and Three - Way Handshake> The current peer - to - peer Bitcoin protocol defines 10 data messages and 13 control messages. In this context, the transfer of data or data packets related to object transfer may refer to individual transactions or blocks.

[0059] A complete list of messages used by the Bitcoin P2P protocol is known and for a complete list please refer to the Bitcoin Developer Reference available at http: / / bitcoin.org / en / developer-reference. A subgroup of messages are concerned with the request or distribution of objects. These messages are BLOCK, GETDATA, INV, TX, MEMPOOL and NOTFOUND. A subgroup of messages are concerned with the reliability and efficiency of objects. These messages are FEEFILTER, PING, PONG and REJECT.

[0060] As an example, nodes 'i' and 'j' on the Bitcoin network communicate using the following steps: 1. Node i sends an INV message containing a list of transactions. 2. Node j responds with a GETDATA message requesting a subset of the transactions it had previously seen. 3. Node i sends the requested transaction.

[0061] Here, the method seeks to optimize the protocol of the blockchain network to at least improve the distribution of data.

[0062] Figure 1 represents a practical scenario where data, in the form of network packets, is sent and received serially at the application level according to primitives provided by the operating system. If transaction x fits into a single Ethernet / IP packet, its transmission to m peers requires the buffering of m different outgoing packets. Both the incoming and outgoing network packets contain, among other information, Serialized transactions, · Logical interface ID representing the TCP / IP connection to the sending / receiving peer Includes.

[0063] The expected time for an incoming transaction to be processed is the input queue L i The expected time for a processed transaction to be successfully transmitted depends on the average length (in packets) of the output queue L o It depends on the average length of

[0064] Therefore, the efficient relay of transactions is L i and L o However, the probabilistic model for selective relaying of transactions to peers depends on reducing both the value of L o directly affects and induces L i also affects.

[0065] In the current Bitcoin implementation, INV and GETDATA message packets are queued in the I / O buffer just like transactions, severely impacting send and receive latency.

[0066] Connectivity <Efficient Transaction Propagation - Probabilistic Relay> If node i were allowed to send new transactions directly, without the use of inventory exchange, the transactions would spread through the network at a faster rate, but without some regulation the network would become flooded.

[0067] Therefore, the present invention uses a mechanism for selective relay of data or objects from a node to a peer node to avoid transmission of huge amounts of unnecessary transactions. The mechanism can be a probabilistic model.

[0068] The mechanism or probabilistic model for relay transmission is based on the assumption, see Fig. 2, that three nodes i, j and k are part of the Bitcoin network and are connected to each other. Node i is directly connected to node j and node k. Node j and node k are indirectly connected through node i or through the Bitcoin network.

[0069] Node i is shown with two interfaces a and b that process data in the form of transaction r. A transaction is initiated at node i and goes through various stages as it propagates across the Bitcoin network between nodes. The stages include: A first phase r1 of processing the transaction for transmission from interface a to a peer node so that it is received by node j; A second phase r2 in which node j processes the transaction for transmission via Bitcoin so that it is received by node k; and A third phase r3 in which node k processes the transaction for transmission to peer node i, which receives the transaction on interface b. Includes:

[0070] For the avoidance of doubt, r1, r2, and r3 are the same transaction, and the subscripts represent relays.

[0071] It is assumed that: If a node receives from interface (b) the same transaction that it processed for transmission from another interface (a), then the two interfaces share a degree of correlation. · If a transaction originating at node i reaches node j through a given input interface j, then a second transaction originating at node i will reach j through the same interface with high probability.

[0072] Referring again to FIG. 2, as an example of relay correlation, nodes j and k are peers of node i. If i generates a new transaction and relays it to node j, and later the same transaction is received at node i from node k, then j and k share a logical path through the network. Thus, the originating node does not need to relay the same information to both of its peer nodes. For clarity, node i does not need to send transaction r to node k because node k has a high probability of receiving it. Similarly, conversely, node k does not need to send transaction r to node i because node k has a high probability of receiving it. The logic is valid in both directions.

[0073] <Relationship between node interfaces> Figure 3 is an example of a local correlation matrix C that may be determined for node i having five interfaces a, b, c, d and e connected to peer nodes. The matrix represents the degree of correlation for incoming traffic. The formation and application of this matrix is ​​described below. The values ​​shown in Figure 3 are for illustrative purposes.

[0074] Each node may, for example, determine a coefficient c that represents the correlation between transactions received from interfaces a and b. ab Construct the correlation matrix C by determining: Such coefficients are determined between all pairs of interfaces.

[0075] Using the list of transaction IDs received from each interface, a and t b Let be the number of transactions received from interfaces a and b, respectively, and t ab Let be the number of duplicate transactions received from both a and b. The correlation coefficient for interfaces a and b is given by Equation 1:

number

[0076] As a convention, for the coefficient c ab the lexicographic order a < b of its indices is assumed. That is, a is assigned '0' (a = 0), b is assigned '1' (b = 1), c is assigned '2' (c = 2), and so on, continuing in the same way between interface IDs and numerical values. Considering the correlation coefficients for the set of interfaces {a, b, d, e}, interfaces a and b are ab > c de more correlated than interfaces d and e in the case of

[0077] Since the elements on the main diagonal are not significant, the matrix size can be reduced to m(m - 1) elements as shown in Figure 3.

[0078] <Assignment of values to node interfaces> The overall correlation index of interface a is as follows:

Equation

[0079] Using the correlation matrix of Figure 3 as an example, the correlation index c a of interface a can be expressed as the sum of the correlation coefficients between each interface. c a = c ab + c ac + c ad + c ae = 0.2 + 0.8 + 0.2 + 0.2 = 1.4

[0080] This metric can be used to rank the correlations of individual interfaces and understand the quality of the relays provided by node peers. As an example, when the correlation index of a is significantly higher than the average value, the transactions received from a are highly redundant.

[0081] In contrast, if the correlation index of a is significantly lower than the average, then either (i) the transactions received from a are somewhat unique, or (ii) the peer nodes connected to a are behaving maliciously. Malicious behavior is discussed in more detail below.

[0082] It should be noted that each node builds its own correlation matrix based only on the received transaction flow: to avoid the propagation of malicious information, no correlation information is exchanged between nodes or peers.

[0083] <Indicator> Considering an incoming transaction from interface a, a node min ,m max ], and then relay to the number of peers m* in the

[0084] The current value m* is the correlation index of interface a, which contains the m-1 correlation coefficients {c a} depends on the current distribution of {c a}=[c 0a ,c 1a ,···,c am-1 ] That is, {c a} is a list or set of correlation coefficients, the set having the coefficients for interface a. The correlation index is calculated as the sum of the coefficients, i.e., c a =c ab +c ac +c ad +c ae It is.

[0085] The number of interfaces selected for relaying from interface a is m*(a) based on the set {c a Metric θ of each element of i (a) Depends on the calculation:

number

[0086] Metric θ i (a) acts as a switch or selector, indicating whether the interface will relay data or not. For example, an interface will relay data if its metric is '1' and will not relay data if its metric is '0'.

[0087] Bar C a Group a metric θ by defining it as the average of the coefficients in i (a) is the corresponding correlation coefficient c ai Bar C a contributes to m*(a) if it is lower than:

number

[0088] θ i (a) Alternatively, instead of the average, a}. The metric θ i (a) We also used statistical analysis to find the a}, for example, the metric θ i (a) is the corresponding correlation coefficient c ai The group a} contributes to m*(a) if it is at least one standard deviation below the mean of

[0089] As an example, an incoming transaction from interface a in Figure 3 is a}, the packets are relayed to the m*(a) smallest correlation interfaces. a A subset of {c* a} is defined as

[0090] Returning to the example in Figure 3, when {ca}={0.2,0.8,0.2,0.2},

number

[0091] Therefore, the number of interfaces selected for relaying from interface a, m*(a), is '3'. Metric θ i (a) The coefficients in the subset below the mean or indicator that determines the value of c* a}, interfaces b, d, and e are selected for relaying.

[0092] The coefficient 'cutoff' point or level used to determine the metric in the above example was the mean of the coefficients '0.35'. This threshold or indicator is the metric θ i (a) Then m*(a) is determined.

[0093] Overall, therefore, the method can be said to relay data from the interfaces according to indicators, which may be used to determine, for each interface, a metric that determines whether it will relay data.

[0094] Although indicators were used to determine the metrics in the above examples, other factors may affect the metrics for each interface. The metrics for each interface may be calculated according to changes to the correlation matrix.

[0095] <Response to changes> As noted above, the determination of which interface should be used to relay information assumes steady state conditions in which the matrix is ​​not altered.

[0096] Further details of the protocol are now given below with regard to a description of how the protocol can respond to changes, for example when a peer node joins the network and forms a new connection with a node, or when a peer node leaves the network and is no longer connected to a node's interface.

[0097] When responding to changes, data can be relayed based on the metric, which takes into account the indicator and therefore the correlation index.

[0098] <Start> When node i starts up, it initializes m peer connections with other nodes in a blockchain, such as the Bitcoin network. See, for example, the Bitcoin Developer Reference for full details. Initially, node i does not have any information on the correlation between data passing through its interface, and has a limited set of data that represents the data passing through or flowing through it. Thus, relaying of complete transactions will take some time to execute.

[0099] During this period T bootup Between them, the metric θ i (a) contributes to m*(a) by setting each interface to '1' and relaying data from all interfaces. Thus, the metric allows data to be relayed regardless of the indicator over a given period of time.

[0100] Period T bootup The length of is a function f(m) of m, i.e. the more connections there are, the more time is needed to build an accurate correlation matrix. The following function is proposed, purely by way of example: f1(m):=m f2(m):=m 2

[0101] Tbootup After,node i performs selective relaying according to the existing nodes,shown below.

[0102] <Existing node> The connections of a general node j change over time to account for changes either due to (i) other nodes joining the network, (ii) other nodes leaving the network, and / or (iii) other nodes behaving maliciously. Malicious nodes are selectively blacklisted and the corresponding connections are closed.

[0103] Therefore, any change in the entire network graph is detected and a quantity T change It can be parameterized by T change Once every, the local correlation matrix of node j needs to be updated.

[0104] The updating of the correlation matrix of the node may include at least one of the following: · Cycle reset when correlation matrix is ​​reset Each new node relays a complete transaction in time. Tbootup Then, node j performs selective relaying on its new m* values ​​for each interface that connects to a peer node. - Updates that update the correlation matrix For a given interface α, the selected set {c* a}, the β highest correlation interfaces (0<β <m min ) is {c* a} are exchanged with the β minimal correlation interfaces not in

[0105] That is, the data is usually divided into a subset {c* a} to the m*(a) smallest correlation interfaces in the matrix, but when the matrix is ​​updated, the subset {c* a}, interfaces with low correlation indexes are added to the subset instead of interfaces with high correlation indexes in the subset. This can ensure the integrity of the flow of data across the network during changes.

[0106] Returning to the example in Figure 3, typically, c d =c da +c db +c dc +c de =0.2+0.4+0.4+0.6=1.6 {c d}={0.2,0.4,0.4,0.6}

[0107] Bar C d Group d}, the metric θ i (d) is the corresponding correlation coefficient c di Bar C d contributes to m*(d) if lower than:

number

[0108] In that case,

number

[0109] Typically, the number of interfaces selected for relaying from interface d, m*(d), is '3'. i (d) The coefficients in the subset below the mean or indicator that determines the value of c* d}, and interfaces a, b and c are selected for relaying. For the avoidance of doubt, the coefficient corresponding to interface e, i.e., {0.6}, isd Not within}.

[0110] When an update occurs relative to an interface d, the pair {c* d It happens that there are 2(β) highest correlation interfaces in}. They are interfaces b and c, both with a value of 0.4.

[0111] There is only one interface that qualifies as the β-minimum correlated interface that is not in {c*d}, and that interface is e. Therefore, only one 'swap' can be performed, and the choice of which interface to swap is either b or c, since they both have the same coefficient of 0.4. As an example, the choice of which interface to select for swapping can be made according to lexicographical priority. This interface is then chosen to be the β-minimum correlated interface that is not in {c*d}. a}, which means that the lowest coefficients are replaced with the remaining coefficients in the set {c d}={0.4,0.4,0.6}. The lowest coefficients correspond to interfaces b and c, and therefore data is relayed to peer nodes connected to those interfaces rather than interface a.

[0112] If a peer disconnects, its coefficient in the correlation matrix becomes invalid. change At the end of the period, a periodic reset as above is required. Then, node j performs selective relaying on its new m* values ​​for each connecting interface.

[0113] When a new peer b joins, the interface it is connected to is {c* a} is selected for relaying regardless of the current value of join For every γ incoming transactions, a relay may be randomly selected for relaying.

[0114] T join is T bootup and / or T change This relay helps node b to build its own correlation matrix. T join At the end of the process, b receives the updated values ​​{c* a} is selected for relay according to

[0115] Node i may need to check if its peer j is still alive because no incoming traffic was received from its interface. temp A temporary relay request of can be sent to j.

[0116] A node issuing a new transaction, i.e., the originating node, needs to carefully select a set of selected peers for relaying to ensure distribution in the network. For example, a number m** of nodes on any interface a can be selected as the first relays, where m*(a) <m**<mである。

[0117] The complete list of parameters is detailed below in Table 1. [Table 1]

[0118] <Malicious node> Malicious nodes aim to make the probabilistic model for transaction distribution ineffective. Malicious nodes can function or behave in any of the following ways: A malicious node does not propagate transactions that should be propagated. Honest nodes connected to this malicious node may be able to obtain those transactions from other honest (or malicious) nodes. However, full distribution of transactions in the network is not necessary, as the set of miners can still receive them and include them in newly mined blocks. Malicious nodes propagate the same legitimate transaction multiple times. Using a lookup table, the receiving node can keep track of previously received transactions. Thus, fraud is easily detectable and malicious peers are removed. Malicious nodes propagate invalid transactions. If the receiving node performs transaction validation, the fraud is easily detectable and the malicious peer is removed. Malicious nodes generate and propagate a huge number of dummy transactions. Receiving nodes can respond differently to a huge number of valid incoming transactions from a peer. In response, (i) the receiver asks the sender to reduce the transaction relay rate. If the problem persists, the sending peer is removed; (ii) the receiver can demand (and check) a minimum transaction fee for relayed transactions. This makes attacks expensive for malicious nodes. If the minimum transaction fee is not respected, the sending peer is removed; and / or (iii) the sending peer is simply removed.

[0119] Based on the above attacks and probabilistic models, the following properties can be inferred. Transaction relay rates depend on both the processing power and bandwidth availability of individual nodes. For this reason, no default maximum rate is enforced. Malicious nodes cannot simply stay silent. They must forward valid transactions to maintain their connection.

[0120] <Message> New message types may be introduced to support implementation of the methods herein, including the probabilistic relay of data or objects from node interfaces on the Bitcoin network. Additionally, some of the current message types detailed above with respect to the current peer-to-peer Bitcoin protocol are no longer used, while message types not described below are unchanged for the Bitcoin P2P protocol.

[0121] <Data message> The message GETDATA, which requests one or more data objects from another node, is no longer used or has been deprecated. Similarly, the message INV, which sends one or more inventories of objects known to the sending peer, is no longer used or has been deprecated. The message NOTFOUND as a response to GETDATA is no longer used or has been deprecated.

[0122] The MEMPOOL message, already introduced above, requests IDs of transactions that the receiving node has verified as valid but that have not been published in a block, i.e. transactions that are present in the receiving node's memory pool. The response to this message is one or more IV messages containing the transaction IDs. The node sends as many INV messages as are needed to reference its complete memory pool. A node may disable this feature and thus not be required to send its local MEMPOOL.

[0123] <control message> PING and PONG messages to verify that peers are still connected are removed. Silent nodes, such as malicious nodes, are managed as above. FEEFILTER messages remain unchanged. However, peers that do not respect the fee threshold are removed.

[0124] New messages TEMP and FLOW are introduced. TEMP messages are used when a node is asked to check if a peer is still alive because no incoming traffic is received from its interface (for an arbitrary short time T temp A temporary relay request TEMP is sent to the peers connected to the interface. The receiving peer starts relaying, but within a given time window T emp If it does not comply with the rules, it will be removed from the queue. The FLOW message is used when a node requests a peer to change its transaction relay rate (number of transactions per second) according to local flow control. The rate may be increased, decreased, or temporarily suspended (relay rate = 0). If the receiving peer does not respect the new relay rate, it is deleted. A new FLOW request is needed to change the current relay rate. If the receiving peer does not receive a second FLOW request to resume relaying, it deletes the sender. The MINFEE message is used when a node is asked to accept transactions filtered by a minimum transaction fee. Minimum values ​​can be set for individual transactions and / or for the sum of fees if multiple transactions fit into a single IP packet. If a receiving peer does not respect the transaction fee restrictions, it will be dropped.

[0125] [Dimensioning] Figure 4 illustrates an element of a blockchain network with nodes i, j, k, and l. The nodes may have different traffic profiles and may be referred to and named, by way of example, as follows: · “Provider”, a node that primarily generates transactions, where node i may represent one or more merchant nodes with a dedicated business activity. Aggregator: a node that primarily aggregates transactions, where node l may represent one or more merchant nodes with a dedicated business activity. "Router": A node such as node j and node k that mainly forwards transactions.

[0126] Each node can automatically control the amount of input and output traffic depending on the current status of its connections and the locally available bandwidth resources. The bandwidth allocation between input and output resources or interfaces can be adjusted according to the node type or function. Nodes i and j are unbalanced, but nodes j and k are balanced since the same amount of data flows into the router node as flows out of the node.

[0127] A node, say node j, has multiple interfaces connected to peer nodes. A node can determine its bandwidth (B) capacity based on the maximum amount of data (D) that can be processed by the node over a period of time (T). Some nodes have bandwidth caps set by their network providers.

[0128] B j is the application-level bandwidth available at node j. Bandwidth B j is the overall budget that depends on both (i) the quality of network access provided by the Internet Service Provider (ISP) and (ii) the network utilization by other local applications.

[0129] B jThe values ​​of B represent the different bandwidth requirements for input and output traffic. j i and B. j o It depends on: B j =B j i +B j o In the case of a router, B j / 2=B j i =B j o In the case of an aggregator, B j i =k j B j o It is considered that k j is the profile coefficient of the node, which is determined, for example, from the type of node, i.e., from the nominal set or from the difference between the actual data entering and leaving the node. j is preferably determined from the ratio of incoming data to the node and outgoing data from the node, which may include relayed data and / or locally generated data.

[0130] Data(d j ) is the input data (d j i ) and the output data (d j o ), and the profile coefficient (k j ) is the input data (d j i ) and output data (d jo ) can be determined from the difference between

[0131] Data(d j ) may be monitored over multiple time periods (T). The value of the monitored data may be reset when a new time period T begins. The data generated in node j may be expressed as output data (d j o )

[0132] The period (T) is D j =D j i +D j o This can be used to determine the maximum amount of data (D) that can be processed by node j, such that j i and D. j o is the maximum amount of incoming and outgoing data that can be supported during that period.

[0133] The period T is the flow control time window T flow Considering the variables at node j, then: B j =(k j +1)D j o / T B j o =D j o / T Therefore, D j i and D. j o The value of k j , T flow and B. j are system parameters that depend on: D j o =B jT / (k j +1) D j i =k j D j o =k j B j T / (k j +1)

[0134] <Current coefficient> To optimize the performance of a blockchain network, Bitcoin is used as an example. The Bitcoin Core specification, by default, allows up to 125 connections to different peers, of which 8 are outgoing.

[0135] The number of peers P that can connect to a node is limited, so in the current system, min is 1, and m max is 125. Without the current restrictions, the number of peers P that can connect to a node is m min ≧1 and m max ≦P.

[0136] The minimum number of peer nodes that can connect to node j (m min ) and the maximum number of peer nodes (m max ) can be set according to the monitored data (d) and the maximum number of peers (P) that can connect to node j.

[0137] The monitored data (d) over two or more time periods (T) is used to determine a ratio, which is then used to determine the minimum number of peer nodes (m min ) and the maximum number of peer nodes (m max ) can be used to set the actual data and the data upper limit. The ratio can be between the actual data and the data upper limit. Other relationships can be used, such as a non-linear relationship between the data (d) and the maximum data (D).

[0138] In addition to the relationship between data (d) and data limit (D), the type or function of node j may be considered in determining the number of peer nodes to which node j can connect. The function is taken into account using a profile coefficient (k) that is assigned a value according to the node's function. The profile coefficient can be variable.

[0139] As an example, the value of the profile coefficient may be 1 for a node configured to forward data, greater than 1 for a node that collects or aggregates data, and less than 1 for a node that generates or supplies data.

[0140] To suppress variability, or outlier data, average data (d*), having an average of data (d) over multiple time periods (T), can be used to determine the minimum and maximum number of peer nodes that can connect to node j by determining the ratio of the average data (d*) to the maximum data (D).

[0141] Furthermore, the minimum number of peer nodes that can connect to a node (m min ) and the maximum number of peer nodes (m max ) may take into account a buffer. Such a buffer may be determined by the standard deviation (σ) or variance (σ) of the data (d) over multiple time periods (T). 2 ), applying a scaling factor to the distribution, and determining the minimum and maximum number of peer nodes that can connect to the node according to the scaled distribution.

[0142] Monitored data (d j ) is the input data (d j i ) and the output data (d j o The minimum and highest number m of peer nodes that can connect to node j is

number

[0143] Linear range [1,P] and [m min ,m max ] values ​​may have a direct proportional relationship.

[0144] d j The number of periods (T) considered for averaging and updating t or T flow The time window can be a constant. The dispersion parameter t can be a multiplicative factor.

[0145] In the above formula, m min ≧1 and m max By imposing ≦P, the formula can be rearranged to determine the range of values ​​for the dispersion parameter t. This gives the following:

number

[0146] During the bootstrap or initial setup of a node, min = 1 and m max =P.

[0147] Variables P, d* and Dj The operating range of is limited, so σ j 2 The operating range of t, which depends on , is limited. As an example, P = 125 and d j * / D j Considering =0.5, then:

number

[0148] The dispersion parameter is

number

[0149] m min and m max Once the (integer number of peer node connections) is determined, the node can further determine a correlation matrix between the interfaces and the peer nodes to which it is connected. The matrix is ​​compiled with correlation coefficients that represent the correlation between the data processed at each interface of said node.

[0150] <Time Window (T)> The period (T) is determined from the length of time between changes to the correlation matrix.

[0151] The node may additionally or alternatively receive information regarding the activity of nodes on the blockchain network and set the period (T) according to the length of time between changes to the correlation matrix and / or changes in the level of activity on the network.

[0152] The time window between two successive local correlation matrix updates may be used to determine T.

[0153] The time T can be determined, or at least influenced, by the average number of active nodes, which is 7561 (as of June 2017), with an average increment of 0.85% every 24 hours. In these conditions, considering that on average 2.5 new nodes join the network every hour, the initial value of T can be fixed at 60 minutes. During the normal relay operation of a node, T is the time it takes for the incoming data (d j i ) may be considered to be inversely proportional to the current cumulative amount of

[0154] When a new peer node is connected, the data is join Depending on the state of the network, this can be relayed to the new node during j o may be considered to be inversely proportional to the current cumulative amount of

[0155] T bootup is the time required for a new node to build a stable correlation matrix, and this value is proportional to the function f(m): the more connections there are, the longer the amount of time required to build an accurate correlation matrix.

[0156] For purposes of this invention, the period T is T flow This is the time window between two successive updates of the cumulative amount of incoming and outgoing data. This value is equal to T change In the simplest case, T flow =T change =T.

[0157] That is, the period (T) is proportional to the flow control parameter (T flow), the parameters of which are adjusted to change the traffic through the node. The period (T) can be temporarily adjusted by the node to a predefined value. This can be based on local changes to the node that affect the bandwidth and subsequently the data flow through it. In such a situation, an increased period, such as a period twice the length of the previous period, i.e., 2T, can be used for a limited period of time. Similarly, the period T can be set to a starting period for which the node accumulates data. Either the local change or the starting period results in a temporary relay of data to all peer nodes for a period of time.

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

[0159] <Summary> Today's Bitcoin network is centered around mining in terms of computational work. This is not always feasible when the volume of transactions increases significantly. The solution described herein allows for the adjustment or dimensioning of the number of peer connections according to the data to be processed and the bandwidth limits. Although probabilistic relaying improves the processing and propagation of large volumes of transactions, it does not take into account the bandwidth or performance capabilities available at each node.

[0160] The present invention provides a way to dimension the number of connected peers, allowing to adjust the timing of operations performed by a node, such as resetting or re-determination of correlation matrices, boot-up time, etc.

[0161] Thus, in addition to adjusting connectivity according to performance to optimize the flow on the network by avoiding bottlenecks, the present invention complements the distribution of data packets by optimizing the communication between nodes.

[0162] Long queues caused by bottlenecks at nodes are suppressed by controlling connectivity and, optionally, selectively relaying data packets according to correlations between interfaces.

[0163] The overall number of peer connections can be managed and complemented by a reduction in packet transmissions while maintaining a safe level of information redundancy.

Claims

1. 1. A computer-implemented method for a node of a blockchain network, the node having a number of interfaces connecting to peer nodes, the method comprising: Parsing transactions received from peer nodes; determining, based on the transaction received from a peer node, that the peer node is a malicious node; upon determining that a peer node is malicious, issuing a request to the peer node to require that the transaction have a minimum transaction fee; if the minimum transaction fees are not respected, the peer node will be removed; method.

2. the node is connected to peer nodes by a plurality of interfaces, and a correlation matrix is ​​determined from correlation coefficients representing correlations between data processed at each interface of the node; The method of claim 1.

3. determining a time period from among a plurality of time periods based at least in part on a length of time between changes in the correlation matrix. The method of claim 2.

4. receiving information regarding activity of nodes on the blockchain network; determining the period according to the length of time between the changes in the correlation matrix; Further comprising The method according to claim 3.

5. the period is a flow control parameter that is adjusted to alter traffic through the node; The method of claim 1.

6. the node has a number of interfaces connected to peer nodes, the number being at least a minimum number of interfaces and no greater than a maximum number of interfaces; The method comprises: determining a correlation matrix having correlation coefficients representative of correlations between data processed at each interface of said node; receiving data at a receive interface of said node; selecting at least one other interface from a plurality of other interfaces of the node, the other interface being selected according to the set of correlation coefficients of the receiving interfaces; relaying the received data from the at least one other interface; and Further comprising The method of claim 1.

7. An indicator is derived from the correlation matrix; data is relayed as a result of a correlation between the receiving interface and a different interface of the plurality of interfaces being lower than the indicator; The method according to claim 6.

8. A node of a blockchain network executes the method. The method of claim 1.

9. A non-transitory computer-readable storage medium storing computer-executable instructions, comprising: The computer-executable instructions, when executed, cause a processor to perform the method of claim 1. A non-transitory computer-readable storage medium.

10. An interface device; a processor coupled to the interface device; a memory coupled to the processor; having The memory stores computer-executable instructions that, when executed, cause the processor to perform the method of claim 1. system.

11. The computer executable instructions further cause the processor to: determining corresponding correlations for each of the plurality of interfaces of the node based at least in part on input data and output data processed at the node; The system of claim 10.

12. The computer executable instructions further cause the processor to: relaying received data based at least in part on a correlation of a receiving interface of the node being less than or equal to an average correlation of two or more interfaces of the node; The system of claim 11.

13. a time period corresponding to a length of time between changes in one or more correlations of each of the plurality of interfaces of the node. The system of claim 12.

Images