E2ED: End-to-end decentralization (Part I)
Motivation and background
All signs are pointing in two directions: 1) Web3 is the future; and 2) Web3 has failed completely. I am not entirely joking. On one hand, traditional financial and governance structures are crumbling, hence we look towards decentralized engineering for at least some semblance of a potential solution. On the other hand, Web3 as it stands today has failed to deliver on virtually any of its promises to create equitable, accessible alternatives. Aside from a handful of successful (lucky?) speculators and investors dumping on clueless retail, most other Web3 users experience an exhausting barrage of complexity, security risks, rug pulls, tax hells, and horrible user experience.
Ideological positions inherited from the early Bitcoin communities are largely limiting the builders to consider only one aspect of decentralization — the permissionless financial ecosystems, a.k.a. blockchains. All other infrastructure that should become decentralized isn’t. This includes a variety of data services, peer-to-peer non-blockchain systems, name services, identity, code repositories, and front-ends.
The financial incentives of issuing and controlling your own token dictates what people focus on and what gets funded. This means that the infrastructure crucially important to the safety of the users, and to their actual ability to use decentralized software never gets built. Or, worse yet, something gets built, but the need to manage a token (supply, issuance, trading) distracts the team to such an extent that the product never delivers any useful service.
The result: Web3 ecosystem is centralized in the worst possible way, as aptly discussed in Moxie Marlinspike’s not-so-recent article. But the problem is not only the lack of good tools to build decentralization into infrastructure services, such as Infura and OpenSea APIs. The problem is also that decentralization is such a powerful tool, that it gives bad actors an unprecedented ability to do bad things, such as trade abusive content, carry out blatant rug pulls, and launder proceeds of criminal activities.
No sane society would stand by and allow the unfettered proliferation of bad actors, and so the regulators (and, consequently, all service providers subordinate to them) will predictably throw out the baby with the bathwater by indiscriminately attacking decentralized systems, which is what we see in this stunning article by the decentralization OG David Vorick. This comes up even in the today’s announcement of the US Treasury adding a large number of wallets (including the Gitcoin grant address!) to the list of sanctioned actors.
This is very unfortunate, but whether you agree or not, the need to control users’ activities in decentralized systems leads to the real need to keep portions of the Web3 ecosystems centralized. Because of regulatory activities, policing becomes a requirement and not an option for many service providers. Sadly, we don’t currently have any tools that would enable such control in the decentralized context.
The problem is this: we have some tools to build decentralized software, and these tools largely lead to the creation of the most radically decentralized software possible. To compensate for the high degree of censorship resistance, which eliminates any possibility of introducing necessary controls, we have to ensure centralization of other services, such as UI access points, data services, KYC, and so on. Such services are then built in a fully centralized way, often using Web2 technology, which defeats the purpose of decentralization entirely, if you ask me (or any sane person).
E2ED — end-to-end decentralization — is the concept that adapts to this state of affairs and proposes a solution. At the high level, E2ED aims to achieve two important philosophical goals. First, we must bring decentralization to all parts of the Web3 development stack, not just the financial network (a.k.a. blockchain), but also data services, UI servers, peer-to-peer application nodes, name services, identity services, codebase management, and so on. Second, we must enable soft decentralization, a methodology of maintaining sufficient control to eliminate bad actors while preserving the essential benefits of decentralization, such as interoperability, privacy, accessibility, and permissionless innovation.
This last requirement might seem impossible to achieve. After all, how can you call something “permissionless” while also policing it? But the truth is much more nuanced than this black-and-white (and false) assumption. For example, privacy can be meaningfully combined with regulation, as discussed in this visionary article by two of the US regulators. In brief, they are advocating for adoption of new technologies, such as zero-knowledge proofs, which would enable enforcement of KYC/AML laws without breaking privacy. This is just one example of combining effective control with useful decentralization.
The software solution that I have now spent 2 years building is called The ADAPT Framework. ADAPT is an acronym that stands for A Decentralized Application Programming Toolkit. ADAPT is my attempt to support E2ED philosophy. In this series of articles I will talk about the philosophy behind ADAPT and how it both simplifies the Web3 software stack; removes needless dependance on outdated Web2 approaches, such as REST APIs; and enables decentralization while also introducing meaningful mechanics to mitigate the bad actor problem.
Decentralization does not just refer to blockchains. Non-blockchain decentralized systems can exist both outside the blockchain space entirely, and also as critical parts of the blockchain-related software stack. It is this broadening of the view on decentralization that enables ADAPT to underlie E2ED. So, next up, let’s update our thinking on decentralization, explain the broader landscape of decentralized systems, and start translating these insights into engineering requirements at the foundation of the ADAPT Framework.
(Please read the second post here)
