This 3-part post focuses on the why, what and how of the latest chapter in the world wide web’s history, called Web 3. Part 1 explains shortcomings of today’s web and how Web 3 represents an improvement; Part 2 focuses on what the Web 3 stack is; and Part 3 focuses on how developers can build on it.
Today’s world wide web, or the internet, has two key missing properties:
- It doesn’t hold “state”, independent of trusted operators
- It doesn’t have a native mechanism to transfer state
Lack of state is a result of the simplicity of the protocols that the web is built on, such as HTTP and SMTP. At any moment, if you were to query a node (a device connected to the internet) about its history or current state, it has no idea. From a user’s perspective, this would be like using the internet for the first time from a new browser (no history, favorites, saved settings or auto-complete), every time you use anything connected to the internet. Imagine having to submit your user information every time you’re trying to use a service or downloading all your favorite apps every time you open your device. The internet would not be useable, or at least extremely inefficient.
The second development that addressed the lack of state is centralized service providers that hold user state on their own machines. Today’s large internet companies like Google and Facebook all hold the state, and hence the value created, by billions of people. There’s nothing inherently wrong with this, as their users have benefited from services and value created by the same companies. The problem lies in how the internet benefits these centralized companies way more than it does the public.
The second key missing property of the internet, the lack of a native mechanism to transfer state, is partly a by-product of the first issue. If you can’t hold state (and the value it creates), you can’t transfer it. The ability to easily and efficiently transfer value is at the heart of economic development and modern finance. Any improvement in how efficiently you can transfer value has cascading positive effects. Today’s internet has made it easier to transfer information by orders of magnitude and thus has created immense potential for new businesses and services. However, if there’s no easy way for businesses to trade value, they need to find another way to profit from their services.
This is why, over the years, the web’s incumbent business model has become advertising, as advertising businesses are the only ones that can efficiently store and transmit the state of billions of users. Again, there is nothing inherently wrong with advertising. But the problem, this time, is three-fold:
- Third-party intermediaries facilitate and profit from every single advertising transaction;
- Advertising favors established businesses, which puts new businesses at a disadvantage, limiting the economy’s growth potential;
- A richer advertising economy is reliant upon more user data (which feeds ad models), creating misaligned incentives with users and bad UX.
A Direction for the Internet
The web, in and of itself, is a technological development. It’s just a bunch of pipes, indifferent to what humans do with it. Humans, ultimately, need to decide where to point it. Over the years, it’s become obvious that its current direction will not benefit those who aren’t already benefiting from it. For the web’s next decade or two, a better direction would be to facilitate:
- The creation of native economic value by any participant; and
- The transfer of this native value to any participant.
With the invention of blockchains, thanks to Satoshi Nakamoto and other academics before her/him/them, we now have a way for each participant in a network to hold and transfer state in a digitally native format. Many developers and entrepreneurs around the world have started to build (or #BUIDL, as the case may be) on this new state layer. With the advent of open platforms such as Ethereum, this is becoming easier by the day. As people become aware of what these new capabilities allow them to do, they have started to rally around the cry for an internet that is more open and fair, otherwise known as Web 3.
As explained in Part 1, today’s internet is a stateless 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 hold state in a digitally native way. Those of us in the crypto and blockchain ecosystem have started to refer to this new fundamental capability as Web 3. Although we’re still in the very early days, we’re starting to have a rough understanding of what benefits it will bring. L4, for example, has put together some great insights on these benefits.
This part is about what the Web 3 stack looks like today, and likely in the future:
The Web 3 Stack — A modular framework
The layers in the framework above start from the top and get built down the y-axis. Colors represent compatibility between modules in the different layers. For example, today’s Crypto Goods (yellow), as depicted above, are compatible with EVM (blue to yellow) but not with the Bitcoin Script (green to red). EVM, in turn, is compatible with the Ethereum Blockchain (blue), but not with the Bitcoin Blockchain (green). This allows us to place in to the framework a future Crypto Good that is compatible with the Bitcoin Script and hence is recorded on the Bitcoin Blockchain (although this is highly unlikely due to technical challenges). Such a modularity is crucial to the robustness of Web 3, as upgrading one of the layers should not require a complete rewrite of everything below it. It’s also important to note that although the modules within each layer may end up looking completely different in 5 years, the layers themselves are intended to be comprehensive and cover all the pieces that make up Web 3.
The state layer preserves the state of all that happens below it. It is almost exclusively provided by blockchain infrastructure and allows for any participant to take part as long as they obey the rules of the preferred network. Any successful network’s goal will be to be a default and reliable infrastructure, akin to today’s DNS providers. No one recognizes them when they work as intended (99% of the time), but we all feel the pain when they don’t.
This layer can either be a public or private/permissioned layer. One can argue that by default, state is a singular and universal truth, and that creating private layers is akin to creating parallel universes. There are also technical differentiators between public and permissioned layers, but they are beyond the scope of this piece and hence will be deferred to developers as a design choice for their products.
From hereon every layer is built on or is compatible with the layers below it.
Software allows humans to give instructions to computers. The Web 3 Computation Layer allows humans to instruct the State Layer to do what they want. Not every Computation Layer allows for anything to be done, though. Bitcoin’s Script for example is very limited in that it allows for very little beyond transaction orders. The Ethereum Virtual Machine (EVM) on the other end is a full Turing Complete machine and, as such, allows for any arbitrarily complex computation to be executed by a state layer that supports EVM.
The choice of Computation Layer for application developers (as well as blockchain developers) is a key one as it determines which blockchains a given application can run on. For example any application compiled to EVM can today run on the Ethereum blockchain and not on the Bitcoin blockchain. The Ethereum Foundation is working to change Ethereum’s default computation layer to another technology called eWASM, based onWebAssembly, or WASM. Other State Layer projects such as Dfinity are also planning to be WASM compatible. This would mean that an app compiled to eWASM could theoretically work on both Ethereum and Dfinity blockchains, and any other blockchain that decides to be WASM compatible.
Combining the State Layer with the Computation Layer increases the design space for new types of digital value by 1,000x (aka programmable money). As such, we have already started seeing a ton of experimentation by developers. Some of these implementations have so much potential (examples below), it’s possible to imagine entire sub-economies being built on top of a given component. My colleague here at Coinbase, Jacob Horne, has laid out this phenomenon (along with the Protocol Layer) as Cryptoeconomic Primitivesand did a deep dive on one of them, Crypto Goods.
Components are built on the Computation Layer, reusing standardized smart contract templates. OpenZeppelin is a well established resource to access such templates. The creator of a component is required to issue new smart contracts onto the State Layer.
Examples of these components are:
- Native Currency: A required and core part of any public blockchain. Gives any participant the right to pay the blockchain and receive the desired service in return, usually in the form of a transaction. Examples: Bitcoin, Ether
- Crypto Assets : Fungible assets which have a basic set of functionalities and metadata associated. Gave rise to the ICO boom as it allows anyone to create their own money. Beyond money, enables many other asset types to be digitized such as stocks, bonds, ownership rights. Most common standard is ERC-20.
- Crypto Goods: Non-fungible assets which have a basic set of functionalities and a richer set of metadata associated with it. Also known as Non-Fungible Tokens (NFTs) or crypto collectibles. Was first explored by CryptoPunks and made popular by CryptoKitties. Enables unique goods to be digitized such as collectible items, game assets, access rights, art. Most common standard is ERC-721.
- Identity: A self-sovereign container for identity information. In and of itself, provides very little valuable information about what it identifies. However, it allows for claims to be associated with the container, which can come from a large array of sources, such as governments or other trusted parties (e.g. Google, Coinbase). Leading proposals are ERC-725/ERC-735 and some of the protocol proposals by uPort. Ethereum Naming Service (ENS) is also highly relevant as a different type of identifier.
- Stablecoins: Crypto assets with a stable value, pegged against a source, such as the value of the USD. A very complex problem with different types of theoretical and practical solutions. Some examples are TrueUSD, Daiand Reserve.
Once you have Components created on the State Layer, they need to come alive. Certain functions are so fundamental and common to the lifecycle of these components that they are becoming standardized. This is not only because these functions need to talk the same language (hence the name Protocol Layer) but also because network effects make them more efficient. These protocols essentially enable the formation of healthy markets for relevant components, much like we have in the physical world, only orders of magnitude cheaper and more efficient.
Multiple different protocols have started to gain traction. These take the form of canonical smart contracts that are deployed by the team developing the protocol and called by each application that wants to apply the relevant function onto a component:
- Trading: If a component is to have value, it needs to be tradable. Trading protocols allow wallet-to-wallet trading of assets in a trustless way. It’s important to draw the distinction between these “relayers” and most “decentralized exchanges”, which take custody of assets on a smart contract. Trades that get facilitated via trading protocols never take custody of the traded assets. Some leading projects include 0x and Kyber Network. To find out more about the daily trading volumes supported on the 0x protocol, you can visit here.
- Lending: Lending increases the efficiency of any asset as it facilitates a return on the investment, which otherwise may have been zero. With a standard lending protocol, an individual in the US can lend money to another individual in Zimbabwe, smartphone-to-smartphone. Dharma and ETHLend are currently the two leading projects in this space.
- Derivatives: The market for derivatives is the largest in the world, estimated at $1.2 quadrillion globally. Building derivatives as a protocol allows trustless markets to form for components native to the State Layer. dy/dx and Market Protocol are two projects in this space.
Scalability / Transfer Layer
Blockchains’ scalability problems are infamous. Bitcoin’s blockchain has a transaction capacity of 7 transactions per second and Ethereum’s is 15 per second. Although there is ample debate about whether blockchains themselves should make concessions to facilitate thousands of transactions per second or not, it’s becoming widely accepted that a different layer (also known as Layer 2 scalability) for the transfer of state is required to support a robust topology. These scalability solutions need to be compatible with the Computation Layer of the underlying blockchain.
There are multiple proposals for how this can be done. Below are some examples:
- Payment Channels: Allows only for transfer of a given native currency. Is done via verifiable signatures that are attached to transactions on the State Layer. Requires funds to be deposited to facilitate disputes. Examples: Lighting Network for Bitcoin, Raiden for Ether, SpankChain’s Vynosimplementation for Ether.
- State Channels: Allows for the transfer of any state. Is done via verifiable signatures that are attached to transactions at the State Layer. Requires funds to be deposited to facilitate disputes. Examples: Counterfactual for EVM, Celer Network for EVM, Arcadeum for EVM, FunFair’s Fate Channelfor EVM, Connext for EVM.
- Side Chains: Allows for transfer of any state. Is done by other blockchains that are compatible with the main chain. Requires the side chain to be able to talk to the Computation Layer on the main chain. Also require funds to be locked to facilitate disputes. The side chain may be a centrally or privately managed infrastructure. Examples: PoA Network for EVM, Loom Network for EVM, Plasma Framewok for EVM. It should be noted that Plasma (which has a number of different implementations) has additional requirements built into it so that it provides users with a guarantee to securely withdraw their assets to the Computation Layer. In this way its value proposition is more similar to state and payment channels.
Now that we’re up to the fifth layer, we can see how this modular stack allows developers some independence from lower level design choices, such as which blockchain to build on. Let’s take the example of a hypothetical Stable Coin smart contract in the not so distant future — compiled to eWASM, runs on Ethereum and is compatible with a Counterfactual state channel (i.e. it can be transferred on the state channel). The same code for said Stable Coin would theoretically be compatible with both the EOS and Dfinity blockchains, as both run WASM. It could even be transferable on a similar state channel running on these blockchains.
User Control Layer
Up until this layer, it’s almost impossible for an average user to consume any of the functionality created, unless s/he talks directly to the Computation Layer via a command line interface. The main functionality of this layer is to manage a user’s private keys and be able to sign transactions on the State Layer. A transaction at the State Layer changes the state of a user’s account and hence is at the core of how users interact with Web 3 applications.
Anatomy of a Transaction on the Ethereum Blockchain
There are two types of wallets:
Hosted Wallets : Made popular by Coinbase or other crypto exchanges, manage funds on behalf of the user by controlling a limited set of proprietary balances on the State Layer. These may pool users’ funds into aggregated accounts and, as such, manage individual users’ states themselves, outside of the State Layer. This operation may be feasible and economic if the only consideration is monetary value, however it becomes more complex with the increasing number of states that Web 3 applications bring.
There are also examples of newer type of Hosted Wallets which manage a dedicated blockchain wallet for each user and support the use of decentralized applications. These promise further flexibility, however are yet to be proven at scale.
User Controlled Wallet: Provide a much more flexible and direct way to consume all the arbitrarily complex operations made possible by Web 3. What makes a wallet a User Controlled Wallet is local custody of a user’s private keys and local signing of each transaction. This means that the wallet software doesn’t replicate the user’s private keys in a way that allows a third party to submit transactions on the user’s behalf.
This is the ultimate user touch point for all the underlying layers and thus needs to expose all available functionality to applications accessed through this layer. This is usually done through front-end libraries such as web3.js. Part 3 of this post dives deeper on how all of this comes together.