Few technologies have had a wider gap between what was claimed for them and what they turned out to be good at.
Separating the achievement from the marketing
The underlying result is genuine and worth stating clearly before the criticism.
The problem solved is this: allowing a set of parties who do not trust each other, with no central authority, to agree on an ordered record of events, in a way that resists participants attempting to cheat. That had been an open problem in distributed computing for a long time, and the combination of cryptographic linking, economic incentive and consensus mechanism that addressed it is a real contribution.
The cost of that property is the part that gets omitted.
Every participant stores and verifies the same data, which is enormously less efficient than one database doing the work once.
Throughput is limited by design, because agreement among many parties takes time.
Changing anything requires coordination among participants who may disagree, which is the point and is also why these systems evolve slowly.
You are paying a very large efficiency cost for one property: not needing a trusted central party. If you have one, you are paying for nothing.
That single sentence explains most of what happened to enterprise blockchain between the announcements and the quiet discontinuations.
What the direction covers
The scope: distributed databases, blockchains, smart contracts, consensus, digital assets and decentralised applications.
Four areas.
Distributed systems foundations. Replication, consistency, partition behaviour and consensus algorithms, most of which predate blockchain entirely.
Cryptographic building blocks. Hashing, signatures, key management and what each actually guarantees.
Smart contracts. Programming models, execution environments and the security practice specific to them.
Applications and regulation. Where these systems are genuinely used, and the legal framework now forming around them.
The question that kills most projects
A large number of corporate blockchain initiatives were announced between the middle of the last decade and the early part of this one. A large number were quietly discontinued. The reason was consistent, and it can be reduced to one diagnostic.
Is there a party that all participants trust to maintain the record? If yes, a database run by that party is faster, cheaper, easier to change and easier to recover. Almost every enterprise consortium had such a party, or could appoint one.
Three further questions that eliminate most of the remainder.
Does the data describe the physical world? If so, the chain records what someone entered. A tamper-evident record of an unverified claim is a tamper-evident unverified claim. Supply chain provenance projects ran into exactly this: the difficulty was never the database, it was knowing whether the item in the box matched the label.
Does anything need to be deleted or corrected? Immutability conflicts with data protection rights, with error correction and with legal obligations to remove information. This is a genuine incompatibility rather than an implementation detail.
Will the participants actually operate nodes? Many consortium chains ended up running on infrastructure operated by one company, which is a database with extra steps and worse performance.
What survives that filter is a narrow set: systems where participants genuinely do not trust each other, where there is no acceptable central operator, and where the data is native to the system rather than a claim about the world. Digital assets, some settlement and clearing applications, and certain cross-border arrangements fall inside it. Most other things do not, and saying so is more useful than enthusiasm.
Where this sits in the domain
Blockchain and distributed systems is the eighth of eight directions in Astra Trainer's AI, data and computing domain, and it is deliberately framed around the distributed systems half. The consensus, replication and consistency material is the durable part and transfers to a great deal of ordinary engineering.
It connects to computer science for the distributed systems foundations, to cybersecurity for key management and contract security, and to cloud computing and DevOps for the infrastructure these networks run on. You can see the eight directions here.
Why smart contract security is unlike other security
The most technically distinctive area in this direction, and the one where the failure record is instructive.
A smart contract is code deployed to a chain that executes automatically. Four properties combine to make its security problem unusually unforgiving.
The code is usually immutable once deployed. A defect cannot be patched in the way ordinary software is. Upgrade patterns exist and introduce their own risks, including the centralised control they are supposed to avoid.
It holds value directly. Exploiting a defect is not a step towards a goal, it is the goal, and the proceeds are immediately transferable.
Everyone can read it. The deployed code is public, so anyone can look for flaws at their leisure, with a direct financial incentive to find one.
Execution is adversarial by default. Transaction ordering can be manipulated, external calls can re-enter the contract before it finishes, price sources can be moved, and the assumption that a called contract behaves reasonably is unsafe.
The result is that very large sums have been lost to defects that would have been unremarkable bugs in conventional software. The engineering response has been correspondingly strict: formal verification, multiple independent audits, extensive adversarial testing and staged deployment with value limits. That discipline is genuinely valuable and transfers well to any high-consequence software.
Where the distributed systems knowledge actually pays
The practical reason to teach this direction, separate from digital assets entirely.
The foundations underneath blockchain are the foundations underneath a great deal of modern infrastructure, and most engineers hold them loosely.
Consensus algorithms run inside the coordination systems that databases, orchestrators and service meshes depend on.
Consistency models. Understanding what a distributed store actually guarantees, and what it does not, prevents a class of data corruption that is difficult to detect and harder to explain.
Partition behaviour. Every distributed system has to choose what it does when parts of it cannot communicate, and the choice has consequences the application must handle.
Cryptographic verification. Hashing, signatures and tamper-evident structures are used far beyond this direction, in software supply chain integrity, audit logs and document verification.
Key management. The hardest operational problem in this area, and one that applies wherever cryptography is used. Lost keys mean lost access with no recovery, which is a workflow and governance problem rather than a mathematical one.
An organisation that trains people here gets distributed systems engineers, which is a scarce and durable capability regardless of what happens to the asset markets.
The roles, named
Distributed systems engineers. The broadest and most durable role.
Smart contract developers.
Smart contract auditors and security researchers, a genuinely specialist and well-paid group.
Protocol engineers, working on the networks themselves.
Cryptography engineers.
Blockchain infrastructure and node operations engineers.
Digital asset custody and key management specialists.
Compliance and regulatory specialists for digital assets, an area growing quickly as regimes come into force.
Blockchain analysts, tracing on-chain activity, used heavily in investigation and enforcement.
Who can be trained into it
Backend and systems engineers. The main route. Distributed systems concepts build on what they already know, and the cryptographic layer is a defined addition.
Security engineers. Into smart contract auditing, where adversarial thinking is the core skill and the domain specifics are learnable.
Database engineers. Into distributed data systems, already holding consistency and replication concepts.
Financial systems engineers. Into settlement and custody applications, where the domain half is the scarce part.
Compliance and financial crime professionals. Into digital asset compliance and on-chain analysis, where existing investigative method transfers directly.
Cryptography and mathematics graduates. Into protocol engineering.
Auditors. Into contract review process and governance, complementing rather than replacing technical audit.
Regulation, custody and irreversibility. Digital assets are subject to financial regulation, tax treatment, anti-money-laundering obligations and securities law that differ substantially by jurisdiction and are changing quickly. Transactions are generally irreversible, and loss or compromise of keys usually means permanent loss with no recovery mechanism. Immutable records can conflict with data protection rights, including rights to erasure and correction. Nothing here is investment, legal or tax advice, and nothing here is a recommendation regarding any asset. Organisations should take qualified professional advice before any deployment or holding.
What to take from this
Distributed consensus among untrusting parties is a real achievement, and it is expensive by design because that is what the property costs.
The diagnostic that ended most enterprise projects is simple: if a trusted party exists, a database is better in every dimension that matters.
Recording a claim about the physical world on a chain makes it tamper-evident, not true.
Smart contract security is unusually unforgiving because the code is immutable, public, adversarially executed and holds value directly, and the resulting engineering discipline is worth borrowing elsewhere.
And the durable reason to teach this is distributed systems capability, which stays valuable no matter what happens to the asset markets.
What problem does a blockchain actually solve?
Letting parties who do not trust each other agree on an ordered record without a central authority. That property is real and costs a great deal in efficiency, because every participant stores and verifies the same data.
Why did most enterprise blockchain projects stop?
Because a trusted party existed or could be appointed, which makes a conventional database faster, cheaper and easier to change. Many consortium chains also ended up operated by a single company, which removes the reason for using one.
Can a blockchain guarantee supply chain provenance?
It can make the record tamper-evident. It cannot verify that what someone entered matches physical reality, and that verification was always the hard part.
Why is smart contract security so difficult?
Because deployed code is usually immutable, is publicly readable, holds value directly and executes in an adversarial environment where transaction ordering, re-entrant calls and manipulated price sources are routine attack methods.
Is this worth training for?
The distributed systems half is, unconditionally. Consensus, consistency models, partition behaviour, cryptographic verification and key management apply across modern infrastructure regardless of digital asset markets.