Blockchain Architecture Guide: Consensus, Layers, and When You Actually Need It

Blockchain is one of the most misapplied technologies in modern software. Teams reach for it when a Postgres database would suffice, or avoid it when decentralization is genuinely needed. This guide covers blockchain architecture from fundamentals through advanced scaling patterns — and helps you decide when it actually belongs in your stack.

Blockchain Fundamentals#

At its core, a blockchain is an append-only distributed ledger. Every node in the network holds a copy of the data, and cryptographic hashing links each block to its predecessor.

Block N-1                Block N                 Block N+1
┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│ Hash: 0xA3  │◄────────│ Prev: 0xA3  │◄────────│ Prev: 0xF7  │
│ Txns: [...]  │         │ Hash: 0xF7  │         │ Hash: 0x2B  │
│ Nonce: 4821 │         │ Txns: [...]  │         │ Txns: [...]  │
└─────────────┘         └─────────────┘         └─────────────┘

Key properties:

• Immutability — once written, data cannot be altered without invalidating subsequent blocks
• Decentralization — no single party controls the ledger
• Transparency — all participants can verify the full transaction history
• Byzantine fault tolerance — the network functions even when some nodes act maliciously

These properties come at a cost: throughput, latency, and storage efficiency are all worse than centralized databases.

Consensus Mechanisms#

Consensus is how a distributed network agrees on the current state. The mechanism you choose defines your chain's security model, throughput, and energy profile.

Proof of Work (PoW)#

Miners compete to solve a computationally expensive puzzle. The first to find a valid hash earns the right to propose the next block.

• Security: Extremely high — attacking requires 51% of total compute power
• Throughput: Low (Bitcoin: ~7 TPS, Ethereum pre-merge: ~15 TPS)
• Energy: Massive consumption
• Finality: Probabilistic — transactions become "more final" with each subsequent block

Proof of Stake (PoS)#

Validators lock up tokens as collateral. The protocol selects validators to propose blocks based on stake size and randomization. Misbehavior results in slashing (loss of staked tokens).

• Security: Economic — attacking requires acquiring a large share of total staked value
• Throughput: Higher than PoW (Ethereum post-merge: ~30 TPS at L1)
• Energy: Orders of magnitude lower than PoW
• Finality: Can be deterministic with proper design

Practical Byzantine Fault Tolerance (PBFT)#

A leader-based protocol where nodes go through pre-prepare, prepare, and commit phases. Tolerates up to f Byzantine nodes in a 3f+1 network.

• Security: Strong with known validator sets
• Throughput: High for small networks, degrades with O(n²) message complexity
• Energy: Minimal
• Best for: Permissioned/consortium chains (Hyperledger Fabric)

Delegated Proof of Stake (DPoS)#

Token holders vote for a fixed set of delegates who produce blocks. Faster than PoS but more centralized.

• Security: Depends on delegate honesty and voter participation
• Throughput: Very high (EOS historically claimed 4,000+ TPS)
• Tradeoff: Smaller validator set means higher centralization risk

Consensus Comparison:
                PoW        PoS        PBFT       DPoS
Throughput      Low        Medium     High*      High
Energy          Extreme    Low        Minimal    Low
Decentralization High      High       Low        Medium
Finality        Prob.      Deter.     Deter.     Deter.

* Degrades with network size

Smart Contracts#

Smart contracts are deterministic programs deployed on-chain. They execute automatically when conditions are met, removing the need for trusted intermediaries.

Architecture considerations:

• Immutability — deployed contract code cannot change (use proxy patterns for upgradeability)
• Gas costs — every computation costs fees, so optimize aggressively
• Composability — contracts can call other contracts, enabling DeFi "money legos"
• Attack surface — reentrancy, integer overflow, and oracle manipulation are common vulnerability classes

// Simplified escrow pattern
contract Escrow {
    address buyer;
    address seller;
    uint256 amount;
    bool delivered;

    function confirmDelivery() external {
        require(msg.sender == buyer);
        delivered = true;
        payable(seller).transfer(amount);
    }
}

Design smart contracts as minimal state machines. Keep logic simple, push complexity off-chain, and audit ruthlessly.

Layer 1 vs Layer 2#

Layer 1 (L1) is the base chain — Ethereum, Bitcoin, Solana. Layer 2 (L2) solutions execute transactions off the main chain but inherit its security.

┌──────────────────────────────────────┐
│           Layer 2 Solutions          │
│  ┌──────────┐  ┌──────────────────┐  │
│  │ State    │  │ Rollups          │  │
│  │ Channels │  │ (Optimistic, ZK) │  │
│  └──────────┘  └──────────────────┘  │
├──────────────────────────────────────┤
│        Layer 1 (Base Chain)          │
│   Consensus + Data Availability      │
└──────────────────────────────────────┘

State Channels#

Two parties open a channel, transact off-chain, and settle the final state on L1. Only the opening and closing transactions touch the main chain.

• Throughput: Essentially unlimited between participants
• Latency: Near-instant
• Limitation: Only works for fixed participant sets
• Example: Bitcoin Lightning Network

Optimistic Rollups#

Transactions execute off-chain and are posted to L1 in batches. The system assumes transactions are valid ("optimistic") and uses a fraud proof window (typically 7 days) where anyone can challenge invalid state transitions.

• Throughput: ~2,000+ TPS
• Compatibility: High EVM compatibility (Optimism, Arbitrum)
• Tradeoff: Withdrawal delay due to challenge period

ZK-Rollups#

Transactions execute off-chain, and a validity proof (zero-knowledge proof) is generated and verified on L1. No challenge period needed — the math proves correctness.

• Throughput: ~2,000–10,000+ TPS depending on implementation
• Finality: Fast — once the proof is verified on L1
• Tradeoff: Proof generation is computationally expensive; EVM compatibility is harder
• Examples: zkSync, StarkNet, Polygon zkEVM

Rollup Comparison:
                    Optimistic          ZK
Proof mechanism     Fraud proofs        Validity proofs
Withdrawal time     ~7 days             Minutes
EVM compatibility   High                Improving
Proof cost          Low                 High (compute)

Decentralized Architecture Patterns#

Event Sourcing on Chain#

Use the blockchain as an immutable event log. Off-chain services read events and build projections (read models). This separates write concerns (consensus) from read concerns (query performance).

Oracle Pattern#

Smart contracts cannot access off-chain data directly. Oracles bridge this gap by posting external data on-chain (price feeds, weather, API results). Decentralized oracle networks like Chainlink reduce single-point-of-failure risk.

Off-Chain Compute, On-Chain Verification#

Execute heavy computation off-chain, then submit a proof or result on-chain for verification. This pattern applies beyond rollups — it works for ML inference verification, complex financial calculations, and game state resolution.

Multi-Chain and Bridge Architecture#

Applications increasingly span multiple chains. Bridge contracts lock assets on one chain and mint equivalents on another. Security is critical — bridge exploits have caused billions in losses.

When Blockchain vs Traditional Database#

This is the most important section. Most applications do not need a blockchain.

Use blockchain when:

• Multiple mutually distrusting parties need a shared source of truth
• No single entity should control the data
• Censorship resistance is a requirement
• Transparent, auditable transaction history is non-negotiable
• Programmable money or token economics are core to the product

Use a traditional database when:

• A single organization controls the data
• You need high throughput and low latency
• Data privacy is paramount (blockchain data is public by default)
• You can trust a central authority or the parties already trust each other
• You need to modify or delete records

Decision Framework:
                                    YES
Multiple untrusted parties? ──────────► Need censorship resistance?
        │ NO                                    │ YES        │ NO
        ▼                                       ▼            ▼
  Traditional DB                          Public         Permissioned
                                        Blockchain       Blockchain

A permissioned blockchain (Hyperledger, Quorum) can make sense when you need auditability across organizations but don't need full decentralization. But always ask: would a signed append-only log with a traditional database achieve the same goal?

Key Takeaways#

1. Consensus defines everything — throughput, finality, decentralization, and energy costs all flow from your consensus choice
2. Layer 2 is where scaling happens — L1 provides security and data availability; L2 provides speed
3. ZK-rollups are the future — validity proofs eliminate challenge periods and enable faster finality
4. Smart contracts should be minimal — push complexity off-chain, keep on-chain logic auditable
5. Most projects don't need blockchain — if you can't identify the trust problem you're solving, use a database

---

Build architecture that matches the actual trust model of your system. Explore more system design patterns at codelit.io.

This is article #163 in the Codelit engineering blog series.