Coinbase Envisions Web 3.0

This 3 part informational article focuses on the whys, the what's and hows of the latest iteration of the web / internet's history, otherwise referred to as Web 3.0. In the first segment of this, we explain some of the shortcomings that we see from the web that we know and commonly use today, and how Web 3.0 represents an improvement and evolution of that formula.

Meanwhile, Part 2 will be focusing on what Web 3.0 stack is; and Part 3 focuses on how developers can get to grips with it and go on to subsequently build on it.

Coinbase Envisions Web 3.0 Part 1

So, some of the limitations that the internet, or ‘World Wide Web' faces are down to fundamental properties that it lacks. These being:

1 – It doesn't hold ‘state' independent of its trusted operators.

2 – It has no native mechanism to transfer state.

This fundamental lack of state is the result of a large-scale simplification of the protocols upon which the web was built, these include HTTP and SMTP. For example, at any moment, if you needed to query a node (a device that is connected directly to the internet) about its history or current state, it has no idea and no data to give you.

From the perspective of the average user, this would be like setting virtual foot onto the internet for the first time from a new browser (meaning no history, no favorites, saved settings or auto-complete), every time you use anything connected to the internet.

Here's another example: imagine having to submit all of your burdensome user information, every single time you wanted to use a service or download your favorite apps (of which you may have dozens) onto your various devices. The internet would become grossly inefficient at the best of circumstances, or wholly unusable by those that expect a certain level of efficiency.

The state, however, is essential to the development of services and applications as it can represent a very real value. As a result, two key developments have allowed this state drawback to be resolved in a couple of ways. Firstly, as is highlighted by Brendan Eich, cookies were invented in order for JavaScript written, web based applications to preserve state on each local device, while also streamlining the process for regular users.

But one of the problems with cookies is that they are created and controlled by the various service providers, and not the end user. The user does not have any control over which provider is giving them state or has access to their state.

One of the other developments that addressed this fundamental lack of state is the centralized service providers that hold user state on their own machines. In today's internet, large companies like Google and Facebook all hold onto the state, and hence the value that was created by the billions of people that constituted their daily active users.

While there is nothing inherently. wrong with doing something like this, as their users have benefited as a result of this system, thanks to the subsequent streamlining of services that occurred. The problem, however, lies in how the internet is able to benefit these centralized companies way more than it does the public.

The second key that makes up the missing property of the internet, the lack of a native mechanism to transfer state, is partly a by-product of the first issue mentioned. If you're unable to hold state (and the value that it creates and represents), you are unable to transfer it. The ability to then easily and efficiently transfer value is something that it at the very heart of economic development, especially for modern finance.

Any improvements in how efficiently you can transfer value has nothing but cascading positive effects. With today's internet, it has been made easier to transfer information by orders of magnitude and thus has created an immense potential for new businesses and services. On the other hand of this: if there is no easy way for businesses to trade this value, they need to find another way to profit from their services.

This is exactly why, over the span of years, the web's business model has flipped in order to become more centered around advertising, especially as advertising businesses are the only ones that can efficiently and reliably store and transmit the state of billions of users. Once again, there isn't anything inherently wrong with doing this. But the problem, this time, is split in three:

  1. Third-party intermediaries facilitate and profit from every single advertising transaction;
  2. Advertising favors established businesses, which puts new businesses at a disadvantage, limiting the economy’s growth potential;
  3. A richer advertising economy is reliant upon more user data (which feeds ad models), creating misaligned incentives with users and bad UX.

Another Direction For The Internet

In and of itself, the internet has been a technological marvel and development. Where it functions as a ‘series of tubes' to borrow a meme, it is indifferent to what humans do with it. Ultimately, it's these same humans that need to decide where to direct it.

Over the last few years, it's become quite obvious that its current direction will not benefit those who aren't already harassing and benefiting from it to some extent. Over the next one or two decades, a better direction would be to do the following:

  1. The creation of native economic value by any participant; and
  2. The transfer of this native value to any participant.

With the advent of blockchain technology, thanks to its creator, Satoshi Nakamoto, among other academics before him/them/her/it?, we now have a better and smarter way for each participant within a network to hold and transfer state in a digitally native format.

At the moment, many developers and entrepreneurs around the world have started to build on this new state layer. And with the dawn of open platforms such as Ethereum, this is becoming an increasingly easy thing for developers to do. Especially as people become aware of what these new capabilities allow them to do, they have started to muster around the banner of an internet that is far more open and fair than the one we continually frequent. Otherwise referred to as Web 3.0.

Coinbase Envisions Web 3.0 Part Two

As previously discussed in Part 1, the internet of today is a stateless one – its participants can't hold their own unique state, nor can they transfer it from one to another natively. Blockchain, and its very first iteration, Bitcoin, provided users with a way to hold state in a digitally native way.

Those of us that currently inhabit the cryptocurrency and blockchain ecosystem have since began to refer to this new fundamental capability as Web 3.0. 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:

State Layers

These state layers preserve the state of all that happens below it. it's almost exclusively a provided element by blockchain infrastructures, allowing for any participant to take part, so long as they obey the rules of the preferred network.

Any successful network's goal will be to be a reliable and default infrastructure, much like the DNS providers that we all know today. No one can honestly recognize them when they work as they're intended to (which refers to them 99% of the time), but we agonize over the times that they don't.

This state layer can either be a publicly accessible one, or a private / permissioned layer. It is arguable that, as a default, state is a singular, and constitutes a universal truth, and the . creating various private layers is akin to creating a pocket dimension or parallel universe. There are also major technical differentiators between these public and permissioned state layers, but they are beyond the scope of this piece and hence will be deferred to developers as a design choice for their own products.

Computation Layer

Software allows us as humans and users to give precise instructions to computers. With the Web 3.0 Computation Layer, this allows us to instruct the State Layer to do what they want. It should be mentioned that not every Computation Layer allows for anything to be done, however. The script for Bitcoin is a prominent example, it's very limited in that it allows very little flexibility beyond standard transaction orders.

On the other side of this is The Ethereum Virtual Machine (EVM), which is a fully Turing Complete machine, and, as a result, allows for any arbitrarily complex computation to be executed by a state layer which allows and supports EVM.

The various choices of Computation Layer for application developers (including blockchain developers) is an essential one to decide on, as it determines which blockchains a given application can and will run on. An example of this any application compiled to EVM can today run on the Ethereum blockchain and not on Bitcoin's blockchain.

The Ethereum Foundation is working to change Ethereum's default computation layer to another technology, which is referred to as eWASM, which is based on WebAssembly. There are a number of other state layer projects, such as Dfinity, which is also planning on becoming WASM compatible. What this means is that an app compiled to eWASM could, in theory, work on both Ethereum and Dfininty blockchains, and any other blockchain that decides to be WASM compatible.

Component Layer

In combining the State Layer with the Computation Layer increases the design space of new types of digital value by 1,000x (aka – programmable money). As a result, we have already started finding a lot of experimentation by developers. Some of these applications have a great deal of potential, so it's possible to imagine entire sub-economies being developed and used on top of a given component.

Components which are built on the Computation Layer, also reuse standardized smart contract templates. For example, OpenZeppelin is a well known and established resource to access such templates. The creator of this component is required to issue new smart contracts onto the existing state layer.

Examples of these components are:

Native Currency:

A required and core part of any public blockchain. These give any participant the right to pay the blockchain and receive the desired service in return, usually in the form of a transaction. Examples of this include  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, Dai and Reserve.

Protocol Layer

So, once these same components are created on the State Layer, they will need to come alive. There are functions which are so fundamental and common to the lifecycle of these components that they are becoming standardized.

This is not only because these same functions need to be able to interact (hence the use of the protocol layer), but they also have to do this because network effects make them far more efficient. These protocols essentially enable the formation of healthier markets for relevant components, much like we have and do in the physical world, only orders of magnitude cheaper and more efficient.

There are multiple different protocols that have started to gain a significant amount of traction. These various protocols 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 specific component:

Trading:

Should a component seek to have value, it needs to be immediately tradeable by users. These Trading protocols allow for wallet to wallet trading of various assets in a trustless way. It's important to draw the distinction between these ‘Relayers' and most ‘decentralized exchanges', which take custody of various assets on a smart contract.Trades that get facilitated via trading protocols never take custody of the various traded assets. Some leading projects include the likes of 0x and Kyber Network to name but two.

Lending:

The aspect of lending increases the efficiency rate of any asset that it facilitates a return on the investment, which otherwise may have initially 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

The issues that blockchain has with scalability has become infamous, with the likes of Bitcoin having a transaction capacity of 7 per second, while Ethereum's is more than twice that at 15 per second.

While there is ample debate over whether blockchains themselves should be making concessions to facilitate thousands of transactions per second or not, it's becoming more of a widely accepted fact that a different layer (AKA – Layer 2 scalability) for the transfer state is becoming increasingly essential to support a robust level of 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:

This system only allows for the transfer of a given native currency, which is done through a verifiable signature system that is attached to transactions on the State Layer. These require funds to be deposited in order to facilitate disputes. Examples: Lighting Network for Bitcoin, Raiden for Ether, SpankChain’s Vynos implementation for Ether.

State Channels:

These allow for the transfer of any state. This is done through a verifiable signature that is attached to the transaction at the state layer. These require funds to be deposited to the affiliated transactions at the state layer too. These also require funds to facilitate disputes.Examples of this include: 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 here may take the . shape of 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, this brings us on to the fifth layer, where we can see how this modular stack allows and gives developers some level of independence from lower level design choices, such as which blockchain they should build on.

We can take the example of the hypothetical Stable Coin smart contract which is taking shape in the not too distant future – Compiled to eWASM, this runs on Ethereum and proves compatible with a Counterfactual state channel (Which can be transferred on the state channel). The same code for this Stable Coin would, theoretically, be compatible with both the EOS and Dfinity blockchains, this is due to both . being able to 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 the average user to consume any of the functionality that is created by it, unless, of course, they were to talk 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 previously mentioned. Any transaction at the state layer changes the state of a users account and, therefore, is at the core of how users interact with Web 3.0 applications.

Anatomy of a Transaction on the Ethereum Blockchain

There are two types of wallets:

Hosted Wallets

These types of hosted wallets were initially made popular by the likes of coinbase among other popular cryptocurrency exchanges. These allow users to exchanges to manage funds on behalf of any user by controlling a limited set of proprietary balances on the State Layer.

These may involve the pooling of users funds into an aggregated account and, as a result, 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 further examples of a newer type of Hosted Wallets which manage a dedicated blockchain wallet for each user, and support the use of dApps through them. These same wallets provide a further level of accessibility and flexibility, with few, at the moment, proving successful at scale.

User Controlled Wallet

These provide a much more flexible and direct way for users to consume all of the otherwise arbitrary and complex operations that are made possible by Web 3.0. What makes a wallet a user-controlled one is that local custody of a user's private keys and local signing of each transaction made. This effectively 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. Ordinarily, this is done through the use of front-end libraries such as web3.js. This sort of area will be covered in more depth in Part 3, where we dive deeper into how these elements all come together.

Application Layer

Much like the traditional web that we currently use, the majority of activity that will take place on the Web 3.0 will be through third party applications built on all the layers below. As an example, users realize value in Cryptokitties, which are essentially Crypto Goods, because of all the functionality that is made available through these apps that consume cryptokitties, such as Cryptokitties.co, 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 previously stated, dApps will need to become pretty much indistinguishable from the existing apps that are used, known and loved by millions of users worldwide.

These new functionalities, however, which are enabled by decentralization are exactly why dApps are so powerful, and why we may start to see usage number go beyond today's web as the stack enters wider maturity.

We are already seeing the sharpest point of the cutting edge in use cases being created by developers around the world in a number of different categories, and users are responding to them in one of the ways they easily can: putting their money where they see credible innovation.

Fundraising:

With close to $20 Billion being raised, 723,000 unique accounts taking part, over 8,000 companies have received a large volume of investment.While the . space has seen its fair share of fraud, as of this moment in time, it is one of the most popular application categories, based on a number of areas, such as the number of accounts taking part and how much is being raised. Additionally, its attraction continues, as seen by the many new fundraising platforms that facilitate ICOs that are subject to regulation.

Trading Platforms:

Compared to traditional cryptocurrency platforms, which act as an intermediary force between yourself and the state layer (by acting as Hosted Wallets), trading platforms that are built as Web 3.0 enabled applications allow users to remain in relative control of their funds, and not have to deposit them into a sort of third party wallet address.Along with this, there are a number of benefits for the trading experience from a UX standpoint that must be considered.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

Throughout this segment of the article, we put together a more holistic picture of the stack for Web 3.0, comprising its modular components that allow for state to be preserved across all participants, whilst preventing vendor lock in to layers underneath. Thanks to this, any application within this system doesn't need to rewrite its entire stack if it wants to change if it wants to change the state layer (aka – Blockchain).

This is pivotal as it creates far healthier competition, and allows for each layer to preserve the intrinsic value that it creates, all without having to worry about what happens if the rules of the game do, in fact, get changed in the near future..

Coinbase Envisions Web 3.0 Part 3

In Part 1, we reviewed how today’s internet is a state-less internet — its participants can’t hold their own state, nor transfer it from one to another, natively. Blockchain, which started with Bitcoin, handed us the way to having a stateful web of computers. And those of us in the cryptocurrency and blockchain world have come to refer to this as the new internet, or Web 3.0.

Web 3 adds a whole new infrastructure layer for applications to interact with, as well as new client functionalities and requirements. Various users will also need to learn relatively new UX concepts to be able to use these applications. As a result, the architecture of Web 3.0 applications will also introduce additional elements to the already existing Web 2.0 framework, while also adding new building blocks and tools for a developer to become acclimated and familiar with.

Web 2.0 Vs Web 3.0 – The Architecture

A more simplistic version of today's internet, or web 2.0 architecture includes a client software, usually a browser or self contained application, including a suite of servers which provide content and logic, all of what are controlled by the same entity – If we refer to this as Game Co. Within this model, the track record of which users own what and how long this content is kept live.

There are a number of examples in the of technology history of how internet companies have changed the rules on their users or stopped their service, usually with users having little to no power to preserve any value they themselves have created.

The way Web 3.0's architecture works is that it leverages what is enabled by a universal state layer. It is able to do this by allowing the following two things:

  1. Allowing applications to place some or all of their content and logic on to a public blockchain. Contrary to standard Web 2.0, this content and logic can become public and accessible by anyone.
  2. Allowing users to exert direct control over this content and logic. Unlike Web 2.0, users don’t necessarily need accounts or privileged API keys to interact with what’s on the blockchain.

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

Wallets:

This is beyond just being the user control layer for the web 3.0 stack. Modern wallets, like the one that exchanges like Coinbase use for example, interact with the main client front end in order to allow a seamless user experience.They are capable of doing this by . allowing applications to send requests to the wallet itself using standard libraries, with web3.js being one of the more popular versions of these.

An example web3.js call can be a payment request for one, in which it asks the user to confirm that the wallet can send the specified amount of funds to the application's address.

When the user accepts, these two things happen. The first being that the wallet lets the application from ten know with a response, so it can present a ‘payment submitted' screen. The second being that the wallet makes an RPC call to the underlying blockchain server to submit the approved transaction to the blockchain. This is where the second infrastructure piece comes into play.

Sample web 3 code allowing a DApp to call a smart contract function from a user’s wallet.

Blockchain Node:

When it comes to this area, there are two types of agents that constantly serve to monitor and engage with a blockchain, these are miners and nodes. The first of these, miners, directly maintain and run the blockchain, whereas nodes monitor and submit transactions to the blockchain. If You can think of them analogous to ISPs versus cloud services providers like AWS. These are relatively similar to how most applications we know today use AWS services to run their application backends, blockchain node providers, like Infura, do likewise with blockchain nodes.

When a wallet wants to submit a specific transaction to the blockchain, or commit a query state information from the blockchain, it makes an initial call to the node provider. Applications' app servers can also interact with the node providers, all to keep the app's logic as up to date as possible, all by making similar RPC calls.

So – What Do Developers Need To Know?

Tools & Frameworks

Knowing exactly what sort of tools and frameworks you, as a developer, will go on to use, while also obtaining a certain degree of proficiency with them is a considerable segment of any developers life. While the web 3.0 space is still very much in its infancy, we're starting to see and have more usable tools which enable developers to get to an MVP stage, allowing them to iterate faster and with greater efficiency. This is most visible on Ethereum, which, thanks to the work of its continually dedicated community, developers are starting to flock towards it in increasing numbers.

While it's not fully possible to go through all of these tools in meticulous detail, it's helpful to keep abreast of which ones would be at a developers disposal should the need arise.

Design Choices

What To Decentralize:

This is a relatively new and essential choice. When it comes to most early-stage developers, they have targeted to decentralize the maximum amount possible and putting everything on the blockchain.

Taking into consideration the slow and expensive nature of blockchains as they stand, however, it's not possible to do something like this at scale. Cryptokitties was one of the first dApps that tried to keep certain segments of it centralized. One example of this is the breeding logic, which is not a public segment. Although they have received some level of criticism for this, it hasn't stopped users from spending a remarkable amount of money to purchase cats which are bred by this same logic.

Although there are many dApps that will take different approaches when it comes to the prospect of decentralization, a first principle way of approaching this choice is to adopt a ‘minimal viable public state' approach. This is especially considerable if you are building a game where users can own various assets, then ownership should be on the blockchain, no question.

If you're building a prediction market, then the reporting . and pay out of that same market should also be on the blockchain. In summary, users will find your application valuable if they can claim true ownership over the key activities that your application allows and enables.

Web App Vs Native App:

This is a choice that’s decades old, yet takes on new form with Web 3 applications. Most DApps today are web apps because of two simple reasons:

  1. It doesn't essentially require the user to download a new app every single time.
  2. Users can otherwise use your app without having to create a brand new wallet every single time.

The very small number of native dApps that already exist all lead the user to create a new digital wallet, which is something that will pull a large number of users out of the experience altogether. It's very easy to see how this is not a feasible plan as this concept moves forward, especially as users will not maintain keys for hundreds of new wallets.

In the near future, there will be a far more seamless way of enabling native apps to go past this UX challenge that blockchain faces, but right now, web apps appear to be a far easier sell, with much easier onboarding experiences.

Desktop Vs Mobile:

The web 3.0 version of this discussion isn't really about deciding between one over the other, it's more about how users end up using the dApp on either of them. Through desktop, a chrome extension such as MetaMask has been how the majority of users have interacted with dApps.

However, it requires users to download a brand new extension, while the user is still interacting with the browser interface they're familiar with.

In contrast, on mobile, no such extensions are possible, at least via iOS. This is why wallet apps, like Coinbase's, allow for browsers inside of their apps. Once in this full browser view, the dApp experience is pretty much the same as on the desktop.

Other Challenges With No Solutions To Date

Who Pays For Gas:

For every dApp built on Ethereum at the moment, every one of their users pays the cost of transactions, called gas for the Ethereum blockchain. This is a system that isn't feasible over the long term, especially if millions of non-cryptocurrency natives are going to be using Web 3 applications.There are a number of proposed solutions to this, some of which are relatively close to being practical, such as the concept of gas relayers. While closer to being practical, none of these are functional are yet.

Every DApp built on Ethereum today makes its users pay the cost of transactions, called gas for the Ethereum blockchain. This won’t be feasible over the long term if millions of non-crypto-native people are to use Web 3 applications. There are a number of theoretical solutions, some which are closer to being practical, such as gas relayers, however, none are functional yet.

App-Specific Accounts Or Not:

One of the exciting applications that Web 3.0 presents is the concept of universal identity. Since there isn't much in the way of functional identity solutions today, some dApps are still asking users to create an account, which enables some identity to be associated with whatever activities a user was to get up to.This is not so different to web 2.0's way of conducting things. Once we have functional decentralized identity solutions, how should DApps treat and present this? Although there’s no clear answer, some are already presenting proposals, such Origin’s demo built using ERC-725 and 735.

Coinbase Envisions Web 3.0 Summary

In the third part, we sought to make a summary of the modifications the Web 3.0 would bring to the architecture of applications, especially for what developers should know when starting to build Web 3.0 apps. A great resource for beginners is Loom's CryptoZombies, which is an interesting and fun workshop, which teaches anyone how they can go about creating their first Web 3.0 app.

While the way to develop and build Web 3.o apps will change in many ways as the infrastructure around it evolves, what's key is that apps are being built today. Web 3.0 represents the metaphorical wild west in its current state that we know it, and a lot of highly capable, very smart teams and individuals are starting to tackle the challenges and opportunities made available to them.

And here is where we conclude our three-pronged instructional guide on understanding the ‘wild west' that is Web 3.0.

[FREE] Get Our Best Crypto Trading, Mining & Investing Hacks:

*Action Required* Enter Your Email To Get Insight For Trending Coin News & Reviews

I will never give away, trade or sell your email address. You can unsubscribe at any time.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

five × 4 =