Public blockchain vs. private blockchain

“Private blockchain” is a confusing expression. It can mean a network isolated from the internet, a network where only invited parties write or a network where only invited parties read. Each of these has different consequences.

This article organizes the comparison based on the technical report on blockchain by the U.S. National Institute of Standards and Technology (NIST) and on the official documentation of two platforms used in enterprise networks, Hyperledger Fabric and Hyperledger Besu. The underlying question is always the same: who can do what, and whom do you need to trust.

The criterion that really separates the two models

NIST classifies networks by their permission model, which defines who can maintain the ledger, that is, who can publish new blocks (NIST, NISTIR 8202):

• Permissionless: anyone can publish blocks, without authorization from any authority. This is what common usage calls a public blockchain.
• Permissioned: only users authorized by some authority, centralized or decentralized, publish blocks. This is what is usually called a private or consortium blockchain.

The report uses a simple analogy: a permissioned network is like a controlled corporate intranet; a permissionless network is like the public internet, where anyone can participate.

Who reads is a second question, separate from the first. According to NIST, a permissioned network can let anyone read the ledger or restrict reading to authorized people. The same goes for who can submit transactions.

Ethereum.org adds a useful distinction. It calls a private network one whose nodes are not connected to the public network, and a consortium network one in which consensus is controlled by a predefined set of trusted nodes. And it adds a warning: “private” here means reserved or isolated, not protected or secure (ethereum.org, Networks).

From here on, this article uses “public” for permissionless networks and “permissioned” for the rest, because that is what matters in practice.

How a public blockchain works

On a permissionless network, participants do not know each other. NIST describes these nodes as users who distrust one another and may know each other only by their public addresses. Anyone can download the software, read the ledger and propose transactions.

This openness creates a problem: if publishing blocks were free, a malicious actor could create thousands of identities and take over the network. That is why, according to NIST, these networks require anyone who wants to publish blocks to spend or lock up resources. That is the role of proof of work and proof of stake, compared in detail in Proof of Work or Proof of Stake. Correct behavior is encouraged with rewards paid in the network’s own cryptocurrency.

The Bitcoin whitepaper sums up the logic: nodes do not need to be identified and can leave and rejoin the network at will, accepting the chain with the most accumulated work as proof of what happened while they were gone (Nakamoto, Bitcoin whitepaper). The structure of that chain is explained in how the Bitcoin blockchain works.

The price of this openness is well known:

• Costly consensus. Energy, in the case of proof of work, or locked-up capital, in the case of proof of stake.
• Full transparency. Anyone can read every transaction. Addresses carry no names, but the history is exposed.
• Hard to change. NIST notes that changing the protocol of an open network, with users spread around the world, is “extremely difficult”. An incompatible change can split the network into two versions.

How a permissioned blockchain works

On a permissioned network, participation requires a known identity. NIST describes the typical case as a consortium: a group of organizations that want to work together but do not fully trust each other, and that invite partners to record transactions on a shared ledger.

Because participants are identified, consensus does not require spending resources. According to NIST, consensus models on these networks tend to be faster and cheaper. And if someone acts in bad faith, there are legal remedies: it is known where each organization is registered and which contracts it signed.

Two platforms show how this plays out in practice:

• Hyperledger Fabric. The documentation describes the network as made up of participants who are “known, identified and often vetted”, and who may be competitors. Fabric does not require a native cryptocurrency, isolates data in channels (only members of a channel can access its transactions) and allows private data among subsets of participants (Hyperledger Fabric, Introduction).
• Hyperledger Besu. This is an Ethereum-compatible client that can run private networks. The documentation describes node permissioning, which restricts access to known participants, and account permissioning, which can require registration, suspend accounts or limit what each one can do (Hyperledger Besu, Permissioning).

A Brazilian example: the pilot of Drex, the Central Bank of Brazil’s digital currency project, ran on a network based on Hyperledger Besu with nodes operated by the Central Bank and the participating institutions. The story of that pilot is in Drex: proposal, architecture and project status.

The central trade-off: whom you trust

The whole comparison boils down to one question: what guarantees that the ledger will not be altered?

On a public network, the guarantee is economic and mathematical. Rewriting history requires controlling the majority of the resource that protects the network. NIST notes that this attack is not technically difficult, just expensive, and that the cost grows the further back the attacker wants to go. The premise is that the majority of the computing power or staked capital behaves honestly.

On a permissioned network, the guarantee is institutional. NIST is blunt about the other side of this: the owner or consortium that admits and removes nodes has “great control”. With that control, any number of blocks can be replaced through legitimate methods, if the owner or consortium wishes. And if a single entity decides who publishes blocks, users need to trust that entity.

In our newsroom’s assessment, this does not make the permissioned network worse. It makes it different. It trades resistance to any authority for performance, privacy and legal accountability. Whether that is a good deal depends on who the participants are and what they fear.

Side-by-side comparison

Criterion	Public blockchain (permissionless)	Permissioned blockchain
Who publishes blocks	Anyone	Authorized participants
Who reads	Anyone	Everyone or only authorized parties, depending on the network
Identity	Pseudonymous (addresses)	Known and verified
Consensus	Proof of work or proof of stake	Fault-tolerance protocols such as Raft or BFT
Finality	Probabilistic (Bitcoin) or after checkpoints (Ethereum)	Usually immediate, with no forks
Native cryptocurrency	Needed to incentivize validators	Optional
Protocol changes	Difficult; an incompatible change can split the network	The consortium can require the software upgrade
Basis of trust	Honest majority of the economic resource	Governance, contracts and identity

About the finality row: Fabric states that, because it uses deterministic consensus, a validated block is final and the ledger does not fork as it does on permissionless networks (Hyperledger Fabric, Ordering Service). Besu’s QBFT and IBFT 2.0 protocols also offer immediate finality, with a minimum of four validators (Hyperledger Besu, Proof of authority consensus). The reasons behind these differences are in how consensus mechanisms work.

Privacy: neither model solves it alone

A public network is transparent by design. That helps auditing, but it is a problem for customer data, commercial contracts or financial transactions protected by confidentiality.

Permissioned networks offer tools for this. NIST cites selective disclosure: the network records that a transaction took place, but only the parties involved see its content. Fabric uses channels and private data.

Even so, restricting who gets in does not solve what each participant sees of the others. The Drex pilot is the example closest to Brazilian readers: even on a permissioned network, the Central Bank concluded that the privacy solutions tested were not mature enough for the bank secrecy required in the country.

When each model makes sense

NIST recommends flipping the usual question. Instead of “how do we fit our problem onto blockchain?”, an organization should ask “how could blockchain benefit us?” and treat it like any other technical solution.

The report lists characteristics that make the technology a good fit, including:

• many participants, distributed;
• a desire or need to do without a trusted third party;
• a transactional workflow, such as transferring assets between parties;
• a need to reduce manual reconciliation and disputes;
• a need for a complete history shared among participants.

From there, a practical roadmap, which is our newsroom’s reading and not a NIST rule:

• A public network tends to make sense when no one should have the power to exclude participants or rewrite the ledger, and when transparency is acceptable.
• A permissioned network tends to make sense when participants are known, need privacy and performance, and accept a common governance backed by contracts.
• A conventional database may be enough when a single organization controls everything. In that case, as NIST itself notes, users would have to trust that entity anyway.

Key takeaways

• “Public” and “private” hide two different questions: who publishes blocks and who reads the ledger.
• Permissionless networks pay for costly consensus because they do not know who the participants are; permissioned networks use identity to get fast, cheap consensus.
• On a permissioned network, whoever controls access can also, legitimately, rewrite history. Trust shifts from mathematics to governance.
• Neither model solves privacy among participants on its own, as the Drex pilot showed.
• Before choosing between the two, it is worth asking whether the problem really needs a blockchain.