3 ms·
I worked on Bitcoin in the early days, and developed decentralized software and protocols as part of that. I also did most of the design on an "enterprise block
by mike_hearn 3y ago
I worked on Bitcoin in the early days, and developed decentralized software and protocols as part of that. I also did most of the design on an "enterprise blockchain" system later which is basically (in my view) a peer to peer database run by competing 'frenemy' businesses, i.e. with mostly untrusted nodes. So I feel like I have a lot of practical experience in this domain.
The RFC is decent enough. It's moderate and reasonable, and cites Marlinspike's "ecosystem is moving" essay which is a very important piece of thinking in this space. I'm not a fan of the RFC's friendliness towards regulation. Governments often achieve the opposite of what they want when they try to regulate the internet, and they don't care about centralization at all or in fact prefer it because it makes it easier to engage in control when there are only a few big players vs thousands of smaller players (see how modern EU regulation is explicitly targeted only at "very large platforms" and ignores the rest).
But the RFC lacks specific suggestions. For engineers who want concrete and achievable ideas that can be worked on with minimal cost, here are a few I'd pick:
1. Support IPv6. Getting flat end-to-end routing working again is one of the lowest lift ways to improve decentralization on the modern internet, in both obvious ways (reducing CGNAT) and less obvious ways, for example it's conceivable that Android could be extended to support socket activation. That would allow apps to bypass push notification and centralized reflectors in some cases. I'm not sure how commercially strategic push services are to Apple and Google these days - it costs a lot of money and it was revealed recently that governments are wiretapping supposedly e2e encrypted messengers by grabbing the push messages. So whilst I doubt Apple would allow it, in theory someone could write a patch for Android to enable it and contribute it upstream.
2. Support confidential computing. A lot of centralization happens because we need a program to be run on a server somewhere to do something sensitive, which means we need to trust the server operators (cloud+admins). So we gravitate towards big brands that everyone can agree on, like AWS. Confidential computing lets client apps (phones, desktop apps, less easily also web apps) to verify the server they're connecting to is untampered with and running the expected software. It takes cloud and root out of the trust equation, meaning you can in theory do things like have a P2P network of anonymous operators who offer their services without needing horrifically complicated and ad-hoc app specific cryptography. The tech works today, but very few people are aware of it or use it, and it's not integrated well into our tech stacks. But it should be!
3. Write smartphone, tablet and desktop apps. Web apps are inherently very centralized. The name of the app is conflated with its hosting location, browsers practically force you to delegate most of the app's work to the server, and user data ends up tightly bound with the operator and implementation. You can't even do tricks like confidential compute with them really, because browsers don't understand the remote attestation protocols. If you write client-side apps you can dodge all those problems and loosen the bindings between user data location, software distribution location and compute location.
Still, you have to be realistic. After some years I realized that centralization happens because decentralization is in some sense like communism. If you take away ownership over private property then people lose the incentive to improve it. It becomes a commons and the usual tragedy follows. Centralized services are private property, and so the owners make sure they are well kept and improved. Also private property and profit is mentally grounding - projects that lack these things have a habit of going crazy and losing interest in what users actually want. These days I'm not quite so interested in pure open source p2p systems anymore because of that problem, but there's a lot of scope to find interesting corners where private property can be combined with more decentralized implementations. After all, Office 2000 was owned by Microsoft yet still much more decentralized in practice than Office 365.
- _heimdall 3y ago> After some years I realized that centralization happens because decentralization is in some sense like communism. If you take away ownership over private property then people lose the incentive to improve it. It becomes a commons and the usual tragedy follows. Its really interesting to me that this was one of your takeaways, I actually would have seen it the other way around but haven't worked in the space nearly as much as you have. The way I see it, centralization of the internet is the analog to communism and the argument for it would be that the internet and the services we use every day are so vital to daily life that one authority needs to own it to make sure everyone has access. In that view, decentralization would lead to things being poorly maintained and abused for selfish gain. Centralization (communism) would benevolently protect the common resources on everyone's behalf and make sure those resources are fairly made available to all. From that angle, centralization of the internet is likely to follow the same road as historic examples of communism. We would see corruption, censorship, and power/money being syphoned off to the few in charge. That sure does feel like the centralized internet we have today.
- mike_hearn 3y agoI was referring to theoretical communism, the one where there's no private property for real, where everything is communally managed. Perhaps anarchocommunism is a better term. Tragedy of the commons gets the issue across just as well. In practice communist countries were highly centralized, agreed. All property was the private property of the state. > benevolently protect the common resources on everyone's behalf A resource is too abstract a notion. The things we're talking about here are services which can adapt and improve. In his essay, Marlinspike was trying to communicate that you can't federate or decentralize because "the ecosystem is moving" i.e. your centralized competitors are innovating and you have to keep up with them or ideally even exceed them. Mere protection here isn't good enough, it requires active change that may upset some stakeholders. Collectivism fails here because of its totalizing nature: there's one of everything, which is theoretically at least communal property. But then you have to please everyone, so the only changes you can make are the ultra-low risk ones and because you often don't know the risk, in practice that means you're forced to simply clone what is observed to work elsewhere. So you end up permanently behind and with time it gets harder and harder to keep up. With competition that's less likely to happen, because there's an incentive to take risks and do things that may upset some existing users, if you think it'll please even more people who aren't your users today. This is a core tension that appears whenever people talk about decentralization. It's the way the Bitcoin community lost the plot as well. Some people interpret it to mean "one universal totalising system which is collectively owned". Other people interpret it as "an interoperable system of many competitors that can innovate and diverge from each other when needed".