Skip to main content

Developer workflow

This section describes the process of creating, deploying, and running programs with SPF in both web2 and web3 environments. The developer experience is largely similar across both ecosystems, with the primary differences being how program runs are initiated and how results are decrypted. This section covers the high level workflow, while detailed information about SPF service endpoints and the smart contract library is provided in later sections.

Creating your program​

The initial program creation process is identical for both web2 and web3 applications.

The workflow consists of:

  • Write the FHE program in C. C code can be written as normal, with a few specific patterns used to handle the compute model of FHE. More details are provided in the writing section.
  • Compile the FHE program library to binary. The compiled program is packaged as an ELF binary file for use by SPF.
  • Upload the program to SPF. The provided client uploads the program library and returns an identifier for referencing the program.

Providing program inputs​

Developers or end users can:

  • Generate ciphertext inputs. The user uploads an encrypted value to the SPF service. The service stores this value and returns an identifier for referencing the ciphertext.

Running your web2 program​

image

In web2 environments, applications integrate with the SPF service through REST API endpoints. The two most useful endpoints for web2 use cases are:

  1. Request program run. Programs are executed through a run endpoint with the specified FHE program and the encrypted inputs. The endpoint returns a unique identifier for the computation, which can be used to track status and derive the resulting ciphertexts.
  2. Request decryption. Once the computation completes, results can be decrypted by calling the SPF decryption endpoint. The service returns a decryption handle for tracking status and retrieving the result.

Running your web3 program​

image

In web3 environments, applications interact with SPF service endpoints through the SPF data bus service, which monitors a blockchain for SPF related events. Developers write smart contracts that use the provided smart contract library, which offers two main functionalities:

  1. Request programs run. The run request function prepares input data and initiates a run request. This emits a run request event that the data bus (aka a pull oracle) observes and routes to SPF for execution. The function also returns a unique identifier for the computation, which can be used to track status off-chain and derive the resulting ciphertexts.
  2. Request decryption. Once the computation completes, the decryption request functionality initiates decryption for a ciphertext identifier. This emits a decryption request event that the data bus (aka pull oracle) observes and routes to SPF for decryption. Upon completion, SPF posts the result back on-chain using the specified callback.

What is done on-chain vs off-chain?​

The SPF design enables developers to bring FHE directly to applications on any chain without requiring migration to a new chain, L2, or rollup. This architecture maintains a similar developer workflow for both web2 and web3 environments, as most blockchains are not designed to handle FHE operations directly on-chain.

Summary of on-chain vs off-chain operations:

  • FHE programs (the binary bytes) are stored off-chain. However, program identifiers are stored on-chain as part of the contract.
  • Ciphertexts (encrypted inputs and results) are stored off-chain. However, ciphertext identifiers are typically stored on-chain.
  • FHE computation is performed off-chain. However, the contract code that requests program runs is stored on-chain.
  • Ciphertext decryption is performed off-chain via the threshold committee, which also operates off-chain. However, the contract code that requests decryption is stored on-chain.