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 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.
State Layer
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.
Computation Layer
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.
Component Layer
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 Primitives and 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 USDC, Dai and Reserve.
Protocol Layer
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 andETHLend 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 Vynos implementation 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.
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.
Application Layer
Much like the traditional web, the majority of the activity on Web 3 will be through third-party applications built on all the layers below. As an example, users realize value in CryptoKitties, which are Crypto Goods, because of all the functionality made available through apps that consume 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 thus are mostly referred to as decentralized apps, or DApps. As laid out by Matt Condon, DApps will need to become indistinguishable from existing apps if they are to be used by millions of users.
However, the new functionalities enabled by decentralization are precisely why DApps are so powerful and why we may see usage numbers beyond today’s web as the stack matures. We are already seeing cutting edge use cases being created by developers around the world in different categories, and users responding to them by putting their money where they see value.
- Fundraising: Close to $20B raised, 723,000 unique accounts participated,8,000+ companies received investments. While the space has seen its share of fraud, as of the date of this article, it is the most popular application category, based on the number of accounts that have taken part. Additionally, its attraction continues, as seen by the many new fundraising platforms that facilitate ICOs that are subject to regulation.
- Trading Platforms: Whereas traditional crypto trading platforms act as an intermediary between you and the State Layer (by acting as Hosted Wallets), trading platforms built as Web 3 enabled applications allow users to remain in control of their funds and not deposit them in to a third party wallet address. In addition, there are potential UX benefits for the trading experience. Many different projects are working to overcome some of the technical challenges, but we’re already seeing usage pick up in this area.
- Games & Collectibles: $50–100M raised with 60,000 unique accounts owning some Crypto Good. Although way smaller than fundraising, games that interact with Crypto Goods offer an exciting potential for the huge gaming market.
Summary of Part 2
In this part, I aimed to put together a holistic picture of the Web 3 stack. As explained, the Web 3 stack is comprised of modular components that allowfor state to be preserved across all participants, whilst preventing vendor lock-in to layers underneath. Thanks to this, an application does not need to rewrite its entire stack if it wants to change the state layer (i.e. blockchain). This is powerful as it creates healthy competition, and allows each layer to preserve the value it creates, without having to worry about what happens if the rules of the game get changed later on.
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.