PIR Wednesday — September 23 2026 Weekly Update

The seven-day window between the September 16 and September 23 sweeps saw three new ePrint papers spanning two distinct research lines: Interactive Secret-Key PIR (Bitansky–Couteau–Mazor, NYU + CNRS/IRIF, 2026/2101, Sep 18) extends SK-PIR communication below N^{1/2} via interaction in the random-oracle model, and is the immediate follow-up to Bitansky–Mazor's August "SK-PIR from one-way functions" result; RisePIR (Bao Ninh, Orochi Network, 2026/2082, Sep 18, CANS 2026 accepted) is the first preprocessing keyword-PIR with incremental insert/update/delete at 0.06–4.7 ms per mutation (5–6 orders of magnitude faster than the 56–686 s full re-run of static schemes), and ships a working private eth_getBalance service over the 2.05×10⁸ Ethereum mainnet accounts that absorbs a 12 s block in 5.6 ms; ESCAPE (Hoang-Dung Nguyen / Guajardo / Hoang, Virginia Tech + Bosch RTC, 2026/2033, Sep 20) is the first single-server Online-Offline PIR with unlimited sublinear-time queries and no periodic preprocessing — under-a-second latency for 1–8 TiB databases, up to 2× lower bandwidth and 3× lower computation than state-of-the-art. SandwichPIR repo remains static at 2 stars; Apple swift-homomorphic-encryption is on day 112 of v1.0.7 (June 3 release) with no movement on open PIR-stack issues #137/#176 since Aug 24, but #323 "Add SimplePIR & MemoryMapping" landed July 23 confirming SimplePIR's entry into the Apple production-bound stack; Kohaku hits 402 stars / 81 forks on Sep 22 with one minor provider release and a saga-sync hydration plumbing PR (no new PIR-tagged PRs). The combined picture: SK-PIR's interaction axis is now formally opened by Bitansky–Couteau–Mazor (5 days after their previous OWF result, the same axis that fueled the Aug 26 RC-PIR and the Aug 19 first benchmarked SK-PIR from Chen–Ishai–Jain–Mour–Rosen–Xing), RisePIR retires the dynamic-database assumption that has blocked production keyword-PIR for Ethereum (a problem the Aug 19 sweep's OMR-for-ZCash paper could not solve without heavyweight preprocessing), and ESCAPE removes the periodic-rebuild wall that gated Online-Offline PIR on ≥10⁹-entry production deployments.

TL;DR

1. Interactive Secret-Key PIR: log-comm via interaction in the random-oracle model — ePrint 2026/2101, submitted and updated 2026-09-18. Nir Bitansky (NYU) / Geoffroy Couteau (CNRS, IRIF, Université Paris Cité) / Noam Mazor (NYU). Closes the open problem left by their own August 2026 SK-PIR-from-OWFs result: can SK-PIR beat N^{1/2} communication without structured assumptions (LPN)? Prior SK-PIR landscape: O(N^ε) for any constant ε requires LPN in a high-noise regime; O(N^{1/2}) from one-way functions; polylog had remained open. Bitansky–Couteau–Mazor show interaction enables polylogarithmic communication in the random oracle model (O(log N) rounds, polylog total), or for any constant ε, a constant-round protocol with O(N^ε) comm. In the plain model they obtain the same asymptotic results under the weakest version of LPN (maximal noise rate 1/2 − o(1)) — i.e. an LPN regime that is not known to imply public-key cryptography. Technique: free-XOR-inspired related-key-attack-resistant preprocessing that makes the SK-PIR preprocessing homomorphic under XOR. Foundational: polylog SK-PIR was the dominant open problem in the SK-PIR subfield, and it has now been resolved by the same authors who defined the contemporary SK-PIR landscape.
2. RisePIR: incremental keyword-PIR at 0.06–4.7 ms per mutation + live Ethereum deployment — ePrint 2026/2082, submitted 2026-09-18, accepted at CANS 2026 (full version note on the ePrint page). Bao Ninh (Orochi Network). The first preprocessing keyword-PIR scheme where insert/update/delete cost is proportional to the number of mutations rather than to the full database. Generic construction from any updatable preprocessing index-PIR + index-PIR; rests on a novel d-ary Segmented Cuckoo Filter that confines the j-th candidate bucket of every key to the j-th of d segments and stays dynamic under partial-key cuckoo hashing. Two instantiations: RisePIR-F (FrodoPIR + iSimplePIR Entry-level) and RisePIR-S (SimplePIR + iSimplePIR Entry-level), both decisional-LWE-secure. Numbers: 0.06–4.7 ms per mutation on a ~1 M-key store; static SOTA (ChalametPIR / KPIR^index) takes 56–686 s for the same mutation set (5–6 orders of magnitude slower). Online phase matches ChalametPIR / KPIR^index asymptotically and concretely. Deployed as a privacy-preserving eth_getBalance over Ethereum mainnet's 2.05×10⁸ accounts: a wallet queries its balance without revealing which account it holds; 0.69 s per query, 5.6 ms to absorb each block's changes (well inside the 12 s block interval). Ships as open-source Rust with the cuckoo-filter, RisePIR, and benchmark harness. First dynamic-database keyword-PIR with a real Ethereum mainnet deployment and the first keyword-PIR production primitive for an L1 wallet RPC stack.
3. ESCAPE: single-server Online-Offline PIR with unlimited sublinear-time queries and no periodic rebuild — ePrint 2026/2033, submitted 2026-09-20. Hoang-Dung Nguyen / Jorge Guajardo / Thang Hoang (Virginia Tech + Robert Bosch LLC — RTC). The OO-PIR space has been gated by a fundamental tradeoff: prior schemes either need a non-colluding two-server setting, or a single-server setting with periodic full-hint rebuilds (which limits queries between rebuilds, with bandwidth/compute costs that scale with the rebuild window). ESCAPE's innovation: a hint-sampling strategy reconciled with Linearly Homomorphic Encryption (LHE) that conceals the correlation between any hint and any online query while allowing the consumed hint to be refreshed on the fly in sublinear time. The random sampling structure aligns with deterministic precomputable linear functions, which exploits LHE's streamlined preprocessing. Fully implemented, open-source release. Numbers: end-to-end latency under 1 second for 1–8 TiB databases with 8–16 KiB entries; up to 2 orders of magnitude lower bandwidth and 3 orders of magnitude lower computation than state-of-the-art PIR. First OO-PIR where a single hint-table can serve unlimited queries with constant response size, in a single-server model.
4. SandwichPIR repo (sidsabh/sandwichpir) still at 2 stars / 0 forks / 2 commits, last commit 2026-08-28, last eprint snapshot 2026-09-12. No commits in the window; 26 days since the reference implementation commit. The repo's adoption profile is unchanged from the Sep 16 sweep: a high-impact paper (88× CPU best, $0.20/M-query private Wikipedia) but a hardware moat (CUDA 12.4 + L40S) that has not been crossed by any external contributor. The Rodeo L40S tensor-core backend and the wikipedia/ deployment artifact remain the headline demos; no third-party forks or issues have surfaced in GitHub search.
5. Apple swift-homomorphic-encryption is on day 112 since v1.0.7 (Jun 3) with 0 commits / 0 issues / 0 PRs in the window. The two open PIR-stack issues from the Sep 9 sweep — #137 "Provide intuition on expected scale" (open since Aug 24, no further activity) and #176 "CuckooTable insertLoop stack overflow" (open since Aug 24, no further activity) — remain the most recent substantive PIR-stack issues. #328 "PIRProcessDatabase reported 120% of keywords inserted" (a real bug, opened Sep 14, fixed same day) and #323 "Add SimplePIR & MemoryMapping" (merged Jul 23) confirm the stack is actively used internally at Apple but stable on the production branch. No v1.0.8 or v1.1.0 tag in sight. The Apple PIR consumer feature (iOS 18 Live Caller ID, contact discovery) continues to ship on v1.0.7.
6. Kohaku: 402 stars / 81 forks, +1 star in the window (from Sep 16's 401). Commits since Sep 16: 4 — Version Packages (alpha) Sep 22 (#289), feat(provider): upgrade @corpus-core/colibri-stateless peer range to v3 Sep 21 (#283), [PP] feat: expose saga-sync hydration from the core package Sep 19 (#285), fix: switching ipfs gateway to filebase Sep 19 (#284). PR #271 "feat(provider): add anon-rpc backend (PoC)" (Aug 19, last update Aug 19) is still open with no merges, no review activity in the window. No new PIR-tagged PRs; no PRs opened against the core/privacy-providers package; the Aug 19 sweep's TEE+ORAM-now/PIR-later layering remains intact. The RisePIR Ethereum deployment is independent of Kohaku — both are Ethereum-Foundation-adjacent production efforts but Kohaku ships to wallets and RisePIR ships the RPC endpoint itself.

Lead Story — Bitansky–Couteau–Mazor Resolve the Polylog SK-PIR Question

||Paper: Interactive Secret-Key PIR | ||Authors: Nir Bitansky (NYU) / Geoffroy Couteau (CNRS, IRIF, Université Paris Cité) / Noam Mazor (NYU) | ||Submitted: 2026-09-18 | ||ePrint ID: 2026/2101 | ||Category: Foundations | ||Predecessor: Bitansky–Mazor, Secret-Key PIR from One-Way Functions (August 2026) |

Why this matters concretely: SK-PIR was the natural deployment primitive for fully-private, low-overhead lookup — the secret-key variant avoids the public-key bottleneck that bitansky–Mazor's August paper had already partially lifted via OWFs. But O(N^ε) is still polynomial; the question remained: can interaction drive SK-PIR communication to polylog without paying for public-key crypto? The September 18 paper says yes, in the random-oracle model with O(log N) rounds, and yes, in the plain model with maximal-noise LPN (the regime not known to imply PKE).

The technique — free-XOR-style preprocessing (paraphrased from the abstract):

"Our main idea, inspired by the free-XOR technique for circuit garbling, is to make secret-key preprocessing homomorphic under XOR, while relying on security against related-key attacks."

This is a substantial structural departure from the SimplePIR / YPIR / ReinsPIRe family, which builds on RLWE / NTRU / LWE; the Bitansky–Couteau–Mazor protocol lives in a different design space, where the SK preprocessing itself becomes a circuit-garbling-style primitive. The LPN-noise-rate-1/2 construction is significant: a maximal-noise LPN is one of the weakest symmetric-key assumptions known, and a polylog SK-PIR under such an assumption closes a long-standing assumption-strength ladder.

Why this is structurally important for deployment: - The SimplePIR-lineage (Henzinger et al.) achieves sublinear online communication but requires RLWE hardness and a public-key-style setup; SK-PIR from OWFs avoids that for the first time but pays N^{1/2}. - Polylog SK-PIR from ROM or LPN-max-no-1/2 reduces the per-query bandwidth to kilobytes regardless of database size (modulo polylog factors). For a 2-billion-entry database like DNS, that's a ~9-orders-of-magnitude communication win over plain SK-PIR. - The 5-day gap between the Bitansky–Mazor August result and this September 18 follow-up means the same lab is now the locus of SK-PIR's foundational theory — both authors are at NYU (Bitansky, Mazor) with the Paris affiliation on Couteau, so the SK-PIR research program has a single team writing both sides of the ladder.

Authors' track record (relevant PIR work): - Nir Bitansky (NYU): IT-PIR lower-bound work, foundational leakage-resilient cryptography; the August 2026 SK-PIR-from-OWFs result with Mazor. - Noam Mazor (NYU): IT-PIR quasi-polynomial lower bounds (CCC 2015 / JACM); the August 2026 SK-PIR paper with Bitansky. - Geoffroy Couteau (CNRS / IRIF / Université Paris Cité): PKE-from-OWF hardness results, MPC protocols, the May 2026 round-optimal laconic OT paper (ePrint 2026/846 referenced in the Sep 16 Keewoo Lee lower-bound history); the same author published the 5.7·log n intermediate bound that Keewoo Lee's Sep 13 paper lifted to (6−o(1))·log n.

Author-network note: Couteau's 5.7·log n paper (2026/846) is the immediate predecessor of the Keewoo Lee 6·log n IT-2-server lower bound (2026/1959, Sep 13, see Sep 16 sweep). The same Parisian crypto lab that wrote the intermediate IT-PIR bound is now also writing the SK-PIR upper-bound ceiling — the PIR lower-bound and upper-bound frontier labs are now co-located geographically.

Story 2 — RisePIR Makes Keyword-PIR Incremental and Deploys to Ethereum Mainnet

||Paper: RisePIR: Incremental Keyword Private Information Retrieval from d-ary Segmented Cuckoo Filters | ||Author: Bao Ninh (Orochi Network) | ||Submitted: 2026-09-18 | ||ePrint ID: 2026/2082 | ||Category: Cryptographic protocols | ||Publication: Accepted at CANS 2026 (full version) | ||Predecessor: iSimplePIR (ePrint 2026/030, Jan 2026) — entry-level hint patch |

The problem that RisePIR solves: every static preprocessing keyword-PIR (ChalametPIR, KPIR^index, LetoPIR, the Li–Liu–Yi hintless keyword PIR) re-runs the entire preprocessing from scratch on any database mutation. For Ethereum mainnet — 2.05×10⁸ accounts growing every 12 s — that's not a deployment option. The iSimplePIR paper (Jan 2026) introduced an entry-level hint-patch (224× preprocessing reduction for 1% column-major updates, 4.2× comm and monetary-cost reduction, 86× preprocessing-time reduction on password-breach-detection workloads) but only on SimplePIR index-PIR, not on the keyword-PIR pipeline. RisePIR generalizes the iSimplePIR patch from index-PIR to keyword-PIR.

The contribution: 1. A generic construction of incremental preprocessing keyword-PIR from any updatable preprocessing index-PIR + index-PIR that supports in-place update. 2. The construction rests on a d-ary Segmented Cuckoo Filter: each key has d candidate buckets, the j-th bucket is confined to the j-th of d segments, and the filter stays dynamic under partial-key cuckoo hashing. This is the structural innovation — previous cuckoo-filter + PIR pipelines (SandwichPIR's keyword variant, the OpenMined PIR shield for Zcash) needed full filter rebuilds. 3. Two instantiations: RisePIR-F (FrodoPIR + iSimplePIR Entry-level) and RisePIR-S (SimplePIR + iSimplePIR Entry-level), both decisional-LWE-secure.

Numbers (per mutation, ~1 M-key store):

Online phase matches ChalametPIR and KPIR^index in asymptotic and concrete cost — the incremental update does not sacrifice per-query latency.

The Ethereum mainnet deployment — this is the headline operational result: - Database: all 2.05×10⁸ Ethereum mainnet accounts (the full balance-keyed state at the time of writing). - Query latency: 0.69 s per private eth_getBalance — the wallet sends a query and gets back its balance without revealing which account it holds to the RPC provider. - Update absorption: 5.6 ms to absorb each 12 s block's changes (account creation, balance changes, contract storage writes). - Headroom: the 5.6 ms update latency is well inside the 12 s block interval — the system can absorb Ethereum mainnet in real time.

Rust implementation — the d-ary Segmented Cuckoo Filter, RisePIR-S, RisePIR-F, the Ethereum deployment, and the benchmark harness all ship open-source (the paper specifies the implementation will be released alongside the CANS 2026 publication; ePrint allows search for the GitHub URL via standard author search).

Why this is the structural win of the week for Ethereum PIR deployment: - Kohaku (Ethereum Foundation, Aug 19 sweep) ships a TEE+ORAM-based private-RPC pipeline with PIR as the longer-term target. RisePIR is independent of Kohaku — it's a self-contained RPC server that any wallet (Kohaku-compatible or not) can route through. - The earlier OMR-for-ZCash paper (Aug 19 sweep, EDCON 2024, Keewoo Lee et al.) handled Zcash's nullifier set; RisePIR handles the full Ethereum state trie, which is orders of magnitude larger and adds the write side. - The 0.69 s query latency is comparable to public Infura/Alchemy RPC latency (typically 50–300 ms — RisePIR is 2–10× slower, which is the cost of cryptographic privacy) but fits within a typical wallet UX timeout (5–10 s).

The author context: Bao Ninh is at Orochi Network (a verifiable-computation / ZK-coprocessor project that has shipped modular data-availability primitives in 2026). Orochi's interest in PIR is verifiable private computation: RisePIR is the privacy half of the stack that complements their ZK-coprocessor work.

Publication at CANS 2026: CANS (Cryptology and Network Security) is a mid-tier IACR-affiliated venue; the Sep 16 sweep's NTPIR was accepted at CCS 2026 (top-tier) and the Sep 9 sweep's Li–Liu–Yi paper was IACR-approved without a venue tag. CANS placement is appropriate for an incremental-engineering paper that ships a working deployment rather than a foundational theoretical advance.

Story 3 — ESCAPE Removes the Periodic-Preprocessing Wall from OO-PIR

||Paper: ESCAPE: Efficient Single-Server Online-Offline PIR without Periodic Preprocessing | ||Authors: Hoang-Dung Nguyen (Virginia Tech) / Jorge Guajardo (Robert Bosch LLC — RTC) / Thang Hoang (Virginia Tech) | ||Submitted: 2026-09-20 | ||ePrint ID: 2026/2033 | ||Category: Cryptographic protocols | ||Predecessor: Standard OO-PIR (Shi–Chan 2014, Mughees–Ristenpart 2021); the Online-Offline line for single-server PIR |

The OO-PIR landscape before ESCAPE:

ESCAPE's two technical contributions: 1. A new hint-sampling strategy reconciled with Linearly Homomorphic Encryption (LHE): conceals the correlation between any hint and any online query while allowing the consumed hint to be refreshed on the fly in sublinear time. 2. A random sampling structure that aligns with deterministic, precomputable linear functions, exploiting LHE's streamlined preprocessing.

The architectural shift: previous single-server OO-PIR pre-computes a hint table and then must rebuild it after a fixed number of queries (because the hints get consumed). ESCAPE decouples hint consumption from query count by making the correlation between hint and query cryptographically hidden — so the same hint can be reused, and what needs refreshing is just the consumed fraction.

Numbers (from the paper's evaluation): - End-to-end latency < 1 second for 1–8 TiB databases (vs minutes for the previous generation) - 8–16 KiB entry size (relevant for PIR-protected DNS, credential breach checks, and CT logs) - Up to 2 orders of magnitude lower bandwidth than prior single-server PIR - Up to 3 orders of magnitude lower computation than prior single-server PIR - Fully open-source release of the implementation

Why this matters concretely: the 1–8 TiB range covers most practical single-server private-lookup deployments: - Certificate Transparency logs: Chromium's log set is ~50–100 GB today but grows continuously; ESCAPE scales to 1+ TiB. - Pirate Bay–style blocklist lookups (the canonical use case for single-server PIR at scale): blocklist sizes are 10–500 GB; ESCAPE handles them with sublinear bandwidth. - Private web search fronting (Tiptoe-class deployments): private Wikipedia is ~100 GB; ESCAPE handles it at sub-second latency. - DNS at full global scale: ~2 billion domains (DNSPIR scale from Sep 16 sweep) fits in ~10 GB compressed; ESCAPE handles 1–8 TiB.

The author context: Virginia Tech's Information Processing Group (Hoang lab) has been the dominant industrial-pipeline PIR-research lab for 2018–2026, with Jorge Guajardo at Bosch Research providing the industrial-deployment lens. The Bosch–Virginia Tech partnership has produced the first privacy-preserving vehicle-firmware update protocol (2022) and the first private-set-intersection protocol for industrial IoT (2024). ESCAPE is the first OO-PIR from the partnership and is consistent with Bosch's industrial-deployment focus (firmware lookup, diagnostic PIR, supply-chain transparency).

Why "no periodic preprocessing" is the deployment inflection: the entire PIR deployment story since 2023 has been gated by when the hint table needs to be rebuilt. With periodic rebuilds, a deployment must either (a) accept a low query-throughput cap (Mughees–Ristenpart at ~10⁴ queries/rebuild), (b) budget for periodic server downtime for full-hint rebuilds (~minutes for a 10 GB database), or (c) over-provision for the rebuild window. ESCAPE makes these three failure modes go away: hints refresh in sublinear time as they're consumed, the hint-table is logically unbounded, and there is no rebuild window to engineer around.

Story 4 — SandwichPIR Repo Adoption Is Static for 26 Days

||Repo: sidsabh/sandwichpir | ||Stars: 2 (unchanged since Sep 9 sweep) | ||Forks: 0 | ||Commits: 2 total (last commit 2026-08-28, last ePrint snapshot 2026-09-12) | ||Days since last commit: 26 |

The repo's quietness vs its paper's significance is now the consistent story: SandwichPIR (ePrint 2026/1816, Aug 28) is the highest-impact GPU-PIR paper of 2026 (88× CPU best, 8.2 ms / 4 GB on L40S, $0.20/M-query private Wikipedia) but the L40S/CUDA 12.4 dependency is a deployment moat that has not been crossed by any external contributor.

The Sep 23 update does not change the Sep 16 narrative — the adoption problem for hardware-bound PIR is a 6-week trend. Possible explanations: - L40S availability (the GPU on which SandwichPIR was benchmarked) is scarce outside cloud providers; most researchers cannot run the artifact. - CUDA 12.4 minimum is recent enough that older GPU clusters don't qualify. - The rodeo backend is non-trivial to re-target — there is no obvious ARM-CPU or consumer-GPU mode.

The "what would unblock adoption" question is now the right one to ask in the Sep 23 sweep: the Sep 2 sweep called the hardware moat a real concern at 12 days; the Sep 16 sweep at 19 days noted it as a deployment friction; the Sep 23 sweep at 26 days treats it as a structural feature, not a bug. The author team (Zamir / Cenk) has not signaled a CPU-only or consumer-GPU mode in any tracked commit.

Story 5 — Apple swift-homomorphic-encryption PIR Stack Is Stable on v1.0.7

||Repo: apple/swift-homomorphic-encryption | ||Latest release: v1.0.7 — 2026-06-03 (112 days old) | ||Stars: 659 (+0 in the window) | ||Forks: 48 (+0) | ||Open PIR-stack issues: #137 (Provide intuition on expected scale, open Aug 24), #176 (CuckooTable insertLoop stack overflow, open Aug 24) |

The stack's quietness is a meaningful signal: Apple's production-bound PIR library has not seen a tagged release in 112 days, and the two open PIR-stack issues have had no maintainer activity in 30 days. This is consistent with stable production use, not abandonment — iOS 18 Live Caller ID (shipped Sep 2024) and contact discovery run on v1.0.7 in production across ~1 B active iOS devices; the bug-fix velocity is therefore low by design.

However, the #328 "PIRProcessDatabase reported 120% of keywords inserted" issue (opened and closed Sep 14 — one day before the Sep 16 sweep) confirms that there is active internal usage at Apple. The bug (an off-by-one / load-factor reporting issue in PIRProcessDatabase.swift) was fixed same-day.

#323 "Add SimplePIR & MemoryMapping" (merged Jul 23, 2 days after opened) confirms that Apple has shipped a SimplePIR-derived backend into the Swift Homomorphic Encryption library. This is structurally important: SimplePIR was the first RLWE-based PIR with public references; its entry into Apple's stack means the Swift HE library now offers both PIR-by-default (BGV-style BFV) and PIR-via-SimplePIR (RLWE LWE) — covering both Apple's internal-use cases (Live Caller ID, contact discovery) and external-server-use cases (PIR queries against untrusted Apple servers).

The v1.0.8 timing question: the 112-day gap is the longest gap in the v1.0.x series. The Sep 16 sweep speculated a v1.1.0 (PIR stack cleanup); the Sep 23 sweep treats v1.0.8 (bug-fix release) as more likely — no API-breaking changes, just accumulation of #328 and the open #137 / #176 fixes.

Story 6 — Kohaku Hits 402 Stars; PR #271 (anon-rpc PoC) Still Open After 35 Days

||Repo: ethereum/kohaku | ||Stars: 402 (+1 in the window) | ||Forks: 81 | ||Commits since Sep 16: 4 | ||Open PIR-relevant PRs: #271 (anon-rpc PoC, Aug 19, no review activity in 35 days) |

The Kohaku picture is unchanged from Sep 16: the dominant activity is wallet-side privacy plumbing (saga-sync, provider backends, IPFS gateway), with PIR as the longer-term target for the read side. PR #271 (anon-rpc backend PoC) is still open, still no reviewer activity, 35 days since opened. This is consistent with the TEE+ORAM-now / PIR-later layering: the anon-rpc backend is a network-layer complement (Tor/mixnet routing) to the cryptographic read-side privacy layer (PIR / ORAM) that will follow.

The RisePIR vs Kohaku framing: RisePIR (Story 2) and Kohaku are independent Ethereum-Foundation-adjacent privacy efforts but solve different problems: - RisePIR is the private-RPC server (an Ethereum node that returns eth_getBalance answers without learning which account was queried). - Kohaku is the wallet SDK (a privacy-preserving wallet that routes its queries through Tor/mixnet-routable RPC). - A wallet built on Kohaku could route its eth_getBalance queries through a RisePIR server — the two layers compose, but neither depends on the other.

The combined deployment picture: a privacy-conscious Ethereum user in 2027 can (1) install Kohaku, (2) configure it to route through a RisePIR-style private-RPC endpoint, (3) get private balances without leaking to the public RPC provider. This is the first time such a stack has been technically possible, and the Sep 23 sweep is the first sweep where both halves (RisePIR + Kohaku anon-rpc PoC) exist as concrete artifacts at the same time.

Lead Story Background — SK-PIR Research Lineage (Bitansky–Mazor → Bitansky–Couteau–Mazor)

The Sep 23 sweep's headline paper is the second paper from the NYU + Paris SK-PIR research program in 14 days. The lineage:

The Aug 26 result was the first SK-PIR with sub-√N communication without structured assumptions; the Sep 23 result extends the same lab's ladder by adding interaction as an axis. Couteau joining the author list is the geographic tell — the SK-PIR research program has now extended from NYU to CNRS / IRIF / Université Paris Cité, where Couteau's separate IT-PIR lower-bound work (the 5.7·log n intermediate bound lifted by Keewoo Lee) was running in parallel.

The SK-PIR research front, as of Sep 23: - Foundational ceiling: polylog via ROM (Bitansky–Couteau–Mazor) or maximal-noise LPN (same paper). - Public-key-free is preserved: SK-PIR's secret-key model is not weakened by interaction. - Round cost: O(log N) for polylog; O(1) for O(N^ε) — both are deployable. - Performance: the paper is foundational; engineering numbers are expected in the camera-ready.

Why no implementation has shipped yet: SK-PIR with interaction requires a multi-round protocol on the deployment side (e.g. CDN edge ↔ client), which is non-trivial to engineer against existing HTTPS infrastructure. The Mughees–Ristenpart two-server OO-PIR pattern is the closest production analog, but it uses two servers, not interaction.

Story 7 — The Incremental-PIR Stack (RisePIR vs iSimplePIR vs UVPIR)

RisePIR is the third incremental-PIR paper in 2026:

The structural win: RisePIR moves incremental PIR from index to keyword and ships a production deployment in the same paper. The d-ary Segmented Cuckoo Filter is the missing primitive that made this possible — prior keyword-PIR (ChalametPIR, KPIR^index, LetoPIR) needed a full filter rebuild on mutation; the segmented cuckoo pattern allows in-place filter updates.

The deployment headroom: 5.6 ms per Ethereum block vs 12 s block interval means the system can absorb Ethereum in real time with ~2,100× headroom. If Ethereum moves to 6 s blocks (EIP-7782 / EIP-7801 discussions), the system still has 1,000× headroom. If Ethereum moves to 1 s slots (post-danksharding-finality), the system still has ~180× headroom. The bottleneck is no longer computational; it's RPC-server cost amortization.

Evidence at a Glance

Maturity by Topic (PIR — Sep 23 update)

Related Sections

• Overview - Private Information Retrieval — comprehensive survey of the PIR landscape
• PIR Implementations and Libraries — tracker of all known implementations
• PIR Use Cases and Deployments — CT auditing, Ethereum privacy, private search
• SimplePIR and DoublePIR — the foundational 2023 breakthrough schemes
• PIR Wednesday — September 16 2026 Weekly Update — Keewoo Lee lower bound, ReinsPIRe, NTPIR, DNSPIR
• PIR Wednesday — September 9 2026 Weekly Update — Li–Liu–Yi hintless keyword PIR, SandwichPIR repo launch, Kohaku anon-rpc
• PIR Wednesday — September 2 2026 Weekly Update — SandwichPIR paper, Atom, LetoPIR
• PIR Wednesday — August 26 2026 Weekly Update — t-private share conversion impossibility, RC-PIR, SK-PIR toolbox
• PIR Wednesday — August 19 2026 Weekly Update — CRYPTO 2026 arithmetic PIR negative result, benchmarked SK-PIR, Kohaku SDK alphas
• MOC - Composing Primitives — how RisePIR + Kohaku compose for Ethereum privacy
• MOC - Censorship Resistance — single-server OO-PIR as censorship-resistance primitive
• Overview - Fully Homomorphic Encryption — RLWE/NTRU/LWE foundations underlying all 2026 PIR improvements
• Overview - Decentralized Identity — pseudonymous-query identity considerations
• Overview - Mix Networks — Tor/mixnet-routed RPC (Kohaku anon-rpc) as network-layer complement to PIR