One idea, different access rules
Blockchains share a basic structure: blocks of records linked by fingerprints and copied across many computers. What differs from one network to another is who is allowed to take part. That single question divides the field into public and private designs, with some in between.
Public blockchains
A public, or permissionless, blockchain is open. Anyone can download the software, run a node, read the full history and submit transactions. Participants usually do not need approval from any organization. Bitcoin and Ethereum are the best-known examples.
Typical features:
- Open membership. No gatekeeper decides who joins.
- Transparency. The history is visible to anyone, usually with pseudonymous addresses rather than names. This is more subtle than it sounds, as the article on common misconceptions explains.
- Incentive-based security. Because participants are unknown and may be hostile, the network relies on economic mechanisms to keep them honest, such as proof of work or proof of stake, compared in consensus mechanisms.
- Slower and costlier operation. Handling unknown participants takes extra work, which is part of the limits discussed in blockchain scalability.
Private blockchains
A private, or permissioned, blockchain restricts participation. A company or group of organizations decides who may run nodes, write records or even read data. Members are identified and are bound by contracts or membership agreements.
Typical features:
- Known participants. Because everyone is identified, the network can use simpler agreement methods based on voting among validators rather than expensive puzzles.
- Higher speed and lower cost. Fewer, trusted computers mean faster confirmation and much lower energy use.
- Privacy controls. The operators can decide which members see which data.
- Governance. Rules can be changed by agreement among members, and mistakes can sometimes be corrected by the group, which public networks generally cannot do.
Consortium and hybrid designs
Many real projects fall between the extremes. In a consortium blockchain, several organizations such as banks or shippers jointly run the network. No single member controls it, but the group is limited to approved participants. Hybrid approaches may keep sensitive data on a restricted ledger while anchoring a fingerprint of it to a public one, so that later tampering can be detected. The fingerprint idea is covered in cryptographic hashes.
Side-by-side comparison
| Question | Public | Private or consortium |
|---|---|---|
| Who can join? | Anyone | Approved members |
| Who can read the data? | Usually everyone | Chosen by the operators |
| Who controls the rules? | Developers, validators and users, loosely | The organization or consortium |
| Agreement method | Often proof of work or proof of stake | Often voting among known validators |
| Typical speed | Lower | Higher |
| Main appeal | Open access, resistance to control by one party | Control, privacy, compliance, performance |
| Main weakness | Cost, limited privacy, slow | Trust placed in the operators |
Is a private blockchain just a database?
This is a common and fair criticism. If a single organization controls every node, its blockchain offers little that a normal database with an audit log does not. The shared fingerprints add little when a single party can rewrite all copies. As the discussion of SQL databases shows, conventional databases are mature, fast and well understood.
A private design starts to make more sense when:
- Several organizations need to share a record.
- No single one of them is trusted to run the database for everyone.
- They want an audit trail that is difficult for any one member to alter quietly.
Typical examples proposed include shared records among banks, shipping partners or manufacturers, as in supply chain tracking. Even then, adoption results have varied, and many projects have found that simpler shared databases were enough. It is wise to be skeptical of any claim that a blockchain is required.
Security and risk differences
In a public network, an attacker must overcome a large, anonymous group of participants. In a private network, the attack surface is different: the small group of operators, their software, and their internal security matter a great deal. Insider risk becomes more relevant, a topic discussed more broadly in insider threats. A compromised administrator of a permissioned system can potentially do far more damage than any single user of a public chain.
Regulation also differs. Organizations in areas such as finance often need to know who their counterparties are and to protect personal information, which is easier to arrange on a permissioned network. Rules vary by country and sector, so this is only a general observation.
Choosing between them
Neither type is better in general. Public chains value openness and resistance to control by any one party, at the cost of speed, energy and privacy. Private chains trade openness for efficiency and control, at the cost of relying on the operators. The questions to ask are practical ones: who needs to participate, who needs to trust whom, how private must the data be, and whether an ordinary database would do the job.