lightning-dev

Testing a Flare-like routing implementation on 2500 AWS nodes

Testing a Flare-like routing implementation on 2500 AWS nodes

Original Postby Fabrice Drouin

Posted on: September 20, 2016 13:07 UTC

The Lightning Network is a proposed solution to address the scalability issue of Bitcoin.

It enables multiple transactions to be executed off-chain before being broadcasted to the main blockchain, thus reducing the load on the network and increasing transaction speed. The Lightning Network proposes a routing protocol that combines local neighborhood maps and paths to remote beacons.Flare is a routing protocol for the Lightning Network that has been implemented in Eclair with some differences between the implementation and the original paper. In the paper, it was assumed that any two nodes in LN could communicate with each other, but in the implementation, inter-nodes communication only occurs on existing open channels. The neighbor discovery/beacons selection is similar to what's in the paper, but simplified. The focus was on static ranking, finding a route formed of open channels between two given nodes. However, the route selection has been simplified. The team tested the algorithm using a LAN setup with static routes, which may not be representative of a real-world scenario.They found that the modified version of Flare worked on a decent-sized network, but noted several caveats, including poor routing table reconciliation and beacon distances that may not accurately reflect real-world conditions. It is possible that a route is not actually usable because the channels are not balanced. The route selection simplification means that the time allowed to find a route is short and predictable, but it is very suboptimal in terms of probability of finding a route. Results for different test nodes are provided, along with network size, beacon distances, route lengths, and response times. The team concludes that the graph is directed and one-way channels may make finding routes difficult at bootstrapping.