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: 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: 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: Latest implementation: 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: 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 👇

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. 🧵

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.

SpeakUp: a new zkVM we're prototyping for private, client-side proving of WebAssembly programs - built to run on low power devices such as mobile phones and browsers. The underlying proof system explore different tradeoffs for different use cases from mainstream zkVMs. SpeakUp is interactive, and uses vector oblivious linear evaluation (VOLE), which provides a fast linear-time prover and post-quantum security at the cost of larger proofs. See the early design draft below, we're looking for public feedback 👇

PSE's Private Transfers Engineering team interviewed 38 teams building in the private transfers space to find the technical problems holding the ecosystem back. See threads for the full blog and summary of what we heard 🧵

1/Introducing ACTA: Anonymous Credentials for Trustless Agents. A composable privacy layer above ERC-8004 so agents can prove: personhood, reputation, model provenance, user jurisdiction, and more — without publishing the interaction graph. 🧵