Tape Replay

Erasure-coded storage has fixed costs per object: encoding, commitment transactions, shipping slices to a group of nodes. A large file amortizes all of that. A small file drowns in it. Networks built only on that pipeline charge about as much to store 1 KiB as they do for something a thousand times bigger. Tapedrive takes a different route below a size threshold: don’t erasure-code at all. Write the bytes into Solana itself, and let the chain’s own durability carry them. That path is called tape replay, and it’s the reason small files work here.

​

How it works

A small write carries its bytes inside the tape-write instruction of an ordinary Solana transaction. When the transaction lands, the data is in the ledger, and that landing is the durability event. The track is registered and certified in the same moment: no slicing, no distribution to a spool group, no signature round to wait on. For serving, the track is assigned to a single spool, and reads flow through gateways like any other track (the write paths, what got skipped).

​

Why it’s called replay

Tapedrive is event-sourced. Every node builds its state by replaying the network’s instructions from Solana blocks, in order. For an inline track, the instruction contains the data, so replaying the chain reproduces the file itself. So a hosting node that disappears, or lies, changes nothing. Anyone replaying the ledger recovers the bytes. Replay has a second payoff, bootstrapping entire nodes, covered in the snapshots section below.

​

Durability without fan-out

A replay-written file can be recovered from three independent places, in order of immediacy:

1. The spool that serves it. The fast path for reads.
2. The Solana ledger. The bytes are inside a transaction; any copy of chain history has them.
3. The epoch’s snapshot. Each epoch, the network bundles its replay writes into an erasure-coded system tape alongside the rest of the epoch’s record (covered next; system tapes).

Small files get chain-grade durability at a cost proportional to their size, because nothing about the write is fixed-size except the transaction that carries it.

​

What fits

The ceiling comes from Solana’s transaction limits: about 10 KiB of data can ride through today, and that number rises as Solana raises its limits. The SDKs default to switching paths well below the ceiling; those defaults are client settings you can change, and they aren’t protocol rules. You don’t pick a path. The SDK chooses by size, so a workload of millions of tiny objects (agent context, manifests, metadata, thumbnails) lands on the cheap path without anyone thinking about it (the write paths).

​

Snapshots

Replay also covers the network itself. Every node processes the same Solana blocks in order, so each committee member independently builds a byte-identical event log of the epoch. The network captures its log, and state can always be rebuilt from it. Each epoch, that log is encoded in two stages: striped across all live spool groups, then erasure-coded within each group. Every committee member ends up holding a piece of every snapshot, and the network can lose whole groups and still recover its record. The result is written to a dedicated system snapshot tape (tapes beyond user data), and the snapshot’s hash is agreed by the same group voting used for assignments (spool groups). An epoch cannot advance until the previous epoch’s snapshot is complete, so the network never outruns its own record (the epoch phases). Bootstrap falls out of this. A new or lagging node walks snapshot tapes backward, decodes, replays the events through the same handlers it uses live, then resumes ordinary block ingestion. There is no trusted state-transfer step and no separate sync protocol to reason about. Joining the network is replaying it.