Module certs 

The verifier’s certificate cache, in front of the Ed25519 verify core.

The problem

Every record carries its batch certificate: the 64-byte commitment and the Ed25519 signature over it. Verifying that signature costs about a thousand times more than the hash work, but all 128 records of a batch carry the same certificate. So the verifier checks each certificate once and remembers the answer, exactly as the reference VerifiedBatch does in software: a record may reuse an answer only if its whole 128-byte certificate is identical to the one that was checked.

The idea

64 entries, picked by the low 6 bits of the batch id (commitment byte 24) mixed with the signer’s key slot. So many because a certificate check takes 52,000–83,000 cycles (Ed25519 project, native simulation of the 1,1,1,1 core): a unit finishes a batch every ~4,500 cycles, so about 20 batches wait for their checks at once. Each holds a certificate (two 64-byte rows in block RAM) and a state:

           miss: store, ask Ed25519
  FREE ───────────────────────────▶ PENDING ──ok──▶ VERIFIED
    ▲                                  │                │
    │                                  └──fail──▶ REJECTED
    └──── replaced by a different certificate (never while PENDING
          or while a waiting record still points at it)

A lookup compares the record’s commitment and signature with the entry’s two rows. A hit on VERIFIED or REJECTED answers at once. A hit on PENDING, or a miss that stores the certificate and asks the Ed25519 core, answers “pending on entry e”; the record then waits at retirement until the entry settles. An entry that waiting records point at (its users count) is never replaced, so their answer cannot change under them.

Several signers

The commitment does not name the signer’s Ed25519 key, so one checked certificate must not answer for a record that claims a different signer. Each record arrives with its signer’s key slot (0 when the verifier trusts one key, as the HBM kernel does). The slot is part of the entry choice (batch id ^ slot << 2), an entry remembers the slot it was checked for, a hit needs the same slot, and the Ed25519 request carries the slot so the cluster presents that slot’s key.

Warm lookups

A warm lookup brings a certificate in ahead of its records (the uBFT service’s certificate announce, crate::ubft): it is looked up like a record’s, and on a miss it is stored and checked, but it answers no record and holds no users count, so it never delays a verdict. When the entry it maps to is busy it is simply dropped; the first record of the batch then checks the certificate as before.

Timing

The loader presents the commitment (beat 0) and the signature (beat 1). The answer comes a few cycles later, long before the record’s 26 beats are in; CertsOutput::busy holds the next record’s beat 0 back in the rare case a lookup must wait for an entry to free up.

Structs

CertAnswer

What a record learns from its lookup.

CertRequest

A certificate check for the Ed25519 core.

CertResult

The Ed25519 core’s answer for an entry.

CertsInput

Inputs of the cache.

CertsOutput

Outputs of the cache.

VerifyCerts

The certificate cache.

Constants

ENTRIES

Certificate entries.

FREE

Entry state: no certificate.

PENDING

Entry state: asked the Ed25519 core, no answer yet.

REJECTED

Entry state: the certificate failed.

VERIFIED

Entry state: the certificate verified.

Functions

rows_equal_kernel

Whether two 64-byte rows are equal (a 512-bit compare as a tree of bytes).

verify_certs_kernel

The cache’s logic.