DISTRIBUTED RECORDS
What hashes, signatures and consensus preserve, and what they cannot establish.
A record can be correctly signed, included in a block, committed by a Merkle root and accepted by distributed consensus.
Every cryptographic check can succeed while the statement recorded is false, incomplete or produced by a compromised key.
This is not a defect unique to blockchains. It is a boundary. Cryptography can make alteration detectable, attribute an action to a key and establish that a community accepted one ordered history under specified rules. It cannot observe the external event that the record claims to describe.
A blockchain can preserve a claim. The system around it must decide why that claim should be believed.
Several properties are hidden inside “immutable”
The word immutable compresses distinct guarantees:
- an entry cannot be modified without changing its hash;
- a block commits to an ordered set of transactions;
- later blocks commit to earlier block headers;
- participants can detect a history that violates consensus rules;
- rewriting accepted history requires control of sufficient consensus power or governance;
- clients can obtain evidence that a particular entry was included.
These statements have different assumptions. Hash linkage provides tamper evidence. Signatures authorise state transitions under keys. Consensus selects a shared history. Economic incentives, validator distribution and governance make replacement of that history costly or unacceptable.
No individual primitive makes the complete ledger immutable. The property emerges from the protocol and the population operating it.
A hash commits to bytes
A cryptographic hash maps an encoded input to a fixed-size value. If the input changes, the hash should change unpredictably. A block header that contains the previous header’s hash makes later history depend on earlier bytes.
This detects modification only when a verifier already knows which hash or chain head it trusts. An attacker who can replace both the data and the reference hash has not broken the hash function. The trust anchor was missing.
Encoding also remains part of the claim. Two systems may describe the same conceptual transaction but serialize it differently. Conversely, an ambiguous encoding may let the same bytes be interpreted in different ways.
The lesson from Signatures are over bytes, not meaning applies equally to hash commitments. The commitment is exact. The meaning assigned to the committed bytes comes from the protocol.
A Merkle proof proves inclusion
A Merkle tree combines leaf hashes into a single root. A compact audit path lets a verifier reconstruct that root from one leaf and a logarithmic number of neighbouring hashes.
If the reconstructed root matches a trusted root, the verifier has evidence that the leaf belongs to the committed tree.
The proof does not establish:
- that the leaf describes a true external event;
- that the signer was authorised under external law or policy;
- that the tree contains every event that should have been recorded;
- that the committed root is the one accepted by the intended network;
- that the underlying data will remain available later.
Inclusion, consistency, completeness and truth are different claims.
Certificate Transparency provides a useful comparison. Its append-only Merkle logs make certificate issuance publicly auditable. The logs do not prevent a certificate authority from misissuing a certificate. They make the event visible so monitors and policy can respond.
A signature identifies a key
A valid transaction signature establishes that the signature was produced using the private key corresponding to a selected public key, over the exact bytes defined by the protocol.
Applications often translate this into stronger language: a person approved, an organisation certified, an asset changed hands or a physical item was delivered.
Those statements require additional bindings:
- how the key was associated with an actor;
- whether the actor still controlled it;
- which software displayed the transaction;
- whether the signer understood the encoded operation;
- which authority assigned the key’s role;
- how compromise and revocation are handled.
A stolen key can create perfectly valid signatures. A malicious application can request a signature over bytes that do not match its user interface. A legitimate key can be authorised for one operation and misused for another if the protocol lacks domain separation.
The ledger preserves the signature. It does not reconstruct the signing ceremony.
Consensus orders protocol-valid statements
Distributed consensus addresses disagreement among nodes about which valid transactions form the accepted history.
Different systems use proof of work, proof of stake, Byzantine fault-tolerant voting or controlled validator sets. Their safety and liveness assumptions differ. What they share is a rule for moving from several candidate states toward one accepted state.
Consensus does not inspect the physical world. It evaluates messages under protocol rules.
If every validator receives a correctly signed statement from an authorised oracle, consensus can agree to record it. Agreement does not prove the oracle’s sensor was calibrated, its database was correct or its operator was honest.
Consensus is a mechanism for shared protocol state, not a general-purpose truth machine.
Finality is a model, not a moment
When is a recorded transaction final?
In proof-of-work systems, confidence often increases as more work accumulates on top of a block. Reorganisation remains possible, with probability and cost depending on adversarial resources, network conditions and confirmation depth.
Some proof-of-stake and Byzantine fault-tolerant systems provide explicit finality under assumptions about validator participation and fault thresholds. They can still face software defects, key compromise, governance intervention or conflicting views during severe network partition.
An application must translate protocol finality into an acceptance policy. A low-value event may proceed after limited confirmation. A high-value settlement may require stronger evidence, more time or an external reconciliation process.
Recording a block number without recording the finality rule leaves the evidence incomplete.
Oracles reintroduce an authority
Many useful applications depend on facts that originate outside the ledger: an exchange rate, a shipment, a temperature, an identity status, a document revocation or the result of a sporting event.
An oracle converts that observation into a signed input the blockchain can process. The cryptographic boundary moves, but it does not disappear.
The oracle design must address:
- who is permitted to report;
- how sources are authenticated;
- whether several independent observations are required;
- how freshness is established;
- how conflicting reports are resolved;
- what happens when no report is available;
- how keys are rotated and revoked;
- which party bears the consequence of an incorrect report.
A threshold of oracle signatures can reduce dependence on one key. It cannot create independent knowledge if every signer consumes the same incorrect upstream source.
Key compromise can remain permanently valid
Append-only history preserves malicious transactions as effectively as legitimate ones.
When a private key is stolen, the network cannot infer which correctly signed operations reflect the owner’s intent. Reversal, if available, comes from application rules, administrator privileges, a compensating transaction or governance intervention.
This creates a tension between irreversible settlement and operational recovery.
A system can introduce:
- multisignature or threshold authorisation;
- spending limits and delays;
- separate online and recovery keys;
- contract-level pause or upgrade controls;
- key rotation with explicit epochs;
- social or institutional recovery.
Each control changes who can override whom. Calling the result trustless hides the governance decision. The more useful question is where authority resides and how its use becomes visible.
Permissioned does not mean private
A permissioned ledger restricts who can submit, validate or observe transactions. That can align the consensus model with a known institutional group and provide clearer accountability.
It does not automatically provide confidentiality.
Replicated nodes may each receive transaction contents. Hashing a predictable or low-entropy value does not conceal it because observers can test guesses. Encryption protects content only while key distribution, access and rotation remain sound. Metadata can reveal relationships even when payloads are encrypted.
Selective disclosure, channels, private data collections and zero-knowledge constructions address different parts of this problem, with corresponding complexity and trust assumptions.
Before placing sensitive data on a ledger, the design should ask whether every required participant must retain it, how erasure obligations are handled and whether a commitment or external reference would be sufficient.
Availability is not implied by a commitment
A hash proves that retrieved bytes match a prior commitment. It cannot retrieve bytes that no participant still stores.
Systems that place documents, credential evidence or large objects outside the chain often record only a digest or content address. Long-term verification then depends on:
- continued storage;
- authorised access;
- preservation of the original encoding;
- algorithm identifiers;
- key and certificate history;
- migration before cryptographic primitives age.
An immutable reference to unavailable data has limited evidentiary value.
Smart contracts execute encoded rules
A smart contract can make state transitions deterministic for every validating node. That does not show that the code implements the intention described in prose.
Correctness has several layers:
- the virtual machine executes the bytecode according to specification;
- the bytecode corresponds to the reviewed source;
- the source implements the intended state machine;
- external inputs represent the intended facts;
- upgrade and administration paths match the governance model.
Consensus can reproduce a bug consistently. Immutability can preserve its consequences.
Testing should include invalid transitions, adversarial ordering, re-entry, interrupted dependencies, key compromise and boundary values. A contract audit is not a proof that the surrounding economic or institutional assumptions are correct.
Governance is part of immutability
Protocols evolve. Clients update. Validators choose software. Communities respond to incidents. Permissioned operators replace members. Smart contracts may include upgrade keys.
A ledger can be highly resistant to unilateral modification while remaining changeable through collective or privileged action.
That is not necessarily a weakness. Recovery from defects and changes in requirements may be essential. The important property is that authority and procedure are explicit.
A serious design should document:
- who can change validation rules;
- how software versions become active;
- which threshold can halt or reorganise operation;
- how emergency powers are constrained;
- how participants learn which rules produced a historical state;
- how cryptographic transitions are completed.
Immutability is always relative to an adversary and a governance model.
When a shared ledger is the right object
A blockchain or related append-only structure is useful when several parties need a shared ordered record, no single party should be able to rewrite it unnoticed, and independent verification is worth the cost of replication and consensus.
The decision should follow concrete questions:
- Which parties can submit records?
- Which parties validate them?
- What disagreement does consensus resolve?
- Which facts originate outside the ledger?
- What evidence does an inclusion proof provide?
- What finality does the application require?
- Which data must remain confidential?
- How are compromised keys and incorrect entries handled?
- Who can change the rules?
- Would a signed transparency log or conventional replicated database satisfy the same need?
The final question is important. Certificate Transparency demonstrates that append-only, publicly auditable history can be valuable without requiring a cryptocurrency or general-purpose consensus network.
Preserving the right claim
Hashes, signatures, Merkle trees and consensus offer precise guarantees.
A hash binds bytes. A signature attributes those bytes to a key. A Merkle proof establishes inclusion under a root. Consensus selects an accepted protocol history. Replication and governance make alteration detectable and costly under stated assumptions.
None of them observes reality, interprets intent or repairs a compromised source.
The engineering task is to define the claim that belongs on the ledger, the authority that can make it, the evidence that connects it to the external world and the procedure used when that connection fails.
A blockchain can preserve a claim for a long time. That makes choosing the right claim more important, not less.
