Public Chain, Private Chain or No Chain

Choosing the wrong chain architecture early is an expensive mistake. Here is how to think through the decision before you write a line of code.

What Problem Are You Actually Solving With a Blockchain?

Before picking a chain type, be precise about what property you need that a traditional database cannot give you. There are essentially four: immutable audit trails, trustless settlement between parties who do not share a database, programmable asset ownership, and decentralised consensus where no single party should be trusted as the arbiter.

If your answer is "we want a tamper-evident log," a Merkle-tree hash chain anchored to a public network costs far less to build and maintain than a full blockchain deployment. PostgreSQL with append-only tables and periodic SHA-256 anchoring to Ethereum mainnet is a legitimate architecture. Do not over-engineer it.

If your answer involves two or more organisations exchanging value or data without a trusted intermediary, you have a genuine blockchain use case. The question then becomes which type of chain fits your threat model and operational requirements.

Public, Private, or Consortium — What the Labels Actually Mean

These three categories are often presented as a clean spectrum. They are not. The distinctions matter at the level of who can read state, who can write transactions, and who runs validator nodes.

Property	Public (e.g. Ethereum, Solana)	Consortium (e.g. Hyperledger Fabric, Quorum)	Private (e.g. single-org Fabric, Besu)
Validator set	Open, permissionless	Known, permissioned set	Single organisation
Read access	Anyone	Configurable per channel	Internal only
Write access	Anyone with gas	Approved members	Internal only
Finality	Probabilistic or slot-based	Near-instant (BFT)	Near-instant
Native token required	Yes	No	No
Regulatory auditability	Public by default	Configurable	Full control
Throughput ceiling	~15–4,000 TPS depending on chain	~2,000–20,000 TPS	Near-unlimited

The throughput numbers are rough. Ethereum mainnet post-merge sits around 15–30 TPS on L1. Solana claims 65,000 TPS theoretical but sustains closer to 2,000–4,000 under real load. Hyperledger Fabric with a well-tuned endorsement policy can reach 3,500 TPS on modest hardware. These numbers matter because they constrain your product design.

When Should You Use a Public Chain?

Use a public chain when censorship resistance or open composability is part of your product's value proposition.

DeFi protocols need Ethereum or a compatible L2 because liquidity, oracles, and AMMs already exist there. Building a lending protocol on a private chain means rebuilding Chainlink, Uniswap, and Aave from scratch. That is not a technical problem, it is a business model problem.

NFT provenance for open markets similarly depends on public verifiability. If a collector cannot independently verify ownership without asking your company, the NFT has no credibility outside your platform.

The honest trade-offs on public chains:

• Gas costs are real and variable. On Ethereum L1, a complex contract interaction can cost $5–$50 depending on network congestion. Layer 2 solutions like Arbitrum One or Base reduce this to under $0.10 per transaction, but add bridge complexity and withdrawal delays.
• Smart contract bugs are permanent. The 2016 DAO hack drained ~3.6 million ETH. Audits from firms like Trail of Bits or Certik cost $15,000–$80,000 for a mid-size codebase. Budget for it.
• KYC and data privacy are genuinely hard. On-chain data is public by default. Zero-knowledge proofs (zk-SNARKs via Circom, Noir, or Aztec) can solve this but add 6–12 months to a project timeline.

When Does a Consortium Chain Actually Make Sense?

Consortium chains are the right fit for multi-party B2B workflows where the participants are known, the regulator needs audit access, but no single party should own the ledger.

Supply chain traceability across competing manufacturers is a genuine example. A food producer, logistics company, and retailer all need to write to and read from a shared record, but none of them will trust the others' database. Hyperledger Fabric's channel architecture lets you isolate data between subsets of participants without running separate networks.

Trade finance is another. Letters of credit involve a buyer's bank, a seller's bank, a shipper, and often an insurer. R3 Corda was designed specifically for this: each node only sees the transactions it is party to, which maps cleanly onto existing legal and privacy requirements.

Fabric vs Corda vs Quorum

Fabric uses a chaincode model (Go, Java, or Node.js) with an execute-order-validate flow. It is general-purpose but operationally complex. Running a production Fabric network means managing certificate authorities, orderer nodes, and peer nodes across organisations.

Corda models transactions as bilateral or multilateral contracts between specific parties. There is no global shared ledger — only a graph of bilateral state updates. This suits regulated industries where data minimisation is a legal requirement, not just a preference.

Quorum is essentially Go-Ethereum with a private transaction layer added via Tessera. If your team knows Solidity and wants Ethereum tooling but with permissioned access and private state, Quorum is the path of least resistance.

What If You Don't Need a Chain at All?

This is the most useful question to ask, and most vendors will not ask it for you.

If all the parties in your workflow can agree on a single trusted operator, a conventional database with a strong audit log, role-based access control, and cryptographic signing of records will meet your requirements. It will deploy faster, cost less to run, and be easier to debug.

The signals that suggest you do not need a chain:

• Only one organisation writes data
• Disputes are resolved off-system anyway (arbitration, courts)
• You control all the nodes in the "network"
• The primary requirement is reporting, not settlement

Blockchain adds operational overhead. You are distributing trust at the cost of coordination complexity. If you do not need the distributed trust, you are just paying the overhead.

How to Make the Decision

Work through these four questions in order:

1. Do multiple independent organisations need to write to a shared ledger without trusting a central operator? If no, stop here — use a database.
2. Do end users or the public need to verify state without your permission? If yes, public chain. If no, continue.
3. Are the participants known and regulated? If yes, consortium chain. If no, reconsider whether this is genuinely a blockchain problem.
4. Does your use case depend on existing liquidity, tokens, or smart contract composability? If yes, public chain, probably an L2.

Conclusion

The decision tree above will eliminate wrong answers faster than evaluating features. Most "blockchain projects" we see at the scoping stage are either a consortium use case being over-engineered onto a public chain for marketing reasons, or a database problem that acquired a blockchain requirement somewhere in the pitch deck.

Pick the architecture that matches your trust model. Then build the simplest version of it that can fail safely.

If you are at the architecture stage and want a technical review of your assumptions before committing to a stack, that is exactly the kind of conversation worth having early.

---

FAQ

Is a private blockchain just a database? Functionally, a private blockchain where one organisation controls all nodes has the same trust properties as a database. The main practical difference is auditability: the append-only ledger and cryptographic linking of blocks make historical tampering detectable. For most single-org use cases, a well-designed SQL audit log achieves the same result with less complexity.

Can you migrate from a private chain to a public chain later? You can migrate data and logic, but it is not straightforward. Smart contract ABIs, data models, and consensus assumptions differ significantly between Hyperledger Fabric and Ethereum-compatible chains. Plan your architecture for the target environment from the start rather than treating migration as a fallback option.

What does it cost to run a Hyperledger Fabric network in production? A minimal production Fabric network across three organisations typically requires six to nine nodes (peers, orderers, CAs). On AWS or GCP, that runs to roughly $1,500–$3,000 per month in compute alone, before monitoring, DevOps time, and certificate management overhead. Consortium governance adds non-trivial coordination costs.

Why do most enterprise blockchain projects fail? The most common reason is that the problem did not require decentralised trust. The second most common is that the consortium never agreed on governance: who can add members, who resolves disputes, who pays for infrastructure. Technology is rarely the failure point.

When should I use an L2 instead of Ethereum mainnet? Use an L2 when your transaction volume or cost sensitivity makes L1 gas fees impractical. Arbitrum One and Base are the most mature general-purpose L2s as of 2024. Use L1 directly only when you need maximum security guarantees and your transaction frequency is low enough that gas costs are manageable.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.