The Blockchain Stack Explained — Every Layer Enterprise Architects Must Know
Blockchain platforms are often presented as monoliths — "Hyperledger Fabric" or "Ethereum" as a single thing. They're not. Every blockchain is a stack of independent layers, each making specific design choices that determine the platform's characteristics.
Understanding these layers — and how different platforms make different choices at each one — is the difference between evaluating blockchain platforms and being sold one.
The 7-Layer Enterprise Blockchain Stack
┌─────────────────────────────────────────────────────────┐
│ 7. APPLICATION LAYER │
│ DApps, dashboards, integrations, external systems │
├─────────────────────────────────────────────────────────┤
│ 6. GOVERNANCE LAYER │
│ Membership, voting, upgrades, policy management │
├─────────────────────────────────────────────────────────┤
│ 5. API LAYER │
│ REST/gRPC, CLI, SDKs, query interfaces │
├─────────────────────────────────────────────────────────┤
│ 4. EXECUTION LAYER │
│ Smart contracts, virtual machines, sandboxes │
├─────────────────────────────────────────────────────────┤
│ 3. DATA LAYER │
│ World state, block storage, indexing, queries │
├─────────────────────────────────────────────────────────┤
│ 2. CONSENSUS LAYER │
│ Consensus algorithm, block production, validation │
├─────────────────────────────────────────────────────────┤
│ 1. NETWORKING LAYER │
│ P2P, TLS/WS, peer discovery, message protocols │
└─────────────────────────────────────────────────────────┘
Layer 1: Networking
What it does: Enables nodes to discover each other, establish secure connections, and propagate blocks and transactions.
Key Design Decisions
| Decision | Options | Impact |
|---|---|---|
| Transport | WebSocket, gRPC, libp2p | WS: simple, browser-friendly. gRPC: binary, efficient. libp2p: modular, complex |
| Topology | Full mesh, partial mesh, hub-spoke | Full: most resilient, O(n²) connections. Hub-spoke: simpler, single point |
| Discovery | Static peers, DNS seeds, DHT (Kademlia) | Static: explicit list. DNS: dynamic. DHT: decentralized, complex |
| Security | TLS, mTLS, Noise protocol | mTLS: mutual auth (used by Fabric). Noise: modern, simpler (used by libp2p) |
How Platforms Compare
| Platform | Transport | Topology | Security |
|---|---|---|---|
| MiniLedger | WebSocket | Partial mesh | TLS + Ed25519 signing |
| Hyperledger Fabric | gRPC | Hub-spoke (orderer hub) | mTLS (X.509 certs) |
| R3 Corda | AMQP/HTTP | Point-to-point | TLS + certificates |
| Besu/Quorum | devp2p (Ethereum) | Partial mesh | TLS |
| Azure ACL | TLS (CCF) | Full mesh | SGX attestation |
Enterprise consideration: WebSocket is simpler to operate and debug than gRPC. Full mesh is maximally resilient but adds connection overhead. For consortiums of 3-15 nodes, WebSocket + partial mesh is the pragmatic choice.
Layer 2: Consensus
What it does: Ensures all nodes agree on the order and content of blocks. The hardest problem in distributed systems.
Key Design Decisions
| Decision | Options | Impact |
|---|---|---|
| Fault model | CFT (Raft), BFT (PBFT, IBFT, QBFT) | CFT: simpler, faster. BFT: tolerates malicious nodes |
| Leader model | Single leader (Raft), Round-robin (IBFT), Leaderless (Tendermint) | Leader: simpler, write bottleneck. Round-robin: fairer. Leaderless: most complex |
| Block production | Timer-based, transaction-count-based, hybrid | Timer: predictable. Count: efficient. Hybrid: best of both |
| Finality | Immediate (Raft/BFT), Probabilistic (PoW/PoS) | Immediate: certain. Probabilistic: eventually certain, more confirmations needed |
How Platforms Compare
| Platform | Algorithm | Fault Model | Leader | Finality |
|---|---|---|---|---|
| MiniLedger | Raft | CFT | Single leader | Immediate |
| Fabric (orderer) | Raft | CFT | Single leader | Immediate |
| Besu | IBFT 2.0 / QBFT | BFT | Round-robin | Immediate |
| Quorum | Raft / IBFT | CFT or BFT | Configurable | Immediate |
| Corda | Notary-based | CFT (notary) | Configurable | Immediate |
Enterprise consideration: For known, legally-bound participants, CFT (Raft) is sufficient. BFT adds complexity for protection you don't need if legal agreements exist. Full consensus comparison →
Layer 3: Data
What it does: Stores the blockchain state and provides query capabilities. The layer most visible to application developers.
Key Design Decisions
| Decision | Options | Impact |
|---|---|---|
| State store | SQLite, LevelDB, CouchDB, RocksDB, PostgreSQL | Determines queryability and performance |
| Query language | SQL, Mango (NoSQL), KV only, custom API | SQL: familiar, powerful. KV only: fast, limited |
| Data model | Key-Value, UTXO, Account-based, SQL/relational | KV: simple, flexible. UTXO: natural for assets |
| Block storage | Flat files, database-backed, object storage | Files: simple. DB: queryable. Object: scalable |
How Platforms Compare
| Platform | State Store | Query Language | Data Model |
|---|---|---|---|
| MiniLedger | SQLite (WAL) | Full SQL + JSON functions | Key-Value (JSON values) |
| Fabric (LevelDB) | LevelDB | Key-range only | Key-Value |
| Fabric (CouchDB) | CouchDB | Mango (NoSQL) | JSON documents |
| Amazon QLDB | Proprietary (AWS) | PartiQL (SQL-compatible) | Document/Journal |
| Azure ACL | KV Store | Key-value only | Key-Value |
| Corda | Relational (H2/SQL) | JPA / SQL | UTXO / relational |
Enterprise consideration: SQL queryability is the most underrated feature in blockchain platforms. If your team needs to answer "show me all accounts with balance > 1000 and last active in the past 30 days," choose a platform where that's a SQL query, not an external indexing project.
Layer 4: Execution
What it does: Runs smart contract code in a secure, isolated environment. Produces deterministic state transitions.
Key Design Decisions
| Decision | Options | Impact |
|---|---|---|
| Language | Go, JavaScript, Kotlin/Java, Solidity, Rust | Determines who on your team can write contracts |
| Runtime | Docker container, JS sandbox, EVM, WASM, JVM | Docker: strongest isolation, heaviest. Sandbox: lightest, less isolated. EVM: battle-tested |
| Execution model | Order-execute (Fabric), Execute-order-validate (Ethereum), Execute-order (Corda) | Order-execute: deterministic. EOV: prevents non-determinism. EO: Corda's model |
| Gas/limits | Gas metering (Ethereum), Timeout (MiniLedger), Resource limits (Fabric) | Gas: economic. Timeout: simple. Resource limits: configurable |
How Platforms Compare
| Platform | Language | Runtime | Execution Model |
|---|---|---|---|
| MiniLedger | JavaScript | new Function() sandbox | Execute in sandbox |
| Fabric | Go, Java, Node.js | Docker container | Order-execute |
| Corda | Kotlin, Java | JVM sandbox | Execute-order |
| Besu/Quorum | Solidity | EVM | EOV |
| QLDB | N/A (no contracts) | N/A | N/A |
Enterprise consideration: Match the contract language to your team's skills. If your team is Node.js, don't choose a platform that requires Go or Solidity. The language barrier adds months to your timeline.
Layer 5: API
What it does: Exposes the blockchain to applications — submitting transactions, querying state, monitoring events.
Key Design Decisions
| Decision | Options | Impact |
|---|---|---|
| Protocol | REST, gRPC, WebSocket, GraphQL | REST: universal. gRPC: performant. WS: real-time. GraphQL: flexible |
| Query interface | SQL endpoint, KV get/scan, custom query API, GraphQL | SQL: powerful, dangerous. KV: safe, limited |
| Event streaming | WebSocket, Server-Sent Events, Kafka, polling | WS: real-time. SSE: simpler. Kafka: enterprise-grade |
| Authentication | API keys, JWT, mTLS, wallet signatures | mTLS: strongest. JWT: familiar. Wallet: blockchain-native |
How Platforms Compare
| Platform | Protocol | Query | Events | Dashboard |
|---|---|---|---|---|
| MiniLedger | REST + WebSocket | SQL endpoint | WS events | Built-in SPA |
| Fabric | gRPC + REST proxy | Chaincode queries | Event hub | Separate tool |
| Corda | REST (via Corda RPCOps) | Vault queries | Observable flows | Separate tool |
| Besu | JSON-RPC (Ethereum) | eth_call, eth_getLogs | Filters + WS | Separate tool (Blockscout) |
| QLDB | AWS SDK (REST) | PartiQL | Journal exports | AWS Console |
Enterprise consideration: A built-in dashboard/block explorer saves months of development. If the platform requires a separate explorer, budget for building or deploying it.
Layer 6: Governance
What it does: Manages consortium membership, policy changes, contract upgrades, and dispute resolution.
Key Design Decisions
| Decision | Options | Impact |
|---|---|---|
| Member management | On-chain (transactions), Off-chain (consortium vote), Hybrid | On-chain: auditable. Off-chain: flexible |
| Voting mechanism | 1-org-1-vote, weighted, token-based, consensus-based | 1-org-1-vote: fair. Weighted: reflects contribution |
| Proposal lifecycle | Submit → Vote → Execute, Submit → Discuss → Vote → Execute | Fewer stages: faster. More stages: more deliberation |
| Upgrade mechanism | Hard fork, soft fork, contract upgrade, config update | Contract upgrade: safest. Hard fork: most disruptive |
How Platforms Compare
| Platform | Member Mgmt | Voting | Contract Upgrades | Built-in |
|---|---|---|---|---|
| MiniLedger | On-chain proposals + voting | Configurable threshold | Yes (versioned) | Yes |
| Fabric | Off-chain (config update tx) | Manual coordination | New chaincode lifecycle | No (manual) |
| Corda | Off-chain (network parameters) | Manual | New CorDapp version | No |
| Besu | On-chain (validator voting) | IBFT/QBFT voting | Contract re-deploy | Partial |
| ACL | On-chain (CCF governance) | Consortium vote | Member-managed | Yes |
Enterprise consideration: On-chain governance provides an auditable, cryptographically verifiable record of every decision. Off-chain governance (Fabric's model) relies on trust that the process was followed correctly. For regulated industries, on-chain governance is strongly preferred.
Layer 7: Application
What it does: The software your users actually interact with — the reason you're building a blockchain in the first place.
Key Design Decisions
| Decision | Options | Impact |
|---|---|---|
| Integration pattern | Embedded library, separate service, managed service | Embedded: tightest integration. Separate: decoupled. Managed: zero ops |
| Frontend | Custom web app, dashboard, mobile, API-only | Dashboard: quick visibility. Custom: tailored UX |
| Data sync | Direct queries, event-driven, ETL pipeline | Direct: simplest. Event-driven: reactive. ETL: for analytics |
| Identity integration | SSO, existing IAM, custom wallet, API keys | SSO: familiar. IAM: enterprise. Wallet: blockchain-native |
Platform-Specific Stack Choices
Here's how different platforms assemble these layers:
MiniLedger Stack
Application ← Your Node.js app (import { MiniLedger })
Governance ← On-chain proposals + voting (built-in)
API ← REST + WebSocket + SQL endpoint + built-in dashboard
Execution ← JavaScript sandbox (new Function, 5s timeout)
Data ← SQLite WAL (full SQL, JSON functions)
Consensus ← Raft CFT
Networking ← WebSocket mesh, Ed25519 identity
Hyperledger Fabric Stack
Application ← Separate application (SDK: Go, Node.js, Java)
Governance ← Off-chain (manual configuration updates)
API ← gRPC (peer) + REST proxy (optional)
Execution ← Docker containers (Go/Java/Node.js chaincode)
Data ← LevelDB (KV) or CouchDB (Mango queries)
Consensus ← Raft CFT (ordering service, separate process)
Networking ← gRPC, mTLS (X.509 PKI), Fabric CA
Ethereum (Besu) Stack
Application ← dApp (web3.js/ethers.js)
Governance ← Token-based or validator voting
API ← JSON-RPC (Ethereum standard)
Execution ← EVM (Solidity bytecode)
Data ← LevelDB or RocksDB (Patricia Merkle trie)
Consensus ← IBFT 2.0 / QBFT / PoA (for permissioned)
Networking ← devp2p (Ethereum wire protocol)
Choosing Your Stack: The Decision Framework
Rather than comparing platforms as monoliths, compare them layer by layer:
| Layer | Key Question | If Answer Is... | Then Look For... |
|---|---|---|---|
| Networking | How many nodes? In what topology? | 3-15 nodes | WebSocket or gRPC, partial mesh |
| Consensus | Known, legally-bound participants? | Yes | CFT (Raft) — simpler, faster |
| Data | Need SQL queries on state? | Yes | SQLite or PartiQL, not KV-only |
| Execution | What's your team's primary language? | Node.js/TS | JavaScript contracts |
| API | Need a built-in dashboard? | Yes | Platforms with built-in explorer |
| Governance | Need auditable governance? | Yes | On-chain governance, not off-chain |
The platform that matches your answers at the most layers is your best fit. If no platform matches, you may be looking for a solution that doesn't exist yet — or you may need to compromise at the layers where the mismatch is least painful.
The Bottom Line
Blockchain platforms aren't magic. They're stacks of well-understood technologies — networking protocols, consensus algorithms, databases, virtual machines, and APIs — assembled in specific ways to solve specific problems.
When a vendor tells you their platform is "better," ask: "At which layer? And by what metric?" If they can't answer that question, they're selling, not informing.
Next: See how platforms compare →
About the Author
Prasad Kumkar is the Founder & CEO of ChainScore Labs. Over the last 5+ years, he has worked with teams building exchanges, DeFi infrastructure, smart contracts, tokenization systems, and protocol-level blockchain products, helping founders make architecture, security, and go-live decisions for production Web3 systems.