Module 3 — Types of Blockchain Networks
Not all blockchains are the same. They differ mainly in who is allowed to participate and who is allowed to read the data. Choosing the right type is one of the biggest design decisions any project makes. This module maps the landscape.
3.1 Public vs private
Public blockchains are open to anyone. Anyone can read the data, anyone can submit a transaction, and (usually) anyone can help run the network. They prioritize openness and censorship-resistance over speed and privacy.
- Analogy: a public town square where anyone can show up, speak, and watch.
- Trade-off: maximum openness, but slower and fully transparent.
Private blockchains are restricted. A known organization (or group of them) controls who can participate and who can see the data. They prioritize speed, privacy, and control.
- Analogy: a members-only club with a guest list at the door.
- Trade-off: fast and private, but you're trusting the gatekeepers.
3.2 Permissioned vs permissionless
This dimension is closely related but worth separating:
- Permissionless: no approval needed to join or participate. Public blockchains are typically permissionless.
- Permissioned: you need approval to take part — especially to help validate transactions. Private and consortium blockchains are permissioned.
A helpful way to hold both ideas: "public/private" is mostly about who can read, while "permissioned/permissionless" is mostly about who can write and validate. Many real systems mix these — for example, a network where reading is open but only approved parties can validate.
3.3 Consortium blockchains — when several organizations cooperate
A consortium (or federated) blockchain is run by a group of organizations rather than a single one. No single member controls it, but it's not open to the whole world either. It sits between fully public and fully private.
- Analogy: several rival shipping companies jointly keeping one shared, trusted logistics record — none of them controls it alone, so none can cheat the others, but outsiders aren't invited in.
- Use cases: banking consortia, supply chains, healthcare data sharing, and multi-service ecosystems where different products need to share one trustworthy record without any one product owning the master copy.
3.4 Which type for which job? (comparison)
| Need | Best fit |
|---|---|
| Open, censorship-resistant money or apps | Public, permissionless |
| Fast internal records for one company | Private, permissioned |
| Shared record across several known organizations | Consortium, permissioned |
| Public transparency but controlled validation | Hybrid (public read, permissioned write) |
There's no "best" type — only the best fit for a goal. A global open currency wants public and permissionless. A group of cooperating businesses — or a family of apps under one ecosystem, like the several services that make up Tupic — often wants the speed and control of a permissioned design, while still keeping the tamper-proof, shared-record benefits of a blockchain.
3.5 Why networks need a "consensus mechanism"
Whatever the type, every blockchain faces the same core challenge: with many participants and no single boss, how does everyone agree on which transactions are valid and in what order?
That agreement process is called a consensus mechanism. It's the set of rules that lets a decentralized crowd reach a single shared truth without trusting any one member. Different network types tend to use different consensus mechanisms — and that's exactly what Module 4 is about.
Key takeaway: Blockchains differ by who can read (public vs private) and who can validate (permissionless vs permissioned). Consortium chains let several organizations share control. The right choice depends entirely on the goal — and it determines which consensus mechanism makes sense.
⬅ Previous: Module 2 — Blockchain Basics | Next: Module 4 — Consensus Mechanisms & PoA ➡
Tupic Academy — Education series. Free to learn, no login required.