Implementations

An implementation is somebody's answer: this specification, this mechanism, this code, this coverage. A kernel routinely has several, and they are expected to differ in language, library, hardware and strategy all at once — that variety is the point of the catalogue.

What one declares

The specification it answers, by address: kernel/spec@version. An implementation answers one specification; a version alone does not name one.

Coverage — the region of the parameter space it handles, as a union of blocks. Each block admits a set of types per type parameter and a set of values or ranges per value parameter. An implementation is judged only inside its coverage: covering a single point is a complete answer, and there is no prize for breadth — otherwise a narrow, very fast answer would rank below a broad, mediocre one. Two implementations are compared only where their coverage intersects.

Mechanism — which technology answers the kernel: plain, fhe, mpc, zk, tee, with the scheme and library where they apply. A structured field, because a comparison across mechanisms must be visible as one: an FHE time next to a plaintext time is a fact about cryptography, not a ranking.

Artifacts — the evidence: a repository at a commit, a container image, a source bundle, or a paper. What is measured is a commit, never a branch — main today and main tomorrow are different code. An implementation whose only artifact is a paper cannot be run; the catalogue says so rather than ranking it.

Environment requirements — what the code needs from a machine, in a closed vocabulary of capabilities: an image, a CUDA version, memory, CPU features. The vocabulary is closed so that openfhe, OpenFHE and open-fhe cannot silently fail to match; an unknown name is refused when the implementation is submitted, not left in a queue nobody can read the reason of.

Requirements also decide the class an implementation competes in. A GPU answer and a bare-CPU answer produce incomparable numbers, and one table holding both would rank hardware — invisibly, because the numbers look equally plausible. Declaring more than the code uses is therefore self-defeating: ask for a GPU and you are compared with those who use one.

Evidence

FHERMA separates an implementation from the evidence available for it, and represents the actual state of the ecosystem rather than pretending only open-source runnable code exists. The three kinds carry different levels of verifiability:

A paper is a first-class object even though it produces no number: the catalogue records it as a claim rather than ranking it against runnable code.

Three functions

The measured code is three functions, scaffolded by fherma implementation init:

init(p: Point)                  -> State     setup. Not measured.
run (state: State, inp: Inputs) -> Outputs   the answer. Measured, whole.
free(state: State)                           optional.

init builds what depends on the parameters alone — keys, tables, an NTT plan. It never sees the data; the signature does not pass it any, and that is a type, not a convention. run is timed from entry to exit. Reading inputs and writing answers happen in generated code, outside the window.

An encrypted implementation writes four functions instead — encoding and decoding join the contract, and an envelope holds the keys. See Encrypted solutions.

Lifecycle

draft → development → published → archived

A draft is its author's. A published implementation is public, and its measurements are attached to the commits they were taken at. Archiving hides it from the default listings without unwriting its history.

Dependencies

An implementation may build on other implementations — an NTT-based multiplier on a particular NTT. The dependency is recorded so that a measurement names everything it measured: a time through a dependency is a fact about the pair.