doitian
commented
1 month ago For privacy, it's still hard to hide the channel balances:
- Jordi Herrera-Joancomart´ı, Guillermo Navarro- Arribas, Alejandro Ranchal Pedrosa, Cristina P´erez-Sol`a, and Joaqu´ın Garc´ıa-Alfaro. On the difficulty of hiding the balance of lightning network channels. In Steven D. Galbraith, Giovanni Russello, Willy Susilo, Dieter Gollmann, Engin Kirda, and Zhenkai Liang, editors, Proceedings of the 2019 ACM Asia Conference on Computer and Communications Se-curity, AsiaCCS 2019, Auckland, New Zealand, July 09-12, 2019, pages 602–612. ACM, 2019.
- Sergei Tikhomirov, Ren´e Pickhardt, Alex Biryukov, and Mariusz Nowostawski. Probing channel balances in the lightning network. CoRR, abs/2004.00333, 2020.
contrun
One widely-known problem of lightning network path-finding with uncertain channel balances. Some paths may not have enough balances in order to transfer a certain amount of assets to another person. We may have to attempt multiple trial-and-errors before we finally find an appropriate path. The peer message specification of lightning network does not include any way to broadcast channel balance in order to facilitate path-finding. The reason as stated in Mastering Lightning Network is that
The privacy part is obvious, but can we somewhat quantify the impact of broadcasting the channel balance on network scalability?
I am currently sifting through the lightning-dev mail list. There are a couple of helpful discussions there. I hope a few pointers to these discussions will be helpful, even if I haven't fully understand their implications. Just note this is not a comprehensive overview of the literature (not even a good overview of what are discussed on lightning-dev).
Nodes Having Full Knowledge of the Whole Network
Full broadcasting/syncing
Lightning network is partly due to the fact that lightning network is flood gossip to disseminate channel information, which is grossly inefficient. In the current implementation of lightning network. All nodes should have all the knowledge of all the channels in the network. Lightning network uses gossip messages to disseminate all these information, which means that broadcasting all the channel balances are impractical to lightning network.
Let's do a simple napkin math (like this one of lightning network). Say we need to support 1 million transactions over fiber network per day. The average path length for a fiber network transaction is 5, and we need to amplify the number of message transmission in gossip flooding by a factor of 4. The we have 20 millions message per day, with the size of approximately 300 bytes (channel balance update should have a few signatures and some metadata of the channel). In other words, if all nodes is going to have all the channel information, then each node has to process 1,000,000 5 4 * 300 bytes = 6GB of data per day. This is clearly un-scalable.
Selective broadcasting/syncing
Since the conclusion above is that not all nodes should have not all the channel balance information of the network, we have to selectively broadcasting/syncing channel balance information. That is, we have a few options.
For the first option, I suspect that all the liquidity provider will always broadcast all the balance information of their channels, since this will make their chance of being selected as a intermediate node in payment path-finding higher (and thus earning more income). If this is the case, I further suspect as long as a node can choose to broadcast balance information, the whole network will be flooded. This is a corollary of my conjecture that liquidity providers are involved in most fiber network transaction and they are incentivized to broadcast all balance updates (thus flood the network). So we have to implement some rate-limiting techniques.
The last options will be explained in the following sections.
Nodes Having Partial Knowledge of the Whole Network
The problem summarized in [Lightning-dev] Every node must be aware of all other nodes - scalability problem? is
And Christian Decker's response to this is
So the problem now is that can we have an incomplete view into the network while keep fiber network working efficiently?
Beacons (TODO: the description here may be inaccurate, I haven't fully grokked how beacons work)
One natural thing to do is to categorize the network nodes into full and light ones. For the nodes that have the power and wiliness to participate in channel balance information dissemination, they can choose to become the "beacons" of the network. This seems to be introduced in [Lightning-dev] Ionization Protocol: Flood Routing, where Rusty Russell wrote
DHT
Another way to alleviate the problem is that instead of having all the information upfront, we try look up channel balances on the fly. One notable way to query over vastly distributed nodes for some information is DHT. We can save the channel balances and network graph to DHT, but I suspect that the latency is too bad for time-sensitive applications like payment (we have to make a few rounds of queries even to obtain the accurate balance of a single channel. Though, we don't have to be astronomically accurate about these number).
Literature
I compiled the emails relevant to this problem here. Some methods do not clearly belong to the DHT/beacon categories.
Scalability under Uncertain Channel Balance
This is what lightning network is doing now. As mentioned above, lightning network nodes have complete information about the public network topology (an directed graph with nodes being vortexes and connected by established channels). In order to make a payment between two nodes, we have to find a path connecting them. Currently major lightning network implementations use Dijkstra's algorithm to find k shortest paths and try them one by one to see if the payment is successfully placed. The smart part of these implementations is that they use some good weight function (to approximate the probability of a success HTLC transfer). For example, rust-lightning uses ProbabilisticScorer to "score" the channel while finding a payment path. A higher score represent a higher probability of the HTLC payment is successfully accepted.
References