Day 2: Blockchain Basics | From Centralized DB to Distributed State Machine
Source: Dev.to
Introduction
As a backend engineer with nearly a decade of experience, I am accustomed to distributed systems, micro‑services, and ACID transactions. On my first day entering Web3, I realized that the core shift isn’t about the language (Solidity vs. Go/Java) but about a fundamental change in the underlying paradigm of data storage and trust.
Web2 vs. Web3: A Backend Perspective
| Dimension | Web2 | Web3 |
|---|---|---|
| Data Consistency | Relies on Raft/Paxos or centralized master‑slave sync | Relies on consensus mechanisms (PoW / PoS) |
| Source of Trust | Trust in DBAs or cloud providers | Trust in math, algorithms, and open‑source code |
| Write Operations | Low latency, nearly free | High latency, requires gas fees (to incentivize nodes) |
| Transparency | Internal visibility; data can be modified/rolled back | Globally transparent; data is immutable |
My Understanding: If a Web2 database is like a private Excel spreadsheet within a company, then a blockchain is like a giant ledger placed in a busy town square—everyone can watch it, and you can only write to it with a permanent pen. It can never be erased.
The Pain Point in Web2
Backend developers often deal with third‑party integrations and reconciliation issues. When two systems (e.g., Bank A and Bank B) interact, each maintains its own database and then runs tedious reconciliation processes to ensure data consistency.
The Web3 Solution
Everyone operates directly on the same state machine. Because the ledger is unique, transparent, and immutable, we no longer need expensive “trust costs” or “reconciliation costs.”
The Core Challenge — Trust & Consensus
In Web2 systems, trust is typically centralized. You trust the data in a database because you trust the company operating it, the trained DBAs, and the firewalls.
In the permissionless environment of Web3, participants are anonymous to one another. How do we reach agreement?
Consensus in Distributed Systems
| Perspective | Typical Algorithms | Assumptions |
|---|---|---|
| Web2 | Raft, Paxos | Nodes may go offline, but they are not assumed to act maliciously. |
| Web3 | PoW, PoS, BFT variants | Must handle the Byzantine Generals Problem – nodes can be compromised and act maliciously (e.g., double‑spending attacks). |
Consensus mechanisms are a set of game‑theory rules that ensure, as long as the majority follows the rules, the ledger remains secure even in the presence of bad actors.
Trust Models
| Model | Analogy | How Trust Is Established |
|---|---|---|
| Traditional Trust (Proof of Authority) | Banking services – you trust the official seal. | An intermediary (the bank) endorses transaction authenticity. |
| Web3 Trust – Proof of Work (PoW) | Physical energy – you must control > 51 % of total computing power. | Attack cost (electricity, hardware) far exceeds potential gain. |
| Web3 Trust – Proof of Stake (PoS) | Economic interest – you must stake a large amount of tokens. | Misbehaviour leads to slashing (confiscation of the stake). |
My Understanding: Blockchains do not eliminate trust; they shift trust from “people/institutions” to “economic costs and mathematical algorithms.”
The 51 % Attack
If an entity controls more than half of the network’s hash power (PoW) or stake (PoS), it can modify unconfirmed transactions, causing a rollback. For massive networks like Bitcoin or Ethereum, the cost of launching such an attack reaches billions of dollars, making the ledger logically immutable.
Problem Solved: Uncertainty & Friction (The “Unstuck” Moment)
- Eliminating Settlement Latency – Traditional finance cross‑border transfers take 3‑5 days because countless intermediaries perform manual “trust reconciliation.”
- Irrevocable Contracts – Once consensus is reached, the transaction is written into the permanent ledger. No CEO or government can unilaterally withdraw a confirmed on‑chain transaction.
Where I Got Confused and How I Got Unstuck
My Confusion
Who deploys all these nodes? What if they all go down?
As a backend engineer, I’m used to servers being managed by a centralized DevOps team. In a blockchain with thousands of nodes, who is actually deploying them? Without a central authority, how can we ensure the network doesn’t collectively crash?
How I Got Unstuck
- Decentralized Operators – Nodes are deployed by independent individuals or organizations (miners or validators). Anyone with the right hardware and software can join the network.
- Incentive‑Driven Maintenance – No one maintains the network out of pure kindness; they do it for token rewards. As long as the network processes transactions and issues rewards, participants are economically motivated to keep their nodes online and healthy.
Node Incentives
Nodes earn gas fees and newly minted tokens.
Redundancy over “Single Point of Failure”
Blockchain doesn’t guarantee that a single node won’t fail; it guarantees the high availability of the entire network. While a Web2 service might go down if a specific AWS region has an outage, a blockchain stays alive as long as even a handful of nodes are running somewhere in the world.
Good Resources for Learning
- Cyfrin – a good website has all the knowledge about Web3, good for beginners.