# Security Model ## Protected assets - model artifact、tokenizer、runtime binary/dylib/source patch の同一性 - prompt、prompt/generated token IDs、decoded output、owner key、commitment opening、audit key の秘匿性 - token count、operation schedule、canonical CU、graph/kernel trace の完全性 - scheduler request/assignment、job/execution nullifier、Receipt の一回性 - replica、audit、escrow、bond/slashing、Work Ticket の状態遷移 ## Trust and issuance boundary 単一の自己申告 Receipt は、悪意ある host に対する独立な暗号学的 proof ではない。本プロトコルは 次を組み合わせて不正コストを上げる。 - content-address された model/runtime manifest と Ed25519 scheduler/worker signature - 同一 runtime class 内の独立 credential/runtime instance による k=2 exact match - Receipt 発行後の future beacon による再実行 audit - authority-signed funding、scheduler-signed assignment lock、conserved durable bond accounting、appeal - scheduler-signed hidden precommitを期限後に開き、worker/scheduler timeoutを分離するdurable canary - transactional replay、pair、audit、bond/slash/health、maturity、WorkTicketV2、external settlement registry schema-v4 coreではこれらの多くがSQLite transactionで接続された。bonded Receipt acceptance、audit/canary slash、maturity時bond release/link、External settlementからticketまでのlocal atomicityを持つ。ただし production scheduler/auditor/authority/payment service全体をrepository内で実装したわけではない。 現行 Metal Self Local path は signed Receipt を発行できるが、evidence は `graph_fallback` であり CUDA kernel proof ではない。mature weight には future audit または challenge window が必要である。 現行CLIはscheduler/worker keyとregistry snapshotをlocalに生成するため、その出力だけからproduction scheduler authorizationやnetwork admissionを推論してはならない。 future-audit state、signed beacon provenance、audit replay、passing maturityはSQLiteへdurableに保存する。 ただしfinalized beaconの取得/governance、独立auditorへのassignment、model re-execution、private opening deliveryは外部serviceのtrust boundaryである。crate内のlocal authority registryはnetwork consensusや beacon finalityを実装しない。 CUDA code はadditive 184-byte V2 codecとstrict full-stream/dispatch/runtime binderを持つが、raw recordの declared producer originはtransport metadataであってproofではない。authority署名をnetwork/job/execution/ assignment、runtime class/manifest、producer integration、operation schedule commitment、全scheduled GEMM/attention coverage、full transcriptへbindし、producer accumulator GEMMだけをReceipt V2 evidenceへ射影するtypestateも実装した。ただしV1にはこの provenanceをcommitするfieldがないため、builderとverifierはCUDA `KernelSketch`をともに拒否する。 この署名は登録authorityによるexact transcript/integrationの承認をauthenticateするが、authorityの正しさや GPU register由来を単独で暗号学的に証明しない。 standaloneのproducer-internal FP32 accumulator採取primitiveはWSL2 Ubuntu 24.04上のRTX 4060 Ti（sm_89）、CUDA Toolkit 13.3.1 / nvcc 13.3.73で最終grouped device suite 8/8とproducer 20/20同一diagnostic fingerprintを通過した。固定Qwenも 37/37 layer CUDA offloadとgraph observer 6/6同一diagnostic streamを確認済みである。vendored llama.cppの Q4_K/Q6_K MMVQ producerはV3 full-K pre-epilogue hookへ接続済みで、same-backend 1-token diagnostic E2Eは253/253 recordを取得する。V3 schema/binderはFA-off eager attentionのcanonical groupingを表現し、 3 stageのwork直後collectorとtyped associationも接続済みである。合計361 launchを3回同一fingerprintで 取得し、5 work classの拒否を確認した。exact symbol/runtime attributes/cubin/DSO release manifest、 Receipt/RuntimeManifest/Request/Assignment V2、暗号化Bundle V2、SQLite V2も実装・検証済みである。 ただしlive callbackはauthority-derived canonical physical-layout IDではなくdiagnostic IDを使用するため、 trace/producer production capability、vendor integration、Receipt mappingの各macroは0、production CMake optionはconfigure時に失敗する。したがって R32は`In progress`だがCUDA Receiptは発行不可である。 host OS、driver、GPU firmware まで敵対的とみなす場合は、TEE attestation または ZK/VC を追加 しなければならない。この v1 はその主張を行わない。 ### Consensus 側の三本柱(node ADR-0045 D2 の反映) node 側 consensus が担う正しさの柱は次の三つで、役割は重複しない。本 crate の Receipt/audit 機構は第 1 の柱への入力であり、支払いの最終性・遡及の扱いは第 3 の柱の規律に従う。 | 柱 | 検出するもの | 効果 | 時点 | |---|---|---|---| | Audit rounds | 標本化された leaf の再検証不一致 | certificate 拒否(事前)/ FraudEvidence(事後) | batch lifecycle 内 | | PCPB | ticket と provider の束縛偽装(委譲・横流し) | ticket 無効 = mint 不能(事前) | mint 時 | | Fraud + slash | 事後に発覚した不正(withhold、虚偽 receipt) | Revoked(**非遡及**)+ bond slash(遡及的担保) | いつでも | Revoked の非遡及は node 側 SS-04 で確定済み(coinbase 済み provider 支払いは UTXO model 上 巻き戻せない;事後抑止は bond slash が担う)。単一 self-reported Receipt が独立証明でないという 本書の宣言を consensus 側も正とし、参照は双方向に固定される(node `docs/adr/0045`)。 ## Threat controls | Threat | Primary controls | Fail condition | |---|---|---| | Fake token count | pinned runtime tokenizer IDs、prefill/decode graph step consistency、opening、audit | count/token vector/phase step が不一致 | | Fake runtime | model/binary/dylib/source/build/host digest、manifest ID、allowlist | digest、class、実行前後 manifest が不一致 | | Fake output | salted output commitment、signed shared nonce、replica/audit opening | nonce、token、stop reason、再実行 output が不一致 | | Replay | domain-separated job/execution nullifier、SQLite unique constraint | receipt/nullifier/job slot が既に受理済み | | Forked runtime | manifest digest、signed assignment、canary、independent runtime instance | 未許可 digest、credential/instance 重複、canary failure | | Dummy execution | strict non-empty event stream、full event/token coverage、trace、replica/audit | event 欠落、unknown op、required evidence 不足 | | Schedule rewrite | ordered hash chain、event count、CU、Receipt signature | reorder/insert/delete/shape mutation で chain または CU 不一致 | | Receipt duplication | receipt/execution/job-slot uniqueness、pair/ticket one-shot state | duplicate accept、pair reuse、二重 ticket 化 | | Trace forgery | manifest capability、strict graph claim、trace root/count、replica/audit | CUDA claim、scheme、root、count、tile metadata が不一致 | | Secret leakage | stdin child pipe、output-byte omission、private opening schema、pre-write scan | canonical Receipt に prompt/token/key/nonce/salt bytes が出現 | | Bundle substitution | receipt/public/AAD binding、XChaCha20-Poly1305 tag、strict decode | receipt/bundle/public digest、nonce、tagが不一致 | | Incomplete output set | checkpoint/fsync、marker-last、core JSON field cross-check | marker欠落・ID/hash不一致（marker自体はunkeyedでauthenticity controlではない） | | Local trust escalation | DB exact restoreとexternal anchored stateless pathの分離 | embedded key snapshotだけで第三者authorityを主張 | | CUDA async failure | permanent poison、committed-count barrier、production gate | poisoned/pending/overflow context または非発行 capability | | External funding/weight forgery | network-scoped authority capability、signed exact funding/grant、canonical replay ID | key/network/asset/amount/grant/epoch/signature不一致 | | External double settlement | stable payment command、signed terminal confirmation、single durable terminal | command/distribution/pair/amount/epoch不一致、逆terminal、conflicting replay | | Canary false slash | scheduler-signed precommit、atomic receipt acceptance、fault-party timeout attribution | precommit/request/assignment/window不一致、opening未到達、scheduler opening timeout | | Bond funding/slash replay | signed funding event、typed primary proof、conservation reconciliation、appeal state | event/offense/canonical payload conflict、account/assignment/evidence不一致 | | Dependency/MSRV drift | exact crypto pins、lockfile、Rust 1.85 all-target CI | lock変更、MSRV manifest parse失敗、lint/test failure | | Premature Work Ticket | opaque maturity basis、required bond release links、WorkTicketV2、atomic one-shot issue | raw claim、epoch前倒し、bond link不足、grant不一致、source再消費 | ## Cryptographic rules - hash は SHA3-256 とし、用途ごとの domain separation と version を必須にする。 - 可変長 field は canonical length-prefix し、曖昧な連結を禁止する。 - Receipt、manifest、request、assignment、future beacon、canary precommit、bond/external authority evidence、verification bundle はstrict versioned canonical formだけを署名・hash/AEAD binding対象にする。 - output nonce、owner salt、private key seed は OS CSPRNG から 32 bytes 生成し、zero を拒否する。 - replica 用 output nonce は scheduler-signed request で共通指定し、worker による差し替えを防ぐ。 - prompt commitment も signed shared nonce、network、job、runtime tokenizer IDs に binding する。 - key ID、algorithmと署名をenvelopeに明記し、public keyはregistryから解決する。Receipt、scheduler message、future beacon、canary precommit、bond/external authorityのEd25519検証は`verify_strict`を使い、 small-order/weak public keyを各registryへの登録時と検証時に拒否する。bond authorityはfunding/appeal/ decision、external authorityはfunding/demand-weight/terminalのcapabilityを分離する。 - verification bundle はXChaCha20-Poly1305（256-bit derived key、192-bit random nonce、128-bit tag）を 使い、receipt binding、public digest、nonce、canonical public sectionをAADへbindする。caller-owned raw audit keyとprivate signing-key seedはbundleへserializeしない。 - replay/cardinality/terminal transition は process-local set ではなく durable transaction で確定する。 - MSRV gate、Clippy、test、release build は committed lockfile を使い、open transitive range が toolchain 非互換 manifest を silent に選ばないようにする。 ## Privacy rules canonical Receipt と公開 JSON に prompt、raw output、prompt/generated token IDs、owner public key、 output nonce、owner salt、private key、accumulator 全体を含めない。公開 JSON は commitment、digest、 non-secret identifier/counter/protocol label、CU、artifact/observer summary、filename、privacy flagを記録する。 後述のlocal verifierがsemanticに照合するのはその一部である。 Receipt CLI は必須の `--prompt-stdin` を使い、UTF-8/非空/1 MiB 上限を inference 前に検査する。 `--prompt TEXT` は廃止され、unknown optionとして拒否する。CLIはさらに `--audit-key-file` を必須とし、 exact 32-byte nonzero key、owner、single link、regular-file、mode `0400`/`0600`、symlink/path race/inode alias/output directory内配置をfail-closedに検査する。 Rust adapter は prompt を tokenizer/native child argv、stderr、error text に置かず専用 stdin pipe で渡す。通常の Receipt 実行は native observer の `--emit-output-bytes` を使わないため decoded output bytes は IPC result にも含まれない。ただし native JSONL は wrapper 内部で prompt/generated token IDs を opening として運ぶため、この local pipe と process memory は trusted privacy boundary である。debug QA で output bytes を明示的に有効化した stream を公開 ログへ流してはならない。 verification bundleのpublic sectionにはreceipt binding/ID、verification epoch、scheduler public-key snapshot、manifest、execution evidenceを置く。worker public keyを含むsigner record、signed request/assignment、output nonce、prompt/generated token IDs、stop reason、owner saltはencrypted private sectionだけに置く。private signing-key seedとaudit keyはoutput artifactへ保持/serializeしない。CLI はcanonical bytesの strict round-tripとprompt/token/key/nonce/salt scanを通過してからだけ`create_new`で書く。audit keyの rotation/backup、bundle/openingのretention/deletionはcallerの運用責任で、このcrateに自動retention policy はない。 tokenizer、observer、host/source identity helperは inherited environment を消去し、`LANG=C` と `LC_ALL=C`だけを設定する。このallowlistはmanifestへbindされ、host identity helperはabsolute pathで 起動する。ただしsame-user debugger、process memory reader、malicious host kernelからlocal openingや audit keyを保護するattestationは提供しない。 ## Durable-state rules SQLite store は WAL、`synchronous=FULL`、foreign key、application ID、schema version 4を検証する。 table/column/foreign-key/index集合に加え、non-internal `sqlite_master` の完全な `(type,name,tbl_name,sql)`列をcanonical SHA3-256 fingerprintで照合する。旧schemaをsilent migrateせず、 既存objectを持つunclaimed DBも拒否する。Receipt ID、execution nullifier、job/replica slot、pair membership、future audit/replay、bond funding/account/assignment/release/slash/appeal/health、signed canary、 maturity source/assignment link、Work Ticket v2、external escrow/payment command/terminalをunique constraintと transactionで守る。 raw maturity flag を受ける public store API は持たない。original receiptの`accepted_at_epoch`、pairの `matched_epoch`、signed beaconのclaimed epoch/key ID/canonical envelope、audit replayのissued/accepted epochを保存し、epoch rollbackを拒否する。beaconを検証したcaller current epochは保存せず、restore時に current `AcceptedReceipt.verified_at_epoch`とauthority registryから再確立する。selected auditは audit-specific replay identityの一回予約、typed projection verdict、terminal state、passing maturity sourceを同一transactionで確定し、non-selected auditもwindow maturityとsource登録を同一transactionで確定する。bond rowがあるaudit pathとSelf Replicated pathはmaturityと同じtransactionでrequired assignment bondをrelease/linkする。Work Ticketは その`mature_epoch`より前には発行できず、job classに必要なrelease link数を満たすsourceだけを一度消費する。 bond fundingはauthority-verified typestateだけをcreditし、funding event ledgerとaccount buckets、active assignment remaining、pending/finalized slash、healthをread/transition時にreconcileする。lockはexact scheduler-signed assignmentにbindする。bonded assignmentのReceiptをgeneric `accept`で受けず、 `accept_bonded`または`accept_canary`のatomic pathを要求する。audit mismatch/timeoutとcanary mismatch/ receipt timeoutはtransition自身からtyped primary proofを作り、slash accountingを同じtransactionに含める。 各claimはinitial bond基準のimmutable targetを持ち、finalized max-envelopeを優先してpending extensionだけを allocateする。overlapを加算せず、equal/weaker/strongerの到着順やreverse後にも全claimから再計算する。 v1のEquivocation追加penaltyは0である。 authority-verified appealはpending offense/worker/assignment/deadlineへexact bindする。signed submissionと appeal verification/acceptance epochをappeal window内に要求し、decision windowは後者から開始する。signed decision epochとdecision verification/acceptance epochもdeadline内でなければならない。期限経過後は default-uphold、appealがなければappeal deadline後のfinalizationだけを認める。exact canonical replayは idempotent、同じbusiness IDのconflicting payloadはfatalである。 pendingまたはuphold/default-final claimを持つassignmentからmaturity/ticketを生成しない。全claim解決後、 audit mismatch/timeout terminalはclaim reversal時も残額を`SlashResolved` releaseする。canary fault terminalはmatching claimがuphold/default-finalの場合だけreleaseでき、reversed canary claim単独では解放しない。External refundもrelease terminalであり、state 1..3からexpiry後にpairの 有無を問わず確定できる。eligible bond残額はrefund terminalでreleaseするが、pending claimを持つbondは解決まで lockedに残す。expiry releaseは未使用またはaccepted-unpaired SelfReplicatedだけを許し、pending canary/slash、paired、Self Local、その他used assignmentを拒否する。`fault_event_epoch`とdurable `applied_epoch`を分離し、terminal epoch/proofは offense-sortedな完全claim/terminal fact setとmax effective epochからcanonicalに導出する。 scheduler-signed canary precommitはactive lockとcanonical envelopeを保存する。normal Receipt insertと `ReceiptSubmitted`はatomicである。pass terminal、mismatch/slash、receipt-missing worker slash、opening- missing scheduler fault/no-worker-slashをそれぞれ一transactionで確定する。passとopening-missingはbondを releaseせず、pending canary中のmaturityを拒否する。terminal後のmature epochをcanary completion以後へ 遅延し、maturity transactionだけが`Mature` release/linkを行う。 External settlementはauthority-verified funding/grant、scheduler request、k=2 pair、stable command、signed terminal confirmationを順にbindする。settlement confirmationはterminal、maturity、両worker bond release/ link、WorkTicketV2を一SQLite transactionでcommitする。refundはterminalとeligible bond releaseをatomicに commitするが、maturity/ticketを生成せず、pending claimのbondは解決までreleaseしない。 `SettlementPrepared` transitionは両bondがactiveでpending/upheld/default-final slashなしと同じtransactionで preflightする。`SettlementPrepared`または`RefundPrepared`以後のnon-replay slashを拒否する。 restartでは`restore_audit`がselected pass/mismatch terminalを`AuditReplayRequired`で拒否する。 `restore_selected_audit_with_replay`だけがstored challenge/canonical replayと全identity/epochを再照合し、 再計算したmatch bit、submission commitment、completed epochをdurable terminalへexact比較する。 DB file の possession は signer authorization を代替しない。受理前の stateless verifier が署名、 request/assignment、manifest/evidence/opening を検証し、その typestate と canonical bytes だけを store へ渡す。 発行時はowned non-symlink output directoryを`0700`に固定し、Receipt/公開JSON/completion markerを `0644`、暗号化bundle/DBを`0600`にする。DBはWAL `TRUNCATE` checkpoint、connection drop、main-file `fsync`を完了してからpublic artifactsを書き、各fileを`fsync`した後にmarkerを最後に作ってdirectoryを `fsync`する。marker v2はreceipt ID、bundle ID、公開JSON SHA-256を記録する。これはcross-file atomic renameではないためlate failureでpartial setは残り得るが、local verifierは全protected artifactの same-directory/expected filename/mode/owner/type/link count、exact marker、typed公開JSON `misaka.palw.public-receipt.v2`全体がsigned Receiptと authenticated bundle manifest/evidenceへ一致しないsetを拒否する。unknown fieldも全階層で拒否する。 markerはunkeyed plain textでsignature/AEAD protectionを持たず、same-owner writerは公開JSONとmarkerを 一緒に置換できる。しかしverifierは保持する`artifacts`と`observer_summary`を含むtyped文書全体を authenticated dataから再構成してexact照合するため、markerを書き直しても改変JSONは受理されない。 marker/JSONはcompletenessとhuman-readable projectionのboundaryであり、canonical Receiptとauthenticated bundleのauthorityを代替しない。 `verify_bundle_and_restore`はembedded snapshotsで再検証した後、既存DB rowへのexact continuityだけを 認め、missing rowをinsertしない。第三者用`verify_bundle_stateless_with_trust`は外部scheduler/signer registry、expected network、approved manifest hashを必須とし、embedded snapshotをauthorityにしない。 後者はbundle-bound historical `verification_epoch`でのstateless verificationであり、present-time network acceptanceやdurable replay reservationではない。 fresh APIはcaller-selected epochがbundleのhistorical verification epoch以上であることを要求する。 `verify_bundle_and_restore_at_epoch`はlocal embedded snapshotsでfresh `AcceptedReceipt`を作りoriginal durable acceptance epochを保持するが、bundle作成後のrevocationは学習できない。 `verify_bundle_stateless_at_epoch_with_trust`はexternal rootsでfresh stateless typestateを作るがDB continuityを 検査しない。production restartではcurrent external rootsと既存DB rowを同時に検査する `verify_bundle_and_restore_at_epoch_with_trust`を使う。future audit restoreではepochをbeacon以上にし、 present-time network admissionは別途判断する。現行CLIはhistorical default restoreだけを呼び、fresh epochは library/service APIで指定する。 ## Residual risks - greedy decode でも driver/kernel/toolchain 差により bitwise output が変わり得る。 - Metal graph-level logical-prefix sketch は lossy で、CUDA kernel/accumulator trace より弱い。 - observer callback の read-only access は timing と synchronization を変え得る。 - k=2 replica が同一所有者・同一障害 domain なら共謀耐性がない。 - external registry/finality serviceが供給するfuture beaconが予測・操作可能ならaudit samplingが弱くなる。 - auditor scheduling、model re-execution、opening deliveryはcrate外であり、durable audit stateだけでは independent replayの運用を保証しない。 - bond/external authority registryのproduction governance、key distribution、revocation deliveryはcrate外で、 同梱in-memory registryはnetwork consensusではない。 - signed funding/terminal evidenceはauthorityのstatementをauthenticateするが、実collateralやpayment railを crateが独立観測したproofではない。rail movementとlocal SQLite commitはdistributed atomicではない。 - External `SettlementPrepared`/`RefundPrepared`後にauthority confirmationが来ない場合のtimeoutや superseding terminalはなく、prepared stateのoperational recoveryは外部serviceに依存する。 - durable canaryはscheduler opening欠落をscheduler faultとしてworker slashから分離するが、production schedulerのprecommit/opening deliveryとavailabilityはcrate外である。 - durable slashへ自動接続済みなのはaudit mismatch/timeoutとcanary mismatch/receipt timeoutである。 invalid-manifest、equivocation、duplicate-executionのproduction typed proof/orchestrationは未統合である。 - legacy in-memory `BondLedger`、`CanaryRecord`、`ExternalEscrow` helperはraw caller mutationを許すため、 schema-v4 signed/durable authority pathの代用にしてはならない。 - `future_audits.state=4`はpublic transitionではdeadlineを保持するが、SQL constraint単独では `deadline_epoch NOT NULL`を要求しない。constraint-validなDB corruptionはload/release時にfail closedとなるが、 schema-level hardening余地が残る。 - CU table は実時間・電力を表さず、versioned governance の対象である。 - encrypted bundleはaudit keyを取得したsame-user/malicious hostからopeningを守らず、key backup/rotation/ retentionも自動化しない。 - CI workflowやRTX実機でのvendored MMVQ diagnostic hook/E2E成功も、FA-off attentionの361-launch実機coverage、 production-approved kernel manifest identity、authority-bound full-stream verification、Receipt V2を代替せず、 R32 production acceptance authorityを与えない。 production scheduler/network transport、governance key distribution、beacon/authority service、payment rail、 NVIDIA CUDAのfull production issuance pathも未統合である。 これらは runtime class 分離、independent identity、future beacon finality、versioned CU policy、 bond/slashing、source統合済みFA-off attention hookの実機full-stream検証、release manifest authorityと attestation/proof layerで緩和する。