Public vs Private Blockchains: Who Can Read, Submit and Validate?

When someone calls a blockchain “public” or “private,” ask which activity they mean. Reading a record, submitting a request, validating updates and changing the rules are different jobs. A label can leave important permissions unexplained.

The useful comparison is a short list of questions about a specific design. If you are deciding whether a shared ledger is needed at all, start with blockchain versus a database. This guide focuses on who may participate once a design has been proposed.

Separate the activities

Ask who can inspect the information, who can request a change, which participants check and order accepted updates, and how the system's rules can change. Do not infer all four answers from one permission.

NIST's Blockchain Technology Overview, sections 2.1 and 2.2, distinguishes permissionless and permissioned approaches. The latter can restrict participation to identified people or organizations. It is a conceptual overview published in 2018, not a current specification for every network. Check a named implementation's present rules before using it as an example.

For a concrete permissioned design, Hyperledger Fabric's membership documentation explains how identities, roles and policies determine authority at different scopes. Being called an administrator does not automatically confer every administrative power. That is a useful reminder to look at the actual permissions, rather than the title printed beside a participant.

Compare two fictional designs

Imagine that two teams design different systems for a classroom exercise. Neither is a description of a named operating network.

Design A: an open practice ledger. Anyone can read its records and submit a request that follows the classroom rules. A participant may volunteer to check updates after meeting the exercise's published conditions. To change those conditions, the group must follow a separate agreed procedure.

Design B: a delivery partnership ledger. Approved partner organizations can read the shared delivery log. Registered staff can submit delivery updates. Two appointed organizations check the updates. A specified partner vote is needed to change those roles. Customers receive a limited view of their own delivery rather than the complete log.

For A, ask whether the checking conditions make participation practical for everyone who wants it. For B, ask who appoints and removes the partner organizations. In both designs, ask what happens if those responsible disagree or stop participating. The exercise answers depend on the rules the class chooses.

The accompanying permissions matrix repeats those fictional choices in four rows: read, submit, validate and change rules. It is an aid to asking questions, not a universal matrix for all public and private networks.

Visibility is not the same as trust

A readable record gives you something to inspect. It does not, by itself, establish that a person delivered a physical parcel, that a token issuer has the assets it claims, or that an application will treat you fairly. Restricting access also does not establish that a system is secure or that its operators are accountable. Those are further questions to investigate.

For comparison, Bitcoin.org's explanation describes a public transaction record and the role of signatures and mining. Those details explain parts of Bitcoin's model. They are not a template for assuming that every blockchain uses mining or has the same governance.

Build your own permission map

Use a fictional school-club record. Write one sentence for each question:

• Who may read the full record, and who sees only an extract?
• Who may submit a correction or new entry?
• Who checks a proposed update, and under what rule?
• Who can change those permissions?
• What happens when a participant leaves or disputes an entry?
• Which real-world facts still need evidence outside the record?

If an answer is missing, write “not specified” and ask for it. Do not fill the gap with an assumption that the system must be public, private, decentralized or safe. Return to how blockchain works if the record and the outside-world claim still seem like the same thing.