Every design increasing transaction capacity gives something up, and identifying what is given up is more useful than comparing headline figures.
The constraint
Every validating node must process every transaction in the base model.
Which means capacity is bounded by what an ordinary node can handle.
Raising that bound raises the cost of running a node, which reduces how many people verify independently.
Larger blocks
The direct approach, increasing bandwidth, storage and processing requirements proportionally.
Which works and shifts node operation toward professional infrastructure.
This trade-off has been the subject of substantial and lasting disagreement in more than one community.
Parallel execution
Processing non-conflicting transactions simultaneously.
Which requires knowing in advance which state each transaction touches.
Designs either require declaration of accessed state or detect conflicts optimistically and re-execute.
Sharding
Splitting state across subsets of validators.
Which increases capacity and complicates cross-shard transactions considerably.
Several projects have found full execution sharding harder to deliver than anticipated, and some have redirected toward data availability instead.
State growth
The accumulated state that nodes must store grows continuously.
Which is a distinct problem from transaction throughput and affects node requirements over time.
Expiry and rent proposals address it and are difficult to adopt because they affect existing contracts.
Statelessness
Allowing verification without storing full state, using proofs supplied with blocks.
Which would substantially reduce node requirements.
The cryptographic structures required are an active area of development.
Data availability sampling
Verifying that data was published by sampling small portions.
Which allows light nodes to check availability without downloading everything.
It is a foundation for scaling designs where execution happens on separate layers.
Reading claims
Ask what hardware a validating node requires, how many independent validators exist, and whether the quoted figure was measured under realistic conditions.
Peak throughput under ideal conditions with a small validator set is a different claim from sustained throughput with broad participation.
Block time versus finality
Fast blocks do not mean fast settlement if finality requires many blocks.
Which is frequently conflated in marketing comparisons.
The question that matters is how long until a transaction cannot be reversed.
Congestion behaviour
How a network behaves under sustained demand differs from its performance under test conditions.
Which has produced outages on networks with high nominal throughput.
Fee markets exist partly to allocate capacity gracefully under load rather than failing.
Hardware requirements over time
Requirements ratchet upward as state grows even without parameter changes.
Which gradually reduces the number of independent verifiers.
Some designs address this explicitly and most do not.
Archive nodes
Storing full historical state requires substantially more resources than validating current state.
Which means historical data access is increasingly provided by a small number of operators.
This is a real and underdiscussed centralisation point for applications depending on history.
The honest comparison
Capacity, decentralisation and security trade against each other, and every design picks a point on that surface.
Modular versus monolithic
Separating execution, settlement, consensus and data availability into distinct layers.
Which allows each to be optimised independently and adds complexity at the boundaries.
Monolithic designs keep everything together, arguing that the boundaries themselves are the risk.
Light clients
Verifying with minimal resources using proofs rather than full state.
Which is what allows verification on constrained devices.
Support varies considerably between networks and determines whether users can verify anything themselves.
Mempool design
How pending transactions are propagated and ordered affects both throughput and fairness.
Which includes whether the mempool is public, private or encrypted.
Encrypted mempool designs aim to prevent extraction based on transaction content before ordering.
Measuring honestly
Sustained throughput with realistic transaction mixes, full validator participation and stated hardware requirements.
Which is rarely how figures are quoted.
Independent measurement of live networks is available and generally shows lower figures than marketing.
The persistent trade-off
Every capacity gain costs something in verification accessibility, and naming that cost is the honest presentation.
What actually constrains adoption
For most applications, capacity has not been the binding constraint for some time.
Which shifts attention to usability, distribution and whether anything is being built that people want.
Throughput comparisons occupy more discussion than their practical importance justifies.
Closing
Ask what a design gives up, since every one of them gives up something.
Network effects
Applications, liquidity and developer familiarity concentrate rather than distributing evenly.
Which means technical capacity is only one factor in where activity goes.
Several technically capable networks have struggled to attract usage regardless of their throughput figures.
Practical reading
Independent measurement of live networks under real conditions is published and is more useful than specification claims.
The useful habit when reading any capacity claim is to ask what a node costs to run and how many independent ones exist, since that is what the number was traded against.
One last point
Capacity has rarely been the reason an application failed to find users, which is worth remembering when comparing networks on that basis alone.