Public, private and permissioned blockchains
In short: Blockchains differ by who may read data, submit transactions and validate blocks. Public chains are open to anyone; private and consortium chains limit participation to known members. The right choice depends on trust, privacy, speed and governance needs, and sometimes the right answer is a normal database.
Two questions that define a blockchain
When people say "blockchain" they may mean very different systems. Two questions sort them out:
- Who can take part? If anyone can run a node and validate, the chain is permissionless. If only approved members can, it is permissioned.
- Who can see the data? A public chain lets anyone read it. A private chain restricts reading to members.
The four common types
| Type | Who validates | Typical consensus | Example uses |
|---|---|---|---|
| Public (permissionless) | Anyone who meets the rules | Proof of work or proof of stake | Cryptocurrencies, open token systems, public registries |
| Private | Nodes run by one organisation | Raft-style or BFT ordering | Internal audit trails, testing |
| Consortium | A set of member organisations | BFT voting among members | Trade finance, supply chains, industry data sharing |
| Hybrid | Private network that anchors proofs on a public chain | Mixed | Keeping data private while proving it existed at a point in time |
Well-known permissioned platforms include Hyperledger Fabric, an open-source project hosted by the Linux Foundation that supports private channels between members, and Corda, designed for regulated financial agreements where data is shared only with the parties involved. Public networks include Bitcoin and Ethereum.
Trade-offs
Public chains offer strong censorship resistance and transparency: nobody can quietly change the rules or exclude you. The cost is lower throughput, transaction fees, and the fact that all data is visible. Permissioned chains are faster and can keep data confidential, but trust moves to the members and whoever runs the membership service. A private chain run by one company gives up most of the "no single owner" benefit, and critics point out it can be close to a replicated database with extra steps.
Security concerns differ too. In a public chain, the threats are majority attacks, smart contract bugs and key theft. In a permissioned chain, you also worry about certificate authority compromise, insider abuse by a member, and weak governance over who can join.
Choosing the right type
- Do several parties need to write to the same record? If only one does, a database is usually better.
- Do those parties distrust each other or lack a trusted middleman? If a trusted operator exists, consider a shared database run by them.
- Must data be confidential? If yes, a permissioned chain or a hybrid design fits better than a fully public one.
- Must anyone be able to verify without permission? If yes, a public chain or public anchoring is needed.
- Who governs upgrades, membership and disputes? Write this down before building anything.
Tip: never put personal data directly on a public chain. Data protection laws such as the UK and EU GDPR include a right to erasure, which conflicts with a ledger designed never to forget. Store data off-chain and record only hashes or references.
In exams, be ready to compare permissioned and permissionless designs and to justify a choice for a scenario. At work, the most valuable skill is often recognising when no blockchain is needed at all.
Practice
What makes a blockchain permissioned?
Why might a consortium chain suit a group of shipping companies?
Why should personal data not be written directly to a public chain?
Key takeaways
- Permissionless versus permissioned is about who can validate; public versus private is about who can read.
- Main types: public, private, consortium and hybrid.
- Public chains favour openness; permissioned chains favour speed, privacy and control.
- Governance and membership are security controls in permissioned chains.
- If one trusted party controls the data, a normal database is usually better.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.