Eliminating the Sync Tax: Private Information Retrieval for Zcash

A bank fetches balances with a single API call. An Ethereum wallet, a single RPC request. Zcash? Downloads gigabytes.

A bank server already knows your identity — you're just asking for the data. Public blockchains are transparent by design. On the other hand, the Zcash protocol is fulfilling the promise of a true encrypted store of value by protecting your ledger from observers. The problem? Querying balances reveals the owner's address. So instead, the wallet downloads more data than necessary and searches locally.

This is the "sync tax" — the cost users pay for privacy. Let's unpack why it exists and how to eliminate it.

The Payment Detection Problem

When someone sends money in Zcash, the recipient doesn't get a notification. Transactions are encrypted — even the wallet can't tell which ones are destined for its keys.

The wallet tries to decrypt every transaction on the chain, one by one, until it finds the right ones. This is called trial decryption, and it's exactly as slow as it sounds.

Some clients work around this by downloading compact blocks to save on bandwidth. Full blocks impose ~7.5x bandwidth overhead compared to compact blocks. But downloading compact blocks and selectively fetching full data leaks your transactions to the RPC provider.

Still, even with compact blocks, this is not scalable. Assume 270 KB (full compact blocks) at 2 blocks/min. After a week of inactivity, that would be ~5.4 GB of download!

There's an improvement: payments can be tagged with a unique identifier, and notifications sent out-of-band. While solving scale, this just shifts the privacy problem — the actual payment data must still be queried, and doing so reveals the owner.

The Nullifier Set Problem

In Zcash, the outputs of encrypted transactions published on-chain are called shielded notes. When a shielded note is spent, it remains private. Rather than revealing which note was spent, a wallet publishes a nullifier — a cryptographic marker that says "one note is now consumed" without identifying which one.

This is what enables privacy. But this creates a problem: to check if a note was spent, the wallet downloads every nullifier ever published and checks them against its own notes. As of 2026, that's 2GB of nullifier data and growing.

If Zcash is to reach scale (assume 1000 TPS with 2 actions per transaction), that would be 5GB of nullifier data to download per day.

What If Queries Were Private?

What if you could ask the server "have I received a payment for this tag" or "is my nullifier spent" without revealing which payment or nullifier is yours?

This is private information retrieval (PIR) — the tool that solves this problem.

PIR lets a user query a database without the server learning what was asked for. The server processes the request, returns an answer, and learns nothing.

The mechanism relies on homomorphic encryption — a way to compute on encrypted data. The client encrypts the query. The server evaluates it over the public database and returns the encrypted result back to the client.

To make it private, the server touches every single record in the database. The full database must be streamed through the CPU to compute the response by matrix-vector multiplication with the encrypted query.

InsPIRe Zcash

To understand why PIR hasn't seen production deployment, consider the historical bottlenecks. Early PIR schemes, while mathematically sound, imposed prohibitive costs. Some required the server to store large, client-specific keys, effectively creating a stateful architecture that could not scale to millions of users. Others shifted the burden to the client, requiring them to download massive compressed representations of the database ("hints") before a single query could be issued. This barred "cold start" applications like mobile wallets loading data on startup.

In October 2025, a novel design (InsPIRe) was released that unconstrained the prior trade-offs.

It achieved this by introducing a packing algorithm that drastically compresses the response, allowing us to eliminate any hint pre-downloading while keeping communication comparable to compressed blocks. This result came at the expense of latency. To mitigate, we have observed that the bottleneck is memory-bandwidth-constrained - which is exactly what GPUs are great at improving!

Our prototype focused on storing full action metadata to solve the privacy leakage in Zashi - the Zcash-powered mobile wallet. The system achieved under 272KB communication with sub-100ms query latency.

To enable position lookups efficiently, we introduce a smaller PIR design that maps from (block height, action index) to the transaction’s position in the main PIR.

The same approach applies to nullifier lookups, eliminating the 2GB download.

Prior work showed PIR was impractical for production use. Recent algorithmic advances, bundled with GPU acceleration, suggest it's time to revisit.

What's Next

Once Tachyon's out-of-band notification scheme is implemented, trial decryption can be eliminated. Instead of scanning every transaction, wallets query only for their tagged payments.

The result: lightweight wallets that sync in seconds. Mobile-first privacy, without the sync tax.

In future posts, we'll discuss PIR architectures in greater detail while describing productionization ideas that would allow Zcash to reach planetary scale.