Does the Trade Actually Work? Performance, Updates, and Deployment Boundaries
ZipPIR’s central claim is a systems claim supported by cryptography: a client can avoid a large database-dependent hint while the server retains a high-throughput online path. This chapter tests that claim against the paper’s 1 GB and 2 GB measurements, separates the measured axes from the costs they do not capture, and asks what the design means for changing databases and privacy-sensitive applications. The goal is a conditional deployment judgment, not a repetition of the headline speed.
What the 1 GB and 2 GB rows actually measure
The paper compares ZipPIR with single-server PIR protocols in a category intended for clients that do not hold a large database-dependent hint. The most useful rows for understanding the design are the 1 GB and 2 GB databases:
| Database | ZipPIR server state per client | Query | Response | Total communication | Server time | Throughput |
|---|---|---|---|---|---|---|
| 1 GB | 120 KB | 708 KB | 181 KB | 889 KB | 339 ms | 3,020 MB/s |
| 2 GB | 170 KB | 782 KB | 255 KB | 1,037 KB | 580 ms | 3,531 MB/s |
The 1 GB row says several things at once. The server keeps 120 KB of state for that client and query arrangement, while the client sends a 708 KB online query and receives a 181 KB response. The combined online communication is 889 KB, and the reported online server time is 339 milliseconds. The measured throughput is 3,020 MB/s. At 2 GB, the server state rises to 170 KB, the query to 782 KB, the response to 255 KB, and the total to 1,037 KB. Server time rises to 580 milliseconds while the reported throughput rises to 3,531 MB/s.
The numbers should be read as a profile, not as one score. The throughput result is strong in the experiment: it is above 3 GB/s for both database sizes. But the query and response are not the same object, and neither is the same as server state. A system designer who cares about client upload bandwidth may focus on the query; a designer who cares about download bandwidth may focus on the response; an operator supporting many clients may focus on the per-client state and its refresh cost. Combining those concerns into “3,531 MB/s” would erase the reason the protocol exists.
The trend also shows why the phrase “small client state” needs a careful referent. The reported 120 KB and 170 KB are server-side per-client state, not the size of the client’s online query and not a claim that the client sends only a few bytes per request. ZipPIR avoids a large database-dependent object stored on the client, but the client still sends hundreds of kilobytes of query material in the listed rows. The design wins on one constraint while retaining a nontrivial communication cost on another axis.
The experiment itself defines the scope of the evidence. The authors implemented ZipPIR in C++ with AVX512 and a Paillier library, using an Intel Xeon Platinum 8276 running Ubuntu 24.04. Offline computation was parallelized, while online computation was single-threaded for comparison with related work. The reported statistics averaged five runs.