I Am Sick to Death of Hearing That Blockchain Cannot Scale
How academia keeps converting “we could not make our model scale” into “scaling is impossible”—while a BSV implementation is processing more than a million transactions per second
Keywords: blockchain scalability; BSV; Teranode; Bitcoin; transaction throughput; distributed systems; horizontal scaling; block propagation; empirical evidence; blockchain trilemma; SPV; proof of work
I am sitting here waiting to give my presentation, listening—again—to an academic explain that blockchain cannot scale.
Again.
There is something almost comforting about the ritual by now. Somewhere there will be a slide containing a triangle. Somewhere there will be the word trilemma. Somewhere there will be a throughput number inherited from an architecture that somebody deliberately constrained years ago. Somewhere an experiment will have failed, a simulation will have become inconvenient, or a model will have encountered a bottleneck. And then, with the serene confidence available only to people who have converted an engineering assumption into a law of nature, comes the conclusion:
Blockchain cannot scale.
Meanwhile, a BSV Teranode deployment has been demonstrated at more than one million transactions per second.
Not one million transactions per day.
Not an extrapolation from seven transactions per second accompanied by an optimistic arrow.
Not “theoretically, if we shard the shard containing the other shard.”
One million transactions per second.
Amazon Web Services published an engineering account in 2026 describing a six-node, globally distributed Teranode architecture deployed across six AWS regions. The stated target was one million consistent transactions per second with zero transaction loss for at least two weeks. According to AWS, the system achieved it. The current Teranode alpha dashboard has subsequently displayed throughput around 1.05 million transactions per second. The responsible qualification is that these are controlled distributed benchmark and alpha-network results, not evidence that BSV mainnet continuously carries one million transactions per second of organic user demand. That distinction matters. So does the result.
Because once a system has actually processed the workload, the proposition that the workload is impossible becomes rather difficult to maintain.
One may argue about economics. One may argue about topology. One may argue about hardware expenditure, network structure, miner concentration, storage, propagation, validation, commercial demand, or whether the architecture represents one’s preferred conception of decentralisation. Those are all legitimate questions.
But “cannot be done” has acquired an unfortunate empirical problem.
It has been done.
The Most Convenient Impossibility Theorem Ever Invented
The blockchain scaling debate has suffered for years from a remarkably persistent logical error: limitations of a particular implementation are treated as limitations of the underlying class of systems.
This is the sort of reasoning that would have made aviation wonderfully economical.
One builds an aircraft with insufficient lift. It crashes. One publishes Why Heavier-Than-Air Transportation Cannot Scale. The paper acquires citations. A second researcher constructs a mathematical model in which aircraft are required to retain the first aircraft’s wing geometry forever. The impossibility is now formal. A third adds a triangle showing that one may choose only two of lift, speed, and not dying. A literature is born.
Then somebody builds a better aeroplane.
The literature responds that this does not count because the new aircraft violates the assumptions of the model.
Quite.
That is normally what progress looks like.
The crucial distinction is between a protocol constraint, a software constraint, a hardware constraint, an economic constraint, and a fundamental impossibility. These are not synonyms. Yet blockchain discourse has spent an extraordinary amount of time pretending that they are.
If a particular node implementation processes xx transactions per second because validation, networking, mempool handling, block assembly and storage all pass through a monolithic architecture, then xx is evidence about that architecture.
It is not Newton’s constant.
If a protocol artificially limits the amount of transaction data that may be processed in a block, observing that the resulting network has low throughput demonstrates the effect of the limit with admirable precision. It does not demonstrate that removing the limit is forbidden by physics.
And if a researcher models every validating machine as performing every task synchronously on one machine, then discovers that the machine becomes overloaded, the discovery is not that distributed computing has failed.
The discovery is that one computer eventually becomes busy.
Humanity had suspected as much.
Figure 1 — Failure of an Architecture Is Not Impossibility of the Problem
Figure 1. The conceptual error in much of the blockchain scalability debate. An architecture in which validation, networking, storage and block assembly become a single bottleneck can fail to scale. That result does not establish that the functions cannot be decomposed, parallelised and scaled horizontally. The empirical question is whether another architecture can process the workload while preserving the protocol properties under examination.
This distinction is not some eccentric objection invented because BSV happens to produce an inconvenient number. Distributed-systems research has spent decades separating logical functions from particular physical implementations. Horizontal scaling is hardly an occult BSV discovery. Databases do it. Search engines do it. content-delivery systems do it. Payment processors do it. Cloud infrastructure does it.
Apparently, however, the moment one writes the word blockchain, servers acquire a moral obligation to remain small.
One Million Transactions per Second Is Not a Philosophical Opinion
The most interesting thing about the Teranode result is not the headline number. It is what the number does to the structure of the argument.
The BSV Association’s earlier SVNode implementation was monolithic. AWS reports that it had demonstrated a peak of 13,614 transactions per second. Teranode instead decomposes node functionality into a microservice architecture capable of horizontal scaling. Transaction processing, block assembly, validation, storage and related services no longer have to behave as though the proper architecture of a global transaction system were a heroic beige box under somebody’s desk.
AWS describes the benchmark as a progression from a single-region proof of concept to a six-region distributed system. The six nodes were geographically distributed across AWS infrastructure, and the target was not a momentary screenshot of a flattering spike. It was one million consistent TPS with zero transaction loss over approximately a difficulty epoch—two weeks. AWS reports that this target was achieved.
That does not prove everything.
It does not prove infinite throughput.
It does not prove that storage is free.
It does not prove that network bandwidth is infinite.
It does not prove that every machine in the world can validate a million transactions per second.
It does not prove that every economic actor wishes to operate such infrastructure.
It does not prove that future workloads cannot expose another bottleneck.
And it certainly does not prove that every architectural decision made by BSV is optimal.
It proves something much more devastating to the usual argument:
a blockchain architecture can process approximately one million transactions per second.
The proposition being falsified is not “all scaling problems have been solved forever.”
The proposition being falsified is “blockchain cannot scale to this level.”
Academics should know the difference. It is, after all, approximately the difference between science and incantation.
The Wonderful Migration of the Goalposts
Once throughput becomes inconveniently large, the argument changes.
This is perhaps my favourite part.
At seven transactions per second, we are told that transaction throughput proves blockchain cannot scale.
At ten thousand, throughput suddenly ceases to be the relevant measure.
At a million, we discover that what everyone had really meant by “scale” was something else entirely.
Now the objection becomes hardware.
Or node count.
Or storage.
Or bandwidth.
Or decentralisation.
Or the fact that the benchmark used cloud infrastructure.
Or the wonderfully metaphysical objection that although a blockchain processed the transactions, it did not process them in the spiritually correct manner.
This is not analysis. It is a travelling circus.
If the proposition is that throughput cannot scale, throughput is relevant evidence.
If the proposition is that increasing throughput changes the economics of node operation, that is another proposition and should be tested separately.
If the proposition is that miner concentration changes with throughput, measure miner concentration.
If the proposition is that propagation delay becomes prohibitive, measure propagation delay.
If the proposition is that validation cannot keep pace with adversarial blocks containing previously unseen transactions, test precisely that condition.
Indeed, this last point is especially important because Teranode is not magically perfect. A July 2026 Teranode issue documents a serious validation-path problem in which blocks containing transactions not previously observed through propagation could cause validation throughput to collapse to roughly 30–50 TPS on affected nodes. A block of only 27,132 transactions reportedly took more than twelve minutes to validate under those conditions, whereas a much larger block whose transactions were already known could validate vastly faster. That is a real engineering problem and exactly the sort of evidence that should be investigated rather than hidden.
Notice the difference in reasoning.
The childish version says:
Teranode did one million TPS, therefore Teranode has no scaling problems.
That is false.
The equally childish academic version says:
Teranode has encountered a validation bottleneck, therefore blockchain cannot scale.
That is also false.
The useful version says:
A distributed implementation has demonstrated sustained million-TPS processing under specified conditions, while other workload conditions reveal particular validation bottlenecks. Identify the operator constraint, measure it, redesign it, and test again.
That is engineering.
It lacks the intoxicating grandeur of an impossibility theorem, but it has the minor advantage of occasionally producing working systems.
“The Blockchain Trilemma” Is Not a Magical Spell
No discussion of blockchain scaling can proceed for long without someone producing the triangle.
Security.
Decentralisation.
Scalability.
Choose two.
It is an extraordinarily successful diagram. One admires any triangle capable of sustaining this much academic employment.
The underlying insight is perfectly respectable: distributed systems face trade-offs. Higher throughput can increase computation, bandwidth and storage requirements. Some consensus designs improve performance by reducing the number of participants directly involved in particular decisions. Network propagation is finite. Processing is finite. Storage is finite. Adversaries exist. Economic incentives matter.
All true.
What does not follow is that there exists a universal constant fixing a single maximum transaction rate for every blockchain architecture.
Yet papers continue to describe the “blockchain trilemma” in language perilously close to a physical law. A 2025 review describes the simultaneous achievement of scalability, security and decentralisation as continuing to elude most blockchain systems. A 2026 paper proposes a “trilemma-resilient” design. Another 2026 article continues to describe the tension as restricting practical deployment.
The interesting word is most.
Most architectures having a problem does not prove that every architecture must solve the problem in the same way.
More fundamentally, “decentralisation” itself is often left disgracefully underspecified. Does it mean number of listening nodes? Number of block producers? Nakamoto coefficient? Geographic distribution? Ownership concentration? Validation accessibility? Hash-power distribution? Network connectivity? Number of economically independent firms? Permissionless entry?
Gencer et al. showed years ago that decentralisation is multidimensional and must be measured through actual network resources, topology, protocol requirements and resilience.
Once decentralisation is recognised as a vector rather than a religious adjective, the triangle becomes much less impressive.
A trade-off requires variables.
Variables require definitions.
Definitions permit measurement.
And measurement has the terrible habit of interfering with slogans.
Not Every User Is Supposed to Be a Data Centre
A particularly peculiar assumption in scaling arguments is that decentralisation requires every user to process everything.
Why?
The original Bitcoin paper did not say this.
Its Simplified Payment Verification section explicitly describes verification without operating a full network node. A user can retain block headers and obtain a Merkle branch linking a transaction to the block containing it. Businesses receiving frequent payments might choose stronger verification arrangements. The architecture distinguishes users from network nodes.
This distinction matters enormously.
If the scaling criterion is:
Every person using the monetary system must maintain and validate the entire global transaction history on inexpensive consumer hardware forever,
then yes, scaling becomes rather difficult.
So does Visa.
So does Mastercard.
So does the Internet.
So does Google.
So does the global banking system.
So does almost every high-volume information system humanity has ever constructed.
But why would that be the criterion?
Decentralisation does not mean identical duplication of every economic function by every participant. Markets themselves are decentralised systems containing specialised actors. Internet users do not each operate backbone routers. Email users do not each operate a complete global mail archive. People making card payments do not each maintain an acquiring bank.
The relevant question is whether the system permits competitive entry, independent verification appropriate to the actor’s role, enforceable rules, and resistance to unilateral control.
Those are economic and architectural questions.
“How many Raspberry Pis store everything?” is a hardware hobbyist question.
The confusion between the two has cost this field years.
Bigger Blocks Are Not Giant Envelopes Sent Blindly Around the Internet
Another persistent scaling argument imagines block propagation as though a miner constructs a gigantic ZIP file and then, upon finding a block, begins mailing the whole thing from scratch to everyone else.
That would indeed become cumbersome.
Fortunately, computer science did not end in 2009.
Transactions can propagate before block discovery. Receiving nodes can already possess much of the underlying transaction set. Efficient reconciliation can communicate the difference rather than retransmitting everything. Ozisik et al.’s Graphene work demonstrated precisely this principle using Bloom filters and invertible Bloom lookup tables, reducing bandwidth required for block reconciliation and showing that propagation techniques themselves are an engineering variable.
Zhang, Wang and Liew subsequently examined coded and uncoded designs for accelerating block propagation specifically to support blocks containing very large numbers of transactions without proportionately increasing propagation latency.
This does not mean propagation has ceased to matter.
It means propagation technology scales too.
The extraordinary assumption lurking behind many static scaling models is that transaction volume increases while networking, hardware, software architecture, propagation techniques, parallel processing, storage technology and market organisation politely remain frozen.
Under those assumptions, I can prove that London cannot support its present population using the sewerage technology of 1600.
I await publication.
Scaling Is a Function, Not a Number
The academically useful way to discuss blockchain scalability is not to ask:
“How many TPS can blockchain do?”
That question is almost meaningless.
A more sensible representation is:
T=f(B,C,N,P,S,L,A,W)T = f(B, C, N, P, S, L, A, W)
where throughput TT depends upon available bandwidth BB, computational capacity CC, network topology NN, propagation technology PP, storage performance SS, latency LL, software architecture AA, and workload characteristics WW.
One could add economic variables, adversarial conditions, transaction size distributions and validation complexity.
Now something interesting happens.
If those inputs change, throughput changes.
Apparently this revelation is controversial.
A system that parallelises validation differently can process differently.
A system with more bandwidth can transmit more data.
A system using efficient transaction reconciliation can reduce redundant transmission.
A system whose UTXO store has different access characteristics can validate differently.
A microservice architecture can scale functions independently.
A system encountering transactions it has not previously propagated can behave differently from one whose relevant transaction metadata is already cached—as Teranode’s own 2026 validation issue demonstrates particularly clearly.
This is why quoting “TPS” without specifying workload and architecture is often nonsense.
But it is equally why declaring scaling impossible from one fixed architecture is nonsense.
The capacity function moves.
That is what “scaling” means.
Figure 2 — The Academic Argument and the Engineering Argument
Figure 2. The methodological distinction. An impossibility claim requires assumptions sufficiently general to cover the architecture being ruled out. A failed implementation establishes only that the tested implementation failed under the tested conditions. An empirical counterexample does not prove unlimited scalability; it does invalidate a universal throughput claim that the counterexample satisfies.
This is basic logic.
If someone claims:
∀x∈B,T(x)<1,000,000,\forall x \in B,\quad T(x) < 1,000,000,
where BB is the class of blockchain systems, then a single valid x\x^\ satisfying
T(x\)≥1,000,000T(x^\) \ge 1,000,000
is sufficient to falsify the universal statement.
It does not prove:
limr→∞T(x,r)=∞.\lim_{r\rightarrow\infty} T(x,r)=\infty.
In English: demonstrating one million TPS does not prove infinite scalability.
It proves that “blockchains cannot process one million TPS” is false if the demonstrated system satisfies the definition of blockchain used in the claim.
One would hope that an academy capable of teaching predicate logic could survive this distinction.
But It Uses Serious Hardware!
Yes.
It does.
What exactly did we think a global transaction processing network was going to use?
A Casio calculator?
AWS reports that the six-region Teranode benchmark involved substantial cloud infrastructure. The BSV Association’s own description says the six-node test used more than 500 machines of various instance types.
This is not an embarrassment. It is a cost input.
The economic question is therefore not whether hardware exists.
It plainly does.
The question is whether transaction revenue can justify the infrastructure required to process the transaction load.
That is a completely different scaling model.
Suppose processing capacity rises approximately proportionally with deployed resources while average cost per transaction remains sufficiently low. Then higher hardware expenditure at the node level does not imply economic non-scalability. It may imply industrialisation.
We somehow accept without emotional trauma that hyperscale cloud providers operate warehouses full of computers. We accept that payment processors maintain expensive infrastructure. We accept that telecommunications networks contain equipment costing billions.
But let a blockchain miner purchase a server and suddenly Rousseau is summoned from the grave to complain that civilisation has betrayed the noble Raspberry Pi.
Professional transaction processing