Patent Application
20200228409
The disclosure relates to the selection of network routing topology in order to optimise network traffic routing in a distributed network, such as a peer-to-peer (P2P) network.
In a distributed network, such as a peer-to-peer (P2P) network for example, multiple nodes can be interconnected with one another and data can be passed between nodes to enable file sharing for example. In such networks, a distributed application architecture can exist that can partition tasks or workloads between peers, where a P2P network can be designed around equal peer nodes simultaneously functioning both as “clients” and “servers”. Peers can be equally privileged, equipotent participants in the application.
For cryptocurrencies, for example Bitcoin, decentralization of control is a design principle and can be achieved and maintained using a flat, decentralized P2P consensus network. Connectivities in decentralized P2P networks can be optimised using a local approximation in which each node optimises its own connectivity based on the current network topology that each node knows. The local approximation approach may therefore become sub-optimal and no longer lead to efficient routing as the network grows and, in some cases, it may even defragment the network.
In a first aspect there is provided a method for selecting a network routing topology in a distributed network comprising multiple nodes, the method comprising, at respective ones of the multiple nodes receiving candidate transactions representing a set of candidate network routing topologies, supplementing a database with the candidate transaction data, and receiving respective voting transactions from each of the other nodes, each representing an indication of a preferred candidate network routing topology, the method further comprising, selecting a network routing topology from the set of candidate network routing topologies on the basis of the voting transactions.
The method may further comprise generating a voting transaction referencing a candidate transaction proposing a candidate network routing topology.
The method may further comprise deploying the selected network routing topology for a predetermined period of time, or until a threshold value for a number of network changes is reached.
A candidate network routing topology may comprise a routing table generated using one or more predefined routing criteria.
The method may further comprise rewarding delivery of messages on the network which are compliant with the selected network topology.
The multiple nodes may be a subset of a larger number of network nodes, the remainder of which are configured to deploy a selected network routing topology.
The database may be a distributed database.
In a second aspect there is provided a distributed network comprising multiple nodes configured to receive candidate transactions representing a set of candidate network routing topologies, supplement a database with the candidate transaction data, receive respective voting transactions from each of the other nodes, each representing an indication of a preferred candidate network routing topology, and select a network routing topology from the set of candidate network routing topologies on the basis of the voting transactions.
In a third aspect there is provided a node in a distributed network, the node configured to receive candidate transactions representing a set of candidate network routing topologies, supplement a database with the candidate transaction data, receive respective voting transactions from multiple other nodes, each representing an indication of a preferred candidate network routing topology, and select a network routing topology from the set of candidate network routing topologies on the basis of the voting transactions.
The node may be configured to generate a voting transaction referencing a candidate transaction proposing a candidate network routing topology.
In a fourth aspect there is provided a machine-readable storage medium encoded with instructions for selecting a network routing topology in a distributed network comprising multiple nodes, the instructions executable by a processor of a node to cause the node to receive candidate transactions representing a set of candidate network routing topologies, supplement a database with the candidate transaction data, receive respective voting transactions from multiple other nodes, each representing an indication of a preferred candidate network routing topology, and select a network routing topology from the set of candidate network routing topologies on the basis of the voting transactions.
Embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:
Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.
Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.
The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and/or groups thereof.
Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.
The present disclosure relates to the selection of a network routing topology, in order to optimise network traffic routing in a distributed network. An example of a distributed network is a peer-to-peer (P2P) network. P2P networks are widely used for distributed file sharing networks and digital cryptocurrencies.
In general, P2P networking (or P2P computing) relates to a distributed application architecture that partitions tasks or workloads between peers. A P2P network is an example of a common protocol for a mesh network; it can be part of a physical network configuration, or virtually overlaid over physical network.
According to an example, a blockchain-based network optimisation method is described in which nodes can vote to optimise network topology in order to make network traffic routing more efficient. A network routing solution according to an example can use a blockchain system, where each blockchain node can be part of a blockchain P2P network. The network may have one or more blockchains built into it and may also maintain a global routing table that may or may not include transfer rates, ping times and so on.
Depending on how nodes use the network, each node can have interest in optimising the network in a different way, where the interest of one node may conflict with the interests of other nodes.
In an example, each node can propose a topology for the whole network routing solution and the node can submit the proposal to be considered for deployment at the next block on the blockchain. Every participating node can then be given a number of votes (for example one or more) in which to vote for the proposed solutions. The network routing solution that receives the most votes can then be recorded in the next block of the blockchain and deployed to the whole network.
In an example, protocols can include: proposing a solution and voting, voting, resolving two or more “winning” solutions, and deployment of the next topology. The resolved winning solution can be the selected network topology that is entered into the next block of the blockchain.
As discussed above, at least one processor of a node may execute instructions encoded on a machine-readable storage medium to cause the node to select a network routing topology in a distributed network including multiple nodes as discussed herein.
In an example, a single node may not be able to see every other participating node, and the single node's proposed solution to the network topology will be generally local, i.e. the proposal may include only the connectivity of the other participating nodes that the single node can see.
In an example, the proposed network topology solutions provided by each node, and to be voted upon, can be based on a previous global topology of the network. The connectivity of the previous global topology of the network can be modified based on the nodes that each node sees (and hence has been able to optimise locally). In this example, the selected proposal can provide a globally accepted network topology.
In an example, the issue of “local vs global” solutions can be resolved using ongoing voting results, in which each node takes a number (e.g. five) of the most voted (global) solutions that it can see, and performs its local optimisation based on the most voted (global) solutions, in order to propose a best result as its own solution.
In an example, votes can be submitted in parallel with network topology proposals.
A node may not necessarily have to wait for the next block in the blockchain to be mined, since nodes can cast their respective votes (in real-time) as they hear network topology proposals being submitted. In an example, one way to issue a voting transaction is by referencing a transaction that proposed the preferred topology, such that a node may be disallowed from voting for their own proposed topology.
The voting mechanism may consist of each node ranking a top number of solutions (e.g. top three solutions). For example, a node that first sees a topology that suits its own needs can vote for it by assigning a number. If that node then votes for another solution that is better suited it can assign a higher number than the first topology, i.e. the primary most favourable vote would have a lowest number, the second most favourable choice with the second lowest number, and so on. Whilst assessing the different proposed network topologies, a node may invalidate any vote that contains the same ranking number for different solutions so as to ensure a strict deterministic method to resolve which solution is ultimately voted for by the node. Whilst this is just one example of a voting method, it will be appreciated that other voting methods may also be possible and any custom voting mechanism can be used instead.
If two (or more) solutions receive an equal number of votes, the winning solution may be selected by ledger heuristics. In an example, this can be achieved as follows:
Once a new solution is selected and deployed in the network, all nodes use the same solution before another block is generated in the blockchain.
Since there are nodes joining and leaving the network from time to time, new blocks for an updated network routing solution will be required. The time interval for new block generation can be predefined or can depend on changes (or a rate of change) of the network nodes and their connection status. For example, this may include numbers of joining/leaving nodes, connection delays, interruptions, etc. Each node can then generate a new routing solution based on a previous solution and incorporate changes around itself when submitting another new vote.
In an example, the network routing topology can be deployed immediately in the next block of the blockchain. Alternatively, the network routing topology can be deployed after a set number of blocks in the blockchain, to ensure that the probability of the block belonging to a fork of the chain is very low.
In an example, node can deploy a heuristic algorithm to find semi-optimal routing tables. As an example, routing criteria can include a message that is passed to the network being treated such that every node sees the message exactly once and only passes it on to one other neighbour. In order to optimise for the total time the message needs to traverse the network a heuristic algorithm can be applied. An example heuristic algorithm that could be applied may be simulated annealing. The result would be that every node would end up producing their own unique suggestion of what the routing table should look like (at least if the parameters in the problem are non-trivial). To then decide which solution to vote for, each node may then evaluate the associated cost function to determine which solution it considers better, e.g. a measure of “good” can be determined by a cost function that is a function for which the lowest possible value is archived as a function of proposed solution. Different cost functions can be defined for a given routing table to assess the how well a proposed solution performs. Example cost functions can include an average shortest path between nodes or a best/worst case time. In another example, the nodes may deploy a “selfish” algorithm (such as Dijkstra's algorithm) to favour fast messages passing from itself to any other node.
To encourage the enforcement of the winning network topology, the system may, in an example, reward delivery of messages on the network which are compliant with the winning network topology. In another example, nodes that consequently refuse to comply with the winning network topology may be penalized or even excluded from the network.
In an example, especially in a case of a very large number of nodes in the network, it might be impractical for all nodes to maintain and optimise the routing solution for the whole network. In this case, the nodes can be divided into two groups: normal nodes and light nodes. Normal nodes may run an optimisation algorithm and take part in solution voting for the next block, whilst light nodes may just download the routing solution.
In another example, the routing protocol can be deployed over the underlying physical network itself to optimise internet connectivity. This can be solved by each routing node running a blockchain based protocol as described above.
The selection methods described herein allow the possibility of global state optimisation using heuristic algorithms. The voting mechanism improves routing efficiency and makes sure to avoid network fragmentation, round routing etc.
Thus, according to an example, a network routing topology can be optimised with blockchain.
The present inventions can be embodied in other specific apparatus and/or methods. The described embodiments are to be considered in all respects as illustrative and not restrictive. In particular, the scope of the invention is indicated by the appended claims rather than by the description and figures herein. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
| Number | Date | Country | Kind |
|---|---|---|---|
| 17306075.7 | Aug 2017 | EP | regional |
This application is the National Phase under 35 U.S.C. § 371 of PCT International Application No. PCT/EP2018/072010, which has an international filing date of Aug. 14, 2018, and which claims priority to European Patent Application No. 17306075.7, filed Aug. 17, 2017, the entire contents of each of which are incorporated herein by reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2018/072010 | 8/14/2018 | WO | 00 |
