fhEVM-backend
WebsiteLibrariesSolutionsDevelopersSupport
  • Welcome to fhEVM
  • Getting Started
    • Quick start
    • fhEVM
      • fhEVM-native
        • geth integration
        • Executor
        • Configuration
      • fhEVM-coprocessor
        • Deploy initial contracts
        • geth integration
        • Coprocessor Backend
        • Configuration
    • Gateway
      • Configuration
    • TKMS
      • Use Zama's TKMS
      • Request the creation of a new private key
      • Application Smart Contract
      • Run a TKMS
  • Fundamentals
    • Overview
    • fhEVM
      • Contracts
      • Inputs
      • Symbolic Execution
      • fhEVM-native
        • Architecture
        • FHE Computation
        • Storage
        • Genesis
      • fhEVM-coprocessor
        • Architecture
        • FHE Computation
    • Gateway
      • Decryption
      • Reencryption
      • Inclusion proof
      • Decryption and reencryption request on TKMS
    • TKMS
      • Architecture
      • Blockchain
      • Threshold protocol
      • Zama's TKMS
    • Glossary
  • Guides
    • Node and gateway hardware
    • Run a benchmark
  • References
    • fhEVM API specifications
    • Gateway API specifications
  • Developer
    • Contributing
    • Development roadmap
    • Release note
    • Feature request
    • Bug report
Powered by GitBook
On this page
  • Smart Contracts
  • fhEVM
  • TKMS

Was this helpful?

Export as PDF
  1. Fundamentals

Glossary

  • Coprocessor: An off-chain component in fhEVM-native that does the actual FHE computation.

  • Executor: A component that runs alongside the fhEVM-native blockchain node/validator and does the FHE computation. The node/validator and the Executor communicate over a network connection.

  • FheLib: A precompiled contract on fhEVM-native that is available on nodes/validators. Exposes functions such as reading FHE ciphertexts from the on-chain storage in fhEVM-native, etc. At the time of writing, it exists at address 0x000000000000000000000000000000000000005d.

  • fhEVM-coprocessor: An fhEVM configuration where an off-chain Coprocessor component does the actual FHE computation. FHE ciphertexts are stored in an off-chain database local to the Coprocessor and in an off-chain public Data Availablility (DA) layer. No modifications the validator software of the existing chain is required (except for the full-node running for the Coprocessor).

  • fhEVM-native: An fhEVM configuration where each validator is paired with an Executor. FHE ciphertexts are stored on-chain. fhEVM-native requires modifications to the validator software of an existing chain.

  • fhevmjs: A JavaScript library that allows dApps to interact with the fhEVM.

  • handle: A handle refers to (or is a pointer to) a ciphertext in the fhEVM. A handle uniquely refers to a single ciphertext from the user's perspective.

  • KMS: Key Management Service. Used for managing secret FHE key material.

  • Symbolic Execution: Onchain execution where inputs to FHE operations are symbolic values (also called handles) that refer to ciphertexts. We check constraints on these handles, but ignore their actual values.

  • TFHE: An Fully Homomorphic Encryption scheme used in fhEVM and TKMS.

  • TKMS: Threshold Key Management Service. Uses threshold cryptography and multi-party computation. See KMS.

  • ZKPoK: Zero-knowledge proof of knowledge of an input FHE ciphertext.

Smart Contracts

fhEVM

  • ACL Smart Contract: Smart contract deployed on the fhEVM blockchain to manage access control of ciphertexts. dApp contracts use this to persists their own access rights and to delegate access to other contracts.

  • Gateway Smart Contract: Smart contract deployed on the fhEVM blockchain that is used by a dApp smart contract to request a decrypt. This emits an event that triggers the gateway.

  • KMS Smart Contract: Smart contract running on the fhEVM blockchain that is used by a dApp contract to verify decryption results from the TKMS. To that end, it contains the identity of the TKMS and is used to verify its signatures.

TKMS

  • fhEVM ISC: Smart contract which contains all the custom logic needed to validate whether an operation such as decryption, is permitted on a given fhEVM chain. Specifically this involves inclusion proofs of an ACL. Note there is one ISC for each fhEVM.

  • fhEVM ASC: Smart contract to which transactions from the gateway (connector) are submitted to. This contract contains all logic required to work with any fhEVM blockchain. It handles any fhEVM chain-specific logic (such as ACL validation) by calling the ISC associated with the given fhEVM chain.

PreviousZama's TKMSNextNode and gateway hardware

Last updated 6 months ago

Was this helpful?