The Enterprise Blockchain Gap

The Bitcoin whitepaper Satoshi Nakamoto published in 2008 is a short document, nine pages, and the core insight is simple enough to state in one sentence: two parties who do not know or trust each other can exchange value without requiring a central intermediary to guarantee the transaction. The mechanism is a distributed ledger maintained by a network of nodes, where the cost of tampering with any record is made prohibitively high by cryptographic proof-of-work. The insight is genuine. It solved a real problem.

What followed in enterprise circles over the next decade puzzles me every time I think about it carefully. Blockchain for supply chain. Blockchain for healthcare records. Blockchain for interbank settlements. Blockchain for voting. Blockchain for real estate title transfers. The technology was repeatedly proposed for problems that share almost nothing with the problem Nakamoto's design actually solved. And I think the gap between what the technology does and what organizations were asking it to do explains a lot of what happened to enterprise blockchain as the 2010s ended.

The original problem is a trust problem between strangers. If I want to send you bitcoin and we have never met, have no legal relationship, and no shared institution we both trust, the distributed ledger makes the transaction possible without either of us needing to trust the other directly. The math provides the guarantee. No bank, no notary, no government. This is elegant and genuinely novel for the context it was designed for.

Most enterprise transactions are not that context. A large retailer and its tier-one suppliers already have contracts, audited financials, and long commercial relationships. They have a shared ERP platform, or at minimum shared EDI connections. They have lawyers and insurance. The retailer and its suppliers already trust each other, in the legal and institutional sense of the word, or they are not doing business together at all. Adding a blockchain to their data exchange does not change the trust geometry. It adds technical complexity to a relationship that already has institutional mechanisms handling the trust problem.

IBM Food Trust, which was built to track produce from farm to store shelf using a blockchain shared among food producers, distributors, and retailers including Walmart, was a real initiative widely covered in the business press. The logic was appealing: a shared, tamper-resistant record of where food came from, so that contamination could be traced quickly. I do not want to dismiss that as worthless. The traceability goal is genuine and the food safety application makes real sense. But the blockchain component specifically adds value only to the extent that the parties involved cannot trust each other's records, or that a tamper-resistant audit trail matters more than a shared database. Many food safety researchers and IS scholars have questioned whether a well-governed shared database would accomplish the same traceability goal with less overhead, and I have not seen that argument convincingly refuted.

TradeLens, the shipping logistics platform IBM built with Maersk, is probably the clearest case study for what happens when the enterprise blockchain premise collides with reality. The platform aimed to put global shipping data, container movements, customs filings, and freight documents, on a shared blockchain accessible to all parties in a shipping transaction. Maersk and IBM announced it with significant press coverage. By late 2022, TradeLens was shut down. The reasons reported at the time included insufficient adoption by competing shipping lines, who were apparently reluctant to share logistics data on a platform operated by a competitor. My read on this is that the critical failure was not technical. It was that the trust problem the blockchain was supposed to solve, between parties who do not trust each other's data, was also the reason those parties would not join the platform. If they do not trust each other, they will not all sign up for a shared ledger that one of them helps operate.

This is the structural contradiction I keep coming back to in enterprise blockchain. The technology solves the problem of establishing trust without a central authority. But deploying enterprise blockchain requires getting competing parties to agree on governance, on who runs the nodes, on what the rules are for data access and dispute resolution. That governance process is itself a trust problem, and it has to be solved through normal institutional means, lawyers, contracts, standards bodies, before the blockchain can function at all. By the time you have solved that governance problem, you have often already built the trust infrastructure that makes the blockchain's trustless mechanism redundant.

The technology itself is not the issue. Public blockchains like Ethereum have real and documented use cases, particularly for applications where the parties genuinely are anonymous, where the value of decentralization is not just philosophical, and where the overhead of running on a distributed network is worth the censorship resistance or transparency it provides. The critique I am making is specifically about private or consortium blockchains deployed inside organizations that already have central authorities, existing legal relationships, and shared institutional infrastructure. In that context, the blockchain is often doing the job of a distributed database with extra overhead, and the extra overhead is not buying anything.

I think part of what happened is that the Gartner hype cycle played out very visibly. Blockchain climbed to a peak of inflated expectations around 2017 to 2019, and then the trough arrived in the early 2020s. Several high-profile enterprise projects were scaled back or shut down. What remains is a technology that still has genuine applications for specific trust problems, and a lot of expensive lessons about what does not count as one of those problems.