Chapter 8 · Why Bitcoin, Ethereum, and Solana Differ
How can you compare chains beyond TPS?
- Capabilities practiced
- Protocol LiteracySystem Thinking
- Hands on
- Compare three chains' block times, finality times, node counts, and hardware requirements for running a node in a table.
- AI Lab
- Have AI generate a comparison table for three chains. Check each item against official docs and mark incorrect figures.
A Real-World Problem
You see two charts on social media.
The first says chain A handles tens of thousands of transactions per second, while B handles only a dozen, so A wins. The second says B has run safely for over a decade without compromise, while A has stopped several times.
Both use real data and reach opposite conclusions.
Reality is more confusing: many of the world's largest on-chain assets have remained on the slow chain for years. If faster means better, this makes no sense.
Every newcomer encounters this: someone asks which chain is better. You know TPS is insufficient but cannot explain what to compare instead.
This chapter provides a way to ask, rather than a universal answer.
Thought Experiment
Forget chain names. Design a shared accounting room for the whole world from scratch.
You control four knobs:
- Who may keep the accounts: everyone, or a selected group?
- What equipment they need: an old laptop, or a professional server and excellent network?
- When a record counts: immediately, or after everyone confirms?
- How complex a record can be: only payments, or arbitrary program results?
You quickly find the knobs interlock:
- Raise equipment requirements → faster processing, but fewer people can afford participation, perhaps leaving only dozens of institutions.
- Raise record complexity → more functionality, but longer processing, requiring slower operation or better equipment.
- Raise settlement speed → better experience, but less verification time and stronger network requirements, excluding slower participants.
- Open participation to everyone → nobody can block entry, but the slowest participants must be accommodated.
One deeper question appears: what does a secure room mean?
It does not merely mean intact cryptography. It means the cost of altering an established record. That cost comes from resources participants commit: more investment makes historical rewriting more expensive.
A fifth knob is therefore determined by the first four: the available security budget.
You now have four controls and their resulting constraint. No configuration maximizes them all.
Your Decision
Three things need rooms. You may choose separate rooms or one for all.
- A: Large savings untouched for ten years.
- B: A game producing frequent, low-value actions.
- C: Lending rules managing enormous funds, where any failure can cost many people money.
What Happens
The choices reveal one fact:
No configuration is best for all three uses. A needs decade-long safety; B needs cheap, instant actions; C needs reliable rules and continuous availability. These demands conflict.
“Which chain is better?” is therefore a poor question. Ask which chain's trade-offs fit this use.
Before comparing, address another problem: the same word means different things on different chains.
| Term | Apparent meaning | What it might actually mean |
|---|---|---|
| Transactions per second | Real processing capacity | Theoretical maximum, lab measurement, or recent thirty-day median? Are transfers and complex calls equivalent? |
| Confirmation time | Time until receipt | Inclusion or irreversible finality? These can differ by seconds or tens of minutes |
| Node count | Participants maintaining the chain | All data-syncing nodes or only producers and voters? Counts can differ by an order of magnitude |
| Decentralization | One scored metric | At least four questions: who produces blocks, changes rules, runs nodes, and where they are located |
This is the chapter's most practical table. Cross-chain comparison is invalid until definitions match.
It explains the opening charts: each selected favorable definitions without disclosing them.
Build a Model
Replace rankings with six dimensions. For each, ask what it measures and what improving it costs.
| Dimension | Question | Cost of increasing it |
|---|---|---|
| Security | What does altering confirmed history cost, and where does that budget come from? | Continuing real expenditure paid by fees or issuance |
| Execution | How complex can rules be, and how much runs per unit time? | Higher hardware and network requirements |
| State | How much data must persist, how quickly does it grow, and who pays storage? | Larger state makes joining harder and can weaken decentralization |
| Latency | Time to inclusion and then irreversibility? | Less margin for verification and propagation; stronger networks needed |
| Decentralization | Who produces blocks, changes protocols, and where are nodes and producers? | More dispersed participation increases coordination costs and lowers performance limits |
| Hardware threshold | What does a full node require, and can an ordinary person run it? | Lower thresholds constrain capacity; higher thresholds concentrate control |
Hardware requirements constrain the other five dimensions in practice. If only professional data centers can verify, ordinary independent verification—the value established in chapter 3—does not really exist.
Use this sequence to connect the dimensions:
- Ask the use case first
- Prioritize six dimensions for it
- Align definitions
- Retrieve each metric with dates
- Judge and state uncertainty
The blockchain trilemma says decentralization, security, and scalability cannot all be maximized. It is useful but coarse; some terms combine several concepts. Six dimensions correspond to specific, retrievable data.
Take away this criterion:
Chains differ by trade-offs, not a universal ranking.
A weakness in one dimension usually means resources went to another. Knowing what was gained is more useful than memorizing rank.
What It Is Called
For chains, security means the cost of rewriting confirmed history, not simply bug-free code.
It depends on resources protecting the chain and their distribution. The former sets attack cost; the latter determines whether bribing a few people bypasses it.
Security is funded by fees or issuance. Issuance-funded security is paid by holders.
A chain's ability to compute new state under rules: supported complexity and throughput.
First ask the definition: theoretical peak, stress-test result, or sustained real median? They can differ by an order of magnitude, while public claims favor the first.
All current data validators must access: balances and contract storage.
State differs from history. History can be archived; state must remain immediately readable. Growth raises joining costs, often visibly only after years, when reversal becomes difficult.
Time between sending a transaction and its taking effect.
Separate inclusion time from finality time. Chapter 6 explained that assurance may grow probabilistically rather than instantly.
These times are close on some chains and far apart on others. Treat comparisons reporting only inclusion time cautiously.
At least four questions, not one number: who produces blocks, changes protocols, runs independent nodes, and how are they distributed geographically and legally?
Block production can be dispersed while protocol control rests with a few developers and a foundation. This is common and rarely visible in comparison tables.
Decentralization supports the assurance that nobody can alter records. Chapter 9 examines the same issue for contracts.
Hands-on
This is your first stage artifact. Do not copy existing tables. The stage introduction warned that widely circulated numbers are often wrong or outdated.
Choose three chains with visibly different priorities: security and simplicity, programmability, and low latency, for example.
Define metrics before retrieving data. Write four definitions above the table:
- Is block time a target or a recently measured median?
- Which confirmation standard defines finality?
- Which nodes are counted, and from which source?
- Are hardware requirements minimum or recommended?
This matters more than filling the table. Without definitions, it is no better than the charts online.
Retrieve each item and record a source link and time.
| Chain A | Chain B | Chain C | |
|---|---|---|---|
| Block time | |||
| Finality time | |||
| Producing or voting nodes | |||
| Independently verifying nodes | |||
| Recommended hardware | |||
| Historical outages | |||
| Who decides upgrades |
Most tables omit the last two, though they often reveal more than the first rows.
Mark unavailable cells. Some official sources omit data or provide vague claims.
Write Not Found rather than substituting secondary numbers. Empty cells reveal transparency gaps.
Write three judgments using the table:
- Where did each chain spend its budget?
- Which would you choose for an asset untouched for ten years, and why?
- Which would you choose for frequent, small actions, and why?
Save the table. Retrieve the figures again in three months to see what changes and what does not. That comparison is a valuable outcome itself.
AI Lab
Ask AI to try first:
Compare three blockchains in a table with:
- Block time, specifying target or measured median
- Finality time and confirmation standard
- Nodes participating in production or voting
- Independently verifying nodes
- Officially recommended full-node hardware
- Historical outages or reorganizations
- Protocol-upgrade decision processes and decision-makers
Rules:
1. Attach a source link and data date to every number
2. Write “Not Found” for unavailable fields; do not estimate or fill them from assumptions
3. List conflicts between sources instead of choosing one yourselfThen do the real work: open every link and verify each item.
Record another table: items verified in official documentation, correct numbers with incorrect dates, broken links, and invented plausible numbers.
Build a calibrated judgment of which outputs are usable and which require personal checking, rather than merely challenging the model.
The common failures are theoretical peaks presented as actual throughput, inclusion confused with finality, and well-formatted nonexistent documentation links.
This adds several items to the common-model-error list started in chapter 1.
Verify these points yourself after using AI
- Find each number in the original text at its cited link
- Check that inclusion and finality times remain separate
- Check what type of nodes the count includes
- Check minimum versus recommended hardware and whether the source is official
- Check data dates and whether different periods appear side by side without explanation
- Check for the often-omitted protocol-upgrade decision row
- Open every link and verify it actually supports the associated claim
Real-World Case
One group sought larger blocks to lower fees and fit more transactions. Another argued that higher node requirements would weaken independent verification over time.
The debate lasted more than two years and ended in a chain split.
The value of the case is its visible trade-off: block size chooses between cheap transactions and participation, not merely a technical parameter. Chapter 7's final variable and chapter 11 continue the argument.
Some chains prioritize latency and throughput. Under transaction surges, validators failed to agree and production stopped for hours, requiring coordinated restarts.
Availability and throughput differ. A normally fast but occasionally unavailable chain can be more dangerous for liquidation than a slow but continuously operating one.
Those chains subsequently improved their engineering. Evaluating today's chain with two-year-old incidents is as unreliable as using theoretical peak throughput.
Every new contract and address on programmable chains adds state that validators must access immediately.
Rather than exploding on one day, it gradually raises joining costs. Proposed responses include expiring unused data, ongoing state fees, and specialized archive nodes.
This dimension takes years to observe, so charts often omit it. For a chain meant to last ten years, it matters more than TPS.
A major chain changed from computation expenditure to staked assets, reducing energy use by orders of magnitude.
This rewrote several dimensions: security resources shifted from electricity and mining hardware to locked assets, participation requirements changed, and finality changed.
The same chain has different trade-off combinations at different times. That is why every figure needs a date.
Change One Variable
Execution and throughput improve, giving users a better experience.
Fewer people can verify independently, perhaps leaving institutions and specialists. Trustlessness then becomes trust that a small group will not collude.
This can still be reasonable, provided you recognize the exchange.
Payments and trading approach traditional-system responsiveness, a real improvement.
Costs usually hide in stronger networking and coordination, narrowing participation, and greater difficulty maintaining fast certainty under extreme network conditions, increasing outage or rollback risk.
Speed's cost often appears on the worst day rather than ordinary days.
State growth is priced directly: unused data expires or requires continuing payment.
Node burdens become manageable and joining easier. But developers face data disappearing while they are not watching, requiring redesign of persistent-storage applications.
Many chains discuss this, but few implement it comprehensively. Consider why.
The first decentralization question improves: bribing a few people becomes harder.
Coordination becomes more expensive, agreement slower, and performance lower. Count also does not equal distribution: participants in one cloud region can fail together.
Counting nodes is easy; understanding their distribution is the work.
Takeaway Questions
A sharper version of the question is which kind of chain you need.
An application seeking cheap, fast actions rather than decade-long immutability may not need the strongest chain, or any chain. Define the use before comparing.
Users determine dimension priorities.
Cross-border settlement prioritizes finality and censorship resistance; games prioritize latency and cost; institutions prioritize outages and compliance interfaces. Without identified users, you cannot prioritize dimensions.
Who bears outage risk? Usually people with open positions, pending liquidations, or imminent withdrawals.
Ordinary parameters become precise determinants of losses during incidents. Chapter 24 incorporates this into the unified risk model.
The direct answer is that security budgets depend on token price.
Zero price removes rewards and lowers attack cost. The chain may continue producing blocks, but immutability fails first. Ask this of every new chain.
Chapter Check
Three reasons suffice individually:
- Definitions differ. Theoretical peak, stress tests, and actual median are different numbers; publicity favors the largest.
- Transactions differ. Transfers and complex calls consume different resources, so counting transactions favors simpler ones.
- It covers one dimension out of six. Throughput gains often surrender hardware accessibility or decentralization.
Ask what was exchanged for speed rather than merely who is faster.
The cost of rewriting confirmed history, rather than just bug-free code.
It depends on resource investment and distribution. Insufficient resources make attacks cheap; concentration lets attackers bribe a few people instead.
Someone ultimately pays this budget: users through fees or holders through issuance dilution.
Inclusion records a transaction in a block that may still be replaced. Finality means it cannot roll back.
Small payments often need only inclusion. Large transfers, cross-chain operations, and exchange deposits require stronger assurance. That explains different confirmation requirements by chain.
Chapter 6 described gradually strengthening assurance, whose rate differs widely across chains.
No. Ask at least three more questions:
- How many actually produce blocks or vote? Data-syncing nodes do not decide consensus.
- Where do they run? Concentrated cloud providers and regions can suffer shared failure or coercion.
- Who decides upgrades? Production can be dispersed while rule-changing authority is concentrated, a usually omitted dimension.
There is no answer key. Check whether you:
- Asked the use case first before prioritizing dimensions
- Defined metrics before retrieving data
- Checked upgrade authority and outage history
- Recorded sources and dates for every number
- Honestly retained Not Found cells
The last point distinguishes research from repetition. Chapter 25 formalizes this as a thirty-minute process.
Key idea
Differences between chains are trade-offs, not a ranking.