Summer’s over — what’s your move? Join Pro for 50% off using code [MAKEITHAPPEN](https://www.codecademy.com/checkout?periods=year&plan_id=proGoldAnnualV2&discountCode=MAKEITHAPPEN)


In this lesson, we’ll look at the specific tools we might use to build a Decentralized App (Dapp).



Blockchain Infrastructure: Web3 Stack

**Decentralized data layers** provide a similar function to centralized data layers, but rather than a single entity managing requests for data, these have methods of decentralizing this process. Decentralized data layers have multiple nodes that provide the blockchain data for developers to pull. They also have a consensus mechanism in place to incentivize proper data and punish false data.

These are some options for interacting with the blockchain from a decentralized service:

- [KYVE Network](https://www.kyve.network/)
- [The Graph](https://thegraph.com/en/)
- [Pocket Network (POKT)](https://www.pokt.network/)

We can set up our code to call one of these APIs when we need certain data in our dapp.

Decentralized Data Layer

The **centralized data layer** is a single company or entity that will host endpoints on which we can query blockchain data and send blockchain data. Unfortunately, they add a level of centralization to our dapp that we may not want, but the developer experience is usually great, and it’s perfect for getting up and running.

The following list of tools are similar, it’s just a matter of preference on which you want:
- [Stacks API](https://docs.stacks.co/docs/blockchain/stacks-blockchain-api)
- [Quicknode](https://www.quicknode.com/)
- [Infura](https://infura.io/)
- [Ankr](https://www.ankr.com/)

Centralized Data Layer

What if our dapp relies on some set of data that exists in the real world? How can we access data and ensure it is real and accurate? This is where oracles come in. **Oracles** are entities that provide external data that we can use in our smart contracts.

For example, let’s say we're building a decentralized betting dapp, and we need to write a smart contract that handles the bets. We might need to access external data that provides information on certain events to determine the outcome of the bet. An oracle allows us to access that data in our smart contract so that we can trustlessly use external data within our on-chain smart contracts.

Two examples of popular oracle services you can use are:

- [RedStone](https://redstone.finance/)
- [Chainlink](https://chain.link/)

Oracles

This is the foundational layer. _The blockchain is what makes web3 decentralized_. Ultimately, our smart contracts will live on whatever blockchain we choose to build on. 

It’s important to consider the use case of our dapp and the different tradeoffs each chain offers:
- **Security**: If it’s important for our smart contracts to live on an extremely _secure_ blockchain, we might choose to use [Stacks](https://www.stacks.co/), since it has final settlement on [Bitcoin](https://bitcoin.org/en/).
- **Speed**: If _speed_ is our top priority, and we're willing to sacrifice some decentralization, we might choose to use [Solana](https://solana.com/).
- **Large Community**: If you need the most _robust_ and _abundant dev tooling_ with the _largest community_ behind it, we might choose to use [Ethereum](https://ethereum.org/en/).

Ultimately, each chain has its own strengths and weaknesses, and the choice will be dependent on a multitude of factors depending on our use case.

Blockchain Layer

Blockchains have **mainnets**, the live blockchain, and **testnets**, which are used for development purposes. Even though testnets are just for development, they are still public and distributed. This means developing locally and needing to deploy your contract any time you want to change anything or during the development process would make development slow and cumbersome. 

We need a way to mock up a blockchain environment locally without having to deploy to a testnet every time we make a change. So, we have blockchain development environments, which will provide tooling to make writing smart contracts easier and provide local mock chains for us to build on. They allow us to have a fully functioning chain running on our local machine! This is similar to running a local server in the web2 world.

Some options for development environments are:

- [Clarinet](https://github.com/hirosystems/clarinet)
- [Hardhat](https://hardhat.org/)
- [Anchor Protocol](https://www.anchorprotocol.com/)


Blockchain Development Environment

Once we decide which chain we want our smart contracts to live on, we need a way to pull data from that chain. This is where the indexing and querying layer comes in. 

What do we mean by indexing and querying? To build dapps that use data from the blockchain, we need a reliable, developer-friendly way to get that data. Reading data directly from a blockchain is a complex process, we should use dedicated, already-existing tools.

If we use a tool like [Infura](https://infura.io/), for example, we are provided with a REST endpoint that we can use to run data queries on the blockchain. If we want to monitor the chain for certain activities, like NFT purchases, we can do this by using another one of these tools. There are both centralized and decentralized methods of querying and posting blockchain data.


Indexing and Querying


In this lesson, we’ll look at the specific tools we might use to build a Decentralized App (Dapp). We’ll start off by going over the web3 stack in general and then walk through some specific tooling for the Ethereum, Stacks, and Solana blockchains.

### From web2 to web3

In our sample web2 app, we have the following components:

- Front End
- API
- Authentication
- Database
- File Storage
- Hosting
- Payments

Each of these has their own web2 tools, but we need to change things a bit when looking at web3 dapps. Let’s look at each component of the decentralized, web3 version of our app and compare.

A lot of these ideas are borrowed from [Nader Dabit’s excellent breakdown of the web3 stack](https://edgeandnode.com/blog/defining-the-web3-stack/). We’ll take a ground-up approach to this, first starting with the blockchain itself and moving all the way through the stack, covering each essential piece along the way.

A gif showing a block that is waiting to be validated by a large network.

Introduction

In the web2 world, we authenticate with usernames and passwords. In the _decentralized_ web3, world we authenticate using cryptography and public/private key pairs. The user-facing mechanism we use to do that is called a wallet. A **wallet** is a piece of software that allows us to create an address on a blockchain and then authenticate using our private key to access it.

This address is how we interact with web3 dapps. This address can be thought of as a user account, except: 
- It’s shared across all dapps that are on the same protocol.
- The data belongs to the wallet owner, us, not the platform. 

Using this wallet is what allows users to interact with our dapp! They are authenticated and can send transactions to the chain itself.

Some options for this are:

- [Hiro Web Wallet](https://wallet.hiro.so/wallet/install-web)
- [Metamask](https://metamask.io/)
- [Phantom](https://phantom.app/)


Wallets and Identity Management

For the most part, the front-end framework (Next, Vue, Remix, etc.) will stay the same, but we will utilize different front-end libraries to interact with our chain. These front-end libraries allow us to hook into our front-end app using something like JavaScript, and they will utilize our wallet to broadcast transactions to the chain on our users’ behalf. They also allow us to more efficiently query data from the chain depending on the library and API protocol we are using.

Some options for this are:

- [Stacks.js](https://github.com/hirosystems/stacks.js)
- [Ethers.js](https://docs.ethers.io/v5/)
- [Web3.js](https://web3js.readthedocs.io/en/v1.8.0/)


Front-End Libraries

Not all data should be stored on-chain! This is a topic of endless debate and discussion, but blockchains have a very specific use case and are meant to be permanent, historical ledgers of transactions. Because of their distributed nature, it is expensive to store data on a blockchain. _They are not meant to replace traditional database storage_.

This is an important topic in web3 development, so let’s look at the use cases of web3 development. _The goal is to provide software that is distributed, immutable, and censorship/tamper-resistant_. It’s important to remember that every state change that is written to the blockchain has to be paid for. It’s a common misconception that all of our data needs to be stored on-chain in order for it to be trustless and immutable, but this is not the case. It’s important to carefully consider the amount and type of data we want to store on-chain and look at the most effective way to do so, even if it takes a little more effort and clever engineering.

Let’s look at our fictional app here. One potential set of data we might have is product information. For each product, we might need to store the:
- `name`
- `description`
- `price`
- `image`

Do we want to store all that in a smart contract where every byte of data is paid for by the user? Definitely not. That would get very expensive very quickly! What happens if we want to modify our data structure? We would have to perform a complex contract migration just to add a simple field like a `product_id`.

This is where some of the misconceptions around of web3 come in - people imagine a decentralized Twitter where they have to pay a transaction fee and wait forever anytime they post or respond to a tweet, but _this is not a pragmatic approach to web3 development_!

What should we do instead? What we really care about here is trustless data integrity. We want to ensure that our data can’t be tampered with and that it is transparently verifiable. What we could instead do is store the data off-chain in either a traditional database or in a decentralized solution. Then, we store a hash of that data on-chain in our smart contract. This way we are guaranteeing the validity of our data on-chain without having to store the data itself. Then, in our app, we compare the hash with the hash stored on-chain to verify any changes.

We can combine this with a wallet-based authentication method. We submit a transaction, containing our address and data hash, to our smart contract, then another part of our app submits the actual data change to our database simultaneously. Because our authenticated address is the only one that could have authorized the transaction on-chain, we can know whether or not our data was tampered with. By utilizing a decentralized data storage solution like Gun, we get the best of both worlds and get decentralized data storage without the expensive inefficiencies of writing that data to the chain.

Some options for this are:

- [Gun](https://gun.eco/)
- [Arweave](https://www.arweave.org/)
- IPFS
- [Gaia](https://docs.stacks.co/docs/gaia/)
- [Ceramic Network](https://ceramic.network/)


Off-Chain Data Storage

With all that in mind, let’s look at how we might build our fictional app using this stack.

1. First, we need to choose what chain we want to build on. Let’s say we choose to build on Stacks. 
2. The next thing we would need to do is decide how we want to access the data from the blockchain. In this case, we’ll utilize the Stacks API provided by Hiro.
3. Next we’ll get set up with our Clarinet development environment so we can spin up a local chain.
4. And we’ll need to integrate our app with the Hiro Web Wallet for authentication and identity management.
5. We’ll also have some data that we don’t necessarily want on-chain, so we’ll set ourselves up with [Gun.eco](http://Gun.eco) for our decentralized off-chain data storage.
6. Next we need to choose a client library, and in this case we’ll choose Micro-Stacks and build our actual front end using Remix.
7. Finally, we need a way to host our dapp. We can go the traditional route of centralized hosting using something like Vercel or Netlify. Or, if we want our dapp, to be 100% decentralized we can deploy it to Arweave or IPFS.

This process is still relatively involved, and this is the basic process you’ll go through each time you want to build a new dapp. You’ll need to consider which pieces you want decentralized and which you want centralized, what should be on-chain and off-chain, and what the right tool for each job is. As you continue to explore the web3 ecosystem and practice building more dapps, you’ll start to both discover new tools and learn which are best for which task.

A gif showing a block that is waiting to be validated by a large network.

