One (fhe) program, any chain

With fully homomorphic encryption (FHE), we can bring privacy to existing applications and enable entirely new applications across finance, prediction markets, machine learning, and much more.

To create privacy-preserving applications, we need a concept of "verifiable hidden state" so that users can protect their individual data while still allowing that data to be used in an application (e.g. trading, matching, prediction). Threshold FHE accomplishes exactly that. Using this technology, program inputs can be hidden from everyone. The program output may or may not be hidden, depending on the particular use case.

Our team has developed what we call our "secure processing framework" (SPF for short), our end-to-end offering that allows developers to create, deploy, and use FHE programs. Its architecture was inspired by that of CPUs and GPUs, and the underlying technology was developed in-house by our team. We've combined our experiences across cryptography as well as high performance computing, signal processing, and high frequency trading to build FHE in a way that scales.

So what motivated us to build SPF and why isn't FHE production-ready yet?

Challenges building FHE apps

The first set of challenges occurs when creating an FHE application.

• You must determine the best FHE scheme for your needs. There are a few different FHE schemes out there such as BFV, CKKS, and TFHE. You'll need to select which scheme is most appropriate for your particular needs (e.g. are you looking to primarily do arithmetic over floats? Comparisons over integers?)
• You must select FHE scheme parameters very carefully. Unlike some other cryptographic primitives (e.g. zero knowledge proofs), program performance is very sensitive to parameter selection. By choosing too large parameters for a particular use case, you may experience a 10x degradation in performance versus having chosen parameters exactly right. For certain FHE schemes (like ours) there are almost a dozen parameters to configure that are deeply interconnected and influence everything from security to correctness and performance.
• You must structure the program exactly right. Working with FHE today is a bit like programming with computers in the early days; you need to express programs in a very low-level way and consider what operations are relatively expensive vs cheap for the particular FHE scheme. Quite a bit of creativity is needed to effectively translate your high level program into arithmetic or binary circuits. If you've already written your application to operate over data in the clear, you may have to restructure it so that it's "FHE friendly."

Challenges deploying FHE apps

In summary, programming with FHE is similar to Goldilocks looking for just the right fit. Unfortunately, more challenges arise in deploying an FHE app.

• Someone must provide the appropriate hardware/machines for running the FHE program. To get good performance with the technology today, very specific hardware must be set up. As an example, we've seen that working with a 64 core machine helps significantly for our TFHE scheme variant as it allows us to take advantage of parallelism opportunities for various operations.
• Someone must set up a "threshold committee" to hold shares of FHE public key. This committee is responsible for responding to decryption requests in a timely manner.
• Someone must set up an access control system and/or a data storage system. How do we ensure that only the "correct" parties have access to data in the clear? This is where access control becomes important. Additionally, FHE-encrypted data is large. If the app is deployed on blockchain, we can't expect to store this on-chain. Where then do we store it and who manages this?

Thus, there's quite a bit of work involved with actually using FHE in an application today beyond just translating your application code into FHE code.

Secure Processing Framework (SPF)

SPF aims to handle all of the above problems on the developer's behalf.

To bring verifiable hidden state to blockchain applications, we make use of threshold FHE, building on our own variant of the Torus FHE scheme (TFHE).

Looking inside

There are 3 major pieces in SPF: the core stack, the control stack, and the data bus.

Core stack

The core stack allows developers to write highly-optimized FHE programs by default. It consists of our LLVM-based compiler, our customized virtual processor, and our low-level TFHE library implementing the cryptographic algorithms necessary for our variant of TFHE. If you'd like to learn more about the core stack, we discuss it in detail in a prior blog post.

Developers only interact with the compiler which abstracts away the usual difficulties in working with FHE. The processor and low-level TFHE library are hidden away.

Control stack

The control stack supports the core stack so that developers can use their FHE programs on chain. It provides important functionalities like threshold decryption (via a decentralized network of nodes holding shares of the secret key), access control (to ensure only authorized parties have access to plaintext data), and off-chain storage.

As we utilize threshold FHE, a network of parties needs to be set up to hold shares of the secret key and respond to decryption requests. We handle this on the developer and user's behalf automatically.

A practical challenge with FHE today is that the encrypted data is fairly large--for blockchain standards at least--and accordingly should not be stored directly on-chain. We provide a data store for ciphertexts and program data. In later versions, we can provide developers with the flexibility of choosing among a few decentralized immutable data storage solutions.

Data bus

So how do you actually interact with SPF on-chain today? That's where the data bus comes in. The data bus can be thought of as a pull oracle; it listens for events emitted on-chain. When you request a program run or decryption, an event is omitted on chain. The data bus picks up the event and forwards the request. The result of the computation is put back on-chain via a callback.

Features

What sets SPF apart from existing FHE offerings is the features it can offer developers today and in the future.

• One program, any chain: Today, blockchains are operating in silos. To unlock the full potential of web3, the community must enable seamless interoperability between various ecosystems. Specifically, we believe there will no longer be chain and language silos in blockchain as there are today. SPF puts this plan in action by enabling developers to write one (FHE) program and use it on any chain, regardless of virtual machine. This makes it easy for developers to experiment with different blockchains as well as deploy their app to multiple chains.
• Bring your own program: Building on our prior belief, developers should not have to re-write their application to take advantage of FHE. In a perfect world, developers can transform their existing application code into FHE-enabled code. To support this experience, we allow developers to write in mainstream programming languages. They simply add directives to indicate which inputs/outputs should be hidden and which functions are FHE programs. Bringing more developers into the blockchain space also requires meeting developers where they're at---whether in terms of programming languages or cryptography knowledge.
• Automatically optimized FHE programs: As we touched upon prior, a big challenge with FHE today is determining how to structure your FHE program to get good performance. SPF includes a compiler and virtual processor which determines, behind-the-scenes, how to optimize a developer's code for them.
• Modular stack: There will be better FHE schemes in the future. Accordingly, we designed SPF so that the backend FHE scheme can be swapped out without interfering with the developer's programming experience. We may also wish to switch out our custom instruction set architecture (called PISA) to something more standardized like RISC-V. Modularity also extends to our control stack, so that off-chain data storage mechanisms can be updated or better access control mechanisms can be introduced.
• Built for the hardware endgame: Much like transformers in deep learning were architected to take advantage of the parallelism provided by GPUs, FHE must be architected to suit hardware. What this means in practice is extracting parallelism from how FHE computing is done as well as reducing the critical path in the circuit itself; together, doing these two things can unlock higher throughput and lower latency as specialized hardware for FHE becomes available. This is accomplished in large part by creating our own variant of the TFHE scheme.

Developer workflow

SPF enables developers to bring FHE directly to applications on any chain. You do not need to migrate your program to a new chain, L2, rollup, etc.

For simplicity, we'll look at how to write and deploy your program on Ethereum. Other chains work similarly.

• Write your FHE program in C. While there are some restrictions as to what you can vs can't write today, your application code is just normal C code.
• Compile your FHE program using our compiler. Doing so will create an ELF object file that can be used by Sunscreen.
• Register your program. As part of registration, you'll receive a hash for the binary program file which will be needed to reference your program on-chain.
• Write your accompanying smart contract and deploy the program. Next, you'll write the Solidity dApp that allows users to actually interact with your FHE program. There are particular ways in which this contract must be structured.
  • Requesting programs runs. To request program execution using SPF, you'll specify the handle of the program to be run along with the number of output parameters. Our data bus monitors the chain for program run requests and routes it to the SPF for off-chain execution.
  • Requesting decryption. To request decryption of the output parameters, you'll need to specify the handle of the program along with the number of output parameters to decrypt. Our data bus monitors the chain for decryption requests and routes it to the off-chain threshold decryption service for processing. The threshold decryption service will then decrypt the desired value and post the results back on-chain using the specified callback.

Alternatively, if you're interested in deploying FHE apps in web2, we also support that experience with SPF.

The only piece that changes is the last step. Instead, you will:

• Develop an application around your FHE program. This involves creating a frontend and backend that interacts with the SPF service. The FHE component will consist of two main pieces:
  • Requesting the SPF service to run your FHE program. You will submit the program, along with the encrypted input data, to an endpoint using an HTTP POST request. The SPF service will respond with a unique identifier for the computation that you can use to track the status of the computation, along with references to resulting ciphertexts.
  • Handling the result. Once the SPF service has completed the computation (which you can check by polling our runs SPF REST endpoint), the appropriate party can request the results be decrypted by making a GET request to our threshold decryption service. This will then return the decrypted result.

We've omitted details about access control as this feature will be developed in a later release.

A delicate balance between on-chain and off-chain

To ensure FHE programs can be used on any chain without having to modify the chain's architecture or consensus mechanism, we must move a number of tasks off-chain.

Specifically, we store FHE programs, their inputs, and any encrypted program outputs off-chain. Instead, only links/handles to these are posted on-chain. For plaintext program outputs, these can be stored on-chain as they're small in size.

The FHE computation is run off-chain using relatively powerful hardware deployed by Sunscreen initially. The threshold committee responsible for decrypting data also lives off-chain.

Why FHE

For many years now, extractive corporations have been feeding on our data without returning any of its value to us; privacy-preserving technology returns power to those of us (be it individuals or corporations) who actually produce valuable data. While there have been many exciting developments in AI and ML, these do not shift the existing power paradigm; rather, these developments have the potential to exacerbate the existing situation.

Trusted execution environments (TEEs) and multi-party computation (MPC) are alternative privacy-preserving technologies. However, we view them as further centralizing forces, if not used in conjunction with FHE.

As a hardware-based and centralized solution, there's a natural vendor lock-in when using TEEs for privacy. Additionally, securely programming an application with TEEs continues to be incredibly challenging, with new attacks found frequently.

MPC is a software-based solution but is communication-bound. Thus, to get good program performance, the relevant computing parties must be located very close in physical proximity. In some cases, this even means co-location of the servers.

We believe in a decentralized future in which users own their own data. Fully homomorphic encryption allows us to best achieve that vision.

Our evolving vision

Devnet and testnet for SPF will be available soon. Our whitepaper will be available in the coming weeks, laying out our vision for how to bring verifiable hidden state to applications in web2 and web3 in a scalable manner.

We'd love to hear what you're excited about building and what features you need to make your dream (d)app a reality!

Resources to get started

• Parasol developer docs: Start using our next-gen FHE compiler today.
• Past blog post: Learn more about our vision for homomorphic computing.
• Ask our team anything: Chat with our team about FHE or any app ideas!