One of the biggest challenges in blockchain privacy is finding a trustless and verifiable way to run confidential computations. Cryptographic primitives like indistinguishability Obfuscation (iO), Multi-Party Computation (MPC), and Fully Homomorphic Encryption (FHE) are being explored to make this possible.
If they work, it would be a major breakthrough - enabling secure, private computation without relying on hardware trust assumptions.
The implications are huge: full privacy for blockchains, dark pools, and trustless on-chain agents, all while maintaining verifiability.
This kind of system would act like a software-based Trusted Execution Environment (TEE), but unlike TEEs it would eliminate reliance on hardware manufacturers.
It’s an extremely compelling vision, and in some ways, this represents the holy grail of blockchain privacy. And privacy is also necessary for mainstream, institutional adoption and compliance, e.g., with GDPR and other data privacy laws worldwide.
But how feasible is this vision? How close are we to making it a reality?
We’ll explore the viability of iO in this article.
Bonus content/spoiler alert: read until the end for an architecture of a practical use case (Dark Pool) using obfuscation and proxy re-encryption.
The Current Landscape
To achieve private, secure computation without relying on hardware, researchers are exploring several cryptographic approaches that could serve as software-based alternatives to Trusted Execution Environments (TEEs):
Multi-Party Computation (MPC): This technique allows a set of parties to compute any function in a distributed setting such that the parties’ inputs remain private and only the result of the computation is revealed. Unfortunately, MPC requires a significant amount of interaction and does not scale well with increasing sets of parties.
Fully Homomorphic Encryption (FHE): FHE allows arbitrary computations on encrypted data without ever decrypting it. While powerful in theory, FHE remains inefficient for most real-world use cases due to a significant computational overhead. FHE also requires the result of the computation to be decrypted, i.e., the decryption key must be stored somewhere. This introduces a single point of failure that, if unresponsive, could bring the entire system to a halt or that could decrypt intermediate ciphertexts, thereby compromising the confidentiality of the data.
Program Obfuscation: A potentially more promising candidate, discussed in the Ethereum community (see e.g. Vitalik’s ethresearch post) is program obfuscation. It is being actively researched as a potential solution.
The State of Obfuscation
In cryptography, there are several forms of program obfuscation. The two most widely known are Virtual Black-Box Obfuscation (VBB) and indistinguishability Obfuscation (iO):
Virtual Black-Box Obfuscation: VBB is the most powerful form of obfuscation. It turns a program into a “black-box” that hides its inner workings and only reveals its input-output behavior. In some sense, this is what everyone working in cryptographic privacy dreams of: a virtual “black-box" that executes a program without revealing its inner working, similar to a TEE, but without the need for hardware. Unfortunately, Barak et al. proved that universal VBB is impossible, i.e., there exist programs that fundamentally cannot be obfuscated in this way.
However, not all hope is lost. Researchers have shown that it is feasible to obfuscate specific programs - like proxy re-encryption via VBB. These examples show that while universal VBB may be impossible, limited forms of black-box behavior are achievable in practice.
Indistinguishability Obfuscation: iO is probably the best known and most actively researched obfuscation primitive today. It’s also the version most often discussed in the Ethereum community.
iO guarantees that two functionally equivalent programs become indistinguishable once obfuscated. This guarantee may sound modest at first glance, but in practice it’s extremely powerful. Research has shown iO to be an extremely versatile tool that can be used to construct many cryptographic primitives, including advanced ones such as witness encryption and functional encryption.
Other Forms of Obfuscation: There are also other, less known variants of obfuscation, such as Oracle-Differing-Input (odiO) and Oracle-Indistinguishability (oiO) obfuscation. These haven’t received as much attention.
Inconvenient Truths about Obfuscation
Among the different forms of obfuscation, iO has gained the most attention. However, it is not a silver bullet that can magically solve all problems, despite what the community might suggest.
Firstly, iO is not a generic plug-and-play solution. Each use case requires intricate analysis. As Campanelli et al. put it:"In fact, most iO-based constructions are quite involved and they are not generic since only carefully designed programs can be successfully obfuscated through iO." Another key limitation: obfuscated programs cannot maintain a state. This is a critical drawback when compared to hardware-based TEEs. An obfuscated program can be executed on some input and return the output, but it does not have a permanent storage to keep a state over multiple executions.
Possibly the most severe issue though is the setup phase. Every obfuscated program must initially be set up (i.e., obfuscated), which requires trusting the party that performs the obfuscation. This is similar to trusting the manufacturer of a TEE to produce the hardware without any vulnerabilities or backdoors.
A distributed setup process (similar to a KZG ceremony) could reduce the trust in a single party, but it introduces a threshold trust assumption. This raises a valid question: if we’re going to make this assumption anyway, would threshold FHE - which relies on the same threshold trust assumption - be a more viable alternative?
Finally, iO is still inefficient and many constructions depend on cryptographic assumptions that are not well studied yet.
Reasons for Optimism
So, is cryptographic obfuscation doomed? Definitely not!
Despite the challenges, real progress is happening. Efficiency is improving (e.g., see the recent work of Ma et al.), bringing iO closer to real-world usability.
Theoretical foundations are also becoming more robust, as constructions move away from exotic cryptographic assumptions toward more well-founded ones.
We already know that universal VBB is impossible, but we also know that specific programs can be obfuscated via VBB. That opens the door to real, targeted applications.
Cryptographic obfuscation is unlikely to be the solution for all problems in Web3, but it doesn’t mean it won’t play an important role. The key challenge is to overcome the limitations and find practical applications that make sense regarding its inherent constraints.
Dark Pool Decentralized Exchange - A Potential Use Case of VBB-Obfuscated Proxy Re-Encryption
Here’s one promising idea: use VBB-obfuscated proxy re-encryption to build a privacy-preserving decentralized exchange (DEX).
This concept is similar to the one proposed by Hohenberger et al., and showcases how VBB-style obfuscation could provide meaningful privacy guarantees in blockchain contexts. While the construction of Hohenberger et al. does not directly support this use case - since it is not built for FHE and has certain other limitations - we can imagine a similar mechanism applied to a fully homomorphic encryption setting.
Consider a Dark Pool Decentralized Exchange (DEX) where all trades are encrypted using an FHE scheme such that they can be processed while encrypted. That is, the entire DEX logic like order matching and execution runs entirely on encrypted data. This gives strong privacy guarantees.
Eventually, though, users need to access their account balance. This requires decryption, and the decryption requires a trusted party or committee to hold the FHE decryption key, which introduces a trust assumption.
Instead, we could remove this trust assumption by using a VBB-obfuscated proxy re-encryption program. This program would:
- Accept as input an encrypted account balance,
- Verify proof that the user is authorized to view the balance, and
- Re-encrypt the encrypted balance to the user’s public key
As such, only the authorized user can decrypt the final result.
In this setup, instead of having a trusted party or committee store the FHE decryption key, it is embedded in the obfuscated program in such a way that it cannot be extracted.
This example illustrates that, even if a universal VBB is impossible, it could potentially be used to obfuscate specific programs and thereby enable powerful use cases worth exploring further.
The journey continues. Let’s keep exploring.
