The Paradigm Shift — From Centralized Databases to Decentralized Ledgers
As a backend engineer with nearly a decade of experience, I am accustomed to distributed systems, microservices, and ACID transactions. However, on my first day entering Web3, I realized that the core shift isn't about the language (Solidity vs. Go/Java), but rather a fundamental change in the underlying paradigm of data storage and trust.
1. Core Concept: What is Blockchain, Really?
In Web2 backend architecture, we talk about Databases. Whether it is MySQL or MongoDB, there is always an ultimate "administrator" who possesses CRUD (Create, Read, Update, Delete) permissions over the data.
In Web3, a blockchain is essentially a globally shared, deterministic state machine.
- No more CRUD: On a blockchain, you only have "Read" and "Append" (changing state via Transactions).
- Decentralized Network: There is no centralized AWS or IDC. Data exists across thousands of Nodes, each holding a complete copy of the ledger.
2. Mental Model: Web2 Database vs. Web3 Ledger
To better understand this, I have constructed a comparison model from 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.
3. Why Do We Need It? (The "Why")
As backend developers, we frequently deal with "third-party integrations" and "reconciliation" issues.
The Pain Point: In Web2, when two systems (e.g., Bank A and Bank B) interact, they must each maintain their own databases and then use 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. However, in the permissionless environment of Web3, where participants are anonymous to one another, how do we reach an agreement?
1. Core Concept: What is Consensus?
In Distributed Systems, consensus refers to how all nodes in a network reaching an agreement on a specific state.
Web2 Perspective: We commonly use algorithms like Raft or Paxos to solve "High Availability" issues. We assume nodes might go offline, but we generally do not assume nodes will "intentionally act maliciously."
Web3 Perspective: Blockchains face the much more extreme Byzantine Generals Problem. We must account for not only node crashes but also nodes being compromised by hackers to intentionally send fraudulent data (such as Double Spending attacks).
Consensus Mechanisms are a set of game-theory rules. they ensure that as long as the majority follows the rules, the ledger remains secure, even if there are bad actors in the network.
2. Mental Model: From "Seal & Stamp" to "Hash Power/Staking"
To understand the transformation of trust, we can build this model:
Traditional Trust (Proof of Authority): Similar to banking services, you trust the official seal. The bank, as an intermediary, endorses the authenticity of the transaction.
-
Web3 Trust (Proof of Work / Proof of Stake):
- PoW (Proof of Work): Trust originates from "physical energy." To act maliciously, one must possess over 51% of the network's total computing power, which requires astronomical electricity costs. The cost of an attack far outweighs the potential gain.
- PoS (Proof of Stake): Trust originates from "economic interest." To act maliciously, you must stake a large amount of tokens (e.g., ETH). If the system detects a violation, your collateral is "slashed" (confiscated).
My Understanding: Blockchains do not eliminate trust; they shift trust from "people/institutions" to "economic costs and mathematical algorithms."
3. 51% Attack: Where is the Security Boundary?
As engineers, we always focus on system boundaries. The so-called 51% Attack is the most famous security vulnerability in blockchain:
If an entity controls more than half of the network's hash power or stake, they can indeed modify transactions that haven't been fully confirmed, causing a "rollback."
The Reality: For massive networks like Bitcoin or Ethereum, the cost of launching a 51% attack reaches billions or even tens of billions of dollars. This "extremely high cost of malice" constitutes logical Immutability.
4. Problem Solved: Uncertainty & Friction (The "Unstuck" Moment)
Why do we go to such lengths for consensus?
Eliminating Settlement Latency: In traditional finance, cross-border transfers take 3-5 days because countless intermediaries are performing 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
Who deploys all these nodes? What if they all go down?
My Confusion: 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 just collective 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: Nobody maintains the network out of pure kindness. They do it for Token Rewards. As long as the network processes transactions, 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 knowledges about web3, good for beginner.
Top comments (0)