From 68ae232a9814bedf55d7f6052b3e814b22838da4 Mon Sep 17 00:00:00 2001 From: Sisyphus Date: Tue, 21 Jul 2026 02:43:22 +0000 Subject: [PATCH] feat: add Interfold vendor profile, verifiable DKG, and ephemeral committees patterns --- patterns/pattern-ephemeral-committees.md | 110 +++++++++++++++++ ...ern-verifiable-dkg-threshold-decryption.md | 113 ++++++++++++++++++ vendors/interfold.md | 104 ++++++++++++++++ 3 files changed, 327 insertions(+) create mode 100644 patterns/pattern-ephemeral-committees.md create mode 100644 patterns/pattern-verifiable-dkg-threshold-decryption.md create mode 100644 vendors/interfold.md diff --git a/patterns/pattern-ephemeral-committees.md b/patterns/pattern-ephemeral-committees.md new file mode 100644 index 0000000..d29ddf3 --- /dev/null +++ b/patterns/pattern-ephemeral-committees.md @@ -0,0 +1,110 @@ +--- +title: "Pattern: Ephemeral Committees & Disposable Encrypted State" +status: draft +maturity: testnet +type: standard +layer: offchain +last_reviewed: 2026-07-21 + +works-best-when: + - Encrypted state must become permanently inaccessible after a defined window, without relying on storage deletion or operational hygiene. + - Each computation should be isolated from others — key material from one execution must not compromise another. + - The data disposal guarantee must combine cryptographic and procedural mechanisms — key destruction renders ciphertexts undecryptable, but honest disposal by node operators is required since no cryptographic protocol can force data deletion. +avoid-when: + - Persistent encrypted state is needed across multiple computations or time periods — use long-lived key management instead. + - The committee cannot be trusted to discard keys (the guarantee depends on honest disposal). + - Recovery or rollback of encrypted state after the committee window closes is a hard requirement. + +context: both +context_differentiation: + i2i: "Between institutions, disposable state means no long-term key custody liability for either party. After the committee disbands, neither side can be compelled to decrypt historical data because the key material no longer exists anywhere." + i2u: "For end users, the guarantee that their encrypted inputs will become permanently inaccessible after the computation protects against future data breaches or compelled disclosure. The guarantee is only as strong as the honest-majority key disposal assumption." + +crops_profile: + cr: high + o: yes + p: full + s: high + +crops_context: + cr: "No single operator can prevent key disposal or retain key material — but the CROPS guarantee relies on honest-majority disposal. If a majority retains keys, undecrypted state remains potentially accessible." + o: "Protocol logic and lifecycle enforcement are open source and verifiable on-chain. Key disposal is an off-chain action by operators and cannot be cryptographically proven — it relies on economic incentives and reputation." + p: "Privacy reaches `full` after the committee disbands: encrypted state becomes information-theoretically inaccessible if keys are truly discarded. During the active window, privacy is `partial` — a threshold of nodes could collude to decrypt." + s: "Security during the active window depends on the k-of-n threshold. After disposal, security depends on honest key destruction — an assumption that cannot be cryptographically verified, only economically incentivized." + +post_quantum: + risk: medium + vector: "Encrypted state collected during the active window has HNDL exposure if the underlying encryption is not post-quantum. State after key disposal is information-theoretically lost regardless of quantum capability, assuming honest disposal." + mitigation: "Combine with post-quantum encryption schemes. The disposal guarantee itself is not quantum-dependent." + +standards: [] + +related_patterns: + requires: [pattern-verifiable-dkg-threshold-decryption] + composes_with: [pattern-pretrade-privacy-encryption] + alternative_to: [pattern-tee-key-manager] + see_also: [pattern-forward-secure-signatures] + +open_source_implementations: + - url: https://github.com/theinterfold/interfold + description: "The Interfold protocol: E3 lifecycle with ephemeral committee key generation and mandatory disposal" + language: "Rust, Noir, Solidity" +--- + +## Intent + +Bound the accessibility of encrypted state to the lifetime of a specific committee, then render all undecrypted state permanently inaccessible by having honest committee members discard their key material as toxic waste after their duties complete. This provides cryptographic data disposal without relying on storage deletion, operational hygiene, or trusted custodians — once the keys are gone, the state is gone. + +This pattern is the foundation for systems where encrypted inputs must leave no decryptable trace after the computation finishes: sealed-bid auctions where losing bids should become permanently unreadable, secret ballots where individual votes must be destroyed after tallying, or cross-institutional data analysis where raw inputs must not persist in decryptable form. + +## Components + +- **Ephemeral committee**: A group of nodes selected for a single computation (one E3, one auction, one ballot). The committee exists only for the duration of that computation. +- **Single-use key material**: The DKG produces a public key used exclusively for one computation. After decryption, the corresponding private key shares serve no further purpose. +- **Key disposal (toxic waste) protocol**: After the output is decrypted and published, honest committee members securely delete their key shares. The act is off-chain and cannot be cryptographically proven, so it is reinforced by economic incentives (slashing for any provable future use of the key material). +- **Timeout-enforced lifecycle**: The coordinating contract enforces strict deadlines (committee formation, DKG, input window, compute, decryption). If any phase times out, the E3 fails and keys should still be discarded. If compute never finishes, encrypted inputs become permanently inaccessible. +- **Slashing for intermediate decryption**: Attempting to decrypt anything other than the agreed-upon output (inputs, intermediate state, or outputs from other computations) is slashable. Combined with key disposal, this creates both ex-ante (economic) and ex-post (key destruction) barriers to unauthorized decryption. + +## Protocol + +1. [operator] A committee is formed for a specific computation request (via sortition or explicit selection). +2. [operator] The committee runs DKG to produce a shared public key. Each member holds a private key share valid only for this committee. +3. [user] Data providers encrypt inputs to the committee public key during the input window. No other committee's key can decrypt these inputs. +4. [operator] The compute provider executes the program over encrypted inputs and publishes the ciphertext output. +5. [operator] The committee performs threshold decryption of the output and publishes the plaintext result. +6. [operator] Honest committee members securely delete (overwrite, shred) their private key shares. These shares are now toxic waste — retaining them is a liability, not an asset. +7. [contract] The E3 lifecycle completes. Any encrypted state that was not decrypted during the active window (inputs from non-winning bidders, intermediate ciphertexts, abandoned computations) is now permanently inaccessible — the keys to decrypt it no longer exist. + +## Guarantees & threat model + +Guarantees: + +- **Time-bounded decryption window**: encrypted state is only accessible while a threshold of committee members possess their key shares. After the window closes and keys are discarded, decryption becomes impossible under the honest-majority assumption. +- **Cryptographic data disposal**: undecrypted state becomes permanently inaccessible without requiring storage deletion. Even if ciphertexts are retained indefinitely, they cannot be decrypted once the keys are gone. +- **Isolation across computations**: each committee uses fresh key material, so compromise of one committee's keys does not expose state from any other computation. +- **Economic backstop**: slashing conditions for intermediate decryption and key retention create a cost for misbehavior that complements the cryptographic disposal guarantee. + +Threat model: + +- **Key retention**: if a threshold of committee members retains their key shares instead of discarding them, undecrypted state remains accessible. This cannot be cryptographically prevented — it relies on honest behavior, economic incentives, and the fact that retained keys are a liability (provable use triggers slashing). +- **Key exfiltration before disposal**: if an attacker compromises a threshold of nodes during the active window and exfiltrates their key shares before disposal, the state remains accessible to the attacker regardless of subsequent disposal. +- **Liveness during active window**: if the committee fails before decryption (timeout, insufficient online members), encrypted state may become permanently inaccessible — which is the desired guarantee for privacy, but a failure mode for the computation's utility. +- **Disposal verification gap**: unlike DKG and decryption (which produce on-chain verifiable proofs), key disposal is an off-chain action with no cryptographic proof. The guarantee rests on incentives, not verification. + +## Trade-offs + +- **No recovery**: once the committee disbands and keys are discarded, undecrypted state is irrecoverable. This is the intended guarantee, but it means there is no "undo" for failed computations or accidental early disposal. +- **Honest-majority disposal assumption**: the cryptographic disposal guarantee is only as strong as the honest-majority key destruction commitment. Retained key shares (maliciously or accidentally) undermine the guarantee. +- **Fresh DKG per computation**: generating new key material for every computation adds latency and on-chain verification cost compared to long-lived keys. +- **Liveness risk**: if the committee fails to reach threshold during decryption, the output is lost. Timeout mechanisms and refund logic in the coordinating contract mitigate economic harm but cannot recover the lost output. +- **Key destruction hygiene**: secure deletion in practice (memory overwrite, hardware security module zeroization, filesystem shredding) is operationally non-trivial and varies across deployment environments. + +## Example + +A sealed-bid auction uses an ephemeral committee of 5 nodes with threshold 3 for decryption. The committee generates a fresh public key used only for this auction. Bidders encrypt their bids; the compute provider determines the winner over encrypted bids and publishes the ciphertext result; the committee decrypts the winning price and publishes it. After decryption, all 5 nodes securely delete their key shares. The losing bids — still encrypted on-chain — are now permanently inaccessible: no key material exists anywhere that can decrypt them. Even if the auction contract's storage is preserved for years, the losing bids can never be revealed. + +## See also + +- [The Interfold — E3 Lifecycle](https://docs.theinterfold.com/computation-flow) +- [The Interfold — Exits, Rewards & Slashing](https://docs.theinterfold.com/ciphernode-operators/exits-and-slashing) +- [Forward Secure Signatures pattern](../patterns/pattern-forward-secure-signatures.md) — related concept: keys that lose utility over time diff --git a/patterns/pattern-verifiable-dkg-threshold-decryption.md b/patterns/pattern-verifiable-dkg-threshold-decryption.md new file mode 100644 index 0000000..a3202f8 --- /dev/null +++ b/patterns/pattern-verifiable-dkg-threshold-decryption.md @@ -0,0 +1,113 @@ +--- +title: "Pattern: Publicly Verifiable DKG & Threshold Decryption" +status: draft +maturity: testnet +type: standard +layer: offchain +last_reviewed: 2026-07-21 + +works-best-when: + - Decryption authority must be distributed across independent operators so no single party can unilaterally expose private inputs. + - Every cryptographic operation (key generation, share publication, decryption) must be publicly verifiable on-chain. + - Misbehavior by committee members must be cryptographically detectable and provable for slashing or dispute resolution. +avoid-when: + - A single trusted key holder is acceptable — use simpler asymmetric encryption. + - On-chain verification cost (gas) is prohibitive for the target deployment. + - The committee is small and fully trusted; PVSS and on-chain verification add complexity without proportional benefit. + +context: both +context_differentiation: + i2i: "Institutions gain auditable proof that no single operator could have decrypted inputs or outputs prematurely. On-chain verification artefacts serve as compliance records and shared evidence in bilateral disputes." + i2u: "End users are protected by the same k-of-n threshold as institutions: no single node can decrypt their input, and any attempt is provable on-chain. The guarantee degrades to that of a single trusted key holder if the operator set is captured." + +crops_profile: + cr: high + o: yes + p: full + s: high + +crops_context: + cr: "No single operator holds sufficient key material to decrypt; censorship requires coordinated action across a threshold of independent nodes. Verifiable proofs on-chain make censorship attempts detectable." + o: "Reference implementations and circuit source are open source; verification contracts are deployed on public networks. Node participation criteria vary by protocol." + p: "Inputs remain encrypted unless a threshold of nodes colludes to decrypt. PVSS ensures share publication is verifiable, and on-chain decryption proofs make any premature decryption publicly detectable." + s: "Security relies on the k-of-n honest-committee assumption, correct implementation of the DKG and PVSS protocols, and soundness of the underlying ZK circuits. A compromised threshold of nodes can decrypt; economic slashing and governance backstops are the residual mitigations." + +post_quantum: + risk: low + vector: "The PVSS scheme is lattice-based and quantum-safe. The proving layer (Noir/Barretenberg/UltraHonk) uses pairing-based cryptography and would need migration to a quantum-safe proving system; this is expected well before any quantum threat materializes." + mitigation: "Migrate the proving layer to a quantum-safe proof system when available. Encrypted state itself is not vulnerable." + +standards: [] + +related_patterns: + composes_with: [pattern-threshold-encrypted-mempool, pattern-pretrade-privacy-encryption] + alternative_to: [pattern-tee-key-manager] + see_also: [pattern-ephemeral-committees] + +open_source_implementations: + - url: https://github.com/theinterfold/interfold + description: "The Interfold protocol: threshold BFV, PV-TBFV, DKG and decryption aggregator circuits" + language: "Rust, Noir, Solidity" + - url: https://github.com/shutter-network/shutter + description: "Shutter threshold-encryption toolkit with on-chain keyper verification" + language: "Rust, Go" +--- + +## Intent + +Distribute decryption authority across a committee of independent nodes such that no single party can unilaterally decrypt encrypted state, and every cryptographic operation — key generation, share publication, and decryption — produces an on-chain verifiable proof. Misbehavior (invalid shares, premature decryption, refusal to decrypt) is cryptographically detectable and provable for slashing or dispute resolution. + +This pattern generalises the distributed key generation and threshold decryption layer used in threshold-encrypted mempools and encrypted execution environments. It differs from basic threshold encryption by making every step publicly verifiable via zero-knowledge proofs, eliminating the need to trust the committee's honesty — you can prove when they misbehave. + +## Components + +- **Publicly Verifiable Secret Sharing (PVSS)**: Each committee member publishes an encrypted key share along with a ZK proof that the share is correctly formed, so any observer can verify share validity without trusting the publisher. +- **Distributed Key Generation (DKG) protocol**: Committee members jointly produce a shared public key through rounds of PVSS exchanges. No party ever holds the full private key. +- **On-chain DKG verifier**: A smart contract or verifier contract that validates the aggregated DKG proof (e.g., a Noir circuit verifying that the published public key was correctly derived from valid PVSS shares). +- **Threshold decryption aggregator**: Collects decryption shares from committee members (each with a per-share ZK proof of correctness), aggregates them into the plaintext result once the threshold is met, and submits the aggregated proof on-chain. +- **On-chain decryption verifier**: Validates the aggregated decryption proof, confirming that a threshold of valid shares was used to produce the claimed plaintext. +- **Slashing / dispute mechanism**: Economic penalties triggered by on-chain proof of misbehavior (invalid shares during DKG, invalid decryption shares, provable premature decryption). + +## Protocol + +1. [operator] Committee members are selected (via sortition, governance, or explicit delegation). +2. [operator] Each member generates a PVSS share and publishes it with a ZK proof of correctness. Shares are aggregated into the committee public key. +3. [contract] The DKG verifier validates the aggregated proof on-chain and records the published public key. +4. [user] Data providers encrypt inputs to the committee public key and submit ciphertexts with proofs of valid encryption. +5. [operator] Computation runs over encrypted inputs; a ciphertext output is produced and published. +6. [operator] Each committee member produces a decryption share with a per-share ZK proof; shares are aggregated once the threshold is met. +7. [contract] The decryption verifier validates the aggregated proof on-chain and publishes the plaintext output. Any invalid or missing shares are cryptographically identifiable for slashing. + +## Guarantees & threat model + +Guarantees: + +- **No single point of decryption**: fewer than k committee members cannot decrypt, even if the rest collude. +- **Public verifiability**: every share (DKG and decryption) carries a ZK proof; invalid shares are detectable by any observer without trusting the publisher. +- **Provable misbehavior**: premature decryption, invalid shares, or refusal to decrypt leave on-chain evidence suitable for slashing or dispute resolution. +- **Auditability**: the full chain of cryptographic operations — from DKG to decryption — is anchored on-chain and independently verifiable. + +Threat model: + +- **Honest-threshold assumption**: if k or more members collude, they can decrypt. Economic penalties and diverse operator selection raise the cost of collusion but do not remove the assumption. +- **Liveness**: if fewer than k members are online, decryption stalls. Timeouts with refund or failure fallbacks are required. +- **ZK circuit soundness**: a bug in the DKG or decryption verifier circuits could allow invalid shares to pass verification. Formal verification and audits are the primary mitigations. +- **Metadata leakage**: transaction volume, timing, and committee membership are observable on-chain regardless of encryption. + +## Trade-offs + +- **On-chain verification cost**: every DKG and decryption round incurs gas for proof verification. Circuit optimisation and proof aggregation (e.g., folding schemes) reduce but do not eliminate this cost. +- **Coordination latency**: DKG requires multiple rounds of PVSS exchange across committee members, adding latency before the input window can open. +- **Committee management overhead**: operator registration, sortition, bond management, and exit queues add protocol complexity beyond the cryptographic layer. +- **Failure modes**: DKG timeout, insufficient committee members, invalid shares detected mid-protocol — all require fallback states and refund logic in the coordinating contract. +- **Post-quantum**: the encryption layer (PVSS) is lattice-based and quantum-safe. Only the proving layer (Noir/Barretenberg/UltraHonk) relies on pairing-based cryptography and would need migration to a quantum-safe proof system; this is expected well before any quantum threat materializes. + +## Example + +A sealed-bid auction protocol requests a committee of 5 nodes with a threshold of 3 for decryption. The nodes run PVSS-based DKG and publish their shares on-chain; the DKG verifier contract confirms correctness. Bidders encrypt their bids to the published public key and submit them during the input window. After the auction logic runs over encrypted bids (via FHE or zkVM), each node produces a decryption share of the output with a per-share ZK proof. Once 3 valid shares are aggregated, the decryption verifier confirms the result and publishes the winning price on-chain. A node that submitted an invalid share during DKG or decryption is provably at fault and slashed. + +## See also + +- [The Interfold Documentation — Cryptography](https://docs.theinterfold.com/cryptography) +- [Shutter Network — Threshold Encryption](https://docs.shutter.network/) +- [PVSS: Publicly Verifiable Secret Sharing (Stadler, 1996)](https://link.springer.com/chapter/10.1007/3-540-68697-5_15) diff --git a/vendors/interfold.md b/vendors/interfold.md new file mode 100644 index 0000000..36e94bb --- /dev/null +++ b/vendors/interfold.md @@ -0,0 +1,104 @@ +--- +title: "Vendor: The Interfold" +status: draft +maturity: testnet +--- + +# The Interfold – Distributed Network for Confidential Coordination (E3 Protocol) + +## What it is + +The Interfold is an open-source protocol that coordinates **Encrypted Execution Environments (E3s)** through a distributed network of ciphernodes. It enables independent parties to compute over encrypted inputs and produce shared, verifiable outcomes without concentrating custody, visibility, or execution authority in a single operator. The protocol integrates Fully Homomorphic Encryption (FHE), Zero-Knowledge Proofs (ZKPs), and Distributed Threshold Cryptography (DTC), along with blockchain-based protocol economics, to ensure correctness and confidentiality throughout execution. + +## Fits with patterns + +- [Publicly Verifiable DKG & Threshold Decryption](../patterns/pattern-verifiable-dkg-threshold-decryption.md) — core cryptographic layer: PVSS-based DKG with on-chain verifier circuits, threshold decryption with per-share ZK proofs, and slashing for provable misbehavior +- [Ephemeral Committees & Disposable Encrypted State](../patterns/pattern-ephemeral-committees.md) — single-use committees with mandatory key disposal after decryption, rendering all undecrypted state permanently inaccessible +- [Private Shared State (FHE)](../patterns/pattern-private-shared-state-fhe.md) — FHE-based computation across multiple independent parties +- [Private Set Intersection (FHE)](../patterns/pattern-private-set-intersection-fhe.md) — encrypted computation over datasets from multiple sources +- [Pretrade Privacy (Encryption)](../patterns/pattern-pretrade-privacy-encryption.md) — sealed-bid auctions and confidential matching +- [Threshold Encrypted Mempool](../patterns/pattern-threshold-encrypted-mempool.md) — shared threshold cryptography approach for distributed trust +- [TEE-Based Privacy](../patterns/pattern-tee-based-privacy.md) — E3s are an alternative to TEEs, replacing trusted hardware with distributed threshold cryptography +- [Noir Private Contracts](../patterns/pattern-noir-private-contracts.md) — Interfold uses Noir for ZK circuit (C0–C7) development + +## Not a substitute for + +- ZK-based L2 privacy (e.g., Aztec, Scroll) — Interfold coordinates ephemeral computations, not persistent shielded state +- General-purpose MPC — Interfold targets specific multiparty coordination use cases with FHE-based execution +- TEEs — Interfold replaces hardware trust with cryptographic and economic guarantees, not hardware enclaves + +## Architecture + +The protocol coordinates five lifecycle phases per E3: + +1. **Request**: A Requester submits a computation request specifying the E3 Program, committee size, input window, and Compute Provider parameters. A fee proportional to requested resources is deposited. +2. **Node Selection**: Ciphernodes are selected via verifiable sortition (weighted by ticket balances) to form a Ciphernode Committee (CiCo). The committee performs distributed key generation (DKG) and publishes a shared public key. +3. **Input Window**: Data Providers encrypt inputs to the CiCo's public key and submit them on-chain with ZKPs proving validity (correct encryption, valid format, non-reuse). +4. **Execution**: A Compute Provider runs the Secure Process (FHE computation) over encrypted inputs and publishes the ciphertext output with a proof of correct execution. Supported backends include RISC Zero zkVM. +5. **Decryption**: The CiCo collectively performs threshold decryption of the output and publishes the plaintext result. Rewards are distributed to committee members on completion. + +**Smart contract suite** (EVM, deployed on Sepolia testnet): +- **Interfold Contract** — central coordinator managing E3 lifecycle, committee selection, and Merkle-tree input integrity +- **E3 Program (E3P) Contract** — defines computation logic, validates inputs, and verifies execution proofs +- **Decryption Verifier** — validates threshold decryption shares +- **Bonding Registry** — manages FOLD token license bonds, tFOLD ticket balances, registration, and exit queues +- **Slashing Manager** — processes slashing for misbehavior (attestation-based and evidence-based lanes with appeal windows) +- **E3 Refund Manager** — calculates and distributes refunds on E3 failure + +**Compute Providers** support multiple trust models: verifiable (RISC Zero, with SP1 and Jolt planned) and oracle-based (zkTLS VMs, committee-based, game-theoretic — all coming soon). + +## Privacy domains + +- **FHE**: BFV scheme via `fhe.rs` and the SAFE library for computation on encrypted data +- **Threshold cryptography**: PVSS-based distributed key generation; decryption requires a threshold of ciphernodes +- **ZKPs**: Noir circuits for input validation (C0–C7 phases) and proof of correct execution +- **Ephemeral keys**: Single-use committee keys eliminate long-lived key material risks — keys are treated as toxic waste after decryption + +## Enterprise demand and use cases + +The Interfold targets three coordination categories: + +- **Competitive coordination**: sealed-bid auctions, RFQ desks, and allocation mechanisms where bid strategy must remain hidden until the outcome is finalized — without granting the operator privileged visibility. +- **Collective coordination**: secret ballots, governance voting, and committee selection where private preferences must produce verifiable, coercion-resistant results without a trusted tallying authority. +- **Data coordination**: cross-institutional analysis (medical research, financial risk modeling, collaborative AI training) where sensitive datasets from multiple organizations contribute to a shared result without pooling or custodial transfer of raw data. + +**Concrete implementations**: The CRISP (Coercion-Resistant Impartial Selection Protocol) is Interfold's flagship application — an Aragon plugin enabling secret ballot governance for DAOs with voter registry, key switching, and coercion resistance (building on MACI concepts but replacing the single trusted coordinator with distributed ciphernodes). + +## Technical details + +- **Networks**: Sepolia testnet and Ethereum mainnet (both deployed) +- **Cryptography**: Threshold BFV FHE, PV-TBFV key generation, Noir ZK circuits (C0–C7 phases), RISC Zero zkVM for verifiable compute +- **SDK**: Interfold SDK for Rust, with Noir circuit toolchain (`interfold noir` CLI) +- **Tokenomics**: FOLD (license bonding, governance), tFOLD (non-transferable ticket token for sortition), USDC for ticket purchases +- **Ciphernode requirements**: 100 FOLD license bond minimum, 1+ ticket (USDC-backed), 8+ cores / 32GB+ RAM / 500GB+ NVMe +- **Timeout configuration** (Sepolia): Committee formation 3,600s, DKG 7,200s, Compute 86,400s, Decryption 3,600s + +## Strengths + +- **No single point of execution control**: threshold cryptography separates key generation, computation, and decryption across independent ciphernodes +- **Economic security**: staking, slashing, and refund mechanisms incentivize honest behavior and penalize misbehavior +- **Modular Compute Provider model**: supports both verifiable (ZK) and oracle-based execution backends +- **Ephemeral execution**: single-use keys and bounded E3 sessions minimize attack surface +- **Open-source**: full protocol and toolchain publicly available, built by Gnosis Guild +- **Coercion resistance**: CRISP demonstrates practical coercion-resistant voting without a trusted coordinator + +## CROPS profile + +| Product | CR | OS | Privacy | Security | Context | +|---------|----|----|---------|----------|---------| +| Interfold (E3 Protocol) | high | yes | high | high | both | + +## Risks and open questions + +- Production alpha network is live; real-world throughput and long-term network decentralization remain to be proven at scale +- FHE compute cost and latency may limit applicability for time-sensitive or high-volume use cases +- For verifiable Compute Providers (RISC Zero), anyone can run the program over published inputs and generate a valid proof — the CP is an on-chain verifier contract with no single party that can refuse to publish or halt the E3. For oracle-based providers (planned), trust assumptions will differ + +## Links + +- [The Interfold](https://theinterfold.com) +- [Developer Documentation](https://docs.theinterfold.com) +- [Confidential Coordination Blog Series](https://blog.theinterfold.com/tag/confidential-coordination/) +- [Whitepaper](https://docs.theinterfold.com/whitepaper) +- [Ciphernode Operator Guide](https://docs.theinterfold.com/ciphernode-operators) +- [CRISP (Secret Ballot Reference Implementation)](https://docs.theinterfold.com/CRISP/introduction)