Web3 stack

Blockchain, Smart Contracts, DeFi, NFTs, and the like, are all information technology (IT) or computer science (CS) based. In previous newsletters, we’ve pointed out that developers at web2 companies, for example Meta and Google, were quitting their traditional careers to become builders of web3. But how different is web3 from web2?

The web2 stack consists of application (app) servers, an authentication layer, databases, frameworks, platforms, libraries, and file storage. On the other hand, web3 is the stack of protocols that enable fully decentralized applications (dApps) – so it has different goals than web2.

While some of the apps developed on decentralized tech stacks may simply replace predecessors, new primitives offered by blockchains, such as native digital payments, metaverse, and digital ownership, have enabled a whole new paradigm of apps. Furthermore, the technologies are less well-established and mature compared to web2. The web3 stack can be broken down into several parts:

• Blockchain
• Nodes (infrastructure providers)
• Development frameworks
• File storage
• Off-chain data protocols
• API (indexing & querying)
• Identity
• Oracles

Source: Edge & Node

Blockchain

All web3 applications need an execution environment and security to ensure the immutability, known as the consensus layer. This is what blockchains are known for. There is no single blockchain that is ‘the best’ – instead there are various tradeoffs among them.

Ethereum is the original smart contract platform, with Solidity and Vyper being the preferred smart contract programming languages. They're employed not only on Ethereum, but also on Ethereum layer 2s, sidechains, and even other blockchains like Fantom, Celo, and Avalanche.

Another important concept is the Ethereum Virtual Machine (EVM). EVM is a computation engine that acts like a decentralized computer with millions of executable projects. It’s considered the part of Ethereum that runs execution and smart contract deployment. An EVM compatible chain creates an environment that supports code execution, which is similar to that of the EVM. So, instead of developers building solutions and protocols from scratch, they can replicate the protocols across various chains. Examples of EVM compatible chains are Avalanche, Binance Smart Chain, Fantom, and Polygon.

Nodes (infrastructure provider)

When interacting with a network, an RPC (remote procedure call) is needed. RPC is a means of accessing remote services by making a local procedure. There are 4 ways to do this:

1. Accessing a public RPC endpoint that’s provided by the network. Utilized by network users.
2. Running your own node. Where users don’t trust the network’s public RPC, they can in theory run their own node, allowing them to protect their privacy and bolster security.
   
3. Accessing a node provider as a service, such as Infura, Alchemy, or Quicknode. This is what most applications do, given that the public RPC may not be stable enough to run a dApp.
   
4. Accessing a decentralized node provider as a service, such as Pocket Network. This provides a decentralized alternative and is cheaper in the long run than centralized providers like Infura, Alchemy, and QuickNode. Used by blockchains and dApps.
   

Most decentralized applications run their nodes through node providers, like Infura or Alchemy. This means the degree of decentralization of those applications is not as great as it might appear. A recent example is the MetaMask wallet, which by default uses Infura nodes. On 3 March, Infura ‘accidentally’ blocked users in Iran and Venezuela from using Metamask. The outage was caused by overly broad configurations incorporated as part of its sanctions compliance program, since Infura is a US-based company. Link.

In addition, there’s the risk of centralization within web3 infrastructure. An example of this is Solana’s network. Even though the network is fully decentralized, approximately 35% (Link) of the nodes run on Amazon Web Services (AWS). So, if AWS suffers an outage, the network can suffer a partial one too.

Development frameworks

While we’ve commented before on the lack of maturity of the web3 tech stack, there are some development frameworks that can be seen as best practice for developing an application, such as:

• Hardhat (JavaScript) is an Ethereum development environment. It can compile smart contracts and run them on a development network to test them.
• Truffle Suite (JavaScript) is a collection of tools for building, developing, and testing applications on the EVM. Truffle, Ganache, and Drizzle are the three components.
  
• Foundry (Solidity) is a development environment with the ability to write tests in Solidity instead of JavaScript. Testing in JavaScript brings additional constraints, as it needs to operate one level of abstraction away from what actually needs testing (the Solidity code).
  
• Brownie (Python) is a development and testing framework for smart contracts for Solidity / EVM development. Python is a high-level, general-purpose programming language.

File storage

Over the last decade, cloud storage has displaced legacy, on-premises servers. The global market for cloud storage will reach $137.3 billion by 2025, growing 22.3% per year (Link). Renowned cloud companies include Amazon Web Services (AWS), Alibaba Cloud, Microsoft Azure, and Google Cloud Platform (GCP).

There are two types of data that web3 blockchains consume: available data and retrievable data. Available data may be on the settlement layer, or outside it, but the key criterion is that valuable transactions will be ‘saved’ for posterity. With low-value data, where strict availability is not required, a guarantee of retrievability is often sufficient.

When it comes to blockchain, storing anything from just a few MB size (like an image or video), on-chain is prohibitively expensive, so it’s usually stored in a dedicated file storage system. The most well-known ones are:

• IPFS is a peer-to-peer file system protocol that optimizes for quick retrieval and distribution of content.
• Filecoin focuses on contract-based storage of large data batches. Users pay a network of nodes to store ‘X’ bytes of data, for ‘Y’ amount of time, with ‘Z’ assurances of retrievability. It was built by the same team as IPFS.
  
• Arweave allows permanent data storage – a developer pays Arweave tokens (AR) as a network fee to store data permanently.
  

Off-chain storage

These solutions are similar to how databases are used in a traditional tech stack, but instead they are replicated across a number of nodes on a decentralized network.

• Ceramic network is a decentralized, open-source platform for creating, hosting, and sharing data. It provides a general-purpose decentralized content processing substrate that relies on and extends the IPFS file system and underlying persistence networks, as well as on other open standards in the decentralized ecosystem.
• GunDB is a decentralized, peer-to-peer ecosystem of tools that lets anyone build community-run, encrypted applications, similar to an open source Firebase or a decentralized Dropbox.
  

It’s common for dApps to publish their code on GitHub, which allows anyone to audit or see what’s going on behind the scenes.

API (indexing & querying)

An API (application programming interface) is a software intermediary that allows applications to access data and interact with external software components, operating systems, or microservices. In short, an API delivers a response to a system and sends the system's response back again.

Data on blockchains isn't stored in a manner that can be effectively and readily consumed by other apps or front ends. Blockchains are instead optimized for write operations – so it’s common to hear of innovations centered around transactions per second, block time, and transaction cost. But given blockchain data is written in blocks over time, anything beyond basic read operations can be impossible.

In most applications, features like relational data, sorting, filtering, full-text search, pagination, and many other types of query capability are needed. This is work that databases do in the web2 tech stack. The Graph is a protocol for indexing and querying blockchain data that simplifies this process and provides a decentralized solution. Anyone can build and publish open GraphQL APIs, called subgraphs, making blockchain data easy to query.

Identity

Identity involves a completely different paradigm in web3. Authentication on the web2 is usually dependent on a user's personal data. This information is generally gathered via a form or an OAuth provider who asks the user to hand it over in exchange for access to the application – e.g. users give the app their email address and a password in order to access it. Managing web2 passwords is a chore, and if the password is lost users generally rely on a centralized web2 company to recover it. The process is often tedious and can take weeks.

In web3, identity revolves exclusively around the concept of wallets. Users are now owners and custodians of their assets, which they can hold in wallets. At a basic level, a common requirement is dApps requesting access to the user’s wallet. By accessing the wallet, dApps can verify the user is in the right network, their fund balance, and also check against a blacklist – at this stage, dApps cannot access the funds.

• Widely used wallets are MetaMask and TrustWallet for Ethereum and EVM compatible chains.
• Wallets can also receive names. This is the value proposition of Ethereum Name Service (ENS), a distributed, open, and extensible naming system based on the Ethereum blockchain. ENS’s mission is to translate human-readable names like 'alice.eth' into machine-readable identifiers like Ethereum addresses, other cryptocurrency addresses, content hashes, and metadata.
  

There’s a whole new social layer being built and enabled by web3. In the early web2 era there were isolated social graphs for each social application – people had to register and re-add friends on every site. The optimal solution was to consolidate all the relationships into one app, such as Meta. Meanwhile, data has become the most valuable resource in the world, with Big Data already a $274 billion industry: 3% of world GDP (Link).

Decentralized social graphs alter the power imbalance between user and platform. Although applications can be proprietary and fragmented, the data that populates them can be shared across protocols. Notable examples of social graphs on web3 are:

• Lens Protocol, a composable and decentralized social graph. It’s ready for developers to build on so they can focus on creating good experiences, not scaling their users.
• CyberConnect, which aims to create a decentralized social graph protocol for web3 social networks and the metaverse. Its mission is to return the ownership and utilities of social graph data to users while providing an infrastructure all web3 developers can integrate and build upon.
  

Oracles

Oracles provide dApps access to real world data and external systems from within a smart contract. The majority of financial applications require access to off-chain data and events – such as the price of Bitcoin – making oracles indispensable to DeFi.

• Chainlink is a decentralized oracle that allows users to access real world data and perform off-chain computations while retaining the security and dependability of a blockchain.
• Flux is a cross-chain oracle that provides smart contracts with access to economical, secure data feeds.
  
• Band Protocol is a cross-chain data oracle that aggregates real world data and APIs, and links them to smart contracts.
  

Source: Arcane Research

Source: Polynya Blog

Looking at the big picture

Unlike web2, users of web3 enjoy full transparency of associated services thanks to smart contracts being publicly available. Robinhood, for example, attracted many retail investors with its commission-free trading, but few of them knew that one of their main revenue sources was payments for order flow (PFOF). Or take traditional banking where cash deposits are automatically used to make loans: in web3, users have an active choice whether to release their cash deposits for lending and earning interest. Similar cases exist in the core web2 business model: the sale of user data. For example, to use a Chrome browser every user must consent to Google selling their data, and with no cut in return. The Brave browser, on the other hand, allows users to choose whether to share data and see ads in return for a slice of the ad revenue – or not share data and instead surf ad free. Overall, web3 increases transparency and gives users an active choice over whether their assets or data can be used.