# Expert-Activation Signatures (EAS) v1.0

**Listing:** 29  
**Status:** formal specification; CC0  
**Scope:** sparse top-k Mixture-of-Experts routing

## 1. Model and canonical objects

Let the model have `M` experts indexed by `[M]={0,...,M-1}` and public parameters `model_params`. `model_id` is a domain-separated hash of the exact serialized architecture, router parameters, expert count, numeric representation, and tie-breaking/version rules. A model identifier therefore commits to the routing function rather than merely naming a deployment.

The input commitment is `input_hash = H("eas.input.v1" || canonical_encode(x))`. The canonical encoding, hash algorithm, field encoding, and endianness are part of `model_id`'s versioned parameters. The router is deterministic: it evaluates logits in the declared fixed-point representation and selects the top `k` scores, breaking equal scores by lower expert index. Define `Act(input_hash; model_params)` as that exact set. `k` is public model configuration and `1 <= k <= M`.

An EAS is the tuple:

```text
EAS = (model_id, input_hash, S, commitment_c, proof_pi)
```

`S` is a strictly increasing, duplicate-free list of exactly `k` expert indices. `commitment_c` commits to the routing witness and the public statement. `proof_pi` is a non-interactive zero-knowledge proof for the relation in §4. All encodings are canonical; malformed, unsorted, duplicate, out-of-range, or wrong-cardinality `S` is rejected before cryptographic verification.

## 2. Verification interface

```text
verify(S, commitment_c, proof_pi, input_hash, model_params) -> true | false
```

The verifier derives `model_id` from the supplied versioned `model_params`, checks `input_hash` and canonical `S`, reconstructs the public statement, and verifies `proof_pi`. It returns true only when every check succeeds. `model_params` may be supplied as a public model commitment plus the public verification key for the fixed model; the commitment must equal the `model_id` inside the statement.

The verifier never receives or evaluates the outputs of any expert. `S` is intentionally public: the signature proves the routing decision, not the secrecy of which experts were selected.

## 3. Exact-set correctness

Let `R_EAS` be the relation containing a witness `(x, router_trace, rho)` satisfying:

1. `H("eas.input.v1" || canonical_encode(x)) = input_hash`;
2. the trace evaluates the declared router with the exact fixed-point arithmetic and tie rule in `model_params`;
3. the resulting top-k set is exactly the public sorted list `S`;
4. `commitment_c = Com(model_id, input_hash, S, router_trace; rho)`.

The required correctness property is:

```text
verify(S, c, pi, input_hash, model_params) = true
iff
S = Act(input_hash; model_params)
```

The `iff` is understood with the normal cryptographic qualification: honest proofs for a true relation are accepted except negligible verifier error, while an accepted proof for a false relation occurs only with negligible probability under the assumptions in §7. Thus “true” cannot be obtained merely by committing to a claimed set; the proof must establish the complete router evaluation and exact top-k relation.

Completeness: an honest prover with the committed model and input produces a proof accepted by the verifier. Soundness: no probabilistic polynomial-time adversary can produce an accepted proof for an `S` different from the deterministic activation set, except with negligible probability. Binding `model_id` to all numerical and tie-break semantics prevents two runtimes from proving different sets for the same nominal model name.

## 4. Privacy for non-selected experts

The public view is `V=(model_id,input_hash,S,c,pi)`. For every `j` not in `S`, `pi` must reveal no information about the output `f_j(x)` or hidden activation state of expert `j` beyond what is logically implied by the public values `(model_id,input_hash,S)`.

Formally, there is a PPT simulator `Sim` that receives only `(model_id,input_hash,S)` and the public verification key and produces a view computationally indistinguishable from a real EAS view:

```text
{Sim(model_id, input_hash, S)} ≈c {model_id, input_hash, S, c, pi}
```

The statement must not include non-selected expert outputs as public inputs. Router logits may be private witness values; if a deployment intentionally publishes selected logits, that disclosure must be declared as a model policy and is not a disclosure of non-S expert outputs. The zero-knowledge property is about expert outputs, not about hiding `S`, which the EAS tuple explicitly exposes.

This definition also excludes accidental leakage through variable-length encodings, path counts, or proof branches: proof length and transcript shape are fixed by public `M` and `k`, or padded to those public bounds. Implementations must specify side-channel behavior separately; algebraic zero knowledge alone does not hide timing or memory access patterns of an unsafe prover.

## 5. Efficiency

The verifier must run in:

```text
O(|S| * poly(log M))
```

where the bound excludes one-time loading of the public verification key and model commitment. It must not scan all `M-|S|` experts or evaluate a dense router itself. Prover work may be `O(M)` for a dense router; the requirement is on verification.

## 6. Concrete construction: fixed-point router SNARK with Merkle commitment

### Setup

Choose a collision-resistant, domain-separated hash `H` (for example Poseidon inside the circuit and a specified transcript hash outside). Commit to the exact model parameters and router version as `model_id`. Compile the relation `R_EAS` into a SNARK circuit using the declared fixed-point representation. Generate a proving key and verification key for the model version; the verification key identifier is included in `model_id`.

### Prover

1. Compute `input_hash` from the canonical input.
2. Evaluate the router over the private input and fixed-point model parameters.
3. Apply the declared top-k and tie-break algorithm to obtain `S`.
4. Build a Merkle tree over a canonical activation witness. A leaf is
   `L_i = H("eas.leaf.v1" || model_id || input_hash || i || score_i || selected_i || salt_i)`.
   The root, together with `model_id`, `input_hash`, and `S`, forms `commitment_c`.
5. Produce a zero-knowledge SNARK proving knowledge of `x`, all router intermediate values, scores, salts, and Merkle openings such that the input hash, router computation, exact top-k comparison, leaf root, and public `S` all agree.
6. Return the EAS tuple. Non-selected expert outputs are never public inputs and are not included in the proof transcript.

### Verifier

The verifier checks canonical `S`, derives the public statement `(model_id,input_hash,S,c)`, and runs the SNARK verifier. It may additionally check a Merkle path for each selected expert if the implementation exposes paths as an independently checkable audit layer. The SNARK relation itself proves all non-selected comparisons, so the verifier does not enumerate non-selected experts. SNARK verification is constant or polylogarithmic in circuit size for standard succinct systems; checking `k=|S|` public indices and optional paths adds `O(|S| log M)`. Therefore the total is `O(|S| * poly(log M))`.

### Alternative transparent construction

A Merkle-only design can provide efficient inclusion proofs for selected leaves, but a naive verifier cannot establish that no unselected expert has a larger score without opening or proving all non-selected leaves. It therefore fails the stated efficiency bound for a dense router. A transparent alternative can use a Merkle commitment plus a succinct transparent STARK proving the exact top-k comparison; its verifier remains polylogarithmic, with the same public statement and privacy requirements. The plain Merkle layer alone is not claimed to satisfy exact-set efficiency.

## 7. Security assumptions

- `H` is collision resistant and domain separation is respected.
- The SNARK has knowledge soundness, completeness, and computational zero knowledge under its named system's assumptions. A Groth16 deployment requires a circuit-specific toxic-waste ceremony and its standard knowledge assumptions; a Plonk/Halo2-style deployment requires the stated polynomial-commitment assumptions and transcript Fiat–Shamir model.
- The fixed-point router circuit exactly models the declared runtime arithmetic, rounding, overflow behavior, quantization, and tie breaking. Floating-point or unspecified GPU reductions are not permitted in the soundness claim.
- The model commitment and verification key are immutable for a given `model_id`; changing either creates a new model version.
- The random oracle model is used for Fiat–Shamir where an interactive proof is made non-interactive.

## 8. Review checklist and limitations

A reviewer should check: (1) the exact five-tuple syntax; (2) the iff exact-set predicate; (3) simulation privacy for non-S expert outputs; (4) the verifier bound and whether any dense router work was incorrectly assigned to the verifier; and (5) the concrete construction and assumptions.

This specification proves routing, not model correctness, output quality, or honest model parameters. It does not hide the selected set `S`, input hash, model identity, or any policy-declared selected-expert metadata. A malicious model owner can publish a model whose routing function is undesirable; EAS only makes the declared function's activation set checkable. Recursive MoE layers require a separate commitment per layer or a composed circuit, and the public cost then scales with the total disclosed selected sets.