Coinbase’s comprehensive analysis of the Web3.0 era and the interpretation of the 4D

This three-part article focuses on the latest constitution in the history of the Internet—the reason, content, and method of Web 3. Part 1 explains the shortcomings of today’s networks and how Web 3 can be improved; Part 2 focuses on the operating mode of Web 3; Part 3 focuses on how developers build on it.

Part1: Why is Web3.0 the next charter of the Internet?

Today’s Internet has two key missing attributes:

It does not hold “status” and is independent of trusted operators

It has no local mechanism to transfer state

The lack of state is the result of the simplicity of web-building protocols, such as HTTP and SMTP. At any time, if you want to query the history or current status of a node (device connected to the Internet), it doesn’t know. From the user’s point of view, it’s like using the Internet for the first time from a new browser (no history, favorites, saved settings, or autocomplete), every time you use anything connected to the Internet. Imagine you have to submit your user information every time you try to use a certain service or download all your favorite apps every time you turn on your device. The Internet will be unavailable, or at least extremely inefficient.

However, state is critical to the development of services and applications because it can represent value. Therefore, two key developments have made up for the shortcomings. First of all, as Brendan Eich emphasized, cookies were invented to allow web-based applications written in JavaScript to save the state on each local device. However, the problem with cookies is that they are created and controlled by the service provider, not the user. Users have no control over which provider provides their status or has access to their status.

The second development to address the lack of state is centralized service providers, which store user state on their own machines. Today, large Internet companies such as Google and Facebook have billions of people in the country, and the value created by it. This is not wrong in itself, because their users have already benefited from the services and value created by the same company. The question is how the Internet can benefit these centralized companies more than the public.

The second key missing attribute of the Internet, the lack of a local mechanism for transmission status, is partly a by-product of the first problem. If you can’t hold the state (and the value it creates), you can’t transfer it. The ability to transfer value easily and efficiently is at the core of economic development and modern finance. Any improvement that improves the efficiency of value transfer will have a cascading positive impact. Today’s Internet makes information transmission easier, and orders of magnitude have created huge potential for new businesses and services. However, if companies do not have an easy way to trade value, they need to find another way to profit from their services.

This is why over the years, the existing business model of the Internet has become advertising, because advertising is the only business that can effectively store and transmit the status of billions of users. Likewise, there is nothing wrong with the advertisement itself. But the problem this time is threefold:

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

Advertising favors established companies, which puts new companies at a disadvantage and limits the growth potential of the economy;

A richer advertising economy relies on more user data (used to provide advertising models), resulting in inconsistent incentives and poor user experience with users.

The direction of the internet

NbRxeyZfj375FwKB2gie61uzIdzBBuHt64ARyyUU.png

The network itself is a technological development. It is 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 creates local economic value;

Transfer this original value to any participant.

With the invention of the blockchain, thanks to Satoshi Nakamoto and other scholars before her/him/them, we now have a way for each participant in the network to save and transmit state in a digital native format. Many developers and entrepreneurs around the world have begun to build on this new state layer (or #BUIDL, depending on the situation). With the advent of open platforms such as Ethereum, this day is getting easier. As people begin to realize what these new features can allow them to do, they have begun to support the call for a more open and fair Internet (also known as Web 3.0).

Part2: The composition of Web3.0

As explained in Part 1, the Internet today 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, the blockchain has provided us with a way to preserve state in a digitally native way. Those of us in the crypto and blockchain ecosystem have begun to call this new basic feature Web 3.0. Although we are still in the early stages, we have begun to understand roughly what benefits it will bring.

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

AbXQZwGUHFIpngiroe78ucQpkKwEeD2KjYfnqrCS.png

Picture: Modular architecture of Web3.0

The layers in the upper frame start from the top and build down along the y axis. The colors represent the compatibility between modules in different layers. For example, today’s encrypted commodity (yellow), as shown above, is compatible with EVM (blue to yellow) but not compatible 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 put into the framework future encrypted goods that are compatible with Bitcoin script and therefore recorded on the Bitcoin blockchain (although this is extremely unlikely due to technical challenges). This modularity is essential to the robustness of Web 3.0, because upgrading one layer should not require completely rewriting everything below it.

State layer

FTL3lYW020TnnXXGlZK0T2tyJhKix7qN46fEAJRx.png

The state layer retains 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 comply with 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 will recognize them (99% of the time), but when they do not work, we all feel pain.

This layer can be a public layer or a private/permitted layer. One might argue that by default, the state is a single and universal truth, and creating a private layer is similar to creating a parallel universe. There are also technical differences between the public layer and the permission layer, but they are beyond the scope of this article, so they will be postponed to the developer as a design choice for their product.

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

Computing layer

V14PtBXMQ4TIcrbOHG550vmmmlULqRZeffEcXMKk.png

Software allows humans to issue instructions to computers. The Web 3.0 computing layer allows humans to instruct the state layer to do what they want. However, not every computing layer is allowed to do anything. For example, Bitcoin’s script is very limited because it only allows things other than trading orders. The Ethereum Virtual Machine (EVM) at the other end is a complete Turing complete machine, and therefore allows arbitrarily complex calculations to be performed by the state layer that supports EVM.

Choosing the 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 EVM can run on the Ethereum blockchain today, but not on the Bitcoin blockchain. The Ethereum Foundation is working to change the default computing layer of Ethereum to another technology called eWASM, based on WebAssembly, or WASM. Other state-level projects such as Dfinity are also planned to be compatible with WASM. This means that applications compiled into eWASM can theoretically run on the Ethereum and Dfinity blockchains and any other blockchains that decide to be compatible with WASM.

Component layer

8bS7YvXqi8Agd3wbWOZfvguMac9EFFwe4ZwIullh.png

Combining the state layer with the computing layer can increase the design space for new digital values ​​by 1,000 times (aka programmable currency). Therefore, we have begun to see a lot of experiments conducted by developers. Some of these implementations have such great potential (example below), it is conceivable that entire sub-economies are built on a given component. My colleague at Coinbase, Jacob Horne, described this phenomenon (along with the protocol layer) as a cryptoeconomic primitive, and conducted an in-depth study of one of them, crypto commodities.

The components are built on the computing layer, and standardized smart contract templates are reused. OpenZeppelin is a complete resource for accessing such templates. The creator of the component needs to publish a new smart contract on the state layer.

Examples of these components are:

Local currency: a necessary and core part of any public blockchain. Give any participant the right to pay blockchain fees and get the required services in return, usually in the form of transactions. Examples: Bitcoin, Ethereum

Encrypted assets: fungible assets with a set of basic functions and related metadata. It sparked the ICO boom because it allows anyone to create their own currency. In addition to currency, many other asset types can be digitized, such as stocks, bonds, and ownership. The most common standard is ERC-20.

Encrypted commodities: irreplaceable assets with a set of basic functions and a richer set of metadata related to them. Also known as non-fungible tokens (NFT) or crypto collectibles. First by exploring CryptoPunks and making popular CryptoKitties. Enable unique products to be digitized, such as collectibles, game assets, access rights, and artworks. The most common standard is ERC-721.

Identity: Self-sovereign container of identity information. On its own, it rarely provides valuable information about its identifying content. However, it allows claims to be associated with the container, which can come from a large number of sources, such as governments or other trusted parties (e.g. Google, Coinbase). The leading proposals are some protocol proposals of ERC-725/ERC-735 and uPort. The Ethereum Naming Service (ENS) is also highly relevant as a different type of identifier.

Stable currency: An encrypted asset with stable value that is linked to the source, such as the value of the U.S. dollar. A very complex problem with different types of theoretical and practical solutions. Some examples are TrueUSD, Dai and Reserve.

Protocol layer

TsvjFyAjAuWq53bWpu3KsDCeH3yoSkRpkx42JDXm.png

Once the components are created on the state layer, they need to be active. Certain functions are so important and common to the life cycle of these components that they are becoming standardized. This is not only because these functions need to use the same language (hence the name protocol layer), but also because network effects make them more efficient. These agreements can basically form a healthy market for related components, just like what we do in the physical world, but only a few orders of magnitude cheaper and efficient.

Many different agreements have begun to receive attention. These are in the form of standardized smart contracts, deployed by the team that develops the agreement, and called by each application that wants to apply related functions to the component:

Transaction: If a component is to be valuable, it needs to be tradable. The transaction protocol allows wallet-to-wallet transactions of assets in a trustless manner. It is important to distinguish between these “repeaters” and most “decentralized exchanges”, which host assets on smart contracts. Transactions facilitated through transaction agreements will never custody 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 promotes return on investment, otherwise the return on investment may be zero. Through standard loan agreements, one person in the United States can lend money to another person in Zimbabwe, from smartphones to smartphones. Dharma and ETHLend are currently the two leading projects in this field.

Derivatives: The derivatives market is the largest market in the world, with a global estimate of US$1.2 trillion. Constructing derivatives as protocols allows the formation of a trustless market for the native components of the state layer. dy/dx and Market Protocol are two projects in this field.

Scalability/transport layer

DRJZaVWo1HDDkGGW8RNAndZ8SL3TqoO0WpMFT6A4.png

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

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

Payment channel: Only the given national currency is allowed to be transferred. This is done by a verifiable signature of the transaction attached to the state layer. Need to deposit funds to promote disputes. Examples: Lighting network for Bitcoin, Raiden for ether, Vynos implementation of SpankChain for ether.

State channel: allows any state to be transmitted. This is done by a verifiable signature attached to the state layer transaction. Need to deposit funds to promote disputes. Examples: Counterfactuals for EVM, Celer Network for EVM, Arcadeum for EVM, Fate Channel for FunFair for EVM, Connext for EVM.

Side chain: allows any state to be transferred. Completed by other blockchains compatible with the main chain. The side chain is required to be able to talk to the computing layer on the main chain. It is also required to lock up funds to facilitate disputes. The side chain can 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 (with many different implementations) has built-in additional requirements to provide users with the assurance that their assets are safely extracted to the computing layer. In this way, its value proposition is more similar to state and payment channels.

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 us take the hypothetical stablecoin smart contract in the near future as an example-compiled into eWASM, run on Ethereum, and compatible with the Counterfactual state channel (that is, it can be transmitted on the state channel). The same code of the aforementioned stablecoin will theoretically be compatible with the EOS and Dfinity blockchains because both run WASM. It can even transfer on similar state channels running on these blockchains.

User control layer

UXKoVFNK3LgDBAYibOPcF3HRiG6MiYEkLc0de5HB.png

Up to this level, it is almost impossible for an ordinary user to use any of the created functions, unless he/she directly talks to the computing layer through the 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. The transactions of the state layer change the state of the user account and are therefore at the core of how users interact with Web 3 applications.

There are two types of wallets:

Custody wallet: Popular by Coinbase or other cryptocurrency exchanges, it manages funds on behalf of users by controlling a limited set of proprietary balances on the state layer. These can pool the user’s funds into the aggregate account, and therefore, manage the status of individual users outside the status layer. If only monetary value is considered, this operation may be feasible and economical, but as the number of states brought by Web 3 applications increases, it becomes more complicated.

There are also some examples of new custodial wallets, which manage a dedicated blockchain wallet for each user and support the use of decentralized applications. These are expected to further increase flexibility, but they have not yet been proven on a large scale.

User-controlled wallet: Provides a more flexible and direct way to use all arbitrarily complex operations implemented by Web 3. The reason for making the 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 will not copy the user’s private key in a way that allows a third party to submit transactions on behalf of the user.

This is the end-user touch point for all bottom layers, so all available functions need to be exposed to applications accessed through this layer. This is usually done through front-end libraries such as web3.js. Part 3 of this article delves into how all these fit together.

Application layer

B6RhNlwAK9q2lajfqStofFkBoB6om5ct8onTE5cx.png

Much like the traditional Web, most activities on Web 3 will be carried out through third-party applications built on all the following layers. For example, users are aware of the value of CryptoKitties (ie, encrypted goods) because all functions are provided through applications that use CryptoKitties, such as cryptokitties.co or kittyrace.com or cryptogoods.com. Applications built on Web 3 and traditional Web applications have different attributes and requirements, so they are usually called decentralized applications or DApps. As Matt Condon explained, if it is to be used by millions of users, DApp will need to be indistinguishable from existing applications.

However, the new features brought about by decentralization are exactly why DApps are so powerful, and why as the stack matures, we may see more usage than today’s networks. We have seen developers all over the world create different categories of cutting-edge use cases, and users respond to them by investing money in places they consider valuable.

Fund raising: closed to $20B upward adjustment, 723,000 unique accounts participated, 8,000+ companies received investment. Although fraud has occurred in the space, as of the date of this article, it is the most popular application category, based on the number of participating accounts. In addition, its appeal continues, as seen by many new fundraising platforms, which promote regulated ICOs.

Trading platform: The traditional crypto trading platform acts as an intermediary between you and the national level (by acting as a custodial wallet), while a trading platform built as an application supporting Web 3 allows users to maintain control of their funds instead of depositing them Enter the third-party wallet address. In addition, the trading experience has potential user experience advantages. Many different projects are working hard to overcome some technical challenges, but we have seen an increase in usage in this area.

Games and collectibles: USD 5-100 million was raised through 60,000 unique accounts with some Crypto Good. Although much smaller than fundraising, games that interact with encrypted goods provide exciting potential for the huge game market.

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 includes a client software, usually a browser or a stand-alone application, and a set of servers that provide content and logic, all of which are controlled by the same entity—we call it a game company. In this mode, Game Co. has sole control over who can access the content and logic of its server, and who owns the content and keeping track of the content of the content. There are many examples of how Internet companies change the rules for users or stop their services in the page of technology history. Users have no right to save the value they create.

The Web 3.0 architecture takes advantage of the functions supported by the common state layer. It does this by allowing two things:

Allows the application to put part or all of its content and logic on the public blockchain. Unlike standard Web 2.0, this content and logic can be made public and accessible to anyone.

Allow users to 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.

The Web 3 application achieves this with the help of two key infrastructure parts:

  • Wallet: 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 to achieve a seamless user experience. They do this by allowing applications to use the standard library to send requests to the wallet itself, web3.js is the most popular among them. An example web3.js call can be a payment request that requires the user to confirm that the wallet can send a specified amount of funds to the application address. When the user accepts, two things will happen: 1) The wallet lets the application front end know through the response, 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 district Block chain. This is where the second part of the infrastructure comes into play.
  • Blockchain nodes: There are two types of agents that constantly monitor and participate in the blockchain-miners and nodes. Miners directly maintain and operate the blockchain, while nodes monitor and submit transactions to the blockchain. One can think of them as similar to ISPs and cloud service providers (such as AWS). Similar to how most applications today use AWS services to run their application backends, blockchain node providers (such as Infura) perform the same operations on blockchain nodes. When the wallet wants to submit a transaction to the blockchain or query status information from the blockchain, it will call the node provider. The application server of the application can also interact with the node provider itself to keep the logic of the application up to date by making similar RPC calls.

Tools and framework

Knowing which tools and frameworks to use and using them proficiently is an important part of any developer’s life. Although the Web 3 field is still in its early stages, we have begun to have tools available that enable developers to enter the MVP phase and iterate faster and faster. This is most obvious on Ethereum, where developers are starting to flock due to the efforts of many people in the community.

Design choices

Decentralization: This is a new key choice. The goal of most early developers is 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 impossible to achieve on a large scale. CryptoKitties may be the first DApp to try to keep some parts centralized. For example, their breeding logic is not public. Although they have received some criticism for this, this has not stopped users from spending a lot of money to buy cats raised with this logic. Gods Unchained is another example. The game itself will be hosted on a standard cloud infrastructure, but the ownership of assets will be tracked on the state layer.

Although many DApps will adopt different decentralization methods, the first principle method to approach this choice is to adopt the “minimum viable public state” method. If you are building a game where users can own assets, the ownership should be on the blockchain. If you are building a prediction market, then your market reports and payments should be on the blockchain. After all, if users can have real ownership of the key activities your application supports, they will find your application valuable.

Web applications and native applications: This is a decades-old choice, but it takes on a new form 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 one every time New wallet. The few existing native DApps have caused users to create new wallets, which is not an ideal user experience. It is easy to see that this is not a viable future because 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 will ultimately use your DApp on both. On the desktop, Chrome extensions like MetaMask have always been the way 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, extension is not possible, at least not on iOS. This is why wallet apps, such as Coinbase Wallet, put the browser in their apps. After entering the browser view, the DApp experience is the same as the desktop. When developing for mobile devices, there are some technical nuances that need to be noted, and Pete Kim, the engineering director of Coinbase Wallet, introduces these details here.

Other challenges for which there is no solution so far:

Who pays for gas: Every DApp built on Ethereum today allows its users to pay transaction costs, which is called the gas of the Ethereum blockchain. If millions of non-encrypted locals want to use Web 3 applications, it will not 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 account or not: One of the exciting applications of Web 3 is the universal identity. Since there are not many functional identity solutions today, some DApps still require users to create accounts in order to associate certain identities with their activities on the app. This is not much different from the way things are done in Web 2.0. Once we have a functional decentralized identity solution, how should DApps treat and present it? Although there is no clear answer, some people have already made suggestions, such as the Origin demo built with ERC-725 and 735.

Original title: “Understanding Web 3-User Controlled Internet”

Original Author | Emre Tekisalp

 

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/coinbases-comprehensive-analysis-of-the-web3-0-era-and-the-interpretation-of-the-4d/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Leave a Reply