Does a DPP Need Blockchain?

Blockchain and product passports are proposed together often enough that the pairing is worth examining on its merits rather than accepting or dismissing it wholesale.

The short answer is that a ledger solves one real problem in this space, and that problem is narrower than most proposals assume.

What people want from it

Three properties are usually cited, and they are not equally well served by a ledger.

The second row is the most common confusion. Authenticity of a claim is established by a signature from an identified issuer, which W3C verifiable credentials already provide without any ledger involvement.

Immutability is the wrong property

Product records must be correctable. A test result is superseded, a supplier is found to have misreported, a calculation method is revised, a figure was simply entered wrong.

What is actually wanted is not immutability but auditability: the ability to show what a record said at a given time, and that it has not been altered since without that alteration being visible. That is a versioning property, and versioning permits correction while immutability does not.

What anchoring actually does

Anchoring publishes a cryptographic hash of a record — or of a tree of records — to a ledger, without publishing the record itself.

The salt in the second step matters more than it appears. Without it, a record with predictable contents can be brute-forced from its hash, which would leak exactly the commercial data the arrangement was meant to protect.

The tree in the third step is what makes it economic. Anchoring every record individually would cost a transaction each; anchoring a root covering thousands costs one, and any individual record can still be proven against it.

When anchoring is worth it

The honest test is whether anybody needs to prove something to a party who does not trust them, about a record that party cannot otherwise verify.

That situation is real in some contexts: a due diligence claim contested years later, an origin assertion in a market with counterfeiting pressure, a carbon figure a buyer is relying on contractually. In each, the manufacturer’s own database is not persuasive evidence to somebody in dispute with the manufacturer.

It is not real for most passport attributes. Nobody needs cryptographic proof of the timing of a product weight declaration, and adding anchoring everywhere is cost without corresponding benefit.

Which ledger, if any

If anchoring is justified, the choice of ledger should follow from what the anchor has to survive rather than from any technology preference.

• Longevity — the anchor must outlive the product, which for durable goods means decades.
• Independence — a ledger the manufacturer controls proves less than one they do not.
• Cost predictability — transaction cost volatility affects a long-running commitment.
• Energy profile — a sustainability record anchored to an energy-intensive chain invites obvious criticism.
• Verifiability without special software — a verifier should not need a bespoke client.

The first criterion eliminates more options than any other. An anchor is worthless if the ledger holding it stops being maintained, and most ledgers are considerably younger than the service life of the products being anchored.

The permissioned ledger middle ground

Consortium ledgers, where a defined set of organisations operate the network, are frequently proposed as resolving the tension. They deserve a fair hearing because they genuinely change some of the trade-offs.

A permissioned network can enforce access control, which addresses the confidentiality objection, and its participants can agree to correction procedures, which addresses the amendment objection. Transaction costs are predictable and the energy profile is unremarkable.

What it gives up is the property that made a public ledger attractive in the first place. If the organisations operating the network are the same organisations whose claims are being recorded, the record proves considerably less to somebody in dispute with all of them than an independent anchor would.

That is not fatal — a consortium ledger operated by a sector body including buyers, suppliers and an independent auditor is a reasonable trust arrangement. It is simply a governance arrangement rather than a cryptographic guarantee, and it should be evaluated as one.

A defensible position

Hold product data in a conventional versioned store under your own control. Sign claims with verifiable credentials so authenticity does not depend on where the data sits.

Anchor hashes selectively, for the attributes where a dispute with a distrusting party is plausible, and record the anchor as provenance on those attributes rather than as a separate system. This gives tamper-evidence where it is worth having, keeps correction and erasure possible everywhere, and avoids publishing commercial data to a public ledger.

What it does not give is the marketing claim that the passport is on the blockchain. That is the actual trade being made, and it is worth making deliberately rather than by default.

How to evaluate a proposal

Vendors and internal advocates will propose ledger-based designs, and a short set of questions separates the ones worth considering from the ones that have not thought it through.

Ask what specifically goes on the ledger. If the answer includes product data rather than hashes, the erasure and correction problems have not been addressed and the proposal will not survive a data protection review.

Ask who is expected to distrust whom. A ledger is a mechanism for parties without mutual trust, so a proposal that cannot name the distrusting party is solving a problem that has not been identified.

Ask how a record is corrected after an error, and how personal data is erased on request. These have answers in a well-designed system and tend to produce visible discomfort in a poorly designed one.

And ask what happens if the ledger stops being maintained in fifteen years. For durable goods that is well within the product lifetime, and a design with no answer is committing to a dependency it cannot honour.