Research · Solana
Bitcoin and Solana, two answers to one constraint
The two designs start from different assumptions about who should be able to run a node. Bitcoin's answer is that the cost of validation should stay low enough that a large number of independent participants can check the chain for themselves, and it accepts a modest throughput as the price. Solana's answer is that throughput is the binding constraint, and it accepts higher hardware requirements in exchange for capacity. Neither is a mistake; they are different bets about what a network is for, and the pages below are careful to describe each bet on its own terms.
Every claim is drawn from the networks' own specifications, and the status of each mechanism is stated on the page. Nothing here is a forecast, and no comparison is a recommendation.
Architecture
Architecture
Bitcoin bounds what a block can carry so that an ordinary machine can validate the chain; Solana pipelines execution and orders transactions by a verifiable clock so that a single machine can process far more of them. These pages work through what each design buys and what it gives up.
Design Intent
Design Intent
A comparison is only fair when it judges each system against the goals it set itself. This page works through four networks — Bitcoin, Ethereum, Solana and ICP — against their own stated design intents, and states plainly where that framing stops being informative.
Execution & State
Execution & State
Solana's throughput comes from a specific set of mechanisms, and each one has a cost. These pages work through the clock that orders transactions before consensus, the runtime that executes them in parallel, the account model that makes that parallelism possible, and the compression scheme that keeps large collections affordable to store.
- Proof of HistoryThe sequential hash chain that orders transactions before consensus, and what it does not prove.
- Sealevel RuntimeParallel execution, the account-access declaration, and how the scheduler orders conflicting work.
- Account ModelThe five account fields, ownership rules, the storage deposit and program derived addresses.
- State CompressionConcurrent Merkle trees, the changelog that allows concurrent writes, and the trade-offs.
Economics & Load
Economics & Load
A network that processes transactions in parallel has to decide what to do when demand concentrates on one piece of state, and how to admit transactions before they reach the scheduler. These pages cover the fee schedule, the local fee market that contention creates, and the ingest path that decides whether a transaction is admitted at all.
- Validators & Leader ScheduleLeader election, Turbine block propagation, Gulf Stream forwarding and vote transactions.
- Fees & Priority FeesThe base fee, the prioritisation fee formula, distribution, and why a failed transaction still pays.
- Local Fee MarketsWhy contention on one account is a different problem from network-wide congestion.
- Congestion & Transaction ProcessingThe QUIC ingest path, stake-weighted stream limits, forwarding, and why transactions are dropped.
The reference pages behind the comparison
The pages above explain the comparison. These hold the underlying record and the methodology, for when you want to check a figure or follow a source.