Coinbase's In-Depth Analysis of the Rise of Web 3.0 Era

Original Title: "Understanding Web3 --- The User-Controlled Internet"

Original Author: Emre Tekisalp

Translated by: Baize Research Institute

This article, composed of 3 parts, focuses on the latest chapter in the history of the internet—Web 3, its reasons, contents, and methods. Part 1 explains the shortcomings of today's web and how Web 3 improves upon them; Part 2 highlights how Web 3 operates; Part 3 emphasizes how developers can build on it.

Part 1: Why is Web 3.0 the Next Chapter of the Internet?

Today's internet has two key missing attributes:

1. It does not hold "state" independently of trusted operators.

2. It lacks a native mechanism to transfer state.

The lack of state is a result of the simplicity of web-building protocols like HTTP and SMTP. At any given time, if you were to query the historical or current state of a node (a device connected to the internet), it would not know. From a user's perspective, this is akin to using the internet for the first time from a new browser (with no history, bookmarks, saved settings, or autocomplete) every time you use anything connected to the internet.

Imagine having to submit your user information every time you try to use a service or download all your favorite apps when you turn on your device. The internet would be unusable, or at least extremely inefficient.

However, state is crucial for the development of services and applications, as it can represent value. Therefore, two key developments have addressed this deficiency. First, as Brendan Eich emphasized, the invention of cookies was meant to allow web-based applications written in JavaScript to save state on each local device.

The problem with cookies is that they are created and controlled by service providers, not users. Users cannot control which provider gives them state or has access to their state.

The second development that addresses the lack of state is centralized service providers, which store user state on their own machines.

Today, large internet companies like Google and Facebook possess the data of billions of people and the value created from it. This is not inherently wrong, as their users have benefited from the services and value created by the same companies. The problem lies in how the internet allows these centralized companies to benefit more than the public.

The second key missing attribute of the internet, the lack of a native mechanism to transfer state, is partly a byproduct of the first issue. If you cannot hold state (and the value it creates), you cannot transfer it. The ability to transfer value easily and efficiently is at the core of economic development and modern finance. Any improvement in the efficiency of value transfer will have cascading positive effects.

Today's internet makes information transfer easier, creating enormous potential for new businesses and services. However, if businesses do not have a simple way to transact value, they need to find another way to profit from their services.

This is why, for years, the existing business model of the web has turned into advertising, as the advertising business is the only one that can effectively store and transfer the states of billions of users. Similarly, advertising itself is not wrong. But this time, the problems are threefold:

1. Third-party intermediaries facilitate every advertising transaction and profit from it;

2. Advertising favors established companies, putting new businesses at a disadvantage and limiting economic growth potential;

3. A richer advertising economy relies on more user data (for providing advertising models), leading to inconsistent incentives for users and poor user experiences.

The Direction of the Internet

The web itself is a technological development. It is merely a collection of pipes, indifferent to what humans do with it. Ultimately, humans need to decide where to direct it. For the future of the web in the next couple of years, a better direction is to promote:

Any participant creating local economic value;

Transferring this native value to any participant.

With the invention of blockchain, thanks to Satoshi Nakamoto and other scholars before her/him/them, we now have a way for every participant in the network to save and transfer state in a digitally native format. Many developers and entrepreneurs around the world have begun to build (or #BUIDL, as the case may be) on this new layer of state.

With the emergence of open platforms like Ethereum, this is becoming easier by the day. As people begin to realize what these new capabilities allow them to do, they have started to support calls for a more open and equitable internet (also known as Web 3.0).

Part 2: Components of Web 3.0

As explained in Part 1, today's internet is a stateless internet—its participants cannot maintain their own state, nor can they locally transfer it from one state to another. Starting with Bitcoin, blockchain provides us with a way to save state in a digitally native manner.

We in the crypto and blockchain ecosystem have begun to refer to this new fundamental capability as Web 3.0. While we are still in the early stages, we have started to roughly understand what benefits it may bring.

This part is about what Web 3.0 may look like today and in the future:

Image: Modular architecture of Web 3.0

The layers in the framework above build downwards along the y-axis, starting from the top. Colors represent compatibility between modules in different layers. For example, today's crypto commodities (yellow), as shown, are compatible with EVM (blue to yellow) but not with Bitcoin script (green to red).

In turn, EVM is compatible with the Ethereum blockchain (blue) but not with the Bitcoin blockchain (green). This allows us to place future crypto commodities that are compatible with Bitcoin script and thus recorded on the Bitcoin blockchain into the framework (although this is highly unlikely due to technical challenges). This modularity is crucial for the robustness of Web 3.0, as upgrading one layer should not require a complete rewrite of everything below it.

State Layer

The state layer retains the state of everything happening below it. It is almost entirely provided by blockchain infrastructure and allows any participant to engage as long as they adhere to the rules of the preferred network.

The goal of any successful network is to become a default, reliable infrastructure, similar to today's DNS providers. When they work as expected, no one recognizes them (99% of the time), but when they do not work, we all feel the pain.

This layer can be public or private/permissioned. One might argue that by default, the state is a single and universal truth, and creating private layers is akin to creating parallel universes. There are also technical differences between public and permissioned layers, but they are beyond the scope of this article and will be deferred to developers as design choices for their products.

From here, each layer builds on or is compatible with the layer below it.

Computation Layer

Software allows humans to issue commands to computers. The Web 3.0 computation layer allows humans to instruct the state layer to do what they want to do. However, not every computation layer allows for anything.

For example, Bitcoin's script is very limited as it only allows for things outside of transaction orders. On the other end, the Ethereum Virtual Machine (EVM) is a complete Turing-complete machine, allowing for arbitrary complex computations to be executed by state layers that support EVM.

Choosing a computation layer for application developers (and blockchain developers) is a critical factor, as it determines which blockchains a given application can run on. For instance, any application compiled for EVM can run on the Ethereum blockchain today but cannot run on the Bitcoin blockchain.

The Ethereum Foundation is working to change Ethereum's default computation layer to another called eWASM, based on WebAssembly, or WASM. Other state layer projects like Dfinity also plan to be compatible with WASM. This means that applications compiled for eWASM could theoretically run on both Ethereum and Dfinity blockchains, as well as any other blockchain that decides to be compatible with WASM.

Component Layer

Combining the state layer with the computation layer increases the design space for new types of digital value by 1,000 times (also known as programmable money). Therefore, we have begun to see a significant amount of experimentation by developers. Some of these implementations have such great potential (as shown in the examples below) that entire sub-economies can be imagined to be built on given components.

My colleague Jacob Horne at Coinbase describes this phenomenon (along with the protocol layer) as crypto-economic primitives and has conducted in-depth studies on one of them, namely crypto commodities.

Components build on the computation layer, reusing standardized smart contract templates. OpenZeppelin is a great resource for accessing such templates. Creators of these components need to deploy new smart contracts on the state layer.

Examples of these components include:

1. Native Currency: A necessary and core part of any public blockchain. It grants any participant the right to pay blockchain fees and receive the desired services in return, typically in the form of transactions. Examples: Bitcoin, Ether.

2. Crypto Assets: Replaceable assets with a set of basic functionalities and associated metadata. This sparked the ICO craze, as it allowed anyone to create their own currency. Besides currencies, many other asset types can also be digitized, such as stocks, bonds, and ownership. The most common standard is ERC-20.

3. Crypto Commodities: Non-replaceable assets with a set of basic functionalities and a richer set of associated metadata. Also known as non-fungible tokens (NFTs) or crypto collectibles. First explored by CryptoPunks and popularized by CryptoKitties. They enable unique commodities to be digitized, such as collectibles, game assets, access rights, and artworks. The most common standard is ERC-721.

4. Identity: A self-sovereign container for identity information. In itself, it provides little valuable information about its identifying content. However, it allows claims associated with the container, which can come from various sources, such as governments or other trusted parties (like Google, Coinbase).

Leading proposals include ERC-725/ERC-735 and some protocol proposals from uPort. Ethereum Name Service (ENS) as a different type of identifier is also highly relevant.

5. Stablecoins: Crypto assets with stable value, pegged to a source, such as the value of the US dollar. A very complex issue with various theoretical and practical solutions. Some examples are TrueUSD, Dai, and Reserve.

Protocol Layer

Once components are created on the state layer, they need to be activated. Certain functions are so important and universal for the lifecycle of these components that they are becoming standardized. This is not only because these functions need to use the same language (hence called the protocol layer) but also because network effects make them more efficient.

These protocols essentially enable healthy markets to form for the relevant components, just as we do in the physical world, only cheaper and more efficiently by several orders of magnitude.

Various different protocols have begun to gain attention. These take the form of standardized smart contracts, deployed by teams developing the protocols, and called by each application that wants to apply the relevant functionality to the components:

1. Trading: For a component to have value, it needs to be tradable. Trading protocols allow for trustless wallet-to-wallet transactions of assets. It is important to distinguish these "relayers" from most "decentralized exchanges," which host assets on smart contracts.

Transactions facilitated by trading protocols never hold the trading assets. Some leading projects include 0x and Kyber Network. To learn more about the daily trading volume supported by the 0x protocol, you can visit here.

2. Lending: Lending increases the efficiency of any asset as it facilitates returns on investments that might otherwise be zero. Through standard lending protocols, a person in the US can lend money to another person in Zimbabwe, from smartphone to smartphone. Dharma and ETHLend are currently two leading projects in this space.

3. Derivatives: The derivatives market is the largest market in the world, estimated at $1.2 trillion globally. Building derivatives as protocols allows for trustless markets to form for state layer native components. dy/dx and Market Protocol are two projects in this field.

Scalability/Transfer Layer

The scalability issues of blockchains are notorious. The Bitcoin blockchain has a transaction capacity of 7 transactions per second, while Ethereum has 15 transactions per second. Despite much debate about whether blockchains should compromise to facilitate thousands of transactions per second, it is widely accepted that different layers for state transfer (also known as Layer 2 scalability) are needed to support a robust topology. These scalability solutions need to be compatible with the computation layer of the underlying blockchain.

There are various proposals on how to achieve this. Here are some examples:

1. Payment Channels: Only allow the transfer of a given native currency. Completed through verifiable signatures attached to transactions on the state layer. Funds need to be deposited to facilitate disputes. Examples: Lightning Network for Bitcoin, Raiden for Ether, Vynos implementation for SpankChain on Ether.

2. State Channels: Allow the transfer of any state. Completed through verifiable signatures attached to transactions on the state layer. Funds need to be deposited to facilitate disputes. Examples: Counterfactual for EVM, Celer Network for EVM, Arcadeum for EVM, Fate Channel for EVM from FunFair, Connext for EVM.

3. Sidechains: Allow the transfer of any state. Completed by other blockchains compatible with the main chain. Requires the sidechain to be able to communicate with the computation layer on the main chain. Also requires locking funds to facilitate disputes. Sidechains can be centrally or privately managed infrastructures. Examples: PoA Network for EVM, Loom Network for EVM, Plasma Framework for EVM.

It should be noted that Plasma (with many different implementations) has additional requirements built in to provide users with guarantees for safely withdrawing their assets to the computation layer. In this way, its value proposition is more similar to state and payment channels.

4. Now that we have reached the fifth layer, we can see how this modular stack allows developers to be independent of lower-level design choices, such as which blockchain to build on. Let's take the hypothetical stablecoin smart contract in the near future as an example—compiled to eWASM, running on Ethereum, and compatible with Counterfactual state channels (i.e., it can transfer over state channels).

The same code for the aforementioned stablecoin would theoretically be compatible with EOS and Dfinity blockchains, as both run WASM. It could even be transferred over similar state channels running on those blockchains.

User Control Layer

Until this layer, it is nearly impossible for ordinary users to utilize any created functionality unless they directly interact with the computation layer through a command-line interface. The main function of this layer is to manage users' private keys and to be able to sign transactions on the state layer. Transactions on the state layer change the state of the user's account, thus being central to how users interact with Web 3 applications.

There are two types of wallets:

1. Custodial Wallets: Popular among exchanges like Coinbase or other cryptocurrency exchanges, representing users by managing funds through a limited set of proprietary balances on the state layer. These can pool users' funds into aggregated accounts, thus managing individual users' states outside the state layer. While this operation may be feasible and economical when considering only currency value, it becomes increasingly complex as the number of states brought by Web 3 applications increases.

There are also some new types of custodial wallets that manage a dedicated blockchain wallet for each user and support the use of decentralized applications. These are expected to further enhance flexibility but have yet to be proven at scale.

2. User-Controlled Wallets: Provide a more flexible and direct way to use all the arbitrarily complex operations enabled by Web 3. The reason for making wallets user-controlled is the local custody of user private keys and the local signing of each transaction. This means that wallet software does not replicate users' private keys in a way that allows third parties to submit transactions on behalf of users.

This is the ultimate user touchpoint for all underlying layers, so it needs to expose all available functionalities to applications accessing through this layer. This is typically done through frontend libraries like web3.js. Part 3 of this article delves into how all of this comes together.

Application Layer

Much of the activity on Web 3 will be conducted through third-party applications built on all the layers below, very similar to traditional Web. For example, users realize the value of CryptoKitties (i.e., crypto commodities) because all functionalities are provided through applications using CryptoKitties, such as cryptokitties.co or kittyrace.com or cryptogoods.com.

Applications built on Web 3 have different properties and requirements than traditional web applications, and are often referred to as decentralized applications or DApps. As Matt Condon articulated, for a DApp to be used by millions of users, it needs to be indistinguishable from existing applications.

However, the new functionalities brought by decentralization are precisely why DApps are so powerful, and why we may see usage that exceeds today's web as the stack matures. We have already seen developers around the world creating different categories of cutting-edge use cases, with users responding by putting funds into what they perceive as valuable.

1. Fundraising: Closed at $20B raised, with 723,000 unique accounts participating and over 8,000 companies receiving investments. Although fraud has emerged in this space, as of the publication of this article, it is the most popular application category based on the number of participating accounts. Moreover, its appeal continues, as many new fundraising platforms have emerged that facilitate regulated ICOs.

2. Trading Platforms: Traditional crypto trading platforms act as intermediaries between you and the state layer (by acting as custodial wallets), while trading platforms built to support Web 3 allow users to maintain control over their funds instead of depositing them into third-party wallet addresses. Additionally, the trading experience has potential user experience advantages. Many different projects are working to overcome some technical challenges, but we have already seen an increase in usage in this area.

3. Games and Collectibles: Raised $50-100 million through 60,000 unique accounts owning some Crypto Goods. While much smaller than fundraising, games that interact with crypto commodities offer exciting potential for the massive gaming market.

Part 3: How Do Developers Build Web 3.0?

Web 2.0 vs Web 3.0 Architecture

A simple version of today's Web 2.0 architecture includes client software, typically a browser or a standalone application, and a set of servers that provide content and logic, all controlled by the same entity—we call this Game Co. In this model, Game Co. has unique control over who can access its servers' content and logic, as well as tracking which users own that content and for how long.

There are many examples in the pages of technological history of how internet companies have changed the rules for users or stopped their services, leaving users without the right to preserve the value they create.

Web 3.0 architecture leverages the functionalities supported by a universal state layer. It does this by allowing two things:

1. Applications can place part or all of their content and logic on a public blockchain. Unlike standard Web 2.0, this content and logic can be public and accessible to anyone.

2. Users can directly control this content and logic. Unlike Web 2.0, users do not necessarily need an account or privileged API key to interact with content on the blockchain.

Web 3 applications achieve this with the help of two key infrastructure components:

1. Wallets: Besides serving as the user control layer of the Web 3 stack, modern wallets (like Coinbase Wallet) also interact with the main client frontend to provide a seamless user experience. They do this by allowing applications to send requests to the wallet itself using standard libraries, with web3.js being the most popular. An example of a web3.js call could be a payment request asking the user to confirm that the wallet can send a specified amount of funds to the application address.

When the user accepts, two things happen: 1) The wallet responds to let the application frontend know, so it can display a "Payment Submitted" screen, and 2) The wallet makes an RPC call to the blockchain server to submit the approved transaction to the blockchain. This is where the second infrastructure component comes into play.

2. Blockchain Nodes: There are two types of agents constantly monitoring and participating in the blockchain—miners and nodes. Miners directly maintain and run the blockchain, while nodes monitor and submit transactions to the blockchain. They can be thought of as similar to ISPs and cloud service providers (like AWS). Just as most applications today use AWS services to run their application backends, blockchain node providers (like Infura) perform the same function for blockchain nodes.

When a wallet wants to submit a transaction to the blockchain or query state information from the blockchain, it calls the node provider. The application server of the application can also interact with the node provider itself, keeping the application's logic up to date through similar RPC calls.

Tools and Frameworks

Knowing which tools and frameworks to use and being proficient in them is an important part of any developer's life. Although the Web 3 space is still in its early stages, we are beginning to have available tools that enable developers to reach the MVP stage and iterate faster and faster. This is most evident on Ethereum, where many efforts from the community have led to a rush of developers.

Design Choices

1. Decentralization: This is a new key choice. Most early developers aimed to decentralize as much as possible and put everything on the blockchain. However, given the slow and expensive nature of today's blockchains, this is not feasible at scale. CryptoKitties may be the first DApp to attempt to keep certain parts centralized.

For example, their breeding logic is not public. Despite facing some criticism for this, it did not stop users from spending significant amounts of money to buy cats bred with this logic. Gods Unchained is another example where the game itself will be hosted on standard cloud infrastructure, but ownership of the assets will be tracked on the state layer.

While many DApps will take different approaches to decentralization, the primary principle approach close to this choice is to adopt a "minimal 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 payments of your market should be on the blockchain.

Ultimately, if users can have true ownership of the key activities supported by your application, they will find your application valuable.

2. Web Applications vs Native Applications: This is a choice that has existed for decades but presents itself in new forms in Web 3 applications. Most DApps today are web applications for two simple reasons: a) It does not require users to download a new application every time, b) Users can use your application without having to create a new wallet each time. The few existing native DApps lead users to create new wallets, which is not an ideal user experience.

It is easy to see that this is not a viable future, as users will not maintain keys for hundreds of wallets. In the near future, there will be more seamless ways for native applications to overcome this UX challenge, but for now, web applications allow for an easier onboarding experience.

3. Desktop vs Mobile: The Web 3 version of this choice is not about choosing between the two, but about how users will ultimately use your DApp on both. On desktop, Chrome extensions like MetaMask have been the way most users interact with DApps. Although it requires users to download a new extension, they are still interacting with a browser interface they are familiar with.

However, on mobile, extensions are not possible, at least on iOS. This is why wallet applications (like Coinbase Wallet) place a browser within their applications. Once in the browser view, the DApp experience is the same as on desktop. There are also some technical nuances to be aware of when developing for mobile, which Pete Kim, the engineering lead of Coinbase Wallet, elaborates on here.

Other challenges that have yet to be solved:

1. Who pays for gas: Every DApp built on Ethereum today requires its users to pay transaction costs, known as gas on the Ethereum blockchain. If millions of non-crypto natives are to use Web 3 applications, this will not be feasible in the long run. There are many theoretical solutions, some of which are closer to practical, such as gas relayers, but none have proven practical yet.

2. Application-specific accounts or not: One of the exciting applications of Web 3 is universal identity. Since there are not many functional identity solutions today, some DApps still require users to create accounts to associate certain identities with their activities in the application. This is not much different from how things are done in Web 2.0.

Once we have functional decentralized identity solutions, how should DApps treat and present them? While there is no clear answer, some have suggested using ERC-725 and 735 to build the Origin demo.