Announcing Concrete Core v1.0

October 18, 2022
The Zama Team

Today, Zama announces the release of a new version of Concrete-core. This release brings us one step closer to mass adoption of FHE. However, there are two keys that still must be completed if we are to unlock that stage: performance and ease of use. Zama is putting all its energy into making these two challenges belong to the past, and part of this effort is Concrete-core. 

Today, it is our pleasure to deliver Concrete-core V1.0.0, a platform to bring FHE to the next level.

Concrete-core V1.0.0 is dedicated to addressing the performance aspect of FHE: its chief aim is  to quickly and reliably integrate hardware acceleration into the Concrete Framework. To do so, this version relies on three core components:

  1. A Rust library that offers a plugin system for hardware contributions.
  2. A testing and benchmarking framework that can handle all implementations of the supported operations on any hardware.
  3. A representation tool that makes it possible to automatically generate APIs to other languages based on the Rust library.

With this, Concrete-core has the potential to become the hub where compiler builders, library writers, and hardware designers meet to build the future of FHE. 

The Rust library

A hardware integration platform.

The API relies on two elements to integrate accelerations of available operations:

  1. A full list of FHE data types and operations supported in the framework, clarifying the inputs and outputs of every operator, via Rust traits: the Specification.
  2. A plugin system to implement any subset of data types and operations on any hardware: the Backends.

This architecture makes it possible to activate any number of desired backends when  compiling. The full list of supported data types and operations is available in the user documentation. The cryptographic content is described in the Rust documentation itself. The supported data types are the following:

  • Encryption keys: GLWE secret keys, LWE secret keys and LWE public keys.
  • Keyswitch keys: LWE keyswitch keys, its compressed version (seeded LWE keyswitch keys), LWE packing keyswitch keys, LWE private functional packing keyswitch keys, and lists of LWE private functional packing keyswitch keys for the circuit bootstrap.
  • Evaluation keys: LWE bootstrap keys and their compressed equivalent.
  • Ciphertexts: LWE ciphertexts and their compressed equivalent (seeded LWE ciphertexts), GLWE ciphertexts and their compressed equivalent, and GGSW ciphertexts and their compressed equivalent. 

All the ciphertext types are also exposed in their vectorized form, which corresponds to lists of such objects that are contiguous in memory. Having those vector types is useful to send batches of data to a given hardware. Additional types for encoders and data in the clear are also exposed. On the other hand, the supported operations belong to several categories:

  • Basic FHE operations: encryption, decryption, encoding, key generation, transformation of an LWE secret key into a GLWE secret key and vice versa, decompression of a seeded ciphertext, keyswitch, etc.
  • Linear algebra: leveled operations that make it possible to perform homomorphic linear algebra computations, for example the addition and subtraction between ciphertexts, the negation of a ciphertext, the multiplication of a ciphertext with a cleartext, etc.
  • Bootstrap: a number of operations related to TFHE's programmable bootstrap are supported: the programmable bootstrap itself, the Cmux, the external product, the circuit bootstrap (that transforms an LWE ciphertext into a GGSW ciphertext), the vertical packing, and the bit extraction.

Finally, a number of operations help in managing data (see the user documentation for more details). A code snippet for each implementation of an operation in a backend is available in the Rust documentation

Supported backends.

Concrete-core comes with a CPU implementation of the TFHE scheme, with support for x86_64 platforms and aarch64 platforms. Linux platforms are officially supported and experimental support for Mac and Windows users is provided. This CPU implementation is exposed in the default backend, except all bootstrap-related operations that are exposed in:

  • The FFT backend, that relies on an in-house FFT implementation in Rust and implements the bootstrap;
  • The FFTW backend, that relies on the FFTW library instead - it is being deprecated but currently implements more operations, namely the building blocks for a large precision bootstrap;
  • The Cuda backend, that provides GPU acceleration of TFHE’s programmable bootstrap and keyswitch.

More backends are in the process of being integrated: an NTT backend on CPU, an Optalysys backend that will provide acceleration via an optical Fourier transformation, etc. It is very easy to integrate a new backend in the library. Check out our tutorial to see how to do it.

Test and benchmark framework

The testing and benchmarking framework is built to support any backend. To this purpose, the sampling and testing of operations is organized into five steps:

  1. Generate all necessary inputs on the CPU
  2. Copy them to another hardware
  3. Execute the operation
  4. Copy the result back to the CPU
  5. Verify the results

This logic is handled by the Concrete-core-fixture package, that defines a `Fixture` trait for every operation, generic over the type of backend. Then, in the Concrete-core-test and Concrete-core-bench packages, all tests and benchmarks are instantiated on CPU and GPU. 

This framework makes it possible to ensure your implementation is correct, and to quickly compare the performance of your implementation to all others. It is very easy to add a new backend in this framework. Check out our tutorials to see how to proceed. 

Using Concrete-core from other languages

Concrete-core comes with two APIs to languages other than Rust:

  • Concrete-core-ffi, that exposes a C API
  • Concrete-core-wasm, that exposes a Javascript API

Writing those APIs manually is tedious, but Concrete-core now provides a tool for automatic API generation. It relies on the Concrete-core-representation package, which generates a custom intermediate representation of the Concrete-core sources. From that intermediate representation, it is possible to automatically generate bindings to another language. At the moment of this writing, the Javascript API is built this way and the C API is on its way to being automatized.

Summing Up

With the release of Concrete-core V1.0.0, Zama is providing the open-source community a platform to integrate FHE primitives implemented on any hardware. This platform is comprised of:

  • a CPU implementation of TFHE operations;
  • a Cuda acceleration of TFHE’s bootstrap and keyswitch;
  • a plugin system in the library’s architecture to easily integrate any other hardware acceleration;
  • a testing and benchmarking framework to quickly check implementations are correct and compare their performance;
  • and a tool to automatically generate APIs to other languages.

The aim of this platform is to experiment with hardware acceleration as swiftly as possible to help resolve one of the main challenges facing FHE today: performance. It has the potential to bridge the gap between hardware developers, cryptographers, compilers and library makers, in order to ultimately bring FHE to a larger audience. 

This v1.0.0 release brings a lot of changes compared to v0.1.10, with the backend system in particular, but it is still a research-heavy project and should be subject to significant changes in the near future. In particular, hardware integration has to be pushed further in the Concrete stack, in particular via the integration in the Concrete Compiler. This will bring hardware acceleration to Concrete-Numpy and Concrete-ML users, both of which aim at making FHE transparent to the user.

Additional Links

- Release notes

- Github repo

- Documentation

- List of contributors

Read more related posts