Sources of Centralization on Lightning (and why they matter)
A couple of recent reports have questioned Lightning’s vulnerability, and both are related to its network structure. One claims that an emerging form of centralization could make it vulnerable to “split attacks”. The other sees hubs as targets for “congestion attacks”.
Centralization was also a hot topic in 2019, in 2018, in 2017, and even in 2016.
It’s true that many forces militate against decentralization: economies of scale, convenience, brand recognition, etc. But Bitcoin and Lightning are designed to overcome them. Centralization leads to vulnerabilities, power imbalances, censorship … fiat. But that’s the past. We’re more interested in the future — how to build a strong, free, and useful network for bitcoin payments. To reach that goal, we need to keep Lightning decentralized. Here’s why (and how!).
What is (de)centralization?
Of the dozens of ways to conceptualize the (de)centralization of a network, the most important is also the simplest: degree centrality. Degree centrality measures how connections are distributed across nodes in a network. If one node is connected to all the others, but none of them is connected to each other, we have a star graph with maximal degree centrality. If each node is connected to every other node, we have a beautiful jumble with minimal degree centrality.
Another way of thinking about this is to count the number of hubs. One hub for all = maximally centralized. Many hubs connected to each other, with each connected to many nodes = moderately (de)centralized. If each node is connected to every other, then every node is a hub, which means that none of them are really hubs = maximal decentralization.
Why does decentralization even matter?
Never change a running system, right? Fiat (generally) works. Custodial services (generally) work. Bitcoin works. If it’s the function that matters, why should anybody care about the form?
Beyond basic functionality, the form of a network like Lightning matters for three reasons: robustness/resilience, censorship, and power.
Robustness/Resilience
Being able to resist failure is robustness. Being able to recuperate from failure is resilience. Robustness and resilience are necessary for the utility of the network, for uptime. Even if we minimize the trust users and hubs must have in each other, they still need to trust in the network. Unless everyone on the network is reasonably confident that it will resist attacks and recover quickly from inevitable failures, they won’t use it.
A network built around few hubs is more dependent on the stability of each one, and the loss of any one will be harder to compensate. As degree centrality increases, robustness and resilience decrease.
A more pressing issue for Lightning is currently liquidity centrality. At the moment, 10% of the nodes on Lightning control 80% of the liquidity. However many connections they may have, these nodes are liquidity hubs. If one of them fails — whether due to an unforeseen technical flaw or an attack — “these routing nodes would nodes would leave gaping holes”. Not surprisingly, a network with gaping holes does not inspire confidence.
Decentralizing the network reduces the impact — and incentive — of attacking any given node, making it more robust. Decentralization also shrinks the “holes” left by any successful attack, making it more resilient.
Censorship
Censorship always pertains to communication, and communication always occurs in networks (even if you’re just talking to yourself). And the feasibility of censorship depends on the form of the network. Censoring a few national newspapers or broadcasters is pretty easy. Censoring a more distributed network, like the internet, will require a (not so) Great Firewall. Private conversations occur in a distributed network, so censors would need either a vast network of spies or a widespread atmosphere of fear (usually both).
In other words, choke points facilitate censorship by making it more economical. In the case of Lightning, hubs that concentrate traffic and liquidity are choke points. They allow censors to monitor, regulate, and restrict many transactions with only few interventions.
Of course, censorship on Lightning doesn’t consist of bugged telephone conversations and redacted documents. In fact, we’ve gotten used to it. We’ve even learned its disarming acronym: KYC. Whatever its merits, KYC is censorship. KYC regulations determine who can access bitcoin, how much, and under what circumstances.
Under snappy titles, like “DIRECTIVE (EU) 2018/843 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 30 May 2018 amending Directive (EU) 2015/849 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing, and amending Directives 2009/138/EC and 2013/36/EU”, regulators write such things as:
competent authorities should be able, through obliged entities, to monitor the use of virtual currencies.
… by which they mean that they want to squeeze exchanges and custodial operators for information on their users. It gets better:
Financial Intelligence Units (FIUs) should be able to obtain information allowing them to associate virtual currency addresses to the identity of the owner of virtual currency. In addition, the possibility to allow users to self-declare to designated authorities on a voluntary basis should be further assessed.
An informal, decentralized network of intelligence services to monitor financial transactions. How could anyone construe that as censorship? 😬 (Everybody act normal!) If you have nothing to hide, you have nothing to fear, right?
And it’s obvious why the regulators are focusing on custodial services and exchanges: they’re choke points. If the censors are using a “decentralized” network, shouldn’t we? A decentralized network might not make censorship impossible, but it would make it much more difficult, expensive, and aggravating for the censors.
Don’t forget to relish life’s small victories.
Power
Centrality generates the power to make and change the rules that people were already planning and betting on. Centralized hubs can dictate terms to their users, and regulators can leverage hubs’ centrality to enforce arbitrary rules. This is the power to control who can use the network and when. It’s the power to put innovative people out of business and nullify the value of their hard work.
But government authorities aren’t the only ones exercising power. As long as Lightning requires significant technical expertise to use properly, there will be a power imbalance between the experts and novices. Incoming users will have to trust experts to protect their interests and maybe even to guard their bitcoin. The higher the barriers to entry, the more knowledge becomes centralized, and the more Lightning will be a tool by and for the cognoscenti. Here, decentralization means making the network easy to understand and use, arming users with knowledge, and liberating them from trust.
Counterintuitively, weakness can also be power. Wait — power through weakness? It sounds counterintuitive, maybe even paradoxical. But it’s the same paradox behind “too big to fail.” When banks — hubs of the monetary system — fail, the consequence is that everyone has to give them more money in exchange for no equity. Heads they win; tails you lose. And it’s not because the banks were strong. They were all too weak, but they occupied a central position in the network.
To the extent that Lightning becomes more centralized, we can expect its central hubs to follow the same path as fiat banks. This includes fractional reserve banking, inflation, depreciation, and so on.
Centralized power corrupts. Decentralized power emancipates.
What drives centralization on the Lightning Network?
Bitcoin and Lightning were both designed to be decentralized. Nakamoto’s whitepaper calls Bitcoin “A Peer-to-Peer Electronic Cash System” right in the title, and the Lightning whitepaper was about finding a way “to encompass all transactions in a way that doesn’t sacrifice the decentralization and security that [Bitcoin] provides”.
So if centralization is a bad thing, and both the on-chain and off-chain networks are designed to avoid it, where does it come from?
Custodial services
Custodial services severely concentrate the network. This tendency holds regardless of how many users they may have and however many they might onboard per month. From the network’s perspective, all the users of a custodial service are collapsed into a single user: the custodian’s node.
By bundling users into few nodes, custodians create choke points, decreasing the network’s robustness and facilitating censorship. Recent events have provided an apt example. The CEO of a custodial Lightning service was recently indicted for reasons barely related to his Lightning operation. Investigators seized the firms’ funds. But since the firm held its users’ funds in custody, users’ satoshis were confiscated too.
No, this would never happen to the customers of a fiat bank. It would cause a panic. And no, it isn’t fair. But if we keep the network decentralized and avoid the creation of chokepoints, we don’t have to care. As far as censors and regulators are concerned, a centralized network is an animal to be tamed, but a decentralized, P2P network is a force of nature, an asteroid coming to make them extinct.
The typical justification for the individual risk and structural vulnerability caused by custodial services is a supposedly better UX. But if non-custodial services can provide a “seamless and hassle-free” UX, then it’s a hollow argument.
Taking a beautiful, functional, open, decentralized network and using it to reverse engineer the centralized, hierarchical, exclusionary system it was actually meant to replace is simply tragic.
Services providing incoming liquidity
Above I mentioned that liquidity centrality — the concentration of liquidity around relatively few nodes in the network — is also a problem, and perhaps an even bigger problem at the moment than degree centrality.
Even in a network of relatively decentralized connections, liquidity could be concentrated around a small number of nodes: low degree centrality but high liquidity centrality. Those nodes would constitute choke points because the network as a whole would suffer disproportionately from an attack or crash at those locations. How funds are distributed among nodes can be just as important as how connections are distributed.
One factor driving the centralization of liquidity is the practice of Lightning nodes providing users with incoming liquidity. Several Lightning nodes and services do this. Breez, Phoenix, LNBIG, and Bitrefill’s Turbo Thor do so at no charge or for a relatively small fee. The reason they do so is to foster onboarding. Lightning needs users, users need to be able to send and receive funds, so it’s important to let them do both.
Of course, this post demonstrates that we’re aware of the risk. Breez doesn’t lock its users to the Breez node. Advanced users can open multiple channels to the nodes of their choice via the Developers menu. We want to make it simpler, of course, and we’re actively working to expand the range of third-party LSPs that our users can connect to. We’re also going to support LNURL-channel in our next update to allow users to easily connect to other nodes.
We envision a free, competitive market of liquidity providers. In a vast, thriving pool of liquidity providers, users can choose the provider that suits their needs, and the network maintains its decentralized structure. It’s effective, efficient, and everybody wins.
Proprietary nodes
By running their own protocol, proprietary nodes offer functions and capabilities that are not defined in the standard Lightning protocol. Yes, they connect clients/users to the rest of the Lightning Network just like any other node, but they force users to connect to the proprietary service’s own hub.
Relative to custodial services, proprietary nodes offer a major advantage: they’re non-custodial. Users keep their keys and remain individuals, without becoming aggregated into a big lump of undifferentiated userdom. This helps to secure users against having their funds lost, confiscated, or embezzled. That’s good.
Here’s how a network built around a proprietary hub looks:
This network has more vertices (i.e. connections) than the one above, but recall degree centrality. All the proprietary client nodes here are connected to a single proprietary hub node. It’s a star graph, which means maximal degree centrality. It has one massive choke point. As a result, proprietary nodes could be even more susceptible to failure and censorship. That’s bad.
Those who operate proprietary nodes typically justify their proprietary model with reference to the UX. (Notice a pattern?) But the functional, standard Lightning protocol gets by with less trust and more privacy. Again, making users easier targets for censors in a less robust network does not improve their experience.
The right time to choose decentralization is always
We don’t have to invent the right network structure, one that is censorship-resistant, that minimizes trust, and that is truly decentralized. That network already exists. It’s the non-custodial, open, second-layer Lightning Network working on top of the non-custodial, open, first-layer Bitcoin network. Robust, decentralized, and beautiful. It looks like this:
Everybody is connected to everybody else one way or another … or another … or another. It’s a more efficient, more practicable, and thoroughly adequate solution. But we have to choose it now and keep choosing it every day. We already have the technology. We just have to do the right thing by developing it wisely.
Decentralization is the onus of freedom
Do we want to be empowered, sovereign, peers in a robust, free network, or will we become prey to faceless authorities and their arbitrary rules, who demand our trust and give us … what exactly?
In order to keep the network free and the users empowered, we need smaller hubs and many more of them. We need a decentralized network, a network resistant to collapse, censorship, and power imbalances.
The network is young. We still have the ability to choose, and what we choose will shape the course of history. What will it be?
