Skip to content
blockchain-compression cargo add →

← back home · compare

blockchain-compression vs vanilla zstd

// General-purpose Zstandard, no chain dictionary

This library wraps zstd. The interesting comparison is what you give up by skipping the custom dictionary, not what you gain from a different algorithm. On the growing archival and historical data that state bloat produces — account snapshots, batched transactions — the dictionary is most of the win, and it is exactly the byte structure a chain repeats billions of times as it scales.

Feature blockchain-compression vanilla zstd Advantage
Underlying encoder Zstandard Zstandard tie
Dictionary Hardcoded Solana patterns (program IDs, discriminators, lamport amounts, Base58) None by default this crate
Ratio on Solana accounts 15–40:1 (README preset range) Lower — no dictionary means cross-block patterns must be rediscovered every block this crate
Ratio on arbitrary data Equivalent to vanilla zstd; dictionary does not hurt but does not help Tuned for general-purpose use tie
Determinism Same bytes in, same bytes out, deterministically — dictionary is a constant Deterministic for a given level; depends on which dictionary file you ship if any tie
Compression levels Six named presets mapping to Zstd level 3, 6, or 19 Levels 1–22, exposed directly vanilla zstd
Surface area Six presets + a CompressionStrategy trait Two functions (compress, decompress) and a level integer vanilla zstd
Roundtrip guarantee Tested per preset on every release; trait contract Tested per Zstd release upstream tie
Binary size Pulls in zstd + the dictionary constant Pulls in zstd only vanilla zstd

Pick blockchain-compression when

  • Your input is Solana data — account snapshots, transactions, instructions
  • You are fighting state bloat: cheaper archival and cheaper data movement as the chain grows
  • You want the measured "up to 60:1 on archival workloads" instead of vanilla-zstd numbers on the same input
  • You want the dictionary to ship with the binary, no model file to manage
  • You want round-trip determinism guaranteed by a hardcoded dictionary

Pick vanilla zstd when

  • Your input is not Solana-shaped (arbitrary blobs, logs, generic data)
  • You already build and ship your own learned zstd dictionary
  • You want to avoid a Solana-specific code path in a chain-agnostic system
  • You are inside a system that only links libzstd and cannot add a Rust crate

Still deciding?

Run both encoders on a sample of your real data. The ratio you measure on your workload is more useful than any preset table — and the crate exposes compressor.stats().best_ratio for exactly this kind of head-to-head check.