Private Blockchain: How Companies Organize a Verifiable History

What is a private blockchain?

A private blockchain is a blockchain network with participation limited to a defined organizational scope and established control over its operation. A company or a defined group of operators determines the conditions for participation.^[2]

The authorised nodes maintain the ledger according to agreed rules. Blocks are cryptographically linked; the network governs which new entries become part of the accepted ledger state and in what order.^[1]

In this article, “private” refers to the defined group of operators and participants. Specific permissions are a separate matter: NIST describes a network as permissioned when only authorised participants may publish blocks. Who may submit data and who may read it are determined separately. Such a network may also make certain information publicly accessible.^[1]

For a business application, the label alone is therefore not a sufficient description. What matters is the actual allocation of rights and responsibilities.

A company can operate the network itself

A private blockchain does not require several independent companies to operate their infrastructure jointly. A single company can also control operation and participant admission. NIST explicitly describes the associated dependence on trust: where one entity determines who may publish blocks, users must trust that entity in this respect.^[1]

Multiple nodes under the same management distribute technical tasks, but do not by themselves create independent oversight. Assessment therefore needs to consider not only the number of nodes, but also who controls their configuration, access and changes. An organizationally separate auditing body may perform a different role from another server run by the same operator.

The literature on blockchain in procurement and supply chains accordingly treats development and operation as separate design decisions. In-house development, cooperation and external sourcing sit alongside questions about partners, access rights and blockchain type.^[2] This does not amount to a general recommendation for in-house development. It does, however, make clear that choosing blockchain does not itself determine the operating model.

Reading, submitting and confirming involve different rights

Three separate questions help explain a private blockchain:

A submitted transaction is not yet a confirmed part of the blockchain. NIST distinguishes transaction submission, inclusion in blocks and consensus on the ledger state.^[1]

This distinction is easily overlooked in day-to-day operations: “confirmed” may refer to a technical entry or to a decision within the business process. The application context must make clear which meaning applies.

Consensus determines which ledger state is accepted

In simplified terms, a consensus mechanism answers the question: under which rules does the network accept the next state of its ledger? This includes checking admissible entries and coordinating their inclusion and order. Different mechanisms address this task under different assumptions about participants, faults and attackers.^[1]

Consensus therefore does not automatically mean a simple majority vote by all users. Nor does a private blockchain require Bitcoin’s mining mechanism. Other mechanisms may be used with a defined group of participants. The description of a specific implementation must match the mechanism actually used.

Users can ask the practical question without access to the source code: when is a submitted entry considered confirmed, how is that status shown and what happens if the nodes needed for confirmation are unavailable? These questions concern the system’s observable behavior.

Example: A handover is documented and later corrected

The following example is fictional. It describes a possible application, not a specified implementation of 420+.

A business hands component B-73 over to a downstream work area. Three successive events are recorded for operation U-118:

For this example, assume that entries are added to the ledger with their operation reference and that corrections are recorded as new entries. The original statement is retained. A current view can display the corrected identifier while also providing access to the sequence from the original information to the correction. The article on the Append-only Log explains this recording principle.

Technical confirmation of the first entry means only that the preparation report has been accepted under the network rules. It does not replace the receiving area’s acknowledgement of receipt. Likewise, recording the correction does not prove that the new identifier is correct in the business context. The underlying evidence and the responsible review remain decisive.

A confirmed entry is not yet a confirmed handover. The blockchain retains the documented operation; the business process model determines what action follows.

What external mirroring makes additionally verifiable

In the example, an external body could continuously receive the block sequence and the associated hash values. It would then hold comparison data outside the operator’s running system. To check a history presented later, the scope, origin and protection of those data must be established.

The distinction is concrete: without its own comparison data, the body initially sees the history currently presented to it. With a sufficiently protected earlier state, it can check whether the data presented match that state. The data bound by each hash value and the comparison procedure must be defined. Hash Chaining explains the cryptographic basis.

Mirroring does not automatically make the external body a node that participates in confirming new blocks. Observing and comparing is a different task from participating in consensus. NIST identifies the involvement of auditors and supervisory bodies as a possible use of permissioned networks; their specific role remains a design decision.^[1]

The transmission itself also needs a clear boundary: up to which confirmed state does the mirror extend? Are there interruptions? Which parts of the history can actually be compared using the data available? An audit report should state this scope. External Data Verification discusses how to assemble the required data, references and verification steps.

Integrity of the history and correctness of its content remain separate

A cryptographically verifiable record may contain an incorrect original statement. If receipt was reported in error for U-118, including that report in a block does not turn it into a handover that actually occurred. NIST describes this limitation when information is taken from the real world as the oracle problem.^[1]

Nor does a consistent history establish that all relevant operations were recorded. An action that was never submitted does not leave a detectable gap merely because other actions are recorded in a blockchain. Completeness requires a defined recording scope and appropriate reconciliation.

“Immutable” is also unsuitable as an absolute assurance. NIST distinguishes making tampering evident and resistant from unrestricted immutability. For permissioned networks, NIST describes a case in which the operator or consortium controls the admission and removal of nodes that publish blocks. That control can also allow existing blocks to be replaced through legitimate mechanisms.^[1] Whether such interventions are possible, and under which conditions, must be examined for the particular architecture. Key management, access rights, software changes and protection of external comparison data remain part of the overall system.

When the approach serves a clear purpose

A private blockchain should serve a specific verification or coordination task. In U-118, the task concerns a jointly traceable ledger state and its comparison with a state retained outside the operator’s system. Whether this structure offers an advantage over another ledger architecture depends, among other things, on the participants, their powers and the required verification procedure.

Supply-chain literature discusses uses such as tracking products, certificates and technical information across organizational boundaries.^[2] These are possible applications, not evidence that every supply chain needs a blockchain. In particular, the technical foundation does not automatically solve the problem of linking a physical component to its digital record.

Five questions can support selection:

• Which shared ledger state is needed, and by whom?
• Who controls admission and operation of the confirming nodes?
• Which data are recorded, which are merely referenced and which are made accessible to auditors?
• Against which independently protected state can a later representation be checked?
• Which statement still requires assessment within the business process after technical verification?

Private blockchain at 420+

420+ has its own private blockchain, operated by the company itself. Hash values and the complete block sequence can be mirrored in real time to an external body, such as a public authority.

This allows external comparison data to be provided alongside the operational system. Which data a receiving body obtains and which checks it can perform depend on the agreed scope and procedure. The ability to mirror data does not mean that every such body participates in consensus or that a connection to a public authority already exists.

The Ledger Architecture of 420+ places recording in its operational context. Assessment depends on which operation is documented, how later additions refer to it and which state an external check actually covers.

A verifiable history needs a defined basis for comparison

“Private blockchain” describes a technical and organizational foundation. A substantiated statement emerges only from the interaction of ledger rules, recorded data, responsibilities and comparison data.

For operation U-118, each layer therefore remains visible: readiness for handover was reported, receipt was confirmed separately and one detail was subsequently corrected. Checking the ledger history can support review of the business process. It does not make that decision.