Hugging Face's logo

Misakachain
/
Qwen3.6-35B-A3B-PALW-runtime

GGUF
English
Japanese
misaka-palw
misaka
palw
proof-of-compute
deterministic-inference
integer-quantization
conversational
Model card Files
xet
 Community
Qwen3.6-35B-A3B-PALW-runtime / docs /protocol-v1.md
Misakachain's picture
Misakachain
Initial import: PALW proof-of-compute runtime for Qwen3.6-35B-A3B (code + docs, no model weights)
0985c38 verified
preview code
|
Raw
History Blame Contribute Delete
49.3 kB

MISAKA PALW Receipt Protocol V1

本書は runtime-palw の現行 Rust 実装を wire protocol の正本として記述する。ここにない production 承認、決済連携、attestation を Receipt から推論してはならない。実装と本書が 一致しない場合は Receipt を発行しない。

1. Primitive types

  • Hash32、commitment、ID、NetworkId: 固定 32 byte
  • u16 / u32 / u64 / i64: big endian。i64 は two's-complement
  • bool: u8(0) または u8(1)
  • enum: variant tag u8 の後に variant 固有 payload
  • Ed25519 public key: 32 byte、signature: 64 byte、algorithm tag: 0
  • Option<T>: u8(0)、または u8(1) || encode(T)

NetworkId は UTF-8 名ではなく Hash32 である。consensus encoding へ usize、float、map、 JSON text、platform enum、暗黙の default を直接入れない。

Receipt、scheduler message、future beacon、canary precommit、bond/external authority evidenceのEd25519 verificationはverify_strictを使う。small-order/weak public keyはworker signer、scheduler、beacon、bond、 external authorityのregistry recordとして拒否し、key IDが一致してもauthorization identityとして扱わない。

2. Canonical encoding 

LP(x)       = u64be(len(x)) || x
bytes(x)    = LP(x)
string(s)   = LP(utf8(s))
vector(xs)  = u64be(count(xs)) || encode(xs[0]) || ...

固定長 hash は LP を付けず 32 byte を直接書く。struct は本書に記した順で field を連結する。 decoder は未知の version/tag、truncated/trailing bytes、invalid UTF-8、非canonical bool/option、 上限超過を拒否し、decode 後の再encodeが入力と一致しなければ拒否する。現行 reader の blob 上限は 64 MiB、item count 上限は 16,777,216 である。

3. Domain-separated hash 

H(tag, part_0, ..., part_n) = SHA3-256(
    LP("MISAKA/PALW") ||
    LP(utf8(tag)) ||
    u16be(schema_version) ||
    LP(part_0) || ... || LP(part_n)
)

part count 自体は入らないが、すべての part が LP されるため partition は曖昧にならない。 raw concatenation と domain の流用は禁止する。core V1 が使用する domain は次のとおり。

model-artifact-leaf/v1    model-artifact-node/v1
model-profile/v1          runtime-class/v1          runtime-manifest/v1
shape-profile/v1          cu-ruleset/v1
job-request/v1            assignment/v1             signer-key/v1
prompt/v1                 output/v1                 owner/v1
job-nullifier/v1          execution-nullifier/v1
schedule-init/v1          schedule-step/v1           schedule-final/v1
gemm-trace-scheme/v1      gemm-trace-init/v1         gemm-trace-step/v1
gemm-trace-final/v1
receipt-body/v1           receipt-id/v1              receipt-signature/v1
replica-match/v1          pair-id/v1
future-beacon/v1          audit-policy/v1
audit-selection/v1        audit-challenge/v1
audit-replay-result/v1    audit-replay-submission/v1
work-ticket/v2            local-maturity-basis/v2    canary/v1
canary-precommit/v1       durable-slash-offense/v2   bond-release/v1
bond-funding-attestation/v1  slash-appeal/v1         slash-decision/v1
slash-default-uphold/v1   external-escrow/v1         external-payment-command/v1
external-funding-attestation/v1  external-demand-weight-grant/v1
external-terminal-confirmation/v1
llama-cuda-dispatch/v1    cuda-kernel-entry/v1
verification-bundle-receipt/v1   verification-bundle-public/v1
verification-bundle-aad/v1       verification-bundle-aead-key/v1
verification-bundle-id/v1

request/v1 は generic helper commit_request に残るが、署名済み JobRequestV1 の ID には 使用しない。job request の唯一の domain は job-request/v1 である。deterministic policy と Qwen Metal profile はさらに lora-set/v1、control-vector-set/v1、 thinking-policy/v1、workspace-policy/v1、thread-policy/v1、 qwen-native-observer-mapping/v1 等の artifact domain を runtime identity の内側で使う。

4. Artifact and model identity

artifact は slash-separated relative path の辞書順で処理する。空、absolute、末尾 /、空要素、 .、..、backslash、非UTF-8、重複、symlink、非regular file は拒否する。

leaf_i = H(
    "model-artifact-leaf/v1",
    utf8(relative_path_i),
    u64be(file_size_i),
    file_bytes_i
)

file は streaming hash するが上式と同じ framing である。各 level の leaf/node が奇数なら 末尾を複製し、H("model-artifact-node/v1", left, right) で二分木を作る。artifact は空に できない。

ModelProfile canonical order:

  1. architecture: string
  2. base_repository: string
  3. immutable_revision: string
  4. topology: u8 (0=Dense, 1=MixtureOfExperts)
  5. tokenizer: string
  6. weight_artifact_root: Hash32
  7. tokenizer_artifact_root: Hash32
  8. chat_template_digest: Hash32
  9. special_tokens_digest: Hash32
  10. hidden_size: u32
  11. attention_heads: u32
  12. kv_heads: u32
  13. head_dim: u32
  14. layer_count: u32
  15. intermediate_size: u32
  16. rope: string
  17. rope_theta: u64
  18. rope_scaling_millionths: u64
  19. native_context_tokens: u32
  20. vocabulary: u32
  21. precision: string
model_profile_id = H("model-profile/v1", encode(ModelProfile))

全 string、artifact hash、次元、RoPE integer parameter は nonzero/nonempty でなければならない。 hidden_size / attention_heads == head_dim、attention_heads % kv_heads == 0 も検査する。 Q4 GGUF は fixed inference artifact であり、学習済み base revision と量子化 artifact の双方を profile に bind する。

5. Runtime class, deterministic policy, and manifest

BackendKind canonical encoding:

  • 0=CUDA: cuda_version, driver_version, cublas_version, sm_architecture（各 string）、 cublas_policy_digest: Hash32
  • 1=Metal: metal_version, driver_build, gpu_family, language_version（各 string）、 metallib_digest: Hash32
  • 2=CPU: isa_class, blas_version（各 string）、affinity_policy_digest: Hash32

TraceCapability: 0=None, 1=GraphFallback, 2=KernelSketch。

RuntimeClass canonical order:

  1. backend: BackendKind
  2. runtime_version: string
  3. runtime_source_repository: string
  4. runtime_source_commit: string
  5. runtime_binary_digest: Hash32
  6. dirty_patch_digest: Hash32
  7. operating_system: string
  8. host_architecture: string
  9. device_class: string
  10. accelerator_api: string
  11. compiler_version: string
  12. build_flags_digest: Hash32
  13. kernel_binary_digest: Hash32
  14. kernel_algorithm_digest: Hash32
  15. accelerator_count: u32
  16. tensor_parallel: u32
  17. split_policy: string
  18. quantization: string
  19. kv_cache_precision: string
  20. flash_attention: bool
  21. tensor_repack: bool
  22. context_size: u32
  23. batch_size: u32
  24. micro_batch_size: u32
  25. thread_count: u32
  26. trace_capability: TraceCapability
  27. deterministic_policy: DeterministicPolicy

DeterministicPolicy の nested canonical order は temperature_millionths:u32, top_p_millionths:u32, top_k:u32, batch_size:u32, tensor_parallel:u32, parallel_sequences:u32, context_shift_enabled:bool, speculative_decoding_enabled:bool, dynamic_fit_enabled:bool, random_seed:u64, kernel_graph_id:Hash32, quantization_artifact_id:Hash32, lora_adapters_digest:Hash32, control_vectors_digest:Hash32, thinking_policy_digest:Hash32, workspace_policy_digest:Hash32, thread_policy_digest:Hash32 である。

V1 strict policy は temperature 0、top-p 1,000,000、top-k 0、batch/tensor-parallel/ parallel-sequences各1、context shift/speculative/dynamic fit無効を要求する。

runtime_class_id = H("runtime-class/v1", encode(RuntimeClass))

Qwen Metal profile の kernel_graph_id は pinned llama.cpp commit、 qwen_adapter_mapping_id_v1()、native graph variant、prefill/decode serialization policyを まとめて hash する。したがって graph-to-CU mapping の変更も runtime class を変更する。

ShapeProfile canonical order は batch_size:u32, max_context_tokens:u32, max_decode_tokens:u32, max_prefill_tokens:u32。batch は1、各上限は nonzero、prefill/decode 各上限は context 以下とする。

RuntimeManifest canonical order:

  1. manifest_version: u16 (=1)
  2. model_profile: ModelProfile
  3. runtime_class: RuntimeClass
  4. shape_profile: ShapeProfile
  5. model_artifact_digest: Hash32
  6. model_artifact_size: u64
  7. runtime_device_digest: Hash32
  8. loaded_libraries_digest: Hash32
  9. environment_allowlist_digest: Hash32
  10. build_provenance_digest: Hash32
  11. schedule_schema_version: u16 (=1)
  12. trace_schema_version: u16 (=1)
  13. cu_ruleset_id: Hash32
  14. trace_scheme_id: Hash32

model_artifact_digest == model_profile.weight_artifact_root、batch/context、CU ruleset を相互検査し、 runtime_manifest_hash = H("runtime-manifest/v1", encode(RuntimeManifest)) とする。

現行Qwen Metal issuanceはtokenizer、observer、host/source identity childのinherited environmentを消去し、 LANG=C、LC_ALL=Cだけを設定する。host/source identity helperはabsolute executable pathを使い、この exact mapをenvironment_allowlist_digestへbindする。親processの追加environmentはcompute childへ継承しない。

6. Scheduler-signed request and assignment

JobClass: 0=SelfLocal, 1=SelfReplicated, 2=ExternalReplicated。 EvidenceLevel: 0=Wrapper, 1=RuntimeObserved, 2=GemmTraced。replicated class は GemmTraced を要求する。

ExecutionConstraintsV1 order:

  1. model_profile_id: Hash32
  2. runtime_class_id: Hash32
  3. shape_profile_id: Hash32

JobRequestV1 canonical order:

  1. version: u16 (=1)
  2. network_id: Hash32
  3. scheduler_job_id: Hash32
  4. job_class: JobClass
  5. prompt_commitment: Hash32
  6. shared_output_nonce: Hash32
  7. constraints: ExecutionConstraintsV1
  8. required_evidence_level: EvidenceLevel
  9. issued_epoch: u64
  10. expires_epoch: u64
  11. external_escrow_reference: Option<Hash32>

ExternalReplicated は nonzero escrow reference が必須、それ以外は None が必須。

request_commitment = H("job-request/v1", encode(JobRequestV1))

AssignmentV1 canonical order:

  1. version: u16 (=1)
  2. network_id: Hash32
  3. request_commitment: Hash32
  4. scheduler_job_id: Hash32
  5. job_class: JobClass
  6. replica_slot: u8
  7. worker_credential_id: Hash32
  8. runtime_instance_id: Hash32
  9. assignment_id: Hash32
  10. issued_epoch: u64
  11. expires_epoch: u64
assignment_commitment = H("assignment/v1", encode(AssignmentV1))

assignment は network/request/job/class を request と一致させ、validity interval を request 内へ 包含させる。Self Local は slot 0、replicated は slot 0/1 のみ。

request/assignment envelope は同じ orderを使う。

u16be(envelope_version=1) ||
LP(canonical_body) ||
scheduler_key_id:Hash32 ||
u8(signature_algorithm=0) ||
signature:64-byte

signature message はそれぞれ request_commitment / assignment_commitment そのもの。 scheduler_key_id = H("signer-key/v1", scheduler_public_key)。network-scoped registry は key の valid-from/through、revocation、message epoch、weak-key rejectionを検査し、signatureはstrict Ed25519で 検証する。miner が job ID、nonce、slot、assignment IDを自己生成したものは authorization record に ならない。現行local Receipt CLIが自己生成するscheduler key/snapshotはfixture boundaryであり、 production scheduler/governance authorizationを表さない。

7. Prompt, output, owner, and nullifiers

prompt text は commit しない。tokenizerの正確な prompt token列を次で commit する。

PromptTokens = u64be(count) || concat(u32be(token_id_i))
prompt_commitment = H(
    "prompt/v1", network_id, scheduler_job_id,
    shared_output_nonce, PromptTokens
)

StopReason:

  • 0=EndOfSequence(u32 eos_token_id)
  • 1=LengthLimit
  • 2=ContextLimit
  • 3=StopSequence(Hash32 stop_sequence_digest)

Cancelled variant は存在しない。cancelled execution から Receipt を発行しない。現行request schemaにはstop-sequence list fieldがないため、StopSequence digestが特定requestの設定へbindして いるかをverifierが別途検査する実装もまだない。

CanonicalOutput =
    u64be(token_count) || concat(u32be(generated_token_id_i)) || encode(stop_reason)

output_commitment = H(
    "output/v1", network_id, job_nullifier,
    shared_output_nonce, CanonicalOutput
)

k=2 の両slotは signed request の同じ nonceを使う。nonce、prompt IDs、output IDs、owner salt は Receipt bodyへ載せず、stateless verifier への private opening とする。

owner_commitment = H(
    "owner/v1", network_id, owner_salt, owner_ed25519_public_key
)

signer_key_id = H("signer-key/v1", owner_ed25519_public_key)

job_nullifier = H(
    "job-nullifier/v1", network_id, scheduler_job_id,
    request_commitment, u8(job_class)
)

execution_nullifier = H(
    "execution-nullifier/v1", job_nullifier, assignment_id,
    u8(replica_slot), worker_credential_id, runtime_instance_id
)

owner commitment に worker credential は含めない。registry の SignerRecord が public key、 owner commitment、worker credential の対応を供給する。owner salt は registry recordにも含めない。

8. Canonical operations and CU

DType: 0=Fp32, 1=Fp16, 2=Bf16, 3=Int8, 4=Int4。 QuantizationClass: 0=None, 1=Q4K, 2=Q4KM, 3=Q5KM, 4=Q8_0, 5=Iq4Xs, 255=Artifact(Hash32)。

GemmShape order は m:u32, n:u32, k:u32, batch:u32, dtype:DType, quantization:QuantizationClass。

ComputeOperation wire tags と payload:

Tag Variant Canonical payload order
0 Gemm GemmShape
1 Attention query_tokens:u32, key_value_tokens:u32, heads:u32, head_dim:u32, batch:u32, causal:bool
2 LayerNorm elements:u32, batch:u32
3 RmsNorm elements:u32, batch:u32
4 Rotary tokens:u32, heads:u32, head_dim:u32
5 ExpertRoute tokens:u32, experts:u32, top_k:u32
6 KvCacheRead bytes:u64
7 KvCacheWrite bytes:u64
8 Silu elements:u64
9 ElementwiseMultiply elements:u64
10 Softmax elements:u64
11 ElementwiseAdd elements:u64
12 TensorCopy bytes:u64
13 EmbeddingLookup elements:u64

Dense modelでは ExpertRoute を拒否する。Qwen adapter mapping V1 は MUL_MAT、RMS_NORM、 ROPE、SET_ROWS、SOFT_MAX、GLU、MUL、CONT、ADD、GET_ROWS を上記 operationへ 変換し、VIEW/RESHAPE/PERMUTEだけを layout metadata として除外する。その他は fail-closed。

ComputeUnitRules::v1() は全variantを integer-only、checked u128、明示ceil、minimum 1で 再計算する。ruleset descriptor の hash が cu_ruleset_id。observer申告の cost は受け取らない。

9. Ordered operation schedule

ExecutionPhase: 0=Prefill、1=Decode(u32 step)。 ScheduledOperation canonical order:

  1. index: u64（0から連続）
  2. phase: ExecutionPhase
  3. layer_id: Option<u32>（None は global LM head 等）
  4. operation: ComputeOperation
s0 = H("schedule-init/v1", job_nullifier, shape_profile_id, cu_ruleset_id)
si = H("schedule-step/v1", s(i-1), u64be(i), encode(event_i))
schedule_root = H("schedule-final/v1", sn, u64be(event_count))

index、chain、decode stepの単調性、model layer range、Dense/MoE制約を verifier が再検査する。 挿入、削除、並べ替えはCU合計が同じでもrootを変える。

10. GEMM trace

TraceEvidenceKind の wire tag は 0=Absent, 1=GraphFallback, 2=KernelSketch。 trace_scheme_id_v1 は H("gemm-trace-scheme/v1", fixed_scheme_descriptor) である。

AccumulatorSketch は i64be lane[4]。TileIndex は m:u32, n:u32, k:u32。 GemmTraceEvent canonical order:

  1. index: u64
  2. schedule_index: u64
  3. kernel_sequence: u64
  4. tile_linear_index: u32
  5. tile_count: u32
  6. evidence_kind: TraceEvidenceKind
  7. phase: ExecutionPhase
  8. layer_id: Option<u32>（None は global LM head）
  9. kernel_id: Hash32
  10. shape: GemmShape
  11. tile: TileIndex
  12. accumulator_sketch: [i64;4]
t0 = H("gemm-trace-init/v1", job_nullifier, trace_scheme_id)
ti = H("gemm-trace-step/v1", t(i-1), u64be(i), encode(trace_event_i))
trace_root = H(
    "gemm-trace-final/v1", tn,
    u64be(trace_event_count), u64be(gemm_group_count)
)

各scheduled GEMMは1つのcontiguous groupとなる。groupのschedule indexは狭義増加、全event index/ kernel sequenceは0から連続、group内metadataは一致、kernel IDはnonzero、全groupで evidence kindを 混在させない。GraphFallback は各GEMM exactly 1 synthetic tile、KernelSketch は1個以上の native tileを許す。trace group数はschedule内GEMM数と一致し、各eventのschedule index、phase、 optional layer、shapeを元scheduleと照合する。

現行 Qwen Metal adapter が発行できる trace は GraphFallback だけであり、CUDA claimへ昇格しない。 CUDA C ABIは既存final-output V1 recordに加え、declared origin、accumulator stage/dtype、sketch scheme、 reduction segment、producer variant IDを持つexact 184-byte V2 wire recordを定義する。Rustのstrict decoder/binderは全unfiltered record streamをexpected launch sequence、schedule、tile/segment order、exact MMVQ/flash-attention dispatch、CUDA runtime manifestへbindする。raw ProducerAccumulatorはtransport上の declared tagにすぎず、BoundCudaTranscriptV1はdiagnostic typestateである。 さらにadditive V3は452-byte recordと、FA-off attentionのQK-score MMVF、masked/scaled softmax、 value-aggregation MMVFからなるcanonical 3-sublaunch grouping、strict schedule/runtime binderを実装する。

別のauthority layerはsigned attestationをnetwork/job/execution/assignment、runtime class/manifest、 producer integration、operation schedule、full unfiltered transcriptへexact bindし、public raw constructorを 持たないAuthorityBoundCudaTranscriptV2を作る。そこからproducer-accumulator GEMMだけを AuthorityBoundCudaReceiptEvidenceV2へdeterministically射影する。attention final-output recordはsigned full-transcript commitmentに残すがGEMM evidenceへは昇格しない。

ComputeReceiptV1にはauthority provenance commitmentがないため、V1 builderはCUDA KernelSketchの発行を拒否し、workerがV1 bodyを手組み・署名してもverifierが拒否する。standaloneの true FP32 producer-accumulator採取primitiveはRTX 4060 Ti sm_89でdevice suite 7/7と20/20同一 diagnostic fingerprintを確認した。最終grouped suiteは8/8である。vendored llama.cppのQ4_K/Q6_K MMVQと FA-off QK/softmax/PV producerも接続済みで、same-backend Qwen 1-token diagnostic E2Eは361/361 record、 3回同一fingerprint、5 work-class rejectionを確認した。ただしproduction Receipt authorityではない。

現行deterministic profileはFA-offで、legacy V2が表すattention dispatchは LlamaFlashAttentionだけである。この非互換に対するV3 sublaunch/grouping schema/binderは実装済みだが、 実eager-attention 3-stage hook、361-launch実機E2E、release manifest、Receipt/Bundle/SQLite V2も 実装・検証済みである。live callbackへのauthority-derived canonical expected table接続は未完了である。public headerは PALW_CUDA_TRACE_PRODUCTION_CAPABLE=0、PALW_CUDA_PRODUCER_VENDOR_RUNTIME_INTEGRATED=0、 PALW_CUDA_PRODUCER_RECEIPT_MAPPING_AVAILABLE=0、PALW_CUDA_PRODUCER_PRODUCTION_CAPABLE=0で、production CMake optionもfailするため、R32はIn progressでもproduction CUDA KernelSketch Receiptを発行してはならない。

11. Compute Receipt and signature

ComputeReceiptV1 は正確に30 fieldで、canonical orderは次のとおり。

  1. receipt_version: u16 (=1)
  2. network_id: Hash32
  3. request_commitment: Hash32
  4. scheduler_job_id: Hash32
  5. signed_assignment_id: Hash32（assignment body の assignment_id）
  6. replica_slot: u8
  7. model_profile_id: Hash32
  8. runtime_class_id: Hash32
  9. runtime_manifest_hash: Hash32
  10. shape_profile_id: Hash32
  11. cu_ruleset_id: Hash32
  12. trace_scheme_id: Hash32
  13. trace_evidence: TraceEvidenceKind
  14. operation_schedule_commitment: Hash32
  15. schedule_event_count: u64
  16. canonical_compute_units: u64
  17. prefill_tokens: u32
  18. decode_tokens: u32
  19. output_commitment: Hash32
  20. gemm_trace_root: Hash32
  21. trace_event_count: u64
  22. owner_commitment: Hash32
  23. worker_credential_id: Hash32
  24. job_nullifier: Hash32
  25. execution_nullifier: Hash32
  26. job_class: JobClass
  27. evidence_level: EvidenceLevel
  28. timestamp: u64（informational only）
  29. issued_epoch: u64
  30. expires_epoch: u64

body-local evidence invariants:

  • Wrapper: schedule count、trace count、CUは0、trace kindはAbsent
  • RuntimeObserved: schedule countとCUはnonzero、trace countは0、trace kindはAbsent
  • GemmTraced: schedule count、trace count、CUはnonzero、trace kindはnon-Absent
  • replicated class: evidence levelはGemmTraced

trace無しでも gemm_trace_root は zero ではなく、同jobで初期化した empty trace root である。

body_id = H("receipt-body/v1", network_id, encode(body))
receipt_id = H("receipt-id/v1", network_id, encode(body))
signature_message = H("receipt-signature/v1", network_id, encode(body))

SignedReceiptV1 canonical order:

u16be(envelope_version=1) ||
LP(encode(body)) ||
signer_key_id:Hash32 ||
u8(signature_algorithm=0) ||
ed25519_signature:64-byte

現行 receipt_id は署名byteを含まず、同じbodyなら同じIDである。signature は worker keyで上記 messageを署名する。verifier は signer registry、scheduler-derived assignment authorization、 manifest、private prompt/output opening、schedule/CU/traceをすべて照合する。signer registryはnonzero owner/credentialとnon-weak keyだけを受け、Receipt signatureはstrict Ed25519で検証する。

12. Stateless verification and durable acceptance

stateless path:

  1. signed envelope と body をstrict canonical decode
  2. body structure、network、assignment epoch
  3. scheduler署名検証済み authorization recordとの全binding
  4. worker signer key、owner commitment、credential、Receipt signature
  5. model/runtime/manifest/shape/CU/trace identity
  6. job/execution nullifier再導出
  7. token shape bounds
  8. schedule、CU、traceをwitnessから再計算
  9. prompt/output private openingとtoken countを再計算

型は UnverifiedReceipt -> StatelesslyVerifiedReceipt。その後 StateStore::accept が SQLite transactionで replay/cardinality keyを予約した場合だけ AcceptedReceipt になる。Matcher と canary submission は AcceptedReceipt を要求する。first acceptance時のstateless verified_at_epochをdurable accepted_at_epochとして保存する。restart後のrestore_acceptedは新しい stateless verification epochとoriginal acceptance epochを区別し、canonical signed Receiptとauthorized runtime instanceがstored rowとexact一致するときだけtypestateを復元する。stored acceptanceはbody issued/expiry内かつcurrent verified_at_epoch以下でなければならず、rollbackを拒否する。

durable storeはapplication ID PALW、schema version 4、foreign keys、WAL、synchronous=FULLを要求する。 exact table set/column order/foreign-key count/indexに加え、non-internal sqlite_masterの全 (type,name,tbl_name,sql)をcanonical encodeしたSHA3-256 fingerprintをcompiled goldenと照合する。 旧schemaのsilent migrationとobjectを持つunclaimed DBは拒否する。receiptのaccepted epoch、pairのmatched epoch、signed future beaconのclaimed epoch、audit replayのissued/accepted epochは8-byte big-endian BLOBとして保存する。beacon verification時のcaller current epochは別columnへ固定せず、restore時の current AcceptedReceipt.verified_at_epochでregistry validity/revocationとともに再検証する。

13. Replica matching

MatchProjectionV1 canonical order:

  1. job_nullifier
  2. request_commitment
  3. job_class
  4. model_profile_id
  5. runtime_class_id
  6. runtime_manifest_hash
  7. shape_profile_id
  8. cu_ruleset_id
  9. canonical_compute_units
  10. prefill_tokens
  11. decode_tokens
  12. operation_schedule_commitment
  13. schedule_event_count
  14. output_commitment
  15. trace_scheme_id
  16. trace_evidence
  17. gemm_trace_root
  18. trace_event_count

network、scheduler job ID、assignment/slot、owner/credential/runtime instance/execution nullifier、 evidence level、timestamp/epoch、signature はprojectionに入らない。ただしjob nullifierとrequest commitmentはnetwork-boundであり、durable pair保存時には両memberのnetworkをexplicitに照合する。 2 Receipt は未失効、slot集合{0,1}、異なるexecution、signer key、credential、owner、assignment、 runtime instanceでなければならない。pairing current_epochは両bodyのissued epoch、両receiptのoriginal accepted epochとcurrent stateless verified epoch以上、両expiry以下でなければならない。

match_commitment = H("replica-match/v1", encode(projection))
pair_id = H(
    "pair-id/v1", network_id,
    min(execution_nullifier_a, execution_nullifier_b),
    max(execution_nullifier_a, execution_nullifier_b),
    match_commitment
)

MatchedReplicaPair はpairing呼出し時のcurrent_epochをprivate matched_epochとして保持する。 このepochはprojection/pair IDには入らないが、Self Replicated用のpublic maturity constructorが MatureEvidence.mature_epochへ封入する。durable pair recordのcanonical bytesにはmatched_epochを 含め、memberのstored issued/accepted/expiry epochと再照合する。

14. Audit, Work Ticket, canary, bond, and external identities

FutureBeaconV1 canonical orderはversion:u16 (=1), network_id:Hash32, epoch:u64, value:Hash32。beacon_id = H("future-beacon/v1", encode(body))。signed envelopeは次のorderである。

u16be(envelope_version=1) ||
LP(encode(FutureBeaconV1)) ||
authority_key_id:Hash32 ||
u8(signature_algorithm=0) ||
ed25519_signature:64-byte

signature messageはbeacon_id。network-scoped authority registryはbeacon epochのvalidity、verification epoch時点のrevocation、key ID、weak keyを検査し、strict Ed25519成功後だけraw constructorを持たない VerifiedFutureBeaconへ昇格する。claimed beacon epochはverification epoch以下でなければならない。

future audit selection:

sample = H(
    "audit-selection/v1", network_id, receipt_id,
    u64be(beacon_epoch), beacon
)
selected iff sample_as_big_endian_u256 < selection_threshold:Hash32

challenge_id = H(
    "audit-challenge/v1", network_id, receipt_id, sample
)

AuditRecord::newはexact AcceptedReceiptを受け、network、receipt ID、body issued epoch、durable accepted epoch、scheduler job、job nullifier、request commitmentをbindする。beacon epochはissued epochと accepted epochの両方より後でなければならない。v1 policyはselection threshold 2^252（一様digestの 1/16）、response window 2 epoch、challenge window 5 epochの固定値で、全値をaudit-policy/v1 IDへ commitする。

StateStore::store_audit_selectionはpolicy ID、original issued/accepted epoch、canonical signed beacon、 beacon ID/value/authority key ID、challenge/deadlineまたはnon-selected mature epochを保存する。restore時は current authority registryでsigned beaconを再検証し、sample/challenge/deadlineを再計算する。

selected replayはdistinctなStatelesslyVerifiedReceiptをaudit専用にacceptする。same network/job/requestを 要求し、receipt/execution/assignment/runtime instance/signer key/worker credential/owner commitmentはoriginal と異ならなければならない。replay issued epochはbeaconより後、durable replay accepted epochはissued/ current stateless verified epoch以上かつdeadline以下である。VerifiedReplayVerdictが両 MatchProjectionV1を比較してresult commitmentとmatch outcomeを作るため、callerはraw projection_matches:boolを注入できない。

selected pathはaudit replay identityの一回予約、terminal mismatchまたはpass、pass時のSelf Local maturity sourceを1 SQLite transactionで確定する。non-selected pathもwindow maturityとsourceを1 transactionで確定する。beacon delivery/finality、auditor assignment、model re-execution、opening配送は このwire/state coreの外部service boundaryである。

restore_auditはnon-replay state/terminalをrestoreするが、selected pass/mismatch terminalは AuditReplayRequiredで拒否する。この場合はrestore_selected_audit_with_replayを使い、durable audit state/challenge、stored canonical replay、全identity/epochを照合する。さらにprojection verdictを再計算し、 match bit、submission commitment、completed epochをstored terminal outcomeへexact比較する。

WorkTicketV2 のIDを除くcanonical body orderは次のとおり。

  1. version:u16 (=2)
  2. network_id:Hash32
  3. source_id:Hash32
  4. maturity_basis_id:Hash32
  5. weight_grant_id:Option<Hash32>
  6. job_class:JobClass
  7. weight_policy_version:u32
  8. canonical_compute_units:u64
  9. weight_bps:u32
  10. weighted_compute_units:u64
  11. issued_epoch:u64
weighted_CU = ceil(CU * weight_bps / 10_000)
ticket_id = H("work-ticket/v2", network_id, encode(ticket_body_without_ticket_id))

V1 default weight は Self Local challenge 2,500、audit pass 5,000、replicated 10,000、external demand bonus最大5,000 bps。これは算術/型変換の実装値であり、production network admission の 証明ではない。

MatureEvidence はwire objectではなく、fieldと低水準constructorを非公開にしたtyped gateである。 生成経路、maturity_basis_id、mature_epochは次の3つだけ。

  • Self Local: exact AcceptedReceipt + AuditRecord::Mature。domain local-maturity-basis/v2で audit basis/epochをbindし、audit stateが保持するmature epochを使う
  • Self Replicated: MatchedReplicaPair。pair IDをmaturity basis、pairのmatched epochを使う
  • External Replicated: authority-verified terminal settlement。confirmation IDをmaturity basis、authority- signed grant IDを必須weight grant、confirmation epochをmature epochとして使う

StateStore::register_mature_evidence(&MatureEvidence) はstored receipt/pairのnetwork、class、CUとopaque evidenceを照合し、Self Localではstored durable auditのstate/basis/epochも照合する。External evidenceは このAPIから拒否し、後述のsettlement transactionだけが登録できる。primary Self Local audit pathと Self Replicated pathは、source登録と同じtransactionで必要な1件/2件のactive assignment bondをMature releaseし、mature_source_assignmentsへrelease IDをlinkする。unbonded/不足/terminal lockならtransactionを rollbackする。ticket issuerもjob classのrequired replica数とlink数を再検査する。 issue_work_ticket は issued_epoch >= mature_epoch を要求し、SQLite ticket pathも保存epochに対して 同じ条件を検査してから1 sourceをatomicに消費する。既消費sourceの通常pathはSourceAlreadyConsumed、 External settlementのexact replayはstored ticketを返す。

canary expected projection commitment:

H("canary/v1", network_id, canary_id, request_commitment,
  u64be(opening_epoch), canary_salt, encode(expected_match_projection))

CanaryPrecommitBodyV1は version, network_id, canary_id, scheduler_job_id, request_commitment, signed_assignment_id, worker_credential_id, expected_commitment, created_epoch, receipt_deadline_epoch, opening_epoch, opening_deadline_epoch をcanonical encodeし、 precommit_id = H("canary-precommit/v1", encode(body))をschedulerがEd25519署名する。strict envelopeは body、scheduler key ID、algorithm、signatureを持つ。scheduler registryのnetwork、key validity/revocation、 strict signatureと、exact signed request/assignment/worker bindingを検査した後だけ VerifiedCanaryPrecommitになる。External Replicated canaryはv1で禁止する。

windowは assignment.issued <= created <= receipt_deadline <= assignment.expires < opening_epoch <= opening_deadline。canary markerはReceiptにない。verified precommitはactive bonded assignmentとcanonical signed envelopeをschema-v4 DBへ保存する。accept_canaryはbonded normal Receipt acceptanceと ReceiptSubmittedを同じtransactionでcommitする。valid opening passはterminalだけをcommitし、valid commitmentのprojection mismatchはtyped CanaryFailure slashをatomicに適用する。receipt deadline経過は worker faultでslashし、receipt受理後のopening deadline経過はscheduler faultとしてworkerをslashしない。 passとOpeningMissingではassignment bondをactiveのまま保持する。pending canaryがあるsourceのmaturityは 拒否し、terminal後はmature epochをcanary completion epoch以上へ遅延する。Self Localでは遅延後のepochで local-maturity-basis/v2も再計算する。その後のmaturity transactionがbondをMature releaseしてsourceへ linkするため、canary terminal単独ではWork Ticketを発行できない。

in-memory helperのslash offense:

Evidence = u64be(unique_sorted_count) || concat(sorted_unique_evidence_id)
offense_id = H(
    "slash-offense/v1", network_id, worker_credential_id,
    assignment_id, u8(reason), u32be(policy_version), Evidence
)

reason tagは 1=InvalidManifest, 2=AuditMismatch, 3=Equivocation, 4=DuplicateExecution, 5=CanaryFailure, 6=AuditTimeout。

durable slashはcaller-selected attachment集合ではなくcrate-private TypedSlashEvidenceのprimary proofを authority identityに使う。

offense_id = H(
    "durable-slash-offense/v2", network_id, worker_credential_id,
    assignment_id, u8(reason), primary_proof_id, u32be(policy_version)
)

audit mismatch/timeoutとcanary mismatch/receipt timeoutはproof IDをstate transition自身から導出して、 slash claim、derived allocation、assignment remainder、pending appeal bucket、health eventを同じtransactionで 更新する。claimはinitial assignment amountからreason別bpsをceilしたimmutable targetを持つ。v1の Equivocation追加penaltyは0である。複数claimを単純加算せず、finalized（signed/default uphold）targetの max-envelopeを先に割り当て、pending claimはそのenvelopeを超えるextensionだけを受ける。同じassignmentへの late equal/weaker claimのallocationは既存envelopeに覆われるなら0、stronger claimはdeltaだけとなる。 reverse後も全claimから再計算するため、ingestion順序でslash総額は変わらない。standard policyのappeal windowはdurable applied_epochから100 epoch。nonappealed slashはinclusive deadlineの後だけfinalizeする。 typed proofが示すfault_event_epochとstoreがclaimを受理するapplied_epochは別で、 locked_epoch <= fault_event_epoch <= applied_epochとaccount transition epochの単調性を要求する。

partial claimのremainderはactive lockとして残る。pendingまたはuphold/default-final claimを持つassignmentは maturity/Work Ticketの根拠にならない。全claim解決後、audit mismatch/ timeout terminalはclaimがreverseされても残額をSlashResolved releaseする。canary mismatch/receipt-timeout terminalはmatching CanaryFailure claimがuphold/default-finalの場合だけ同releaseを許し、External refundも release terminalになる。reversed canary claimだけではreleaseしない。未使用または acceptedだがunpairedのSelf Replicated assignmentだけは、pending canary/slashがなくsigned expiryを過ぎた 場合にExpired releaseできる。paired、Self Local、その他used assignmentはこのexpiry bypassを持たない。 pendingで全targetをallocateしたstate 2にもdistinct late claimを保存できるが、fully finalized/exhaustedの state 3は新claimを拒否する。terminal epoch/proofは全immutable claimをoffense ID順に並べ、各effective epochの maxと完全なterminal fact setから導出する。audit/canary terminalとExternal prepared/terminal stateは 後出しclaimのcutoffであり、特にExternal SettlementPreparedまたはRefundPrepared以後は新しい non-replay slashを受けない。

bond funding、slash appeal、slash decisionはそれぞれversion 1 canonical bodyとsigned envelopeを持つ。 funding bodyはnetwork/worker/funding event/asset/exact amount/finalized epoch、appeal bodyはnetwork/worker/ offense/assignment/appeal ID/submitted epoch、decision bodyはnetwork/appeal/offense/outcome/decided epochを bindする。network-scoped bond authority registryはkey validity/revocation、funding/appeal/decision capability、 weak key、strict Ed25519を検査し、raw constructorを持たないverified typestateだけをstoreへ渡す。

appeal submissionはstored pending slashとinclusive appeal deadlineを照合する。signed submitted_epochと registry verification epochの両方がapplied_epoch..=appeal_deadline内でなければならず、後者をdurable accepted_epochとして保存する。decision deadlineはaccepted_epoch + 100である。authority-signed Uphold/Reverseはsigned decided_epochとdecision verification/acceptance epochの両方がdeadline以下で だけ受理し、claim statusを更新してassignment全claimのallocationをatomicに再計算する。期限を過ぎても decisionがなければfinalize_stale_slash_appeal(current_epoch > decision_deadline)がdomain-separated default decisionを作ってdeterministically upholdする。offenseごとのappealは1件だけで、first stored signed/default decisionが勝つ。stored canonical appeal/decisionのexact replayは期限後もidempotent、distinct second appealやconflicting later decisionはfatalである。

ExternalEscrowTermsV1 canonical order は version:u16, network_id, escrow_nonce, funding_authorization_id, prompt_commitment, ExecutionConstraintsV1, required_reward:u64, demand_bonus_amount:u64, demand_bonus_bps:u32, protocol_fee:u64, failure_reserve:u64, issued_epoch:u64, expires_epoch:u64。

escrow_reference = H("external-escrow/v1", encode(terms))

external authorityはnetwork-scoped Ed25519 keyにfunding、demand-weight、terminal capabilityを分離する。 key validity/revocation、weak key、strict signatureを検査し、次のraw constructorを持たないtypestateを作る。

  • VerifiedFundingAttestation: escrow reference、funding authorization ID、asset、exact finalized amount/epoch
  • VerifiedDemandWeightGrant: escrow/funding attestation、grant/policy/asset、funded bonus amount/bps、 issued/expiry interval（v1 bonus上限5,000 bps）
  • VerifiedTerminalConfirmation: escrow、payment command、rail confirmation、asset、exact settlement/refund distribution、confirmed epoch

schema-v4 durable external pathはexact funding+grantからFunded escrowを作り、scheduler-signed External request、typed k=2 pair、stable payment commandへ進む。settlement confirmationはcommand/distribution/ pair/asset/epochを照合し、terminal state、maturity source、両worker assignment bondのrelease/link、 WorkTicketV2 insert、source consumptionを一SQLite transactionでcommitする。refund commandはstate 1..3 （Funded|Assigned|EvidenceReady）からterms expiry後に作成でき、pairの有無を問わない。refund confirmationは terminalとeligible assignment bond releaseを一SQLite transactionでcommitし、maturity/ticketを作らない。 pending slash claimを持つbondは解決までreleaseせず、解決後に残額だけをreleaseできる。exact confirmation replayは idempotentで、逆terminal、amount、identityのconflictを拒否する。

settlement commandをSettlementPreparedへcommitする同じBEGIN IMMEDIATE transactionで、pair両assignmentが active state 0かつpending/upheld/default-final slash claimなしであることをpreflightする。 SettlementPreparedとRefundPrepared（state 4/5）はどちらもnon-replayのlate slashを拒否するため、 terminal準備とslashの順序で結果が変わらない。

これはexternal authorityが「rail上のfinality」を正しく署名するというtrust boundaryである。crateは payment railを操作せず、rail transactionとSQLite commitのdistributed atomicityを主張しない。

15. Encrypted verification bundle and restart restoration

VerificationBundleV1はcanonical Receiptのprivate openingをrestart後もstrict verifyするためのartifactで、 Receipt wire format自体は変更しない。audit keyはcaller-owned raw 32 bytes、nonzeroで、bundleには含めない。

public sectionのcanonical order:

  1. version:u16 (=1)
  2. receipt_binding:Hash32
  3. receipt_id:Hash32
  4. verification_epoch:u64
  5. scheduler key snapshot: network_id, verifying_key, valid_from_epoch, valid_through_epoch, revoked_at_epoch:Option<u64>
  6. LP(RuntimeManifest canonical bytes)
  7. LP(portable ExecutionEvidence canonical bytes)（schedule/CU/trace witness）

worker public keyはpublic sectionへ置かない。private sectionのcanonical order:

  1. LP("MISAKA/PALW/PRIVATE-OPENING"), version:u16 (=1), public_digest:Hash32
  2. LP(SignedJobRequestV1), LP(SignedAssignmentV1)
  3. worker verifying_key, owner_commitment, worker_credential_id
  4. output_nonce, u64be(prompt_token_count), u32be(prompt_token_id_i)*
  5. LP(CanonicalOutput)（generated token IDsとstop reason）
  6. owner_salt

private signing-key seedはどのsectionにもserializeしない。

receipt_binding = H("verification-bundle-receipt/v1", canonical_signed_receipt)
public_digest   = H("verification-bundle-public/v1", canonical_public_section)
aead_key        = H("verification-bundle-aead-key/v1", raw_audit_key)
aad = H(
    "verification-bundle-aad/v1",
    "XCHACHA20-POLY1305;KEY=256;NONCE=192;TAG=128",
    receipt_binding, public_digest, nonce, canonical_public_section
)

envelope canonical order:

LP("MISAKA/PALW/VERIFICATION-BUNDLE") ||
u16be(version=1) || u16be(cipher=1) ||
receipt_binding || public_digest || nonce:24-byte ||
LP(canonical_public_section) || LP(XChaCha20-Poly1305 ciphertext_and_tag)

nonceはOS CSPRNGのnonzero 192-bit値、AEAD keyは256 bit、tagは128 bit。envelopeは64 MiB、public sectionは48 MiB、private plaintextは16 MiBを上限とし、strict decode/re-encode、receipt/public binding、 AEAD authenticationを検査する。

bundle_id = H("verification-bundle-id/v1", canonical_complete_envelope)

local restart pathはembedded scheduler/worker snapshotsを使ってcomplete stateless verificationを再実行し、 既存schema-v4 DB rowのcanonical Receipt/runtime instance/original acceptance epochへexact restoreする。 missing DB rowを新規acceptしない。これはlocal continuity modeであり、embedded snapshotはthird-party network authorityではない。

bundle public sectionのhistorical verification_epochはoriginal acceptance時点をbindする。 verify_bundle_and_restore_at_epochはcaller-selected current epochがhistorical値以上であることを要求し、 同じbundle/openingをfresh epochで再検証したうえでoriginal durable acceptance epochを保持してrestoreする。 ただし、このlocal APIはembedded snapshotsを使うためbundle作成後のrevocationを学習できない。future audit restoreではcurrent epochをbeacon以上にする。rollbackは拒否する。現行 palw-verify-bundle CLIはhistorical default pathで、fresh epoch overrideはlibrary APIだけが公開する。

external stateless pathはexpected network、independent scheduler registry、independent signer registry、 approved manifest hashを必須にし、embedded snapshotとのexact equalityも検査する。default APIはhistorical epoch、verify_bundle_stateless_at_epoch_with_trustはrollbackしないcaller-selected fresh epochで検証する。 DB reservationを行わず、network acceptanceを主張しない。production restartではcurrent external trust rootsと 既存DB continuityを同時に検査するverify_bundle_and_restore_at_epoch_with_trustを使う。

Receipt CLIは--prompt-stdin --audit-key-file RAW_32_BYTE_KEYを必須とし、--prompt TEXTを受けない。 key fileはoutput directory外のowner-owned single-link regular file、mode 0400/0600、exact 32 bytesで なければならない。issuance output directoryは0700、Receipt/公開JSON/completion markerは0644、 bundle/DBは0600。DB WALをTRUNCATE checkpointしてmain DBをfsyncし、各artifactをfsyncした後、 misaka.palw.receipt-set.v2 markerへreceipt_id、bundle_id、公開JSON bytesのSHA-256を記録して最後に 書き、directoryをfsyncする。local verifier CLIは--public-jsonも必須とし、protected artifactsが同じ owned 0700 directoryにexpected filename/modeで存在すること、marker、typed公開JSON misaka.palw.public-receipt.v2全体を検査する。 保持するartifactsとobserver_summaryはauthenticated bundle manifest/evidenceから再構成してexact照合し、 extra JSON fieldはobjectの全階層で拒否する。 marker-lastはpartial setをcompleteとして受理しないためのgateであり、cross-file atomic transactionでも authenticity proofでもない。markerはunkeyed plain textなのでsame-owner writerはJSONとmarkerを一緒に 置換できるが、改変JSONはReceipt/bundleとの照合に失敗する。canonical Receipt/authenticated bundleだけが protocol authorityである。

16. Security and issuance boundary

trace root は approved observer が報告したeventへのcommitmentであり、単独のproof of executionでは ない。intended production safety modelはpinned build、signed assignment、independent replica、future audit、bond/slashing、durable uniquenessを組み合わせるが、個別primitive/state machineの存在はそれらが operationally統合済みであることを意味しない。

schema-v4 coreはscheduler-signed canary precommit、authority-signed bond funding/appeal/decision、durable assignment lock/release/slash/health、authority-signed external funding/grant/terminalを実装する。bonded receipt acceptance、audit/canaryのtyped slash、maturity時bond release/link、WorkTicketV2 gate、External terminalから maturity/ticketまでのlocal atomic transactionも実装済みである。

ただしproduction scheduler/network transport、governance-backed scheduler/worker/beacon/bond/external key distribution、finalized beacon delivery、independent auditor execution/opening delivery、実payment railと authority serviceはこのrepositoryにない。署名済みfunding/terminalは外部factのauthenticated statementで あり、crate単体が実collateralやrail movementを独立証明するものではない。railとSQLiteはdistributed atomic transactionではない。durable slashへ自動接続済みのproofはaudit mismatch/timeoutとcanary mismatch/receipt timeoutで、invalid-manifest、equivocation、duplicate-executionのproduction proof constructor/orchestrationは未統合である。legacy in-memory BondLedger/CanaryRecord/ExternalEscrow helperの raw mutation APIをproduction authority pathとして使ってはならない。

現時点で実モデルReceiptを発行できるのはApple Metal GraphFallback runtime classである。CUDAは RTX 4060 Ti sm_89 / CUDA Toolkit 13.3.1 / nvcc 13.3.73で固定Qwen 37/37 layer offload、graph observer 6/6、standalone true-accumulator primitiveの最終grouped device suite 8/8とproducer 20/20同一fingerprintに 加え、vendored MMVQ/FA-off attention same-backend 1-token diagnostic E2Eで361/361 recordと3回同一 fingerprintを実測済みである。exact entry/cubin/DSO release manifest、Receipt/RuntimeManifest/Request/ Assignment V2、暗号化Bundle V2、SQLite V2も実装・検証済みである。これはproduction KernelSketch acceptanceではなく、authority-derived canonical IDを使うlive callbackとauthority governanceは未完了である。 V1 builder/verifierとproduction macro/CMake gateはfail closedを維持するため、 これらが完了するまでproduction CUDA Receipt/Work Ticketを発行しない。TEE attestationやZK/VCは 実装範囲外である。