You send a transaction. It leaves your wallet, hits a node, and somewhere in that first millisecond it gets compressed into a flat sequence of bytes before anything else can happen to it. You never see this. Almost nobody does. But the format doing that compression has been at the center of a quiet, years-long argument inside Ethereum's core development community, and the reason that argument hasn't resolved tells you more about how protocol upgrades actually work than any roadmap post ever will.
The Actual Difference Between RLP and SSZ
RLP, Recursive Length Prefix, is Ethereum's original wire format. Vitalik Buterin designed it in 2014 as a minimal, recursive encoding: prefix any byte string or list with its length, nest those structures arbitrarily deep, done. It's elegant in the way a Swiss Army knife is elegant. A transaction is a list; each field is a byte string; the whole thing self-describes its own boundaries as you decode it.
The problem is what RLP doesn't give you.
No fixed schema. No concept of field positions. You cannot know what byte offset a particular field sits at without decoding everything before it, and that matters enormously once you want to prove something about a transaction without revealing the whole thing. Which is exactly what light clients and rollups need.
SSZ, Simple Serialize, was designed for the Beacon Chain with the opposite philosophy. Every type has a fixed layout. Fixed-size fields sit at known byte offsets. Variable-size fields get a pointer table up front. Want the validator index out of an attestation? Jump to byte 0, read four bytes. No sequential scan. No guessing.
The deeper win is Merkleization, which just means: chunking an object into 32-byte leaves and hashing them into a tree so you can prove one field's value without exposing everything else. SSZ is built for this natively. RLP can be Merkle-hashed too, but it's bolted on rather than grown in, and the proof sizes are larger and less uniform, like a retrofit smoke alarm taped to a wall that was never wired for one.
A worked example makes this concrete. Say a light client, call her Priya, wants to verify that a specific validator held a balance of 32.1 ETH at a given state root, without downloading the full state. With SSZ, the state is a tree of known shape. Priya receives a branch of roughly ten 32-byte hashes and she's done. Her counterpart Marcus, running the same check against an RLP-encoded state, has to navigate Ethereum's Merkle Patricia Trie: variable-length nodes, nibble-based paths, extension nodes that inflate the proof. Marcus finishes with a larger payload and more parsing code. Multiply that gap across thousands of proofs inside a ZK circuit, a zero-knowledge proof system that verifies computation without re-executing it, and the difference stops being academic.
Where Each Format Lives Right Now
Ethereum doesn't use one serialization format. It uses two, split along the consensus/execution boundary, and a lot of the confusion in this space comes from people not realizing that.
The consensus layer, validators, attestations, beacon blocks, fork-choice state, runs entirely on SSZ. The Beacon Chain was a clean slate, and the client teams (Lighthouse, Prysm, Teku, Nimbus, Lodestar) all implemented SSZ from scratch.
The execution layer is still RLP. Every transaction you've ever sent was RLP-encoded. The execution clients (Geth, Nethermind, Besu, Erigon) carry years of RLP logic in their core paths. EIP-2718, which introduced typed transaction envelopes, added a thin wrapper around RLP rather than replacing it. EIP-4895 used SSZ-adjacent structures in the beacon block, but the execution payload still speaks RLP.
The boundary is real and actively maintained. Cross it in either direction and you need a translation layer.
Why the Migration Stalled
The intent was always to migrate the execution layer to SSZ. The benefits are real and widely acknowledged by the people who matter here. So what happened?
Three things, mostly.
Scope is the first one. Migrating transactions, receipts, and state to SSZ isn't a single EIP you ship on a Thursday. It's a family of changes touching every client's encoding and decoding paths, the JSON-RPC API that thousands of applications depend on, every block explorer, every indexer, every wallet library. Ethereum's Snap sync protocol, the mechanism new nodes use to bootstrap quickly without replaying history, is built around the existing trie structure. You don't swap that out casually.
The SSZ spec itself kept moving during the Beacon Chain's early life. Merkleization details changed. The Union type, which handles objects that can be one of several variants, was debated long enough that different client teams made different early implementation choices. Shipping a stable migration target was hard when the spec wasn't frozen.
And third, most honestly: the execution layer works. RLP is not broken. There is no crisis. That means the migration competes against roadmap items with more immediate user impact. The Surge (rollup scaling), the Scourge (MEV mitigation), the Verge (Verkle trees) all pull engineering attention. The Verge is particularly relevant because Verkle trees would replace the Merkle Patricia Trie entirely. The argument, and it's a reasonable one, is that you'd rather migrate serialization formats after the trie has also changed, not before.
EIP-6493 is the live proposal for migrating transaction encoding to SSZ. It defines an SSZ transaction type, specifies how the transaction hash is computed to stay compatible with existing tooling, and provides a migration path. Progress is real. But the proposal has to solve hash stability, receipt changes, and API compatibility simultaneously, or it breaks things downstream. That's not bureaucratic timidity. That's the actual constraint.
The question worth sitting with: if SSZ's proof advantages are so compelling for ZK applications, why haven't rollups pushed harder for the execution-layer migration? The honest answer is that most rollups have built their own serialization layers rather than waiting for Ethereum L1 to move. They solved their immediate problem. That reduced the urgency on the mainnet side, which is probably the most underappreciated reason the timeline keeps slipping.
The Honest Caveat About Complexity
SSZ is simpler than RLP in the sense that a fixed schema with known offsets is easier to reason about formally. It is not simpler to retrofit into a codebase with years of RLP assumptions baked in, and anyone who tells you otherwise hasn't tried.
RLP is so minimal that a compliant decoder fits in roughly a hundred lines of most languages. SSZ requires a schema, a type registry, and offset table handling. The complexity is manageable, worth it for the proof capabilities, but it isn't free. The Union type stabilization took longer than expected and left fingerprints on multiple clients.
SSZ is Ethereum's future serialization layer. It has been running in production on the consensus side for years. The execution-layer migration is real work in progress, not a cancelled project gathering dust. The reason it hasn't finished is the same reason most large protocol changes outlast their original timelines: the existing system works well enough that you have to be certain the replacement is better in every dimension before you break the thing millions of people depend on. What looks like stalling is actually the protocol taking its own stability seriously.