Original title: "Understanding Web 3 — A User-Controlled Internet"

Compile | Baize Research Institute

Compile | Baize Research Institute

first level title

text

The internet today has two key missing properties:

- It holds no "state", independent of trusted operators

- it has no native mechanism to transfer state

The lack of state is a result of the simplicity of the protocols the web is built on, such as HTTP and SMTP. At any point, it doesn't know if you're going to query the history or current state of a node (a device connected to the internet). From a user perspective, it's like using the internet for the first time from a new browser (no history, favorites, saved settings, or autocomplete) and 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 every time you turn on your device. The internet would be unusable, or at least extremely inefficient.

However, state is critical to the development of services and applications as it can represent value. Thus, two key developments have filled the gap. First, as Brendan Eich highlights, cookies were invented to allow web-based applications written in JavaScript to save state locally on each device. The problem with cookies, however, is that they are created and controlled by the service provider, not the user. Users have no control over which provider provides them state or has access to their state.

The second development to address the lack of state is centralized service providers that keep user state on their own machines. Today, large Internet companies such as Google and Facebook own countries of billions of people, and the value created by them. There is nothing wrong with that in itself, as their users already benefit from the services and value created by the same company. The question is how the Internet benefits these centralized companies more than the general public.

The second key missing property of the Internet, the lack of a local mechanism for transferring state, is partly a byproduct of the first problem. If you can't hold state (and the value it creates), you can't transfer it. The ability to transfer value easily and efficiently is at the heart of economic development and modern finance. Any improvement that increases the efficiency of value transfer will have cascading positive effects. Today's Internet has made information transfer orders of magnitude easier, thereby creating enormous potential for new businesses and services. However, if businesses don't have an easy way to trade value, they need to find another way to monetize their services.

This is why over the years, the existing business model of the web has become advertising, because the advertising business is the only business that can efficiently store and transmit the state of billions of users. Again, there is nothing wrong with advertising per se. But this time the problem is threefold:

- Third-party intermediaries facilitate and profit from each advertising transaction;

- Advertising favors established businesses, which disadvantages new businesses and limits the growth potential of the economy;

- A richer ad economy relies on more user data (used to feed ad models), creating inconsistent incentives with users and poor user experience.

direction of the internet

The web itself is a technological development. It's just a bunch of pipes, indifferent to what humans do with it. Ultimately, humans need to decide where to point it. For the next year or two of the network, a better direction is to promote:

- Any participant that creates local economic value;

- Transfer this native value to any participant.

first level title

Part2: Composition of Web3.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, blockchains have given us a way to preserve state in a digitally native way. Those of us in the crypto and blockchain ecosystem have started referring to this new fundamental capability as Web 3.0. While we're still in the early days, we've already begun to get a rough idea of ​​what benefits it will bring.

image description

Image: Modular Architecture for Web 3.0

The layers in the frame above start at the top and build down the y-axis. Colors represent compatibility between modules in different layers. For example, today’s cryptocommodities (yellow), shown above, are compatible with EVM (blue to yellow), but not with Bitcoin Script (green to red). In turn, the EVM is compatible with the Ethereum blockchain (blue), but not with the Bitcoin blockchain (green). This allows us to put into the framework future crypto-goods that are compatible with Bitcoin Script and thus recorded on the Bitcoin blockchain (although this is highly unlikely due to technical challenges). This modularity is critical to the robustness of Web 3.0, because upgrading one layer should not require a complete rewrite of everything below it.

state layer

The state layer keeps the state of everything that happens below it. It is provided almost entirely by the blockchain infrastructure and allows any participant to participate as long as they abide by the rules of the preferred network. The goal of any successful network is to be a default, reliable infrastructure, similar to DNS providers today. When they work as intended, no one will recognize them (99% of the time), but when they don't, we all suffer.

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

computing layer

computing layer

Software allows humans to give instructions to computers. The Web 3.0 computation layer allows humans to instruct the state layer to do what they want. However, not every compute layer allows to do everything. For example, Bitcoin's script is very limited in that it only allows transactions outside of order books. The Ethereum Virtual Machine (EVM) at the other end is a complete Turing-complete machine, thus allowing arbitrarily complex computations to be performed by an EVM-enabled state layer.

The choice of computing layer for application developers (and blockchain developers) is a key factor because it determines which blockchains a given application can run on. For example, any application compiled to the EVM can run on the Ethereum blockchain today, but not on the Bitcoin blockchain. The Ethereum Foundation is working to change Ethereum's default computing layer to another technology 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 to eWASM could theoretically run on the Ethereum and Dfinity blockchains, as well as any other blockchain that decides to be WASM compatible.

component layer

Combining a state layer with a computation layer can increase the design space for new types of digital value (aka programmable money) by a factor of 1,000. As a result, we've started to see a lot of experimentation by developers. Some of these implementations have such potential (examples below) that entire sub-economies could be imagined built on top of a given component. My colleague Jacob Horne at Coinbase describes this phenomenon (along with the protocol layer) as cryptoeconomic primitives, and has done an in-depth study of one of them, cryptocommodities.

Components are built on the computing layer, reusing standardized smart contract templates. OpenZeppelin is a perfect resource for accessing such templates. Creators of components need to publish new smart contracts on the state layer.

Examples of these components are:

- Native Currency: A required and core part of any public blockchain. Giving any participant the right to pay a blockchain fee and receive a desired service in return, usually in the form of a transaction. Examples: Bitcoin, Ethereum

- Cryptoassets: fungible assets with a set of basic functions and associated metadata. Sparked the ICO craze because it allowed anyone to create their own currency. In addition to currencies, many other asset types can be digitized, such as stocks, bonds, titles. The most common standard is ERC-20.

- Crypto-commodities: non-fungible assets with a basic set of functions and a richer set of metadata associated with them. Also known as non-fungible tokens (NFTs) or crypto collectibles. Start by exploring CryptoPunks and making popular CryptoKitties. Enables unique items to be digitized such as collectibles, game assets, access rights, artwork. The most common standard is ERC-721.

- Identity: A self-sovereign container for identity information. By itself, it rarely provides valuable information about what it recognizes. However, it allows claims to be associated with containers, which can come from a number of sources such as governments or other trusted parties (e.g. Google, Coinbase). Leading proposals are some protocol proposals for ERC-725/ERC-735 and uPort. The Ethereum Naming Service (ENS) is also highly relevant as a different type of identifier.

protocol layer

protocol layer

Once components are created on the state layer, they need to be made active. Certain functions are so important and common to the lifecycle of these components that they are becoming standardized. Not only because these functions need to speak the same language (hence the protocol layer), but also because network effects make them more efficient. These protocols are basically able to form a healthy market for related components, just like we do in the physical world, only orders of magnitude cheaper and more efficient.

A variety of different protocols have begun to receive attention. These take the form of canonical smart contracts, deployed by the team developing the protocol, and called by every application that wants to apply the relevant functionality to the component:

- Transactions: If a component is to have value, it needs to be tradable. The transaction protocol allows wallet-to-wallet transactions of assets in a trustless manner. It’s important to distinguish these “relayers” from most “decentralized exchanges,” which host assets on smart contracts. Transactions facilitated through the transaction protocol never take custody of the transaction assets. Some leading projects include 0x and Kyber Network. To learn more about the daily transaction volume supported by the 0x protocol, you can visit here.

- Loans: Loans increase the efficiency of any asset because it facilitates a return on investment that might otherwise be zero. With a standard lending agreement, one person in the US can lend money to another in Zimbabwe, from smartphone to smartphone. Dharma and ETHLend are currently the two leading projects in this space.

- Derivatives: The derivatives market is the largest in the world, estimated at $1.2 trillion globally. Building derivatives as a protocol allows for a trustless marketplace for components that are native to the state layer. dy/dx and Market Protocol are two projects in this space.

Scalability/Transport Layer

Blockchains are notorious for their scalability issues. The transaction capacity of the Bitcoin blockchain is 7 transactions per second, and that of Ethereum is 15 transactions per second. While there is much debate about whether the blockchain itself should make concessions to facilitate thousands of transactions per second, it is generally agreed that a different layer for state transfer (also known as layer 2 scalability) is needed to support robust topology. These scalability solutions need to be compatible with the computing layer of the underlying blockchain.

There are various suggestions on how to do this. Here are some examples:

Payment Channels: Only allow transfers of given national currencies. This is done through verifiable signatures of transactions attached to the state layer. Funds need to be deposited to facilitate disputes. Examples: Lighting Network for Bitcoin, Raiden for Ethereum, Vynos implementation of SpankChain for Ethereum.

State Channel: Allows the transfer of any state. This is done through verifiable signatures attached to state layer transactions. Funds need to be deposited to facilitate disputes. Examples: Counterfactuals for EVM, Celer Network for EVM, Arcadeum for EVM, FunFair's Fate Channel for EVM, Connext for EVM.

Sidechain: allows any state to be transferred. Done by other blockchains that are compatible with the main chain. The side chain is required to be able to talk to the computing layer on the main chain. Funds are also required to be locked to facilitate disputes. Sidechains can be centrally or privately managed infrastructure. Examples: PoA Network for EVM, Loom Network for EVM, Plasma Framewok for EVM. It should be noted that additional requirements are built into Plasma (there are many different implementations) in order to provide users with assurances that they can safely withdraw their assets to the computing layer. In this way, its value proposition is more akin to state and payment channels.

Now that we have reached the fifth layer, we can see how this modular stack allows developers to make independent lower-level design choices, such as which blockchain to build on. Let’s take as an example a hypothetical stablecoin smart contract in the near future — compiled to eWASM, running on Ethereum, and compatible with Counterfactual state channels (i.e. it can be transmitted on state channels). The same code for the aforementioned stablecoin would theoretically be compatible with both the EOS and Dfinity blockchains, since both run WASM. It can even be transferred on similar state channels running on these blockchains.

User Control Layer

Up to this layer, it is almost impossible for a normal user to use any created functionality unless he/she talks directly to the computing layer through a command line interface. The main function of this layer is to manage users' private keys and be able to sign transactions on the state layer. Transactions in the state layer change the state of user accounts and are therefore central to how users interact with Web 3 applications.

There are two types of wallets:

- Custody wallets: popularized by Coinbase or other cryptocurrency exchanges, manage funds on behalf of users by controlling a limited set of proprietary balances on a state layer. These can pool users' funds into aggregated accounts, thus, managing the state of individual users outside of the state layer. Such an operation may be feasible and economical if only monetary value is considered, but it becomes more complex as the amount of state brought about by Web 3 applications increases.

There are also examples of new types of managed wallets, which manage a dedicated blockchain wallet for each user and enable the use of decentralized applications. These promise further improvements in flexibility, but have yet to be demonstrated at scale.

- User Controlled Wallet: Provides a more flexible and straightforward way to use all the arbitrarily complex operations enabled by Web 3. What makes a wallet a user-controlled wallet is the local custody of the user's private key and the local signature of each transaction. This means that the wallet software does not duplicate the user's private key in a way that would allow a third party to submit transactions on the user's behalf.

application layer

application layer

Much like the traditional web, most activity on Web 3 will take place through third-party applications built on all layers below. For example, users realize the value of CryptoKitties (i.e. cryptogoods) because all functionality is 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 therefore often referred to as decentralized applications or DApps. As Matt Condon articulates, DApps will need to be indistinguishable from existing apps if they are to be used by millions of users.

However, the new capabilities enabled by decentralization are exactly what makes DApps so powerful, and why we'll likely see usage beyond today's web as the stack matures. We’ve seen developers around the world create different categories of cutting-edge use cases, and users respond to them by putting their money where they see value.

-Funding: Closed to $20B raise, 723,000 unique accounts participating, 8,000+ companies received investments. While the space has seen fraudulent activity, as of the date of this article, it is the most popular app category based on the number of accounts participating. Plus, its appeal continues, as seen with many new fundraising platforms that facilitate regulated ICOs.

- Exchanges: Traditional crypto exchanges act as an intermediary between you and the state layer (by acting as a custodial wallet), while exchanges built as Web 3 enabled applications allow users to maintain control of their funds, rather Deposit to the third-party wallet address. Additionally, there are potential UX advantages to the transaction experience. Many different projects are working to overcome some of the technical challenges, but we've seen an uptick in usage in this area.

first level title

Part3: How do developers build Web 3.0?

Web 2.0 and Web 3.0 architecture

A simple version of today's Web 2.0 architecture consists of a client software, usually a browser or a standalone application, and a set of servers providing content and logic, all controlled by the same entity - we call it the game company. In this model, Game Co. has sole control over who has access to the content and logic of its servers, and which users have a track record of what and how long that content is kept. In the pages of the history of technology there are many examples of how Internet companies changed the rules or discontinued their services to users, who had no right to preserve the value they created.

The Web 3.0 architecture leverages the capabilities supported by a common state layer. It does this by allowing two things:

- Allows applications to place some or all of their content and logic on a public blockchain. Unlike standard Web 2.0, this content and logic can be exposed and accessible to anyone.

- Allows the user to directly control this content and logic. Unlike Web 2.0, users don't necessarily need accounts or privileged API keys to interact with content on the blockchain.

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

• Wallets: In addition to being the user control layer of the Web 3 stack, modern wallets such as Coinbase Wallet also interact with the main client front end for 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. An example 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 lets the app frontend know by responding so it can display the "Payment Submitted" screen, 2) the wallet makes an RPC call to the blockchain server to submit the approved transaction to the zone blockchain. This is where the second infrastructure part comes into play.

• blockblockChain node provider (egInfurablockblockChain nodes also do the same. When a wallet wants to submit a transaction to the blockchain or query state information from the blockchain, it calls the node provider. An application's application server can also interact with the node provider itself, by making similar RPC calls to keep the application's logic up to date.

Tools and Frameworks

Knowing which tools and frameworks to use and using them proficiently is an important part of any developer's life. Although it's still early days in the Web 3 space, we're starting to have tools available to enable developers to get to the MVP stage and iterate faster and faster. This was most evident on Ethereum, where developers started flocking due to the efforts of many in the community.

design choice

- Decentralization: This is a new key option. The goal of most early developers is to be as decentralized as possible and put everything on the blockchain. However, given the slow and expensive nature of blockchains today, this is not possible at scale. CryptoKitties may be the first DApp to try to keep some parts centralized. For example, their breeding logic is not public. While they've gotten some criticism for this, that hasn't stopped users from spending huge sums of money on cats bred with this logic. Gods Unchained is another example, the game itself will be hosted on standard cloud infrastructure, but the ownership of the assets will be tracked on the state layer.

While many DApps will take different approaches to decentralization, a first principles approach to approaching this choice is to take a "minimum viable public state" approach. If you're building a game where users can own assets, ownership should be on the blockchain. If you are building a prediction market, then the reporting and payouts of your market should be on the blockchain. At the end of the day, users will find your app valuable if they can take real ownership of the key activities your app supports.

- Web Apps vs. Native Apps: This is a decades-old choice, but it's taking on a new form in Web 3 apps. Most DApps today are web apps for two simple reasons: a) it doesn't require users to download a new app each time, and b) users can use your app without having to create one every time new wallet. The few existing native DApps all 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 apps to overcome this UX challenge, but for now, web apps allow for an easier onboarding experience.

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

However, on mobile devices, extensions are not possible, at least not on iOS. This is why wallet applications such as Coinbase Wallet place browsers within their applications. Once in the browser view, the DApp experience is the same as the desktop. There are also some technical nuances to be aware of when developing for mobile devices, and Pete Kim, director of engineering at Coinbase Wallet, covers those details here.

Other challenges for which there are no solutions so far:

- Who pays for the gas: Every DApp built on Ethereum today makes its users pay transaction costs, called the gas of the Ethereum blockchain. If millions of non-encrypted natives are going to use Web 3 applications, it won't be feasible in the long run. There are many theoretical solutions, some of which are closer to practicality, such as gas repeaters, but none of them are practical yet.

- Application-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 requiring users to create accounts in order to associate certain identities with their activity on the app. This is not much different from the Web 2.0 way of doing things. Once we have a functional decentralized identity solution, how should DApps treat and present it? While there is no definitive answer, some have suggested it, such as the Origin demo built with ERC-725 and 735.