Web 3 Architecture

Introduction

In web 3, The backend logic is implemented via smart contracts that will be later deployed to shared decentralized network ****(blockchain network). So backend resides in a peer-to-peer network that everyone can contribute by matching some criteria (ex. owning and locking cryptocurrency in order to vote the changes or make a proposal to the program). But how the front end works then?

Every frontend must connect to a ‘node’ which is a machine that has connection to blockchain Since making a node is cumbersome, many use third party services such as Infura/Metamask. This node will be able to make requests that make update to existing blockchain using what is called smart contracts.

In a nutshell, this is how web 3 works:

1. All data and backend logic are stored in blockchain network, a peer to peer transparent state machine.
2. Frontend will need to connect to a node in the network to access the blockchain using provider/signer
3. Every action that is changing a state within the blockchain is called transactions.
4. Transactions can only be initiated by user, but can be processed by smart contracts, which is an interaction code (i.e backend) within the blockchain.
5. Transactions is only valid if it’s ‘mined’. which incur a cost called ‘gas fee’
6. After a request is being processed by the smart contract, the smart contract can return an event to the node.
7. The node than relay back the event to the provider/signer, which in turn relay the event to the frontend.
8. In many cases, the data is stored on external peer to peer database to reduce cost

Basic Building Blocks

Basic building blocks of web 3:

• Blockchain (smart contract, EVM in etherium, blocks)
• Nodes → A connection to the blockchain
• Provider/ Signer → A pipe or connection to a node, usually comes in with a wallet as metamask.
• Peer to Peer database
• Front-end

The main frontend architecture in the case of DApp is focused on communication with smart contracts (decentralized programs). And it will differ from the common frontend-backend communication.

When we want to interact with the data and code on a blockchain, we need to interact with one of nodes in a blockchain network. This is because only node will have direct interaction with blockchain. In the case of ethereum blockchain network, node will make a request for transaction to the EVM (Ethereum virtual machine). A miner will then execute the transaction and propagate the resulting state change to the rest of the network.

Many DApps uses provider as connection to a node. This node will in turn interact with blockchain. Every Ethereum provider implements a JSON-RPC specification. This ensures that there’s a uniform set of methods when frontend applications want to interact with the blockchain.

Once you connect to the blockchain through a provider, you can read the state stored on the blockchain. But if you want to write to the state, there’s still one more thing you need to do before you can submit the transaction to the blockchain, “sign” the transaction using your private key, so that node can relay the transactions. This is where the provider is not enough, you need a signer. Otherwise, the nodes wouldn’t accept the transaction.

Metamask stores a user’s private keys in the browser, and whenever the frontend needs the user to sign a transaction, it calls on Metamask to privde a signer instead of provider.

Keep in mind that, with Ethereum, the user pays every time they add new data to the blockchain. That’s because adding a state to the decentralized state machine increases the costs for nodes that are maintaining that state machine. So asking users to pay extra for using your DApp every time their transaction requires adding a new state is not the best user experience. One way to combat this is to use a decentralized off-chain storage solution, like IPFS or Swarm

.