Obfuscation, part II: diamond iO (Buterin)

Vitalik Buterin, 28 July 2026, part II of a series on indistinguishability obfuscation. Parked in the hub _inbox on the day it arrived because no spoke owned cryptography; it is a founding member of this one. Sora Suegami and Janmajaya Mall are credited for review.

T2 — an expert secondary source explaining somebody else's construction, not the construction's own paper. Useful for the framing and the caveats; the primary is not held here.

What iO is for

Obfuscation encrypts a program so anyone can run it on plaintext inputs and get plaintext outputs without seeing its internal logic. The motivating use is handing someone a package that uses a hidden secret key in some circumstances but not others.

Part I covered the mainstream, conservative tech tree, whose blocking problem Buterin states bluntly: "literally galactic runtime" — running one takes longer than the lifetime of the universe. Feasibility breakthroughs notwithstanding, they have stayed theoretical curiosities.

What diamond iO trades

Speed for safety. It buys "planetary, rather than galactic runtime — still infeasible today, but perhaps only a few further optimizations away from becoming a reality at least for a few use cases" by adopting "much braver and more untested cryptographic assumptions."

Structurally it modifies the BGG+14 attribute-based encryption scheme, running FHE inside ABE as traditional iO does, but changes both the conditional-FHE-decryption mechanism and the input-encoding generation. The effect is that it is "just as computationally intensive as functional encryption" rather than a tower built on top of FE. Security rests on two lattice assumptions: evasive LWE (Wee22) and all-product LWE, the latter unique to diamond iO.

The concrete bottleneck is the depth of H₁ inside the ABE×FHE layer, currently a tree of Goldreich PRGs. The post lists six optimization paths.

The caveat is the most valuable part

Buterin's own assessment of the assumptions is unusually direct: they are "at the same time plausible… but also novel and risky." Evasive LWE is non-falsifiable in Naor's sense, there are known settings in which it is false (diamond iO picks a variant that avoids those), and "more security analysis is needed."

This is why the spoke's standing caveat says security is a moving argument rather than a fact. A scheme is described by what it assumes as much as by what it achieves, and here the assumptions are the youngest part of the construction.

Its argument for analyzability

The post's closing claim is not about speed. Diamond iO's real advantage, it argues, is that it can be understood — no towers of protocols inside protocols, so a reader does not need twenty years of prior constructions to follow it. That makes simplicity a security property rather than an aesthetic one: an assumption nobody can analyze cannot accumulate the scrutiny that turns it into a trusted one.

Where it sits in this spoke

The far end of concrete-efficiency. binius and flock argue about factors of 9 and 14 on a laptop; diamond iO is arguing about the gap between "longer than the universe" and "merely infeasible." Same question — what is actually runnable — asked several orders of magnitude earlier in a construction's life, and answered in assumptions rather than in seconds (synthesis).

indistinguishability-obfuscation · concrete-efficiency · vitalik-buterin · binius · flock · synthesis