Ethereum co-founder Vitalik Buterin published the second installment of his cryptographic obfuscation series on July 28 on his official blog, analyzing the protocol architecture of “Diamond iO.” Compared with the “galaxy-level” computation time required by mainstream iO protocols, Diamond iO successfully reduced complexity to “planetary level.” Vitalik believes that with just a few key optimizations, certain specific use cases may become feasible for commercial deployment.
Diamond iO Architecture Breakthrough: “Planetary-Level” Compute Power
(Source: Vitalik.eth)
In traditional iO technology, all homomorphic encryption (FHE) operations are usually performed inside attribute-based encryption (ABE), and then a tower of layered protocols is used to ensure that evaluators can only decrypt after correctly executing the evaluation circuit. This architecture creates a devastating computational burden. Diamond iO solves the problem through two core modifications to the BGG+14 ABE scheme: introducing a brand-new conditional FHE decryption mechanism and a new input encoding generation mechanism, reducing the overall computational strength to roughly equivalent to functional encryption (FE).
In the operation flow, evaluators obtain helper items, perform FHE encryption of the hidden input z, receive the public input bits x and a low-range FHE decryption key s; the protocol cleverly uses a “bucket-wise left shift” operator to scale bit weights and avoid error blow-up, and finally extracts the result through a “trapdoor,” where the trapdoor only releases outputs for computations that correctly match the circuit structure.
Security Assumptions: Evasive LWE and All-product LWE Block Zeroing Attacks
The most controversial but also most innovative part of Diamond iO is its input encoding generation mechanism, which relies on two newer cryptographic assumptions: Evasive LWE proposed by Wee22 and All-product LWE unique to Diamond iO. These assumptions effectively prevent evaluators from leaking secrets through methods such as subtraction, sidestepping the “zeroing attacks” that have repeatedly dismantled early obfuscation protocols.
On the security side, the protocol uses “PROM bootstrap”: it makes the hidden input z contain the real secret along with a random PRF key, then computes a new function with an offset, and finally applies XOR hashing, successfully transforming the obfuscation of pseudo-random functionality into the general iO protocol.
Vitalik admits that these assumptions are relatively novel and carry certain risks; in the future, the cryptography community will still need to invest more effort into security analysis and verification.
Future Optimization Directions: More Efficient PRF, Advanced FHE Protocols, and STARK Integration Optimizations
Diamond iO’s current performance bottlenecks include: BGG+ evaluation overhead (the product of ABE and FHE), internal PRF depth that heavily depends on the input length’s Goldreich PRG tree, tolerance only for low-depth circuits to prevent error accumulation, and the need to use large sub-exponential security parameters. The future optimization directions proposed by Vitalik are as follows:
· Use a more efficient PRF to replace the Goldreich tree
· Switch to more advanced FHE protocols (such as BGV/CKKS or packed GSW)
· Further merge the ABE and FHE layers to reduce overhead
· Perform targeted optimizations for “complete iO programs” that combine with STARK proofs
At the end of the article, Vitalik said the biggest value of Diamond iO lies in its relatively simple structure and ease of analysis—developers do not need to master all the complex constructions from the past 20 years to understand the core. He hopes this article will attract more researchers to work on security analysis and performance optimizations.
Common Questions
What exactly does Diamond iO’s “planetary-level” complexity mean?
In the article, Vitalik describes traditional iO protocols’ required computation time as “galactic,” meaning a level of computation that lasts longer than the lifetime of the universe. Diamond iO successfully reduced complexity to “planetary level.” Although it is still infeasible under today’s hardware conditions, it has significantly shortened the distance from theory to real-world practicality. Vitalik believes that after a few key optimizations, some specific use cases may become commercially deployable.
Which two new cryptographic assumptions does Diamond iO rely on, and what problems do they solve?
Diamond iO relies on Evasive LWE (proposed by Wee22) and All-product LWE (unique to Diamond iO). These assumptions effectively prevent evaluators from leaking secrets through subtraction and similar methods, avoiding the “zeroing attacks” that have previously repeatedly dismantled early obfuscation protocols. Vitalik says these assumptions are relatively novel, and the cryptography community will need to conduct more security analysis in the future.
What performance bottlenecks does Diamond iO currently face most?
The main bottlenecks include: BGG+ evaluation overhead (the product of ABE and FHE), an internal PRF that uses a Goldreich PRG tree whose depth depends on input length, only being able to tolerate low-depth circuits to prevent error blow-up, and the need to use large sub-exponential security parameters. The improvement directions Vitalik suggests include more efficient PRFs, advanced FHE protocols (such as BGV/CKKS), and merging the ABE and FHE layers.
