Ethereum Already Has a Binary RPC. It's Just Not the One You Call.

A full Ethereum node listens on two ports that look like the same idea and are not.

8545 is JSON-RPC. Wallets, ethers.js, indexers, Infura-shaped products. Hex strings. Human-readable. Slow in the way every backend engineer has been told JSON is slow.

8551 is the Engine API. Consensus client talks to execution client, every slot, on the path that has to finish before the next block. Same machine. Different job.

I keep a bad habit: I read a sharp benchmark, see json.Marshal in a flame graph in someone else's post, and start shopping codecs. Protobuf. MessagePack. SSZ. Whatever the last impressive chart used. It feels like infrastructure work. Most of the time it is displacement activity.

So I did the measurement on the actual protocol, with real mainnet payloads, and then I went and read what Ethereum is already doing about it. The short version: the 3× win is real, and it still is not the first place to look. The interesting part is that the protocol has already picked a side — just not on the port you curl.

Two ports, two contracts

JSON-RPC on 8545 is a compatibility surface. Every client implements the same execution APIs. You can swap Geth for Reth and the wallet does not notice. Hex is the price of that: every hash, address, bloom filter and byte of calldata is 0x plus two ASCII characters per byte.

The Engine API on 8551 is the opposite contract. It runs between two processes you operate, once per 12-second slot, on the path that decides whether a payload is valid in time. The consensus layer already speaks SSZ. The execution layer still receives that payload as JSON-RPC with hex in the middle.

That mismatch is not a blogger's complaint. It is in the draft specs.

EIP-7807 says the same thing in one line: move the engine API from textual JSON to binary SSZ, ~50% less data, “significantly improving encoding/parsing efficiency.” The Hegotá / Magicians writeup is blunter about when it starts to hurt:

The JSON based engine API starts to become a relevant bottleneck as the number of blobs increases and block data grows bigger.

So Ethereum is not confused about JSON. It is keeping JSON where strangers call, and trying to retire it where the slot clock is the SLA.

I still wanted the number for the public port. That is the one the fancy codec posts are actually talking about, even when they pretend they are talking about “Ethereum.”

What I measured

One thousand real eth_getBlockByNumber(true) responses, gzip, mean:

The ratio does not depend on how many blocks you picked. It is the codec, not the window:

Uncompressed, JSON is 2.3× protobuf. That is EIP-8178's “hex doubles the wire” in a stopwatch. After gzip the size story gets boring. The CPU story does not.

Receipts say the same thing in a fatter object (JSON raw 784 KB, gzip 77 KB): protobuf+gzip is 1.31 ms against JSON+gzip 5.23 ms.

Gzip ate the size argument

If your post stops at “JSON is verbose,” you are quoting the uncompressed column. Production RPC already speaks gzip. I know that from scars, not theory — bsc-geth #1801 is a production leak in JSON-RPC response gzip. Operators send Accept-Encoding: gzip. The comparison that matters is JSON+gzip versus binary+gzip.

Best size on this set is MessagePack or protobuf with zstd (~106 KB). Best CPU if you can choose the compressor is protobuf+snappy (0.26 ms). The migration people actually propose — “swap JSON for protobuf, keep gzip” — is the 1.6 ms row. Real, not magical.

The rows that are not 1%

Blocks and receipts are the polite table. Logs and blobs are why the Engine API EIPs mention blobs by name.

A synthetic 24-blob-style bundle: JSON+gzip 112 ms, protobuf 1.0 ms. Gzip barely shrinks the binary (already incompressible 128 KiB blobs). It spends a fortune trying to shrink hex. That is the Magicians sentence with a clock on it.

If you run an indexer, a debug/trace API, or anything that returns blobs as JSON hex, this is not a 1% story. It is the request.

Then I looked at the wrong flame graph on purpose

A 3× table is how codec posts get written. The next question is whether that table is the machine.

Marius van der Wijden's 2025 geth pprof — core developer, mainnet full sync — puts about 41% of CPU in InsertChain / the downloader and about 35% in applying transactions. That is EVM and state. It is not json.Marshal. ethereum.org on archive nodes says the same about sync: you are CPU-bound on execution. P2P is already RLP on the execution layer and SSZ on the consensus layer. Swapping 8545's codec does not make a node sync faster.

The people who do burn CPU on JSON have already given that job a separate process. Erigon ships rpcdaemon so the query layer can scale off the chain-follower. Under load, operators have watched it peg 8–9 cores with disk idle (erigon#2245). AWS literally sizes sync nodes and RPC nodes as different instance classes.

So the 3× win has an address. It lives on the RPC product, on fat methods, after the data is in memory. It does not live on a home validator. It does not live in snap sync. It is starting to live on 8551 as blobs grow — which is why the EIPs exist.

A blended public RPC mix is still mostly eth_call and small reads. Those requests spend their time in EVM and disk. Encode is a rounding error. A call-heavy fleet might see a few percent of box-level CPU from a codec change. A logs-and-blocks fleet might see more. I will not invent a single “Ethereum is 4% JSON” number. I do not have a production pprof of an Alchemy-shaped cluster, and neither do most of the posts that imply one.

The codec is not the first place to look

This is the part I am writing to my own hands.

I will open a “10× JSON” post, or an EIP that says hex doubles the wire, and feel underdressed if I am still on encoding/json. That instinct is how you spend a quarter replacing a protocol so you can avoid looking at the actual profile.

On almost every backend I have actually shipped, the order that moved the bill was:

1. The query you should not be making. Chatty Preloads, unbounded eth_getLogs, debug_trace on the hot path.
2. The disk and the pool. Cold page cache, unpinned connections, one AZ too far.
3. The work inside the request. EVM, a lock, a regex, an N+1.
4. Then, if a profile still says encode+gzip, the codec — and only on the pipe that owns that sample.

JSON on 8545 is a political choice dressed as a technical one. Changing it means every wallet, every SDK, every provider. The EIPs are not doing that. They are changing 8551, where both ends are your processes and the SLA is a slot.

If you only remember one structural fact from the table: MessagePack already got you most of the way, because the tax is hex, not the absence of a .proto file. Schema is optional. Stopping 0x is the migration.

make bench-quick

Offline path is synthetic. The numbers in this post are the Alchemy window above. Raw samples from that run live with the harness (results/<timestamp>/raw_samples.jsonl). Dollar figures in the harness report are estimates at $0.09/GB; I am not leaning on them here. The CPU table does not need a price to be true.

I started this wanting a reason to replace JSON. I finished it with a map. The optimization is real. It has an address. For most people reading this — including me, on most Tuesdays — that address is not the public RPC port, and the first tool is not a new encoder.