Web3 is often touted as one of the runner-ups for solving many of the problems with the current Internet. However, like many technologies that are surrounded by the fluff of hype, the truth about what it actually is, does, and will do is shrouded behind layers of obscure visions, fundraising, and human-induced drama therein.
This article will provide a constructive look at what an actual web3 architecture looks like and how it can be actualized. Furthermore, it will be compared to “web2“, or the current web. This will mostly be from a development standpoint, which stands to answer the everlasting question:
What does “building on web3“ or “being a web3 developer“ even mean in a real context?
I am using the term web3, not because this is what the ‘final‘ version of the web will look like, but because it is a useful abstraction that is used to describe a multitude of different concepts.
As a precursor, web3 does not only comprise of blockchain; it represents a more fundamental change with the custodial control and representations of one’s digital presence. The traditional narrative goes as follows:
Web1, or the 1990s, enabled a read-only web. At the time, technologies such as hypertext markup language (HTML) were the innovations to watch out for. Quickly, the world evolved to a content-first internet - with useful, collaborative web apps becoming commonplace with the likes of Facebook, Google, and many others.
Beautiful UI and UX became the forefront of the internet - a place where suddenly, many people of infinitely many backgrounds were connected on a common ground. Best of all, these services were free of cost - enabling an extremely low barrier to entry. This is what became known as web2, where users could both consume and contribute content to the World Wide Web.
However, as the years would soon prove, it wasn’t all that free. When you sign up for any of these services, you are giving one thing: your data. Anything you post online is not actually yours but at the mercy of the service provider that you’re entrusting your digital presence with.
In other words, you don’t really own the digital representation of yourself. You are paying for UI and UX with your data!
As one can imagine, this also became a problem. Not only from a social aspect but also a computational aspect - with the epicenters of computing being held in the hands of a select few, who could refuse you access if they deemed it by their standards.
The aforementioned problem is rooted in one single concept - the architecture. At a high, non-technical level, all services work mostly the same way. Once you sign up, you are usually bound by the legal terms and conditions of that specific provider. You, the user, are subject to the service provider, which controls your access to a particular service.
It’s time to introduce a word that, to web3 folk, won’t be all that foreign: governance. Once you sign up, you are also under the jurisdiction of this particular service. This service can effectively do anything it likes with your digital presence. In a more technical sense, it is often that these services depend on other service providers, who themselves are centralized authorities.
Companies that provide computing in the form of infrastructure and servers are essentially providing the ‘raw material‘ for these services to run in the first place. If these companies are compromised in some fashion, there is a potential cascading effect that can affect many other services as well.
Needless to say, this presents a fundamental lack of architectural integrity within these systems. There are two primary factors that are missing from web2 architectures: resilience and robustness. Protocols that are robust, i.e., have inherent integrity, and that are resilient, can recover quickly and effectively, are needed in today’s digital world.
Web3 is effectively the backbone that rearranged the puzzle pieces of web2 into a more sovereign, user-oriented methodology. The notion of a governing service provider is cut out entirely, with the user in total control of their actions. The help of various technologies, such as public key cryptography, digital signatures, and other cryptographic primitives, form the basis of verifying someone’s right to access a particular service.
Notice I did not specifically highlight decentralization. Decentralization is important, yes, but it should not be the primary goal. A system that is too decentralized can present issues of its own.
There are new paradigms and technologies that are introduced, such as blockchains, emphasis on Byzantine fault tolerance, distributed systems, and the like, but these systems are here for one thing: to provide resilience.
Instead of being bound by the service provider’s whims, a user can simply prove through a combination of cryptographic primitives and trustless verification that they have the right to access a particular service.
As stated, the idea is to actually reduce the amount of trust in a service provider. This essentially means that you do not need to inherently trust them - you simply either do, or don’t have access to the service.
As before, we stated that compute is generated by a few large companies. In the Web3 paradigm, compute is generated trustlessly by a network of validators, who are constantly ensuring the state of a given network is in a good state.
Web3 systems (usually with blockchains as a foundation) are made up of a distributed network of nodes. These nodes are responsible for authoring, validating, and persisting data over a period of time. The result you get is computation, which you can trust.
Disclaimer: I am a technical educator at the Web3 Foundation, but it really is a fantastic web3 technology stack.
When we look for web3 systems to build on, it’s important to evaluate a slightly different set of criteria:
In many ways, these questions are also questions for “Web2“, as reliability for a given system is important in any context, i.e., for a Web2 solution, you may also ask if it is scalable, economical, and reliable.
There is still a way to go for both the developer and user experience for web3 as a whole. The paradigm is rooted in good faith, but execution is still in the works. This is a huge positive - there is a lot to work on and a lot of room for innovation. Tackling common problems, such as interoperability, authentication, DX, or UX all have many opportunities for one to swoop in with a unique solution.
This article was obviously very high level - I look forward to writing more technically oriented content in the future. If you ever want to chat, hit me up on X.
Stay safe!