[Part 3: How] Understanding Web 3  -  A User Controlled Internet

by Emre Tekisalp

In Part 1, we reviewed how today’s internet is a state-less internet — its participants can’t hold their own state, nor transfer it from one to another, natively. Blockchains, starting with Bitcoin, gave us a way to have a stateful web of computers. Those of us in the crypto and blockchain ecosystem have started to call this new internet as Web 3, which we reviewed in Part 2.

Web 3 adds a whole new infrastructure layer for applications to interact with, as well as new client functionalities and requirements. The users also need to learn new UX concepts to be able to use these applications. As such, the architecture of Web 3 applications introduce additional elements to the current Web 2.0 framework, as well as new building blocks and tools for a developer to get familiar with.

Architecture of a Web 2.0 application vs that of a Web 3.0 application

Web 2.0 vs Web 3.0 Architecture

A simplistic version of today’s Web 2.0 architecture includes a client software, usually a browser or a self-contained application, and a suite of servers providing content and logic, which are all controlled by the same entity — let’s call it Game Co. In this model, Game Co. has sole control over who may access its servers’ contents and logic, as well as the track record of which users own what and how long that content is kept live. There are many examples in the pages of technology history of how internet companies have changed the rules on their users or stopped their service, with users having no power to preserve the value they’ve created.

Web 3.0 architecture leverages what’s enabled by a universal State Layer. It does this by allowing two things:

  1. Allowing applications to place some or all of their content and logic on to a public blockchain. Contrary to standard Web 2.0, this content and logic can become public and accessible by anyone.
  2. Allowing users to exert direct control over this content and logic. Unlike Web 2.0, users don’t necessarily need accounts or privileged API keys to interact with what’s on the blockchain.

Web 3 applications enable this with the help of two key infrastructure pieces:

  • Wallets: Beyond just being the User Control Layer for the Web 3 stack, modern wallets, such as Coinbase Wallet, interact with the main client front-end to allow a seamless user experience. They do this by allowing applications to send requests to the wallet itself using standard libraries,web3.js being the most popular of these. A sample web3.js call can be a payment request, asking the user to confirm that the wallet can send a specified amount of funds to the application’s address. When the user accepts, two things happen: 1) the wallet lets the application front-end know with a response, so it can present a “Payment Submitted” screen, 2) the wallet makves an RPC call to the blockchain server to submit the approved transaction to the blockchain. This is where the second infrastructure piece comes into play.
  • Blockchain Node: There are two types of agents that constantly monitor and engage with a blockchain — miners and nodes. Miners directly maintain and run the blockchain, whereas, nodes monitor and submit transactions to the blockchain. One can think of them analogous to ISPs versus cloud services providers (e.g. AWS). Similar to how most applications today use AWS’s services to run their application backends, blockchain node providers, such as Infura, do the same with blockchain nodes. When a wallet wants to submit a transaction to the blockchain, or query state information from the blockchain, it makes a call to the node provider. Applications’ app servers can also interact with the node providers themselves, to keep the app’s logic up to date, by making similar RPC calls.

What Do Developers Need To Know?

Tools & Frameworks

Knowing what tools and frameworks to use and being proficient with them is a considerable portion of any developer’s life. Although the Web 3 space is still in its early days, we’re starting to have usable tools that enable developers to get to an MVP stage and iterate faster and faster. This is most visible on Ethereum where, thanks to the work of many in the community, developers are starting to flock in increasing numbers.

Credit for chart: Stefano Bernardi; Source of data: Github

Although I won’t go through the tools available in detail, it’s helpful to know which ones are at developers’ disposal. The list below is by no means comprehensive (in fact, there is such a list here), but includes tools new developers should start with.

Design Choices

What to decentralize: This is a new and key choice. Most early developers have targeted to decentralize the maximum amount possible and put everything on the blockchain. Given the slow and expensive nature of present day blockchains however, this is not possible to do at scale. CryptoKitties was perhaps the first DApps that tried to keep certain portions centralized. For example, their breeding logic is not public. Although they have received some criticism for this, it hasn’t stopped users from spending a significant amount of money to purchase cats bred by this logic. Gods Unchained is another example where the game itself will be hosted on a standard cloud infrastructure, but ownership of assets will be tracked on the State Layer.

Although many DApps will take different approaches on decentralization, a first principles way of approaching this choice would be to adopt a “minimally viable public state” approach. If you are building a game where users can own assets, then ownership should be on the blockchain. If you are building a prediction market, then the reporting and pay out of your market should be on the blockchain. At the end of the day, users will find your application valuable if they can claim true ownership over the key activities your application enables.

Web app vs native app: This is a choice that’s decades old, yet takes on new form with Web 3 applications. Most DApps today are web apps because of two simple reasons: a) it doesn’t require the user to download a new app every time, b) users can use your app without having to create a new wallet every time. The small number of native DApps that exist all lead the user to create a new wallet, which is not the ideal user experience. It’s easy to see how this is not a feasible future, as users will not maintain keys for hundreds of wallets.There will, in the near future, be more seamless ways of enabling native apps to go past this UX challenge, but for now, web apps allow a much easier onboarding experience.

Desktop vs mobile: The Web 3 version of this choice isn’t about choosing between one or the other, but about how users end up using your DApp on both. On desktop, a Chrome extension like MetaMask has been how most users have interacted with DApps. Although it requires the user to download a new extension, the user is still interacting with a browser interface they are familiar with.

On mobile however, extensions are not possible, at least on iOS. That’s why wallet apps, such as Coinbase Wallet, place browsers inside their apps. Once in the browser view, the DApp experience is the same as on desktop. There also are several technical nuances to be aware of when developing for mobile, which Coinbase Wallet’s Head of Engineering Pete Kim covers here.

Other challenges with no solutions to date:

  • Who pays for gas: Every DApp built on Ethereum today makes its users pay the cost of transactions, called gas for the Ethereum blockchain. This won’t be feasible over the long term if millions of non-crypto-native people are to use Web 3 applications. There are a number of theoretical solutions, some which are closer to being practical, such as gas relayers, however none are functional yet.
  • App-specific accounts or not: One of the exciting applications of Web 3 is universal identity. Since there aren’t many functional identity solutions today, some DApps are still asking users to create an account, enabling some identity to be associated with their activity on the app. This is not too different than the Web 2.0 way of doing things. Once we have functional decentralized identity solutions, how should DApps treat and present this?Although there’s no clear answer, some are already presenting proposals, such Origin’s demo built using ERC-725 and 735.

Summary

In Part 3, I aimed to summarize the modifications Web 3 brings to the architecture of applications and what developers should know when starting to build Web 3 apps. A great resource for beginners is Cryptozombies, which is a fun workshop teaching anyone how to create their first Web 3 app.

Although the way to build Web 3 apps will change in many ways as the infrastructure around it evolves, what’s key is that apps are being built today. It’s the wild west of the web as we know it and a lot of really smart teams are starting to tackle the challenges and opportunities made available.

This concludes our three part post on Understanding Web 3 — A User Controlled Internet. Here at Coinbase, we are building products to support an Open Financial System, and we see Web 3 as the way developers all around the world will build the products and businesses that make this vision a reality. If you want to join us and the rest of the ecosystem by building your own Web 3 application, make sure to check out Coinbase Wallet to get access to the many users who are already using DApps! We’re also hiring for many different roles and investing in the companies that will build the decentralized web with us.

Thanks to Linda Xie, Josh Stark, Tony Sheng, Sid Coelho-Prabhu, Jacob Horne and Daniel Harrison for feedback.

Unless otherwise indicated, all images provided herein are by Coinbase.