Networks use different methods to verify current state and manage old block data. Comparing them requires separating archival storage, node synchronization, consensus validation and the assumptions made when bootstrapping from a snapshot or proof.
Editorial update — September 8, 2026: This revision clarifies history expiry, pruning and snapshot verification, corrects node requirements, and removes unsupported hardware-price and synchronization-time claims. Primary sources are linked below.
A blockchain is a shared record book. Nodes check new blocks against the network’s rules. Replaying a longer history requires more work, while snapshots and proofs offer different ways to start. Here is how five networks approach that trade-off.
Bitcoin
Bitcoin nodes can validate the chain from genesis. In that mode, they download historical blocks, and synchronization time depends on hardware, connectivity and validation settings. Pruning can discard old block files after validation while retaining the current state needed to follow the chain.
A node performing a genesis-to-tip sync still needs peers or another source to supply those historical blocks. Archival storage preserves history for that use and for historical queries. This is distinct from a rule that every online node must retain the entire history. (Bitcoin full-node operation and pruning)
Ethereum
Ethereum uses rollups as part of its scaling approach. Rollup activity, interoperability and historical-data retention are related operational topics, but they are not the same measurement. This comparison focuses on what execution clients retain and where older block data can be retrieved.
On 8 July 2025, the Ethereum Foundation announced that all execution clients supported partial history expiry for pre-Merge block data. It estimated a 300–500 GB disk saving, depending on the client and data retained. This concerns old block bodies and receipts, not deletion of the current state or a requirement that every operator erase all pre-September-2022 records.
Historical data remains necessary for full replay from genesis and historical queries. Archive operators and other distribution methods can provide it; an operator can also choose to retain it. History expiry changes storage and retrieval responsibilities rather than proving that only centralized companies can supply Ethereum’s past. (Ethereum Foundation partial history expiry announcement, 8 July 2025)
Solana
Agave’s current validator recommendations start at 12 CPU cores / 24 threads and 256 GB RAM, with separate NVMe capacity for accounts, ledger and snapshots. Staked validators need at least 2 Gbit/s symmetric connectivity, with 10 Gbit/s available bandwidth recommended. Larger RPC workloads can need more memory and storage.
Those requirements make operating a production validator demanding. They do not establish a universal $15,000–$50,000 entry price or prove that individuals cannot run verification infrastructure. Retaining complete historical data is a different workload from participating in current validation. (Agave validator requirements)
Cardano
Cardano uses an extended UTXO model and a proof-of-stake consensus design. Its consensus documentation describes an average block interval of about 20 seconds; that average is not a complete throughput or confirmation-time comparison.
A traditional full sync processes historical blocks. Mithril provides certified snapshots to accelerate bootstrap, with its own stake-based multisignature assumptions. These are different verification paths, so a comparison should name which one it measures. (Cardano consensus and storage technical report · Cardano Mithril bootstrapping)
Kaspa
Kaspa uses proof of work and a UTXO model, with a target rate of ten blocks per second. Ordinary nodes prune old block data while retaining the state and proof data required by the protocol. Retention is determined by pruning and finality rules and node configuration; it is not a promise that every record is deleted at exactly one age. (Kaspa block-rate and pruning-depth configuration · Kaspa pruning-point proof validation)
How can a network delete its history and stay safe? Every Kaspa block carries a kind of fingerprint. This fingerprint is a short mathematical summary of all coins that exist at that moment. It is made with a method called MuHash, which can update the fingerprint with every new block without redoing all the work.
A joining Kaspa node validates a pruning-point proof and obtains the UTXO state needed to continue validation. It checks the state commitment as part of that process, alongside proof-of-work, ordering and other consensus checks. A matching MuHash commitment alone does not prove every historical transaction was valid.
This bootstrap path avoids replaying all pruned history, under Kaspa’s consensus and cryptographic assumptions. Archival history can still be useful for explorers, audits and research; it is a separate service from following the current network. (Kaspa pruning-point proof validation · Kaspa Prunality research)
What It Adds Up To
These networks distribute historical storage and bootstrap work differently. Bitcoin pruning reduces retained block data after validation; Ethereum history expiry changes which old data a node serves; Solana has demanding production-node requirements; Cardano offers Mithril snapshots; Kaspa uses pruning proofs and state commitments. Sync time and hardware costs need an explicit benchmark, and each path relies on specified consensus and cryptographic assumptions. (Bitcoin full-node operation and pruning · Ethereum Foundation partial history expiry announcement, 8 July 2025)
The useful comparison is what a new node verifies, what it retains and which assumptions its bootstrap method requires.
Sources and methodology
This comparison uses official protocol documentation, implementation sources and operator guidance checked on 8 September 2026. Hardware recommendations apply to the node roles identified in the article. Block intervals, finality, throughput and operating costs measure different things; they are not interchangeable benchmarks. Proposed upgrades are identified separately from deployed behavior.
- Bitcoin full-node operation and pruning
- Ethereum Foundation partial history expiry announcement, 8 July 2025
- Agave validator requirements
- Cardano consensus and storage technical report
- Cardano Mithril bootstrapping
- Kaspa block-rate and pruning-depth configuration
- Kaspa pruning-point proof validation
- Kaspa Prunality research
