DOCSEARCHbyAlgolia
Submit Docs

CoFHE Client SDK

website·Indexed 33 days ago

https://cofhe-docs.fhenix.zone

TypeScript client SDK and plugins for building Fully Homomorphic Encryption (FHE) enabled applications on Fhenix. Includes @cofhe/sdk for encrypting inputs and managing Access Control Permissions (ACP), as well as @cofhe/hardhat-plugin and @cofhe/foundry-plugin for local FHE contract development and testing.

Tokens
87.3K
Snippets
364
Records
527
Agent score
63%

What's inside CoFHE

  1. Overview of Teecryptor decryption component

    Teecryptor is an offchain component that decrypts CoFHE ciphertexts inside a hardware-attested Trusted Execution Environment (TEE), specifically using Intel TDX. It holds the FHE secret key within an isolated, hardware-encrypted environment to ensure that only a specific, reviewable program can access the key. Its primary responsibilities include authorizing requests against an onchain Access Control List (ACL), verifying ciphertexts against onchain commitments, performing decryption inside the enclave, and signing or sealing the results for delivery.

  2. Overview of CoFHE Mock Contracts

    The CoFHE Hardhat plugin deploys a suite of mock contracts that simulate the full CoFHE coprocessor stack on the Hardhat network. This allows developers to test FHE contracts without running the off-chain FHE engine. The SDK automatically detects the mock environment by checking the bytecode at the MockZkVerifier fixed address, skipping ZK proof generation and using mock verification instead.

    ContractRole
    MockTaskManagerManages FHE operations; stores plaintext values onchain for testing
    MockACLAccess control for encrypted handles
    MockZkVerifierSimulates ZK proof verification for encrypted inputs
    MockThresholdNetworkHandles decryption requests

  3. Overview of the ZK Verifier component

    The ZK Verifier is an offchain component running inside a hardware-attested TEE (Intel TDX). It verifies that users possess the plaintext for encrypted inputs using Zero-Knowledge Proofs of Knowledge (ZKPoK) before those inputs are allowed into confidential smart contracts. This prevents malleability attacks (transforming ciphertexts without knowing contents) and Chosen Ciphertext Attacks (CCAs).

  4. Overview of CoFHE network keys and their purposes

    CoFHE utilizes a set of keys that are never held in their entirety by any person or machine outside of an attested enclave. The primary keys include:

    • FHE network key: Used by Teecryptor to decrypt ciphertexts inside the enclave.
    • Result-signing key: Used by Teecryptor to sign decryption results for on-chain verification by the TaskManager.
    • Verifier signing key: Used by the ZK Verifier to sign verified input batches.
    • Public material: The network public key and Common Reference String (CRS) used by clients for encryption.

  5. Overview of the Encryption Request Flow

    The Encryption Request Flow converts plaintext application data into verified encrypted inputs that a smart contract can compute on. To ensure security, all sensitive operations (encryption and ZK proof generation) occur client-side; only ciphertexts and proofs are transmitted. Inputs are processed in batches and verified with a single signature bound to the specific consuming contract to prevent replay attacks across different contracts.

  6. Overview of the CoFHE Solidity Framework

    CoFHE is a Solidity framework that enables secure, private computation on encrypted data within smart contracts. It allows developers to perform operations on encrypted values without revealing the underlying plaintext data, maintaining blockchain transparency and trustlessness while preserving privacy.

  7. Overview of the TaskManager contract

    The TaskManager is a UUPS-upgradeable contract deployed on every host chain. It serves as the onchain entry point for CoFHE integration with the following responsibilities:

    • Initiating FHE operations requested via the FHE.sol library.
    • Generating unique handles to reference future FHE results.
    • Emitting structured task events for offchain components.
    • Verifying signatures on encrypted inputs and published decryption results.

  8. Overview of ERC20Confidential dual-mode tokens

    ERC20Confidential is a dual-mode token contract that provides every holder with two distinct balances within the same contract: a public ERC-20 balance (compatible with standard wallets and DEXs) and a confidential, FHE-encrypted balance (stored as an euint64 handle).

    Key characteristics include:

    • Public Layer: Inherits from OpenZeppelin's ERC20. Standard functions like balanceOf, transfer, and approve work normally.
    • Confidential Layer: Implements the ERC-7984 API, allowing private transfers via confidentialTransfer and the use of operators and receiver callbacks.
    • Bridging: Tokens move from public to confidential via shield() and from confidential back to public via unshield() and a claim process.
    • Backing: All confidential units are backed by real public tokens held in a sentinel address called CONFIDENTIAL_POOL (0x1011000000000000000000000000000000000000).

  9. Overview of CoFHE Decryption Flow

    Decryption in CoFHE is a multi-step process that converts encrypted data back to plaintext using a combination of offchain and onchain components. The general flow is:

    1. A client requests decryption offchain and receives the plaintext and a signature from Teecryptor.
    2. The plaintext and signature are submitted onchain, where the contract either publishes the result globally or verifies the signature for a specific operation.

  10. Overview of CoFHE FHE Coprocessor

    CoFHE is a Fully Homomorphic Encryption (FHE) coprocessor that enables blockchains to perform computations on encrypted data without requiring a migration to a specialized FHE chain. It allows developers to maintain standard Solidity development workflows while adding confidentiality. Instead of handling large ciphertexts onchain, Solidity contracts work with lightweight 'handles' (references to ciphertexts), while the computationally expensive FHE math is executed offchain in a compute pipeline.

  11. Overview of FHERC20 Wrappers

    FHERC20 Wrappers provide a privacy layer by allowing users to convert transparent ERC20 or native tokens (e.g., ETH) into confidential FHERC20 tokens. This enables private transactions while maintaining a 1:1 backing of the underlying tokens held in the wrapper contract. The process is reversible, allowing users to unshield confidential tokens back to their original form.

  12. Overview of CoFHE Architecture

    CoFHE (Coprocessor for Fully Homomorphic Encryption) allows smart contracts to perform computations on encrypted data. The architecture consists of onchain contracts that request operations and offchain components that execute those operations and commit results. Data remains encrypted until an authorized decryption occurs, and all results are verifiable against onchain commitments.