PeerDAS: Erasure Coding When You Can't Trust the Storage

You've probably used erasure coding without calling it that. RAID, CDs that still play with scratches on them, most distributed storage systems. The idea is you add redundancy up front so you can lose some of the data and still rebuild it. Reed-Solomon is the usual workhorse, and the property you care about is that any ~50% of the encoded pieces is enough to get everything back.

The catch is that all of those systems assume the storage isn't out to get you. A disk can die, but it won't deliberately hand you corrupted bytes, and it won't sit on the exact pieces you need while pretending everything's fine. Once the thing storing your data is an untrusted peer who might be malicious, that assumption is gone, and plain erasure coding isn't enough anymore.

This talk is about what you have to add to make it work anyway. I'll use PeerDAS as the example because it shipped on a live Ethereum network in December 2025, and several independent open-source clients had to implement the same protocol and actually interoperate.

I'll cover why a malicious peer is harder than a failing disk, specifically the two separate problems: it can serve you wrong data, or it can withhold the pieces you're missing. Those need different solutions. For the first, KZG commitments let you check that a single chunk is the real thing without downloading the whole dataset. For the second, you sample a handful of random chunks, and because of the erasure coding, that's enough to be confident the whole thing is really available. Then there's the networking layer: deciding who stores which pieces, passing samples around between peers, and letting the network reconstruct data that's gone missing.

This talk would be nothing about blockchain. Just a genuinely hard distributed systems problem and how people solved it.

1. what erasure coding gives you and why that 50% reconstruction number is the thing that makes the whole approach possible
2. why storage that fails is a different problem from storage that lies, and why one set of tricks doesn't cover both
3. how you check a small chunk is correct without pulling down the dataset it came from
4. the basic idea of data availability sampling: look at a few random pieces, conclude something about all of them
5. how the network actually spreads the data out, shares samples, and repairs itself, and a couple of the practical tradeoffs that came with shipping it