In the 24 hours to 09:41 UTC on 11 November 2026, the Bitcoin network settled 647,898 transactions, about 7.5 a second, according to block data from mempool.space. Ethereum’s main chain handled roughly 23 a second that morning. Solana managed about 1,265 a second in the hour to 09:45 UTC. Visa says its card network can process up to 83,000 transaction messages a second. That gap is what blockchain scalability is about, and it is not quite the gap most people imagine.
None of the blockchain figures above is an engineering accident. Each one is a choice about who can still check the chain. A Bitcoin node runs on an ordinary computer with 2 GB of memory and, in pruned mode, about 7 GB of free disk. Ethereum asks for 16 GB of memory and a 4 TB SSD. For a Solana validator, Anza lists a 12-core server, several fast SSDs and a connection of at least 2 gigabits per second, and suggests a motherboard that can take 512 GB of memory.
Why that trade-off exists is the subject here. The 2015-2017 fight over Bitcoin’s block size turned on it, and so does each of the main answers since: bigger blocks, sharding, layer 2s and data availability. The lesson assumes you know what a blockchain is and builds on our introduction to Ethereum, its accounts and its validators.
Blockchain scalability means more transactions without fewer verifiers
Scaling a blockchain means letting it process more transactions, at lower cost, without shrinking the group of people who can check it on their own. The last part is what separates it from scaling a website.
An online shop handles holiday traffic by renting more servers. Nobody outside the company verifies its orders, so the extra machines only have to be fast. A public blockchain makes a different promise: anyone, anywhere, can verify every balance and every rule without trusting the company, the miner or the validator that produced a block. That promise is the product. It is also what gets expensive as usage grows, because every extra transaction is extra work for every person who keeps that promise alive.
Vitalik Buterin, Ethereum’s co-founder, put rough numbers on the problem in his May 2021 essay The Limits to Blockchain Scalability. His argument is that a chain stays decentralized only if regular users can run a node, and that such a node can only give part of its machine to the chain: he suggested that about 5 to 10% of its processing power should go to verifying blocks, and put the right storage budget at around 512 gigabytes rather than 10 terabytes. Under those limits, he wrote, blocks of perhaps 1 to 5 MB every 12 seconds might be reachable, and even that would be hard.
So a transactions-per-second figure is a measure, not the goal. The useful questions are about the person at the edge of the network: what machine do they need, how much bandwidth, how much disk, and what are they asked to trust if they cannot afford those?
The real bottleneck: every full node checks everything
Re-execute, store, relay: the work behind each block
A full node does not take a block on faith. When one arrives, it checks the signatures, re-runs every transaction against the current state, confirms the block follows every rule of the protocol, stores it and passes it on to its peers. Our guide to what a node does and the different kinds of node covers that cycle in detail; what matters here is the bill it creates.
On Bitcoin, Blockchair put the full chain at about 782 GB on 11 November 2026. The bitcoin.org page on running a full node (undated) says a first start downloads around 740 GB, asks for at least 2 GB of memory and an upload speed of at least 400 kilobits per second, and notes that pruning can cut disk use to about 7 GB. Pruning does not skip the checking: the node still downloads and verifies every block since 2009, then throws old ones away.
On Ethereum the load is heavier because every transaction may run a program. The ethereum.org guide to running a node, updated on 29 October 2026, gives a minimum of 2 or more cores, 16 GB of memory, a 4 TB NVMe SSD and 25 Mbit/s. Its recommended setup, taken from EIP-7870, is 4 or more fast cores, 32 GB of memory and 50 Mbit/s down, with more for anyone running a validator.
Every extra transaction a second adds to all of these numbers, on every node, for good. It has to be checked once by each machine, stored unless the node prunes, sent to peers, and replayed by every new node that joins in the years that follow.
Why a bigger network is not a faster one
In most computer systems, adding machines adds capacity. In a blockchain, adding nodes adds copies. Ten thousand nodes doing the same work process exactly as many transactions as one of them would. That redundancy is the price of not trusting anyone, and it is why the slowest machine the network wants to keep sets the pace.
Time matters as well as size. A new block has to reach most of the network before the next one appears. When blocks get larger or come faster, more nodes are still downloading the previous one when a competitor turns up, and two valid blocks at the same height end with one being dropped. Miners and validators with the best connections lose fewer blocks that way, so pushing the limits slowly favours large, well-connected operators over small ones.
The scalability trilemma: Buterin’s pick-two framing
Buterin gave the problem its best-known name in a post of 7 April 2021, Why sharding is great. He described three properties a chain would like to have. Scalability, in his words, means that “the chain can process more transactions than a single regular node (think: a consumer laptop) can verify”. Decentralization means the chain runs without depending on trust in a small group of large, centralized actors. Security means it can resist a large share of its own participants trying to attack it.
He then sorted existing designs into three families, each holding two of the three properties. Traditional blockchains such as Bitcoin, Ethereum before proof of stake and sharding, and Litecoin ask every participant to run a full node that verifies every transaction: decentralized and secure, but not scalable. High-throughput chains rely on a small set of nodes, which he put at often 10 to 100, to keep consensus among themselves: scalable and secure, but less decentralized. Multi-chain ecosystems spread applications across many separate chains that talk to each other: scalable and decentralized, but each chain carries only part of the security, so an attacker who captures one chain’s consensus can break it and possibly harm applications linked to it.
Two cautions. The trilemma is a framing, not a theorem: nobody has proved that the three properties cannot coexist. And the designs Ethereum adopted later, sharding first and rollups since, are attempts to escape it by letting an ordinary node confirm that work was done correctly without redoing all of it. Whether they fully succeed is still argued over, and later lessons of this path look at each one.
Bigger blocks: the Bitcoin block size war as a scaling choice
The most obvious way to fit more transactions is to make blocks bigger. Bitcoin spent most of 2015 to 2017 fighting over exactly that, and the fight shows the trilemma better than any diagram.
A 1 MB cap added in 2010
Bitcoin started without an explicit limit on block size. In 2010, Satoshi Nakamoto added a cap of 1,000,000 bytes in two code changes that were not announced, according to the Bitcoin Wiki’s history of the controversy. Satoshi never published a reason; it is widely understood as an anti-spam measure, protecting a young network with almost no fees from being flooded with junk blocks.
Later that year a user proposed a patch raising the limit. On 3 October 2010, Satoshi replied on the BitcoinTalk forum that applying it would make the user incompatible with the rest of the network, and added: “We can phase in a change later if we get closer to needing it.” Both camps would quote that sentence for years. One side read a promise to raise the limit; the other read a warning that any change must keep the whole network together.
What the big-block side argued
For the big-block camp, Bitcoin’s purpose was in the title of its white paper: peer-to-peer electronic cash. If blocks stayed at 1 MB while usage grew, fees would rise until small payments made no sense on-chain, and users would drift to custodial services, the opposite of the original idea. Hardware and bandwidth get cheaper every year, they argued, so a moderate increase would not push ordinary users off the network, while off-chain systems that could carry everyday payments were not ready.
Their proposals were concrete. Bitcoin XT shipped BIP 101, which would have raised the limit to 8 MB once 75% of miners signalled for it, then doubled it every two years; it never activated. Bitcoin Classic proposed BIP 109, a hard fork to 2 MB in 2016, with a limit that would adjust itself afterwards. Neither gathered the support it needed.
What the small-block side argued
The small-block camp started from the node, not the payment. Bigger blocks mean more bandwidth, more disk and longer initial syncs, and every increase prices some users out of verifying the chain themselves. Larger blocks also travel more slowly, which, as described above, favours large miners with fast links and pushes the network toward a few big players.
They also feared the method. Raising the limit required a hard fork, a rule change that old software rejects, and a contested hard fork could split the network and its coin in two. And they doubted that any fixed size would ever be enough: demand for cheap, permanent block space is close to unlimited, so a bigger block would fill up too, only later. Their answer was to keep the base layer small and easy to verify, and to move everyday payments to layers built on top of it.
Strip away the personalities and both sides accepted the trilemma. They disagreed on which corner to give up and on who had the right to decide.
How it ended: SegWit, Bitcoin Cash and the cancelled 2 MB fork
The end game ran over six months of 2017, and our guide to Bitcoin governance and the BIP process tells it step by step. In short: the New York Agreement of 23 May 2017 paired SegWit with a later hard fork to 2 MB (the SegWit2x plan); a group of big-block supporters split off on 1 August 2017 and created Bitcoin Cash, a separate chain with larger blocks; SegWit became active on Bitcoin on 24 August 2017 at block 481,824; and the 2 MB part of SegWit2x was called off on 8 November 2017. How a chain splits in two is covered in our guide to hard forks, soft forks and chain splits.
SegWit did raise capacity, in a roundabout way. It replaced the 1 MB size cap with a limit of 4 million weight units, defined in BIP 141, in which signature data counts for less; our guide to SegWit and Taproot explains the weight system. Over the 144 blocks to 09:41 UTC on 11 November 2026, the average block measured 1.62 MB and 3,943,565 weight units, about 99% of the limit, according to mempool.space data.
Those numbers also show where the famous figure of 7 transactions a second comes from. A full block holds roughly 1 million virtual bytes. The average transaction in those 144 blocks took about 219 of them, so a block carried about 4,500 transactions, and at one block every ten minutes that is about 7.5 a second. Smaller transactions push the rate up: in the last 15 blocks of the same sample, blocks of up to 7,600 small transactions lifted it to about 14 a second. The honest phrasing is about 7 a second on average, more when transactions are small, not a hard ceiling of 7.
When demand outruns block space, fees go up
Block space is fixed in the short run, so when more people want in than there is room for, they bid. On Bitcoin, users offer a fee per virtual byte and miners pick the best offers. On Ethereum, a base fee rises automatically whenever blocks run above their target and falls when they run below it. Both mechanisms are covered in full in our guides to the Bitcoin mempool and transaction fees and to Ethereum gas and EIP-1559.
On 20 April 2024, the day of Bitcoin’s fourth halving and of the launch of the Runes token protocol, fees averaged 9.67 BTC per block, and block 840,000 alone paid 37.63 BTC in fees against a 3.125 BTC block reward. On Ethereum, on 1 May 2022, during the Otherside land sale, a simple ether transfer cost about $28.16 at Etherscan’s average gas price for the day.
Fees are calm as of November 2026. The same Ethereum transfer cost about $0.033 on 9 November 2026, and Blockchair put Bitcoin’s average fee over the 24 hours to 11 November 2026 at about $0.32. Calm fees do not mean the problem is solved. They mean that, for now, demand fits in the space available, a space that on Ethereum has been widened several times since 2022.
Faster, bigger or layered: the menu of answers
Every scaling design moves some work, some data or some trust away from the ordinary node. Reading them that way makes the menu easier to compare.
Bigger and faster blocks on layer 1
Solana is the clearest case of a chain that chose raw layer 1 throughput. Its slots now target 200 milliseconds, down from 400, and on 21 October 2026 it switched to a new consensus system, the Alpenglow upgrade that went live on Solana mainnet; on-chain block times show the last block under the old system at 13:54:00 UTC that day. Solana’s public RPC showed an average slot of about 215 ms and about 1,265 transactions a second over the hour to 09:45 UTC on 11 November 2026. Validator votes no longer appear as on-chain transactions since Alpenglow, so that figure is all user activity; older headline numbers that counted votes cannot be compared with it.
The cost shows in the validator requirements published by Anza, which maintains Solana’s main client: a processor with at least 12 cores and 24 threads at 2.8 GHz or more, separate NVMe drives of 1 TB or more for accounts and for the ledger plus 500 GB for snapshots, a motherboard with 512 GB of memory capacity suggested, and a symmetric connection of at least 2 Gbit/s, with 10 Gbit/s recommended. That is data-centre hardware. Solana’s design accepts that the people who verify in full will be professionals, and works on keeping that group large and spread out.
Ethereum has also widened its own blocks, in small steps. Validators can nudge the gas limit up or down with a client setting, without a hard fork, and they raised it from 30 million gas (in place since August 2021) to about 36 million in February 2025, 45 million in July 2025 and 60 million at the end of November 2025. A block read on 11 November 2026 still showed a limit of 60,000,000, and a sample of 60 recent blocks used 28.7 million gas on average, just under the 30 million target. More room per block also means more work per node. The setup ethereum.org recommends now has 32 GB of memory, twice its minimum.
Sharding, and why Ethereum changed plan
Sharding splits a chain into many parallel pieces, so that each node checks only some of them while the system as a whole carries far more. For years it was Ethereum’s main scaling plan. On 2 October 2020, Buterin published A rollup-centric Ethereum roadmap, arguing that the ecosystem was “likely to be all-in on rollups”. In the long run, he wrote, the base layer would offer one high-security execution shard that everyone processes, plus a scalable data availability layer.
The ethereum.org scaling pages now describe that change: instead of splitting execution across shards, Ethereum shards data, through blobs and the longer-term plan known as danksharding, and leaves most execution to rollups. The chain stopped trying to run everything faster and started trying to be the place where other systems publish their data and settle.
Layer 2s: channels, rollups and sidechains
A layer 2 runs transactions away from the main chain and relies on that chain for its final settlement. Our guide to layer 1 versus layer 2 already covers the basics, from sequencers and withdrawal delays to the maturity stages tracked by ETHBEAT, formerly L2BEAT. Three families of layer 2 differ in what they borrow from the main chain.
Payment channels lock funds on the main chain with one transaction, let two parties exchange signed updates between themselves as often as they like, and settle the final balance with another transaction. The Lightning Network on Bitcoin is the best-known example, and the answer the small-block camp had in mind.
Rollups run transactions in batches off-chain and post the data, compressed, together with a commitment to the result, to Ethereum. The two main kinds, optimistic and zero-knowledge, differ in how they prove the result is right; later lessons of this path, on layer 2 rollups, optimistic rollups and ZK rollups, take them one by one. Base and Arbitrum One were the largest by value secured as of 11 November 2026, according to ETHBEAT.
Sidechains are separate blockchains with their own validators, linked to a main chain by a bridge. They can be fast and cheap, but their security is their own, not the main chain’s: if their validators misbehave, the main chain cannot step in. A later lesson compares sidechains and rollups in detail.
Data availability, the part most explanations skip
A rollup is only as trustworthy as its data. If anyone can download the transactions a rollup posted, anyone can rebuild its state, check its operator and, if needed, prove their own balance to withdraw. If the operator withholds that data, users are stuck with its word. So the question becomes: where is the data published, and can ordinary nodes confirm it is really there?
Ethereum’s answer is blobs. Since the Dencun upgrade of 13 March 2024, rollups have posted their data in these separate packets, which are cheaper than ordinary transaction data because nodes keep them only for a limited period rather than forever. The Fusaka upgrade, live on 3 December 2025, added PeerDAS: instead of every node downloading every blob in full, nodes download parts and sample the rest, so the number of blobs can grow without each node’s bandwidth growing in step. That is the trilemma escape in practice, checking that work was done without redoing all of it.
Ethereum’s scaling steps, dated
The table below lists the main capacity changes on Ethereum’s main chain since blobs arrived. Blob figures are the target and maximum per block; the fee effects are covered in our gas guide.
| Date | Change | What it added |
|---|---|---|
| 13 March 2024 | Dencun upgrade (EIP-4844) | Blobs for rollup data, target 3 and maximum 6 per block |
| 4 February 2025 | Gas limit raised by validators | About 36 million gas per block, from 30 million |
| 7 May 2025 | Pectra upgrade | Blob target 6, maximum 9 |
| 24 July 2025 | Gas limit raised by validators | 45 million gas |
| 30 November 2025 | Gas limit raised by validators | About 60 million gas |
| 3 December 2025, 21:49 UTC | Fusaka upgrade | PeerDAS data sampling; 60 million gas as client default; per-transaction cap of 16,777,216 gas (EIP-7825) |
| 9 December 2025, 14:21 UTC | BPO1 fork (blob parameters only) | Blob target 10, maximum 15 |
| 7 January 2026, 01:01 UTC | BPO2 fork (blob parameters only) | Blob target 14, maximum 21 |
| 6 October 2026 | Glamsterdam on the Sepolia testnet | No mainnet date as of 11 November 2026 |
The Fusaka and BPO dates and blob numbers come from the Ethereum Foundation’s Fusaka mainnet announcement of 6 November 2025; BPO stands for blob-parameter-only, small forks that change nothing but the blob numbers. On the 60 sampled blocks of 11 November 2026, the chain carried about 6.5 blobs per block, well under the target of 14, so the data room added in 2025 and 2026 was not full that morning.
Chains compared: throughput and what a node costs
The comparison below puts measured activity next to the cost of verifying, which is the trade-off this lesson is about. Read the throughput column with care: a Bitcoin payment, an Ethereum token swap and a Solana transaction are different amounts of work, so transactions per second are not a like-for-like unit across chains.
| Network | Block or slot time | Measured throughput | What a node needs | Source |
|---|---|---|---|---|
| Bitcoin | About 10 minutes (target) | About 7.5 tx/s, 24 hours to 09:41 UTC, 11 Nov 2026 (647,898 transactions in 144 blocks) | Bitcoin Core: 2 GB memory, about 7 GB disk if pruned; full chain about 782 GB (11 Nov 2026) | mempool.space, bitcoin.org, Blockchair |
| Ethereum (layer 1) | 12 seconds | About 23 tx/s (60-block sample, 11 Nov 2026); 2,064,096 transactions on 10 Nov 2026 | 2+ cores, 16 GB memory (32 GB recommended), 4 TB NVMe SSD, 25+ Mbit/s | Public Ethereum RPC, growthepie, ethereum.org |
| Solana | About 215 ms on average (200 ms target) | About 1,265 tx/s, hour to 09:45 UTC, 11 Nov 2026 | 2.8 GHz+ processor, several NVMe drives of 0.5 to 1 TB+, 512 GB memory capacity suggested, 2 to 10 Gbit/s | Solana public RPC, Anza docs |
| Base (layer 2 on Ethereum) | 200 ms since 5 Nov 2026 | 8,468,276 transactions on 10 Nov 2026 (about 98 tx/s) | Settles on Ethereum; users can rely on Ethereum nodes for its data | growthepie, Base |
| Visa (card network, not a blockchain) | Not applicable | Up to 83,000 messages/s capacity; about 10,200 a second on average from more than 322 billion a year | Private data centres | Visa, 29 Oct 2025 |
Bitcoin and Ethereum keep verification within reach of a home machine and accept low throughput in exchange. Solana carries far more activity on its base layer and asks verifiers for professional hardware. Base, which moved to 200 ms blocks with its Denim upgrade on 5 November 2026, shows the layered route: high activity on top, with Ethereum holding the data and the final word.
Visa is a useful yardstick but a loose one. Its own description of its network, published on 29 October 2025, speaks of “up to 83,000 transaction messages per second worldwide” and more than 322 billion transactions a year. The first figure is capacity, not a measured rate; the second, divided by the seconds in a year, gives about 10,200 a second on average. And a Visa authorisation is not final settlement: banks settle between themselves later, in batches, inside a system nobody outside can audit.
What scaling changes for you
For most users, blockchain scalability shows up as fees. A transfer that cost tens of dollars on Ethereum in 2021 and 2022 costs cents as of November 2026, and the same activity on a layer 2 costs a fraction of a cent. Part of that comes from the capacity added since 2024 and part from quieter markets; a rush of demand can still push fees up quickly, as it did on Bitcoin in April 2024.
Scaling also changes who you trust. On a chain whose node you can run on a laptop, you can check everything yourself. On a high-throughput chain or a layer 2, you rely on someone else’s hardware or on a proof system, and the details decide how much. Three questions help with any headline claim of tens of thousands of transactions a second:
- Is the figure measured on the live network, with a date, or a theoretical peak from a test?
- What machine and connection does it take to verify that chain in full, and how many independent operators actually do?
- If you cannot verify it yourself, what exactly are you trusting: a validator set, a sequencer, a bridge or a cryptographic proof?
For US readers, moving to cheaper networks has a tax side worth knowing. The IRS says in its virtual currency FAQ that the cost basis of crypto you buy includes fees, commissions and other acquisition costs, and that moving crypto between wallets or accounts you own is not a taxable event. That FAQ does not address bridging or wrapping tokens between networks, so those steps are not covered by it. Fees and taxes do not change the scaling argument, but they are part of what a transaction really costs you.
The next lesson of this path picks up where this one stops: how layer 2 rollups work, why they are cheaper and what they still ask users to trust.
