The Blockchain + AI Reality Check — Part 2 of 3
The Scalability Wall: Can Blockchain Actually Handle Daily Life?
In Part 1 of this series, I argued that AI-generated content provenance is one of the strongest cases for blockchain + AI. Every photo signed at capture, every AI image marked at generation — verifiable across the internet.
A thoughtful reader pushed back: Hold on. If every photo gets a hash recorded on chain, we’re talking about volumes far beyond what any blockchain can handle today. How does that actually work?
It’s the right question. And the answer reveals one of the most important — and most under-explained — design patterns in the entire blockchain space.
The Numbers Are Absurd
Roughly 5 billion photos are taken globally per day. That’s about 57,000 photos per second.
Now compare that to actual blockchain throughput:
| Blockchain | Transactions per second |
|---|---|
| Bitcoin | ~7 |
| Ethereum mainnet | ~15–30 |
| Solana (one of the fastest) | ~3,000–5,000 |
Even Solana — among the highest-throughput major chains — would need to be ten times faster just to log every photo. And that’s only photos. Add medical records, IoT sensor data, supply chain events, and AI outputs, and you’ve blown through the throughput budget of every blockchain combined.
Worse: every node has to store this. Within a year you’d be looking at petabytes per chain, and only data centers could afford to run nodes. At that point you’ve recreated the centralization you were trying to avoid.
So is the whole vision a fantasy? No — but it requires a clever workaround.
The Trick: Merkle Trees
The fundamental insight is this: you don’t put individual data items on the chain. You put a fingerprint of a giant batch of them.
Think of a single-elimination tournament bracket. Imagine one million photo hashes as players in round one. You pair them up and hash each pair together, producing 500,000 winners. Pair those up again — 250,000. Keep going until you have one champion: a single 32-byte value called the Merkle root.
That root is a cryptographic summary of all one million original hashes. Change any single photo, and the root changes completely. So if I publish the root somewhere tamper-resistant, the entire batch is locked in.
Here’s the magic part: even though the root is just 32 bytes, you can prove that any specific photo was in the original million using only about 20 hashes (a “Merkle proof”). Verification is fast and fits in a few kilobytes.
So the actual architecture for content provenance looks like this:
- Cameras around the world capture photos and hash them locally
- Every second, a coordinator collects one million hashes from that second
- The Merkle root of those million is recorded on chain — one transaction per second
- Each photo carries its Merkle proof as metadata (a few KB)
- Anyone can verify the photo by checking the proof against the on-chain root
One million photos per second processed, one blockchain transaction per second posted. Storage on chain is constant: 32 bytes per batch, regardless of how many photos.
This isn’t theoretical. It’s the foundation of every Ethereum Layer 2 (Arbitrum, Optimism, Base, zkSync) — they batch thousands of user transactions and post only a root to Ethereum mainnet. The same pattern scales to any high-volume use case.
The Even More Honest Question
Now, here’s where it gets philosophically interesting. Once you understand the Merkle batching trick, a follow-up question becomes obvious:
If we’re just publishing a single root hash per second, do we even need a blockchain to publish it?
You could publish it on a regular website. In a New York Times notice ad. In a Git commit. As long as a lot of people see and timestamp it, the root is effectively unforgeable.
This is the dirty secret of large parts of the blockchain industry: many “blockchain” applications could work just as well without one. The current Content Authenticity Initiative (C2PA), the actual production system implementing photo provenance, barely uses blockchain at all. It uses traditional PKI — the same certificate system that powers HTTPS and your country’s e-government login.
The camera manufacturer issues a certificate. That certificate signs photos. A trusted root authority manages the list of valid camera manufacturers. Done.
So where does blockchain genuinely add value?
The honest answer is narrow: when you can’t agree on a single trust authority.
In photo provenance, Adobe maintaining the “valid manufacturers list” is fine for most purposes — they have no incentive to cheat, the list is auditable. If you don’t trust Adobe specifically, you can switch to a competitor.
But for cross-border systems, multi-corporation consortiums, or politically contested domains (cryptocurrency itself, international medical records, election integrity), there is no neutral party everyone trusts. That’s where decentralizing the trust list onto a blockchain actually justifies the complexity cost.
The Blockchain Trilemma in One Sentence
Blockchain engineers have a name for this trade-off: the Blockchain Trilemma. Coined by Vitalik Buterin, it states that any blockchain has to compromise on at least one of three properties:
- Decentralization (lots of independent nodes, no single point of control)
- Security (resistance to attack)
- Scalability (throughput)
Bitcoin chose decentralization and security, sacrificing scalability (7 TPS). Solana chose scalability and security, sacrificing decentralization (fewer, more powerful nodes). Most chains pick two of three.
Merkle batching is the most important technique for working around this — it lets a low-throughput, highly decentralized chain “anchor” enormous volumes of off-chain activity. Layer 2s like Arbitrum and Base are this pattern productized.
What This Means for Real Applications
If you’re evaluating any blockchain product or pitch, the scalability question can be cut into pieces:
1. How much data goes on chain? If the answer is “every event,” it doesn’t scale. If the answer is “a root hash per minute summarizing all events,” it does.
2. Where does the actual data live? Real-world systems store data off-chain — on IPFS, AWS, the user’s own device — and only put proofs on chain.
3. Who runs the batching coordinator? This is the centralization risk that Merkle batching introduces. Be skeptical of designs where one party batches everything.
4. Could a regular database solve this? Always ask this. If the answer is yes, the blockchain is decoration.
Closing Thought
The scalability question I started with is real. But the technical solutions are well-developed. The harder question — the one blockchain engineers wrestle with constantly — is the philosophical one.
When you actually need to coordinate trust across parties that don’t trust each other, blockchain pays for its complexity. When you’re just looking for a slightly fancier database, it doesn’t.
The good news is that the genuine cases exist. The bad news is they’re narrower than the marketing suggests.
Next in this series: a deep look at Korea’s medical mydata initiative (건강정보 고속도로) — where blockchain could legitimately add value, where the law fights against it, and what an honest assessment of the future looks like. Coming in Part 3.
Written by ChainLab — Chain Within Your Life. We build blockchain infrastructure for the real world. chainlab.dev
