title: SMPDC Paper 02｜相位耦合與有界持續擴散動力學：多主工作流的激活、流量、背壓與靜止偵測
english_title: Phase Coupling and Bounded Persistent Diffusion: Activation, Flow Control, Backpressure, and Quiescence Detection for Multi-Primary Workflows
series: SMPDC — Stellar Multi-Primary Persistent Diffusive Computing
paper: 02 / 11
version: 0.1
status: Full Research Manuscript — Formal Protocol and Conditional Results; Empirical Validation Pending
date: 2026-10-16
language: zh-TW
primary_concept_originator: Neo.K
research_collaboration: Aletheia / GPT-6
institution: EveMissLab / 一言諾科技有限公司
canonical_source: UTF-8 Markdown; inline math $...$ ; display math $$...$$
predecessors: SMPDC Paper 00 v0.1 (2026-10-16) · SMPDC Paper 01 v0.1 (2026-10-16)
artifact_scope: Formal phase semantics, coupling protocol, bounded diffusion, progress and quiescence, reference pseudocode, counterexamples and falsifiable test design

SMPDC Paper 02｜相位耦合與有界持續擴散動力學

——多主工作流的激活、流量、背壓與靜止偵測

英文題名： Phase Coupling and Bounded Persistent Diffusion: Activation, Flow Control, Backpressure, and Quiescence Detection for Multi-Primary Workflows
系列： 群星多主節點持續擴散計算論（SMPDC）
主構想提出： Neo.K
研究協作： Aletheia / GPT-6
機構： EveMissLab / 一言諾科技有限公司
日期／版本： 2026-10-16／v0.1
成熟度： L0–L1，形式化、協議候選與測試規格已寫成；未聲稱完成實體 CPU/GPU 的相位加速實驗。
前置： SMPDC Paper 00 [I0]、Paper 01 [I1]；並對接 PCMT [I2]、GCCFT 相位論 [I3]。

作者： Neo.K
日期： 2026-10-16
版本： 0.1

摘要

SMPDC Paper 00 提出多主工作流、相位耦合、資訊冗餘、分層提交及 CPU/GPU 協作的中觀研究綱領；Paper 01 進一步建立具穩定身分、自治責任、版本狀態、資源授權、核心映射與安全遷移條件的 PrimaryFlowNode Contract v0.1。本篇接續回答尚未解決的核心問題：當多個 CPU 工作流均能在邏輯上獨立持續存在時，哪些事件有資格激活工作流間的耦合？資訊應當向哪些節點擴散、在何種條件下停止，又如何證明傳播不因環路、重送、熱點或調度策略而無界膨脹？

本文首先沿用既有《相位計算機理論》（PCMT）所要求的本體、表示、演化及承載架構分離，並參照 GCCFT 對就緒、因果、同步與驗證相位的區分，將 SMPDC 的相位限制為具有任務相對、狀態敏感、可檢驗的互動效果的執行座標；一般標籤、時鐘值或任意浮點權重不會因命名為 phase 而自動構成新計算機理。本文進一步提出多主節點的具型別相位封套、相位就緒判定、耦合狀態機、有界擴散規則、credit 帳本、背壓策略、取消與靜止偵測，形成 PhaseDiffusion Contract v0.1。

在明示前提下，本文給出三類可檢查命題：(1) 有限、不可複製的發送 credit 對成功獲准的邏輯發送事件提供數量上界；(2) 以世代、租約及仲裁條件保護的擴散不會因一條舊的相位訊息自動獲得新世代的權威寫入資格；(3) 對有限、可靠及公平執行的已封閉事件世代，局部靜止和已清償的在途義務可以成為全域擴散靜止偵測的必要組件，但僅憑所有工作流的 inbox 暫時為空，不足以推出全域完成。這些命題均不能直接證明沒有死鎖、沒有飢餓、所有外部 I/O 僅執行一次，或相位擴散在現有硬體一定更快。

本文特別納入已有先例：Lamport 的事件偏序、Dijkstra–Scholten 的擴散計算終止偵測、Kahn 程序網絡、BSP/Pregel 的分階段訊息運算，以及 Reactive Streams 的背壓規範。新研究貢獻定位並非發明「擴散計算」一詞，而是嘗試讓持續性 CPU 多主工作流、相位耦合、有限傳播權、可審核的流量協議在同一近硬體 Runtime 中具備聯合可操作語義，並與傳統事件調度、資料流與現有異質運算實作進行公平 A/B 對照。

關鍵詞： 多主工作流、相位耦合、有界擴散、事件偏序、相位封套、credit 守恆、背壓、靜止偵測、終止偵測、因果世代、核心親和性、異質運算、形式不變量、模型檢查、可證偽實驗。

1. 研究任務、限制與真正的增量

1.1 從節點存在到節點互動

Paper 01 已使工作流具有獨立身分、局部進度和有限自治權。但「所有 CPU 核心都能承載主要工作流」只解決了節點的局部身分，尚未解決彼此何時互動、如何交接資訊、何時收斂，以及動態拓撲會否無意間破壞先前的安全契約。

如果直接讓每個主節點收到事件便廣播全網，網絡中的重複消息量可能快速膨脹；如果讓所有節點每次都等待全域 barrier，則又可能消除非同步化的價值；如果將相位等同實體時鐘角度，則會把一般程序與因果事件錯誤限制成週期振盪器。故本篇需要更精確的相位協議。

1.2 本篇交付

本篇交付以下規範物件，而非已實作的 CPU opcode：

PhaseState Contract v0.1：相位型別、來源、有效期、依賴與取消規則。
CouplingEdge Contract v0.1：候選邊、授權啟用、解除與拓撲世代。
PhaseDiffusion Contract v0.1：有界訊息傳播、credit、TTL、背壓及安全守衛。
Quiescence Detection Contract v0.1：區分工作流休眠、擴散靜止及真正的提交完成。
條件性命題、反例矩陣、最小模擬器與可反駁的 V0–V1 實驗綱領。

1.3 嚴格不處理的內容

Paper 03： R1／R2／R3 類型冗餘、異源校驗、編碼冗餘及主節點資料融合；本篇只處理可安全承載這些策略的消息封套與傳播預算。
Paper 04： 跨工作流權威提交、推測計算的回滾與外部副作用；本篇只標示提交請求不得越權。
Paper 05–06： 完整 ISA、IR、程式語言與型別檢查；本篇只提出抽象操作的協議效果。
Paper 08–09： GPU 的具體加速核、CPU/GPU 資料搬移，以及微觀快取與硬體實現。

1.4 新穎性不可過度主張

「訊息觸發計算」「事件偏序」「擴散計算」「終止偵測」「backpressure」「動態圖式運算」均已有成熟文獻 [E1–E6]。SMPDC 的新研究承諾是特定組合的形式化、可實驗操作性與增量效能，不是把已有研究重新命名即等於首創。

2. 概念層級與原稿相容性

2.1 PCMT 四層分離

先沿用 PCMT [I2] 的分層思想：

層次	在 SMPDC 中的問題	不能偷換成
相位本體	何種關係或演化狀態真正具有互動意義	時鐘角或任意標籤
相位表示	如何用事件、版本、偏序、時間窗等編碼	強制所有設備用同一資料結構
相位演化	哪些局部轉移會改變合作資格	單純 tick 數量增加
相位承載	工作流、OS worker、CPU 核、硬體事件與 GPU kernel 如何承載	一張抽象圖等同晶片導線

本篇仍屬中觀／宏觀。若未來有新型晶片，可能透過微碼、NoC、硬體佇列或專用加速器實作，但本篇不預設微觀同構。

2.2 對接 GCCFT 相位觀

GCCFT Paper 02 [I3] 已辨認 readiness、causal、synchronization、recurrent、semantic convergence 和 verification 等相位類型。本篇不再創造競爭性的總分類，而把對CPU 工作流擴散協議有直接作用的相位投影為四個基本視圖：

$\phi_i^{r}$ ：就緒視圖，是否滿足啟動當前工作片段的依賴及本地狀態條件。
$\phi_i^{d}$ ：依賴／因果視圖，哪些輸入世代與來源版本已被合法納入。
$\phi_i^{c}$ ：耦合視圖，哪些邊正在候選、啟用、排空或撤銷。
$\phi_i^{v}$ ：驗證／提交資格視圖，哪些輸出仍是候選、哪些已符合本地驗證規則。

其他同步、迭代或語義相位，可以依工作負載作為擴充欄位進入，而不是強迫所有低階 Runtime 一律啟用。

定義相位投影：

\phi_i(e,t)=\left\langle\phi_i^{r}(e,t),\phi_i^{d}(e,t),\phi_i^{c}(e,t),\phi_i^{v}(e,t)\right\rangle

其中 $e$ 是事件世代識別， $i$ 是邏輯工作流身分。它不直接對應 CPU 的硬體時鐘週期；同一核心上可以先後執行多個不同相位的工作流。

2.3 相位的必要性測試

若某個候選相位欄位在給定任務、觀測精度與可達狀態內，無法改變任何合法互動、資源配置、消息收發、取消或驗證的可觀測結果，應把它消去或只留作診斷 metadata。

給定系統狀態 $X$ 、候選相位 $p$ 和同一輸入 $u$ ，以 $\mathcal O$ 表示目標可觀測量；若在對照的可達狀態集合中：

\mathcal O(T(X,p_1,u))=\mathcal O(T(X,p_2,u))

且此等式對所有合法 $p_1,p_2$ 都成立，則 $p$ 在此研究域中可視為相位盲（phase-blind）可化約。這是有條件的檢驗規則，並非聲稱現階段已完成所有可達狀態的等價證明。

這一條防止相位變成沒有識別力的理論裝飾。

3. 繼承 SMPDC 九元模型與節點契約

3.1 原有九元狀態不重命名

沿用 Paper 00：

\mathfrak S_t=\langle V_t,E_t,X_t,\Phi_t,\rho_t,\mathcal M_t,\mathcal Q_t,\mathcal R_t,\mathcal L_t\rangle

其中 $V_t$ 為邏輯工作流， $E_t$ 為可激活的協作邊， $X_t$ 為狀態， $\Phi_t$ 為相位， $\rho_t$ 為工作流到 CPU 核心的承載映射， $\mathcal M_t$ 為傳遞中的訊息， $\mathcal Q_t$ 為驗證與提交契約， $\mathcal R_t$ 為資源， $\mathcal L_t$ 為可觀測證據。

本篇所增加的是具體投影與守衛，不是第十個全域本體元素。 用來追蹤 credit 的帳本屬於 $\mathcal R_t$ 與 $\mathcal L_t$ 的協議狀態；相位封套屬於 $\Phi_t$ 、 $\mathcal M_t$ 的交集；拓撲世代是 $E_t$ 的版本表示。

3.2 從 Paper 01 繼承的必要欄位

每個可參與節點 $i$ 必須存在 PrimaryFlowNode Contract v0.1，至少能查到：

flow_id、flow_generation、logical_epoch、current_state、dependency_view、inbox、outbox、resource_budget、authority_scope、allowed_actions、state_version、binding_lease、fencing_token、topology_generation、observation_policy。

其中，工作流 logical_epoch、全域擴散事件 event_epoch、物理執行環境 topology_generation 和寫入排他性的 fencing_token 是不同量；絕不以一個整數取代四個不同的生命週期或權威關係。

3.3 三個身分空間

工作流身分： $flow\_id$ ，跨 worker 遷移持續存在。
傳播世代： $\epsilon$ ，指本次封閉的擴散事件集合或一次外部觸發的 work wave。
訊息身分： $msg\_id$ ，區分某個邏輯訊息及其可能的物理嘗試。

一個持續工作流可處理多個相繼或交錯的傳播世代；一個傳播世代也可以涉及多個主工作流。不能把「所有工作流常駐」解讀為「全域永遠處於同一個尚未結束的事件」。

3.4 安全與活性分開

安全（safety）描述不應發生的壞事：未授權激活、負額度發送、過期承載權寫入、已撤銷連結發送新消息、錯世代消息冒充新證據。

活性（liveness）描述應當最終進展的事：一個已就緒且合法的工作流是否終於得到 CPU 時間、排空中的訊息是否最終被確認、擴散世代是否能完成或明確失敗。

有界消息數量最多直接證明某類安全性；不會自動證明調度公平、消息必達或不存在死鎖。

4. 具型別的相位狀態與訊號

4.1 相位不是單一數字

PhaseState 最小應包含：

phase_kind：readiness | causal | coupling | verification；可擴充 sync | recurrent | semantic。
phase_state：此種相位的型別化狀態，不要求全類別使用相同 enum。
flow_id、flow_generation、event_epoch。
dependency_digest、source_state_version、target_scope。
valid_from、expiry_policy、topology_generation。
authority_requirement、required_effects、trace_id。

不應將 phase_kind=verification 直接解讀為「已取得 commit 權」。能夠驗證、驗證結果通過，以及有權正式提交，是三個不同事件。

4.2 一個候選封套

PhaseSignalV0_1 {
    signal_id: StableSignalId
    source_flow_id: StableFlowId
    source_flow_generation: MonotonicGeneration
    source_logical_epoch: MonotonicEpoch
    event_epoch: EventEpochId
    target_scope: EligibleTargetSetOrSelector

    phase_kind: PhaseKind
    phase_state: TypedPhaseValue
    dependency_digest: DependencySnapshotDigest
    source_state_version: MonotonicStateVersion
    causal_parents: BoundedEventReferenceSet

    topology_generation: TopologySnapshotVersion
    permit_ref: CapabilityReference
    source_fencing_token: MonotonicFencingToken
    expiry_policy: ExpiryAndCancellationPolicy
    trace_id: TraceIdentifier
}

source_fencing_token 用於檢查這個訊號是否由當時合法的本地執行者發出；它不能自動成為接收者狀態的寫入權。若某種通知本身無權威副作用，可在契約中降級其授權要求，但不能默認所有 PHASE_SIGNAL 都可以變更共享受控狀態。

4.3 PhaseSignal 的三種不同用途

觀測訊號： 只更新可見性或統計狀態，不授予執行與寫入權。

互動資格訊號： 通知特定邊的依賴可能已經滿足；接收端需要重新評估當前版本、許可及資源。

授權後控制訊號： 請求重新配置或受控狀態改變；必須在接收端檢查相應 capability 和 fencing，不可單靠訊號文字內容授權。

三種用途必須有不同的 effect type。否則診斷封包可能被誤用為控制命令，構成安全漏洞。

4.4 相位更新原則

同一工作流的權威世代不得回退。
合法的就緒狀態可因依賴撤銷、deadline 或拓撲變動變成不就緒；就緒值本身不必單調。
因果紀錄通常只能附加或由新世代取代，不能無痕刪除已承諾依賴。
相位延遲抵達不能回寫成更早狀態；應先檢查來源世代及目標依賴。
相位的可用性是時間及工作負載相對的，不等於固定的周期。

5. 相位就緒規則：何時才可啟動工作

5.1 就緒判定分兩層

一個工作流可在邏輯上具備所需輸入，但尚未被允許消耗資源；也可以有資源卻因依賴未滿足而不得執行特定片段。因此定義：

\operatorname{DataReady}_i(\epsilon,t)=\operatorname{Deps}_i(\epsilon)\subseteq\operatorname{ValidInputs}_i(t)

\operatorname{ExecReady}_i(\epsilon,t)=\operatorname{DataReady}_i(\epsilon,t)\land\operatorname{Permit}_i(\epsilon,t)\land\operatorname{Capacity}_i(t)

這裡 ValidInputs 必須經來源、版本與契約檢查；Capacity 是可取得實際執行資源，並非單純觀測 CPU 還有空閒百分比。

5.2 部分就緒不得偷換成完整就緒

某些工作負載不必等待全部輸入。例如拓撲探索可以先擴張已知候選邊，模型推論可以先計算無外部副作用的候選值。此時引入：

\operatorname{PartialReady}_i(\epsilon,t)

它只表示允許指定的可撤銷、無權威效果的局部工作。若後續依賴驗證失敗，候選結果必須丟棄或依 Paper 04 的正式規則回滾；本文不假定這類投機行為一定值得執行。

5.3 就緒與執行租約

Paper 01 允許工作流邏輯身分跨 CPU 承載遷移，但對受控局部狀態的有效寫入者需要租約及 fencing。若 binding_lease 已撤銷，而舊 worker 仍收到 PHASE_SIGNAL，它至多能產生合法的非權威診斷紀錄；任何需要當前寫入權的效果必須被拒絕。

5.4 就緒轉移的反直觀性

Ready → NotReady 並不是系統違反單調因果，而可能來自：

上游輸入被證實損壞；
外部權限撤銷；
資源預算被其他合法任務用盡；
先前使用的版本不再是當前世代有效版本；
拓撲世代變更使舊邊不再合法；
工作流收到取消訊號；
已知的 deadline 不再允許該工作。

因此若使用者採用「相位永遠向前」作為比喻，必須限制為因果紀錄或世代版本的單調性，而非所有相位觀測值皆單調。

6. 相位耦合：從候選關係到合法可執行邊

6.1 相位耦合不是把兩個狀態相加

令 $G_t=(V_t,E_t)$ 是工作流邏輯拓撲。兩個工作流之間有概念上的協作可能，不代表一定存在可用的實體傳輸通路，也不代表資料在 CPU cache 間移動沒有成本。

定義候選耦合決策：

K_{ij}(\epsilon,t)=\mathcal K(\phi_i,\phi_j,X_i,X_j,\mathcal R_t,\Omega_i,\Omega_j)

$K_{ij}$ 是一個帶狀態與拒絕理由的協議決策，不是必然為連續實數的場強。其最小取值：

6.2 耦合的允許條件

對候選有向邊 $(i,j)$ 定義：

\operatorname{Eligible}_{ij}(\epsilon,t)=A_{ij}\land D_{ij}\land P_{ij}\land B_{ij}\land T_{ij}\land L_{ij}

其中：

$A_{ij}$ ：來源有許可，目標對該訊息型別也有接收許可。
$D_{ij}$ ：依賴和事件世代相容。
$P_{ij}$ ：雙端的相位關係滿足該邊的互動前提。
$B_{ij}$ ：傳輸有足夠 credit、佇列空間與時間預算。
$T_{ij}$ ：拓撲世代及路由路徑有效。
$L_{ij}$ ：必要的本地授權租約或 fencing 不已失效。

Eligible 可以授予一次傳播資格，但不能自動授權修改接收者的權威狀態，也不是 GPU 加速承諾。

6.3 CouplingEdge Contract v0.1

CouplingEdgeV0_1 {
    edge_id: StableEdgeId
    source_flow_id: StableFlowId
    target_flow_id: StableFlowId
    topology_generation: TopologySnapshotVersion
    edge_generation: MonotonicEdgeGeneration

    admissible_phase_pairs: PhaseCompatibilityPredicate
    admissible_payload_schemas: SchemaSet
    required_source_capabilities: CapabilitySet
    required_target_capabilities: CapabilitySet
    guard_dependency: DependencyPredicate

    queue_capacity_bytes: BoundedByteCapacity
    queue_capacity_messages: BoundedMessageCapacity
    outstanding_limit: BoundedCounter
    ingress_policy: BackpressurePolicy
    expiry_policy: EdgeExpiryPolicy

    lifecycle: EdgeLifecycle
    cancellation_policy: CancellationPolicy
    provenance_ref: AuditEvidenceReference
}

其 edge_generation 專屬於邊，而 topology_generation 專屬拓撲快照；若一條舊邊被刪除、又以相同兩端重新加入，兩種世代有助於辨識 ABA 式錯誤重用。

6.4 邊狀態轉移

Dormant --propose--> Candidate
Candidate --admit guards pass--> Admitted
Candidate --reject--> Denied
Admitted --activate with valid credits--> Active
Active --drain or remove requested--> Quiescing
Quiescing --all obligations settled--> Revoked
Admitted --permit expires--> Revoked
Active --revoke signal--> Quiescing

不可直接把 Active 的有權威在途消息無條件抹去，否則會喪失對已發送但尚未收到的事件之責任；實作應先進入排空、取消追蹤或故障隔離路徑。

6.5 不應依幾何距離決定所有邊

使用者提出的「群星」及「圓形」是可理解的宏觀形象。但此處距離可代表數種不同成本：依賴長度、共享快取關係、資料複製延遲、網路跳數、權限邊界或 deadline slack。它們沒有普遍共用的量綱。

可以定義向量代價：

\mathbf c_{ij}=\langle c_{lat},c_{byte},c_{cache},c_{energy},c_{sync},c_{risk}\rangle

此向量不能無權重、無限制地相加成單一「距離」。若需投影為加權分數，必須先固定工作負載、量綱正規化與安全性硬約束；不得以低分數覆蓋權限禁止。

6.6 耦合滯後（hysteresis）與反覆開關

如果相位條件在門檻附近震盪，系統可能每毫秒建立／撤銷同一邊。故可將啟用門檻與停用門檻分離，或設定最短穩定觀測窗口。

只有在證明其不會延遲安全撤銷的前提下，才允許性能型 hysteresis。權限失效、安全 fencing 失效的撤銷不得為了滯後延遲而繼續授權。

7. 有界持續擴散：本系列最主要的動力學實體

7.1 擴散的操作定義

令訊息 $m$ 在工作流 $i$ 的可達候選集合為 $N_t(i)$ 。在事件世代 $\epsilon$ ，允許的目的地集合為：

D_t(m,i,\epsilon)\subseteq N_t(i)

並滿足每次傳播的最大合法扇出：

|D_t(m,i,\epsilon)|\leq b_i(\epsilon,t)

這只是一項局部限制，並不足以排除多跳環路造成的累積膨脹。完整協議尚需 credit、重複辨識、隊列容量、截止時間與異常處理。

7.2 「持續性」與「擴散性」不同

Persistent： 工作流的身份、狀態、等待條件可跨事件存在。
Diffusive： 某個已被授權的事件或工作片段，可以依相位及預算向多個後續工作流傳播。

持續工作流可以長期處於 Dormant，不發送任何訊息；一次有界擴散完成後，工作流也可以繼續等待下一個事件。兩者互不蘊含。

7.3 DiffusionEpoch 的封閉性

對一次外部注入的事件，建立 event_epoch=ε。一個可完成的 epoch 應有顯式的新消息接受窗口：

Open：允許符合政策的外部新種子加入；
Sealing：停止接受本 epoch 的新外部種子，允許已保留在途義務完成或失敗；
Sealed：不再創建新的外部種子；內部傳播仍可繼續直到額度或工作耗盡；
Quiescent：符合第 11 章的在途義務清償條件；
Closed：相關資源與追蹤已合法收束，具權威的對外結果另由 Paper 04 規範。

持續開放且允許無限加入新事件的資料流，不應承諾自然進入 Quiescent。

7.4 消息血緣與層數

root_event_id 定義外部觸發源，lineage_id 記錄一條具有界定的傳播分支，hop_count 記錄該支的已走步數。若採硬性 TTL，要求：

0\leq h(m)\leq H_{max}

對固定最大分支因子 $b$ 、初始種子數 $s$ 且不允許分支合併後再生成新的無界根，最粗略的樹展開上界是：

N_{tree}\leq s\sum_{k=0}^{H_{max}}b^k

這不是實際節點數或傳輸位元數的精確成本；不同分支可能重複抵達同一邏輯節點。若 root 可以無限重開、不同世代持續注入，該上界不適用於總系統生命週期。

7.5 訊息封套最小型別

DiffusionEnvelopeV0_1 {
    message_id: StableMessageId
    root_event_id: StableEventId
    event_epoch: EventEpochId
    lineage_id: LineageIdentifier
    hop_count: NonNegativeInteger
    max_hops: FiniteHopLimit

    source_flow_id: StableFlowId
    source_generation: MonotonicGeneration
    target_flow_id: StableFlowId
    topology_generation: TopologySnapshotVersion
    source_state_version: MonotonicStateVersion
    causal_parents: BoundedEventReferenceSet

    payload_schema_id: SchemaIdentifier
    payload_ref: ImmutableOrVersionedPayloadReference
    transmission_class: "data | phase | control | diagnostic"
    redundancy_class_hint: "single | duplicate | corroborate | coded"

    authority_scope: CapabilityReference
    source_fencing_token: MonotonicFencingToken
    send_credit_id: OptionalUniqueCreditToken
    delivery_attempt_id: StableAttemptId
    expiry_policy: ExpiryAndDeadlinePolicy
    trace_id: TraceIdentifier
}

這是語義契約，不是建議每個 CPU cache-line 必須放進所有欄位。實作可將不常變動的 metadata 移至 side table、索引或共享記憶體，並以測量證明解碼成本與版本檢查仍足夠低。

7.6 邏輯發送、物理嘗試與處理效果

一個邏輯訊息可能因傳輸失敗而需要重新嘗試。要分開紀錄：

message_id：邏輯訊息身分；
send_authorization_id：一次合法傳播決策；
delivery_attempt_id：一次實際入佇列、跨執行緒或跨設備嘗試；
process_result_id：接收端對此消息的某次處理結果。

消息去重必須在同一 namespace 下進行；delivery_attempt_id 不同不代表兩份不同工作，message_id 相同也不證明兩份資料內容都正確。Paper 03 才決定異源證據與編碼修復的型別語義。

8. Credit 守恆式傳播預算

8.1 為什麼只靠 TTL 不夠

TTL 能限制單條血緣的深度，卻無法單獨排除同一層的大扇出、源源不斷的新種子、重試風暴和外部輸入過載。故本篇將 credit 設計為更接近全域有界許可權的資源，而不只是消息 header 的展示欄位。

8.2 最低信用制度

對一個已封閉事件世代 $\epsilon$ ，設 $B_0(\epsilon)$ 為初始可發送許可數量。每個新的、計入限制的傳輸嘗試需要唯一不可複製的 credit token，成功保留後才能送出。

令 $C_t(\epsilon)$ 為尚未消耗的可用 credit 數， $S_t(\epsilon)$ 為從世代開始至 $t$ 已獲准的傳播嘗試累計數。在不額外增資、不重複使用 token、單一權威原子發配及取消不退款的簡化制度下：

C_t(\epsilon)+S_t(\epsilon)=B_0(\epsilon)

因此：

S_t(\epsilon)\leq B_0(\epsilon)

該模型刻意將每次重試視為新的有成本嘗試。若另一實作允許退款、租借或將多次物理重試視為同一邏輯額度，便須建立不同帳本與上界，不得直接套用這個證明。

8.3 分散帳本的安全發放

在單機原型可以由原子計數器或預先切分的 token 分片實作。若 credit 先分配給主節點 $i$ ，則它對自己的 quota 有有限自治；但所有節點持有的有效額度加總及已用額度，必須不超過該 epoch 總額。

定義某 epoch 的分片授權 $a_i$ 、共同保留庫 $a_{pool}$ 與已消耗 credit $S$ ，在不可重複持有與轉移時原子交割條件下：

\sum_{i\in V}a_i+a_{pool}+S=B_0

節點遷移時，credit token 的所有權跟隨合法 work-flow lease 或經正式轉移；不能因複製 checkpoint 便把額度複製兩份。

8.4 CreditLedger Contract v0.1

CreditLedgerV0_1 {
    event_epoch: EventEpochId
    root_budget: FiniteSendBudget
    allocated_tokens: UniquelyOwnedTokenSet
    unallocated_tokens: UnallocatedTokenSet
    irrevocably_spent_tokens: SpentTokenSet
    token_owner_generation: Map<TokenId, FlowGeneration>
    token_fencing_generation: Map<TokenId, FencingToken>
    ledger_authority: LedgerAuthorityId
    audit_trace: AppendOnlyEventReference
}

對大型系統，完全中心化的原子帳本可能導致巨大競爭成本；因此它只是安全的語義參考模型。較高效的 distributed escrow、批次 token 配額與近核池化須另證明授權不重複與總額不超發。

8.5 控制訊息是否收取 credit？

這是協議設計中不能略過的細節。若某些傳輸通道的 ACK、取消、失效通知及退讓通知也消耗同一有限傳播 credit，而 credit 用完後又無法送出必要 ACK，可能造成永久停滯。

本篇因此區分：

資料擴散 credit： 約束新的資料/工作傳播。
恢復與清償 control credit： 獨立保留的有界控制額度或可靠控制通道，用於 ACK、cancel、drain、lease revoke。
外部輸入 admission credit： 控制新 epoch 被建立的速率，避免無限開新世代繞過資料額度。

這三個池的上界和實際佔用應分別量測。若 control channel 無限制，單靠 data credit 不足以證明所有封包位元數有界；若 control 也受限，便須證明控制通道仍有足夠終止進度。

8.6 資料容量與 credit 分離

一個 token 可能對應大小不同的 payload。若只限制消息數量，仍可能被單個巨大 payload 耗盡記憶體。因此還需要：

\sum_{m\in\operatorname{InFlight}(t)}\operatorname{bytes}(m)\leq M_{limit}(t)

以及各邊的 bytes limit。共享 immutable payload 的引用可以減少資料拷貝，但需要考慮引用計數、實體頁面常駐、跨 NUMA 讀取和生命周期；不能把引用複用誤當成零成本內存。

9. 背壓、排程公平性與擴散速度

9.1 背壓不只是效能優化

在多主持續工作流中，某節點處理較慢、另一節點持續生產消息，是常見狀態。若不限制 downstream queue，任何理論上的高吞吐量都可能只是把未完成工作累積在記憶體裡。Reactive Streams 將非阻塞背壓作為跨非同步處理邊界的一個成熟設計要求 [E5]。

SMPDC 不宣稱先發明背壓；它要研究的是背壓如何與相位資格、傳播信用、局部自治和提交前的檢查責任連接。

9.2 兩層容量

對每一條邊 $(i,j)$ ，要求消息及位元組層容量：

q^{msg}_{ij}(t)\leq Q^{msg}_{ij},\qquad q^{byte}_{ij}(t)\leq Q^{byte}_{ij}

對整個進程或 epoch 另設共享限制，避免每條邊看似安全，但邊數增多造成全域記憶體耗盡。

9.3 連續型擴散流速

定義 $\lambda_i(t)$ 為節點 $i$ 合法新消息進入率， $\mu_i(t)$ 為該節點實際可完成的服務率。作為排隊分析直觀，在長時間穩定且平均量可定義的模型下，若持續存在：

\lambda_i>\mu_i

且沒有 admission control 或丟棄策略，則 backlog 有成長壓力。此式不是完整的多類型、優先權、突發負載或非平穩工作隊列模型；實驗須測實際佇列長度分布與尾端延遲。

9.4 允許的降級策略

當條件不足時，合法策略包括：

defer：延後，但保留權威義務與到期資訊；
coalesce：對已證明可合併的同型事件做壓縮，保留原始因果歸屬；
drop_non_authoritative：只丟棄不要求送達保證的診斷或推測資料；
shrink_fanout：縮小目前擴散目的地集合；
route_alternative：在合法且已驗證的新拓撲中改道；
spill_to_persistent_storage：明確記錄 I/O、耐久性與恢復成本後外溢；
abort_epoch：在契約明許時失敗結束，而不是偽造成功。

絕不能為了降低內存而偷偷丟棄需要最終驗證或法律/交易授權的權威訊息；也不能讓非權威診斷被延後後阻塞必須處理的 revoke 訊號。

9.5 公平與優先級反轉

多主工作流不等於每個工作流都可以無限制搶占 CPU。為防止低優先級等待者永久飢餓，可採用 aging、分組 quota、最長等待時限或資源保留。實際設計須保留緊急停止、權限撤銷和安全控制的高優先級。

公平性必須有工作負載相對的服務定義。例如：對具足夠資源、輸入已到、未被取消且持續合法的工作流，若排程器滿足 weak fairness，則其可執行步驟不應永遠被跳過。這是待驗證活性假設，不會由 credit 自動推出。

10. 執行轉移系統：相位與擴散如何發生

10.1 操作事件字母表

在中觀語義下，定義一組抽象標籤化事件：

EPOCH_OPEN
PHASE_OBSERVE
PHASE_SIGNAL
COUPLE_PROPOSE
COUPLE_ADMIT
COUPLE_ACTIVATE
DIFFUSE_RESERVE
DIFFUSE_SEND
DIFFUSE_RECEIVE
DIFFUSE_ACK
COUPLE_QUIESCE
COUPLE_REVOKE
CANCEL_REQUEST
EPOCH_SEAL
EPOCH_QUIESCE
EPOCH_CLOSE

這不是 CPU opcode，也不宣稱某個通用 ISA 目前能原生執行以上指令。Paper 05 才會決定哪些可以成為中介表示的一級原語，哪些應被編譯成既有原子操作、共享佇列、eventfd、condition variable 或 GPU command buffer。

10.2 原子性邊界

在軟體參考模型中，DIFFUSE_RESERVE 對 token 唯一性、邊容量與授權檢查是一個不可分割的語義事務。在真實 CPU 實作中，它可能由多個原子變數、鎖、交易式日志或 compare-and-swap 實現；是否能保持語義上線性化，需要獨立驗證。

DIFFUSE_SEND 僅在 reservation 成功後入佇列。若入佇列失敗：

如果 reservation 可取消且尚未對外曝光，可按已規定的安全規則撤銷；
如果此傳播嘗試已在協議中被計為消耗，則必須保留消耗記錄並使用新額度嘗試；
不允許未經明確轉移狀態便同時保留「可重用 credit」與「可能已送出的消息」。

10.3 參考轉移關係

令 $\tau$ 表示一次可觀測原子步驟，系統轉移為：

\mathfrak S_t\xrightarrow{\tau}\mathfrak S_{t+1}

步驟類型 R1｜相位更新。 根據合法輸入、工作流版本及觀測狀態更新 $\Phi_t$ ，不得僭越已存在的局部狀態寫入權。

步驟類型 R2｜耦合准入。 計算 $\operatorname{Eligible}_{ij}$ 並建立可審核 admission decision。候選邊並非直接可發送。

步驟類型 R3｜傳播保留。 取得唯一額度、目標容量及合法路由；其中任一必要條件不滿足則不得完成保留。

步驟類型 R4｜傳播發送。 構造攜帶世代、血緣、依賴、權限與 trace 的 envelope，投遞到指定通道；必須記錄可辨識的結果。

步驟類型 R5｜接收再驗證。 接收端獨立驗證消息，而不是信任發送端在較早時刻判定的合法性永遠成立。

步驟類型 R6｜處理與後續擴散。 若消息仍有效，接收端更新其合法局部狀態或生成候選結果；若再向外傳播，必須重新滿足新的傳播守衛和預算。

步驟類型 R7｜清償。 按已建立的消息協議回報接收、失敗或取消，更新 in-flight obligations；不可把 ACK 等同業務成功或權威提交。

10.4 參考偽程式碼

function phase_step(flow, epoch, observation):
    require flow.contract.valid
    phase_candidate = derive_phase(flow, epoch, observation)
    append_trace("phase_candidate", phase_candidate)

    if not validate_phase_lineage(phase_candidate):
        return Reject("STALE_OR_INVALID_PHASE")

    flow.phase_view = phase_candidate
    return phase_candidate

function try_diffuse(source, target, epoch, payload):
    require epoch.accepts_internal_emission
    require source.current_state permits diffusion
    require source has current action capability
    require source current lease/fence if effect requires it

    edge = lookup_edge(source, target, epoch.topology_generation)
    require edge.lifecycle == Active
    require compatible_phases(source, target, edge, epoch)
    require valid_dependency_scope(source, target, payload)

    reservation = atomically_reserve(
        epoch.send_credit,
        edge.queue_capacity,
        global_memory_budget
    )
    if reservation.failed:
        return BackpressureOrReject(reservation.reason)

    envelope = build_envelope(source, target, epoch, payload, reservation)
    outcome = enqueue_with_protocol(envelope, reservation)
    audit(outcome)
    return outcome

function receive_diffusion(target, envelope):
    if not check_message_epoch_and_schema(envelope):
        return RejectWithAccounting("BAD_MESSAGE")
    if not check_target_authority_and_edge_generation(envelope):
        return RejectWithAccounting("NO_LONGER_ADMISSIBLE")
    if not check_causal_dependency(envelope, target):
        return DeferOrRejectWithAccounting("DEP_NOT_READY")

    candidate = target.compute_local_step(envelope)
    record_candidate_progress(candidate)
    schedule_possible_next_phase(candidate)  // not a global commit
    return AcknowledgeProcessingOutcome(candidate)

此偽程式碼僅供語義討論，並不假裝 atomically_reserve 在任意 OS 或 CPU 平台上已經無鎖、可擴展或沒有飢餓。相反地，它是一個在 V0 模擬器中可以被故障注入和模型檢查的可反證對象。

10.5 工作流遷移時的交接

從 CPU 核 A 改由核心 B 承載工作流，並不建立第二個具有原始權威的 PWN。遷移應遵守 Paper 01 的 fencing 與版本快照規則。尚未完成的擴散 reservation 須明確轉移、清償或取消，不可兩邊都以為自己持有同一筆 credit。

若新 worker 收到舊 worker 發出的消息：消息可做診斷或作為候選輸入，但需要當前權威效果者仍須通過完整 version/fencing 檢查。

11. 工作流靜止、擴散靜止與終止偵測

11.1 最容易混淆的三個術語

工作流 Dormant： 一個持續性工作流沒有立即可執行片段，但其身分與合法狀態仍保留。

單次擴散 Quiescent： 指定事件世代的活動和在途責任已清償，並且根據明示的輸入封閉規則，不存在可再引發本 epoch 工作的潛在來源。

全域完成／Commit： 系統已滿足規定的驗證、資料權威和對外副作用契約；這由後續 Paper 04 處理。

因此：

\operatorname{Dormant}(i)\not\Rightarrow\operatorname{Quiescent}(\epsilon)

\operatorname{Quiescent}(\epsilon)\not\Rightarrow\operatorname{Committed}(\epsilon)

11.2 為什麼不能只看 queue 為空

假設節點 A 剛將消息送往 B，A 的 outbox 已成功清空；B 因 OS 排程延遲尚未觀測到入站消息。此時 A 和 B 的本地 queue 快照即使看似同時為空，也不代表該消息已處理。

這是經典的分散式終止偵測問題，而不是 SMPDC 首先發現的新困境。Dijkstra–Scholten 的 Termination Detection for Diffusing Computations（1980）便為擴散活動與反向完成訊號提供了研究模型 [E2]。在原始研究中，對計算消息與反向訊號的平衡負責，是判定擴散終止的重要思想。

11.3 Quiescence 的候選判準

對已 Sealed 的事件世代 $\epsilon$ ，要求：

沒有合法的新外部根消息可進入該世代。
沒有尚可執行、尚未取消或尚未明確失敗的本 epoch 工作片段。
沒有需要計入的在途資料訊息及未確認送達義務。
沒有尚未清償的重試、取消與排空義務。
不存在等待中的 credit 所有權交割、租約遷移交割或隱藏的懸掛提交準備。
所有上述判斷來自一致且足夠完整的因果快照或正確的 termination-detection protocol，而不是從不同時刻任意拼湊的計數器。

可以記為：

\operatorname{QSafe}(\epsilon)=\operatorname{Sealed}(\epsilon)\land\operatorname{NoActiveWork}(\epsilon)\land\operatorname{ObligationsSettled}(\epsilon)\land\operatorname{ConsistentObservation}(\epsilon)

此式是協議契約中的目標謂詞；要進一步斷言它「被完整且正確地偵測」，必須建立對應實作的訊息和記帳不變量。

11.4 終止偵測三種可比較實作

候選實作	思想	優點	代價／限制
共同清償帳本	對 epoch 的 active 與 in-flight 義務做單一權威紀錄	V0 好驗證，狀態透明	中央競爭、共享快取熱點
Dijkstra–Scholten 式回傳訊號	追蹤擴散活化與其完成義務	對擴散樹／活動相關性有成熟先例	要處理消息協議、拓撲和失效條件
一致性快照／分散偵測	建立能辨認在途狀態的全域觀測	易與多域系統橋接	快照、記錄與外部故障模型較複雜

在單機共享記憶體上，第一版可以選擇共同帳本，但研究報告應把其成本獨立列為 epoch_accounting_overhead；若它成為瓶頸，應改做消融與替代方案，而不能隱藏該成本。

11.5 實體 CPU 工作流持續存在，不妨礙 epoch 終止

一顆 CPU 核承載的主要工作流可以終生處理許多不同任務，但每個已封閉 epoch 都有自己可獨立清償的消息責任。因此需要將：

flow_lifetime；
worker_lifetime；
core_binding_lifetime；
epoch_lifetime；
message_lifetime；

視為五個不同維度，不能因工作流持續存在就讓所有事件永遠未完成。

11.6 關於時鐘與因果

Lamport 1978 年提出以事件偏序理解分散式因果關係的重要架構 [E1]。因此本篇將 happened-before／因果父事件關係，與壁鐘時間戳分離。

不要求不同 CPU 核的物理時間戳完全相同；也不允許因為某個消息 timestamp 較小，就直接推斷它在另一核的受控狀態已合法發生。即便是在同一實體機器內，CPU 頻率調整、排程延後與 memory ordering 仍需要規範化觀測模型。

11.7 活性前提不能省略

要把「最終可以偵測到靜止」當成可證命題，至少需要：事件世代不再注入無窮工作、每個局部任務最終完成或有界失敗、必要的控制消息最終可送達或可被檢出的故障終止、排程對合法待執行工作具有適當公平性，以及過期租約可由權威端可靠拒絕。

若有任意網路永久分割、OS 永久停止某工作流、程序內有死循環，或具有無限制重試，不能一般性保證整個 epoch 會完成；此時安全輸出是 blocked、timed_out 或 failed，而不是宣稱成功。

12. 三項條件性命題與證明邊界

12.1 命題 A：已封閉 epoch 的 credit 發送上界

前提：

A1. $B_0(\epsilon)$ 是有限非負整數。
A2. 每個受管理的實際傳播嘗試必須消耗一個唯一 credit。
A3. credit 不得複製、透支、退款或在同一 epoch 重新創造。
A4. credit 分配與消耗使用可線性化／等效強度的唯一權威仲裁；同一 token 不得同時被兩節點合法花費。
A5. 新的外部種子、不同 event epoch 或協議之外的控制通道不計入本命題結論。

命題： 本 epoch 內受管理的發送嘗試次數滿足：

N_{send}(\epsilon)\leq B_0(\epsilon)

證明概要： 設初始存在 $B_0$ 個唯一 credit，根據 A2 每次發送將一個此前尚未消耗的 token 移入已消耗集合；根據 A3、A4 兩次不同發送不能使用同一 token，且沒有額外 token 被創造。由集合單射可得發送事件數量不超過 token 數量。

不可推論： 不保證送達、不保證正確、不保證不阻塞，也不保證單次發送的位元大小或控制流量已界定。若 credit 由分散節點分配而存在 race condition，證明前提 A4 便可能失效。

12.2 命題 B：舊世代相位訊號不能自行取得新權威

前提：

B1. 每條具受控狀態效果的相位訊號都攜帶來源工作流世代、拓撲世代與必要的權限憑據。
B2. 所有對指定受控狀態的權威修改，都必須由共同的寫入仲裁點驗證最新 fencing token。
B3. 新承載的有效 token 產生後，舊 token 對同一資源寫入不可再次有效。
B4. 無其他旁路可以跳過該仲裁直接修改同一受控狀態。

命題： 一條在工作流遷移前由舊 token 發出的相位消息，無法僅因延遲抵達，就被當作合法的新世代受控狀態寫入。

證明概要： 由 B2、B3，舊 token 在任何必經寫入仲裁點將被拒絕；B4 排除旁路。因此即使消息仍可抵達或被解析，它也不能單獨取得已變更的寫入權。

不可推論： 不保證所有無副作用運算都會取消，也不保證接收者無法在本地產生候選診斷；若 raw shared-memory 指標繞過權威檢查，命題不成立。

12.3 命題 C：完整責任清償能避免特定誤判

前提：

C1. 本 epoch 已封閉新外部輸入。
C2. 每次合法入佇列或傳播保留均創建不能遺失的未清償義務。
C3. 義務只可由合法處理完成、明確取消或已定義的終局失敗原子結束；消息重送不會讓義務雙重清償。
C4. 靜止判定在一致性觀測下同時檢查 local active work 與全部未清償義務。
C5. 沒有未記帳、可重新啟動此 epoch 的額外外部通道。

命題： 若一條合規的消息仍處於已保留或在途狀態，則該 epoch 不能因其他節點暫時 idle、局部 inbox 為空而被判定為已靜止。

證明概要： 根據 C2 該消息產生未清償義務，根據 C3 未合法完成前義務持續存在，根據 C4 靜止判定要求所有義務清償，因此不能得出靜止結論。

不可推論： 這只是防止一類假陽性的安全命題。要證明完整的終止偵測正確性與最終可發現性，仍需要證明所有活動都被記錄、義務能最終清償，以及所選快照／協議的全域一致性。本文不把三項局部命題誇大成通用分散式終止定理。

12.4 一項值得主動證偽的性能命題

性能假說 H-P02： 對具有反覆局部事件、動態依賴及非均勻工作流服務率的負載，具型別相位＋有限選擇性擴散，相較於同等正確性契約下的固定 DAG／一般事件通知／有界廣播，有可能降低不必要消息、同步等待或 p99 完成延遲。

但若對照組已能由已有依賴資訊作出相同決策、而新增相位封套與額度仲裁產生更高 overhead，則此假說應判定不成立或只在有限的負載區間成立。

13. 反例與故障模式：這個架構最容易失敗的地方

13.1 全域廣播風暴

假設有四個持續工作流形成環： $A\to B\to C\to D\to A$ 。如果每個節點在收到任何消息後都自動轉發到所有相鄰節點，且沒有穩定消息身分、TTL 或 budget，同一原始事件可反覆繞環。系統可能觀測到極高的「消息吞吐」，但有效工作量接近零。

本篇要求： 轉發前必須辨認 event epoch、消息血緣、許可、quota 與局部依賴；不能以忙碌的 CPU 使用率當成功證據。

13.2 只靠時間戳的錯誤同步

工作流 B 收到兩份帶不同物理時間戳的消息，直接選較早者當成因果來源。但不同核心的時鐘觀測與排程延遲並不能一般性替代有向因果依賴。必須記錄 causal parents、版本與明確的依賴關係 [E1]。

13.3 兩個主工作流爭寫同一狀態

Primary 不是無限制寫入權。若兩個工作流對同一受控狀態擁有重疊有效寫入許可，又沒有單一仲裁與版本規則，結果可能與排程次序耦合，甚至產生資料競爭。Paper 01 的租約／fencing 契約不得因「更快速擴散」被跳過。

13.4 重試把有限額度變成無限流

一個消息邏輯上只計一份 credit，然而傳輸失敗後無限重試，每次重試均產生真實 queue/PCIe/CPU 成本。若實作對重試不另設邊界，便不能宣稱整體傳播成本有界。

13.5 Credit 分片複製

工作流從 CPU 核 A 遷移到 B，checkpoint 內含當前可用的 100 個 tokens；舊 worker 與新 worker 在某段時間各自認為持有全部額度。若允許兩者發送而沒有 fencing，實際發送可超過原先配置。

對策： 額度屬於帶不可重複所有權的資源，遷移必須完成原子轉移、舊權失效或安全拒絕。

13.6 靜止誤判

所有節點的 inbox 看似為零，卻有消息仍在共享佇列、外部設備或異步 DMA 的在途狀態。系統如果宣告完成，便可能丟棄已發生的計算責任。

對策： 必須具有可觀測的 in-flight 義務和一致性快照或等效終止偵測協議。

13.7 背壓循環死鎖

A 等待 B 清空 queue 才能發送取消訊號；B 等待 A 的取消訊號才釋放容量。若資料與控制共用已滿的單一佇列，會形成協議上的死鎖。

對策： 保留有界高優先級控制通道、可證明不被資料負載餓死的 credit，以及可取消等待狀態；但控制通道本身仍須防止濫用。

13.8 相位反覆切換

快速抖動的資源觀測使耦合邊不斷 Active → Revoked → Active，造成更多快取失效、配置和同步。必須比較有無 hysteresis 的總體成本；安全型撤銷不能被延後。

13.9 CPU/GPU 錯誤直通想像

相位圖中有一條邊 $CPU_i\to GPU\to CPU_j$ ，不表示 GPU 可以直接充當 CPU 兩核心間的實體互連。GPU 只在確有適合並行化的關係計算與充分批次時才承接工作；所有資料移動、kernel 啟動、同步與權限效果仍須計入。

13.10 不必要的相位膨脹

若普通工作佇列已能根據依賴就緒做相同決策，卻額外為每個消息附加大量相位欄位和多次版本檢查，可能純粹增加分支、cache misses 和內存用量。遇此情況應使用 phase-blind reduction，保留簡單基線。

13.11 部分輸入導致不可回復副作用

某節點在 PartialReady 即觸發不可逆對外 I/O，後來發現依賴版本錯誤。即使本地狀態可以回滾，外部世界可能已被改變。這是 Paper 04 應處理的問題；本篇禁止把暫態相位就緒直接視為已取得不可逆 effect 權限。

13.12 GPU 批次等待破壞尾延遲

系統為了利用 GPU，把零星小消息聚成大批次，卻使即時決策工作流長時間等待。平均吞吐量改善，不等於 p99 latency、deadline miss 或使用者體驗也改善。

13.13 永久低優先級飢餓

若所有 CPU 都被高優先級擴散風暴佔據，低優先級、但必須最終完成的已驗證工作永遠沒有機會提交。動態相位與預算不會自動解決公平性，需要受規範的 scheduler contract。

13.14 故障模型超出命題範圍

若 host 在原子帳本已記下「傳播成功」但實際消息尚未持久化時當機，系統如何重新確認發送結果，需依持久性、回復和 exactly-once／at-least-once 契約明確設計。此處只有進程內形式安全模型，不能冒稱已覆蓋所有 crash consistency 問題。

14. 性能成本模型與觀測指標

14.1 一個階段的總成本不是指令數而已

令工作負載 $w$ 在策略 $\pi$ 下的端到端成本向量為：

\mathbf J(w,\pi)=\langle T_{end},T_{p99},E_{joule},M_{peak},B_{transferred},N_{invalid},R_{deadline}\rangle

其中 $T_{end}$ 是完成時長或相應的多請求統計量， $T_{p99}$ 為尾端延遲， $E_{joule}$ 為能源， $M_{peak}$ 為峰值內存， $B_{transferred}$ 為資料轉移量， $N_{invalid}$ 為違反約定輸出的計數， $R_{deadline}$ 為截止時間失誤率。

不應在未指定權重、單位、硬性約束與工作負載前把全部量投影成一個任意分數。

14.2 新增相位協議可能帶來的成本項目

在可分解的局部實驗中，可把附加成本分類為：

T_{overhead}=T_{phase}+T_{couple}+T_{credit}+T_{enqueue}+T_{sync}+T_{trace}+T_{reconcile}

這是一個會計分類，不是斷言總延遲等於以上時間的直接算術和。真實 pipeline 可並行重疊，各元件的重疊與臨界路徑影響須靠 trace 和干預式 profiling 分辨。

14.3 避免用核心使用率替代有效產出

核心占用 100% 可能表示有用計算增加，也可能表示 spin wait、資料碰撞、無用相位掃描或重複轉發。至少需同時量測：

每秒完成且合法的工作量；
每個工作單位需要的消息數、有效處理數、重送數；
各 worker 等待時間、喚醒次數、CPU migrate 次數；
queue 停留時間和 p50/p95/p99 延遲；
快取命中及跨核資料流量（依工具能力）；
峰值內存與每訊息 header／metadata 成本；
背壓發生頻度及控制通道利用率；
終止偵測時間與 epoch 清償正確性；
能耗與溫度／時脈變化；
數值、順序與權威結果的一致性。

14.4 同樣正確性才可比較速度

例如一個 baseline 每次都驗證消息，SMPDC 卻只做 CRC 並直接提交，那麼即使 SMPDC 更快，也不是公平對照。測試前應固定：輸入、工作負載分布、容錯契約、錯誤檢出率目標、記憶體上限與輸出驗證。

若某版本因權威檢查不完整而較快，結果必須標示 unfair_or_incomparable，不能當成速度優勢。

14.5 分離邏輯效益與硬體效益

同一份邏輯計算圖在不同實體 CPU 核、共享快取域、NUMA 節點或 GPU 上執行，性能可能差很多。故要同時做：

固定硬體承載、比較相位和擴散語義；
固定相位語義、比較實體 core mapping；
固定消息尺寸、比較同步與背壓；
固定 correctness contract、比較 CPU-only 與 GPU 批次。

第四項僅作本篇後續介接，不提前對 Paper 08 得出效能結論。

15. 最小可證偽實驗路線 V0–V1

15.1 V0：決定性模擬器優先

在購買新 CPU 前，先建立無需 GPU、無需新 ISA 的事件模擬器。模擬器支援多個 PWN、動態依賴、有限 credit、版本化拓撲、消息重送、取消與靜止偵測，並提供可重現的事件 trace。

前期的成功標準是安全性與協議完整性，而不是效能。 即使在模擬器中大幅減少消息數量，也不能直接換算為實體機器效能。

15.2 B0–B5 比較組

ID	比較組	目的
B0	標準有界佇列＋固定工作流圖	最基本的成熟排程對照
B1	常駐工作流＋固定依賴事件通知	隔離持續工作流的收益
B2	常駐工作流＋動態邊，沒有相位條件	隔離拓撲更新本身的收益
B3	常駐工作流＋具型別相位，不允許二階擴散	隔離相位訊號的處理成本
B4	SMPDC 有界選擇性擴散，不啟用冗餘／GPU／AI	驗證本篇主要假說
B5	SMPDC 完整安全協議，但使用 phase-blind reduction	判斷相位欄位是否真有必要

所有比較組都要有等價的授權、容量上限、結果正確性及合法的 failure semantics。若 B0 等沒有相位語義，仍要給它們相同資訊以作公平的依賴優化，避免故意讓 baseline 因資訊不足而變弱。

15.3 工作負載矩陣

建議至少包含下列六類：

W1｜固定無環圖。 依賴靜態且可事先預測，預期動態協議可能沒有優勢。
W2｜動態無環圖。 下游依賴由上一階段結果決定。
W3｜局部循環與可收斂迭代。 可能重複激活，但具有限輪數或誤差門檻。
W4｜高度不均勻的事件串流。 工作流服務率差異大，測背壓及尾延遲。
W5｜高 fanout 稀疏圖遍歷。 測消息放大、去重與拓撲變動。
W6｜相位無關的純密集計算。 強制測出新增協議開銷，不預期總是加速。

日後 Paper 10 可再把上述負載映射到 MoE、稀疏 attention、Agent 推理與 AI training pipeline；本篇不預設大型 GEMM 一定適用。

15.4 可控制的變項

$|V|$ ：主工作流數量；
邊的密度、環比例、拓撲變更頻率；
$B_0$ ：全 epoch 發送額度；
$b$ ：每跳 fanout；
$H_{max}$ ：最大傳播深度；
每消息 payload bytes 與 metadata bytes；
來源事件到達率、burstiness 和輸入封閉策略；
主工作流異質服務率；
背壓政策、佇列容量及 control channel 限額；
CPU 親和性、實體核數、SMT 開關和快取／CCD 拓撲；
消息丟失、亂序、複製、暫停和故障比例；
相位欄位啟用組合及 gate 計算成本。

15.5 首輪負面證據比正面跑分更重要

本篇需公開以下可能不利於 SMPDC 的結果：

相位判定開銷大於節省的等待；
全域 credit 仲裁變成比原 scheduler 更大的熱點；
因為版本／權限欄位太大導致 cache pressure；
小消息大量進出佇列令 p99 變差；
觀測與 trace 使原本可能的加速消失；
非同步多主拓撲的順序不穩定使結果必須增加高成本驗證；
純 CPU 任務因過度切碎反而變慢；
硬體 topology 差異比抽象「星系擴散」更能解釋全部收益。

這些不是要用術語重新解釋掉的「暫時噪音」，而可能直接限制或推翻研究主張。

15.6 V1：現有一般消費級 CPU 原型

在 V0 協議安全基本成立後，V1 才利用現有多核桌機建置最小 Runtime。現有基準可使用使用者尚未更換的 AMD 桌機、32GB RAM 與 RTX 3070（本篇 CPU-only 實驗不要求 GPU 參與）；任何新型大小核 CPU 或雙 CCD 平台都屬後續可能購買的比較硬體，不能誤記為已持有設備。

建議以同一輸入 seed 至少進行多次重複，記錄 OS、BIOS、核心拓撲、電源計畫、記憶體設定、編譯器、CPU 頻率範圍、測試負載和輸出 hash，避免以單次跑分作結論。

15.7 故障注入與可接受結果

至少注入：

訊息延遲但不丟失。
重複消息以不同 attempt ID 抵達。
目標工作流已換核但訊息帶舊世代。
發送過程恰好耗盡最後 credit。
目標 queue 已滿。
不同工作流同時向同一目標發送。
耦合邊在訊息在途時撤銷。
活動中的 epoch 收到 seal。
無窮重試策略試圖繞過上界。
control channel 被資料消息阻塞。
本地 trace 觀測出不同世代交錯。
某工作流永遠停止進展。

對最後一項，允許正確顯示 blocked，不要求虛假的自動成功。

16. 一個完整的示意運行：五個主節點與有界擴散

16.1 設定

假設一台有足夠 CPU 執行資源的抽象機器，存在五個具獨立 PrimaryFlowNode Contract 的工作流：

$F_A$ ：外部事件接入與主工作流入口。
$F_B$ ：局部狀態查詢與第一條驗證線。
$F_C$ ：另一條平行資料處理線。
$F_D$ ：具版本依賴的候選聚合工作流。
$F_E$ ：後續驗證結果接收與待提交佇列。

所有節點均是語義上的主要工作流，不能因 $F_A$ 是事件入口就宣稱它對其他四個節點擁有無限權威。下述任何邊都屬邏輯連線，並非聲稱 CPU 核心間有新的物理導線。

對一次事件世代 $\epsilon=42$ ，設：

event_epoch = 42
root_event = user_defined_event_42
send_credit_budget = 8
control_credit_budget = separate_and_bounded
max_hops = 3
max_fanout_per_node = 2
external_admission = sealed_after_initial_event
reliability_policy = reliable_in_process_simulation
payload_mode = immutable_ref_with_version

此示意只有六次資料發送，因此帳本應該最終為 spent=6, remaining=2。若實測消息數不同，必須解釋重試、額外轉發、拒絕及 trace 是否計入。

16.2 相位與事件逐步追蹤

邏輯步驟	事件	作用	安全檢查
T0	`EPOCH_OPEN(42)`	對五個既有工作流建立新的事件責任	有限預算、合法 root
T1	`PHASE_SIGNAL(A,42)`	A 宣告自己持有本事件有效輸入	權限、世代及來源版本
T2	`COUPLE_ADMIT(A,B)` 與 `(A,C)`	啟用兩條合法邊	兩端相位、依賴及容量
T3	`DIFFUSE_SEND(A,B)` 與 `(A,C)`	兩次發送，已用 credit 2	唯一 token，扇出 2
T4	`DIFFUSE_SEND(B,D)`	B 產生聚合候選輸入	credit 3，版本有效
T5	`DIFFUSE_SEND(C,D)`	C 產生另一聚合候選輸入	credit 4，血緣分別記錄
T6	`PHASE_SIGNAL(D,ready)`	D 在確認 B/C 依賴後進入完整就緒	兩份輸入是否符合實際依賴
T7	`DIFFUSE_SEND(D,E)`	D 的候選聚合輸出送往 E	credit 5，不等於正式提交
T8	`DIFFUSE_SEND(B,E)`	B 發送附加待驗證證據	credit 6，與聚合消息不同型別
T9	`EPOCH_SEAL(42)`	不再接納新外部根	現存工作與 ACK 仍需清償
T10	`DIFFUSE_ACK(...)`	已發送消息完成各自協議清償	不得提前視為 commit
T11	`EPOCH_QUIESCE(42)`	無活躍工作、無在途義務	需完整一致的帳本／偵測協議
T12	`EPOCH_CLOSE(42)`	清理本 epoch 資源	正式輸出另受 Paper 04 管理

這是手工構造的協議示例，不是 CPU latency benchmark，也不代表 D 只有在所有實體消息都精確同時抵達時才能執行。D 可能先作 PartialReady 的可撤銷計算，但不能提前對外 commit。

16.3 兩個刻意設計的反例

反例 A： 在 T4 後，D 尚未收到 C 的消息便向 E 發送需要 B/C 雙依賴的正式聚合輸出。除非工作負載的依賴契約允許投機且標示候選，否則屬於 illegal phase activation，模擬器應判定失敗。

反例 B： 在 T9 後，A 因未知錯誤再次注入 new_root_event(42)，繞過 epoch seal。這違反本 epoch 的輸入封閉契約；不能因此創建新 credit 或將原本應結束的世代變為無限存在。若系統要接收該外部事件，應分配新 epoch 及相應受控資源。

16.4 性能的非平凡觀察

上述示例仍有可能比常規固定 DAG 執行更慢，特別是：

五個節點的消息量很小，不值得建立動態耦合邊；
A/B/C/D/E 實際都在相同快取共享域，固定佇列已近最佳；
PHASE_SIGNAL 與 COUPLE_ADMIT 帶來額外同步；
CreditLedger 出現全域原子競爭；
trace 記錄比實際工作消耗更多時間。

正因如此，本示例用於確立正確性語義與可觀測事件，不是用來說明 SMPDC 已經比現有 Runtime 快。

17. 與相鄰理論及成熟技術的差異

17.1 與經典 diffusing computation 的關係

Dijkstra–Scholten [E2] 對「一個事件引起的分散擴散活動如何偵測其終止」已有原創貢獻。本文直接承認該先例，因此不宣稱 diffusion 的基礎思想或終止偵測是 SMPDC 獨有。

SMPDC 的特定研究問題是：在同一個中觀執行協議裡，多個具有穩定主工作流身分的 CPU 論理節點，如何與相位資格、有限 quota、核心承載租約、背壓及後續 GPU 協作整合。

17.2 與 Kahn process networks 的差異

Kahn 型程序網絡以 FIFO stream 和限制性讀寫規則取得可決定性等性質；其理想模型常採無界 channel 作為語義假設，而實際實作需要處理容量與阻塞問題 [E3]。SMPDC 則在協議層先行要求有界資源與顯式背壓，並將權限、拓撲世代及承載遷移納入工作流交互契約。

但這並不意味 SMPDC 自然擁有 Kahn 網絡的決定性。動態路由、非固定合併順序與投機執行可能令相同輸入產生不同中間序；需要額外指定運算是否交換律、結合律、次序敏感或有明確排序歸約。

17.3 與 BSP / Pregel 的差異

BSP 以 superstep、全域通信及階段性同步提供並行計算模型 [E4]；Pregel 更把頂點局部處理與消息傳遞用於大型圖處理 [E6]。SMPDC 允許局部不同步、相位窗口相對、持續工作流與事件世代分離，但必須實測這種彈性是否抵得過增加的非同步管理成本。

如果某任務本就天然以 barrier 分段且消息密集、同步成本可控，BSP/Pregel 式既有方法可能是更適合的 baseline。

17.4 與 Reactive Streams 的差異

Reactive Streams 對非同步資料流有嚴謹的需求反饋及背壓原則 [E5]。SMPDC 不重製全部 Publisher–Subscriber API，而考慮把這類控制與相位資格、root epoch、credit 不可複製與權限 fencing 連在一起。

因此最有意義的對照，不是「無背壓傳統系統」對「有背壓新系統」，而是相同背壓強度下，相位型別與傳播選擇性還能額外改善多少。

17.5 與 Logical Synchrony Networks 的關係

2024 年的 Logical Synchrony Networks [E8] 研究以邏輯延遲分離同步控制與運算，並檢驗確定性與有界緩衝的關係。它提醒 SMPDC：讓控制層與執行層分離、支援高吞吐與保持緩衝界限，本身已是活躍研究領域。

本篇可在 V0 引入它所代表的同步設計方向作為對照，而不是把所有近似方法稱為 SMPDC 的前身或變體。

18. 給後續各篇的規範性交接

18.1 給 Paper 03：冗餘資訊流與主節點聚合

Paper 03 至少須以本篇 DiffusionEnvelopeV0_1、event_epoch、message_id、lineage_id、delivery_attempt_id、authority_scope 及 credit 預算為前提，明確處理：

R1／精確副本：同一邏輯 payload 的多路重傳與競速；
R2／異源佐證：兩份來自不同推導或來源的候選結果，如何建立可檢驗的相關性／獨立性；
R3／編碼冗餘：恢復及錯誤檢出能力依賴何種實際編碼與故障模型；
dedup、checksum、不同版本與衝突的處理；
即使兩條路均已到達，也不能自動產生對受控外部狀態的提交權。

redundancy_class_hint 只是路由與工作負載建議，不可以代替 Paper 03 的正式驗證契約。若 R1 每條分支都產生真正的發送嘗試，其信用和位元組成本必須如實計入。

18.2 給 Paper 04：推測性進度與權威提交

Paper 04 應區分：accepted_for_processing、locally_verified、globally_reconciled、authorized_to_commit、committed。本篇 EPOCH_QUIESCE 不能跳過這些責任，尤其不能從「消息都清空」推導出「結果已正確或已正式寫入」。

18.3 給 Paper 05：持續擴散抽象指令集

本篇具型別事件可作為候選語義：

PHASE_SIGNAL(epoch, scope, phase_kind, phase_payload)
COUPLE_PROPOSE(source, target, constraints)
COUPLE_ADMIT(edge, guard_proof)
DIFFUSE_RESERVE(edge, credit, bytes, version)
DIFFUSE_SEND(edge, message)
DIFFUSE_ACK(message, outcome)
DIFFUSE_THROTTLE(edge_or_epoch, policy)
COUPLE_QUIESCE(edge)
EPOCH_SEAL(epoch)
EPOCH_QUIESCE(epoch)

每個指令都必須具有輸入、效果與失敗路徑。命名為 PHASE_SIGNAL 的語言指令若沒有檢查副作用權限，便只能是一個通知而不是真正能安全控制硬體的高級操作。

18.4 給 Paper 06：程式語言與型別系統

最低型別效果應分辨：PhaseObserve、PhasePropose、CouplingAdmit、SendNonAuthoritative、WriteOwnedState、CommitAuthorized。語言不得讓對 PhaseObserve 的讀取隱含 WriteOwnedState 權限，也不得讓 DIFFUSE_SEND 忽略 finite budget。

18.5 給 Paper 07–10：Runtime、異質設備、硬體與 AI

Paper 07 需驗證無 AI 的規則控制器仍完整運作，AI 只能提出可被否決的建議。
Paper 08 需確認 GPU 並行關係運算的加速收益足以抵銷所有資料搬移、批次等待、kernel 啟動與 CPU 回收成本。
Paper 09 可以研究快取/CCD/NUMA/NoC 與微觀承載，但不可以把邏輯圖的圓形意象直接當成實體晶片拓撲。
Paper 10 應在明確的 AI 模型與訓練/推論負載中做 baseline；若普通異步 pipeline 已最佳化，SMPDC 必須證明額外的協議價值。

18.6 給 Paper 11：可證偽結案

Paper 11 不應預設一定能得出「新的計算機範式比傳統 CPU 更快」；它應報告某些工作負載適用、某些無優勢、某些失敗，以及仍待研究的工程瓶頸。若所有增量收益均可由傳統 scheduler＋現有資料流 library 等價實作，則本系列可以保留為高階描述語言，但不能宣稱已形成不可替代的新底層運算性能。

19. 結論

Paper 02 的核心結果，是把持續性多主工作流之間的協作從抽象「相位呼叫」推進為可審核的中觀操作協議。 每個工作流可保留自己的身份與局部計算責任，但一條擴散邊能否激活，必須由當前相位、依賴、授權、核心承載世代、資源及流量預算共同決定。

本篇建立四項可供後續研究直接沿用的基礎：

相位是可影響互動合法性的具型別狀態，而不是任意時間戳或振盪角度。
擴散必須是有界、有授權、有回應責任且具血緣標識的資訊流，不是無差別廣播。
持續性工作流可以跨很多 epoch 存活，而單一 epoch 的消息義務可以獨立判定清償。
任何加速命題都必須扣除相位判定、edge 管理、credit 仲裁、queue、背壓、trace、快取與故障恢復成本。

上述形式化在明示前提下有可檢查的安全性推論；尚未證明整體執行協議具有普遍活性，也未證明實體性能優越性。 理論的工程價值需由 Paper 03–11 的逐層實作與 A/B 實驗決定。

因此本篇最後的研究問題不只是「資訊能否擴散」，而是：

在多個自主但受限的主要 CPU 工作流之間，能否把訊息的允許性、相位就緒性與有限流量作為可編譯的計算語義，在與成熟異步系統相同的正確性契約下產生可重現的成本優勢？

附錄 A｜PhaseDiffusion Contract v0.1 檢查表

ID	契約性質	非合格情況
PD-C01	每個節點引用有效 PWN 契約	缺少 `flow_id`、世代或權限
PD-C02	相位具型別且有可觀測用途	任意標籤可突破相位 guard
PD-C03	明確分離工作流世代、拓撲世代與事件世代	使用同一欄位代替全部世代
PD-C04	候選耦合邊無法直接發送	`Candidate` 可跳過 `Admitted`
PD-C05	拒絕非法依賴輸入	缺少有效版本仍 `ExecReady`
PD-C06	Credit 是唯一不可複製資源	checkpoint 被複製後額度翻倍
PD-C07	每個發送嘗試符合發送預算	重試繞過 quota
PD-C08	每邊及全域都有限內存容量	緩衝隨輸入無界成長
PD-C09	安全撤銷不受性能型 hysteresis 阻擋	失效權限可繼續發送
PD-C10	在途義務可追蹤	消息未抵達卻清償
PD-C11	`Quiescent` 不等於 `Committed`	空 queue 自動對外輸出
PD-C12	具有效 ACK／取消控制路徑	data queue 塞滿導致永久無法取消
PD-C13	可區分消息與物理送達嘗試	一份消息重試被當成兩份獨立證據
PD-C14	具備 epoch seal 規則	已封閉的世代仍無限制加新 root
PD-C15	動態邊生成具版本	已撤銷邊之舊訊息取得新資格
PD-C16	不允許 AI 繞過硬性守衛	AI 建議增加 credit 即直接超發
PD-C17	觀測／診斷與權威效果分離	trace 訊息可變更受控狀態
PD-C18	支援無進展狀態如實回報	死鎖被偽報為完成
PD-C19	phase-blind 對照可執行	以未經檢驗的新名詞當作必要性證明
PD-C20	完整成本與安全效益可報告	只報 CPU usage 和單次速度

附錄 B｜建議的追蹤事件與資料結構

TraceEventV0_1 {
    timestamp_observed: MonotonicObservationTimestamp
    trace_sequence: MonotonicTraceIndex
    event_epoch: EventEpochId
    source_flow_id: OptionalStableFlowId
    target_flow_id: OptionalStableFlowId
    topology_generation: OptionalTopologyGeneration
    flow_generation: OptionalFlowGeneration
    event_type: TypedEventName
    message_id: OptionalMessageId
    credit_token_id: OptionalCreditTokenId
    result: "ok | rejected | deferred | cancelled | failed"
    reason_code: TypedReasonCode
    metrics_ref: OptionalMetricsSampleReference
}

事件追蹤的讀取並不自動等於完整因果關係重建。若多執行緒 log 使用不同 buffer 或在寫出時延遲，必須保留局部序列、因果父事件或可驗證的其他排序證據；不能把最後合併出來的文字行順序當成不可反駁的真實發生順序。

附錄 C｜形式化驗證建議與狀態空間範圍

C.1 V0 最小有限模型

建議在 TLA+、PlusCal、Alloy 或同等的有限狀態探索工具中測：

節點數：2–4。
邊：固定環、無環鏈、完整小圖。
epoch：1–2。
credit：0–4。
edge queue：0–2。
控制事件：send、ack、cancel、revoke、migrate、seal。
異常：out-of-order、duplicate、no-progress、lease expiry。

這些是待實作的驗證規格，不是聲稱本篇已完成模型檢查或產生 PASS log。

C.2 必須檢查的不變量

Inv1: no_negative_credit
Inv2: each_credit_has_at_most_one_effective_owner
Inv3: admitted_edge_required_for_send
Inv4: invalid_fencing_cannot_authorize_owned_state_write
Inv5: event_epoch_seal_blocks_new_external_roots
Inv6: no_quiescence_while_accounted_inflight_obligations_remain
Inv7: queue_capacity_never_exceeded
Inv8: diagnostic_phase_does_not_grant_commit_authority

活性條件應另外檢查，並明示 fair scheduling、可靠控制通道、有限工作片段與可失敗終局狀態；未引入這些前提的無限執行模型，不能直接要求 eventually Closed。

C.3 與既有發送上界命題的一致性

Paper 00 曾給出有限 credit 的基礎上界，Paper 02 對 credit 歸屬、重試、控制通道及閉合世代補齊前提。這是收緊原命題的適用域，而不是在沒有新假設的情況下宣稱證明更強的定理。 若未來採回收式 credit，則需重新定義「最多發送次數」為每次結算週期、同時在途數或其他明確計數，不應沿用當前不可回收 credit 的原式。

附錄 D｜UTF-8 Canonical Source 與版本治理規則

以本 .md 檔案的 UTF-8 bytes 為正式原稿，聊天畫面只作閱讀，不作唯一保存來源。
數學原始碼一律使用 $...$ 和 $$...$$，不得混用其他 LaTeX 數學分隔符，也不做 unicode_escape round-trip。
任何指令／結構定義如 PhaseSignalV0_1 均先視為候選規範；若修改欄位，需記錄從 v0.1 的遷移映射。
形式命題必須保留完整前提與不可推論的外延，不可在摘要或行銷稿中改寫為普遍已證明的效能定理。
若實驗顯示此協議沒有可測得的性能優勢，應直接註明負面證據；不能藉由改寫「相位」「擴散」定義迴避反例。
若與 Paper 00/01 不一致，先確認是新增可選擴充還是破壞性的契約變更，並在修訂歷程中註記。

參考文獻與原始研究連結

內部原稿（使用者既有研究脈絡）

[I0] Neo.K × Aletheia，〈SMPDC Paper 00｜群星多主節點持續擴散計算論：形式總綱〉，2026-10-16，v0.1；canonical UTF-8 Markdown：SMPDC_Paper00_Stellar_Multi_Primary_Persistent_Diffusive_Computing_v0.1_2026-10-16.md。
[I1] Neo.K × Aletheia，〈SMPDC Paper 01｜多主工作流節點論〉，2026-10-16，v0.1；canonical UTF-8 Markdown：SMPDC_Paper01_Multi_Primary_Workflow_Nodes_v0.1_2026-10-16.md。
[I2] Neo.K × GPT，〈相位計算機理論：相位本體、馮諾依曼模擬、非馮諾依曼原生與元機理選擇〉，2026-07-25。無界智庫公開版。
[I3] EveMissLab，〈GCCFT Paper 02｜計算相位與耦合激活：從時間排序到 Phase-Aware Interaction〉，2026-09-22。
[I4] Neo.K，〈群星架構在計算機系統中的應用與改良計畫〉，早期研究稿。
[I5] EveMissLab，〈GCCFT Paper 06｜從 Scheduler 到 Coupled Computation Planner〉。

外部學術與工程先例（來源核對日：2026-10-16）

[E1] Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7), 558–565. DOI: https://doi.org/10.1145/359545.359563 。作者／研究機構頁面。
[E2] Dijkstra, E. W., & Scholten, C. S. (1980). Termination Detection for Diffusing Computations. Information Processing Letters, 11(1), 1–4. DOI: https://doi.org/10.1016/0020-0190(80)90021-6 。Dijkstra 原始手稿（EWD687）。
[E3] Kahn process networks 理論及工程背景；見 Edward A. Lee 等對 dataflow process networks 的介紹與 FIFO/決定性分析：ScienceDirect Topics — Kahn Process Network。作為經典語義先例，不假稱一般有限緩衝非同步網路自動繼承其決定性。
[E4] Valiant, L. G. (1990). A Bridging Model for Parallel Computation. Communications of the ACM, 33(8), 103–111. DOI: https://doi.org/10.1145/79173.79181 。
[E5] Reactive Streams Initiative，Reactive Streams Specification for the JVM，非阻塞非同步背壓語義。官方專案；官方網站。
[E6] Malewicz, G., et al. (2010). Pregel: A System for Large-Scale Graph Processing. Proceedings of SIGMOD, 135–146。Google Research publication。
[E7] Chandy, K. M., & Lamport, L. (1985). Distributed Snapshots: Determining Global States of a Distributed System. ACM Transactions on Computer Systems, 3(1), 63–75。Microsoft Research。
[E8] Kenwright, L., Roop, P., Allen, N., Lall, S., Cascaval, C., Spalink, T., & Izzard, M. (2024). Logical Synchrony Networks: A Formal Model for Deterministic Distribution. arXiv:2402.07433。https://arxiv.org/abs/2402.07433 。

原創性與證據聲明

公開文獻中的事件偏序、過程網絡、擴散終止偵測、BSP、背壓、圖式消息處理與邏輯同步，是本研究必須承認的既有成果。雲端原稿提供 Neo.K 舊有理論及設計的歷史連續性，不能當成外部實驗已完成的證據。本篇新增的具型別 PhaseDiffusion Contract、共同守衛及分層實驗規格，是供後續形式驗證與工程反駁的研究候選。尚無證據可據此宣稱一定降低 DRAM 價格、替代現有 CPU/GPU 架構、普遍提升 AI 訓練速度，或已證明優於成熟異步 Runtime。

SMPDC Paper 02｜相位耦合與有界持續擴散動力學：多主工作流的激活、流量、背壓與靜止偵測

SMPDC Paper 02｜相位耦合與有界持續擴散動力學

——多主工作流的激活、流量、背壓與靜止偵測

摘要

1. 研究任務、限制與真正的增量

1.1 從節點存在到節點互動

1.2 本篇交付

1.3 嚴格不處理的內容

1.4 新穎性不可過度主張

2. 概念層級與原稿相容性

2.1 PCMT 四層分離

2.2 對接 GCCFT 相位觀

2.3 相位的必要性測試

3. 繼承 SMPDC 九元模型與節點契約

3.1 原有九元狀態不重命名

3.2 從 Paper 01 繼承的必要欄位

3.3 三個身分空間

3.4 安全與活性分開

4. 具型別的相位狀態與訊號

4.1 相位不是單一數字

4.2 一個候選封套

4.3 PhaseSignal 的三種不同用途

4.4 相位更新原則

5. 相位就緒規則：何時才可啟動工作

5.1 就緒判定分兩層

5.2 部分就緒不得偷換成完整就緒

5.3 就緒與執行租約

5.4 就緒轉移的反直觀性

6. 相位耦合：從候選關係到合法可執行邊

6.1 相位耦合不是把兩個狀態相加

6.2 耦合的允許條件

6.3 CouplingEdge Contract v0.1

6.4 邊狀態轉移

6.5 不應依幾何距離決定所有邊

6.6 耦合滯後（hysteresis）與反覆開關

7. 有界持續擴散：本系列最主要的動力學實體

7.1 擴散的操作定義

7.2 「持續性」與「擴散性」不同

7.3 DiffusionEpoch 的封閉性

7.4 消息血緣與層數

7.5 訊息封套最小型別

7.6 邏輯發送、物理嘗試與處理效果

8. Credit 守恆式傳播預算

8.1 為什麼只靠 TTL 不夠

8.2 最低信用制度

8.3 分散帳本的安全發放

8.4 CreditLedger Contract v0.1

8.5 控制訊息是否收取 credit？

8.6 資料容量與 credit 分離

9. 背壓、排程公平性與擴散速度

9.1 背壓不只是效能優化

9.2 兩層容量

9.3 連續型擴散流速

9.4 允許的降級策略

9.5 公平與優先級反轉

10. 執行轉移系統：相位與擴散如何發生

10.1 操作事件字母表

10.2 原子性邊界

10.3 參考轉移關係

10.4 參考偽程式碼

10.5 工作流遷移時的交接

11. 工作流靜止、擴散靜止與終止偵測

11.1 最容易混淆的三個術語

11.2 為什麼不能只看 queue 為空

11.3 Quiescence 的候選判準

11.4 終止偵測三種可比較實作

11.5 實體 CPU 工作流持續存在，不妨礙 epoch 終止

11.6 關於時鐘與因果

11.7 活性前提不能省略

12. 三項條件性命題與證明邊界

12.1 命題 A：已封閉 epoch 的 credit 發送上界

12.2 命題 B：舊世代相位訊號不能自行取得新權威

12.3 命題 C：完整責任清償能避免特定誤判

12.4 一項值得主動證偽的性能命題

13. 反例與故障模式：這個架構最容易失敗的地方

13.1 全域廣播風暴

13.2 只靠時間戳的錯誤同步

13.3 兩個主工作流爭寫同一狀態

13.4 重試把有限額度變成無限流

13.5 Credit 分片複製