Pillars of Bitcoin: Decentralization
Day 4: Rubin's Bitcoin Advent CalendarTweet
Many may have tried, but few have successfully characterized what “being decentralized” means in an objective / quantitative sense. Instead, we’re left with soft “know it when I see it”s.
Decentralization may be a pillar of Bitcoin with a lotta fanfare, but it’s still just a means to an end. It’s about the Pantheon, not the pillars! A system can be very decentralized and still kinda suck. Much like pillars with no roof won’t keep the rain out!
For a more than slightly contrived example, imagine a pre-internet driver navigating gas stations prices. Kind of “decentralized”, right? Users/purchasers operate on local information to see pricing and make a decent decision, and sellers operate on local information to stay competitive. Over time the network should “converge” a sellers learn who has better prices throughout town, but from the perspective of an individual purchaser it’s really hard for them to determine within their remaining tank range/willingness to drive across town for a dollar who has the best prices. So while the market works as a decentralized pricing system, it’s not highly consistent!
It’s Hard; No CAP
Computer network nerds have three rules for keeping their jobs: consistency, availability, and partition tolerance. What do these mean in practice? Thinking back to our gas analogy, gas stations are very available (you can always get gas at some price), they’re strongly partition tolerant (i.e., if you can’t see other gas station’s advertised prices you won’t know if it’s better, but you can still get gas). But the pricing might be all over the map! No consistency!
It’s really hard to achieve all three properties – there even exist proofs of its impossibility. Instead, engineers make tradeoffs to achieve different amounts of guarantee across the properties.
For Bitcoin we care a lot about consistency1. If I send money to Alice, I should not be able to send it to Bob. We also care a lot about partition tolerance. If some group of participants should shunt themselves out from others, the system should still operate? So do we inherently care less about availability? Well, kinda! If the “blockchain is closed” and you can’t transact, at least you still have your money. And technologies like Lightning Network can help bridge the gaps if the Bitcoin blockchain is unavailable that you can still fully confirm transactions as long as it comes back eventually.
So, interestingly, Availability seems like the property we need to care about the least… but it’s one of the main reasons we need decentralization! That’s because even though we might have a design that elevates the other two properties, it doesn’t mean that availability is unimportant. And availability is not one monolithic level, there are many different types of availability fault one might experience on a network. For example, you might experience reduced or no availability if:
- The network doesn’t have blockspace at your price
- The internet is down
- Your usual peers are offline
- Theres a fire at a major data center
- Your battery on your phone dies
- A big solar flare happens
- An evil government changes your DNS records to your mining pool and you don’t know the IP address
- An evil government runs the network entirely and doesn’t like your transactions so they get censored.
Some of these problems, decentralization can help us with! Some, decentralization can’t help with. And some are caused by decentralization. Uh oh!
A fire a major data center can be defrayed by being more decentralized – a fire can only spread so far! The other data centers should be fine, since Bitcoin is partition tolerant, the overall network is available.
If a big solar flare happens, there’s not much any of us can do if all the internet is down and our devices got fried. Too catastrophic… We can recover eventually, your metal seed plates will be fine, but hopefully someone had some Faraday cage shielded backups.
If blockspace is too expensive, decentralization may be the cause!
In order to keep the network decentralization friendly, Bitcoin uses far less bandwidth and storage than a centralized system (like Google) could use. This ensures that participants on the network need not be particularly well resourced or well connected to be a meaningful, full participant in the Bitcoin Network.
That’s because of another availability issue: censorship. Bitcoin fundamentally stands as a fuck-you to the entrenched powers that be. As such, Bitcoin uses decentralization to guarantee censorship-resistance against state actors. While there’s been much ink scaled about the censorship of scalability v.s. the censorship of state actors, Bitcoin is hyper focused on providing some form of “equal protection”.
Everyone hates that you lose availability from high tx prices, and all are equally affected2. Everyone hates solar flares, and all are equally affected. But with state actor censorship, enemies of the state, be they Jews, Conservative Non-Profits, Black Americans, Gazan Chocolatiers, People who believe things posted on *******’s Twitter Account etc, can be picked apart and subjected to selective abuses. If anyone can run a node (and hopefully miner), and most people don’t have a political agenda, we can maybe protect individuals of any background.
As such, Bitcoin’s decentralization is focused on censorship-resistance, even at the expense of on-chain availability.
The Neverending Story
The story doesn’t end there. Decentralization, as we noted earlier, is very tough to quantify. Even if we can’t quantify it, we can still reason about decentralization efficiency. Given the “costs of decentralization”, how much censorship resistance do we get? Can we decrease the costs and achieve the same amount? Can we keep the cost the same and gain more censorship resistance? Or… do we need to increase the costs, because we’re not censorship resistant enough? Stay tuned for future posts we’re we’ll see if we can’t do something about it!
If we’re being pedantic, technically Bitcoin sacrifices consistency for eventual consistency to preserve the other properties… but it really depends on what you view the “output” of the network being as you can detect consistency losses by seeing hashrate decreases, for example. My opinion is we sacrifice availability of high quality confirmations for consistency… ↩
There is a complex interaction between scalability solutions and chain space that can help bridge the fact that rich people are typically in power and poorer people aren’t. ↩