PSE

1/ 🌱 The zkID team published OpenAC: Open Design for Transparent and Lightweight Anonymous Credentials earlier this week with a show proof time of 0.129 seconds. It describes a zero-knowledge identity construction designed to work with existing identity stacks and was purposely constructed to be compatible with the European Digital Identity Architecture and Reference Framework (EUDI ARF). github.com/privacy-ethere…

Practical iO should not be a problem only for “iO specialists.” We want researchers and engineers from FHE, ZKP, and MPC to be able to contribute to making iO practical. In this explainer, we present concrete remaining challenges in Diamond iO that different communities can work on using their existing expertise: machina-io.com/posts/io-is-no… The point is that practical iO breaks down into several concrete bottlenecks, including: * making FHE evaluation over BGG+ encodings practical; * scaling input size without exponential noise growth; * cryptanalyzing the non-standard lattice assumptions behind Diamond iO; * designing proof systems whose verification is cheap over BGG+ encodings; * building distributed obfuscation without making the obfuscated circuit size scale with the committee size. If you work on FHE, ZKPs, MPC, lattice-based cryptography, or cryptanalysis, there is likely a concrete part of the practical iO roadmap where your expertise can matter. We are also launching ObfusBench as a public leaderboard and obstacle tracker for iO efficiency: sorasuegami.github.io/obfusbench The goal is to make progress visible, comparable, and attributable: when someone improves one component, we want that improvement to show up in end-to-end estimates under a common framework. Practical iO is still far away, but it is becoming a much more modular and collaborative engineering/research problem.

Diamond iO Update We are excited to share that we have introduced several new optimization techniques for Diamond iO, implemented the full end-to-end pipeline with realistic lattice parameters, and produced concrete performance estimates. Latest paper: eprint.iacr.org/2025/236 Latest implementation: github.com/MachinaIO/mxx Last year’s initial Diamond iO implementation deliberately left out one crucial component: FHE evaluation over BGG+ encodings. The reason was simple: the noise growth was too large to support realistic lattice parameters. This component is not specific to Diamond iO. FHE evaluation over BGG+ encodings has been used as a theoretical building block in advanced lattice-based cryptography for more than a decade, but there has been very little work on making it actually implementable. In the latest update, we make this component concrete. We introduce several techniques that substantially reduce noise growth, including native lookup-table evaluation, constant-depth arithmetic circuits, and specialized noise refreshing. The new implementation also runs all major lattice operations on GPUs. Together, these optimizations allow us to instantiate the full Diamond iO pipeline with realistic lattice parameters: a modulus size of at most 1540 bits and lattice dimension 2^{16}, comparable to large parameter sets used in CKKS-style FHE implementations. The total running time is still far beyond practical use, but we can now estimate the end-to-end cost rather than leaving a major component abstract. What improves? Our estimates suggest that Diamond iO reduces the overhead of the main bottleneck in most modern iO schemes: the transformation from functional encryption (FE) to iO. Compared with prior FE-to-iO transformations, Diamond iO reduces this overhead by at least a factor of 2^118, making the transformation almost as efficient as the underlying FE scheme itself. In other words, Diamond iO appears to largely remove the FE-to-iO transformation as the dominant cost. What remains? Diamond iO is still very far from practical. Once the FE-to-iO overhead is reduced, the bottleneck shifts to the final FE decryption step, which requires FHE evaluation over BGG+ encodings. Our current estimate is that this step would still take about 10^36 hours. As explained in Vitalik’s recent post, much of the inefficiency in modern iO comes from the need to stack a complicated tower of cryptographic primitives: FHE × ABE × GC × XiO × ... Diamond iO significantly simplifies this picture: the construction is essentially simple matrix operations plus an FHE × ABE layer, where the ABE component is essentially BGG+ encodings. In our view, this gives a much clearer roadmap toward practical iO: further simplify the remaining FHE × ABE layer, and the gap to practicality could shrink dramatically.

A ten-thousand word monster post trying to cover the entire tech tree behind the main lineage of obfuscation (iO) protocols: vitalik.eth.limo/general/2026/0… Special thanks to all who helped!

We hardened Sonobe, our folding schemes & IVC library, before its first release. Two audits: one human (@alpeh_v) + one AI (@v12sec). Each caught bugs the other missed, but both independently flagged every critical one. Read more 👇 pse.dev/blog/sonobe-up…

5/ 5.65M gas per tx is not too cheap ($3-4 today), but the 100-bit security of our result rests on a proven bound. The next step is to try amortizing this cost across multiple proofs with recursion/aggregation.

4/ Can a new EVM precompile help? Profiling pointed to one operation that appears across FRI, STIR, WHIR and sumcheck - the extension-field inner product c + Σ aᵢbᵢ that we called EXTFIELD_MAC. But it only drops the cost to 4.33M gas.

1/ New post alert! ⏰ Is onchain ZK PQ-ready? Round two of putting WHIR on Ethereum gave us an inconvenient result: small fields shrink proofs but make them challenging to verify. We rebuilt WHIR verifier over a 31-bit KoalaBear field and measured where the gas goes. pse.dev/blog/evm-verif… 🧵

mopro just made history at the very first mobile event by @appjsconf — huge thanks to @swmansion, @expo, and the entire react native community for making this happen!

Public petition signer lists expose signers to retaliation. In high-stakes contexts, knowing who signed can be dangerous. New IPTF writeup: Resilient Civic Participation. Prove a petition reached quorum without ever publishing who signed. Third and final post in our resilience series.

New on the blog: Machina iO's four-part series on circuit-specific decryption keys for FHE. A primitive that lets a decryption committee publish a key for one specific computation and then step away no need for an always-online committee. pse.dev/blog/circuit-s…

7/ What’s next: Here are the links to test if you have a valid Taiwan Citizen Digital Certificate. Web: …f-of-personhood-openac-web.vercel.app iOS Testflight: testflight.apple.com/join/UuVzqwHk Android: drive.google.com/file/d/15ukmBz… We’re also publishing the spec and welcome feedback from builders, researchers, and identity teams. zkspecs: github.com/privacy-ethere… And stay tuned for the upcoming production release in a BBS-style online forum setting.

6/ Why this matters: Privacy-preserving identity needs to work with real credentials, real devices, and real user flows. This implementation shows OpenAC running with an existing credential on mobile devices.

We built a real-world OpenAC implementation for privacy-preserving proof of personhood. It uses an existing government-issued credential, proves eligibility in zero knowledge, supports revocation checks, and runs the proof flow on mobile devices. Check threads for links and summary 🔗

The latest work from the Client Side Proving team- Spartan-WHIR: a transparent (no trusted setup), post-quantum SNARK with 128-bit security.