Cryptography

This page explains the cryptography that protects an E3. It covers threshold BFV encryption, distributed key generation (DKG), and the zero-knowledge (ZK) proofs that make each step publicly verifiable. It is for developers and operators who want to know what the protocol proves and where. At the end, you can map each protocol step to its circuit and to its on-chain verifier. The PVDKG and ZK proof pipeline page gives the full detail.

Building blocks

BFV

BFV works in the polynomial ring $R_q = \mathbb{Z}_q[X]/(X^d + 1)$. The degree $d$ is 64 or 8192. The ciphertext modulus $q$ is a product of CRT moduli $q_\ell$, and $t$ is the plaintext modulus.

A key pair has a secret key $s$ and a public key $(\mathrm{pk}_0, \mathrm{pk}_1)$. A message $m$ encrypts to a ciphertext $(\mathrm{ct}_0, \mathrm{ct}_1)$, with small random polynomials $u$, $e$, $e_0$, and $e_1$ and the scale factor $\Delta = \lfloor q/t \rfloor$:

Decryption computes $\mathrm{ct}_0 + \mathrm{ct}_1 s \bmod q$, which is $\Delta m$ plus small noise. It then scales by $t/q$ and rounds to get $m \bmod t$.

The sum of two ciphertexts decrypts to the sum of the two messages. The default template and CRISP both use this addition. BFV also supports multiplication, but each multiplication uses part of a limited noise budget.

Threshold BFV

In threshold BFV, no party holds $s$. Three numbers define each committee:

• N is the committee size that sortition selects.
• H is the number of dealer contributions that form the key. The active aggregator selects an ascending roster $S$ of H members that are all ready.
• T is the threshold. Decryption needs T + 1 shares from the roster.

The values come from crates/committee/src/lib.rs and packages/interfold-contracts/contracts/lib/ActiveCryptoConfig.sol.

Key generation

Each member $h$ makes a secret contribution $s_h$ and a public key share. It splits $s_h$ into Shamir shares with a polynomial of degree T. It encrypts each share under the recipient's individual BFV key and sends it. The same process runs for smudging noise $e_{\mathrm{sm}}$, which later hides each decryption share.

The individual BFV keys protect only the share traffic during DKG. They are different from the threshold key that data providers use.

After the share proofs pass, each member publishes a signed readiness report. The active aggregator then selects the roster $S$. The threshold secret and public key are:

All members use the same common polynomial $a$, so $\mathrm{pk}_1$ is not a sum. Each roster member $i$ adds the shares that it received from the roster into $\mathrm{sk}_i$, its Shamir share of $s$.

Threshold decryption

Each roster member $i$ computes a decryption share from the ciphertext output:

Ciphernodes use the committee key and decryption domain from confirmed chain state. Repeated matching key publications do not start more share calculations or proof requests. After a restart, the node resumes retained work when effects are enabled. Local worker failures retry the same request.

The aggregator takes T + 1 shares with party coordinates $x_i$. The coordinates start at 1, and they must be unique and in increasing order. The aggregator combines the shares with Lagrange coefficients at zero:

The coefficients $L_i(0)$ add up to 1, so $u = \mathrm{ct}_0 + \mathrm{ct}_1 s$ plus small noise. The aggregator then decodes $u$ to the plaintext, as in normal BFV decryption.

T + 1 roster members that collude can decrypt any ciphertext under the committee key. This limit applies to every threshold scheme. Larger committees raise T.

Publicly verifiable threshold BFV

Publicly verifiable threshold BFV (PV-TBFV) adds a ZK proof to each sensitive step. Anyone can check the proofs without the private values. The DKG part is publicly verifiable DKG (PVDKG). The steps form four phases:

The FHE computation runs between P3 and P4. The compute provider proves it with its own proof system (the OpenVM zkVM in the current code), not with these circuits.

A failed proof is attributable to one member. Other members then start an accusation, which can lead to a slash. See Commitment consistency and Exits and slashing.

Circuit map

The circuit IDs match the CircuitName enum in crates/zk/config/src/circuit.rs. The directories are under circuits/bin/.

The "a" and "b" suffixes are the secret-key track and the smudging-noise track. C3 and C4 use one circuit for both tracks.

Proof aggregation

Members exchange their proofs over libp2p gossip and verify each other's proofs. Recursive circuits in circuits/bin/recursive_aggregation/ then fold the proofs:

Only two proofs go on-chain for each E3:

1. The DKG proof from dkg_aggregator. The registry verifies it at publishCommittee through BfvPkVerifier. The registry also checks one signed fold attestation from each roster member with DkgFoldAttestationVerifier. It then stores the DKG anchors: the party IDs and the commitments to each member's aggregated key share and smudging noise.
2. The decryption proof from decryption_aggregator. The Interfold contract verifies it at publishPlaintextOutput through BfvDecryptionVerifier. The verifier compares the commitments in the proof with the stored DKG anchors.

Both proofs bind the committee hash. CommitteeHashLib computes it as the Keccak-256 hash of the committee addresses in ascending order. The decryption proof also binds a decryption domain: the hash of the chain ID, the Interfold address, the e3Id, the committee hash, the ciphertext output hash, and the committee public key. A decryption proof for one E3 therefore fails for any other E3.

Commitments link the circuits

BFV polynomials are too large to publish for every step. Each circuit hashes its polynomials into a short commitment with the SAFE sponge. A later circuit takes the earlier commitment as a public input. It recomputes the commitment from its private inputs and checks that the two values are equal.

These links form one chain from key generation to decryption:

• C1 to C2: the committed secret contribution and smudging noise.
• C2 to C3: the shares that each ciphertext encrypts.
• C1 to C5: the public key shares that form the threshold key.
• C4 to C6: the aggregated key share and smudging noise of each member.
• C6 to C7: the decryption shares.

The recursive circuits check most links inside the proofs. node_fold checks the links in one member's chain. dkg_aggregator checks the links between members and from C5 to C1. decryption_aggregator checks the link from C6 to C7. The C4 to C6 link goes through the DKG anchors, which the on-chain decryption verifier compares.

Domain-separation labels (DS_* in circuits/lib/src/math/commitments.nr) keep different kinds of commitments apart.

Recursive verification also binds the complete VK tree. Each sequential fold carries fixed leaf, fold, and genesis key hashes. The final proof commits to every nested key at public input zero. Deployment pins that commitment from the matching artifact pair's .vk_tree_hash, so a prover cannot substitute another circuit within the proof tree.

BFV presets

Two BFV presets exist. Each preset has a threshold parameter set for user data and a DKG parameter set for the individual keys. The values come from crates/bfv/params/src/constants.rs.

insecure-64 is for development and tests only. The code marks it as not for production. The deployment script refuses to deploy it on a chain that is not a known test or local chain.

Presets by chain

ActiveCryptoConfig.sol selects the supported presets from block.chainid:

Any chain that is not Sepolia or local gets the mainnet rules. The mainnet launch pricing configuration sets minCommitteeSize to 19. With that value, getE3Quote rejects Minimum and Micro requests on mainnet, so only Small can be requested.

Each request must name the expected circuit configuration in expectedCryptoConfigId. The ID binds the scheme, the parameter hash, and the circuit version (keccak256("interfold-bfv-v5")).

Next steps