Computation Flow

The computation process within the Interfold protocol is decentralized and open, allowing any participant to contribute to each phase of execution. This design ensures transparency and flexibility, enabling different roles to be fulfilled by various actors, including the application server, Compute Providers, or other network participants.

Phase 1: Request

Define the E3 Program: Author your Secure Process using the tooling described in Writing the Secure Process. The Interfold currently ships first-party support for the BFV scheme via fhe.rs (opens in a new tab) and the SAFE library.
Choose a Compute Provider: Your program must align with the execution backend (e.g., RISC Zero (opens in a new tab) for CRISP or a custom FHE coprocessor).
Assemble E3RequestParams:
- threshold: the CiCo size/threshold tuple (m/n) used for decryption security
- inputWindow: a two-element array [start, end] defining when inputs open and close
- e3Program, e3ProgramParams, computeProviderParams, and optional customParams

Submit the Request: Call request with the struct to publish the new computation.

function request(
  E3RequestParams calldata requestParams
) external returns (uint256 e3Id, E3 memory e3);

struct E3RequestParams {
  uint32[2] threshold;
  uint256[2] inputWindow;
  IE3Program e3Program;
  bytes e3ProgramParams;
  bytes computeProviderParams;
  bytes customParams;
}

The contract validates the parameters, transfers the required fee from the requester, creates an E3 record with a random seed derived from block.prevrandao, and delegates committee selection to the CiphernodeRegistry.

You can estimate the fee before submitting by calling getE3Quote:

function getE3Quote(E3RequestParams calldata requestParams) external view returns (uint256 fee);

Phase 2: Node Selection

Each new request to the Interfold contracts initiates a verifiable sortition process to select a Ciphernode Committee (CiCo). The selected Ciphernodes use the E3 Program parameters to determine the appropriate Fully Homomorphic Encryption (FHE) scheme, then generate and publish a shared public encryption key.

Node Selection

Phase 3: Input Window

During this phase, Data Providers — who may include individual users, applications, or institutions — encrypt their data to the CiCo's public key and publish commitments to those inputs onchain.

Data Encryption: Data Providers encrypt their inputs using the CiCo's public key.
Input Validation: Data Providers generate several Zero-Knowledge Proofs about their inputs to ensure they are valid for the requested E3. Some of these proofs are generic (e.g., proof of valid encryption) while others will be specific to your application.
Submit Inputs: Both encrypted data and ZKPs are submitted to your E3 Program contract's publishInput function. The E3 Program validates the input and may add its hash to a Merkle tree, the root of which can later be used to anchor proofs of correct execution of your E3 Program.
```
function publishInput(uint256 e3Id, bytes memory data) external;
```

Phase 4: Execution

In this phase, the Compute Provider (CP) executes the Secure Process defined in your E3 Program and publishes the encrypted output back to Interfold contract. This must happen before the compute deadline expires.

Execution: The CP retrieves encrypted inputs and executes the Secure Process defined in your E3 program.
Publish Output: The ciphertext output and accompanying proof are submitted to the Interfold contract via publishCiphertextOutput. The Interfold contract calls your E3 Program's verify function to validate the proof before accepting the output.
```
function publishCiphertextOutput(
  uint256 e3Id,
  bytes memory ciphertextOutput,
  bytes memory proof
) external returns (bool success);
```

Phase 5: Decryption

After the ciphertext output is published, the CiCo for the given E3 coordinates to decrypt the ciphertext output and publish the resulting plaintext. The decryption must complete before the decryption deadline. The Decryption Verifier contract validates the submitted plaintext proof before accepting the output. The plaintext output can be queried from the Interfold contract's getE3() function.

function getE3(uint256 e3Id) external view returns (E3 memory e3);

or by listening to the PlaintextOutputPublished event.

event PlaintextOutputPublished(uint256 indexed e3Id, bytes plaintextOutput);

Upon successful decryption, rewards are distributed to the active committee members.

Failure Handling

If any phase exceeds its deadline or a fault is detected, the E3 transitions to the Failed stage. Anyone can call markE3Failed(e3Id) to check timeout conditions, or the SlashingManager / CiphernodeRegistry can trigger failure directly.

Once failed, the E3RefundManager calculates a proportional refund based on how much work was completed:

The requester can claim a partial refund via claimRequesterRefund(e3Id)
Honest committee members (non-expelled nodes) can claim compensation via claimHonestNodeReward(e3Id)
A protocol fee is retained for operational costs

Architecture Overview Use Cases