by Sora Suegami and Nam Ngo

Indistinguishability obfuscation (iO) is the endgame for Ethereum privacy. This makes it possible to build "the God Protocols" on Ethereum: trustless systems that can behave like a trusted third party.

Unfortunately, iO is far from practical: traditional iO constructions require combinations of primitives so complex that even implementing them has been infeasible. A recent post by Vitalik describes this difficulty in more detail.

Diamond iO, our proposed construction, makes iO simple enough that its end-to-end performance can be concretely estimated. It removes a major existing bottleneck in traditional iO constructions by replacing it with simple matrix products, yielding an estimated speedup of more than $2^{118}$. Nonetheless, the remaining components are still far from practical—the end-to-end evaluation is estimated to require at least $10^{36}$ hours—and several challenges remain before Diamond iO can become practical.

This article aims to demystify Diamond iO by breaking down how it works. It shows that iO is not magic: it is a collection of concrete challenges that the broader community can help solve. In particular, we hope this article serves as a starting point for researchers and engineers working on ZKP, FHE, and MPC to contribute to practical iO research.

Strictly speaking, the security guaranteed by indistinguishability obfuscation for arbitrary programs is limited, and it is not always sufficient for every application. However, in a variant of the random oracle model, it can be upgraded to a stronger primitive called ideal obfuscation. Informally, for most natural, non-contrived programs, ideal obfuscation can protect privacy as strongly as a trusted third party or an ideal TEE—without requiring any additional trusted party or trusted hardware, of course! In the rest of this article, we will not distinguish between indistinguishability obfuscation and ideal obfuscation, and will simply refer to both as iO.

Demystifying Diamond iO: Enforcing Computation on Encrypted Data, from Lattices to iO

If you are familiar with ZKPs or FHE, iO can be viewed as combining properties of both. Specifically:

• (Enforced computation) As in ZKPs, iO forces an untrusted evaluator to correctly perform a computation according to a specified circuit. Otherwise, the evaluator obtains only a random and meaningless value.

• (Computation on encrypted data) As in FHE, iO allows an untrusted evaluator to perform computation on ciphertexts without revealing the encrypted private data.

Surprisingly, Diamond iO, our proposed lattice-based iO scheme, can be constructed in a highly intuitive way—conceptually in three steps in the evaluation—by combining FHE with lattice-based encodings, mainly BGG+ encodings. The following table compares properties provided by FHE and BGG+ encodings.

Primitive	Enforced Computation	Computation on Encrypted Data
FHE	❌	✅
BGG+ Encoding	✅	❌

Therefore, if you are already familiar with lattice-based FHE or ZKPs, we believe that understanding Diamond iO should be relatively straightforward. In the following, rather than leaving the mechanism of iO as something magical, we explain how it can be realized simply as a combination of matrix operations.

The Core Primitive: BGG+ Encodings

Definitions. The core primitive underlying Diamond iO is BGG+ encodings. These encodings are introduced to force the evaluator of the obfuscated circuit, who is an untrusted party, to perform computation along a specific circuit: if the evaluator computes correctly, they obtain the output of that circuit in plaintext; otherwise, they obtain a useless random value.

Each BGG+ encoding is concretely defined as the following vector: $$\begin{align} \mathbf{c}_{x} := \mathbf{s}(\mathbf{A} - x\mathbf{G}) + \mathbf{e}. \end{align}$$

Here, we refer to each component as follows.

• $\mathbf{s}$ is a vector of the secret.

• $\mathbf{A}$ is a matrix of the public key.

• $x$ is an integer of the value being encoded.

• $\mathbf{G}$ is a fixed matrix called gadget matrix, defined later.

• $\mathbf{e}$ is a vector of the small error, necessary for the LWE security.

In addition to this encoding, the evaluator can publicly know the public key, the value, and the gadget matrix, but cannot know the secret or the error.

The evaluator holds such encodings separately for multiple different values $x_1, \dots, x_L$. All of these encodings share the same secret, but each has a distinct public key $\mathbf{A}_{i}$. Crucially, the public key can be also defined independently of the encoded value. Therefore, the obfuscator can know the public keys in advance, before knowing the values to be encoded, which are determined by the evaluator’s input to the obfuscated circuit.

Homomorphism. Similarly to FHE ciphertexts, BGG+ encodings are fully homomorphic. That is, given encodings of some values $x_i$ and $x_j$, the evaluator can compute valid encodings of the sum $x_i + x_j$ and the product $x_i x_j$, without knowing their secret $\mathbf{s}$ or errors $\mathbf{e}_i$.

Furthermore, unlike FHE, BGG+ encodings are also homomorphic with respect to public keys: the public key appearing in the encoding after a homomorphic computation can be deterministically derived solely from the input public keys. Therefore, as long as the obfuscator knows the input public keys $\mathbf{A}_i$ and $\mathbf{A}_j$, it can compute the public key $\mathbf{A}_{i + j}$ corresponding to the addition result and the public key $\mathbf{A}_{i \times j}$ corresponding to the multiplication result in advance, without knowing their values or encodings.

Let us now verify that such homomorphism indeed holds. Addition is always trivial in lattice cryptography: $$\begin{align} \mathbf{c}_{i} + \mathbf{c}_{j} &= \left(\mathbf{s}(\mathbf{A}_i - x_i\mathbf{G}) + \mathbf{e}_i\right) + \left(\mathbf{s}(\mathbf{A}_j - x_j\mathbf{G}) + \mathbf{e}_j\right) \\ &= \mathbf{s}\left(\underbrace{(\mathbf{A}_i + \mathbf{A}_j)}_{=\mathbf{A}_{i+j}} - (x_i+x_j)\mathbf{G}\right) + \underbrace{(\mathbf{e}_i + \mathbf{e}_j)}_{bounded}. \end{align}$$ When $\mathbf{A}_{i+j}:=\mathbf{A}_i + \mathbf{A}_j$, one can confirm that $\mathbf{c}_{i} + \mathbf{c}_{j}$ forms a valid BGG+ encoding of the sum $x_i+x_j$, especially because $\mathbf{e}_i + \mathbf{e}_j$ remains a small bounded error. Besides, $\mathbf{A}_{i+j}$ is derived solely from $\mathbf{A}_i$ and $\mathbf{A}_j$.

Multiplication is always difficult in lattice cryptography. First of all, a naive multiplication, such as taking the inner product of two input encodings, does not form a valid encoding: $$\begin{align} \mathbf{c}_{i} \cdot \mathbf{c}_{j} &= \left(\mathbf{s}(\mathbf{A}_i - x_i\mathbf{G}) + \mathbf{e}_i\right) \cdot \left(\mathbf{s}(\mathbf{A}_j - x_j\mathbf{G}) + \mathbf{e}_j\right)\\ &= \mathbf{s}\mathbf{A}_i \cdot \mathbf{s}\mathbf{A}_j + \mathbf{s}\mathbf{A}_i \cdot \left(-x_j\mathbf{s}\mathbf{G} + \mathbf{e}_j\right)\\ &+ \left(-x_i\mathbf{s}\mathbf{G} + \mathbf{e}_i\right) \cdot \mathbf{s}\mathbf{A}_j + \left(-x_i\mathbf{s}\mathbf{G} + \mathbf{e}_i\right) \cdot \left(-x_j\mathbf{s}\mathbf{G} + \mathbf{e}_j\right) \\ &= \underbrace{\left(\mathbf{s}\mathbf{A}_i \cdot \mathbf{s}\mathbf{A}_j - \mathbf{s}\mathbf{A}_i \cdot x_j\mathbf{s}\mathbf{G} - x_i\mathbf{s}\mathbf{G} \cdot \mathbf{s}\mathbf{A}_j + x_i\mathbf{s}\mathbf{G} \cdot x_j \mathbf{s}\mathbf{G} \right)}_{\text{a quadratic expression in $\mathbf{s}$}} \\ &+ \underbrace{\left(\mathbf{s}\mathbf{A}_i \cdot \mathbf{e}_j + \mathbf{e}_i \cdot \mathbf{s}\mathbf{A}_j -x_i\mathbf{s}\mathbf{G} \cdot \mathbf{e}_j - \mathbf{e}_i \cdot x_j \mathbf{s}\mathbf{G} \right)}_{\text{a linear expression in $\mathbf{s}$}} + \mathbf{e}_i \cdot \mathbf{e}_j \end{align}$$

Even setting aside the fact that this is no longer a vector but a scalar, it still does not form a valid BGG+ encoding for the following reasons. First, the output contains the quadratic expression in $\mathbf{s}$, which is not allowed in the valid form of the BGG+ encoding. Second, the linear expression in $\mathbf{s}$ depends on the errors $\mathbf{e}_i$ and $\mathbf{e}_j$.

To avoid these issues, multiplication between encodings is defined as a linear combination of the input encodings. Before defining this operation, we introduce the definition of the gadget matrix, which we have postponed until now.

Let $q$ be the modulus, $n$ be the lattice dimension, and $m:=n\lceil \log_2 q \rceil$. The gadget matrix $\mathbf{G} \in \mathbb{Z}_{q}^{n \times m}$ is defined by $$\begin{align} \mathbf{G} &:= \mathbf{I}_{n} \otimes (1, \dots, 2^{\lceil \log_2 q \rceil-1}) \\ &= \begin{pmatrix} (1, \dots, 2^{\lceil \log_2 q \rceil-1}) & \dots, & \mathbf{0}\\ \vdots & \ddots & \vdots \\ \mathbf{0} & \dots & (1, \dots, 2^{\lceil \log_2 q \rceil-1}) \end{pmatrix}. \end{align}$$

For any matrix $\mathbf{A} \in \mathbb{Z}_{q}^{n \times m}$, a gadget-decomposed matrix $\mathbf{G}^{-1}(\mathbf{A}) \in \{0,1\}^{m \times m}$ is defined as a bit-decomposed matrix of $\mathbf{A}$, where each column $\mathbf{a}_i \in \mathbb{Z}_{q}^{n}$ of $\mathbf{A}$ is expanded to the bit-decomposed vector $\textsf{bits}(\mathbf{a}_i) \in \{0,1\}^{m}$. Then we have $$\begin{align} \mathbf{G} \mathbf{G}^{-1}(\mathbf{A}) = \mathbf{A}. \end{align}$$

Using the gadget-decomposed matrix, one can define the homomorphic multiplication between BGG+ encodings as follows: $$\begin{align} \mathbf{c}_{i \times j} =&\, \mathbf{c}_{i}\mathbf{G}^{-1}(\mathbf{A}_j) + x_i\mathbf{c}_{j}\\ =&\, \left(\mathbf{s}(\mathbf{A}_i - x_i\mathbf{G}) + \mathbf{e}_i\right)\mathbf{G}^{-1}(\mathbf{A}_j) + x_i\left(\mathbf{s}(\mathbf{A}_j - x_j\mathbf{G}) + \mathbf{e}_j\right)\\ =&\, \left(\mathbf{s}\mathbf{A}_i\mathbf{G}^{-1}(\mathbf{A}_j) - x_i\mathbf{s}\mathbf{A}_j + \mathbf{e}_i\mathbf{G}^{-1}(\mathbf{A}_j) \right) + \left(x_i\mathbf{s}\mathbf{A}_j - x_ix_j\mathbf{s}\mathbf{G} + x_i\mathbf{e}_j\right)\\ =&\, \mathbf{s}\left(\underbrace{\mathbf{A}_i\mathbf{G}^{-1}(\mathbf{A}_j)}_{=\mathbf{A}_{i \times j}} - x_ix_j\mathbf{G}\right) + \underbrace{(\mathbf{e}_i\mathbf{G}^{-1}(\mathbf{A}_j) + x_i\mathbf{e}_j)}_{bounded}. \end{align}$$

When $\mathbf{A}_{i \times j} := \mathbf{A}_i\mathbf{G}^{-1}(\mathbf{A}_j)$, one can confirm that $\mathbf{c}_{i \times j}$ forms a valid BGG+ encoding of the product $x_ix_j$, where the above remains a small bounded error if $x_i$ is small (e.g., bit) because $\mathbf{G}^{-1}(\mathbf{A}_j)$ is a bit matrix. Besides, $\mathbf{A}_{i \times j}$ is derived solely from $\mathbf{A}_i$ and $\mathbf{A}_j$.

Circuit-specific decoding key. It is now time to reveal why BGG+ encodings can force the evaluator to compute a specific circuit. Let the product of the values carried by wires $i$ and $j$ be one of the circuit outputs. As discussed above, the evaluator can compute $$ \mathbf{c}_{i \times j} = \mathbf{s}\left(\mathbf{A}_{i \times j} - x_ix_j\mathbf{G}\right) + \mathbf{e}_{i \times j}, $$ where $\mathbf{e}_{i \times j} := \mathbf{e}_i\mathbf{G}^{-1}(\mathbf{A}_j) + x_i\mathbf{e}_j$. Here, the obfuscator wants to enable the evaluator to decode $\mathbf{c}_{i \times j}$ and obtain the product $x_i x_j$, while revealing no information about the values encoded in any other encodings.

One might think that this is pointless, since the evaluator already knows the encoded input values and can therefore compute the product directly. In fact, the decoding procedure described below can also be applied in settings where some of the encoded values are private and the evaluator does not know the product. We will later discuss how multiplication involving private values can be handled over encodings.

From the above equality for $\mathbf{c}_{i \times j}$, one can observe that the product $x_ix_j$ appearing in the second term is masked by the first term, $\mathbf{s}\mathbf{A}_{i \times j}$. For now, ignore the fact that the second term is multiplied by $\mathbf{s}$ and that a small error still remains. Therefore, if the first term is available separately as the circuit-specific decoding key, the evaluator can extract the output from the output encoding.

At a high level, Diamond iO uses BGG+ encodings as follows.

• The obfuscator who wants to obfuscate a circuit $C$ samples the input public keys $(\mathbf{A}_1, \dots, \mathbf{A}_L)$ and computes the output public keys, e.g., $\mathbf{A}_{i \times j}$. This is possible since the public key for each gate output depends only on the input public keys. Then the obfuscator provides a helper data that allows the evaluator to obtain

  • the input encodings $(\mathbf{c}_{1}, \dots, \mathbf{c}_{L})$ for the evaluator's input bits $\mathbf{x} := (x_1, \dots, x_L) \in \{0,1\}^{L}$,
  • the circuit-specific decoding key for the output public keys.

  We later explain how this helper data is built.

• The evaluator obtains the output $C(\mathbf{x})$ in three steps:

  1. Use the helper data to obtain the input encodings.
  2. Homomorphically compute the output BGG+ encodings.
  3. Use the helper data to obtain the circuit-specific decoding key, allowing the evaluator to obtain the circuit outputs in plaintext.

Unfortunately, the above construction still has two problems. Diamond iO resolves them by combining BGG+ encodings with the two remaining building blocks, namely FHE and GGH15 encodings. Here, we only explain these problems and the high-level ideas behind their solutions; for the details, please refer to our blog posts.

• Problem 1. Homomorphic multiplication between BGG+ encodings requires the evaluator to know the left-hand-side value $x_i$ in plaintext. This implies that BGG+ encodings cannot straightforwardly handle the multiplication between private values.

  • This problem is resolved by using FHE together with BGG+ encodings. Concretely, we encrypt the private values under FHE and encode the resulting ciphertexts as public values in the input BGG+ encodings. Then, we evaluate the FHE homomorphic evaluation and decryption over BGG+ encodings. A key question here is how to delegate the FHE decryption key to the (trustless) evaluator. The obfuscator simply provides the encodings of the key without providing the key itself for the evaluator. This encoding can still be used for a single multiplication by an encoding of a public value since the encoding multiplication requires only one of the two input values in plaintext. As a result, FHE decryption with the noise left intact can be performed over the encodings without revealing the key. Please refer to this post or the AKY24 FE paper for more details.

• Problem 2. How can the obfuscator prepare the helper data that allows outputting the input BGG+ encodings and the circuit-specific decoding key for arbitrary input $\mathbf{x} \in \{0,1\}^{L}$. There are two difficulties. First, both outputs depend on the secret $\mathbf{s}$, which must be distinct for each input $\mathbf{x}$. Second, the helper data needs to return outputs for $2^L$ possible patterns, while both its size and the time required for the obfuscator to prepare it must be bounded by a polynomial in $L$.

  • Diamond iO solves this problem by making it possible to represent these outputs as products of secret matrices, each of which depends only on a single input bit $x_i$. The obfuscator protects these secret matrices using another lattice encoding, called GGH15 encodings, and publishes them as helper data. The evaluator selects some of the given matrices according to their input $\mathbf{x}$, and simply multiplies them together. This simple matrix multiplication yields the required input encodings and decoding key for $\mathbf{x}$, which is a novel and key technique that enables Diamond iO to significantly improve efficiency. Please refer to this post or the Diamond iO paper for more details.

Help Push Diamond iO Toward Practice: Starting Points for Researchers in ZKP, FHE, MPC, and Beyond

The Remaining Bottleneck: FHE Evaluation over BGG+ Encodings

Challenge 1: Practical implementation of FHE evaluation over BGG+ encodings

Diamond iO is still not practical, because FHE evaluation over BGG+ encodings remains the major efficiency bottleneck and requires prohibitively large computation. We introduced many new optimizations and succeeded in implementing them within the range of practical lattice parameters, described in this post. Nevertheless, it is estimated that computing a single FHE multiplication over BGG+ encodings would require more than $10^{16}$ hours on a single GPU.

Even worse, the Diamond iO construction must evaluate, over BGG+ encodings, not just a few FHE multiplications, but a homomorphic PRF: namely, the homomorphic evaluation of a pseudorandom function under an encrypted key. This process accounts for more than 99% of the total evaluation time of Diamond iO, and is estimated to require more than $10^{36}$ hours on a single GPU.

In this sense, the central bottleneck in Diamond iO is not a fundamental impossibility result, but the current lack of scalability in the circuit sizes that can be practically evaluated over BGG+ encodings. Once this scalability reaches a critical threshold—such as the circuit size required for a bootstrapping method of BGG+ encodings—we should be able to evaluate arbitrarily complex circuits without increasing the parameters further. This mirrors the historical trajectory of FHE research, where sustained progress eventually made FHE bootstrapping practical to a meaningful extent. We therefore believe that lattice and FHE researchers can play a major role in addressing this challenge.

Input Scaling

Challenge 2: Input-size scaling without exponential noise growth

Another limitation of Diamond iO is its inability to support large input lengths efficiently. Here, “input length” refers to the input size of the circuit being obfuscated, rather than the size of the circuit itself.

The main reason is that, for the input size $L$, evaluation requires multiplying the LWE noise by $L$ matrices sequentially. This causes the noise bound to grow exponentially with $L$, which in turn forces the modulus $q$ to grow exponentially as well. Maintaining the same security level for larger $q$ requires increasing the lattice dimension $n$ accordingly, and the overall evaluation cost eventually grows by at least roughly $L^{10}$.

Our solution to this limitation is to reset the accumulated noise to a bounded level after every $\ell$ matrix multiplications, where $\ell$ is a constant smaller than $L$. This is essentially the same approach as bootstrapping in FHE. However, implementing this idea requires evaluating a homomorphic PRF over BGG+ encodings, which, as discussed above, is currently the main bottleneck. We believe that exploring how to scale the input size without relying on the homomorphic PRF would be an interesting research direction for lattice and FHE researchers.

Non-Standard Lattice Assumptions Underlying Diamond iO

Challenge 3: Cryptanalysis of evasive and all-product LWE assumptions

Diamond iO relies on two non-standard lattice assumptions: evasive LWE and all-product LWE. The former was introduced in Wee22 and has been used not only for iO but also for simpler primitives such as ABE, FE, and witness encryption. However, it is a relatively non-falsifiable assumption in the sense that its concrete statement depends on a scheme-specific class of samplers, and several works have exhibited counterexample samplers for specific formulations of evasive LWE. A caveat is that these counterexamples should not be interpreted as attacks on the particular samplers used in Diamond iO, nor as attacks on the Diamond iO construction itself.

The all-product LWE assumption is more falsifiable than evasive LWE, but it is a new assumption that we introduced. We are still actively analyzing it, and to the best of our knowledge, no attacks have been found for at least a year since it was first proposed. We believe that both assumptions provide interesting targets for further cryptanalysis.

We also believe that this kind of cryptanalysis is important not only for security, but also for efficiency. A deeper understanding of lattice assumptions riskier than standard LWE—especially assumptions that publish additional auxiliary data to make the evaluator’s, and therefore the adversary’s, computation more efficient—could clarify which kinds of leakage are benign and which are dangerous. This may allow us to introduce bolder but still plausible assumptions that substantially reduce the computational cost of Diamond iO.

(S)NARK proof verification inside BGG+ encodings

Challenge 4: Efficient (S)NARK proof verification over BGG+ encodings

An orthogonal but still important workstream is the construction of the circuit being obfuscated. Specifically, we are interested in verifying a given (S)NARK proof inside the obfuscated circuit. This immediately enables strong applications, including

• witness encryption by obfuscating a null circuit into which an encryptor's message is hardcoded. The obfuscated circuit outputs the message if and only if the given proof is valid.

• Root iO, a single obfuscation of an application-agnostic circuit that is available to all privacy-preserving applications on Ethereum. The obfuscated circuit takes FHE ciphertexts together with a SNARK proof that a specified Ethereum smart contract has authorized their decryption, and outputs their plaintexts only if the proof is valid.

In the Diamond iO construction, BGG+ encodings are generated for both the ciphertext and the proof, and the proof verification is carried out over these encodings. Crucially, if the proof is publicly verifiable, then the proof verification need not be wrapped once again inside FHE over BGG+ encodings; instead, it can be evaluated directly on the encodings.

We believe this opens a concrete research direction for ZKP researchers and engineers: designing proof systems whose verification is cheap to perform over BGG+ encodings—namely, verification procedures with low multiplicative depth and simple arithmetic operations. In this setting, reducing verification depth is especially valuable, much more so than in the usual setting, because the modulus $q$ grows exponentially with the depth. Moreover, it is also important to reduce the proof size, which dominates the size of the input to the obfuscated circuit. As explained in Challenge 2, scaling the input size is one of the hardest tasks in Diamond iO.

Distributed Obfuscation

Challenge 5: Distributed obfuscation without scaling the obfuscated circuit size with the committee size

We have not yet solved the issue that there is a single obfuscator who learns the secrets hardcoded into the obfuscated circuit, which makes the approach unsuitable for Ethereum use cases. This is why we want distributed obfuscation, where $N$ parties jointly perform the obfuscation and no single party learns the secrets unless all of them collude.

In what follows, we assume that the only value hidden by the obfuscation is some hardcoded secret key, such as an FHE decryption key. The rest of the circuit’s logic may be public—or should even be public to enable public verifiability.

A naive solution is as follows. The $N$ parties first run a DKG protocol to generate secret shares of the hardcoded secret key, together with the corresponding public key. Each party then independently generates an obfuscation that hardcodes only its own share. The evaluator can obtain partial decryptions by evaluating each party’s obfuscation, and then recover the plaintext by combining all of these partial decryptions.

However, this approach is inefficient: the total obfuscated size and the evaluator’s computation both grow linearly with the number of parties $N$. We therefore want a solution in which these costs are independent of $N$. In the case of Diamond iO, such a solution would likely rely on several building blocks: DKG for LWE secret shares, MPC for matrix operations, and distributed lattice preimage sampling. Fortunately, these are all topics that have been studied for many years in threshold (lattice) cryptography. We therefore believe that this is a problem to which MPC researchers can make substantial contributions.

Summary

	Challenge	Urgency	Who to tackle?
C1	Practical implementation of FHE evaluation over BGG+ encodings	High	lattice (including FHE) researchers
C2	Input-size scaling without exponential noise growth	High	lattice (including FHE) researchers
C3	Cryptanalysis of evasive and all-product LWE assumptions	Medium	cryptanalysts
C4	Efficient (S)NARK verification over BGG+ encodings	Medium	ZKP researchers
C5	Distributed obfuscation without scaling the obfuscated circuit size with the committee size	Low	lattice or MPC researchers

ObfusBench: A Coordination Hub for Practical iO

To support this effort, we are building ObfusBench, a public leaderboard and obstacle tracker for monitoring progress in concrete iO efficiency.

What do we have so far? For each lattice-based iO construction, we implemented the obfuscation of a PRF with 110 input bits and reported estimates of the end-to-end performance. These remain estimates because executing the full end-to-end procedure with currently realistic GPU resources would still be prohibitively expensive in both time and cost.

However, the lattice parameters used here are ones that we believe satisfy correctness for the full end-to-end procedure—or at least, ones for which we are not knowingly ignoring noise growth in any component. We also confirmed that the lattice estimator reports at least 100 bits of security. This is the most important—and most fundamental—difference from our first benchmark.

Concretely, ObfusBench shows the following metrics.

• total obfuscation/evaluation time (and their live GPU costs). Estimates of the total running time required to execute the full obfuscation and evaluation procedures on a single GPU. They are obtained by measuring the GPU runtime of several unit computational tasks, multiplying each by the corresponding number of invocations, and summing the resulting costs. The live GPU costs are computed by multiplying the estimated total running time by the live hourly cost of the GPU used for the measurements.

• obfuscation size. Estimated data size of the obfuscated circuit.

• obfuscation/evaluation latency. Estimated latency required to execute the full obfuscation and evaluation procedures on a sufficiently large number of GPUs. These estimates are computed assuming that the procedures are parallelized across multiple GPUs as much as possible; for example, multiple unit computational tasks are executed concurrently on different GPUs.

These estimates are visualized by graphs.

Moreover, by clicking on each implementation listed on the leaderboard, you can view the following detailed information about it.

• metadata. This includes the implemented iO scheme’s authors and paper link, the implementers and implementation link, and the record submission date.

• device. The GPU type used for runtime measurements. Generally, the larger the peak VRAM required to execute a unit computational task, the more expensive the required GPU.

• breakdown of the total obfuscation and evaluation times, as well as the obfuscated circuit size. We believe this is essential to clarify bottlenecks.

ObfusBench = coordinator. We hope ObfusBench can serve as a coordinator: when researchers improve individual building blocks within the vast overall iO construction, those improvements will ultimately be reflected in the end-to-end performance evaluation under the same framework. By making these changes traceable to everyone, ObfusBench can attribute each piece of progress to the researchers who contributed it.

Anyone can apply to have a new iO implementation listed on ObfusBench by opening a PR to the ObfusBench repository that adds a single yaml file in the specified format. We will review the submission and accept it if the measurement methodology and security proof of the implemented iO scheme appear sound.

If you want to improve an implementation based on Diamond iO, we recommend building on the mxx library, which includes primitive-level lattice operations, BGG+ encodings, and an implementation of Diamond iO. That said, the current Diamond iO implementation is still somewhat messy and difficult to modify component by component. We are therefore working to clean up the implementation so that each component can be understood and modified without needing to understand the entire system.

An ultimate goal of ObfusBench is to evaluate performance on interesting Ethereum applications that would become maximally trustless through iO. To do so, however, we need to solve at least Challenge 4, which in turn requires solving Challenges 1 and 2 first. In particular, if Challenges 2 and 4 become implementable with practical lattice parameters, then even if completing the full computation would still take a prohibitively long time, we may at least be able to estimate the performance of such applications.