Skip to main content

​
Road to decentralization

Integrating FHE into a blockchain runtime is a hard and complex task. Our engineering philosophy is to ship fast: to build the best possible product we need to meet real users early. Similar to the approach described in Vitalik’s “training wheels” post (in the context of rollups), CoFHE ships with training wheels of its own. Outlined here is a non-exhaustive list of trust points, centralized components, and compromises made to ship CoFHE to users as fast as possible. Each row notes how we plan to address it, and the list will be updated as things progress. One training wheel has already been narrowed: the ZK Verifier now runs inside a hardware-attested TEE, with its signing key released only to the attested code image. The enclave itself stays a trust point until the move described below.

​
The path to multi-party computation

CoFHE runs two TEE services today, Teecryptor and the ZK Verifier. Both move to multi-party computation, and they move together. No TEE stays on the critical path after that. Decryption becomes a Threshold Network. Independent parties decrypt through multi-party computation, so no single party (and no single machine) ever holds the FHE key. Robustness goals for it include a t-out-of-n protocol (no requirement that every party stays online), party share rotation, and full protocol key rotation. Input verification follows the same model. Each partner runs ZK verification on its own side, instead of one attested enclave checking every proof and signing the batch alone. See Research in Fhenix for the threshold decryption protocol behind this plan.

​
Upcoming features

In the spirit of transparency, here is the general feature roadmap planned for CoFHE.