At Alchemy, we define Web3 as a decentralized internet ecosystem built on blockchain technology.
As developers and builders first and foremost, we understand that decentralization often evokes the notion of a fragmented tech stack. And while it is true that Web3 is still nascent and rapidly evolving, we have found that its underpinning building blocks have begun taking shape.
To better understand the inner workings of Web3 and the decentralized internet, let’s dive right into the Web3 development stack.
Web3 Stack Overview
On a high level, building any Web3 application requires an in-depth understanding of blockchain networks, Web3 infrastructure, and Web3 development environments.
Web3 Network Layer
At the base of the Web3 technology stack is the blockchain network layer. While Web2 applications rely on centralized databases, Web3 applications are built on top of blockchain architectures for trustless and permissionless access.
When picking a blockchain network for building decentralized applications (dApps), developers have two primary choices: Ethereum Virtual Machine (EVM)-compatible blockchains and non-EVM-compatible blockchains.
Historically, Ethereum has served as the primary framework for Web3 development, where its virtual environment (i.e. its Ethereum Virtual Machine or EVM) stores key information like accounts and balances. Ethereum’s Virtual Machine also stores a machine state, which is able to change with each new block according to a set of predefined rules laid out by the EVM. Most importantly for developers, the EVM provides a framework for the storage and execution of smart contracts which allows developers to program on-chain logic.
With the rise of Ethereum’s blockchain and the EVM, many different networks aiming to solve Ethereum’s scalability limitations or expensive transaction costs have opted to develop frameworks fully compatible with the EVM. This means EVM-compatible chains all share the same software layer—namely Solidity—that runs smart contracts.
EVM-compatible blockchains allow developers to leverage all the same tools, documentation, and communities built specifically for EVM chains, saving time and money.
EVM Blockchain Examples
- Ethereum - Original EVM smart contract platform
- Polygon - Ethereum sidechain
- Arbitrum - Layer 2 blockchain using Optimistic rollups and multi-round fraud proofs
- Optimism - Layer 2 blockchain using Optimistic rollups and single-round fraud proofs
- Hermez - ZK rollup Ethereum Layer 2 network managed by Polygon
- ZKSync - ZK rollup Ethereum Layer 2 network using SNARKs
- Starknet - ZK rollup Ethereum Layer 2 network using STARKs
- Avalanche - EVM-compatible Layer 1
- Cronos - EVM-compatible Layer 1
3 Best Web3 Development Environments
When selecting a blockchain network upon which to build on a dApp, Web3 developers should consider the depth and breadth of developer tooling that is available. Fortunately, EVM-compatible chains benefit from years of Ethereum development and have a host of battle-hardened options when it comes to development environments.
- Truffle - the primary development environment, testing framework, and deployment pipeline
- Ganache - allows developers to quickly create a local blockchain
- Drizzle - an assortment of frontend libraries to connect frontend components with smart contracts
An alternative to Hardhat or Truffle as a Python-based framework for EVM development, Brownie offers a full suite of Web3 developer tools primarily built off of the web3.py package for compiling, testing, and deploying dApps.
More recently, developers have started building more dApps on blockchains that do not follow the Ethereum framework and are therefore not EVM-compatible.
Non-EVM network engineers argue that EVM chains are too constrained by the Ethereum framework and instead choose to innovate by designing new structures. Generally, non-EVM blockchains are designed with data and transaction scalability from the get-go and allow for high transactions per second (TPS).
Non-EVM Blockchain Examples
- Flow - Layer 1 using Cadence, Flow's native resource-oriented programming language
- NEAR - Layer 1 using Rust or Assemblyscript for smart contracts
- Solana - Layer 1 using Rust C, C++ for smart contracts
- Terra - Layer 1 using Rust for smart contracts
Non-EVM Blockchain Development Environments
While there are less established development environments for non-EVM chains, some networks have begun spearheading developer tooling for their respective chains
Flow gives developers the ability to test Cadence smart contracts for bugs with a native Visual Studio Code Extension, one of the most popular IDEs (Integrated Development Environments).
Another example of a Non-EVM development environment is Anchor which allows for building and testing Solana contracts with the similar feel of Solidity and Truffle. Overall, Anchor’s environment lowers the barrier to Rust and Solana development.
What Blockchain Network Should I Use?
With individual blockchains often having unique architectures and consensus mechanisms, they will inevitably be better optimized for particular use cases over others. As such, we are firm believers in a multichain Web3 future.
The EVM framework is an incredibly rich environment given its growing diversity of interoperable tooling. In addition, EVM-compatibility provides users and developers alike with a more fluid process for moving liquidity through cross-chain dApps and provides a familiar user and developer experience. For early developers and new protocols, we believe there is a compelling argument for developing around EVM-compatible blockchains to take advantage of existing tooling, infrastructure, and developer documentation.
That being said, we also recognize the niche capabilities of non-EVM blockchains for more experienced developers, their growing community base, and increased development in tooling support for early developers.
Blockchain Interaction Layer
After selecting a blockchain network, the next step in the Web3 stack is the blockchain interaction layer. This layer allows developers and users to read and write data to the blockchain.
If you’re not familiar with how a blockchain works, here’s a quick recap.
- The blockchain is made up of blocks of data.
- Blocks are stored on distributed nodes.
- Each node in a blockchain serves as a “mini-server” that allows its operator to read/write blocks of data.
- Any blocks added to the blockchain must be propagated across all nodes on the network to be in sync.
When thinking about the data access layer within the Web3 framework, remember that on-chain storage is the standard given that it is inherently immutable and allows any public individual to view/verify it.
Data providers, like block explorers, are a key part of the blockchain interaction layer. For starters, they provide a window into the lower network layer and serves as an online resource for real-time and historical data retrieval about transactions, address balances, gas fees and more. Block explorers are commonly used for looking up key details of a payment, determining the status of different transactions or simply understanding aggregate trends for blockchain usage. Data providers give the public the ability to read and interpret blockchains.
Web3 Infrastructure Challenges
However, without the proper infrastructure requirements, accessing and interacting with blockchain data can be quite difficult.
Because writing data directly on-chain is not cost effective, Web3 developers use EVM chains’ built-in logging capability so that smart contracts can “print” information on-chain in a searchable, cost-efficient manner via Solidity events. While logging for cheaper storage and is the most popular way for reading and writing to the blockchain, it requires a robust blockchain interaction layer to ensure that developers are able to capture events as they are emitted without fail.
Running a Node vs. Using a Node Service Provider
Historically, use of the blockchain interaction layer required running a self-hosted, self-maintained node. This is an expensive and time-consuming process, with an average of $86k/year in costs just to run a single Ethereum node. Instead of building protocols and dApps, developers found themselves spending their engineering resources managing bugs, regressions, disk issues, CPU traffic spikes, etc. from nodes.
The cost of running your own node led to the creation of Alchemy. At its core, Alchemy exposes a suite of APIs for developers to interface with blockchains without having to manage nodes.
As a firm believer in a multichain Web3, Alchemy’s API suite offers multichain support across Layer 1s including the Ethereum network, Layer 2s including Arbitrum and Optimism, sidechains including Polygon, and non-EVM-compatible L1s such as Flow within a single familiar API framework.
Ultimately, Alchemy allows blockchain developers to have reliable and scalable access to the entire Web3 network layer, allowing them to focus on building up the Web3 stack.
Web3 Presentation Layer
In many ways, the Web3 presentation layer closely mirrors many aspects of Web2 development.
For the creation and development of frontend components, many developers turn to the time-tested React.js library. With a healthy number of developers and a Web3 community following, it is the de facto standard for Web3 frontends.
One area where Web2 and Web3 frontend stacks diverge is the specific libraries used to interact with blockchain data.
When interacting with the data access layer, Web3 dApps tend to use Ether.js or Web3.js instead of the more typical HTTP request libraries like Axios and Fetch. In particular, both Ethers.js and Web3.js natively support remote procedure calls (RPC) to blockchain nodes hosted on the blockchain interaction layer, enabling more seamless integration into a developer’s Web3 tech stack and reading and writing data to the blockchain.
How to Choose Between Ether.js and Web3.js
When deciding between Ethers.js and Web3.js, there are a few points to consider.
Ethers.js is a more lightweight, developer-friendly library with robust documentation. While many early developers and veterans alike developed dApps via Ether.js, it is maintained by a few people, limiting the development of the library.
Another alternative to Web3.js is Alchemy Web3, a fork with additional API methods, upgraded websocket support, and automatic retries already enabled allowing for easier developer adoption.
While blockchains provide a medium for decentralized state management, smart contract storage/execution, and transaction value, higher level applications require additional components. For frontend cotent like images, videos, and GIFs, blockchain storage is prohibitively expensive and inefficient. Decentralized storage fills in this gap.
One solution is the Interplanetary File System, or IPFS, a distributed network made up of nodes where individual people store and share files, websites, applications, and data. With the rise of NFTs, IPFS usage has surged and often serves as the underlying storage medium for NFT media assets.
Another popular decentralized storage solution is Arweave which aims to incentive individuals to store data permanently. With the Arweave network, miners provide storage space in exchange for tokens and the protocol itself ensures that the data stored remains correct and in-consensus across all nodes.
Web3 Application Layer
In the context of Web3, the application layer ranges across DeFi, NFTs, Identity & Authentication, Data & Analytics and many other exciting dApp categories. Altogether, these decentralized Web3 applications include some of the biggest native Web3 companies like OpenSea, Uniswap, and and Aave.
As developers, this is often the most interesting layer to build on. Different decentralized applications can be mixed and matched together, combining powerful primatives into new, complex products.
The application layer is what primarily allows public consumers (many of whom may not fully understand the intricacies of Web3 development) to easily interact with an intuitive frontend. Ultimately, user-friendly frontends gives the public the power to leverage the decentralized internet in their everyday lives.
As Web3 grows from its current state to maturity, there will surely be paradigm shifts, new Web3 infrastructure tools, and plenty to learn. While it may seem daunting to start developing with the Web3 tech stack given its constant changes, the layers defined within the Web3 stack are here to stay.
Join a growing movement of developers—both Web3 natives and fellow travelers from Web2— and together we can build the future!