--- title: "CWSR Paper 07｜CWSR Runtime：遊戲引擎整合與參考實作" english_title: "CWSR Runtime: Engine Integration and a Reference Implementation for Causally Governed World-State Execution" series: "CWSR — Causal World-State Runtime" paper: "07 / 08" version: "v0.1" date: "2026-10-16" author: "Neo.K" ai_research_collaborator: "Aletheia / GPT-6" institution: "EveMissLab / 一言諾科技有限公司" status: "Research Draft — Engineering Extension / Reference-Implementation Specification; Hardware Validation Pending" canonical_source: "UTF-8 Markdown; mathematical delimiters $...$ and $$...$$ only" language: "zh-TW" predecessor: "CWSR Paper 06 v0.1" next_paper: "CWSR Paper 08 — 可證偽驗證與開放世界效能基準" --- # CWSR Paper 07｜CWSR Runtime：遊戲引擎整合與參考實作 ## 從因果工作票、跨尺度狀態、記憶體契約與 24／72 路由，到可隔離、可重播、可測量的遊戲執行核心 **English:** *CWSR Runtime: Engine Integration and a Reference Implementation for Causally Governed World-State Execution* **系列定位：** CWSR Paper 07 / 08。本文是 Paper 00–06 的工程收斂與 Paper 08 的實驗入口，不重新定義全域計算論、24／72 或 Rust 語言語義。 **本篇交付：** 分層 Runtime 架構、資料及權威接口、階段性交付門檻、最小 Rust 標準庫參考核心原始碼、CPU 決定性測例、GPU 後端接入規則、Godot／EveWorld 適配規格、存讀檔與失效恢復契約、基準執行與反證矩陣。 **交付證據等級：** 本篇內含完整可供本地端複製的最小 Rust 參考候選，而非宣稱已經打包或測通商用引擎。當前寫作環境沒有 Rust 編譯器，因此**本篇 Rust 範例未經 `cargo test` 實際驗證**；也未在實機 GPU、Godot、Windows 驅動或 EveWorld Engine 上量測。該界線必須保留在正式原稿中。 **作者：** Neo.K **機構：** EveMissLab / 一言諾科技有限公司 **日期：** 2026-10-16 **版本：** v0.1 --- ## 摘要 CWSR 前六篇已建立若干互相獨立而不可混淆的義務：邏輯世界不等於活動工作；世界內容有效不等於已駐留；世界某部分休眠不等於其時間與因果責任消失；宏觀摘要不等於可任意反推微觀歷史；GPU kernel 完成不等於世界提交；24／72 計算形態不等於固定硬體或效能排名。若只把這些規則留在論文中，而沒有具體 Runtime 邊界，實作者很容易在優化、遊戲引擎回呼、MOD 熱更新、快轉與裝置故障時重新破壞這些區分。 本文的任務，是在**單機、有限資源、權威世界狀態**的工程邊界內，將前述契約落成可測試的執行結構。其核心不在於另造大型通用計算作業系統，而是採取極小、能驗證的垂直切片：固定 world fixture、明示的事件／期限、版本戳記、可撤回路由建議、容量門檻、候選結果、唯一 Commit Gate，以及可以與原始 CPU 參考語義比較的重播歷史。GPU 世界計算與引擎適配採逐步接入；沒有可驗證後端，就不得把 GPU 計畫當成已完成計算。 本文提出 `WorldRegistry`、`WakeController`、`ScaleBridge`、`ResidencyManager`、`FormAnnotator`、`RoutePlanner`、`ResourceAllocator`、`CandidateExecutor`、`CommitGate`、`HistoryReplay` 與 `EngineAdapter` 的最小責任分界，定義候選執行記錄與重播證據，並附帶不依賴第三方 crate 的簡化 Rust 轉帳式 world fixture。範例的保守設計刻意採**全域 revision barrier + 單執行緒 CPU 計算**，而不假裝已涵蓋依賴索引併發、GPU fencing、動態尺度細化或真實裝置分配；其作用是提供可供後續逐項擴充的語義對照錨點。 Paper 08 必須以同一世界規則、輸入事件、可觀測契約、精度與資源環境，對照成熟 CPU ECS、事件驅動、GPU Compute 與 FormBlind 異質路由，檢查 CWSR 是否在語義正確的前提下帶來真實收益，並允許結論為「沒有額外收益」。因此，**Reference Runtime 的第一完成條件是可證偽與可恢復，不是最大化功能數或直接宣稱效能突破**。 **關鍵詞：** CWSR；Reference Runtime；Game Engine Adapter；Rust；Deterministic CPU Oracle；Causal Ticket；World Revision；Commit Gate；Route Planner；24／72；Selective Materialization；GPU Compute；Device Fence；Multi-Scale Simulation；Replay；Mod Compatibility；Godot；EveWorld Engine；Falsifiability。 --- # 0. 任務界線與研究責任 ## 0.1 這篇是實作規格延伸，不是第七套母理論 CWSR 的理論母源已存在於 GCM、GCCF、GCCFT、GCCWT，以及計算 24 範式與 72 格計算動力學候選系列。本篇只有一項新增責任：把前六篇在單機遊戲內的規範，以具體資料流、元件接口、失敗路徑和測試閘門表達。 這裏所稱 `Runtime` 是可被遊戲引擎呼叫、可回放世界結果的**程式層與執行控制面**。它不暗示重新實作 Windows 排程器、顯示卡驅動、編譯器、物理引擎、圖形 API 或 Rust 所有權機制。既有 ECS、Dirty Flag、Event Bus、Timer Wheel、GPU Compute、Fixed-Step Physics、快取、存檔與重播機制均是成熟工程來源；本篇研究它們如何在一組明確世界語義下被協調，而非冒稱發明之。 ## 0.2 四個階層必須永久分開 1. **世界規則層：** 身份、規則修訂、資產及歷史、模擬時間、精度與可觀測不變量。 2. **工作資格層：** 必要事件、期限、依賴失效、候選喚醒、尺度／形式註記。 3. **物理執行層：** CPU 工作、GPU dispatch、RAM／VRAM lease、fence、完成回執。 4. **權威修改層：** 版本與證據驗證後的唯一世界提交、歷史追加、後繼事件生成。 不可用「GPU 寫進 buffer」「引擎節點更新」「路由分數最高」「模型認為已結算」取代第四層。 ## 0.3 必須實作和可以延期的事項 | 類別 | Paper 07 必需規格 | 首輪允許的保守實現 | |---|---|---| | 世界身份 | 世界、schema、rule、revision、epoch、工作 ID | 單一 world + 單一寫入者 | | 因果義務 | 可觀察事件與時間到期、不可漏喚醒 | 有序 CPU 事件佇列 | | 工作讀寫 | 顯式依賴集合、guard、寫入集 | 全域 revision barrier 保守失效 | | 尺度 | 尺度視圖、身份錨點、轉換憑證 | 固定尺度 fixture；切換暫時拒絕 | | 記憶體 | 物理副本與邏輯事實分離、界限、回收證據 | CPU-owned memory + 可量化模擬預算 | | 路由 | FormBlind 強基線、FormAware 可撤回層 | CPU 基準先完成，GPU 僅 shadow candidate | | GPU | 驗證過的 kernel、buffer generation、fence | 無 adapter 時明確 `Unsupported` | | 提交 | 唯一 world writer、原子校驗與版本遞增 | 同一 process 下的單執行緒提交 | | 存讀檔 | 對齊 world 與未履行義務、rule/schema 校驗 | 先以可重播日誌 + deterministic snapshot | | 引擎介接 | 事件輸入與唯讀世界投影分開 | Host-driven tick、main-thread UI 更新 | 這個表不是將未實現功能宣稱已完成，而是規定逐階段什麼叫做有證據的完成。 ## 0.4 明確禁止的完成宣稱 - 沒有 `cargo test` 報告就不能稱 Rust 參考 crate 已編譯驗證。 - 沒有 adapter／GPU driver／shader hash 及 fence 測試就不能稱已完成 GPU 世界計算。 - 沒有實際 Godot／EveWorld build 與事件回放就不能稱已整合引擎。 - 沒有公平的 B0–B6 對照就不能稱 24／72 改善性能。 - 沒有存檔恢復、MOD 變更與時間快轉壓力測試，就不能稱大世界因果一致性已證明。 - 沒有世界規則等價證據，就不能把畫面顯示正常當成執行正確。 --- # 1. 從 Paper 00–06 的明確交接 | 上游 | 保留的 canonical 概念 | Paper 07 的責任 | 不得偷換為 | |---|---|---|---| | 00 | CWSR 單機／消費級硬體適用域；有限活動實現 | 建立最小原型與輸入／輸出合約 | 任意軟體都應事件化 | | 01 | `WorldState`、`StateRef`、版本／身份；活動與提交分離 | 類型化世界登錄、唯一 writer | 只要在 RAM 中就等於權威 | | 02 | `WakeTicket`、期限、Guard、Subscription Barrier | 持續事件日誌與可恢復義務佇列 | 喚醒等於完成 | | 03 | `ScaleView`、Anchor、Ledger、Temporal Cut、Scale Certificate | 轉換接口及保守可拒絕的尺度適配 | 聚合可反推全部個體歷史 | | 04 | `MemoryRegionContract`、ReplicaRef、Lease、Eviction Certificate | 容量治理與安全物化／卸載介面 | buffer 是邏輯世界身份 | | 05 | `CausalMicroflow`、hazard、GPU queue、fence、candidate receipt | CPU／GPU 後端協定及同步證據 | Dispatch 完成就是提交 | | 06 | Form24／72、FormBlind／FormAware、HardGate、CostEvidence、Hysteresis | 保留對照路由與路由審計 | 24／72 等於硬體排名 | ## 1.1 共用世界記號 沿用前篇（本篇只引用、不修改）： $$ W_t^{\mathrm{log}}=\langle V_t,E_t,X_t,T_t,H_t,\Gamma_t\rangle. $$ $$ R_t^{\mathrm{run}}\subseteq A_t^Q\subseteq Q_t. $$ $$ N_t\subseteq A_t^Q\cup P_t. $$ 在本篇中， $N_t$ 表示不可丟失的規則義務， $A_t^Q$ 是已取得活動資格的工作， $P_t$ 是符合契約的待處理義務；三者都不等於現在 CPU 正在執行的函式集合。 ## 1.2 候選與權威分離 令 $C_t(q,r)$ 為工作 $q$ 在路由 $r$ 上得到的候選結果， $\mathrm{Gate}$ 為權威提交檢查。只有通過 Gate，才能取得新世界 revision： $$ W_{t+1}=\mathrm{CommitGate}(W_t,C_t(q,r),\pi_t). $$ 這是操作性要求，不表示任意 GPU 工作結果皆可直接套入同一個數值計算函式。跨尺度轉換、隨機更新與物理子步進仍需要各自證據策略。 ## 1.3 參考版故意先使用更強的版本壁壘 為避免早期原型因細粒度索引缺陷而漏依賴，初版採 **world-wide revision barrier**：候選建立後若任何權威世界修改發生，候選必須拒絕並重跑，即使修改不在其 read set。這會犧牲吞吐量，卻提供簡單且可重現的 CPU oracle。後續才可把全域 barrier 放寬至經證明完備的 per-key 或 domain-based version vector。 ## 1.4 提交權不得由引擎偷偷取得 Godot／EveWorld 可以呼叫 Runtime、接收只讀事件與渲染狀態，但不能因 Inspector、動畫事件、腳本回呼或模組熱更新而直接越過 Commit Gate 修改 canonical world。若某 gameplay 系統需要寫入，它應產生型別化的 `Intent`／`WorldCommand`，由同一個授權鏈安排。 --- # 2. Runtime 的最低模組邊界 ## 2.1 `WorldRegistry`：世界身份與讀取快照 職責：維持 world ID、revision、rule/schema revision、受保護的 canonical state、可重播歷史索引及 snapshot token。最小讀取能力為 `get_state_ref` 與 `snapshot_at_revision`；直接修改權只存在於 Commit Gate。Registry 不以裸 GPU address 充當世界物件 ID。 ## 2.2 `WakeController`：義務與工作票生命周期 職責：由已提交事件、到期時間、訂閱與恢復記錄生成 Ticket；記錄工作是否已完成、延期、取消或重試。所有延期需保留期限與因果義務；未知 Guard 必須阻止不安全休眠，或採保守輪詢／固定步進。 ## 2.3 `ScaleBridge`：尺度投影與結果對齊 職責：提供 macro／meso／micro 的尺度視圖、聚合／條件細化、identity anchors、數量守恆、版本與 Temporal Cut。拒絕任何不能在既有事件帳本下合法還原的個體歷史；若尺度轉換帶近似，必須附誤差界限及可審計 policy ID。 ## 2.4 `ResidencyManager`：物理載體管理 職責：RAM／VRAM working set 的預算與 lease、版本化 replica、重建成本、Pin／Evict 與裝置失效恢復。它可以管理 buffer，不能管理遊戲世界因果真值；卸載不得一併刪除尚未到期的事件。 ## 2.5 `FormAnnotator`：分類不是指令 職責：在明確 observation context 下，給工作片段加上 24／72 profile；支援 `Single`、`Set`、`Path`、`Stack`、`Unclassified`，保留 basis version、rule revision 與分類證據。結果屬 metadata，可以撤回；不得直接觸發世界變化或決定某種硬體必然較快。 ## 2.6 `RoutePlanner`：提出可撤回計畫 職責：先取得合法候選，再比較 CPU Serial、CPU Jobs、CPU SIMD、CPU Event、GPU Direct、GPU Resident、Cache Reuse 等路由，在 shape、成本、資源、期限和證據下選擇計畫。提供 `FormBlind` 和 `FormAware` 兩種對照配置，後者不可豁免原有 hard gates。 ## 2.7 `ResourceAllocator`：物理預算與授權 職責：提供有限時間 lease、負載快照、裝置能力、render reserve、最大 outstanding work、RAM／VRAM headroom，以及明確的拒絕理由。計畫者說「GPU 可行」不等於 allocator 已保留該資源，lease 也不等於驅動已物理配置 VRAM。 ## 2.8 `CandidateExecutor`：計算與候選回執 職責：從有效 snapshot、授權的 lease 與 verified algorithm/kernel 產生只讀候選回執。CPU 後端可先使用定義清楚的參考函式；GPU adapter 必須有 buffer generations、fence、寫集、精度／bitwise 契約和完成證據。 ## 2.9 `CommitGate`：唯一的世界改寫門 職責：重驗 snapshot、規則、schema、MOD hash、ticket、read/write hazards、尺度和精度憑證、lease/fence 與可觀測不變量，然後一次提交，遞增 revision、追加歷史並產生下游因果事件。CommitGate 不必自己執行昂貴 kernel，但不能只相信 executor 宣稱成功。 ## 2.10 `HistoryReplay`：審計與可恢復記錄 職責：保存輸入事件、logical time、ruleset hash、seed/counter、ticket、route、candidate evidence、commit／reject、world snapshot hash、版本及後端資料。預測性 preload 不得被當作已發生世界事件寫入 canonical history。 ## 2.11 `EngineAdapter`：宿主引擎的薄接入層 職責：轉換遊戲事件到型別化命令、安排行為／畫面同步時點、發佈唯讀世界投影、遵守主執行緒限制；不改寫世界權威規則、圖形框架或第三方引擎內建物理正確性。 --- # 3. 由 Intent 到 Commit 的分段運行協定 ## 3.1 事件不直接執行 建議的分段協定： ```text Engine Input / Simulation Timer / Committed Event -> Intake + Durable Event Key -> WakeController (necessary obligations) -> Work Descriptor + Versioned Snapshot -> ScaleBridge / FormAnnotator (optional, may return Unknown) -> RoutePlanner (FormBlind or FormAware) -> Hard Gate / ResourceAllocator / Reservation -> CandidateExecutor (CPU, GPU, hybrid, reuse) -> CandidateReceipt (not canonical) -> CommitGate (revalidate everything required) -> Canonical Revision + Event Journal -> Read-only World Projection / Engine Render ``` 外部遊戲事件即使已抵達，也只代表存在需判定的意圖。禁止讓外部 callback 直接保證世界已完成某項計算。 ## 3.2 五種生命週期必須互不混淆 | 狀態 | 代表 | 退出方式 | |---|---|---| | `PendingObligation` | 事件／期限必須被處理 | Ticket 取得合法資格或明示取消理由 | | `AdmittedWork` | 已通過第一輪規範和預算檢查 | Reservation 建立或退回 | | `Executing` | CPU 正執行／GPU in-flight | 產生 receipt 或失敗回條 | | `CandidateReady` | 有完成證據，但尚未權威 | Commit Gate 通過／拒絕／重試 | | `Committed` | 世界修訂已合法遞增 | 追加歷史並喚醒後繼義務 | 這個生命周期不是必須建立五個 thread；它可以在小遊戲中由一個排程器處理。重點是語義可分，而非刻意把簡單程式拆成微服務。 ## 3.3 排程同意與權威提交的兩次驗證 第一次 Admission 針對現在的 snapshot 及資源，第二次 Commit 針對實際 candidate 和**提交當下**的世界、規則、資源與依賴。兩次檢查間發生的世界修訂、MOD 替換、buffer 世代變化、deadline 超時或設備故障，均可能使第一次許可失效。 ## 3.4 最低事件鍵與冪等處理 每個被提交的世界義務至少包含 `world_id`、`work_id`、`source_event_id`、`epoch`、`rule_revision` 與可選 `attempt_no`。Retry 與 Replay 不得僅靠 event name 判斷是否已執行；應以穩定的 semantic idempotency key 避免同一轉帳、傷害或資產事件二次生效。 ## 3.5 Backpressure 與 Deadline 當工作超過容量時，系統可以延後符合契約的工作、降低合法的觀察精度、切換為 CPU fallback 或暫停接收非必要預載；不可透過刪除已承諾時間義務或改寫世界歷史來假裝系統跟上時間。無 admissible route 應返回帶證據的 typed failure，讓遊戲選擇等待、降載或中止目前操作。 --- # 4. 形式資料契約與核心不變量 ## 4.1 最小 World Stamp ```text WorldStamp { world_id, canonical_revision, simulation_epoch, rule_revision, schema_revision, mod_digest, optional_scale_certificate } ``` 真正存取時可採 interned ID；文字欄位僅供持久化及可讀審計，避免高頻熱路徑大量複製字串。 ## 4.2 Work Descriptor ```text WorldWork { work_id, source_event_id, expected_world_stamp, read_dependencies, candidate_writes, guard, due_time_or_step, max_completion_window, precision_contract, scale_context, required_authority, optional_form_profile, admissible_backend_capabilities, fallback_policy } ``` `read_dependencies` 不得只列已存在的鍵。若工作依賴「附近沒有敵人」「某任務目前不存在」等負向查詢，必須使用 range/predicate subscription、版本索引或採全域版本壁壘。沒有這些證據，不能允許稀疏更新跳過對該依賴的檢查。 ## 4.3 法律／語義上的 Guard 與硬門檻 令候選路由集合為 $\mathcal R(q,t)$，只有當其滿足所有不可降級要求時才算可行： $$ \mathcal R_{\mathrm{adm}}(q,t)=\{r\in\mathcal R(q,t):\bigwedge_{j=1}^{m}g_j(q,r,t)\}. $$ $g_j$ 應至少檢查必要的身份、世界修訂、依賴、權威、schema/rule、期限、精度、尺度不變量、資源容量、輸出副作用界限及回復條件。分類和估計模型只能用來縮小候選或排序，不能宣告一個 hard fail 候選為合法。 ## 4.4 Revision 與 Epoch 不是同一個時鐘 `canonical_revision` 表示權威變更序列；`simulation_epoch` 表示規則中的世界時間或步進；`wall_clock` 表示外部真實時間。沒有外部規則指定，不得把三者視為同一個遞增量。某次快轉可在一個 wall-clock interval 內處理多個 simulation epoch，且有多次 canonical commit；反之，即使 wall-clock 流逝，遊戲可能合法暫停世界時間。 ## 4.5 資源活動量與邏輯大小分離 $$ |\mathcal W_{\mathrm{active}}(t)|\leq B_{\mathrm{work}}(t), $$ 其中 $B_{\mathrm{work}}$ 是當前資源契約給出的工作集界限；它不代表邏輯世界資料的理論上界。對固定 RAM／VRAM 也不能假設所有重新載入免費，物化和移動成本必須納入路由總成本。 ## 4.6 參考版先不嘗試絕對最優 $$ \pi^*_t\in\operatorname{Pareto}\bigl(\mathcal R_{\mathrm{adm}}(q,t)\bigr) $$ 是一個可比較候選的研究方向，並非聲稱 Runtime 已計算出完全已知的最優 Pareto front。未知延遲、未知 VRAM 可用量及高度動態 render load 應被記為 Unknown 或保守估計，而不是填上憑空的精確分數。 --- # 5. Rust 實作工程的最小封裝與里程碑 ## 5.1 建議 workspace 目錄 ```text cwsr-runtime/ Cargo.toml crates/ cwsr-core/ # ids, world stamp, candidate, typed errors cwsr-wake/ # event & deadline obligations cwsr-scale/ # anchors, ledgers, transitions cwsr-memory/ # region budgets & replica leases cwsr-router/ # hard gates & B4/B5/B6 profiles cwsr-executor-cpu/ # canonical deterministic oracle cwsr-executor-gpu/ # optional verified GPU adapter cwsr-commit/ # only canonical writer cwsr-replay/ # journal, fixtures, replay cwsr-adapter-godot/ # optional host connector cwsr-adapter-eve/ # optional EveWorld connector examples/ city_flow/ weather_grid/ travel_jump/ tests/ conformance/ failure_injection/ benchmark_fixtures/ ``` 這是建議的未來工程拆分，而非宣稱上述 crate 已建立在現有 GitHub 倉庫中。早期可以先用單一 `cwsr-reference` crate 實驗，以降低過早模組化成本；確認契約穩定後再拆分。 ## 5.2 階段性驗收順序 | 階段 | 完成證據 | 若失敗如何處理 | |---|---|---| | M1 決定性 CPU | 版本、Ticket、候選、Commit、重播測試 | 不進入 GPU | | M2 Typed Hard Gates | 每類拒絕理由有隔離測試 | 保留 CPU fixed-step | | M3 FormBlind Router | 同規則下 B4 baseline 可重現 | 停止 FormAware 實驗 | | M4 FormAware | B4/B5 可交換開關且分類成本可觀察 | 可永久關閉分類 | | M5 GPU Adapter | Shader hash、buffer generation、fence、oracle 對照 | GPU 故障走 CPU 或 typed fail | | M6 Replanning | 政策切換、render reserve、遲滯與成本記錄 | 固定 route fallback | | M7 跨尺度 fixture | 身份／資產／時間 cut 的反例測試 | 不進行自動細化 | | M8 Engine Adapter | Godot／EveWorld host demo 和 replay | Engine 使用唯讀 mirror，核心不動 | ## 5.3 可重現的完成物清單 每個 milestone 至少生成：原始碼與 commit SHA、cargo lock（如適用）、工具鏈版本、執行平台、測試命令及 exit code、fixtures、金標結果、失敗樣本、CPU/GPU 驅動詳情（若適用）、基準報告與已知不支援列表。沒有這些證據，設計草圖仍應標記為 Draft。 --- # 6. 最小 Rust CPU 參考核心：正式範圍與使用方式 ## 6.1 為什麼以兩個帳戶的資源轉移開始 若第一個示範就同時包含一百萬 NPC、流體模擬、GPU Kernel、多尺度城市與即時場景，錯誤來源將難以分離。本篇選擇一個**單一權威世界、兩個有身份的非負整數資源帳戶、可追蹤的合法轉移事件**作為最小 oracle。它雖簡單，仍能強制檢查在大型世界中同樣重要的七項條件： 1. 提交前的 candidate 不得改動世界； 2. 新舊 world revision 不得混用； 3. 規則、schema 與 MOD 版本必須吻合； 4. Event/Ticket 的時間義務必須到期； 5. 每個成功提交的 work ID 在該世界不得重複生效； 6. 資源轉移遵守非負性及總量守恆； 7. 已提交事件可從相同初始世界重播，得到相同金標狀態。 這是語義參考而不是最佳化 benchmark；其中一個保守 `world_revision` barrier 會導致所有其他新 commit 使舊 receipt 失效，未來若要並行化，必須另立 per-key 或 domain-based dependency proof。 ## 6.2 Rust 參考程式的驗證狀態 下列程式刻意使用 Rust 2021 Edition 與標準庫，不依賴 GPU 驅動及第三方 crate。其角色是 Paper 07 的**可複製實作候選原始碼**，包括 6 個 Rust `#[test]` 測例；本輪已做文本及不變量審閱，但無可用 `rustc`／`cargo` 執行環境，故不能宣稱已確認其編譯與測試結果。若本地 Agent 複製後編譯失敗，應把錯誤作為待修的工程證據，不得回寫研究稿為「測試通過」。 範例提供的是純 CPU reference；GPU、FormAware、真正的多尺度與引擎適配**不是**本段程式碼已實現的功能。 ## 6.3 建議指令與目錄 在具有 Rust 工具鏈的本機工作區，建立 `cwsr_reference` 專案，分別填入以下 `Cargo.toml` 與 `src/lib.rs`，從專案根目錄執行： ```bash cargo fmt --all -- --check cargo check --all-targets cargo test --all-targets cargo clippy --all-targets -- -D warnings ``` 在首次貼入時，可先執行 `cargo fmt --all` 統一 Rust 格式，再執行上列檢查。若 CI 執行 clippy，需要指定所用 Rust toolchain 的版本並記錄實際 exit code。 ### `Cargo.toml` ```toml [package] name = "cwsr_reference" version = "0.1.0" edition = "2021" publish = false [lib] path = "src/lib.rs" ``` ### `src/lib.rs` ```rust //! CWSR Paper 07: minimal single-writer CPU semantic oracle. //! This is a deliberately narrow reference candidate, not a GPU runtime. use std::collections::{BTreeMap, BTreeSet}; #[derive(Clone, Copy, Debug, PartialEq, Eq, PartialOrd, Ord)] pub struct StateId(pub u64); #[derive(Clone, Copy, Debug, PartialEq, Eq)] pub struct WorldStamp { pub world_id: u64, pub revision: u64, pub epoch: u64, pub rule_revision: u64, pub schema_revision: u64, pub mod_digest: u64, // Toy fixture token; not a cryptographic hash. } #[derive(Clone, Copy, Debug, PartialEq, Eq)] pub enum Precision { Exact } #[derive(Clone, Copy, Debug, PartialEq, Eq)] pub struct Transfer { pub from: StateId, pub to: StateId, pub amount: i64, } #[derive(Clone, Debug, PartialEq, Eq)] pub struct Ticket { pub work_id: u64, pub source_event_id: u64, pub stamp: WorldStamp, pub due_epoch: u64, pub transfer: Transfer, pub precision: Precision, } #[derive(Clone, Copy, Debug)] pub struct ResourceBudget { pub cpu_allowed: bool, pub ram_free_bytes: u64, } #[derive(Clone, Copy, Debug, PartialEq, Eq)] pub struct CpuLease { work_id: u64, stamp: WorldStamp, expires_epoch: u64, reserved_bytes: u64, } #[derive(Clone, Debug, PartialEq, Eq)] pub struct CandidateReceipt { work_id: u64, stamp: WorldStamp, writes: [(StateId, i64); 2], total_before: i128, total_after: i128, algorithm: &'static str, } #[derive(Clone, Debug, PartialEq, Eq)] pub struct JournalRecord { pub ticket: Ticket, pub revision_after: u64, pub digest_after: u64, } #[derive(Debug, Clone, Copy, PartialEq, Eq)] pub enum Failure { InvalidFixture, WrongWorld, StaleWorld, WrongRules, WrongSchema, WrongMod, NotDue, DuplicateWork, BadTransfer, UnknownState, InsufficientBalance, ArithmeticOverflow, CpuForbidden, CapacityExceeded, LeaseMismatch, LeaseExpired, ReceiptMismatch, WorldInvariantViolation, RevisionOverflow, ReplayMismatch, } #[derive(Clone, Debug)] pub struct World { stamp: WorldStamp, balances: BTreeMap, applied: BTreeSet, journal: Vec, } impl World { pub fn new(stamp: WorldStamp, a: (StateId, i64), b: (StateId, i64)) -> Result { if stamp.revision != 0 || a.0 == b.0 || a.1 < 0 || b.1 < 0 { return Err(Failure::InvalidFixture); } let mut balances = BTreeMap::new(); balances.insert(a.0, a.1); balances.insert(b.0, b.1); Ok(Self { stamp, balances, applied: BTreeSet::new(), journal: Vec::new() }) } pub fn stamp(&self) -> WorldStamp { self.stamp } pub fn get(&self, key: StateId) -> Option { self.balances.get(&key).copied() } pub fn journal(&self) -> &[JournalRecord] { &self.journal } pub fn total(&self) -> i128 { self.balances.values().map(|v| i128::from(*v)).sum() } fn check_ticket(&self, ticket: &Ticket) -> Result<(), Failure> { let s = ticket.stamp; if s.world_id != self.stamp.world_id { return Err(Failure::WrongWorld); } if s.rule_revision != self.stamp.rule_revision { return Err(Failure::WrongRules); } if s.schema_revision != self.stamp.schema_revision { return Err(Failure::WrongSchema); } if s.mod_digest != self.stamp.mod_digest { return Err(Failure::WrongMod); } if s.revision != self.stamp.revision || s.epoch != self.stamp.epoch { return Err(Failure::StaleWorld); } if self.stamp.epoch < ticket.due_epoch { return Err(Failure::NotDue); } if self.applied.contains(&ticket.work_id) { return Err(Failure::DuplicateWork); } let x = ticket.transfer; if x.amount <= 0 || x.from == x.to { return Err(Failure::BadTransfer); } let from = self.get(x.from).ok_or(Failure::UnknownState)?; self.get(x.to).ok_or(Failure::UnknownState)?; if from < x.amount { return Err(Failure::InsufficientBalance); } Ok(()) } fn expected_writes(&self, t: &Ticket) -> Result<[(StateId, i64); 2], Failure> { let x = t.transfer; let a = self.get(x.from).ok_or(Failure::UnknownState)?; let b = self.get(x.to).ok_or(Failure::UnknownState)?; let next_a = a.checked_sub(x.amount).ok_or(Failure::ArithmeticOverflow)?; let next_b = b.checked_add(x.amount).ok_or(Failure::ArithmeticOverflow)?; Ok([(x.from, next_a), (x.to, next_b)]) } /// Fixture digest only: stable across map iteration order, not collision-resistant. pub fn digest(&self) -> u64 { let mut h = 0xcbf29ce484222325_u64; for (key, value) in &self.balances { for byte in key.0.to_le_bytes().into_iter() .chain(value.to_le_bytes().into_iter()) { h ^= u64::from(byte); h = h.wrapping_mul(0x100000001b3); } } h } pub fn verify_and_commit(&mut self, t: &Ticket, lease: &CpuLease, r: &CandidateReceipt) -> Result { self.check_ticket(t)?; check_lease(self, t, lease)?; let expected = self.expected_writes(t)?; let before = self.total(); let after = before - i128::from(self.get(expected[0].0).unwrap()) - i128::from(self.get(expected[1].0).unwrap()) + i128::from(expected[0].1) + i128::from(expected[1].1); if r.work_id != t.work_id || r.stamp != self.stamp || r.writes != expected || r.algorithm != "cpu-transfer-v1" || r.total_before != before || r.total_after != after { return Err(Failure::ReceiptMismatch); } if before != after { return Err(Failure::WorldInvariantViolation); } let next_rev = self.stamp.revision.checked_add(1) .ok_or(Failure::RevisionOverflow)?; // All checks above; no fallible step is allowed after the first world write. self.balances.insert(expected[0].0, expected[0].1); self.balances.insert(expected[1].0, expected[1].1); self.stamp.revision = next_rev; self.applied.insert(t.work_id); let digest = self.digest(); self.journal.push(JournalRecord { ticket: t.clone(), revision_after: next_rev, digest_after: digest, }); Ok(next_rev) } } pub fn admit_cpu(world: &World, ticket: &Ticket, budget: ResourceBudget) -> Result { world.check_ticket(ticket)?; if !budget.cpu_allowed { return Err(Failure::CpuForbidden); } // A conceptual bookkeeping reservation; not an OS allocator reservation. const RESERVATION_BYTES: u64 = 128; if budget.ram_free_bytes < RESERVATION_BYTES { return Err(Failure::CapacityExceeded); } let expiry = world.stamp.epoch.checked_add(1) .ok_or(Failure::LeaseExpired)?; Ok(CpuLease { work_id: ticket.work_id, stamp: world.stamp, expires_epoch: expiry, reserved_bytes: RESERVATION_BYTES }) } fn check_lease(world: &World, ticket: &Ticket, lease: &CpuLease) -> Result<(), Failure> { if lease.work_id != ticket.work_id || lease.stamp != world.stamp || lease.reserved_bytes != 128 { return Err(Failure::LeaseMismatch); } if world.stamp.epoch > lease.expires_epoch { return Err(Failure::LeaseExpired); } Ok(()) } pub fn execute_cpu(world: &World, t: &Ticket, lease: &CpuLease) -> Result { world.check_ticket(t)?; check_lease(world, t, lease)?; let writes = world.expected_writes(t)?; let before = world.total(); let after = before - i128::from(world.get(writes[0].0).unwrap()) - i128::from(world.get(writes[1].0).unwrap()) + i128::from(writes[0].1) + i128::from(writes[1].1); Ok(CandidateReceipt { work_id: t.work_id, stamp: world.stamp, writes, total_before: before, total_after: after, algorithm: "cpu-transfer-v1" }) } pub fn replay(initial: World, records: &[JournalRecord], budget: ResourceBudget) -> Result { let mut world = initial; for record in records { let t = &record.ticket; let lease = admit_cpu(&world, t, budget)?; let receipt = execute_cpu(&world, t, &lease)?; let revision = world.verify_and_commit(t, &lease, &receipt)?; if revision != record.revision_after || world.digest() != record.digest_after { return Err(Failure::ReplayMismatch); } } Ok(world) } #[cfg(test)] mod tests { use super::*; fn stamp() -> WorldStamp { WorldStamp { world_id: 7, revision: 0, epoch: 10, rule_revision: 1, schema_revision: 1, mod_digest: 0 } } fn world() -> World { World::new(stamp(), (StateId(1), 100), (StateId(2), 10)).unwrap() } fn ticket(w: &World, id: u64, amount: i64, due: u64) -> Ticket { Ticket { work_id: id, source_event_id: id + 100, stamp: w.stamp(), due_epoch: due, transfer: Transfer { from: StateId(1), to: StateId(2), amount }, precision: Precision::Exact } } fn budget() -> ResourceBudget { ResourceBudget {cpu_allowed:true, ram_free_bytes: 4096} } #[test] fn transfer_commit_and_replay() { let mut w = world(); let first = ticket(&w, 1, 30, 10); let lease = admit_cpu(&w, &first, budget()).unwrap(); let receipt = execute_cpu(&w, &first, &lease).unwrap(); assert_eq!(w.get(StateId(1)), Some(100)); // Candidate does not mutate. assert_eq!(w.verify_and_commit(&first, &lease, &receipt), Ok(1)); assert_eq!(w.get(StateId(1)), Some(70)); assert_eq!(w.get(StateId(2)), Some(40)); let saved = w.journal().to_vec(); let reconstructed = replay(world(), &saved, budget()).unwrap(); assert_eq!(w.digest(), reconstructed.digest()); } #[test] fn duplicate_work_rejected() { let mut w = world(); let t = ticket(&w, 1, 4, 10); let lease = admit_cpu(&w, &t, budget()).unwrap(); let r = execute_cpu(&w, &t, &lease).unwrap(); w.verify_and_commit(&t, &lease, &r).unwrap(); assert_eq!(admit_cpu(&w, &t, budget()), Err(Failure::StaleWorld)); let retried_with_current_stamp = ticket(&w, 1, 4, 10); assert_eq!(admit_cpu(&w, &retried_with_current_stamp, budget()), Err(Failure::DuplicateWork)); } #[test] fn stale_candidate_cannot_overwrite_new_world() { let mut w = world(); let old = ticket(&w, 4, 5, 10); let old_lease = admit_cpu(&w, &old, budget()).unwrap(); let old_receipt = execute_cpu(&w, &old, &old_lease).unwrap(); let new = ticket(&w, 5, 6, 10); let new_lease = admit_cpu(&w, &new, budget()).unwrap(); let new_receipt = execute_cpu(&w, &new, &new_lease).unwrap(); w.verify_and_commit(&new, &new_lease, &new_receipt).unwrap(); assert_eq!(w.verify_and_commit(&old, &old_lease, &old_receipt), Err(Failure::StaleWorld)); } #[test] fn altered_receipt_does_not_commit() { let mut w = world(); let t = ticket(&w, 8, 5, 10); let lease = admit_cpu(&w, &t, budget()).unwrap(); let mut r = execute_cpu(&w, &t, &lease).unwrap(); r.writes[0].1 = 123; assert_eq!(w.verify_and_commit(&t, &lease, &r), Err(Failure::ReceiptMismatch)); assert_eq!(w.stamp().revision, 0); } #[test] fn resource_deadline_and_rule_hard_gates() { let w = world(); let future = ticket(&w, 1, 3, 11); assert_eq!(admit_cpu(&w, &future, budget()), Err(Failure::NotDue)); let ready = ticket(&w, 2, 3, 10); assert_eq!(admit_cpu(&w, &ready, ResourceBudget {cpu_allowed:false, ram_free_bytes: 4096}), Err(Failure::CpuForbidden)); assert_eq!(admit_cpu(&w, &ready, ResourceBudget {cpu_allowed:true, ram_free_bytes: 0}), Err(Failure::CapacityExceeded)); let mut outdated = ready.clone(); outdated.stamp.rule_revision = 99; assert_eq!(admit_cpu(&w, &outdated, budget()), Err(Failure::WrongRules)); } #[test] fn invalid_transfer_is_never_proposed() { let w = world(); let too_large = ticket(&w, 11, 200, 10); assert_eq!(admit_cpu(&w, &too_large, budget()), Err(Failure::InsufficientBalance)); let reversed = ticket(&w, 12, -1, 10); assert_eq!(admit_cpu(&w, &reversed, budget()), Err(Failure::BadTransfer)); } } ``` ## 6.4 程式碼對應的正式語義 `WorldStamp` 將世界身份、版本、時間、規則、schema 與 MOD digest 綁定。此處 `mod_digest: u64` 只是 fixture 用的識別 token，**不是**具碰撞抵抗能力的 hash；正式引擎應改用經驗證的內容摘要／簽章、來源鏈及版本策略。`StateId` 是穩定邏輯身份，不可使用 GPU buffer offset 取代。 `World::new` 只接受兩個非負的初始帳戶且 revision 為零；這是為了防止讀者誤以為示範已涵蓋一般市場、多資產、跨尺度事件或大規模 ECS。未來資料匯入需保留 schema validation、重複 ID、資產上限及事件帳本校驗。 `admit_cpu` 根據到期、身份與容量生成一張邏輯 CPU lease；`reserved_bytes` 是簡化簿記示範，**沒有實際向 Windows 或 OS 預留實體記憶體**。因此這個 128-byte 配額不應被用作記憶體最佳化測試證據。 `execute_cpu` 只讀世界，產生 `CandidateReceipt`；`verify_and_commit` 重算合法轉帳結果，檢查內容是否完全等價，並由唯一 writer 完成實際修改。此處的重算很便宜，所以採用最保守的 full oracle；將來 GPU 候選不能假設一律以全量 CPU 重算驗證，必須依錯誤契約選擇 hash、抽樣、區間證明、精確 oracle 或其他具證據的驗證方案。 `World::digest` 是純粹示範 deterministic fixture digest，未包含全部遊戲事件、規則資料及未完成義務，也不是密碼學證據。正式存檔必須採用更強的狀態／歷史摘要契約，不能把它當成 tamper-proof 簽章。 ## 6.5 測例的涵蓋範圍 | Rust 測例 | 預期保證 | 仍未覆蓋 | |---|---|---| | `transfer_commit_and_replay` | 候選不改世界、提交守恆、可重播 | Crash-safe durable write | | `duplicate_work_rejected` | 舊票及同 ID 更新票皆拒絕 | 多 process 同時提交 | | `stale_candidate_cannot_overwrite_new_world` | 版本改變阻止舊 receipt | 細粒度 MVCC 最佳化 | | `altered_receipt_does_not_commit` | 候選竄改不能越過 Gate | GPU buffer 記憶體可見性 | | `resource_deadline_and_rule_hard_gates` | 預算、時間、規則硬拒絕 | 真實 OS allocator 與時間回撥 | | `invalid_transfer_is_never_proposed` | 金額、餘額不合法不得進入執行 | 任意型別經濟交易及浮點問題 | 上述是**預期測例**，本輪無 Rust toolchain 的情況下未聲稱 PASS。對審稿或工程交接，務必附上可複製的真實 `cargo test` 輸出及編譯器版本。 ## 6.6 單執行緒示例不等於跨執行緒安全 參考程式以 `&mut World` 維持單一可變 writer，在程序內可清晰表示「只有 Commit Gate 修改世界」。這並不自動保證：多執行緒中訂閱／事件的原子性、跨 CPU/GPU 記憶體可見性、裝置佇列完成順序、硬碟寫入原子性或 Rust FFI 的記憶體安全。擴充這些功能時必須另加競態、故障注入與 replay tests。 --- # 7. 從 CPU Oracle 走向可替換多後端 Runtime ## 7.1 工程化類型簽名 成熟版可將規劃、資源許可、計算及提交表示成四個接口。以下是**設計草案**，不是本篇第 6 章 `lib.rs` 已實現的四個 trait： ```rust pub trait RoutePlanner { fn propose(&self, req: &WorldRouteRequest) -> Result; } pub trait ExecutionAdmission { fn admit(&self, proposal: &RouteProposal) -> Result; } pub trait CandidateExecutor { fn execute(&self, lease: &Reservation, input: &ImmutableSnapshot) -> Result; } pub trait WorldCommitAuthority { fn verify_and_commit(&mut self, proposal: &RouteProposal, receipt: &CandidateReceipt) -> Result; } ``` `WorldRouteRequest`、`RouteProposal`、`Reservation`、`ImmutableSnapshot` 與 `CommittedWorldRevision` 應在正式 crate 中定義為具版本及審計能力的 typed structs，不應在 API 中隱藏成未受檢查的 `serde_json::Value` 或裸 `void*`。上述接口有意保持可由不同引擎實作；不能推斷此處已有通用跨平台 FFI ABI。 ## 7.2 Snapshot Token 不應只是整數 正式 snapshot token 除世界 revision 外，還應攜帶 rule/schema/MOD lineage、時間切面、讀集合版本及使用的精度契約。若 GPU 在另一個 process 或佇列上持有更舊副本，僅比較 canonical revision 可能不足以判斷副本與候選是否有效。`ReplicaRef`、device generation、completion fence 和 snapshot identity 必須相互綁定。 ## 7.3 候選結果需要證據族，不只是 `bool success` 推薦的 receipt 描述： ```text CandidateReceipt { work_id, route_id, input_world_stamp, dependency_versions, required_lease_ids, backend_name, backend_version, algorithm_hash, shader_hash_if_any, device_submission_id, device_fence_if_any, output_replica_generation, precision_evidence, scale_transition_evidence, output_candidate_writes, measured_costs, timestamp_and_epoch, error_or_recovery_code } ``` CPU 可以沒有 shader 與 device fence，不能因此以虛假的 GPU 完成事件補齊欄位。當後端報告 device loss 時，其受影響候選都必須進入 invalid/retry，而不是由另一個未校驗 buffer 繼續寫入。 ## 7.4 Backend Feature Negotiation `GpuComputeAvailable`、`GpuKernelVerified`、`ExactPrecisionSupported`、`BudgetReserved`、`RenderHeadroom`、`ReadbackPathAvailable` 與 `RecoveryPathVerified` 應當分別檢查。裝置支援 Compute Shader 不等於指定世界 kernel 可以以相同數值語義運行；平台差異需要保守 fallback。 ## 7.5 退出 GPU 路徑也要有成本 使用 GPU 的主要問題不只是 dispatch latency，而是進入、維持及退出某段設備常駐工作鏈的完整代價。CPU／GPU 決策至少比較 kernel、batch、transfer、synchronization、render contention、memory residency、readback、verification、fallback probability 及 route-switch cost。若 GPU kernel 很快，但必須每幀將小量結果同步回 CPU，選擇 CPU route 可能更合理。 --- # 8. 24／72 FormBlind／FormAware 雙軌路由 ## 8.1 為什麼需要兩個真正公平的實驗組 若新 RoutePlanner 同時加入 SIMD、事件化、GPU 批次、資料布局優化和 24／72 classification，就算勝過舊遊戲迴圈，也不能分辨究竟是什麼帶來收益。Paper 06 已規定 B4／B5 近似「只差分類註記」的對照；Paper 07 必須在同一段演算法、硬體、硬門檻與成本證據上保存這個實驗能力。 ## 8.2 Canonical Form 只描述語境中的計算形態 保留原始 24 格： $$ \mathfrak P_{24}=\mathfrak B_2\times\mathfrak U_4\times\mathfrak O_3. $$ 其中 $\mathfrak B_2$ 是 Continuous／Discrete 底空間， $\mathfrak U_4$ 是 Sequential／Jump／Parallel／Recognition 更新模式， $\mathfrak O_3$ 是 Continuous／Discrete／Single-Measure-Refusal 觀察類型。 72 格在此基礎上加入候選轉移律： $$ \mathfrak P_{72}=\mathfrak P_{24}\times\mathfrak L_3, \quad \mathfrak L_3=\{\mathsf F,\mathsf K,\mathsf Q\}. $$ $\mathsf F$ 表示函數式／確定性型， $\mathsf K$ 表示機率核型， $\mathsf Q$ 表示相干／量子通道型。將 $\mathsf Q$ 寫入分類空間，不表示 PC 遊戲有量子硬體或必須模擬量子通道。未建立明確 semantics、分類證據或 hardware mapping 時，應標記為 `Unclassified` 或 `UnsupportedForm`，而不是假設任何 GPU 等價。 ## 8.3 建議的 FormProfile 結構 ```text FormProfile { basis_version, observation_context_id, rule_revision, scale_contract_id, kind = Single | Set | Path | Stack | Unclassified, forms[], classification_evidence_id, classification_cost, expiry_condition } ``` 對一個混合「天氣網格 + 局部豪雨觸發 + 城市洪水離散事件」的工作，不應強迫整條運算被貼成單一類別。它可能包含多個連續場與離散觸發組件，形式相對於不同工作片段而異。 ## 8.4 硬門檻之前不能直接按 Form 選裝置 錯誤範例： ```text if update_mode == Parallel { backend = GPU; } else if update_mode == Sequential { backend = CPU; } ``` 正確方向：先建立合法工作候選，依依賴、精度、資源與 deadlines 做硬過濾，然後以 FormProfile、work shape 和成本證據縮小候選或排序；不具備有效證據時採同一個 FormBlind decision 或固定 CPU fallback。 ## 8.5 Classification Tax 必須包含在總成本 假設加入 FormAware 後，分類和維護 metadata 的成本為 $C_{\mathrm{form}}$，優化路由節省的工作成本為 $\Delta C_{\mathrm{route}}$，則只有在指定工作條件下： $$ \Delta C_{\mathrm{route}}>C_{\mathrm{form}}+C_{\mathrm{switch}}+C_{\mathrm{monitor}} $$ 且沒有更差的義務期限、精度或尾延遲時，才可能形成淨效益。這不是全域性能定理；成本與差值須由 Paper 08 測量。 ## 8.6 Form-aware ablation 清單 - 只停用 FormAnnotation，其餘 routing policy 不變。 - 只停用 Form-driven candidate pruning，保留 metadata trace。 - 只停用 hysteresis，觀察 churn 及 p99。 - 將 `Unclassified` 全部轉成 FormBlind，檢查未知比例。 - 對相同 workload 更換 observation resolution，檢查分類與效能是否穩定。 - 固定資料布局、batching、kernel、GPU clock 及 render workload，避免比較不公平。 --- # 9. GPU 世界小流的真正實作邊界 ## 9.1 因果小流不是「一個事件對應一個 dispatch」 Paper 05 的 `CausalMicroflow` 指具備已驗證依賴、guard、期限與結果契約的局部世界工作。若每一個 NPC 狀態變化都產生一次 GPU submit，很可能因同步、驅動及資料搬移而比 CPU 更慢。Runtime 應由工作形狀及 hazard 安全規則決定 batch frontier，限制最大等待窗口與最大資料量。 ## 9.2 GPU Candidate Batch ```text GpuCandidateBatch { world_stamp, sim_epoch, domain_id, stable_work_ids[], resource_lease, input_replica_refs[], output_replica_refs[], read_write_hazard_certificate, kernel_id, kernel_hash, dispatch_shape, deadline_bounds, precision_contract, submission_id, completion_fence, verification_policy } ``` 任何缺失依賴、共享寫入衝突、不可對齊時間切面的工作，都應在 batch 前被拆開或退回 CPU／序列執行；不能因為 GPU 很適合平行運算就忽略世界事件的可觀測次序。 ## 9.3 完成事件的順序要求 ```text CPU plan -> budget lease -> buffer creation/validation -> GPU submission -> in-flight -> fence reached -> readback or device-side evidence -> candidate receipt -> Commit Gate -> world revision ``` `GPU dispatch submitted`、`GPU command completed`、`candidate validated`、`world committed`、`render frame presented` 至少是五個不同概念。若上游世界在 fence 前已變，完成後的 GPU 候選可能需要丟棄，不能為省成本繞過版本規則。 ## 9.4 對消費級 GPU 的公平性 在 GPU 渲染高壓時應保留 graphics headroom，必要時降低背景 compute batch 而不是硬把顯示卡推到耗盡。RAM、VRAM、PCIe 傳輸、upload/readback queues 和 CPU 程式時間一起納入成本。不同顯示卡的 VRAM、記憶體頻寬與 compute capability 差異可能讓最佳路由不同，不能假設「消費級顯卡都應 GPU-first」。 ## 9.5 裝置常駐資料鏈 若連續的 GPU 世界工作合法共用同一代版本的資料，結果可留在 GPU，讓下一個 kernel 使用，不必在每個階段回 CPU。這有可能降低傳輸與 staging 成本；但只要某階段存在 CPU-side authoritative decision、外部不可延遲事件或跨尺度證據義務，就必須按規則同步或產生可由 Gate 使用的等價證書。 ## 9.6 GPU 故障與恢復程序 | 故障點 | 正確動作 | 禁止動作 | |---|---|---| | Dispatch 前資源不足 | 回傳 Typed Capacity failure，考慮 CPU | 宣稱 dispatch 成功 | | Dispatch 後 device loss | 受影響 receipt 全部失效，lease 釋放／撤銷 | 重用不可信 buffer | | Fence 超時 | 停止 commit、保存 Ticket、可重試 | 因時間壓力猜測 GPU 完成 | | Shader hash 改變 | 重新驗證 kernel／規則兼容 | 沿用舊證據 | | 失去 CPU recovery path | 明確 `NoSafeFallback`，保留世界不變 | 偽造回滾結果 | | Render 壓力升高 | 收縮 compute quota 或延期允許之工作 | 犧牲已承諾重要期限 | ## 9.7 第一版 GPU kernel 應選低風險負載 優先選擇一個可精確對照 CPU 的城市商品需求更新或純數值網格算子；使用固定 input layout、已知精度契約及可重現 fixture。先處理單個 kernel family 的 device fence 和 CPU oracle，再擴充更多世界子系統；不宜一開始選擇帶大量腳本分支、MOD 可變規則或全域即時副作用的 NPC AI。 --- # 10. 宏觀—中觀—微觀模型的 Adapter 契約 ## 10.1 Scale View 不是三個可互相覆蓋的世界副本 一個城鎮的微觀居民、街區活動、商品物流及宏觀經濟不是三份彼此競爭的 canonical world。它們是同一權威世界在不同尺度／時間精度下的合法視圖。粗尺度計算可使用摘要，但摘要無權擦除已提交身份、唯一物品、事件或資產帳本。 ## 10.2 最小跨尺度輸入 ```text ScaleWorkContext { world_stamp, target_domain_id, current_scale_view, proposed_scale_view, identity_anchor_index, event_journal_position, boundary_flow_ledger, temporal_cut, precision_contract, transition_policy_id, materialization_budget } ``` 粗尺度世界與細尺度世界不能僅依鏡頭距離判斷切換。若玩家遠在外地，但遠方發生會改寫重要角色命運的世界事件，也可能需要更細的因果處理；相反地，近處大量未參與互動的背景人口未必都要每幀具備完整行為樹。 ## 10.3 Aggregation／Refinement 須有來源與不變量 假設微觀狀態集合為 $X_{\mu}$，中觀摘要為 $X_m$，宏觀摘要為 $X_M$。可考慮有條件的聚合映射： $$ A_{\mu\rightarrow m}:X_{\mu}\rightarrow X_m, \qquad A_{m\rightarrow M}:X_m\rightarrow X_M. $$ 但一般不成立： $$ A_{\mu\rightarrow m}^{-1}(X_m)=X_{\mu}. $$ 因此 Runtime 在尺度細化時，必須從 identity anchor、event journal、既有保存個體資料與明示的生成政策產生**與已提交事實一致的條件實現**，不得將原本不可恢復的微觀歷史偽裝為觀測結果。 ## 10.4 時間切面的提交責任 `TemporalCut` 不是單一 `float time`。它應記錄各尺度可讀取的已提交進度、跨區域事件邊界、尚未完成的高優先級義務及源規則 epoch。若跨城市物流在 epoch 20 已從 A 扣除、卻直到 epoch 25 才到達 B，狀態可以合法代表在途資產；但不允許 A 和 B 同時將同一批貨物記作自由可用的庫存。 ## 10.5 區域交換 Ledger 的保守規則 - 流量須以穩定 Event ID 和來源／目的域記錄。 - 微觀事件造成的上行變化須在宏觀摘要中可追溯。 - 宏觀政策造成的下行變化須有生效 epoch，不得穿越既有已提交歷史。 - 對資產、人口等有守恆要求的量，需有跨域 ledger 與增減來源證據。 - 經過近似的群體狀態需綁定誤差界限，不能因 UI 不可見而默認精確。 ## 10.6 具名 NPC 與匿名人口要分不同約束 具名角色的身份、關係、死亡、承諾及唯一持有物等資料可能具有不可丟失的敘事義務；匿名人口可按規則採統計描述或程序化條件細化，但兩者不能因為都叫 NPC 而互換恢復策略。ScaleBridge 應先判斷哪些資訊可聚合、哪些需要錨點或不可壓縮來源。 ## 10.7 跨尺度候選的拒絕回條 不具備時間切面、identity anchors、不可逆歷史來源或合法誤差界限時，回傳 `ScaleProofMissing`、`TemporalCutMismatch`、`UnrecoverableHistory` 或 `PrecisionContractViolation`。`FallbackToMicro` 並非必然可行；若恢復資料已丟失，必須承認安全路由不存在。 --- # 11. 記憶體、所有權與版本化物化協定 ## 11.1 Rust 語言所有權與遊戲世界權威不同 Rust 借用與生命週期可防止許多未定義記憶體操作；但 `&mut T` 不自動證明世界因果、跨尺度歷史或交易規則正確。需要另行區分： 1. **Memory Owner：** 誰管理 CPU/GPU buffer。 2. **Logical Owner：** 哪個狀態身份及版本被引用。 3. **Execution Authority：** 哪個計算工作能讀寫候選。 4. **Mutation Authority：** 哪個 Commit Gate 有權修改 canonical world。 5. **History Custodian：** 誰維護可恢復的事件及重播證據。 這些權限可以在同一進程內實作，但不能在資料模型上混同。 ## 11.2 物化狀態機 ```text Addressable -> MaterializeRequested -> Allocated -> Validated -> Resident -> Pinned / InFlight / Idle -> EvictionCandidate -> EvictionVerified -> Released \-> RecoveryNeeded -> Rematerialize ``` `Released` 並不意味世界事實被刪除，前提是狀態存在可合法恢復的邏輯表示或歷史來源；對不能重建的資料，系統不得僅靠低優先級標籤就予以回收。 ## 11.3 有界但可調整的記憶體宣告 每個區域可預先宣告：`minimum_resident`、`soft_limit`、`hard_limit`、`growth_policy`、`eviction_priority`、`recovery_cost`、`pinned_generation`、`deadline_reserve` 和 `preferred_devices`。這表示**不必於啟動時實際配置所有容量**，而非無成本無界使用記憶體。 ## 11.4 Device Fence 與借用關係 如果 GPU kernel 正在讀取 input buffer，或渲染工作正在消費該 generation，CPU 端不得因 Rust 變數已離開 lexical scope 就提前重用裝置底層記憶體。`GpuReplicaLease` 應記錄 queue、submission、fence、generation 和所有尚未結束的讀寫使用者；只有確認沒有 in-flight 使用者且有合法恢復路徑時，才能 evict。 ## 11.5 Copy-on-Write 不是版本安全的充分條件 即使使用 CoW，若新寫入頁面仍被標記為舊 ruleset 的合法計算結果，仍可能產生邏輯污染。版本判斷須包含計算結果真正依賴的 rule、schema、MOD、scale、precision 和 source evidence，不能只看 page pointer 是否變更。 ## 11.6 Memory Pressure 不能破壞玩家畫面 背景 world compute 可使用被管理的 VRAM quota，但不能將 GPU 畫面輸出視為永遠低優先級。對玩家輸入延遲、渲染幀時間和已承諾世界期限，應提供可配置的 hard/soft constraints。當同時無法滿足所有 hard requirements，允許拒絕或暫停相關操作，而不是默默跳過必要世界事件。 --- # 12. Godot Engine 的薄適配規格 ## 12.1 為什麼不需要取代 Godot Godot 既有的 SceneTree、輸入、UI、動畫、物理、渲染、資源載入與場景編排可以繼續運作。CWSR 只對指定的世界模擬子系統提供一條可獨立測試的狀態與計算路徑。強行接管所有 Node 每幀邏輯，既不符合 CWSR 的選擇性原則，也會提高原型風險。 ## 12.2 Host API 的建議邊界 ```text CwsrHost.submit_intent(intent: TypedGameplayIntent) -> TicketId | Rejection CwsrHost.advance_simulation(requested_epoch, budget) -> StepOutcome CwsrHost.poll_world_revision() -> RevisionInfo CwsrHost.read_projection(scope, revision) -> ReadOnlyProjection CwsrHost.acknowledge_projection(revision) -> Ack CwsrHost.query_pending_obligations() -> ObligationSummary CwsrHost.pause_world_time(reason) -> TimePolicyResult ``` 以上為建議 API，並非 Godot 當前已有的原生函式名。真正 GDExtension／FFI 綁定需要依正式 Godot 版本及 ABI 文檔另行實作驗證。 ## 12.3 一個可行的 Godot host 循環 ```text _process(delta): gather_ui_and_input_intents() enqueue_non_authoritative_intents() consume_read_only_projection_if_ready() update_visible_nodes_on_main_thread() _physics_process(fixed_delta): if world_time_policy_allows: submit_due_simulation_epoch(fixed_delta) process_bounded_runtime_results() ``` 它只是 Host-side pseudocode，不是可直接貼入的合法 GDScript。主執行緒與工作執行緒的實際互動應遵循特定 Godot 版本的資源與節點 thread-safety 規則；不可因 CWSR 使用 Rust 就默認任意 SceneTree 操作可並行。 ## 12.4 UI 只讀投影，不是世界副本作主 玩家所看到的角色屬性、背包、城鎮商品價格與 NPC 日程，可由 Runtime 已提交 revision 生成唯讀 projection。UI 動畫、字串漸變與材質插值是呈現層效果，不得自行代表權威物品已增加或角色已死亡。UI 暫時落後於世界可被允許，但必須有 consistency/freshness policy。 ## 12.5 既有物理及動畫系統可維持固定步進 連續碰撞、骨骼動畫和某些物理積分需要連續或固定更新時，保留既有 Godot 行為。CWSR 可管理周邊世界狀態、休眠與遠端區域經濟，但不能為了統一性而要求將所有高頻狀態轉成離散事件。 ## 12.6 避免主迴圈中的同步等待 同步等待 GPU Readback、檔案序列化或跨執行緒鎖，可能造成可觀測掉幀。Host Adapter 應在設定的 frame budget 內收集已完成回執，不等待不必要的遠端事件；對不可延後的玩家操作，提供正確但可能較慢的 CPU 路徑，或給出明示的進度等待機制。 ## 12.7 Engine Binding 的版本與錯誤面 Host adapter 的版本表至少包含：`engine_version`、`cwsr_schema_version`、`ffi_abi_version`、`world_ruleset_digest`、`gpu_backend_version`。若版本不兼容，應拒絕載入危險世界寫入接口，允許只讀診斷或 migration path。沒有正式轉換契約的舊存檔不得被強制解讀為當前版本。 --- # 13. EveWorld Engine 與其他引擎的抽象介接 ## 13.1 不把 EveWorld 當成已完成的依賴 EveWorld Engine 可成為 CWSR 未來實驗 host，但本文沒有讀取並驗證其現有最新實作的全部接口，因此不聲稱存在相容的現成 Rust plugin。優先採 `WorldHostAdapter` 抽象：CWSR 保持對單一遊戲引擎的依賴最小化；EveWorld 可選擇從 GameLoop、WorldModel、Scheduler 或 SimulationServices 其中合適層級接入。 ## 13.2 可共享的跨引擎契約 - 同一 `WorldStamp` 與 `Ticket` 格式。 - 同一提交策略及 idempotent work ID。 - 同一 fixture 與重播工具。 - 同一基本可觀測狀態核對。 - 不同 engine adapter 只可改變顯示與事件輸入映射，不能任意改寫核心世界規則。 ## 13.3 三種合法整合模式 **模式 A — Library Mode：** Runtime 作為 Rust 動態／靜態庫；遊戲主迴圈直接呼叫。適合精簡、延遲敏感的單機測試。 **模式 B — Process Mode：** 世界模擬獨立進程，以本地 IPC 發送 intent 和 read-only projection。適合隔離故障及調試，但增加序列化與 IPC 成本。 **模式 C — Offline Simulation Mode：** 不開圖形視窗，只載入 fixture、跑世界時間、輸出可重播結果；適合 Paper 08 的大規模語義與效能測試。 三者可採相同語義但效能未必相同；初版通常應優先使用離線模式驗證規則，再導入 Library Mode 及引擎渲染壓力。 ## 13.4 MOD 與腳本界限 若 MOD 直接改動世界規則、腳本工作或物件關係，必須重新評估依賴圖、規則 digest、GPU kernel 相容性與存檔契約。可以提供 Script Hook，但 Hook 不得繞過世界修改權；建議先把 script intent 轉成 checked command，再由 Runtime 接手後續流程。 --- # 14. 並發、事件訂閱與不漏喚醒 ## 14.1 單執行緒參考核心的安全性只在受限論域成立 Paper 07 的 Rust 樣例因沒有第二個實際並發 writer，也沒有 GPU 執行佇列，因此不會遇到多執行緒 `lost wake-up`。這不是證明完整 CWSR 不會漏事件。當引入 Worker Threads、Godot 回呼和 GPU async jobs，必須正式加入 Paper 02 的 Subscription Barrier。 ## 14.2 訂閱競態的典型反例 ```text Thread A: 讀取「城市道路可通行」= true Thread B: 提交道路被炸毀 Thread A: 之後才註冊道路變化訂閱 Thread A: 睡眠，永遠沒收到已發生事件 ``` 正確作法必須使用「訂閱與版本檢查不可漏掉中間事件」的協定。可以在同一把鎖下訂閱及檢查，或使用事件日誌位置與原子 epoch，再在訂閱建立後重查版本差異；不能僅依兩次普通讀取靠運氣避免競態。 ## 14.3 建議的保守訂閱屏障 ```text snapshot = read_world_versioned() subscribe(event_index, work_dependencies, snapshot.revision) current = read_committed_revision() if current != snapshot.revision: revalidate_dependencies_or_requeue() else: mark_dormant_with_subscription_certificate() ``` 以上是邏輯協定，不表示任意 lock-free memory ordering 都正確。正式實作須指定線性化點、原子內存序、事件保留策略與 replay cursor，不應用 GIL 或 Rust Borrowing 當作完整併發正確性證據。 ## 14.4 高扇出因果圖不必逐個物件熱更新 如果一次宏觀政策造成全國城市潛在影響，可以先持有版本化的 domain-level invalidation，對真正需要精細值的子域再展開。前提是觀察截止時刻、下游必要義務和依賴完整性受到保全；不能把數千個實際已到期的重要事件簡單標示為「域已失效」就不處理。 ## 14.5 迴圈依賴的處理 對高耦合回饋（價格—供需—物流—價格），可採有界固定點迭代、明示 epoch phase、或模型允許的數值收斂策略。若不能證明收斂或容許誤差，應返回 `UnresolvedCycle`／保守 fixed-step，而不是無限制安排工作造成飢餓、或強行接受暫態值為權威。 ## 14.6 跨 CPU/GPU 記憶體可見性 CPU 看到 fence signal 仍需依 graphics API／memory model 正確處理 buffer barriers、host/device coherency、cache invalidation 與 resource ownership transfer。不能把 `fence reached` 簡化為「隨意讀取同一塊 CPU 指標」。所有這些 API-specific 細節必須由被驗證的 GPU adapter 實作。 --- # 15. 持久化、崩潰恢復與確定性重播 ## 15.1 存檔不能只存畫面與人物數值 真正的存檔最少應能重建：canonical world snapshot、規則和 MOD 版本、時間 epoch、唯一身份／資產、尚未完成的義務、可恢復依賴訂閱、事件去重鍵、跨尺度帳本及必要的 RNG counter／seed。對 in-flight GPU work，通常只保存可恢復的工作描述與來源版本，不能假設重開遊戲後舊 GPU fence 仍有效。 ## 15.2 Crash-safe 提交的兩個正當方向 **WAL-first：** 先 durable append 已驗證的 commit intent 與交易標識，按照資料庫約束實際修改 snapshot，再標記 durable completion；恢復時依 idempotent record 重做或回滾。 **Atomic Snapshot + Journal：** 在明示檔案系統與儲存語義下寫入 versioned snapshot + journal，使用可驗證的原子替換／校驗和備援檔，恢復時由最後一致位置重播。 這兩種只是設計方向，不能從第 6 章記憶體中的 `Vec` 推論已具 crash durability。實際落地應指定 `fsync`／rename／directory sync 與 OS/filesystem 邊界及 fault injection 實測。 ## 15.3 Replay 是重新執行規則，不是重播動畫 Replay engine 從固定初始狀態、規則版本、seed/counter 和事件順序，重新計算並比對每次 commit 的 semantic state hash。動畫、鏡頭和 GPU 畫面可不重放，除非研究目標另含視覺確定性。帶浮點差異的工作按 precision contract 使用指定容許誤差，而不是要求所有顯示卡 bitwise 一致。 ## 15.4 隨機性不能被不斷重算任意消耗 若 NPC 使用 RNG 決定日常事件，跳過計算可能改變亂數消耗序列，進而影響其他角色。建議以 world/domain/entity/epoch/event-key 的 counter-based 或有明示隔離的 RNG streams 來固定語義；即使可重播，也要測試不同路由是否維持指定分布或確定結果。 ## 15.5 預測預載不得出現在已提交歷史中 Causal Frontier 預估只用來提前準備資源、編譯 kernel、載入快取或暖化資料。預測中某個 NPC 可能去市場，不代表 NPC 實際去過市場；預熱事件不能產生遊戲故事、獎勵或紀錄，直到規則級真實事件通過 Commit Gate。 ## 15.6 存檔的調試欄位 推薦持久化或旁路記錄：`world_id`、`revision`、`sim_epoch`、`ruleset_hash`、`schema_hash`、`mod_digest`、`journal_offset`、`last_committed_event_id`、`rng_policy`、`resource_policy_version`、`allocator_version`、`router_policy_version`、`engine_adapter_version`。其中 router 和硬體後端不一定屬於世界語義的一部分，但有助於定位回放性能與非決定性差異。 --- # 16. 端到端世界案例與範例事件軌跡 ## 16.1 Case A：橋梁損壞、道路中斷與跨尺度供需 假設玩家在 `epoch = 200` 炸毀城市 A 與 B 之間的橋。此事件有穩定 `source_event_id` 並透過 Commit Gate 成為權威事實。系統不得只更新附近橋樑模型，還必須檢查：道路可通行性、預約中的貨車路線、兩地物流、在途貨物、城市商品供給、價格及影響 NPC 日程的義務。遠方城市可以保留中觀摘要，但與橋樑依賴的物流路由需要失效或重新評估。 **合法工作流：** 微觀橋樑狀態提交 → 地區交通 domain invalidation → 重新計算受影響物流 → 以中觀商品供需更新候選 → 跨區域 ledger 校驗 → macro summary 與 NPC 購物介面依訂閱更新。 **不合法工作流：** GPU kernel 直接改寫城市 B 的 canonical 價格，因為其計算完成而略過道路事件版本比對；或由宏觀總量逆推某具名 NPC 已經完成一趟不存在的送貨任務。 ## 16.2 Case B：沉睡的具名 NPC 在十日快轉後重逢 玩家快速旅行十天，遠方具名 NPC 的完整行為樹平時未執行。合法的休眠方案應保留其身份、已有裝備、任務承諾、到期事件、必要隨機流及可能影響他者的約束。若從粗尺度日程直接細化成故事敘述，必須分清楚「已提交實際事件」與「在規則及已知事實下可接受的條件補全」。 重逢時不能偷偷新增一份具名角色副本，也不能憑人口統計平均值決定其生死。若某時間窗口需高精度事件模擬卻已被不當丟棄，安全策略可以是重新播放保存事件、進行保守回退，或明示 `UnrecoverableHistory`；不可偽裝為無損結果。 ## 16.3 Case C：百萬居民的數值需求、GPU 與渲染壓力 遠方世界有大量匿名居民的簡單可平行需求更新。Runtime 可選擇以連續數值狀態批次在 GPU 上更新，但只在資料布局規整、路由依賴可證明、資料已合適駐留、kernel 精度被驗證並有 render headroom 時採用。若顯卡 VRAM 緊張、畫面需要高幀率或批次過小，使用 CPU SIMD／Job System 可能更好。 本案例需要至少三個證據：計算正確性與 CPU oracle 的對照、包含 device transfer/fence/commit 的完整延遲，以及遊戲渲染 p95/p99 frametime。只顯示 GPU kernel 吞吐不構成遊戲總體性能勝利。 ## 16.4 Case D：MOD 增加經濟規則 原本居民需求只依賴收入與商品價格，MOD 新增疾病影響、派系禁令及倉庫封鎖條件。舊依賴圖、分類註記、GPU kernel、快取與跨尺度摘要可能同時失效。正確的更新程序先提升 rule/MOD revision，將舊計畫標記為 stale，重建或否決受影響的 cache/route/kernel，並保留所有尚未完成的合法義務；不得只熱替換函式指標再繼續沿用已 in-flight 的 GPU 世界結果。 ## 16.5 Case E：遊戲停止在選單但世界時間由規則決定 當玩家打開暫停選單，遊戲可按設計合法暫停 simulation clock，並繼續 UI／畫面動畫；亦可設計為世界時間持續推進。CWSR 不能從「螢幕沒變」推導自動休眠全世界，而須根據 `TimePolicy`、事件期限及遊戲規則確定哪些工作需要繼續。此案例直接對應系列最初從 DOSBox-X 畫面與程式執行不對應的觀察。 --- # 17. Conformance Matrix：正式的工程正確性義務 ## 17.1 檢查項目與失敗觸發 | ID | 情境 | 必須通過的行為 | 失敗意味 | |---|---|---|---| | C07-01 | Candidate 尚未提交 | 權威世界保持原值 | Executor 越權 | | C07-02 | 正確票證、正確版本 | 原子提交一次並遞增 revision | 提交路徑錯誤 | | C07-03 | 同 work ID 重送 | 不再次生效 | 無冪等保護 | | C07-04 | Snapshot 版本過期 | 拒絕舊結果 | Stale commit | | C07-05 | Rule／MOD 版本不同 | 拒絕或重新規劃 | 舊規則污染 | | C07-06 | 未到期 Ticket | 等待、不得提前提交 | 時間義務錯置 | | C07-07 | 動態負向依賴改變 | 喚醒或保守退回 | 漏失效 | | C07-08 | 訂閱建立與世界變更競態 | 補查 revision／重排 | Lost wake-up | | C07-09 | 資產轉移與跨域物流 | 數量總帳一致 | 重複或遺失資產 | | C07-10 | 具名 NPC 尺度切換 | 身份及已提交歷史不變 | 身份偽造 | | C07-11 | 聚合後試圖還原未知歷史 | 拒絕或有條件生成 | 虛構被當事實 | | C07-12 | 路由超出 RAM 預算 | Typed reject/fallback | 虛假資源許可 | | C07-13 | GPU VRAM 不足 | 不 dispatch，保留義務 | 過量分配 | | C07-14 | GPU fence 未到 | 不提交／不回收受用 buffer | 提前讀取或釋放 | | C07-15 | Device loss | 撤銷受影響結果 | 不可信候選被採納 | | C07-16 | Candidate 內容遭竄改 | Gate 拒絕且世界不變 | 驗證薄弱 | | C07-17 | Fixed-step 必要子系統 | 不因事件化漏步進 | 模型轉換錯誤 | | C07-18 | GPU 計算碰到高渲染壓力 | 遵守 render／world 合約 | FPS 和期限搶占失控 | | C07-19 | 存檔期間崩潰 | 恢復最後一致權威狀態 | Durability 缺陷 | | C07-20 | Replay 相同事件及規則 | 指定精度下世界一致 | 非決定性未被治理 | | C07-21 | Shadow B7 略過 hard gate | 只可影子執行、不可提交 | 研究危險干擾玩家 | | C07-22 | FormAware 註記缺失 | 回落 FormBlind，世界仍正確 | 分類被錯當必要依賴 | | C07-23 | 高扇出耦合／循環 | 有界排程或 typed fail | 飢餓／永不收斂 | | C07-24 | GPU buffer 復用世代錯誤 | 拒絕舊 generation | ABA 類錯誤 | | C07-25 | Router 沒有合法候選 | 給出明確原因 | 偷偷刪義務 | | C07-26 | Host 非主執行緒操作 UI | 拒絕／轉發主線程 | Engine thread-safety 破壞 | | C07-27 | 工作快速連續兩次改值 | 版本與事件次序保留 | 混用新舊狀態 | | C07-28 | 不可恢復狀態欲回收 | 禁止或持久化後再回收 | 丟失世界事實 | | C07-29 | 分類座標錯誤／混合不可判 | Unclassified／保守策略 | 語義硬塞 24／72 | | C07-30 | 需求與路由成本過高 | 允許固定 CPU 最優策略 | 管理成本變成教條 | ## 17.2 測試的分層驗收 **Core Unit：** C07-01–06、12、16、20、22、25、27；至少以不依賴引擎的 CPU fixture 先跑通。 **Scheduler Concurrency：** C07-07、08、17、23；需加入並發與 time-jump fault injection。 **Scale／Memory：** C07-09–11、28；需真實保存個體 identity anchors 與 ledger。 **GPU／Host：** C07-13–15、18、24、26；必須使用真實後端／驅動／引擎主線程驗證。 **Research Controls：** C07-21、29、30；驗證新路由不因分類或理論主張僭越正確性。 ## 17.3 Conformance 不等於效能勝利 通過 C07-01–30 只能表示指定場景下契約有一定工程支持。它仍不能證明 CWSR 更快、更省電、更節省 VRAM、能同時模擬更多 NPC，或適用所有消費級硬體。這些必須由 Paper 08 的公平測試另行建立。 --- # 18. Benchmark Harness：提供 Paper 08 的強基線 ## 18.1 對照組必須與前篇相同 | Benchmark | 定義 | 主要用途 | |---|---|---| | B0 | Naive per-frame update | 僅供最原始參照 | | B1 | 成熟 CPU ECS／SIMD／Job System | 檢查一般 CPU 最佳化收益 | | B2 | CPU Event／Dirty／Deadline | 檢查因果稀疏排程的增量 | | B3 | 成熟 GPU Direct Compute | 檢查 GPU 執行路線的本來收益 | | B4 | FormBlind 異質路由，同一 gates/cost | 一般異質規劃強基準 | | B5 | B4 + FormAware 24／72 metadata | 檢查分類是否有額外價值 | | B6 | B5 + hysteresis/replanning/history | 檢查動態治理與切換收益 | | B7 | 隔離 shadow／ablation，不能寫世界 | 鑑別各 gate、成本欄位的作用 | ## 18.2 最小 Fixture 組合 - `sparse_npc_daily_001`：居民長時間不變，偶爾有期限及物品交互。 - `dense_population_002`：大量居民的規整數值更新。 - `bridge_trade_003`：橋樑毀損、物流路由、價格、帳本。 - `weather_field_004`：連續網格與離散雨災觸發。 - `fast_travel_005`：時間跳進、具名 NPC、死亡或任務到期。 - `mod_rule_shift_006`：運行中合法規則版本切換與失效。 - `render_pressure_007`：GPU 世界計算與高畫面負載競爭。 - `tiny_work_008`：小任務，預期 CPU 固定路由可能勝出。 - `high_conflict_009`：多事件讀寫同一地區／資產。 - `low_memory_010`：小 RAM／VRAM 工作集、預載／回收抖動。 ## 18.3 同規則、同義務、同期限 比較的每組必須滿足相同 world semantics、事件輸入、seed/counter、精度、可觀測量和時間截止條件。若某組使用更粗糙近似，其誤差界限及可接受玩法結果必須與其他組對齊。不得將減少規則義務或永久凍結遠方世界當成純性能改善。 ## 18.4 必報指標 $$ \mathbf M=(T_{50},T_{95},T_{99},L_{\mathrm{world}},D_{\mathrm{miss}},F_{95},F_{99},M_{\mathrm{RAM}},M_{\mathrm{VRAM}},B_{\mathrm{transfer}},C_{\mathrm{route}}). $$ 其中 $T$ 為工作端到端延遲分位數， $L_{\mathrm{world}}$ 為指定窗口內合法世界提交量， $D_{\mathrm{miss}}$ 為期限失誤， $F$ 為幀時間分位數， $M$ 為峰值記憶體， $B_{\mathrm{transfer}}$ 為資料搬移， $C_{\mathrm{route}}$ 為分類／路由額外成本。可再加入能源、GPU 占用、CPU thread time、replay divergence 與 failure recovery time。 ## 18.5 測量條件不能省略 報告 CPU 型號、核心與記憶體、GPU 型號和 VRAM、OS、驅動、Rust 版本、Godot 版本、shader backend、裝置溫度／時脈政策、render resolution、場景幀率目標、素材設定、warm/cold cache 和測試時間。對不同硬體至少保留交叉結果；若尚無跨硬體資料，就直接標明限制。 ## 18.6 B4 與 B5 必須能互相推翻 若 B5 沒有顯著改善，甚至因 classification tax 使 p99 或 frametime 變差，就應接受「24／72 在此路由負載沒有可觀察淨效益」的結論。分類理論仍可具有描述價值，但不能因此宣稱它帶來性能效益。 --- # 19. 可證偽命題與負面結果 ## 19.1 P07-1：提交權限分離足以檢出部分錯誤候選 若同一 fixture 下改寫 receipt 內容、改變 world revision 或重播同 work ID，嚴格的 Commit Gate 應拒絕且 canonical world 不變。反例：任何不經合法驗證而改變世界者，否定當前實作的權威隔離宣稱。 ## 19.2 P07-2：模組化不保證性能改善 Runtime 的路由、事件索引、證據與保存成本本身可能高於工作計算；如果 B4/B5/B6 在大多數負載落後優化良好的 B1/B2/B3，應以工作範圍、啟用門檻與算法精簡處理，而不是將性能下降解釋成測試失誤。 ## 19.3 P07-3：CPU oracle 可以作為異質世界計算的精度基準 對純確定、整數或可明確建立 tolerance 的參考 kernel，可使用 CPU oracle 比對 GPU 候選。在浮點、統計或非交換耦合模型中，需擴展為相應的驗證契約；若完全無 oracle 或觀察不變量，就不能宣稱已有強正確性證據。 ## 19.4 P07-4：類型化 route error 可以防止部分沉默失敗 當 VRAM 不足、時間期限不合法、rule revision 不同或 device loss 時，系統應回傳 typed failure，保留義務並進行受控 fallback；若系統只是刪除錯誤或默默使用舊副本，便不符合本篇契約。 ## 19.5 P07-5：引擎適配可以保持 Gameplay World 的單一權威 若同一條規則在 Godot／EveWorld host 下產生等價已提交事件，即使畫面渲染／輸入來源不同，world semantic core 應可由相同 fixture 測試。然而使用者腳本和原生引擎節點可繞過接口是明確風險，需要配合權限隔離與契約測試，而不能只靠團隊約定。 ## 19.6 P07-6：多尺度恢復的正確性取決於保留資訊 如果在粗尺度更新後沒有必要的 identity anchors、事件或條件化生成策略，就無法保證恢復到原本的微觀個體歷史。反例不是「演算法不夠強」，而是資料契約根本不成立。此時應否決精細化或重新設計世界規則。 ## 19.7 P07-7：GPU residency 只有在端到端成本受控時值得使用 GPU kernel 更快並不意味總延遲、更少功耗或更平穩畫面；只有當資料搬移、同步、驗證與 render contention 被量測後，才有資格討論其適用域。若 GPU 只是轉移成本或擠壓顯示資源，應退回 CPU／混合策略。 --- # 20. 反例資產與失敗恢復優先序 | 反例代碼 | 事件 | 主要後果 | 初始處理 | |---|---|---|---| | E07-A | 所有單元都每步變化 | 細粒度事件索引無益 | 固定步進／批次 | | E07-B | 工作過小 | 路由與 dispatch 高於計算 | CPU 直行 | | E07-C | Shader kernel 非等價 | 世界錯誤結果 | 無 GPU admission | | E07-D | 高共用寫入衝突 | 序列化與重試增加 | Domain 拆分或固定路由 | | E07-E | 未知負向依賴 | 睡眠漏事件 | 完整 predicate watch／保守 polling | | E07-F | 不可恢復唯一歷史 | 回收後永久資訊遺失 | Pin／持久化／拒絕 evict | | E07-G | Mod 舊快取仍被採用 | 因果及 schema 污染 | Version revoke + invalidate | | E07-H | GPU 丟失且 CPU 備援不在 | 安全路由不存在 | 保留世界、回報明示失敗 | | E07-I | 提交前發生另一世界變更 | Candidate 版本過期 | 丟棄候選、重新計算 | | E07-J | 政策頻繁切換 | p99 顯著增加 | Hysteresis／固定策略 | | E07-K | 事件跨尺度重複結算 | 庫存／人口複製 | Ledger 與 stable event key | | E07-L | 回放只有畫面一致 | 隱藏世界狀態 diverge | Semantic oracle comparison | | E07-M | 使用非安全 FFI | 記憶體與 thread 污染 | typed ABI + API tests | | E07-N | 一次遊戲保存不完整 | 恢復時漏期限 | WAL/journal + pending work | | E07-O | FormAware 分類不穩 | 路由不可重現 | 保守 Unclassified／FormBlind | | E07-P | AI 產生不正確依賴標籤 | 漏計算但表面正常 | Shadow check／static & dynamic audit | **恢復優先序：** 保全 canonical world → 保全未履行義務與持久化事件 → 取消／隔離不可信候選 → 釋放合法租約 → 恢復保守已知路由 → 重跑受影響工作 → 重新量測成本。不得為了保留原來 FPS 而犧牲世界真值或玩家存檔。 --- # 21. Paper 08 的資料契約與交接要求 ## 21.1 必要輸出文件 後續實作者完成真正 Runtime 後，至少生成： ```text runtime_manifest.json world_fixture_manifest.json backend_and_driver_manifest.json rust_toolchain.txt source_commit.txt schema_rule_mod_digest.json cpu_oracle_golden_results.json conformance_test_report.json route_trace_formblind.jsonl route_trace_formaware.jsonl resource_trace.jsonl world_commit_journal.jsonl replay_comparison_report.json bench_latency_memory_render_energy.csv fault_injection_report.json negative_cases.md ``` 此清單是可追溯性要求，不表示本篇已生成上述測試結果。實際格式可採 TOML／JSONL／CSV 或其他版本化機器可讀格式，但每個結果必須能回指同一輪 fixture 與原始程式碼版本。 ## 21.2 首輪可提交的狀態聲明 - **Paper 07 Specification Complete：** 文本、接口、失敗邊界、測試義務完整。 - **Rust Reference Code Candidate：** 第 6 章提供 source；目前待本地 Cargo 編譯與測試。 - **CPU Semantic Conformance Pending：** Rust 真正執行結果尚未由此環境取得。 - **GPU Native Adapter Pending：** 尚無本篇實機 GPU 提交、fence 或性能證據。 - **Godot／EveWorld Adapter Pending：** 是可執行整合計畫，不是已整合完成。 - **B0–B7 Comparative Evidence Pending：** 全部公平效能比較留待 Paper 08 實作測量。 不得把第一行完成誤解成後面五行全部通過。 ## 21.3 工程化下一步 1. 在本地 Rust 環境輸入第 6 章的兩個檔案並執行 `cargo fmt`、`cargo check`、`cargo test`；保留完整 log，修復任何編譯與 borrow/lifetime 問題。 2. 擴大 World Fixture，加入資產與 NPC identity、已提交事件日誌及 time advance authority。 3. 將 M1 CPU oracle 規格固定成相同輸入／預期輸出的金標集合。 4. 接 M2 的 typed gates、M3 的 FormBlind route，再測 M4 的 24／72 附註成本。 5. 只挑一個具精度 oracle 的 GPU kernel，完成 fence、buffer generation、device-loss 實驗。 6. 接入 Godot／EveWorld adapter 的最小場景，驗證 UI 仍由 main thread 控制。 7. 用 Paper 08 的公平 B0–B7 測試判斷各模組實際收益和可關閉的部分。 ## 21.4 為什麼不需要立即啟動更大的母理論 若 Paper 07 的某個 Router 在現有 24／72 分類之外需要新的工作性特徵，例如 cache locality、predicated execution、time-to-deadline 或能耗界限，應優先把它記作**執行策略的附加屬性**。只有在明確證明原有分類的核心形式系統缺乏必要的描述維度，且工程特徵不能合理作為 metadata 處理時，才有理由另行回到上游修訂，而不是直接宣布出現第 25／73 種基礎範式。 --- # 22. 版本來源、已有研究與可追溯性 ## 22.1 本輪核對的 CWSR 正式 UTF-8 原稿 1. Neo.K × Aletheia，**CWSR Paper 00｜因果世界狀態運行：既有計算理論的單機遊戲 Runtime 延伸總綱**，v0.1，2026-10-16，`CWSR_Paper00_Causal_World_State_Runtime_Series_Charter_v0.1_2026-10-16.md`。 2. Neo.K × Aletheia，**CWSR Paper 01｜世界狀態本體與可執行狀態分離**，v0.1，2026-10-16，`CWSR_Paper01_World_State_Ontology_and_Executable_State_Separation_v0.1_2026-10-16.md`。 3. Neo.K × Aletheia，**CWSR Paper 02｜因果觸發、執行休眠與條件喚醒機制**，v0.1，2026-10-16，`CWSR_Paper02_Causal_Trigger_Execution_Dormancy_and_Conditional_Wakeup_v0.1_2026-10-16.md`。 4. Neo.K × Aletheia，**CWSR Paper 03｜宏觀—中觀—微觀多尺度世界模擬**，v0.1，2026-10-16，`CWSR_Paper03_Macro_Meso_Micro_Multi_Scale_World_Simulation_v0.1_2026-10-16.md`。 5. Neo.K × Aletheia，**CWSR Paper 04｜動靜態記憶體契約與選擇性物化**，v0.1，2026-10-16，`CWSR_Paper04_Dynamic_Static_Memory_Contracts_and_Selective_Materialization_v0.1_2026-10-16.md`。 6. Neo.K × Aletheia，**CWSR Paper 05｜CPU／GPU 異質世界計算與因果小流**，v0.1，2026-10-16，`CWSR_Paper05_CPU_GPU_Heterogeneous_World_Computation_and_Causal_Microflows_v0.1_2026-10-16.md`。 7. Neo.K × Aletheia，**CWSR Paper 06｜24／72 計算範式的世界狀態自適應路由**，v0.1，2026-10-16，`CWSR_Paper06_24_72_Adaptive_World_State_Computation_Routing_v0.1_2026-10-16.md`。 ## 22.2 上游 EveMissLab 研究（繼承，不改寫） 8. Neo.K，**《計算的二十四重範式》**，正式版候選稿 v4.0，2026-07-19，`計算的二十四重範式_正式版_v4.0.md`。 9. Neo.K × Aletheia，**《從二十四重計算形態學到七十二格計算動力學》**，v0.1，2026-07-19，`從二十四重計算形態學到七十二格計算動力學_v0.1.md`。 10. Neo.K × Aletheia，**Global Computation Methodology Series**，2026，特別是 00 與 01 的全域一致性、有限活動實現及計算／觀察／物化分離。 11. Neo.K × Aletheia，**GCCF 04｜全域可尋址狀態與選擇性物化**，v0.1，2026-09-22。 12. Neo.K × Aletheia，**GCCF 05｜因果流計算與預記載**，v0.1，2026-09-22。 13. Neo.K × Aletheia，**GCCF 06｜計算 24 範式與 72 格作為全域計算路由文法**，v0.1，2026-09-22。 14. Neo.K × Aletheia，**GCCWT Paper 04｜計算場與資源激發：跨 CPU／GPU／Memory／Agent 的動態執行域**，Draft v0.2。 15. Neo.K × Aletheia，**GCCWT Paper 06｜AI 原生全域調度：從 Task Scheduler 到 World Computation Planner**，Draft v0.2。 16. EveMissLab，**GCM Phase B：Deterministic Compute Allocator 技術白皮書**，v0.1，2026-08-27。 17. Neo.K × Aletheia，**《從有序計算到全域耦合計算》統合母論文**，v0.1，2026-09-22。 ## 22.3 成熟工程背景及尚待補齊的正式外部引文 本篇直接運用 CPU／GPU 一般計算、ECS／Job System、事件排程、Timer Wheel、Dirty Flag、Rust ownership、MVCC、Write-Ahead Logging、GPU command queue／fence、Godot Engine host 融合與可重播模擬等成熟技術。這些不是 CWSR 所原創，未在本輪逐項完成版本限定的外部文獻查核；正式投稿或對外公開技術白皮書時，應補充語言規格、GPU API、Godot 引擎文檔與學術性能比較的權威來源，區分已知技術、本文延伸接口與尚未證實的性能假說。 ## 22.4 原始碼與再現性的規則 本文以 UTF-8 Markdown 另存 canonical source；數學唯一正式 delimiter 為 ` $...$ ` 及 `$$...$$`。聊天渲染與後續 PDF／網站投影不能作為正式 source of truth。未來若本地 Rust 參考碼經修正，應保留此 v0.1 原稿及對應來源 SHA／差異紀錄，另出新的程式 commit 與論文修訂，不得靜默把實驗後的程式碼當成本文當時已驗證的版本。 --- # 23. 結論：Reference Runtime 的責任是讓世界狀態可驗證地運行 本篇將 CWSR 從世界狀態分類、因果休眠、多尺度模型、記憶體駐留、CPU／GPU 工作流及計算形態路由，收斂為一個可以被單機遊戲引擎採用的最小工程分層。其第一原則仍是：**世界存在不代表必須持續執行；執行發生不代表結果合法；運算完成不代表具有世界修改權。** Rust 所有權、可撤回的計算規劃、CPU oracle、GPU 裝置完成證據、ScaleBridge 和 Commit Gate 各自解決不同層的問題，不能因為共享 Runtime 名稱就互相取代。單一世界、保守 revision、完整讀寫檢查、候選與提交隔離，構成最小可測試錨點；之後再用實測證據判斷是否值得加入更細粒度路由、GPU 物化、宏中微尺度切換及 AI 輔助規劃。 **本篇完成的是形式化工程原稿與可供本地驗證的 Rust 候選程式碼，不是已被編譯、實機測通的 CWSR 引擎產品。** 這項限制不是缺陷被隱藏，而是下一篇可證偽測量的必要起點。Paper 08 將要求 CWSR 與成熟的 CPU／事件／GPU 路線在相同工作義務下競爭，並同時公開成功域、失敗域、效能收益及治理開銷。 如最終實驗發現，某些單機遊戲只需要成熟事件系統、簡單 CPU 更新與少量 GPU Compute，則 CWSR 應允許該系統保持簡單。真正值得保留的，不是強迫所有計算都進入新框架，而是**讓每一項實際啟動的世界工作，都具有可理解、可計量、可撤回且不破壞因果的正當理由**。 --- **End of CWSR Paper 07 v0.1 — Engineering Specification and Rust Reference Candidate**