The encrypted computer — a machine that runs encrypted programs on encrypted inputs and reveals only the encrypted output, with cryptographic guarantee that no internal state can be inspected — is the long-term endgame of privacy-preserving computation. Progress between ETHPrague 2025 and ETHPrague 2026 (one year) was substantial enough to shift the consensus path: direct program obfuscation is becoming preferred over FHE+threshold-committee, and the local-mixing approach has reached a credible challenge-release state. The work cluster is led by Phantom Zone / Ox Labs (Janmajaya Mall) and Machina (Ethereum Foundation).
Key Ideas
Definition
An encrypted computer is a black-box machine that:
- Takes encrypted inputs and encrypted programs.
- Executes the program.
- Produces output that can be encrypted or selectively decrypted.
- Cryptographically guarantees no party — including the operator — can inspect any internal state during execution.
This is fundamentally different from ZK proofs (which prove correctness but require knowing inputs) and from TEEs (which trust hardware vendors). The encrypted computer trusts only math.
The Phantom journey: FHE as one path
Phantom is a RISC-V virtual machine built using FHE circuits. The 2025 announcement at ETHPrague projected ~2 cycles per second (immensely slow). The 2026 update: implementation finalized late 2025, now running at ~600ms per cycle on a 32-core CPU, with expected 100–150× improvement on GPU (not yet implemented). zkVM-class throughput is now in sight.
The catch: FHE always requires someone to hold the decryption key. The best practical answer is a threshold decryption committee — multiple parties hold key shares, decryption requires a quorum.
Why threshold committees aren’t acceptable
Mall’s argument against the threshold-committee pattern (echoing positions from ECC2 and the d/acc track):
- Bootstrapping is intractable. People have tried for ~5 years to make secure threshold systems work on blockchain. Mall’s position: not achievable in practice.
- Collusion is undetectable. If committee members secretly collude and leak the shared key, you cannot detect this from the outside. The privacy is silently broken.
- Closed gated systems are not decentralized. Threshold committees that work well in practice tend to be permissioned — which defeats the purpose.
This led the research group to deprioritize the FHE-plus-conditional-decryptor approach Mall presented at ETHPrague 2025, and pivot to direct obfuscation.
Obfuscation as the alternative
A program obfuscator takes a program P and produces an obfuscated circuit C, with the cryptographic guarantee that anyone observing C learns nothing about P beyond input-output behavior. Obfuscation is theoretically harder than FHE (longer-standing open problem, fewer breakthroughs) but a single primitive — no committees needed.
If you can obfuscate a program containing a secret signing key, you’ve effectively created a smart contract that can sign on your behalf based on conditions, without the smart contract leaking the key. This is the killer application.
Local mixing as the practical approach
Mall’s 2026 update: substantial progress on the local-mixing approach to obfuscation. Not yet provably secure but increasingly resistant to attacks.
The recipe:
- Shift to reversible circuits. Boolean circuits lose information (AND gate destroys input). Reversible circuits preserve all bits — you can always recover the input from the output. This is the computational model used.
- Pre-processing for high algebraic degree. XOR wires together randomly to raise the polynomial degree of each wire (defends against differential analysis).
- Gadgets that reverse the XOR-induced functionality changes.
- Iterative shuffle / shoot / lock / compress loop (3–4 rounds):
- Shuffle wires and gates while preserving functionality.
- Shoot each gate as far as the circuit dependencies allow.
- Lock gate pairs by replacing them with large identity circuits (introduces irreducible redundancy).
- Compress the result to remove the most easily-detected redundancy.
The result: a circuit that is ~100–2000× larger than the original (vs. FHE’s billion×) and resistant to heat-map analysis (correlation between obfuscated and original circuit computation no longer visible).
The challenge release
In mid-May 2026 (timing immediately after ETHPrague), the group releases a public collection of obfuscated circuits as a challenge — break them to disprove the approach. This is the field-test for the local-mixing thesis. If unbroken for ~12 months, the practical path to obfuscation is open.
Machina’s Diamond IO
Parallel work by the Machina team (Ethereum Foundation): an exact implementation of Diamond IO, an obfuscation scheme built from secure cryptographic primitives (lattices) rather than from heuristic mixing. Currently has practical lattice parameters but astronomical execution times (years for non-trivial programs). The key innovation: key homomorphic encoding — a step toward making lattice-based obfuscation usable.
Diamond IO is the conservative path; local mixing is the speculative path. Both are pursued in parallel.
Confidential Compute applied to AI
Daniel Bar’s ETHPrague talk (Confidential Compute for Orbital AI) extends FHE/TEE confidential-compute to AI workloads running in space-based infrastructure. The motivation: AI model weights are valuable IP, and inference inputs are sensitive. Running models inside TEEs (or, longer-term, FHE) lets a cloud operator serve model inference without seeing inputs, prompts, or even the model weights. The orbital deployment removes one more attack surface (physical access).
How Confidential UX Unlocks Markets You Can’t Touch Today
Kate Stapleton’s ETHPrague talk operationalizes encrypted-compute-as-product: insurance use cases, regulated healthcare data, salary benchmarking, dark-pool trading. The thesis: many trillion-dollar markets are legally impossible to address today because the data cannot be aggregated. Encrypted compute lets a single entity provide statistics, scoring, and matching over data that no party can read.
Details / Subtopics
Why obfuscation is harder than FHE (and why it’s still worth it)
FHE lets you compute on encrypted data but you still need a key to decrypt. Obfuscation lets you publish a program that runs on plaintext but reveals no secrets. The asymmetry: with FHE, you can trust nobody and lose key custody; with obfuscation, you can trust nobody including the program operator. For applications like “a smart contract holds a real key and signs transactions under conditions,” obfuscation is required, not optional.
The heat map test
Mall’s intuitive measure of obfuscation strength: plot original-circuit-computation vs. obfuscated-circuit-computation on a scatter plot. If you see a clean diagonal line, the obfuscation has done nothing. If you see a hazy line, partial obfuscation. If you see no correlation, the obfuscation has succeeded against this analysis class. The 2025 version showed a hazy line; 2026 versions show no visible correlation. (This does not prove obfuscation against more sophisticated attacks — hence the challenge release.)
The asks of attackers
For the May 2026 challenge: break by recovering anything about the underlying program, even functional equivalence with a smaller circuit. Heat-map analysis, differential cryptanalysis, gadget-pattern detection — all valid. If the challenge survives ~12 months of public attack, the field has its first practical obfuscation candidate.
Janmajaya Mall’s broader thesis
The path from FHE → local-mixing is also an architectural pivot: lift as much compute as possible into the more-practical primitive (FHE), and limit the harder primitive (obfuscation) to a small surface (a conditional decryptor). The 2026 update reverses this: it turns out direct obfuscation may be cheap enough that the FHE intermediary is not needed.
Adjacent tools
- Aztec — General-purpose ZK compute, production-ready, narrower threat model (proofs of computation, not secrecy of programs).
- Fhenix — Production FHE smart contract platform from ECC2 / EthCC9 era.
- Cysic / Mind Network — Hardware-accelerated FHE.
- Inco — FHE-enabled Ethereum L2.
Threshold FHE breakthroughs (Devconnect Argentina, d/acc track)
A 1000× threshold FHE decryption speedup was reported at Devconnect — relevant for the FHE side of this work. Even Mall’s pivot doesn’t kill FHE; it just demotes threshold-committee FHE from primary architecture to one tool among several.
Connections
- ZK Proving Infrastructure — Adjacent cryptographic infrastructure; ZK proves correctness, obfuscation hides programs, FHE computes encrypted.
- Privacy as UX Design — Privacy Pools v2 uses ZK; the next-gen tools using FHE/obfuscation will extend the privacy-UX layer to features impossible with ZK alone (private contract state, not just private transactions).
- Orbital Compute & Space Infrastructure — Confidential Compute for Orbital AI cross-references this work.
- ETHPrague 2026 — Overview — Mall’s update is the most consequential cryptography talk of the conference.
- Decentralisation Accelerationism (d/acc) — Threshold-FHE breakthrough on the d/acc side.
Open Questions
- Will the May 2026 obfuscation challenge survive? If broken in months, local mixing remains a research curiosity. If it survives 12+ months, this is the most important cryptography milestone of the cycle.
- Diamond IO with key-homomorphic encoding is conservative path: when does it become practical (i.e., minutes, not years, per execution)? Public estimates: 3–7 years, but cryptography milestones often arrive unexpectedly.
- Threshold FHE: the 1000× speedup is real, but does it eliminate the bootstrap and collusion-detection problems Mall is concerned about? Open.
- What is the killer application that justifies the obfuscation blow-up cost? Smart-contract-holding-a-key signing is the canonical one; private DAO voting and private prediction markets are next.