Milestones of Machina iO from Q1 2026 to Q2 2027

# Milestones of Machina iO from Q1 2026 to Q2 2027 As discussed in [our position paper](https://eprint.iacr.org/2025/2139), iO is the only way to build trustless confidential smart contracts, namely ones that do not require any trust beyond the existing Ethereum validators, and it is essential for making confidential smart contracts scalable without sacrificing their security. This document describes our team’s milestones from Q1 2026 through Q2 2027 toward realizing practical iO, as well as the research collaborations we seek. ## Milestones ```graphviz digraph milestones { rankdir=LR; newrank=true; nodesep=1.0; // increases the separation between nodes node [color=Black, fontname=Courier, shape=box]; // All nodes will have this shape and colour edge [color=Blue, style=dashed]; // All the lines look like this // ---- Node definitions (IDs + labels) ---- bgg_mul [label="Milestone 1:\nFHE Multiplication over\nKey-Homomorphic Encodings\n(Q1 2026)"] nr_dummy_prf [label="Milestone 2:\nNoise Refreshing\nwith Dummy PRF\n(Q2 2026)"]; blind_prf [label="Milestone 3:\nBlind PRF over\nKey-Homomorphic Encodings\n(Q2 2026 - Q3 2026)"]; obf_nontriv [label="Milestone 4:\nObfuscation with\nNontrivial Input Size\n(Q3 2026)"]; snark_ver [label="Milestone 5:\nSNARK Verification over\nKey-Homomorphic Encodings\n(Q4 2026 - Q1 2027)"]; // blind_snark [label="Blind SNARK i.e.,\nSNARK inside FHE\n(Q1 2026)"]; we_2027q1 [label="Milestone 6:\nWitness Encryption\n(Q1 2027 - Q2 2027)"]; obf_cond_fhe [label="Obfuscation for\nConditional FHE Decryption"]; // snark_rec [label="Blind SNARK recursion\n(Q2 2026 - Q3 2026)"]; verify_fhe [label="Verifiable FHE"] // ---- Clusters ---- subgraph cluster_input_scaling { label = "Input Scaling"; style = rounded; color = blue; bgg_mul; nr_dummy_prf; blind_prf; } // subgraph cluster_snark { // label = "Blind SNARK"; // style = rounded; // color = gray; // snark_ver; // blind_snark; // snark_rec; // } subgraph cluster_products { label = "Products"; style = rounded; color = red; obf_nontriv; we_2027q1; } subgraph cluster_out { label = "Outside of Milestones" style = rounded; color = gray; verify_fhe; obf_cond_fhe; } // ---- Edges ---- bgg_mul -> blind_prf; nr_dummy_prf -> obf_nontriv; blind_prf -> obf_nontriv; obf_nontriv -> we_2027q1; we_2027q1 -> obf_cond_fhe; snark_ver -> we_2027q1; verify_fhe -> obf_cond_fhe; // blind_snark -> snark_rec; // snark_rec -> obf_cond_fhe; // ---- Ranks ---- // { // rank = same; // nr_dummy_prf; // } // { // rank = same; // blind_prf; // } // { // rank = same; // obf_nontriv; // snark_ver; // } } ``` ### Milestone 1: FHE Multiplication over Key-Homomorphic Encodings We implement a circuit evaluated over key-homomorphic encodings that simulates FHE multiplication. The implemented scheme can choose arbitrary lattice-based FHE schemes. We first demonstrate the usefulness of the circuit by implementing predicate encryption or laconic functional evaluation (LFE), which are weaker primitives than iO but have not been implemented over 10 years. **Connection to subsequent milestones**: We expect that this circuit implementation will serve as a foundation for the Milestone 3 implementation. Specifically, if the PRF can be expressed as a polynomial in the PRF key, then the blind PRF computation described below could be realized by repeatedly performing FHE multiplications (and additions) over the key-homomorphic encoding. **Timeline**: Q1 2026 **Implementation**: An implementation of FHE multiplication over key-homomorphic encodings. **Dissemination**: We will publish a paper that demonstrate the first implementation of predicate encryption (or LFE), along with new techniques that enables the efficient simulation of FHE multiplication over key-homomorphic encodings. The paper could be submitted to [ACM CCS 2026](https://www.sigsac.org/ccs/CCS2026/call-for/call-for-papers.html). ### Milestone 2: Noise Refreshing with Dummy PRF We implement noise refreshing of GGH15 encodings, described in Subsection 4.2 of the position paper, with using a dummy implementation for a blind PRF over key-homomorphic encodings (described below). This milestone has the following two purposes. 1. We will confirm that, assuming the blind PRF over key-homomorphic encodings, the idea of noise refreshing actually works in practice. In more detail, we need to make sure that **parameters (especially the bit size of the modulus $q$) grow only polylogarithmically in the input size**. 2. By evaluating the performance of noise refreshing with varying the circuit size and depth of a dummy implementation of the blind PRF over key-homomorphic encodings, **we will determine concrete numerical targets for how small the circuit size and depth of the blind PRF must be so that we can support the obfuscation of circuits with sufficiently large input size within a practical running time**. **Timeline**: Q2 2026 **Implementation**: An implementation of noise refreshing with a dummy implementation of blind PRF. The design of the implementation should be modular so that the blind PRF implementation can be easily replaced later. **Dissemination**: We will publish a paper that formally describes the construction of noise refreshing and its security proof.   ### Milestone 3: Blind PRF over Key-Homomorphic Encodings We implement a circuit evaluated over key-homomorphic encodings that simulates PRF without revealing a PRF key and a PRF output, called blind PRF over key-homomorphic encodings. The implemented scheme should be useful for the noise refreshing and be proven secure under well-defined (but probably nonstandard) cryptographic assumptions. **Timeline**: Q2 2026 - Q3 2026 **Implementation**: An implementation of the blind PRF circuit, of which a more detailed spec is explained in page 20 of [the position paper](https://eprint.iacr.org/2025/2139.pdf). **Dissemination**: No paper for this milestone because its result is introduced in a paper for Milestone 4.   ### Milestone 4: Obfuscation with Nontrivial Input Size We realize an obfuscation of a circuit with at least 64 input bits. This obfuscated circuit itself is not directly useful. However, it represents an important scientific milestone; when the number of input bits is small, one can build an obfuscated circuit using a simple lookup table, whereas once the input size reaches 64 bits or more, constructing such a lookup table becomes practically impossible. As long as all input bits are meaningfully used, we do not impose any particular requirement on the functionality of the circuit. **Connection to prior milestones**: This milestone will be achieved by replacing the dummy implementation of the blind PRF in the implementation developed in Milestone 2 with the implementation developed in Milestone 3. **Connection to subsequent milestones**: Real applications including witness encryption in Milestone 6 will require more than 64 input bits. However, since the noise refreshing makes parameters (especially the bit size of the modulus $q$) grow only polylogarithmically in the input size, we can support input sizes larger than 64 bits simply by allowing the running time to grow linearly. Alternatively, by parallelizing, e.g., using GPUs or performing input insertion in a tree structure rather than sequentially, it could be handled with a sublinear growth of the running time. Therefore, as long as noise refreshing is available, **increasing the supported input size is an engineering and computational-resources problem rather than a theoretical one**. **Timeline**: Q3 2026 **Implementation**: An implementation to produce and evaluate the obfuscated circuits with at least 64 input bits. **Dissemination**: We will publish a paper to claim that we are the first to realize iO with practical performance for nontrivial input sizes. This paper can be submitted to conferences whose submission deadlines are in October or November 2026, e.g., Eurocrypto or IEEE S&P. We will also present this result at Devcon 2026. ### Milestone 5: SNARK Verification over Key-Homomorphic Encodings We implement a circuit evaluated over key-homomorphic encodings that simulates a verification algorithm of a SNARK scheme. This milestone includes selecting, or if necessary newly designing, a SNARK scheme whose proofs can be easily verified over the encoding. There is an efficiency trade-off between public-verifier (PV) and designated-verifier (DV) SNARK schemes. While a proof of a PV scheme is publicly verifiable, a proof verification of a DV scheme requires a private verifying key. The latter scheme is acceptable for iO because this key can be hardcoded into obfuscated circuits; however, the scheme must guarantee strong reusability of the verifying key. From the viewpoint of efficiency, a DV scheme has a smaller proof size and lower verification complexity than a PV scheme, but it requires simulating the process over BGG+ encodings that executing the verification algorithm homomorphically using FHE, whereas the verification algorithm of a PV scheme can be simulated over the encodings without FHE. Therefore, the choice in this trade-off will mainly depend on the magnitude of the overhead incurred by simulating FHE over the encodings. To the best of our knowledge, [[ADY25]](https://eprint.iacr.org/2025/2160.pdf) achieves the shortest proof size, in particular 768 bits, among PV SNARK schemes. In contrast, although the DV SNARK scheme in [[ADI25]](https://eprint.iacr.org/2025/517.pdf) enables a shorter proof size than that of [ADY25], it does not guarantee the strong reusability. The DV scheme in [[BIOW20]](https://eprint.iacr.org/2020/1319.pdf) guarantees the strong reusability, but it relies on the Paillier encryption scheme for a negligible soundness error, incuring a proof size larger than 1000 bits. **Timeline**: Q4 2026 - Q1 2027 **Implementation**: An implementation of the SNARK verification circuit, along with that of the corresponding SNARK prover. **Dissemination**: No paper for this milestone because its result is introduced in a paper for Milestone 6. ### Milestone 6: Witness Encryption We realize witness encryption (WE) as an obfuscation that on input a SNARK proof outputs a hardcoded message if and only if the proof is valid. Although WE is weaker than iO, it already provides amazing applications as follows: - [Trsutless bitcoin bridge](https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953) - Trustless encrypted mempool for protection against MEV attacks - [Trustless one-time programs](https://eprint.iacr.org/2017/935.pdf) - [Trustless time-lock encryption](https://eprint.iacr.org/2015/482) **Connection to prior milestones**: There are two challenges to overcome in order to achieve this milestone. 1. The input size needs to be large enough to cover the size of the SNARK proof. For example, the proof size in [[ADY25]](https://eprint.iacr.org/2025/2160.pdf) is 768 bits at a 128-bit security level. 2. A circuit evaluated over key-homomorphic encodings needs to verify the provided SNARK proof. The first and second challenges are addressed by Milestones 4 and 5, respectively. Therefore, we can realize WE by essentially combining these results. **Timeline**: Q1 2027 - Q2 2027 **Implementation**: Implementations of witness encryption and its demoe application. **Dissemination**: We will publish a paper to claim that we are the first to realize WE with practical performance for general NP problems.  The following is outside the scope of the milestones planned through Q2 2027, but we describe how the iO construction could be further developed in the future for reference. ## Out of scope in this roadmap ### Verifiable FHE This produces a SNARK proof that FHE computation is honestly performed. ### Obfuscation for Conditional FHE Decryption This obfuscates a circuit that on input an FHE encryption of some message and a SNARK proof, outputs the decrypted message if and only if the decrypted proof is valid. The input proof is assumed to be that of verifiable FHE. ## Collaborative research We would like to collaborate with academic researchers on security analysis and efficiency improvements.  The scope of the security analysis is as follows: - Cryptanalysis of the all-product (Ring-)LWE assumption - Cryptanalysis of the private-coin evasive LWE assumption with specific parameter ranges and samplers used in [Diamond iO](https://eprint.iacr.org/2025/236) - Cryptanalysis of new assumptions that might be introduced to improve efficiency of key-homomorphic encodings A paper on these cryptanalyses are expected to be published before Devcon 2026.