Module halo2_middleware::zal

This module provides “ZK Acceleration Layer” traits to abstract away the execution engine for performance-critical primitives.

Terminology

We use the name Backend+Engine for concrete implementations of ZalEngine. For example H2cEngine for pure Halo2curves implementation.

Alternative names considered were Executor or Driver however

• executor is already used in Rust (and the name is long)
• driver will be confusing as we work quite low-level with GPUs and FPGAs.

Unfortunately the “Engine” name is used in bn256 for pairings. Fortunately a ZalEngine is only used in the prover (at least for now) while “pairing engine” is only used in the verifier

Initialization design space

It is recommended that ZAL backends provide:

• an initialization function:
  • either “fn new() -> ZalEngine” for simple libraries
  • or a builder pattern for complex initializations
• a shutdown function or document when it is not needed (when it’s a global threadpool like Rayon for example).

Backends might want to add as an option:

• The number of threads (CPU)
• The device(s) to run on (multi-sockets machines, multi-GPUs machines, …)
• The curve (JIT-compiled backend)

Descriptors

Descriptors enable providers to configure opaque details on data when doing repeated computations with the same input(s). For example:

• Pointer(s) caching to limit data movement between CPU and GPU, FPGAs
• Length of data
• data in layout:
  • canonical or Montgomery fields, unsaturated representation, endianness
  • jacobian or projective coordinates or maybe even Twisted Edwards for faster elliptic curve additions,
  • FFT: canonical or bit-reversed permuted
• data out layout
• Device(s) ID

For resources that need special cleanup like GPU memory, a custom Drop is required.

Note that resources can also be stored in the engine in a hashmap and an integer ID or a pointer can be opaquely given as a descriptor.

Modules

• impls
• traits