Two axes: access and validation
Chains differ on who can read/write and who can validate. Public vs. private describes data visibility. Permissionless vs. permissioned describes who can propose/validate blocks. Mix and match and you get very different trade-offs.
Ask two questions: (1) Who can see the data? (2) Who can add to it? Open everything maximizes neutrality but makes scaling harder. Tight control boosts throughput but concentrates power.
| Read / Write | Permissionless validation | Permissioned validation |
|---|---|---|
| Public data | Open chains (e.g., Bitcoin, Ethereum) | Public, permissioned (e.g., some CBDC pilots) |
| Private data | Private, permissionless (rare “club” chains) | Private, permissioned (enterprise/consortium) |
Public, permissionless
Anyone can read the ledger and submit/validate transactions (e.g., Bitcoin, Ethereum). Security comes from open verification and economic costs (PoW/PoS). Drawback: scalability and noisy data are harder problems.
Examples: Bitcoin (PoW), Ethereum (PoS), many L1s and L2s. Benefits: censorship-resistance, fork choice by open consensus, broad auditability. Costs: fee spikes during congestion, slower finality than private rails.
Public, permissioned
Data is readable by anyone, but only approved validators write blocks. This trims attack surface and can improve throughput, but reduces the “anyone can validate” property.
Used for enterprise or consortium chains that still want public transparency (e.g., certain CBDC pilots). Trust rests on the operator list; if they collude, they can rewrite state.
Private, permissioned
Access is restricted; only select participants can read and validate. Governance is centralized or consortium-based. Good for compliance and throughput; weak on censorship-resistance and openness.
Examples: internal settlement nets, supply-chain ledgers, interbank projects. Performance can be high because validator sets are small and predictable, but users must trust the gatekeepers to stay honest.
Private, permissionless (rare)
Data is closed, but many participants inside that boundary can validate. This is uncommon; most private chains also gate validators.
Think of it as a club network: members can validate, outsiders can’t even read. Useful for sensitive data, but “trustless” only applies inside the club.
“Open chains trade speed for cred; closed chains trade cred for control. Pick your poison.”
Trade-offs to remember
Scalability vs. neutrality. Fewer validators and tighter access can increase throughput but reduce censorship-resistance and independent auditability.
Who sets the rules? In permissioned setups, governance decides validators and upgrades. In permissionless, the social/economic majority chooses the canonical chain.
Use the right tool. Public, permissionless for cred and openness; permissioned for controlled environments; private for internal data.
Interoperability costs. Crossing chains (bridges, wrapped assets) adds risk: different trust models, smart-contract risk, and possible censorship on the other side. Know which security model you’re inheriting.
L2s and sidechains. Many “faster” environments inherit security from a base chain (rollups) or run as separate permissioned sets (sidechains). Check whether data availability and proofs land on a robust L1 or rely on a small council.