Code RoomVerifiable model execution
FrontierPrep Room Coding #4980

Verifiable model execution

CodingML systemsSenior–Staff~80 min

An answer your service produced is now the subject of a claim, and the party asking is under no obligation to believe you. They want one specific thing established: that the answer came from the model version you published a card for, and not from a cheaper substitute, a different quantization, or a router hop into a smaller model at a busy moment. Your weights are confidential and stay that way.

Design the protocol.

Handing over the weights is off the table, including handing them to an escrow the verifier is then simply told to trust. Re execution by the verifier is therefore off the table too. A hardware root of trust may be a component and may not be the answer: if you use attestation, enumerate what the measurement covers, what it does not, which weights were loaded after it, which party the verifier is now trusting, and what happens the day a vendor key is revoked. Output watermarking may be a signal and is not the mechanism. Nothing here turns on recomputing the answer to the last bit on a second machine, which is a different problem and not the one being asked.

Start by writing the claim predicate. It is harder than it looks. Decoding is sampled, the stack holds a cache and a draft model for speculation, and an honest system can return two different answers to one prompt.

Hand in the predicate, the protocol with its roles and messages and what each party holds, a soundness argument that names the cheating strategy your protocol still permits and what that strategy costs the cheater, the cost in prover overhead and verifier work as a function of parameter count and sequence length, and your position on coverage: whether every request is proven or a sampled subset is, and precisely what a sampled protocol asserts about the requests it did not cover. Ties break toward the narrow claim with a real soundness argument.

What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

0:00 of about 80 min
InputExpectedGot