The parties

Two parties. The server holds a fine-tuned model and does not want to ship the weights. The client holds an input -- a sentence, a medical record, a prompt -- and does not want the server to see it. They run a protocol whose ideal functionality is: the client learns $M(w, x)$, and neither party learns anything else. Iron, BOLT, CipherGPT and Nimbus all implement some version of this. Bootstrapping is All You Need implements something adjacent, which we get to below.

Assumption 1: the adversary is semi-honest

Every 2PC system in this section -- Iron, BOLT, CipherGPT and Nimbus -- is proved secure against a semi-honest (honest-but-curious) adversary. This is the single most load-bearing sentence on the page. (Bootstrapping is All You Need states no adversary model at all; see below.)

Same as prior works [14, 17], we consider an honest-but-curious adversary that passively corrupts either the server or the client, but not both. Such an adversary follows the protocol specification exactly, but may try to learn more information than allowed (e.g., the model's weights or inference inputs) via analyzing the data it receives.

Iron · §2.1, Threat Model

Nimbus and BOLT state the same assumption, and BOLT is unusually candid about why: the parties have to trust each other to some extent because the server is providing the inference service, and semi-honest performance is much more practical. Both halves of that are honest, and both are worth taking seriously rather than dismissing. But the consequence is unambiguous. A server that deviates from the protocol is outside the model. It can compute a different function, return garbage, return a competitor's cheaper model's answer, or run a backdoored set of weights, and the protocol has no opinion. The client's privacy still holds. Its answer does not.

Note the asymmetry that this creates in practice: the party with the incentive to cheat (the server, which is paid per query and wants to serve a smaller model) is the party the threat model declines to constrain.

Assumption 2: the architecture is public

The weights are secret. The shape of the model is not.

As in all prior two-party inference protocols, the client is only allowed to learn the model's architecture and inference result while the server gains no information about the client's input.

Nimbus · §2.1, Threat Model

BOLT spells out how far this goes -- both parties know the parameter scales and the dimensions of every layer, and in its BERT setting the tokenizer is frozen and public as well:

BOLT assumes that the model architecture is known to both parties. As is standard in all secure computation protocols, we also do not aim to hide leakage of the inference result.

BOLT · §3, Threat Model

This has two consequences that matter for an SoK.

First, the protocol itself is a function of the architecture. Layer dimensions determine the packing, the ciphertext parameters, and the communication pattern. "Hiding the architecture" is not a knob you can turn later.

Second -- and this is the interesting one -- the privacy column makes the architecture public while hiding the weights, which is structurally the same split the verifiability column may need in order to stay clear of the Fiat--Shamir/GKR attack's precondition (see proof systems; the mitigation is to pin the circuit rather than only the weights, which is what zkAudit does). Whether that is sufficient has not been analysed on either side. The two columns have converged on the same public/private split from opposite directions, and neither cites the other for it.

Assumption 3: the output leaks, by construction

Both BOLT and Iron state that they do not attempt to hide what can be inferred from the inference result itself, and both point at differential privacy as the orthogonal tool for that. This is correct and unavoidable -- the result has to be useful to somebody -- but it means model extraction and membership inference against the served model are entirely out of scope. A client who queries a private-inference service repeatedly learns whatever a client querying a plaintext API learns. 2PC protects the individual query, not the model.

Assumption 4: the "client" is not a phone

The word "client" imports an intuition (a laptop, a browser, a handset) that does not survive contact with these protocols. Nimbus states the real deployment requirement outright, in the course of arguing that its own design is not making things worse:

Due to the symmetric-computation characteristic of MPC as well as the expensive NTT cost brought about by homomorphic encryption and decryption, existing secure-inference frameworks, e.g., [17, 14, 5, 26, 29, 42], require the client to be equipped with similar resources as the server, including a powerful CPU (e.g., 64 vCPUs) and a large memory (e.g., 128 GB) [42, 26, 29].

Nimbus · §3.3, Memory Impact of the COP Protocol

Nimbus additionally has the server ship the encrypted weights to the client during a setup phase, so the client must also store an encrypted copy of the entire model on disk and stream it in as the layers are consumed. Whatever else this is, it is not an edge deployment. The realistic picture of 2PC private inference is two datacenter machines that distrust each other, connected by a network the paper gets to choose -- which is where the cost model page picks the story up.

The FHE row is a different game

Bootstrapping is All You Need does not fit any of the above, and benchmarking it head-to-head against the 2PC systems is a category error. It calls its setting NISTI -- Non-Interactive Secure Transformer Inference. The client encrypts its input under CKKS, sends it, and leaves. The server evaluates the whole transformer homomorphically on ciphertext it can never read, and returns a ciphertext the client decrypts.

The last row is the one people get wrong. FHE does not make the server honest; it makes it blind. A NISTI server can return an encryption of anything it likes, and the client will decrypt it and believe it. The correctness gap is exactly as wide as in the 2PC systems -- arguably wider, because there is no interaction in which anything could be checked. Bootstrapping is All You Need's own framing of the interactive alternatives is about cost, not trust:

In general, these interactive approaches suffer from high communication overhead and require continuous client presence during inference.

Bootstrapping is All You Need · §7, Related Work

Summary

The last row is the same in every column, and it is the row this section exists to make visible.