# Why Zakura Doubled the Lattice Dimension for Zcash Voting This engineering page explains the parameter choice for the lattice-based private information retrieval (PIR) system used to obtain Ironwood nullifier non-membership proofs for Zcash coinholder voting. Before the voting system went into production, the team doubled the lattice dimension from the default 2,048 to 4,096. The change was proactive: the page does not claim that YPIR, LWE, RLWE, or the deployed voting system was practically broken. The article is an account of the team's security-margin decision. Its bit figures are modeled estimates against known attacks, not proofs, guarantees, or equivalent wall-clock attack costs. ## Why the voting system needs PIR The Zcash voting system follows a one-ZEC-one-vote rule. A user proves their balance at a snapshot height and must also prove that the corresponding note has not been spent. That second statement uses a Merkle non-existence proof for the note's nullifier. An off-chain server supplies the proof, which is checked against a root published on the voting side-chain. A direct nullifier query would create a privacy problem: after the nullifier appeared on Zcash mainnet in a later spend, the server could link it to the earlier query. The deployment instead uses YPIR+SP. The client encrypts its query; the server homomorphically matrix-vector multiplies it against a public database and compresses the encrypted response; the client decrypts the requested Merkle proof. The requested row remains computationally hidden from the server. ## What the security estimates mean YPIR uses Regev encryption based on Learning With Errors (LWE). Concrete lattice-security analysis models known attacks against an exact parameter set and reports the cheapest result. Lattice dimension matters, but so do the modulus, noise, secret distribution, number of available samples, and algebraic structure. The page distinguishes two cost models: - Core-SVP prices calls to the hardest underlying lattice operation. It is a deliberately conservative abstraction that omits many real attack costs. - MATZOV accounts for more of an attack's concrete work, including dimensions and available LWE samples. The YPIR paper claims 128-bit security for its default parameters. When the team reran the default configuration, the page reports estimates ranging from 94-bit quantum Core-SVP to 131-bit MATZOV. The 94-bit figure is not a demonstrated 2^94 attack; it is the output of the conservative model. It was nevertheless below the team's desired margin for a new production deployment. ## Why ring structure added uncertainty YPIR uses both unstructured LWE and structured RLWE. LWE handles the server's first matrix-vector multiplication. Sending that result directly would need a large database-dependent hint; the article cites an earlier PIR design whose hint was 121 MB for a 1 GB database. YPIR uses the CDKS transformation to embed the LWE results in the negacyclic structure of a polynomial ring and compress them into an RLWE ciphertext. The same algebraic structure that makes the compression efficient can also give an attacker additional structure to exploit. The article cites 2026 research on the concrete hardness gap between MLWE and LWE. That research reports a consistent 2–3 bit gap for ML-KEM and gaps of up to 15 bits for some sparse-secret RLWE parameters. The page explicitly says those results do not directly break YPIR and do not use identical parameters. They are presented as evidence that an unstructured-LWE estimate should not be treated as the last word for a ring-based construction. ## The deployed parameter choice For launch, the team doubled the lattice dimension from 2,048 to 4,096. Using the same conservative baseline, the article reports: - 238.5 bits under quantum Core-SVP; - 262.8 bits under classical Core-SVP. These are modeled estimates against known attacks. Do not describe them as a proof that an attack requires exactly 2^239 or 2^263 operations. The intended result is additional margin against future attack improvements, better use of ring structure, or changes in cost modeling. ## Performance and production figures The stronger parameters increase resource use. The article reports that one query upload grows from 544 KB to 1.53 MB. Its supplied performance graphic labels this as 2.8x and about one additional megabyte. A vote padded to five notes sends five queries, for 7.65 MB total. The graphic also reports server compute per query rising from 150 ms to 182 ms: 32 ms or 21%. The article says Ironwood made that trade practical. The previous PIR design targeted roughly 67 million Orchard nullifiers, while Ironwood had about 31,000 at voting-system launch. A redesigned tree reduced the private database to 48 MiB and replaced two sequential PIR queries with one. In a 60-second load test at eight concurrent requests, the 4,096-degree configuration completed 689 proofs with zero errors. The page reports 11.48 proofs per second, 685 ms median latency, and 975 ms p99 latency. These are specific load-test results, not general guarantees for every deployment or network condition. ## Caution - The cited attacks did not demonstrate a practical break of PIR. - The 94.3-, 131-, 238.5-, and 262.8-bit values come from different estimator and cost-model views; they are not equivalent wall-clock measurements. - The MLWE/RLWE research cited by the page does not use YPIR's exact parameters and is not described as a direct YPIR break. - No parameter choice is permanent. The page's conclusion is that deployed security models should be revisited as attacks, implementations, and cost models change. - Preserve the page's reported performance figures and their stated context; do not extrapolate them into whole-wallet or whole-voting-system guarantees. ## Primary links - MLWE/LWE hardness-gap paper: https://eprint.iacr.org/2026/279 - Formal refutation of the separate 2026 DCP claim: https://eprint.iacr.org/2026/1693 - YPIR implementation used by Valar Group: https://github.com/valargroup/ypir - CDKS transformation: https://eprint.iacr.org/2020/015 - Lattice estimator: https://github.com/malb/lattice-estimator - Default-parameter analysis script: https://github.com/valargroup/vote-nullifier-pir/blob/d28745c82924e3c5ffb3839334eb1076cb9635cd/docs/security/nullifier-pir-analysis.py - Zcash coinholder voting-chain discussion: https://forum.zcashcommunity.com/t/the-coinholder-voting-chain/56925 - NU7 coinholder vote: https://forum.zcashcommunity.com/t/nu7-coinholder-vote/56912 --- Canonical HTML version: https://zakura.com/engineering/pir-security-parameters/