阅读说明：本技术 区块链网络中概率中继的流量控制 (Flow control for probabilistic relays in blockchain networks ) 是由 朱塞佩·德泰法尼 西蒙娜·马代奥 帕特里克·莫特林斯基 史蒂芬·文森特 亚历山德拉·科瓦奇 于 2018-06-25 设计创作，主要内容包括：本发明涉及一种方法，该方法用于调整区块链网络上的节点将连接的对等节点的最小和最大数量。该调整考虑了节点的带宽和处理能力。节点的带宽容量是基于该节点在一个时间段内可处理的最大数据量来确定的。监控通过节点的接口，发送至对等节点或从对等节点发出的数据，并根据输入数据与输出数据之间的差值确定节点的配置文件因子。在监控所述数据的多个时间段上，所分析的数据用于根据所述监控的数据和可连接到节点的对等方的最大数量来设置可连接到该节点的对等节点的最小数量和最大数量。该方法使节点能够根据性能限制因素例如带宽可用性和处理性能等来调整连接的数量。通过确定对等节点连接的数量，该节点可以进一步确定接口之间的相关矩阵和与它所连接的对等节点。可以用相关系数来编译矩阵，所述相关系数表示在所述节点的每个接口处处理的数据之间的相关性。本发明还涉及相应的计算机可读存储介质、电子设备、区块链网络的节点、或具有这种节点的区块链网络。(The present invention relates to a method for adjusting the minimum and maximum number of peer nodes to be connected by a node on a blockchain network. The adjustment takes into account the bandwidth and processing power of the node. The bandwidth capacity of a node is determined based on the maximum amount of data that the node can handle over a period of time. Data sent to or from the peer node via the node's interface is monitored, and a configuration file factor for the node is determined based on a difference between the input data and the output data. The analyzed data is used to set a minimum number and a maximum number of peer nodes connectable to a node based on the monitored data and the maximum number of peers connectable to the node over a plurality of time periods during which the data is monitored. The method enables the node to adjust the number of connections according to performance limiting factors such as bandwidth availability and processing performance. By determining the number of peer node connections, the node can further determine the correlation matrix between the interfaces and the peer nodes to which it is connected. The matrix may be compiled with correlation coefficients representing the correlation between data processed at each interface of the nodes. The invention also relates to a corresponding computer readable storage medium, an electronic device, a node of a blockchain network, or a blockchain network having such a node.)

1. A computer-implemented method for a node of a blockchain network, the node having a plurality of interfaces to connect to peer nodes, the computer-implemented method comprising:

determining a bandwidth (B) capacity of the node based on a maximum amount of data (D) that the node can handle over a period of time (T);

monitoring said data (d), said data (d) comprising incoming data (d) originating from a peer node via a node interface_i) And outputting the data (d) to the peer node_o) And on the basis of said input data (d)_i) And output data (d)_o) The difference between them to determine a profile factor (k) for the node;

monitoring said data (d) for a plurality of time periods (T); and

setting a maximum of peer nodes connectable to the node according to the monitoring data (d) and a maximum number of peers (P) connectable to the nodeSmall number (m)_min) And maximum number of peer nodes (m)_max)。

2. Method according to claim 1, wherein the monitored data (d) are used to determine a ratio and to use said ratio to determine to set a minimum number of peer nodes (m) connectable to said node during at least one time period (T)_min) And maximum number of peer nodes (m)_max)。

3. Method according to claim 1 or 2, wherein the profile factor (k) is assigned a value according to the function of the node, wherein in the profile factor:

for nodes used to route data, the value is one (1),

for nodes that collect data, the value is greater than one (1), and

for nodes that generate or provide data, the value is less than one (1).

4. Method according to any one of the preceding claims, wherein the node has a plurality of interfaces connected to peer nodes, a correlation matrix is determined from correlation coefficients representing the correlation between the data processed at each interface of the node, and the time period (T) is determined from the length of time between changes of the correlation matrix.

5. The method according to claim 4, wherein the node receives information about the activity of nodes on the blockchain network and determines the time period (T) from the time duration between changes of the correlation matrix.

6. Method according to any of the preceding claims, wherein average data (D) is used for determining the minimum and maximum number of peer nodes connectable to said node by determining a ratio of said average data (D) to said maximum data (D), said average data (D) comprising an average value (D) of data over said plurality of time periods (T).

7. The method of claim 6, further comprising: determining a variance (σ) of data (d) over a plurality of time periods (T)²) (ii) a Applying a scaling factor to the variance; and determining a minimum and maximum number of peer nodes connectable to the node according to the proportional variance.

8. The method of claim 7, wherein:

wherein:

d is the average level of data (d) of said plurality of time segments (T),

d is the maximum data (D) that the node can handle during the time period (T),

p is the maximum number of peers (P) connectable to the node,

σ²is the variance of the data (d),

t is a scale factor or variance parameter, and

m_max≤P。

9. the method of claim 8, wherein the scaling factor or variance parameter t has an operating range of:

the average of the variance parameter t may be used within the operating range when determining the minimum and maximum number of peer nodes connectable to the node.

10. The method according to any of the preceding claims, wherein the node temporarily adjusts the time period (T) to a predetermined value to accommodate at least one of:

an update to a local parameter of the node,

an initialization period in which the nodes accumulate data, an

The data is temporarily relayed to all peer nodes.

11. Method according to any of the preceding claims, wherein said time period (T) is a flow control parameter (T ™)_flow) And adjusting the parameter to modify traffic through the node.

12. Method according to any of the preceding claims, wherein the node has a plurality of interfaces to peer nodes, the plurality being at least a minimum number (m) of connections to peer nodes_min) And is less than or equal to the maximum number of connections to a peer node (m)_max) The method further comprises the following steps:

determining a correlation matrix having correlation coefficients representing correlations between data processed at each interface of the nodes;

receiving data at a receiving interface of the node;

selecting at least one of a plurality of further interfaces of the node, and relaying the received data from the or each further interface, wherein a further interface is selected in dependence on a set of correlation coefficients for the receiving interface.

13. A method according to claim 12, wherein if the correlation between the receiving interface and the or each other interface is below a metric, the metric is derived from the correlation matrix and data is relayed.

14. A computer-readable storage medium comprising computer-executable instructions that, when executed, cause a processor to perform the method of any of claims 1 to 13.

15. An electronic device, comprising: an interface device; one or more processors connected to the interface device; a memory connected to the one or more processors, the memory having stored thereon computer-executable instructions that, when executed, cause the one or more processors to perform the method of any of claims 1-13.

16. A node of a blockchain network, the node being configured to perform the method of any one of claims 1 to 13.

17. A blockchain network having nodes according to claim 16.

Technical Field

The present specification is generally directed to computer-implemented methods and systems suitable for implementation in nodes of a blockchain network, illustrating modified blockchain link point structures, network architectures and protocols for handling large volumes of transactions and large transaction blocks. The invention is particularly applicable, but not limited, to use with bitcoin blockchains.

Background

The term "blockchain" is used herein to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain techniques, licensed and unlicensed ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most well-known application of blockchain technology is the bitcoin ledger. Although reference is made herein to bitcoin for purposes of convenience and illustration, it should be noted that the present invention is not limited to use with bitcoin blockchains, and other blockchain implementations and protocols are within the scope of the present invention. As used herein, the term "user" may refer to a human or processor-based resource.

A blockchain is a point-to-point electronic ledger implemented as a computer-based decentralized, distributed system consisting of blocks, which consist of transactions. Each transaction is a data structure encoding a transfer of control of a digital asset between participants in a blockchain system, each transaction including at least one input and at least one output. Each block contains a hash of the previous block such that the blocks are linked together to create a permanent, unalterable record of all transactions that were written into the block chain from the birth of the block chain. The transaction contains applets, called scripts, which are embedded in the input and output of the transaction, specifying how and by whom the output of the transaction is accessed. On bitcoin platforms, these scripts are written using a stack-based scripting language.

In order to write a transaction to a blockchain, the transaction must be "verified". The network node (miners) performs this work to ensure that each transaction is valid and that invalid transactions are rejected by the network. The software client installed on the node performs this verification work by executing its lock and unlock script on an inexpensive Transaction (UTXO). If the execution of the lock and unlock script evaluates to TRUE (TRUE), the transaction is valid and the transaction is written to the blockchain. Thus, in order to write a transaction to a blockchain, the transaction must: i) verification by a first node receiving a transaction-if the transaction is verified, the node relays the transaction to other nodes in the network; ii) added to new blocks built by miners; iii) mined, i.e. added to public ledgers for past transactions.

While blockchain technology is known for use with cryptocurrency implementations, digital entrepreneurs have begun exploring cryptosecurity systems based on the use of bitcoins and data that can be stored on the blockchain to implement new systems. It would be advantageous if blockchains could be used for automation tasks and processes that are not limited to the field of cryptocurrency. Such a solution would be able to take advantage of the strengths of blockchains (e.g., permanent, tamper-resistant logging of events, distributed processing, etc.) while being more versatile in its application.

According to reference [1], the average number of bitcoin transactions per block is about 2000 units. In the near future, the limit on the maximum tile size may be relaxed and the number of transactions per tile may increase substantially.

Competitive cryptocurrency requires that large numbers of unacknowledged transactions be disseminated as quickly as possible. In contrast, the peak capacity of a Visa electronic funds transfer is 56k transactions per second [2 ].

The current three-step messaging protocol for exchanging new transactions in bitcoin networks via inventory is not sufficient to cope with the rapid spread of transaction volumes (about 5 transactions per second [3]) several orders of magnitude larger than the current standard.

In terms of computational effort, today's bitcoin networks are primarily focused on mining. This is not necessarily possible as the volume of transactions increases significantly.

Not only is data flow management critical, but also the technical capacity or capabilities of the nodes and networks need to be considered.

The solution described in this specification enables bitcoin networks to handle the propagation of large numbers of transactions, while taking into account the limitations of the nodes and the network.

Known methods of sending data packets or transactions in bitcoin networks, for example, propagate new transactions through three steps of messaging, resulting in slow propagation of data packets in the network. The look ahead step results in queues going in and out of the node. These problems are exacerbated when a node is required to operate above or near its nominal limits.

Disclosure of Invention

In general, the present invention is directed to a new method for processing and propagating increased traffic, which is several orders of magnitude greater than current blockchain capabilities. This may be achieved by supporting faster propagation of data packets in the network, which is achieved by reducing communication between nodes. By selectively relaying packets based on the correlation between interfaces, long queues into and out of the node due to bottlenecks may be prevented. Additionally or alternatively, the present invention relates to a new method for managing data or traffic arriving at a peer node over a node interface. The data to be transmitted and the local resources may be considered. The local resources may include at least one of bandwidth resources, data profiles, number of connected peers, and node capabilities. The functionality of the node may also be considered.

The method enables nodes to operate in an adaptive manner such that (i) the number of interfaces connected to a peer node is unknown, and (ii) changes associated with the interfaces of the nodes are unknown, thereby addressing new connections, broken connections, and malicious nodes, and maintaining the integrity of the network.

The method allows the number of interfaces that can be managed on a node to be unlimited, which makes the performance and scale of the network unlimited, since the method can adapt to the conditions of the network and the node. Invalid transmissions are minimized and malicious nodes are circumvented.

The method allows determining a minimum and a maximum number of connected peers. The time window for performing the critical task may be adjusted accordingly.

The method improves blockchain network performance and provides an improved blockchain network or overlay network cooperating with a blockchain network.

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

It is therefore desirable to provide a computer-implemented method for a node of a blockchain network, the node having a plurality of interfaces to peer nodes, the computer-implemented method comprising: determining the bandwidth capacity of the node based on the maximum data volume which can be processed by the node within a certain time; monitoring data comprising input data and output data, the data originating from the peer node via the interface of the node and arriving at the peer node via the interface of the node, and determining a profile factor for the node based on a difference between the input data and the output data; monitoring the data over a plurality of time periods; setting a minimum number of peer nodes connectable to the node and a maximum number of peer nodes according to the monitoring data and the maximum number of peers connectable to the node.

The method enables the node to adjust the number of connections according to performance limiting factors such as bandwidth availability and processing performance.

The monitored data may be used to determine a ratio over at least one time period. The ratio may be used to determine setting a maximum number of peer nodes and a minimum number of peer nodes connectable to the node. The ratio may be calculated from the data passing through the node and the maximum amount of data that the node can handle. The ratio may be non-linear.

The profile factor may be assigned a value based on the function of the node, where the value of the profile factor is one (1) for the value of the node used to route the data, greater than one (1) for the value of the node collecting the data, and less than one (1) for the value of the node generating or providing the data.

The node may have a plurality of interfaces connected to peer nodes and the correlation matrix may be determined from correlation coefficients representing correlations between data processed at each interface of the node. The time period may be determined according to the length of time between changes to the correlation matrix. The change may be associated with the node initiating, or may be associated with the node joining or leaving the network.

The node may receive information related to node activity on the blockchain network and determine a time period based on a length of time between changes in the correlation matrix.

Averaging data, said averaging data comprising an average of the data over a plurality of time periods, is operable to determine a minimum number of peer nodes and a maximum number of peer nodes connectable to the node by determining a ratio of the average data to the maximum data.

The method may further comprise: determining a variance of the data over a plurality of time periods; applying a scaling factor to the variance; and determining a minimum number of peer nodes and a maximum number of peer nodes connectable to the node according to the proportional variance.

The minimum and maximum number of peer node connections (m) may be determined by the following equation:

wherein D is the average level (D) of data for a plurality of time periods (T), D is the maximum data (D) that a node can process during a time period (T),

p is the maximum number of peers (P), σ, that can be connected to the node²Is the variance of the data (d), t is a scale factor or variance parameter, and m_max≤P。

The scale factor or variance parameter t may be defined by the following equation:

the average of t may be used when determining the minimum and maximum number of peer nodes that may be connected to the node.

The time period may be temporarily adjusted by the node to a predetermined value to accommodate at least one of: update the local parameters of the node, start a time period in which the node accumulates data, and relay the data temporarily to all peer nodes.

The time period may be a flow control parameter. The parameters may be adjusted to modify traffic through the node.

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

When a node has multiple interfaces to a peer node, the multiple is at least the minimum number of interfaces (m) to the peer node_min) And less than or equal to the maximum of the interfaces connected to the peer nodeLarge number (m)_max) The method may further comprise: determining a correlation matrix having correlation coefficients representing correlations between data processed at each interface of the nodes; receiving data at a receiving interface of the node; selecting at least one of a plurality of further interfaces of the node, and relaying the received data from the or each further interface, wherein a further interface is selected in dependence on a set of correlation coefficients for the receiving interface.

The indicator may be derived from the correlation matrix. Data may be relayed if the correlation between the receiving interface and the or each other interface is below a criterion.

The data may correspond to an object (e.g., a transaction or a block). If the correlation is higher than the index, relaying can optionally occur. The indicator may be a threshold. The indicator may represent a degree of correlation, e.g. an average, between the interface receiving the data and the plurality of interfaces. The average value may be an average value of correlation coefficients between the receiving interface and the other interfaces. The metric may be used to determine a metric that sets a criterion for determining which other interface to select for relaying data. The metric may be considered an instruction for selecting which interfaces to relay data from. The instructions may be set according to a threshold or index.

For example, the instructions require that the interface have a dependency index below the index. The instructions may determine which interface relays the data based on whether the correlation index is above or below the index.

An example of data relay when the index is below the index may be normal steady state network conditions. In "steady state" conditions, the number of interfaces and connected peers remains unchanged, and therefore the correlation matrix is unchanged.

Examples of data relaying when the exponent is above the index, the condition may be variable, e.g. adding a new peer node connection to the node. Different instructions may be applied to different interfaces.

The distributed data may include data received from the blockchain network, including data from miners, peer nodes, and complete nodes. The correlation between data processed at each interface of a node may account for duplicate packets or objects received at the node. The metric may be an average or median of the correlation indices for each interface of the node. The metric may define a point between the lowest and highest correlation interfaces. When the correlation index is below the index, data or objects may be relayed from the interface. Interfaces with low degrees of correlation may be prioritized because it can be safely assumed that interfaces with high degrees of correlation will acquire data.

The nodes process data through the interface, including sending and receiving data or objects, such as transactions or blocks.

The data may pertain to network packets representing serialized transactions and identifiers representing connections to neighboring or peer nodes. The interface may be a logical interface ID that represents a TCP/IP connection with the sending/receiving peer.

The node may establish a correlation matrix by monitoring (i) the data identifier of each data packet processed through each interface and (ii) the same transaction processed through the interface pair, and determining therefrom a correlation coefficient between any two interfaces. The correlation matrix may have m (m-1) elements and may be used to determine the correlation index for interface a, as follows:

where m is the number of interfaces connected to the peer node.

The correlation matrix may have m (m-1) elements and may be used to determine a set of correlation coefficients for interface a as follows:

{C_a}＝[c_0a,c_1a,…c_am-1].

the indicator may be determined as follows: determining for each interface connected to a peer node a set of correlation coefficients derived from the correlation matrix, the set having the connection coefficients between each interface; a mean or median is derived from the set.

The indicator may be used by a set of instructions to determine which interfaces relay data.

The metric used to determine the number of nodes to relay data may also be based on at least one of: a reset time, i.e. the time since the node was started, and a change time, i.e. the time between change events, said events comprising at least one of: a new peer node connected to the interface; a termination connection with the interface; and an interface to connect to the malicious node. The reset time is available to the new node. The change time may be available to the existing node.

At startup of a node, the node may connect with a peer node, e.g. a peer node adjacent to or directly connected to the node, and relay data via all interfaces for a reset period, establish a correlation matrix during the reset period, and after the period has elapsed, the node relays all objects from the node over the interfaces having a correlation index below a metric.

Once a change event is detected, the correlation matrix may be reset and re-determined. This may occur when a periodic reset is required.

The invention also relates to a computer-readable storage medium comprising computer-executable instructions for causing a processor to perform the claimed method when executed.

The invention also relates to an electronic device comprising: an interface device; one or more processors connected to the interface device; a memory coupled to the one or more processors having stored thereon computer-executable instructions that, when executed, cause the one or more processors to perform the claimed method.

The invention also relates to a node of a blockchain network for performing the claimed method. The invention also relates to a blockchain network with nodes, as claimed.

Drawings

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

FIG. 1 illustrates a network data packet sent and received serially at an application layer by a node on a bitcoin network;

FIG. 2 illustrates the routing taken by a single transaction between nodes and throughout the bitcoin network;

FIG. 3 is a graphical representation of a correlation matrix showing correlation coefficients of interfaces connected to peer nodes; and

fig. 4 is a schematic diagram showing nodes having different functions in a blockchain network.

Detailed Description

In this specification, a solution to the problem of handling and storing large, gigabyte-sized blocks is described. By determining connectivity between nodes and relaying data accordingly, efficient trading of data across a blockchain network may be improved. In addition, the size and available bandwidth of the nodes can affect the data traffic across the network and the number of connections the nodes have, and the time to determine connectivity can be adjusted to improve the traffic.

Treatment ofTypes of blockchain network nodes and verification nodes

A blockchain network may be described as a peer-to-peer open member network that anyone can join without invitations or consent from other members. A distributed electronic device running an instance of a blockchain protocol (a blockchain network runs under the blockchain protocol) may participate in the blockchain network. Such distributed electronic devices may be referred to as nodes. For example, the blockchain protocol may be, for example, a bitcoin protocol or other cryptocurrency protocol.

Some blockchain networks (e.g., bitcoins) use TCP for node-to-node communication. Packets sent using TCP have an associated sequence number that is used for ordering.

In addition, the TCP protocol involves a three-way handshake procedure both when establishing and terminating a connection. There is an associated overhead for packets sent over TCP that have associated sequence numbers and a three-way handshake protocol. When a connection is established, 128-136 bytes are transmitted, while it takes 160 bytes to close the connection. Therefore, the handshake cost in packet transmission is up to 296 bytes.

In addition, when a node receives a new transaction, it notifies other nodes through an Inventory (INV) message that contains the transaction hash. The node receiving the INV message checks whether the hash of the transaction has been seen; if not, the node will request a transaction by sending a get data (GETDATA) message. The time required for the transaction to travel from node a to node B is T1 ═ verification + TCP (inv + getdata + tx), where TCP () represents the time overhead introduced by the TCP handshake process.

TCP protocol and three-way handshake

The current point-to-point bitcoin protocol defines 10 data messages and 13 control messages. In this context, the transmission of data or data packets related to Object Transfer (Object Transfer) may refer to a single transaction or block.

A complete list of messages used by bitcoin point-to-point protocols is known, see reference [4] for a complete list. The subgroup of messages relates to the request or distribution of objects. These messages are BLOCK (BLOCK), get data (GETDATA), list (INV), Transaction (TX), memory pool (MEMPOOL), and miss (notify). The subgroup of messages is related to the reliability and efficiency of the object. These messages are FEEFILTER, PING, PONG and REJECT.

For example, nodes "i" and "j" on a bitcoin network communicate by:

1. node i sends an INV message containing a transaction list.

2. Node j replies with a GETDATA message asking for a subset of the transactions that were previously notified.

3. Node i transmits the requested transaction.

The methods herein attempt to optimize the protocols of a blockchain network to at least improve the propagation of data.

Fig. 1 illustrates a practical scenario in which data in the form of network packets are serially sent and received at the application layer in accordance with primitives provided by the operating system. Assuming transaction x fits into a single ethernet/IP packet, its transmission to m peers requires buffering m different outgoing packets. Incoming and outgoing network packets and other information will include:

-serializing the transaction.

Logical interface ID, representing the TCP/IP connection with the sending/receiving peer.

The expected time of incoming transaction to be processed depends on the input queue LⁱIs determined by the average length (in packets) of the transaction, and the expected time to correctly transmit the processed transaction depends on the output queue L^oIs measured.

Thus, efficient relaying of transactions is dependent on LⁱAnd L^oThe value is decreased. However, the probabilistic model for selectively relaying transactions to peers directly impacts L^oAnd also influence L by inductionⁱ。

In current bitcoin implementations, INV and GETDATA message packets are queued in the I/O buffer in the same manner as transactions, which severely impacts transmission and reception delays.

Connectivity-efficient transaction propagation-probabilistic relaying

If node i is allowed to transmit new transactions directly without using inventory exchange, the transactions will propagate through the network at a faster rate. However, if there is no provision, the network will be overwhelmed.

Thus, the methods herein use a mechanism for selectively relaying data or objects from a node to a peer node to avoid transmitting large amounts of unnecessary transactions. The mechanism may be a probabilistic model.

Referring to fig. 2, a mechanism or probabilistic model for transaction relaying is based on an assumption that three nodes i, j, and k are part of a bitcoin network and are connected together. Node i is directly connected to node j and node k. Nodes j and k are connected indirectly through node i or through the bitcoin network.

Node i is shown with two interfaces a and b that process data in the form of a transaction r that is initiated at node i and undergoes various stages of propagation between nodes and throughout the bitcoin network, including:

a first stage r₁The transaction is processed for transmission from interface a to the peer node, and received at node j,

-a second stage r₂Node j processes the transaction, which is transmitted over the bitcoin network, received at node k, and

-a third stage r₃Node k processes the transaction for transmission to peer node I, which receives the transaction at interface b.

For the avoidance of doubt, r₁，r₂And r₃Are the same transaction and the suffix indicates the relay.

The following assumptions were made:

-if the node receives from interface (b) the same transaction as the transmission process from the other interface (a), then the two interfaces have a certain degree of correlation.

If a transaction generated at node i arrives at node j through the input interface given to j, then a second transaction generated at node i will most likely arrive at j through the same interface.

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, then node i receives the same transaction from node k, j and k share a logical path through the network. Thus, the originating node does not need to relay the same information to its two peer nodes. It should be clear that node i does not need to transmit transaction r to node k, since node k has a high probability of receiving the transaction. Similarly, node k, in contrast, does not need to send transaction r to node i because the likelihood of receiving the transaction is high. The logic is valid in both directions.

Relationships between node interfaces

Fig. 3 is an example of a local correlation matrix C that may be determined for a node i having five interfaces a, b, C, d, and e connected to a peer node. The matrix represents the degree of correlation of incoming traffic. The formation and application of the matrix is described below. The values shown in fig. 3 are for illustration purposes only.

Each node is formed by determining, for example, a coefficient c_abTo establish a correlation matrix C, the coefficients C_abRepresenting the correlation between the transactions received from interfaces a and b. Such coefficients are determined between all pairs of interfaces.

Let t use the list of transaction IDs received from each interface_aAnd t_bThe number of transactions received from interfaces a and b, respectively, and t_abIs the number of repeat transactions received from a and b. The correlation coefficients of interfaces a and b are defined by equation 1:

conventionally, for the coefficient c_abLet the dictionary order of its indices be a<b, i.e. between the interface ID and the value, a is assigned '0' (a ═ 0), b is assigned '1' (b ═ 1), and c is assigned '2' (c ═ 2), and so on. Given a set of correlation coefficients for the interfaces { a, b, d, e }, if c_ab>c_deThen interfaces a and b are more relevant than interfaces d and e.

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

Assigning values to node interfaces

The overall correlation index for interface a is defined in equation 2 as follows:

taking the correlation matrix in FIG. 3 as an example, the correlation index c of the interface a_aMay 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

This metric can be used to rank the relevance of the various interfaces and understand the relay quality provided by the node peers. For example, if the correlation index of a is significantly higher than the average, then the transactions received from a are highly redundant.

Conversely, if the correlation index of a is much lower than the average, then (i) the transaction received from a is somewhat unique, or (ii) the behavior of the peer node connected to a is malicious. Malicious behavior will be discussed in more detail below.

It is noted that each node builds its own correlation matrix based solely on the received transaction flow. No association information is exchanged between nodes or peers to avoid spreading malicious information.

Index (I)

Given an incoming transaction from interface a, the node will relay to m_min,m_max]M peers within the range.

The current value m depends on m-1 correlation coefficients c_aThe correlation coefficient comprises the connection index a:

{c_a}＝[c_0a,c_1a,…c_am-1]

in other words, { c_aIs a list or set of correlation coefficients, the set having coefficients of interface a. The connection index being the sum of the coefficients, i.e. c_a＝c_ab+c_ac+c_ad+c_aeAs shown in fig. 3 and the above example.

The number of interfaces m (a) selected from interface a for relaying depends on the set of pairs c_aThe metric θ of each element in_i ^(a)Wherein:

the metric theta_i ^(a)Acts as a translator or selector and indicates whether the interface is relaying data. For example, if the metric of the interface is "1", the interface will relay the data; if the metric of the interface is "0," the data is not relayed.

By mixing

Is defined as a set { c_aMean value of coefficients in (f), if the corresponding correlation coefficient c_aiIs less than

Then measure theta_i ^(a)Will contribute to m (a):

or, theta_i ^(a)May be based on { c_aMedian value of } instead of mean value. The metric theta_i ^(a)Or from the set c based on using statistical analysis_aThe derived alternative values can also be derived from the set c by using statistical analysis_aDerived substitution values are determined, for example, if the corresponding correlation coefficient c_aiIs a set { c_aAt least one standard deviation below the mean of the values of θ, the metric_i ^(a)Contribute to m (a).

For example, an incoming transaction from interface a in FIG. 3 would be according to { c }_aThe correlation coefficients in the are relayed to m x (a) least relevant interfaces. Selecting { c ] for relaying_aWill be defined as c_a}。

Returning to the example of FIG. 3, if { c }_a0.2,0.8,0.2, then,

θ_b ^(a)＝1

θ_c ^(a)＝0

θ_d ^(a)＝1

θ_e ^(a)＝1

therefore, the number m (a) of interfaces selected from the interface a for relaying is "3". The coefficients in the subset falling below the mean or index are {0.2, 0.2,0.2}, which are used to determine the metric θ_i ^(a)Select and { c }_aRelaying with the coefficients corresponding to interfaces b, d, e。

The "cutoff point or coefficient criterion used in the above example to determine the metric is the mean value of the coefficients-" 0.35 ". This threshold or metric determines the metric θ_i ^(a)From theta_i ^(a)Determining m (a).

Thus, in general, the method can be said to relay data from the interface according to the metrics. The metrics may be used to determine a metric for each interface that determines whether it will relay data.

Although metrics are determined using metrics in the above example, other factors may affect the metrics for each interface. The metrics for each interface may be calculated from the change in the correlation matrix.

Adapting to changes

As described above, it is determined which interfaces will be used to relay information, assuming a steady state condition in which the matrix has not changed.

More details of the protocol are provided below to explain how the protocol accommodates changes, for example, when a peer node joins the network and establishes a new connection with the node, or when a peer node leaves the network and is no longer connected to the network.

In adapting to the change, data may be relayed based on a metric that takes into account the index and the correlation index.

Starting up

When node i is started, it will initiate m peer-to-peer connections with other nodes in the blockchain (e.g., the bitcoin network). For detailed information see, for example, bitcoin developer reference [4 ]. In the initial phase, node i has no information about the correlation between data passing through its interfaces and has a limited data set representing the data passing through or flowing through it. Thus, a complete transaction relay will be performed over a period of time.

At T_bootupDuring, measure θ_i ^(a)M x (a) is facilitated by setting each interface to "1" and relaying data from all interfaces. Thus, the metric allows data to be relayed without regard to the metric over a period of time.

Period T_bootupIs a function f (m) of m, i.e. the larger the number of connections, the longer the time needed to build an accurate correlation matrix. The following functions are presented, by way of example only:

f₁(m):＝m f₂(m):＝m²

at T_bootupAfter that, the node i performs selective relaying as an existing node shown below.

Existing node

The connection of the generic node j will change over time due to other nodes (i) joining, (ii) leaving the network and/or (iii) exhibiting malicious intent, which are selectively blacklisted and the corresponding connections closed.

Thus, any change in the overall network map may be by the amount T_changeTo perform detection and parameterization, quantity T_changeRepresenting the average time between two (or more) consecutive change events. Every T_changeOnce, the local correlation matrix for node j needs to be updated.

The updating of the correlation matrix of the node may comprise at least one of:

-a periodic reset, wherein the correlation matrix is reset.

As a new node, will be at a time T_bootupAnd complete transaction relay is performed. Node j then performs selective relaying of the new m values for each interface connected to the peer node.

-updating, wherein the correlation matrix is updated.

Given from the selected set { c }_aInterface a of (i.e. the β most relevant interfaces, 0)<β<m_min) Will not be in { c }_aβ least relevant interface exchanges in the array.

In other words, in general, when relaying data to the subset { c }_aM (a) least relevant interfaces in the matrix will not belong to the subset c when the matrix is updated_aInterfaces with low correlation indices are added to the subset in place of interfaces with high correlation indices in the subset.

This ensures the integrity of the data flow across the network at the time of the change.

Returning again to the example of fig. 3, in general,

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}

will be provided withAs a set { c_dMean value of coefficients in (f), if the corresponding correlation coefficient c_diIs less thanThen measure theta_i ^(d)Contribution m (d):

then:

θ_a ^(d)＝1

θ_b ^(d)＝1

θ_c ^(d)＝1

θ_e ^(d)＝0

typically, the number m (d) of interfaces selected from interface d for relaying is "3". The coefficients in the subset falling below the mean or index are {0.2, 0.4,0.4 }, which are used to determine the metric θ_i ^(d)Select and { c }_dAnd relaying the coefficients corresponding to the interfaces a, b and c.

For the avoidance of doubt, the coefficients corresponding to interface e, i.e. {0.6}, are not in the selected subset { c }_dIn.

When an update occurs, it is coincidental, with respect to interface d, that it is in the set { c }_dThere are two interfaces that belong toThe β most relevant interfaces, interface b and c, both have a value of 0.4.

Only one interface corresponds as not belonging to { c }_dβ least relevant interfaces of the interface, said interface is e, therefore, only one "swap" can be done, and the interface to be swapped is b or c, both of which are 0.4 because the coefficients are the same_aβ least relevant interfaces in the set, which means that it will be switched from the set c_dThe lowest coefficient is selected from the remaining coefficients {0.4,0.4,0.6 }. The lowest coefficients correspond to interfaces b and c, so data will be relayed to peer nodes connected to these interfaces, rather than to interface a.

If a peer disconnects, its coefficients in the correlation matrix will become invalid. At T_changeAt the end of the period, the above-described periodic reset is required. Node j then performs selective relaying on the new m values of each connection interface.

If a new peer b joins, it will choose the interface to which it is connected to relay with { c } of every other peer interface with node a_aThe current value of. For example, at time T_joinThe interface with b is randomly selected for relaying at the frequency of every gamma incoming transactions.

According to T_bootupAnd/or T_changePeriodic setting T_join. The relay will help node b to build its own correlation matrix. At T_joinAt the end, it will be only based on the updated values { c } of every other peer interface on node a_aB to select b for relaying.

Node i may need to check if its peer j is still present because no incoming traffic is received from its interface. Can use any small amount of time T_tempThe temporary relay request is sent to j.

The node issuing the new transaction, i.e. the originating node, needs to select a set of selected peers to relay carefully in order to guarantee propagation in the network. For example, m nodes of any interface a may be selected as the first relay, where m (a) < m.

A complete list of parameters is detailed in table 1 below.

TABLE 1

Malicious node

Malicious nodes aim to reduce the efficiency of the probabilistic model for transaction propagation. A malicious node may act in any of the following ways.

Malicious nodes do not propagate the transaction that should be propagated. A honest node connected to the malicious node may be able to retrieve these transactions from other honest (or malicious) peers. However, given that a group of miners may still receive and include these transactions in a new mined block, there is no need to fully propagate the transactions in the network.

Malicious nodes propagate the same legitimate transaction multiple times. The receiving node is able to track previously received transactions through a look-up table. Thus, misbehaviour is easily discovered and malicious peers will be removed.

-the malicious node propagating the invalid transaction. If the receiving node performs transaction verification, misbehaviour is easily discovered and malicious peers will be removed.

Malicious nodes generate and propagate a large number of virtual transactions. The recipient node may respond differently to a large number of valid incoming transactions from the peer. In response, (i) the receiver will ask the sender to reduce the transaction relay rate. If the problem still exists, the sender peer will be removed;

(ii) the recipient may ask (and check) the relay transaction for a minimum transaction fee. This makes the attack expensive for the malicious node. (ii) if the minimum transaction fee is not adhered to, the sender peer will be removed, and/or (iii) the sender peer is simply removed.

Based on the aforementioned attack and probability models, the following properties can be inferred.

The transaction relay rate depends on the bandwidth availability and the processing performance of the individual nodes. Therefore, the default maximum rate is not performed.

Malicious nodes cannot easily do this. The malicious node must forward the valid transaction,

to maintain the presence of its connection.

Message

The method herein includes probabilistic relaying of data or objects from node interfaces on the bitcoin network, and new message types may be introduced in support of implementation of the method herein. Furthermore, some of the current message types described in detail above with respect to the current point-to-point bitcoin protocol are not used, while message types not mentioned below remain unchanged with respect to the bitcoin point-to-point protocol.

Data message

The message GETDATA requesting one or more data objects from another node is no longer used. Similarly, the message INV for transmitting one or more lists of objects known to the peer is no longer used. The notify message is no longer used as a reply to GETDATA.

The MEMPOOL message, as introduced above, requests the ID of a transaction (i.e., a transaction in the memory pool of the receiving node) that the receiving node has verified as valid but is not disclosed in a block, and the response to this message is one or more INV messages containing the transaction ID. The node sends the required number of INV messages to reference its full memory pool. A node may disable this function and therefore need not transmit its local MEMPOOL.

Control messages

PING and PONG messages are removed to confirm that the peer is still connected. Malicious nodes such as silent nodes are managed as described above. Message FEEFILTER remains unchanged. However, peers that do not comply with the charging threshold will be removed.

New messages TEMP and FLOW are introduced.

-checking peer nodes when a node is required to check for incoming traffic due to not receiving it from an interface of the nodeIf it still exists, the TEMP message is used. Will temporarily relay the request TEMP (for an arbitrarily small amount of time T)_temp) To a peer connected to the interface. If the receiving peer starts relaying, but does not obey a given time window T_tempThe peer is removed from the matrix.

FLOW messages are used when a node requires a peer to modify a transaction relay rate (e.g., number of transactions per second) according to local FLOW control. The rate may be increased, decreased, or temporarily suspended (relay rate 0). If the receiver does not comply with the new relay rate, the receiver is removed. A new FLOW request will be needed to modify the current relay rate. If the receiver does not receive the second FLOW request to resume relaying, the sender will be deleted.

-requiring the node to use the minneee message when receiving transactions filtered by the lowest transaction cost.

If there are multiple transactions in a single IP packet, a minimum value may be set for a single transaction and/or total amount of charges. If the receiving peer does not comply with the transaction fee limit, it is removed.

Determining

Fig. 4 shows elements of a blockchain network with nodes i, j, k and l. Nodes may have different traffic profiles and may be classified and referred to as

"provider" is the node that generates the transaction primarily, and node i may represent one or more merchant nodes with specialized business activities

"collector", which is the node that collects mainly the transactions, node l may represent one or more merchant nodes with specialized business activities

"Router" is the node that primarily routes transactions, such as node j and node k.

Each node is capable of automatically controlling input/output traffic based on the current state of its connection and locally available bandwidth resources. The bandwidth allocation between input and output resources or interfaces may be adjusted according to the type or function of the node. Nodes i and j will be unbalanced and nodes j and k will be balanced, since the same amount of data flowing into a router node will flow out of that node.

A node, such as node j, has multiple interfaces to connect to peer nodes. A node may determine its bandwidth (B) capacity based on the maximum amount of data (D) that the node can handle within a time period (T). Some nodes have an upper bandwidth limit imposed by their network provider.

B_jIs the application layer bandwidth available at node j. Bandwidth B_jIs an overall budget that depends on (i) the quality of network access provided by Internet Service Providers (ISPs) and (ii) the network usage of other local applications.

B_jIs dependent on the input flow B_j ⁱAnd output flow rate B_j ^oDifferent bandwidth requirements. Thus:

for a router, assume:

for the collector, assume:

k_jis a profile factor of the node and is determined, for example, according to the type of node (i.e., nominally set) or according to the difference between actual data entering and exiting the node. The profile factor k_jPreferably by the ratio of data input to the node and data transmitted from the node, which may include relayed data and/or locally generated data.

Data (d)_j) Input data (d) that may be sent from a peer node over an interface of node j_j ⁱ) And output data (d) sent to the peer node_j ^o) To monitorControl and set up, and may be based on input data (d)_j ⁱ) And output data (d)_j ^o) The difference between them determines the profile factor (k) of node j_j)。

The data (d) can be monitored over a plurality of time periods (T)_j). When a new period T begins, the monitored data value may be reset to zero. The data generated in node j contributes to the output data (d)_j ^o)。

The time period (T) may be used to determine the maximum amount of data (D) that the node j can handle_j) Thereby to make

Wherein d is_j ⁱAnd d_j ^oIs the maximum amount of incoming and outgoing data supported during that time period.

The time period T may be a flow control time window T_flow. Considering the variables of node j, then:

thus, D_j ⁱAnd D_j ^oIs dependent on k_j，T_flowAnd B_jThe system parameter of (1).

Current factors

To optimize the performance of the blockchain network, bitcoin is taken as an example. By default, the specification of the bitcoin core allows up to 125 connections to different peers, 8 of which are outbound connections. Thus, there may be a maximum of 117 inbound connections.

The number m of peers P that can connect to the node is limited, so for the current system m_minIs 1, m_maxIs 125. Without current restrictions, the number m of peers P connectable to a node is m_minNot less than 1 and m_max≤P。

The minimum number of peer nodes (m) connectable to node j may be set in dependence of said monitoring data (d) and the maximum number of peers (P) connectable to node j_min) And maximum number of peer nodes (m)_max)。

The monitored data (d) may be used to determine a ratio over two or more time periods (T), and use the ratio to set a minimum number of peer nodes (m) that may be connected to node j_min) And maximum number of peer nodes (m)_max). The ratio may be between the actual data and the data limit. Other relationships may be used, such as a non-linear relationship between data (D) and maximum data (D).

In addition to the relationship between data (D) and data limit (D), the type or function of node j may be factored into determining the number of peer nodes to which node j may connect. The function is taken into account by using a profile factor (k) which is assigned a value according to the function of the node. The profile factor may be variable.

For example, the profile factor value is one (1) for nodes used to route data, greater than one (1) for nodes that collect data, and less than one (1) for nodes that generate or provide data.

To reduce fluctuating or rogue data, the mean data (D) comprising an average of the data (D) over a plurality of time periods (T) may be used to determine the maximum and minimum number of peer nodes that may be connected to node j by determining a ratio of the mean data (D) to the maximum data (D).

Still further, the section may be determined to be connectable theretoMinimum number of peers of a point (m)_min) And maximum number of peer nodes (m)_max) The buffering factor is taken into consideration. Such buffering factors may include using a standard deviation (σ) or variance (σ 2) of the data (d) over a plurality of time periods (T), applying a scaling factor to the variance, and determining a minimum and maximum number of peers connectable to the node according to the scaling variance. The scaling factor may be a variance parameter t.

Monitoring data (d)_j) Is the output data (d) sent to the peer node via the interface of node j_j ^o) And input data (d) from the peer node_j ⁱ) The sum of (a) and (b). Thus, the minimum and maximum number of peer nodes m that can connect to node j can be set by:

wherein the content of the first and second substances,

m_minand m_maxIs an integer number of peer-to-peer node connections

d_jIs the average level of data (d) over a plurality of time periods (T),

D_j ⁱand D_j ^oIs the maximum amount of incoming and outgoing data supported over the time period (T),

p is the maximum number of peers (P) that can connect to the node,

σ²is the variance of the data (d) over a given time period (T),

t is a scale factor or variance parameter, and

m_max≤P

linear range [1, P]And [ m ]_min，m_max]There may be a direct and proportional relationship between the values.

For averaging d_jAnd the time period (T) or T for updating T_flowTime of dayThe number of windows may be constant. The variance parameter t may be a multiplier.

By adding m to the preceding equation_minNot less than 1 and m_maxP, the equation can be rearranged to determine a range of values for the variance parameter t, which can be written as:

during node bootstrapping or initial setup, m_min1 and m_max＝P。

Variables P, D and D_jIs limited and therefore depends on σ_j ²The operating range of t is limited. For example, given P125 and d_j*/D_jWhen the value is equal to 0.5, then

An approximation of the range mean may be used to determine the variance parameter, which may be expressed by the following equation:

once m is determined_minAnd m_max(integer number of peer nodes connected) the node can further determine the correlation matrix between the interfaces and the peer node to which it is connected. A matrix is compiled with correlation coefficients representing the correlation between data processed at each interface of the nodes.

Time window (T)

The time period (T) is determined by the length of time between changes to the correlation matrix.

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

The time window between two consecutive local correlation matrix updates may be used to determine T.

The average number of active nodes is 7561¹(6 months 2017), an average increase of 0.85% every 24 hours, and the time T can be determined or at least influenced thereby. In this case, the initial value of T may be fixed to 60 minutes, considering that an average of 2.5 new nodes join the network per hour. During normal relay operation of a node, T may be treated as incoming data (d)_j ⁱ) Is inversely proportional to the current accumulated amount of (a).

When a new peer node is connected, it may be in a dedicated time period T_joinRelaying data to the new peer. Depending on the state of the network, it can be treated as outgoing data d_j ^oIs inversely proportional to the current accumulated amount of (a).

T_bootupIs the time required for the new node to establish a stable correlation matrix, which is proportional to the function f (m), i.e. the greater the number of connections, the longer the time required to establish an accurate correlation matrix.

For the purpose of the present invention, the time periods T and T_flowSame, T_flowIs the time window between two successive updates of the cumulative amount of incoming and outgoing data. The value may be related to T_changeProportional, in the simplest case, T_flow＝T_change＝T。

In other words, the time period (T) may be a flow control parameter (T)_flow) And adjusting the parameter to modify traffic through the node. The node may temporarily adjust the time period (T) to a predetermined value. This may be based on local changes to the nodes that affect the bandwidth and subsequently the data flow through. In these cases, a longer period of time may be used for a limited period of time, such as twice the length of the previous cycle (i.e., 2T). Similarly, the period T may be set as a start-up period in which the nodes accumulate data. A local change or initiation cycle may result in data being temporarily relayed to all peer nodes for a period of time.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" and "comprises", and the like, does not exclude the presence of other elements or steps in their entirety, even if these elements or steps are not listed in any claim or the specification. In the present specification, "comprising" means "including" or "consisting of", and "comprising" means "including" or "consisting of". The singular reference of an element is not intended to exclude the plural reference 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 the 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.

Small knot

In terms of computational effort, today's bitcoin networks are primarily focused on mining. With a large increase in the amount of transactions, this will not necessarily be feasible. The solution described in this specification enables the number of peer connections to be adjusted or determined according to the data to be processed and the bandwidth limitations. Although probabilistic relaying improves the processing and propagation of large numbers of transactions, performance capacity or available bandwidth at each node is not considered.

The present invention may provide a method of determining the number of connected peers and adjusting the timing of the node taking action, including the resetting or re-determination of the correlation matrix, start-up time, etc.

Thus, in addition to adjusting connectivity according to performance to optimize flows across the network by avoiding bottlenecks, the present invention facilitates the propagation of data packets by optimizing communications between nodes.

Long queues caused by node bottlenecks are suppressed by controlling connectivity and optionally relaying packets based on correlation between interfaces.

The total number of peer connections can be managed and refined with reduced data packet transmission while maintaining a level of security information redundancy.

Reference data

[1]Bitcoin transaction levels are made available via BlockchainLuxembourg S.A.R.L.and retrievable fromhttp://blockchain.info.

[2]VISA transaction levels are summarised in a document published by VisaInc.Visa Inc at Glance.June 2015.It is retrievable fromhttp://usa.visa.com/ dam/VCOM/download/corporate/media/visa-fact-sheet-Jun2015.pdf.

[3]Decker,Christian and Wattenhofer,Roger(2013).Information propagationin the bitcoin network.IEEE Thirteenth International Conference on Peer-to-Peer Computing(P2P),2013.

[4]A Bitcoin Developer Reference is retrievable fromhttp://bitcoin.org/ en/developer-reference.