How To Optimize Lightning Node Centrality

In the post, we evaluate the results of an international team of researchers who recently published preprint “Short Paper: A Centrality Analysis of the Lightning Network” for the 26th conference Financial Cryptography and Data Security 2022. The authors researched the degree of decentralization of the Lightning Network via calculation of the betweenness-centrality distribution.

The major conclusion of the paper:

We find that although the network is generally fairly decentralized, a small number of nodes can attract a significant fraction of the transactions, introducing skew. Furthermore, our analysis suggests that over the last two years, the centrality has increased significantly, e.g., the inequality (measured by the Gini index) has increased by more than 10%.

The latest snapshot of the Lightning Network graph considered in the paper dates to January 1, 2021. We demonstrate how to apply developed code to the relatively fresh dataset and how to find a better candidate for your personal node.

Reproducing Results Is Easy

There is an open repository with some already uploaded datasets. The authors used these data for their publication. They introduced TimeMachine as a cornerstone of their research method. The TimeMachine replays gossip messages from a snapshot and reconstructs the state of the network to a particular selected date.

The TimeMachine is a part of lntopo library available in a separate repository. There are also published links on archives containing snapshots up until a particular date. The only nuance to the moment of publication of this post is in the fact that one must unpack the dataset using some archiver and not use provided read_dataset function.

python -m lntopo timemachine restore --fmt=graphml gossip-20210908.gsp 1578582389

The latest published gossip snapshot is dated by September 9 2021. For the plots below we have employed fresher data provided by Vincenzo Palazzo from his CLightning node. Look at his project on Kotlin which aims to research LN graph.

On the figures below we have rebuilt all plots from the original publication with the dataset from 3rd December 2021 and combined it with the latest dataset from paper with timestamp T7=1609498800=01 Jan. 2021. Between January and December, Lightning Network exploded which even may be viewed as a contribution to increased Bitcoin market capitalization (see Value of Layer 2, however it is rather a speculative way of thinking). Plots indicate that the same total accumulated betweenness-centrality metric is represented by less percentile of nodes in December than in January. The GINI coefficient adds to them with increased value by 0.2%.

Optimizing For Betweenness-Centrality

Despite the explosive growth of the network in 2021, an average node operator still can do some calculations on the network graph for improving node position. It may increase chances for getting higher liquidity flow and higher cumulative fees with reasonable fee policies. Let’s look at the tools allowing us to do that.

First of all, the user should reject networkx library for this task. We suggest installing networkit since it implements an important algorithm for dynamic Betweenness-Centrality re-evaluation and generally computes metrics faster than networkx. The disadvantage of networkit is that it doesn’t store graph metadata. So one should apply additional efforts for identifying nodes by its integer numbers in networkit graphs.

After installing the required library, clone this gist and check if binary file gossip-03–12–21-json.networkit presents in the directory.

By running the Python script and this file you can test if optimization works.

python optimization-fees.py

Should load graph in networkit binary format.

graph loaded 16942 nodes, 137330 edges (channels).

This graph was built for smaller transaction size 0.0001 BTC or 1000 sat so it must be taken into account when selecting corresponding wedge weight iW. Transaction size plays an important role in interpreting results of centrality analysis and may be important for optimization as well. We haven’t researched this detail yet but we suggest that this parameter may also represent the fee policy of the node being optimized.

Why it may be important to optimize particular node centrality when opening a new channel? It should allow better selecting of the next best peer. As authors of “Short Paper: A Centrality Analysis of the Lightning Network” state:

Nodes with high betweenness centrality have a considerable amount of influence on a network by means of information control, since most of the network traffic will pass through them — in contrast to other centrality measures which represent a more local view, e.g., degree centrality, which counts the numbers of edges incident to a node.

Let’s look at the code in the context of this work. To ease the optimization task we can filter potential neighbouring nodes (those with whom we want to open a new channel).

ranks = bc_original.ranking()
nodes = [n for n, b in ranks if b > minBetweenness]
filtered = [ n for n in nodes if G.degree(n) >= minPeers]

With the calculated betweenness — centrality metric it can be easily demonstrated that a large amount of nodes have 0 value so they are leaf nodes of the graph or simply dead ends. Although connecting to such nodes may increase network decentralization in a sense of some metric values they are unlikely to provide any meaningful liquidity flow. In January 2021 researchers reported about 5520 leaf nodes out of 6630.

An additional constraint by the number of neighbouring peers may be useful for a directed fee-weighted graph that doesn’t store node capacities (remember, networkit graph has no metadata). Application of simple filter excluding leaf nodes and those with less than 7 channels obtains 2312 out of 16942 nodes for 03 December 2021 graph against 764 nodes for 01 January 2021 network snapshot. Our experience is that it is possible to iterate over approximately 2000 newly added channels using the special DynBetweennessOneNode function of networkit library.

The resulting plot clearly demonstrates some nodes to select for the next channel opening. Additional heuristics may apply like limiting candidates by the amount of already opened channels because the peer may be already overloaded.

Conclusion & Further Research

We published this simple guide for the benefit of the whole network. It is simple: all participants may benefit from a more resilient, more decentralized Lightning Network. The authors of the Centrality analysis paper stress that the increased betweenness-centrality metric may implicitly protect LN from discovered attack vectors. We did pretty simple research and it can be easily extended. Let’s consider some other opportunities for node network position optimization.

Positioning Strategically

One can build an undirected weighted network graph with channel capacities. The benefits of this approach are such that it will have twice as much fewer edges and the graph itself will demand less frequent updates. Positioning the node using this information implies longer-term horizons.

Easing Liquidity Crunch

Channel fees in Lightning Network are very dynamic. Thus directed fee-weighted graph demands constant updates to deliver important information. In our post, we gave it up for technical feasibility and illustrative purpose. However, on the contrary to long-term node positioning with an unweighted graph, we could propose using a fee-weighed directed graph specifically for easing the potential liquidity crunch of a specific node. In this case, other optimization parameters other than just maximization of betweenness-centrality may apply.

Support Us

If you just want to get some directions from Centrality analysis use @CentralityBot in Telegram. For 2000 sats it will provide top 10 nodes out of more than 500 (those having more that 10 and less than 100 channels) which increase centrality of your node specifically.

Like Standard Sats project.

Or just send some sats via LNURL. Thank you!