Stripped of the surrounding claims, a blockchain solves a narrow and genuinely difficult problem. Understanding what that problem is makes it much easier to assess whether any given application needs one.
The problem
How do parties who do not trust each other, with no central authority, agree on a shared record of what happened?
Specifically, how do you prevent the same digital asset being spent twice, when digital records can be copied freely?
Centralised systems solve this trivially — a bank maintains the record and everyone accepts it.
The problem is only hard when you remove the central authority, and that removal is the entire point.
The mechanism
Transactions are grouped into blocks, each containing a cryptographic reference to the previous one, forming a chain where altering history requires redoing everything after it.
Participants must agree on which chain is valid, which requires a consensus mechanism.
Proof of work makes producing a valid block computationally expensive, so rewriting history costs more than it could gain.
Proof of stake requires participants to lock up value that can be forfeited for misbehaviour, achieving a similar result at far lower energy cost.
Both make dishonesty expensive rather than impossible, which is the actual security model.
The trade-offs
Every property comes at a cost.
Every participant verifying every transaction is enormously less efficient than one party maintaining a database.
Which means throughput is low, cost per transaction is high, and storage grows without bound.
These are not implementation defects to be engineered away. They follow from the design requirement of not trusting anyone.
The scaling approaches
Considerable work has gone into addressing throughput.
Layered approaches conduct transactions off the main chain and settle periodically to it, which preserves the security of the base layer for settlement while moving activity elsewhere.
Partitioning the network so different subsets handle different transactions increases capacity and complicates the security analysis.
Both are genuine engineering and both involve trading some property of the original design for throughput.
The question to ask of any application
Does this involve parties who cannot trust each other and cannot agree on a trusted intermediary?
If a trusted party exists and is acceptable to everyone, a database is better in every respect — faster, cheaper, simpler, correctable.
A great many proposed applications had a perfectly acceptable trusted party and adopted the technology anyway, which is why so many pilots concluded without deployment.
The oracle problem
A limitation that constrains most real-world applications.
A blockchain can guarantee the integrity of data recorded on it. It cannot guarantee that the data corresponded to reality when recorded.
Which means any application depending on physical facts — that goods shipped, that a property exists, that a temperature was maintained — depends on whoever entered that information.
The trust problem is relocated rather than removed, and for supply chain applications in particular, that relocation is where the difficulty actually was.
Immutability as a liability
The inability to alter records is presented as a feature and is frequently a problem.
Errors cannot be corrected. Data required to be deleted under privacy law cannot be deleted. Stolen assets cannot be returned without changing the rules.
Which has led to interventions that contradicted the design principle, and to considerable argument about whether such interventions are legitimate.
Those arguments are not technical. They are governance questions in a system designed to avoid governance.
Where it has held up
The original application — a bearer digital asset transferable without an intermediary — works and has continued working.
Whether that asset should have value is a separate question this does not address.
Beyond that, applications involving settlement between institutions that genuinely do not trust each other have shown more durability than consumer applications.
The honest position after more than a decade is that the technology does a specific thing reliably and that the range of situations requiring that specific thing is narrower than the enthusiasm suggested.
This is a technical description and is not a view on whether any asset is worth holding. This is a highly volatile area and total loss is a realistic outcome.
Permissioned variants
Where most institutional experimentation actually went.
A permissioned ledger restricts participation to known, vetted parties, which removes the need for expensive consensus mechanisms since participants can be held accountable by contract and by law.
Which makes them far faster and cheaper than open networks.
It also means they are, functionally, shared databases with cryptographic integrity checks, and the honest question is whether that required the surrounding framework at all.
Several large pilots concluded that a well-designed shared database with strong audit would have achieved the same result, which is why many were quietly wound down.
Governance in practice
Open networks face decisions about protocol changes with no formal decision-making body.
In practice, influence sits with core developers, large holders, exchanges and, where applicable, those providing computational resources.
Disagreements that cannot be resolved result in the network splitting into two, which has happened several times.
Which demonstrates that removing formal governance does not remove governance, it makes it informal and harder to observe.