title

SMPDC Paper 03｜冗餘資訊流與主節點聚合協議：有界多路傳播、具型別佐證、編碼恢復與可驗證收斂

english_title

Redundant Information Flows and Primary-Node Reconciliation: Bounded Multipath Propagation, Typed Corroboration, Coded Recovery, and Verifiable Convergence

series

SMPDC — Stellar Multi-Primary Persistent Diffusive Computing

paper

03 / 11

version

0.1

status

Full Research Manuscript — Proposed Reconciliation Protocol, Conditional Safety Claims; 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) · SMPDC Paper 02 v0.1 (2026-10-16)

artifact_scope

Typed redundancy modes, evidence identity, receiver/aggregator state machines, conditional safety propositions, faults, costs, and falsification-first validation

SMPDC Paper 03｜冗餘資訊流與主節點聚合協議

——有界多路傳播、具型別佐證、編碼恢復與可驗證收斂

英文題名： Redundant Information Flows and Primary-Node Reconciliation: Bounded Multipath Propagation, Typed Corroboration, Coded Recovery, and Verifiable Convergence
系列： 群星多主節點持續擴散計算論（SMPDC）
主構想提出： Neo.K
研究協作： Aletheia / GPT-6
機構： EveMissLab／一言諾科技有限公司
日期／版本： 2026-10-16／v0.1
研究成熟度： L0–L1：具型別協議、條件命題、反例及測試規格；尚未實作、量測或完成模型檢查。
承接： SMPDC Paper 00–02 [I0–I2]。

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

摘要

SMPDC 系列研究一個中觀—宏觀的異質計算問題：多個 CPU 實體核心能否分別承載穩定而自治的主要工作流，並利用相位耦合、有界訊息擴散及選擇性的 GPU 並行協作，對特定 AI 訓練、推論或動態計算負載取得可重現的端到端效益？Paper 01 已建立具有局部狀態責任、執行租約及遷移防護的 PrimaryFlowNode Contract v0.1；Paper 02 已建立相位、耦合邊、不可複製傳播 credit、背壓與事件世代靜止偵測。然而，允許資訊流動還不能回答一個關鍵問題：同一工作結果經由兩條或多條路徑抵達後，主節點究竟應當如何認定它們的身分、價值、可信程度、相互依賴與可合併性？

本文提出 RedundantFlowReconciliation Contract v0.1，將使用者原始構想中「為降低延遲，可先送兩路相似或互補資訊，再由主要節點合併、判斷、去重」區分為四種不同語義：R0 單路、R1 精確複製／競速、R2 異源或異算法佐證、R3 具有明確碼參數的編碼冗餘。這些型別各有不同的成功條件：R1 可以在適當條件下改變完成時間分布，卻不會憑複製而產生獨立正確性證據；R2 可以揭露衝突，卻無法靠兩個相互矛盾的候選自行判定真值；R3 的重建能力取決於編碼參數、有效份額、擦除／錯誤模型與獨立性假設，而不取決於資料看起來「相似」。

本文進一步定義四層不同的身分——邏輯結果、候選計算、邏輯訊息與物理傳輸嘗試——以及版本化資料綱要、來源血緣、候選可信性、共享故障域、有效期限和局部聚合權限。本文建立分段驗證接收管線、單次聚合決策的狀態轉移、冪等處理邊界、衝突隔離及取消／重播規則；在明示的原子性、故障與權威假設下，提出關於重送去重、錯誤隔離及可證明合併操作的條件性命題。所有候選合併均僅能得到局部候選結果或局部驗證狀態，不能藉由多數票、雜湊吻合或傳輸 ACK 自動越過 Paper 04 才定義的正式權威提交層。

本篇以 Hedged Requests、冪等訊息處理、Raft、CRDT、Reed–Solomon 編碼、Dijkstra–Scholten 終止偵測及 NCCL 為先例對照；其增量不是發明複製、去重或編碼，而是檢驗上述機制能否在每核持續主工作流＋相位擴散＋有限信用傳輸＋分層聚合的整體近硬體 Runtime 中形成可描述、可編譯、可反證的協定。所有效能優勢均須在相同品質、同等資源與完整開銷計入的實測條件下另行驗證。

關鍵詞： 多主工作流、冗餘資訊流、相位擴散、異源佐證、編碼冗餘、局部聚合、去重、冪等、相關故障、Hedged Requests、CRDT、Reed–Solomon、確定性驗證、CPU/GPU、可證偽實驗。

1. 問題、論文增量與排除範圍

1.1 從「兩路較快」到「兩路究竟意味什麼」

直觀上，若一條資訊路徑延遲不穩，第二條路徑可能較快抵達；若一份結果可能存在錯誤，另一份結果可能揭露不一致。然而，這兩種動機不同：前者主要處理完成時間分布，後者處理證據與正確性。如果兩份內容來自同一個錯誤來源或複製了相同錯誤，冗餘並不能使它們互相糾錯。若傳兩條路帶來更多快取競爭、記憶體讀寫、佇列堵塞或額外驗證，冗餘甚至可能同時增加成本與延遲。

本篇因此拒絕將「多路」、「可靠」、「一致」、「確定性」、「準確」和「收斂」當成同義詞。各項屬性需有自己的判準、成本及失敗報告。

1.2 本篇五項研究問題

RQ03-1｜型別： 何時兩份資料是同一結果的不同傳遞，何時是獨立推導，何時是具有可解碼關係的份額？

RQ03-2｜正確性： 主節點如何分離接收、完整性、來源驗證、語義比較、佐證與正式權威？

RQ03-3｜速度： 多路抵達何時降低 p95／p99，何時因資源競爭而惡化？

RQ03-4｜持續性： 工作流遷移、世代變化、訊息亂序、重新發送和取消，會否造成重複計算或雙重有效結果？

RQ03-5｜可操作性： 能否把上述差異建立成可模擬、可型別檢查、可追蹤且可映射至一般 CPU 的協議？

1.3 預定交付成果

本篇交付六個可版控規範：

1. RedundancyMode Contract v0.1：R0／R1／R2／R3 的互斥語義與模式轉換規則。
2. ReconciliationEnvelope Extension v0.1：對 Paper 02 訊息封套的相容擴充。
3. CandidateEvidence Contract v0.1：候選來源、獨立性聲明、版本與證據要求。
4. PrimaryReconciler Contract v0.1：主節點聚合狀態機、去重、驗證、衝突及輸出。
5. ReconciliationSafety Invariants v0.1：可在有限狀態模型中檢查的安全性條件。
6. V0/V1 Falsification Protocol v0.1：負面控制、故障注入、效能量測及停止準則。

1.4 明確不提前宣稱的事項

• 本篇不是可直接安裝的 CPU 微碼、全新物理互連或已完成的 GPU kernel。
• 不宣稱兩路資料在所有場景均比單路更快，亦不宣稱複製兩份可以天然提高正確率。
• 不宣稱本篇的 VerifiedLocal 就是 Paper 04 的 Committed。
• 不把 GPU 計算所謂「流速」等同於 CPU 核心間新增實體連線。
• 不把 CRDT、quorum、雜湊校驗、仲裁與錯誤更正碼混成一種模糊的「高確定性格式」。
• 不要求每顆物理 CPU 核心永久綁定一個實體主權控制器；此為可變執行映射，不是硬體主權制度。

2. 與 Paper 00–02 的相容性

2.1 不重新命名九元中觀系統

延續 Paper 00，系統仍寫成：

本篇主要細化 $\mathcal{M}_t$ （訊息與候選）及 $\mathcal{Q}_t$ （驗證、冗餘、聚合契約），也將多路策略造成的頻寬、佇列及計算成本計入 $\mathcal{R}_t$，把候選證據與失敗原因寫入 $\mathcal{L}_t$。 $V_t$ 、 $E_t$ 、 $\Phi_t$ 與 $\rho_t$ 的前置語義不因本篇擴張而改變。

2.2 繼承 PWN 的主節點概念

Paper 01 的 Primary Workflow Node（PWN）有穩定 flow_id、狀態責任、邏輯進度和有限自治權。本文的「聚合主節點」是針對某個邏輯結果被指定執行局部聚合的工作流角色，不是整台機器唯一的 CPU 核心，也不因此取得其他工作流受控狀態的寫入權。

2.3 不越過 Paper 02 的擴散安全邊界

任何實際傳送的 R1／R2／R3 分支仍需遵守：

• event_epoch 及 topology_generation 的有效性；
• source_generation、source_fencing_token 及來源權限；
• PhaseDiffusion Contract v0.1 的相位、耦合邊及依賴守衛；
• 不可複製 send_credit_id，以及訊息數量／位元組容量限制；
• 外部新根事件限制、已封閉 epoch 的入域與內部義務清償規則；
• 必須由獨立可靠控制通道或保留控制額度送出 ACK、取消與清償事件。

同一根資料的兩路實體傳送若是兩次已計入的入佇列／傳播嘗試，必須各自消耗對應的 token；不允許因稱為「副本」便複製 credit。

2.4 工作流存在、擴散靜止與提交完成分離

定義三種互不蘊含的條件：

持續性 PWN 可以在某一 epoch 已靜止時繼續存活；所有訊息責任清償，不意味已產生有效候選結果；候選驗證通過，也不等於已取得對外寫入權。這個分離是後續全部規範的共同前提。

3. 複製的對象：四層身分不可混同

3.1 邏輯結果鍵（Result Key）

對一個有明確語義的求值目標，提出候選鍵：

其中 $d$ 為結果／權限域、 $e$ 為事件世代、 $o$ 為運算身分、 $v$ 為輸入版本或快照指紋、 $s$ 為語義綱要版本、 $a$ 為權限範圍、 $r$ 為結果種類。這只是同一論證對象的識別鍵，不保證每份 payload 都正確。

3.2 候選運算鍵（Candidate Key）

$b$ 為候選分支、 $x$ 為該分支的實際執行身分。兩個候選可擁有相同 $K$，但使用不同演算法或來源。候選不同不等於證據獨立。

3.3 邏輯訊息鍵（Message Key）

$m$ 為語義訊息身分。共享 $M$ 的多次發送是重試或複製配送，不可增加「獨立候選」數量。R3 的不同編碼份額應以不同 shard_index 或相應子身分識別，避免被錯誤消去。

3.4 實體送達嘗試鍵（Attempt Key）

$u$ 為送達嘗試身分；可能對應入佇列、共享記憶體複製、設備提交或跨程序傳輸。重送產生新的 $A$，但不天然產生新的 $C$。

3.5 四種計數都必須在追蹤中存在

例如同一錯誤答案 $y$ 透過五條路徑抵達：五個 attempts 可以收斂為一個邏輯訊息、一個候選、一個仍然錯誤的結果。若把每次抵達當作新的「一票」，系統可被重試流量污染。

4. R0／R1／R2／R3 的最低型別系統

4.1 RedundancyMode Contract v0.1

重要： single/duplicate/corroborate/coded 既有於 Paper 00–02，本文細化其規範，不另改名。如果同一上游工作同時需要競速和交叉校驗，應建立巢狀或分階段計畫（例如 R2 的兩個候選各自允許 R1 配送），不可將單一模式欄位偷偷重解釋為任意複合行為。

4.2 每種冗餘回答不同的問題

• R1 回答「同一正確性要求的結果，能否更早由任一路徑送達？」
• R2 回答「不同候選在指定比較契約下是否相容？若不相容應如何處理？」
• R3 回答「在規定的遺失／錯誤範圍內，是否存在唯一可驗證的原始載荷？」

形式上，它們不是由「冗餘副本數 $n$ 」這一個參數可無損表示的單一運算。

4.3 高確定性格式的五種不同意思

1. 編碼決定性： 同一規範輸入可得到同一序列化 bytes。
2. 運算決定性： 在指定硬體與數值契約下重算結果可重現。
3. 傳輸完整性： payload 與完整性標記一致，降低部分資料損壞風險。
4. 來源可驗證性： 訊息能被綁定到受信授權的來源身分及世代。
5. 語義／證明正確性： 候選符合目標問題及驗證規則。

前四項不等於第五項。特別是雜湊吻合可能只代表「錯誤被忠實複製」，不是「計算答案正確」。

4.4 模式轉換與降級需要授權

R2 在發現兩來源其實共享同一模型輸出後，不可繼續宣稱獨立佐證；可降為 R1 關係或保留 R2 但標記「高度相關／不能增加獨立支持」。R3 份額不足時可等待或失敗，不得沒有證據便將任意份額當 R1 複製品。R1 競速資料未能合法驗證時，不能單因 deadline 接近就升級為局部已驗證結果。

5. 資訊封套：對 PhaseDiffusion 的相容擴充

5.1 繼承，不取代 DiffusionEnvelopeV0_1

Paper 02 既有 message_id、root_event_id、event_epoch、lineage_id、hop_count、max_hops、source_flow_id、source_generation、target_flow_id、topology_generation、source_state_version、causal_parents、payload_schema_id、payload_ref、transmission_class、redundancy_class_hint、authority_scope、source_fencing_token、send_credit_id、delivery_attempt_id、expiry_policy 與 trace_id。

本篇定義其伴隨 metadata 或版本化 extension，不允許舊訊息因缺少新型別欄位而被默認當作 VerifiedLocal。

5.2 ReconciliationEnvelopeExtensionV0_1

ReconciliationEnvelopeExtensionV0_1 {
    extension_schema_id: SchemaId
    extension_schema_version: 1

    result_key: LogicalResultKey
    operation_id: StableOperationId
    candidate_id: StableCandidateId
    candidate_branch_id: StableBranchId
    computation_attempt_id: StableExecutionId
    logical_message_id: StableMessageId
    delivery_attempt_id: StableAttemptId   // mirrors base envelope

    redundancy_mode: Single | Duplicate | Corroborate | Coded
    plan_id: StableRedundancyPlanId
    plan_version: MonotonicPlanVersion
    semantic_comparator_id: OptionalComparatorId
    comparator_version: OptionalComparatorVersion
    merge_algebra_id: OptionalMergeAlgebraId

    payload_schema_version: ExplicitSchemaVersion
    payload_digest: OptionalVersionedDigest
    canonicalization_id: OptionalCanonicalizationRuleset
    provenance_chain_ref: BoundedProvenanceReference
    shared_fault_domain_id: OptionalFaultDomainTag
    evidence_policy_id: TypedVerificationPolicyId
    evidence_ref: OptionalEvidenceReference

    coded_group_id: OptionalCodingGroupId
    coding_scheme_id: OptionalRegisteredCodeId
    coding_parameters: OptionalBoundedCodingParameters
    shard_index: OptionalShardIndex
    shard_digest: OptionalDigest

    aggregation_owner_flow_id: StableFlowId
    owner_generation: MonotonicGeneration
    owner_fencing_token: MonotonicFencingToken
    input_snapshot_id: StableSnapshotIdentifier
    expiry_condition: ExplicitTimeOrEventPredicate
}

此結構為概念規範：實際傳輸可以用短 header＋不可變 side table 減輕負擔；必須證明 side table 版本、權限與記憶體生命週期仍然安全。shared_fault_domain_id 為保守的已知群組標示，unknown 不得被當作「已獨立」。

5.3 數據大小、序列化與版本拒絕

接收端必須有：

• 明確的最大 header、payload、依賴集合及證據參考長度；
• 允許的 schema／算法／編碼版本清單；
• 不信任由 payload 自行指定的任意解碼器或指令地址；
• 原子或可審核的跨版本轉換規則；
• 未知或不相容重要欄位的拒絕、延遲或有記錄降級；
• 所有語義比較與合併先綁定輸入快照、精度及型別。

一個 NaN、負零、浮點捨入差異、Unicode 正規化差異或不定序 map 的 bytes 差別，都可能造成「語義相同但雜湊不同」。反過來，不同版本的兩個 payload 就算偶然有相同 bytes，也可能代表不同單位或語義。故 bytes equal 與 semantic equivalent 永久分離。

5.4 來源宣告與來源驗證不同

同機記憶體保護域內的來源身分可以由 OS 或受信 Runtime 驗證；跨主機、跨租戶或不可信來源須另行使用適當的認證和權限機制。source_flow_id 是宣告性欄位，不自帶密碼學來源保證；單純 checksum 或非金鑰雜湊不是身分認證。

6. 冗餘計畫與進入條件

6.1 RedundancyPlanV0_1

RedundancyPlanV0_1 {
    plan_id, plan_version, event_epoch, result_key
    mode, branch_limit, attempt_limit, deadline_policy
    payload_bytes_budget, send_credit_budget, compute_budget
    required_result_quality, verification_policy
    source_diversity_policy, fault_domain_model
    branch_start_policy, hedge_delay_policy
    quorum_or_witness_policy, comparator_policy
    coded_parameters_if_any
    aggregate_owner, owner_generation, fencing_token
    fallback_policy, cancel_policy, expiration_policy
    telemetry_sampling_policy
}

branch_limit、attempt_limit、send_credit_budget、payload_bytes_budget 不能互相代替。兩條支路即使都使用同一個 immutable payload ref，仍可能各有 cache miss、指標驗證、佇列操作與同步成本。

6.2 不可以無條件送兩份

R1／R2／R3 的採用至少取決於：

1. 當前工作負載是否對尾延遲、資料遺失或錯誤敏感；
2. 單路及多路成本能否在同一度量下比較；
3. 路徑延遲／故障是否高度相關；
4. 接收方是否有容量進行額外比較或解碼；
5. 是否存在合法的「第一個有效結果」判準；
6. 每條分支能否在 PhaseDiffusion 的額度內傳輸；
7. 取消是否能及時釋放資源，或只是取消未來分支；
8. 哪些結果需要 proof、權威 domain 或持久化見證；
9. 背壓狀態會否讓第二份資料變成嚴重干擾。

若沒有可驗證收益的理由，R0 應作為合法而非被貶低的預設。

6.3 冗餘計畫的授權邊界

PWN 可以依本地授權提出 ProposeRedundancy，但真正多路發送仍需有效耦合邊、擴散額度、資源分配及外部權限。若 AI 控制層建議增加支路，不能改寫權限或超發 credit；OS/Runtime 的確定性安全守衛仍是必要底層。

6.4 取消未完成副本的條件

對 R1，當存在一個通過既定品質驗證的候選時，可以向其餘分支發出 CancelRequested，但其他分支可能已執行部分工作、已完成 DMA 或已開始不可取消的 kernel。實測必須計入取消延遲、剩餘計算與額外資料搬移，而非假設取消立即且免費。

7. R1 精確複製與競速協議

7.1 精確副本的語義

R1 的兩路可能是：

• 一次候選計算，多次物理配送；
• 同一規範輸入與演算法的兩次計算，具有可區分 execution id；
• 同一資料在兩個允許的路徑／佇列中進行有條件競速。

第二種即使由不同核心執行，仍可能遭遇共享程式缺陷、同一輸入錯誤、同一編譯器 bug 或相同浮點異常。因此 R1 的運算重做不自動升為 R2 的獨立證據。

7.2 何謂 first valid

定義候選 $c$ 的局部有效檢查：

這裡的 Policy 可以要求純量範圍、證明、快照一致、決定性重算等，依工作負載決定。先抵達不等於先有效；先通過廉價 hash，也不等於已滿足完整局部驗證。

7.3 理想化尾延遲模型

設一份候選經路徑 A、B 的完成時間為 $T_A,T_B$。在兩者均可合法輸出等價結果，且 winner selection 不需要等待 loser 的前提下：

對時間門檻 $t$：

只有在獨立性成立的特殊模型下，才能改寫為尾機率相乘。真實 CPU 工作流共享 LLC、記憶體頻寬、熱／功耗預算與 OS 排程時，路徑往往相關；啟動第二份副本還可能令原本第一條路徑變慢。故不能將上述理想式直接當成實測保證。

7.4 Hedging 策略

候選策略：

• immediate_duplicate：兩路同時送；可能浪費最多但降低部分尾部等待。
• delayed_hedge：等待指定分位數或實測延遲門檻後才啟用備援。
• failure_triggered_retry：只有明確失敗或過期才重試。
• no_duplicate：R0 基準。

所有策略的觸發時間、資源配額與停止條件應在實驗前固定；不可在結果不好時事後任意換參數再宣稱通用優勢。

7.5 R1 主節點聚合規則

1. 相同 result_key、有效 input snapshot、相容 schema 的候選可進入同一聚合群。
2. 相同 logical_message_id 之重送只增加傳輸觀測，不增加候選佐證票數。
3. 第一份滿足 ValidLocal 與結果契約的候選可標為 LocalSelected。
4. 不可取消或已在途的其餘分支繼續處理其 credit/ACK 清償，不再重複輸出有效本地結果。
5. 若所有分支均無效或失敗，輸出明確 Unavailable/Failed，不偽造有效結果。
6. LocalSelected 仍不是授權域正式提交。

8. R2 異源佐證與衝突識別

8.1 佐證對象不是重複封包

R2 允許主節點在同一 result_key 下收集兩個或多個不同計算來源產生的候選。其差異可來自不同資料來源、獨立測量、不同數值方法、獨立實作或不同形式證明鏈。然而，不同執行序號、不同 CPU 核心甚至不同 AI 模型名稱，都不是嚴格的統計獨立性證明。

例如 A、B 兩個算法都讀取同一份錯誤的觀測資料，即便算式各不相同，也可能共同輸出相同錯誤結論。R2 只能從可追蹤的血緣和已聲明假設建立可信性程度。

8.2 三種佐證關係

對兩個候選 $c_a,c_b$，定義可檢查的候選關係：

• Equivalent：符合已版本化的等價判準。
• Compatible：相容但未必完全相等，例如兩區間具有非空交集，且規範允許。
• Conflict：在同一語義目標與比較規則下不可共同成立。
• Incomparable：目標、單位、精度或版本不同，未定義合法比較。
• Unknown：資料不足或驗證器無法完成。

只檢查兩個字串是否相同，不能替代這五種情況。Compatible 也不能在沒有完整可行集規則時直接當作 true。

8.3 佐證獨立性與相關故障

將候選的來源血緣表示為有向圖 $\mathcal{G}_{prov}$。若二者共享同一原始量測、模型權重、校準參數、程式版本或存取失敗域，就應記錄交集，而非默認獨立。

若兩個錯誤事件分別為 $E_a,E_b$，其共同出錯機率為：

只有在具體、可辯護的獨立性假設下，才能以 $\Pr(E_a)\Pr(E_b)$ 代替此聯合機率。沒有校準資料時，不能以「兩個候選一致」推算出任意明確的正確性百分比。

8.4 兩份不一致不能靠兩票判案

假設候選 A 回傳 $7$，候選 B 回傳 $9$。若沒有外部可驗證的運算規格、證明、可信第三來源或權威優先序，單靠兩份候選不能確定哪一份正確。合法策略只能是：

• ConflictHold：保存兩份候選並標記衝突；
• RequestWitness：要求第三來源、形式證明或決定性重算；
• ApplyAuthorityPolicy：使用事先約定、可查核的優先權規則，但需標記此為權威選擇而非真值證明；
• FailClosed：不得繼續產生高風險輸出；
• UseApproximateContract：只有當事先定義了近似允收規則時才可採納。

R2 的價值可能在於「更早揭露不可靠」而非「更快形成答案」。負面結果同樣是有效研究成果。

8.5 形式證明與重算證據

對形式化、可決定的工作負載，主節點可以要求 ProofArtifact 或可信驗證器輸出；對純數值工作負載，可依問題性質要求殘差界、區間包覆、穩定性檢查、同一輸入不同算法交叉比對。不可把數值結果附近的多個浮點表示視為新的邏輯真理。

驗證器的正確性本身是可信計算基礎（Trusted Computing Base, TCB）的一部分，需要版本管理、測試與失效處理；驗證器不是因為被命名為 verifier 就無錯。

8.6 可反駁的 R2 命題

假說 H-R2（未證實）： 對共享故障來源可識別、可取得異源候選且驗證契約具有區分能力的工作負載，R2 可能提高特定錯誤的偵測召回率；其收益須以衝突檢出率、錯誤放行率、額外運算成本及端到端延遲共同量測。

如果測試顯示 A、B 高度相關、錯誤率沒有改善或檢驗成本過高，本假說對該工作負載失敗。

9. R3 編碼冗餘與資訊恢復

9.1 編碼冗餘與「兩個類似位元」不同

本研究保留原始構想中「兩條近似或互補資訊流，最後合併」的研究意圖，但在 R3 必須要求可明確定義的編碼與解碼關係。任意兩個相似位元不具有自動修復能力；必須說明哪個是資料符號、哪個是校驗符號、彼此在何種有限域或編碼方案下相聯。

如果 R1 是複製相同字節，R3 是將原始資料映射為多個可驗證份額，兩者可比較但不可混同。對 GPU 或 CPU 上的高速實作，編碼本身的計算與搬移成本也需列入。

9.2 抽象編碼模型

設原始載荷為 $x$，編碼器與解碼器分別為：

$\theta$ 含編碼方案、版本、有限域、資料符號數、總份額數、符號索引及可信前提。研究最低要求是：對符合所選故障模型的有效份額集合，解碼可以唯一恢復同一載荷，否則明確失敗。

對適當的 $(n,k)$ MDS 擦除碼，在只存在已定位擦除且剩餘份額未被未偵測篡改的條件下，通常可由任意 $k$ 個不同、有效的份額重建資料；這不是任意錯誤下的普遍承諾。[E4]

9.3 距離界與兩份不足的情況

對碼的最小距離 $d_{min}$，典型離散碼理論給出可保障的錯誤更正半徑：

並且對已知位置的擦除，可在對應前提下處理最多 $d_{min}-1$ 個擦除。這些是相應碼模型下的規則，不是從「冗餘」一詞直接推出。

兩份完全相同的資料，若其中一份無法通過完整性校驗，可以使用另一份；若兩份內容不同且缺少可信校驗或外部見證，無法僅靠彼此決定哪一份正確。

9.4 份額去重不得刪除解碼所需資訊

R3 份額的邏輯身分至少為：

同一索引的重送可以去重；不同 shard_index 的有效份額即使 bytes 恰巧相同，也不應僅依 payload hash 全部刪除。反之，兩份同一索引但 bytes 衝突必須觸發一致性／來源錯誤，不能任選一份偷偷繼續。

9.5 擦除、未知損壞與惡意篡改

至少分為：

1. ErasureKnown：份額未收到或已被明確判為無效；
2. CorruptionUnknown：份額存在但無法辨識是否錯誤；
3. ByzantineTampering：來源可能主動提供協議一致、內容卻錯誤的份額；
4. CommonModeEncodingBug：所有份額均由同一錯誤編碼器生成。

擦除碼能否容忍第二、第三種情境，取決於具體的碼與認證機制，不能用單純 (n,k) 參數涵蓋全部安全條件。

9.6 解碼資源模型

定義：

若載荷極小、路徑延遲低，額外編碼成本可能遠大於任何恢復收益。若資料量極大或存在明顯分散傳輸損失，編碼可能有用。必須在同一故障模型下比較 R1 完整副本和 R3 編碼，而不是只比較名義冗餘比例。

10. 比較、去重與合併的代數邊界

10.1 先定義三種不同操作

DuplicateFilter : Messages × SeenState -> UniqueMessages × SeenState
CompareEvidence : Candidates × ComparatorPolicy -> RelationEvidence
MergeCandidates : EvidenceSet × MergeContract -> LocalOutcome

DuplicateFilter 不需要判斷某個公式是否正確；CompareEvidence 不必真的合併狀態；MergeCandidates 不必等於外部副作用提交。三者的測試與權限應彼此分離。

10.2 位元一致、語義等價與可安全合併

• ByteEqual(a,b)：序列化位元組一致。
• SemanticEqual(a,b,s)：在語義規格 $s$ 下等價。
• Mergeable(a,b,p)：在合併政策 $p$ 下，存在規定的合法結果及副作用界線。

前兩項均不自動推出第三項。例如同一份「扣除餘額 $100$ 」指令，即使 bytes 相同，也不能被視為兩份可安全疊加的財務操作；需要業務冪等鍵及授權提交規則。

10.3 可交換合併的候選條件

若某種聚合操作 $\sqcup$ 已被證明具結合律、交換律及冪等律：

則在指定資料域內，可較容易容忍重送和不同抵達順序。CRDT 提供成熟的對照，但只有相應資料型別與操作符合收斂條件時，才能使用這個性質。[E5]

此處的「冪等合併」不是所有資料的天然性質。向量加總、計數累加與梯度累積往往不是冪等操作。

10.4 浮點合併是陷阱

IEEE 浮點數加法一般不具精確結合律，將 GPU 批次結果換順序可能造成位元級不一致。若驗證要求逐位重現，就需要固定縮減樹、固定精度、固定裝置條件及必要時的可重現加總策略；若允許近似等價，必須定義誤差界、NaN 與 Inf 政策、相對／絕對容忍門檻及錯誤累積方式。

不得把「差不多相同」默認為可合併；近似性必須是事先明定的工作負載契約。

10.5 模式與聚合函數矩陣

11. 主節點聚合權限與局部收斂

11.1 聚合者是工作流角色，不是單點的永久中央 CPU

對邏輯結果 $K$，指定有權聚合的工作流 $owner(K,t)$。不同結果鍵可指向不同 PWN，並隨合法租約與遷移改變：

為降低熱點，可以依可測量的資料局部性、負載及責任域將不同 $K$ 分片。聚合者只具有 AggregateLocal(K) 之權，不天然具有 CommitAuthoritative(K)。

11.2 聚合者所有權與仲裁規則

若聚合者工作流遷移，需沿用 Paper 01 的租約與 fencing 機制。舊 owner 的延遲計算結果可以作為待驗證候選被新 owner 讀入，但不能憑舊 owner_generation 寫入新的受控聚合狀態。

兩名 PWN 即使同時都被作業系統安排執行，也不能對同一受控聚合記錄同時具有有效寫入租約。此限制是局部一致性要求，不否定各自的工作流自治。

11.3 聚合狀態與外部權威狀態

將狀態分為：

LocalCandidateSet
LocalVerifiedEvidence
LocalReconciliationOutcome
CommitProposalToAuthority
AuthoritativeState    // owned by Paper 04 protocol, not by RFR alone

LocalReconciliationOutcome 可以指向 SelectedCandidate、CodedRecoveredPayload、CorroboratedEvidenceSet、Conflict、Unknown 或 Failed，但本篇不自行修改外部權威狀態。

11.4 聚合工作的並行界限

可並行化的部分包括：校驗碼計算、版本掃描、份額完整性確認、已知 schema 的數值比較、候選特徵抽取、部分規約樹及批次索引。需要序列化的部分包括：同一 result_key 的最終決策轉移、租約檢查、重要衝突狀態寫入和對下一篇提交協議的唯一提案。

GPU 若參與可平行批次工作，必須明示它輸出的是候選證據／中間值；不能由 kernel 寫入跨權威域結果來繞過 CPU/Runtime 的安全仲裁。

11.5 局部收斂可能是失敗狀態

收斂不必定義為「得到一個答案」。對某一 epoch，若所有候選已處理完畢，而結果是 Conflict 或 InsufficientEvidence，則聚合過程可終結，但不可報告為「已找到正確答案」。正式追蹤要同時記錄 closed、locally_verified、selected 與 failed，避免研究數據被成功率統計污染。

12. 聚合狀態機、決策規則與不可跳過的關卡

12.1 候選資料的狀態機

Observed
  -> EnvelopeChecked
  -> Admitted
  -> PayloadChecked
  -> CandidateRegistered
  -> Compared
  -> {LocalSelected | Corroborated | Recovered | ConflictHold | Unresolved}
  -> {VerificationReady | VerificationFailed}
  -> {ProposalExported | Rejected | Expired | Cancelled}

其中 Observed 到 Admitted 的任何失敗都應保留可審核拒絕原因；CandidateRegistered 不代表 PayloadChecked 的比較器可信；LocalSelected 不代表 CommitAuthorized。

12.2 聚合域的狀態集合

該狀態集合是本地協議投影，並非整個 PWN 的生命週期。Sealed 只指本聚合輪次不再接收新的候選資格；若要重新開放或開始新輪次，必須使用新且明確的 aggregation_round 或 plan_version。

12.3 最小守衛表

12.4 ACK 不代表真值

至少分別回報以下狀態：

• TransportReceived：傳輸層成功接收。
• EnvelopeAccepted：封套通過初步檢查。
• CandidateRegistered：已登錄候選。
• LocallyVerified：滿足指定局部驗證。
• ProposalExported：向後續提交系統提出候選。
• Committed：僅由 Paper 04 的權威層回報。

將任何前三種 ACK 當成最終結果都會掩蓋失敗、錯誤或重送風險。

13. 接收、比較與聚合的最小參考演算法

13.1 限定目的

以下偽程式碼用於指定語義及模型測試，不是可投入生產的程式。atomic_* 表示需要工程實作證明的線性化語義；這裡不聲稱已由共享記憶體、CAS、GPU kernel 或任何 OS API 自動達成。

13.2 合法發送支路

function plan_and_reserve_branch(plan, candidate, target, event_epoch):
    require plan.version is current
    require candidate.result_key == plan.result_key
    require event_epoch == plan.event_epoch
    require branch_count(plan) < plan.branch_limit
    require attempt_count(plan) < plan.attempt_limit

    require current_phase_allows(plan.mode, candidate, target)
    require edge_is_admitted_and_current(candidate.source, target)
    require permission_allows_payload_and_target(candidate, target)
    require authority_generation_is_current(candidate.source)

    reservation = atomic_reserve_all(
        unique_send_credit_for_this_attempt,
        edge_message_capacity,
        edge_byte_capacity,
        global_byte_capacity,
        branch_compute_budget
    )
    if reservation.failed:
        return DeferredOrRejected(reservation.reason)

    ext = build_reconciliation_extension(plan, candidate, reservation)
    env = inherit_phase_diffusion_envelope(ext, reservation)
    record_attempt_issued(env.delivery_attempt_id, reservation)
    return enqueue_with_accounting(env)

對 R1 的第二次發送、R2 的額外候選及 R3 的每一有效份額，都須建立可區分並可追蹤的 reservation。若 reserve 後輸出前的故障需要返還額度，必須證明該 token 尚未產生可觀察的外部效果；Paper 02 不可回收額度基準中，預設不返還。

13.3 接收處理的分層拒絕

function receive_redundant_message(owner, envelope, extension):
    if not bounded_parse_and_schema_check(envelope, extension):
        return RejectAndAccount("MALFORMED")
    if not valid_epoch_topology_fence_and_capability(envelope):
        return RejectAndAccount("STALE_OR_UNAUTHORIZED")
    if extension.aggregation_owner_flow_id != owner.flow_id:
        return RouteOnlyIfAuthorizedOrReject("WRONG_OWNER")
    if not current_owner_generation(owner, extension):
        return RejectAndAccount("OWNER_FENCED")
    if not plan_version_and_result_key_match(extension):
        return RejectAndAccount("PLAN_OR_RESULT_MISMATCH")
    if not delivery_attempt_accounted(envelope):
        return RejectAndAccount("CREDIT_OR_ATTEMPT_INVALID")

    status = atomic_register_attempt_and_detect_duplicate(envelope)
    if status == "SAME_LOGICAL_MESSAGE_ALREADY_SEEN":
        record_attempt_duplicate(envelope.delivery_attempt_id)
        acknowledge_transport_with_accounting(envelope)
        return DuplicateDeliveryNoNewEvidence
    if status == "IDENTITY_COLLISION_WITH_DIFFERENT_PAYLOAD":
        quarantine(envelope)
        return RejectAndAccount("MESSAGE_IDENTITY_COLLISION")

    payload = bounded_materialize_and_validate_digest(envelope)
    if payload.failed:
        return RejectAndAccount("PAYLOAD_INVALID")

    candidate = validate_candidate_schema_snapshot_and_provenance(payload, extension)
    if candidate.failed:
        return RejectAndAccount(candidate.reason)

    register_candidate_without_commit(candidate)
    return schedule_reconciliation_if_phase_ready(candidate.result_key)

先做廉價且安全的基本資料檢查，不應因為性能最佳化而先執行來自不可信載荷的自訂比較器；也不能在昂貴校驗前讓未授權封包佔滿全域佇列。

13.4 主節點的模式分派

function reconcile_one_result(owner, result_key, plan):
    require owner_lease_and_fence_valid(owner, result_key)
    require round_is_open_or_sealed_consistently(plan)

    candidates = get_registered_valid_candidates(result_key, plan.version)
    switch plan.mode:
        case Single:
            outcome = validate_one_candidate(candidates, plan.evidence_policy)

        case Duplicate:
            outcome = select_first_eligible_valid_candidate(
                candidates, plan.quality_contract, plan.candidate_identity)

        case Corroborate:
            relations = compare_with_provenance(
                candidates, plan.comparator_policy, plan.source_diversity_policy)
            outcome = apply_predeclared_witness_policy(relations, plan.evidence_policy)

        case Coded:
            shards = validate_distinct_indexed_shards(candidates, plan.coding_parameters)
            outcome = decode_or_fail_with_scheme(shards, plan.coding_parameters)

    if outcome.satisfies_local_validation:
        store_local_outcome_idempotently(result_key, plan.version, outcome)
        return ExportTypedProposalOnly(outcome)

    return RecordPendingConflictOrFailure(outcome)

任何 ExportTypedProposalOnly 都只是向下一篇定義的權威提交層提供候選及證據。不能被設定為對外付款、覆蓋模型權重或寫入外部不可逆狀態的 shortcut。

13.5 原子性的真實落點

至少需找出四種線性化點：

1. 送達嘗試保留 credit、byte budget 與佇列容量；
2. 收件端以同一 namespace 登錄 message／attempt 與去重狀態；
3. 同一 result_key 的聚合結果決策轉移；
4. 聚合 owner 租約／世代 fencing 的撤銷與替換。

若整個實作跨多個記憶體地址而沒有適當原子協定，這些語義點可能是交易或可回復協議，不一定能用單個 CAS 完成；本篇不預設無鎖或等待自由（wait-free）。

14. 重播、保留期限、遷移與故障恢復

14.1 為什麼去重需要範圍

若只在易失 hash set 保存 seen(message_id)，聚合節點重啟後可能忘記曾接收消息，導致相同邏輯消息再被當成全新候選。若要跨故障重播仍安全，需要明確的：

• 去重 namespace 和 epoch;
• 必須保存的最長重送窗口;
• 日誌耐久性與 checkpoint 邊界;
• 副本恢復時的 seen-set 合併與排序;
• tombstone 退場與世代無效化規則。

不同強度故障模型需要不同保留策略。對只允許單進程內 V0 模擬的情境，可採記憶體去重；但結論不得外推到突然斷電、磁碟損毀或跨程序外部效果。

14.2 事件世代與聚合輪次

同一 PWN 在多個 epoch 持續存在；同一 epoch 也可能有多個聚合輪次。定義：

更換 plan_version 不可抹除前一輪對控制訊息、信用或外部權威提案的責任；舊輪次在途副本也不得自動取得新輪次的驗證資格。

14.3 PWN 遷移中的候選轉移

安全遷移的建議順序：

1. 停止舊聚合 owner 接收新權威決策；
2. 撤銷其有效寫入租約並增加 generation/fence；
3. 對候選集合、未清償義務及版本快照建立可驗證交接；
4. 新 owner 驗證交接內容及授權；
5. 只重用仍符合 schema／input snapshot／epoch 的舊候選證據；
6. 按新 fence 恢復局部聚合，舊 owner 延遲寫入全部拒絕。

如採共享記憶體直寫，還必須確認舊 writer 不會因 CPU 重排、快取可見性或延遲的 atomic 操作突破 fencing。租約數字本身不等於處理器自動的記憶體屏障。

14.4 ACK 遺失與不確定結果

發送者可能不知道接收端是否已處理消息。此時可重送到指定 at-least-once 通道，再由接收端冪等去重；不能假裝因收到 timeout 就代表此前送達必然沒有作用。若重送沒有有效 credits、queue capacity 或剩餘 deadline，系統應停在 Unknown/Failed，不得造出成功訊息。

14.5 垃圾回收不能早於安全保留界

被抑制的舊訊息可能在長時間後再抵達。只有當已知最大重送生命期、epoch fencing 或權威域持久保留策略足以否定其資格時，才能清理相應 tombstone。否則清理 seen-set 後重送可能重新成為有效候選。

15. 可信度、權限與安全故障模型

15.1 失敗假設的分層

本文建議至少分四層做逐步驗證：

1. F0： 單進程、可信工作流、可控制的延遲／亂序／重送；
2. F1： 可中斷執行、可取消、局部 crash/restart，但沒有惡意來源；
3. F2： 程序間或主機間傳輸，存在斷線、來源身分驗證和持久化需求；
4. F3： 拜占庭／對抗式來源，可能精心偽造合法形式的錯誤資料。

本篇條件性命題主要針對 F0–F1；將其延伸到 F2 或 F3，必須額外給出密碼學驗證、可信執行、耐久日誌與必要的容錯共識條件。

15.2 checksum、hash、MAC、signature 的不同承諾

• CRC／checksum 可以有效協助偵測某些隨機傳輸損壞，但不能認證發送者。
• 非金鑰密碼雜湊可提供內容指紋，但若雜湊和內容同由惡意來源控制，不能單憑此建立來源可信性。
• MAC 可在具適當金鑰管理的信任模型下驗證訊息完整性與共享密鑰身份。
• 數位簽章可在適用的公鑰信任體系下綁定訊息來源，但同樣不保證簽署者的計算一定正確。
• 形式證明／可驗證計算關心的是特定命題或計算關係，必須依賴明示的驗證器與 trusted base。

15.3 三種不同的故障相關性

路徑相關性： 兩路共同受同一個快取或匯流排瓶頸影響。
運算相關性： 不同候選使用同一資料、程式或模型偏誤。
權威相關性： 兩個來源都依賴相同且可能已損壞的授權／提交系統。

R1 延遲分析著重第一種，R2 正確性分析著重第二種；第三種可能同時影響安全與正確性。三者不得用「兩個核心」這一個數字替代。

15.4 AI 不是來源真值仲裁者

AI 可以提出：較適合的候選、延後備援、來源相異性猜測、更多檢查建議或預估負載；但 AI 的輸出不能直接修改硬性驗證條件、偽造 source_fencing_token、放寬最小證據集，或把自己生成的文本當作已驗證的形式證明。

16. 條件性安全命題與證明概要

本節明確區分「協議指定的形式性質」與「實際系統完成了正式模型檢查／性能驗證」；下列命題是在指定參考模型下的條件性主張。完整 TLA+ 或同等機械驗證仍為未來工作。

16.1 命題 A：同一邏輯訊息的重送不得自動增加候選數量

前提 A1： result_key、candidate_id、logical_message_id 由有版本的唯一性規則指派，且拒絕同一身分指向衝突 payload。
前提 A2： 對相同的 (event_epoch, logical_message_id, owner_generation) 存在原子的 dedup 登錄。
前提 A3： CandidateRegistered 只在首次合法登錄時增加。

則對同一 message 的任意次傳輸嘗試數 $n\geq1$：

證明概要： 首次成功登錄將身份鍵標記為 seen；依 A2，同鍵後續嘗試不得再成功走首次登錄分支；依 A3 候選計數只對首次登錄增加。這是去重機制的安全性，並不保證消息一定送達或第一次處理必然成功。

失效邊界： 若去重記錄遺失、身份碰撞、跨 owner generation 的重播未被 fencing 排除，或 payload 先觸發外部副作用才去重，結論不成立。

16.2 命題 B：無額外 witness 的雙路衝突不可自證真值

設一個任務輸出有多個可能值，而兩個可信度尚未排序且無外部 oracle 的候選 $c_a,c_b$ 回報不同結果。若系統的可觀測資訊在「A 正確、B 錯誤」及「A 錯誤、B 正確」兩種世界均可能出現，則僅憑這兩份候選值無法決定哪一世界為真。

證明概要： 兩種世界對接收端產生相同的可觀測輸入，但要求相反的選擇。任何只依此輸入的確定性選擇函數在至少一種世界會錯；隨機選擇亦無法無條件保證正確。此為資訊不足的區分性反例，不是對所有已知具驗證器問題的一般不可能定理。

結論： R2 的 Conflict 應是合法且必要的輸出狀態。

16.3 命題 C：R3 僅在所宣告編碼前提內保證唯一解碼

前提 C1： 編碼器／解碼器與版本參數 $\theta$ 相同。
前提 C2： 足量份額符合編碼方案的線性獨立性／索引要求。
前提 C3： 擦除／錯誤數量未超過該碼的可恢復條件。
前提 C4： 所用份額經指定完整性與來源政策驗證。

則解碼器對此故障模型內的載荷可返回唯一符合編碼規則的 $x$ ；超出條件時應報錯、請求更多份額或輸出 Unknown。

證明概要： 這是指定編碼構造的既有可解碼性結果之條件化使用，而非本篇新證明的通用編碼定理 [E4]。SMPDC 的研究工作是把這些前提明確反映到工作流聚合契約。

16.4 命題 D：局部已驗證不自動授權正式提交

前提 D1： Reconciliation 只有寫入 local outcome／輸出 proposal 的能力。
前提 D2： AuthoritativeCommit 由另一具型別能力守衛，不能由本篇 state machine 直接調用。

則合法的本篇轉移系統中，不存在僅經 LocallyVerified 便可直接轉移至 Committed 的路徑。

證明概要： 對本篇的合法事件字母表進行狀態歸納，沒有轉移可產生 AuthoritativeCommit 效果。這是語義層的非授權性，不是對惡意原生程式繞過作業系統保護、硬體漏洞或外部服務弱驗證的安全保證。

16.5 命題 E：有限支路不代表有界全部實際執行成本

即使每個 epoch 最多授權 $B$ 次資料傳播，仍可存在：單次巨量 payload、解碼消耗超大記憶體、某個候選進行無限運算，或未受限制的控制重送。故從 $S\leq B$ 不能推出總執行時間、所有位元流量或記憶體使用量均具有有限且固定上界。

如欲建立資源上界，必須同時限制每條消息的 bytes、候選計算預算、驗證器時間／空間、控制通道義務與 admission 速率。這是對 Paper 02 credit 上界的必要分層，不是對該定理的否定。

17. 常見反例與實際故障模式

17.1 同源雙路假獨立

A、B 不同 CPU 核心執行相同錯誤公式，得到相同結果。若 R2 把「兩核一致」當作兩票，便產生錯誤的證據膨脹。

17.2 訊息重送投票污染

單一候選連續送達十次，若 candidate_id 取 delivery_attempt_id，就能用重試產生十票；正確做法是以候選來源及邏輯結果鍵去重。

17.3 接收端先做副作用再去重

同一扣款請求傳兩次，接收端先執行扣款再更新 seen-set。第二次即使最後被辨認為副本，外部效果已經產生。這是 Paper 04 必須修復的提交邊界。

17.4 編碼份額被 byte-hash 誤刪

R3 的不同 shard_index 意外具有相同內容，若只依相同 payload hash 去重，可能令可恢復份額數不足。

17.5 兩份互相矛盾但先到者獲勝

在 R2 的 Conflict 情境，若套用 R1 的 first-valid 規則，會把候選抵達時間誤當成真值排序。

17.6 時鐘晚到與舊版本交錯

對快照 $v_1$ 的候選晚於 $v_2$ 到達，若以 wall-clock timestamp 判最新，而不檢查版本偏序及授權，可能把新狀態覆寫回舊狀態。

17.7 浮點重排造成假衝突

兩種合法平行 reduce 因非結合性產生末位差異。若 comparator 只允許 bytes 相同，R2 會錯判衝突；若 comparator 過度寬鬆，又可能錯放行真正數值錯誤。

17.8 高冗餘觸發 cache thrash

為了加速，同時發送四份大 payload；共享 LLC 被佔滿，兩條正常工作流同時變慢。策略必須允許降級 R0，而不能把冗餘數當成單調增益。

17.9 競速造成熱／功耗降頻

兩條副本同時執行於受同一功耗預算約束的核心群，導致基準運算降頻。此時 $\min(T_A,T_B)$ 的實際分布與單路測得的 $T_A$ 不相同。

17.10 R3 中兩份衝突且無校驗

若資料的兩個完整複本不同，又沒有可驗證的信任或編碼關係，接收端無法從兩份中辨認正確者；不能以「互相校正」的名稱跳過限制。

17.11 聚合者遷移產生雙重 owner

舊 owner 尚有在途聚合寫入，新 owner 同時開始接收。若租約／fence 未在原子點生效，本地候選可能出現分歧，即使每條消息都有效。

17.12 誤把 ACK 當成正確性

TransportReceived 回應後發送者釋放所有校驗材料，接收者後續才發現 payload schema 錯誤，且已不能重算。必須依契約保留足夠證據或明確回報不可恢復失敗。

17.13 跨 trust domain 的 hash 偽裝

惡意來源同時送出 payload 與其 hash，兩者吻合；若系統因此認定受信，將來源宣告誤當成身分證明。

17.14 控制通道因資料通道塞滿而失效

接收端 queue 滿而無法處理 Cancel 和 ACK，所有分支持續佔用額度，造成無法前進。必須保留獨立或優先控制機制及測量其容量。

17.15 Credit 被複製

兩條 R1 分支各拿相同 credit token，造成 S_t>B_0。這不是「協議容錯」，而是破壞 Paper 02 已界定的不變量。

17.16 Trace 事件重排

不同核心以不同緩衝區輸出日誌，事後將文字行合併的順序誤當因果順序，產生假的 first-valid 優勢。必須有因果父事件及局部序號。

17.17 重啟後 seen-set 遺失

聚合主節點 crash 後未保存去重紀錄；其餘分支繼續傳送，使同一 message_id 再次進入本地選擇流程。需依故障模型具備持久化或版本 fencing。

17.18 完全沒有有效結果卻宣稱收斂

整個 epoch 的傳輸與計算均已停止，但兩候選互相矛盾。這是「已終止但沒有可驗證答案」，不是成功合併。

17.19 GPU 批次聚合延遲反噬

小型候選每次都搬入 GPU 才檢查 digest，造成 kernel 啟動及 host/device 同步成本大於 CPU 即時處理。應以小尺寸 CPU baseline 做反面對照。

17.20 副本取消未能回收成本

一條分支先成功，取消另一條後者仍在進行 DMA 或 GPU kernel。若實驗忽略此費用，將高估 R1 效益。

18. 成本函數、速度優勢與品質等價

18.1 優化的是有效完成工作，不是產生最多封包

定義某 workload $w$ 的可比較完成時間為 $T_{end}(w,\pi)$，其中 $\pi$ 為冗餘與聚合策略。該時間必須在共同的起點及終點下測量，例如從工作意圖合法受理至滿足指定品質的局部結果可輸出，不能拿「單路完成全部檢查」與「多路只收到第一份原始 bytes」比較。

局部驗證階段可以記錄：

但其中有些部分可能重疊，此式若被當成精確時間分解，必須使用互斥時間區間或臨界路徑歸屬；不允許將重疊的 CPU/GPU 時間簡單相加而聲稱等於 wall-clock latency。

18.2 必報資源

• logical_results_completed / second（附品質門檻）；
• 每個邏輯結果的 physical_attempt_count、傳輸總 bytes、有效 payload bytes；
• p50/p95/p99 端到端局部驗證延遲及逾期率；
• CPU cycles、核心佔用、執行緒移轉、cache miss／LLC 命中或代理指標；
• 記憶體常駐量、queue occupancy、peak bytes、額度用盡比率；
• GPU launch、H2D/D2H 搬移、kernel 計算及同步等待（若有）；
• 整個工作負載完成時耗用的能量／平均功率（若可可靠測量）；
• false acceptance、false rejection、conflict detection、decoder failure、restart recovery；
• 由協議造成的額外 tracing／驗證費用。

CPU 使用率升高或流量加倍，不等於有效吞吐量改善。若不具備可靠功率測量工具，應明確標記該指標未量測，不以 TDP 或標示功率充數。

18.3 品質契約下的 Pareto 比較

設定策略的四個主要觀測軸：

需要比較 latency、資源成本、能耗及錯誤風險四者，並在相同工作負載與驗證契約下分析 Pareto frontier。可能有策略降低 p99 但增加能耗；可能增加誤差檢出率但讓延遲增加。這些不是矛盾，而是多目標權衡。

18.4 R1 性能增益的必要觀察

一份 R1 候選的兩路理想時間，若不計競爭，可寫作 $\min(T_A,T_B)$ ；真實情境中，加入第二份運算會使兩路時間依策略 $\pi$ 而改變：

T_unhidden 是未被其他計算遮蔽的額外等待與協定開銷。必須用同一套硬體、固定的壓力負載和相同驗證條件直接量測；不能從獨立測量的兩個單路延遲分布拼湊成 R1 的真實分布而不測資源競爭。

18.5 R2 的正確性權衡

對有帶標準答案或可驗證證明的 dataset，評估：

兩個分母必須有明確定義，且不能讓不同任務類別混在一起直接總結。若不能建立 ground truth，需誠實使用「候選一致率」「衝突率」等觀測指標，而不是把它們改稱為 accuracy。

18.6 R3 的可恢復率與成本

R3 對每種故障型別另行報告：

• erasures_detected、recovery_success、undetected_corruption；
• 有效份額數、不同索引數、解碼失敗原因；
• 編碼和解碼分別消耗的時間與 bytes；
• 與完整雙副本 R1 的儲存／傳輸費用比較；
• 在失效域相關條件下是否真的有恢復優勢。

18.7 不可把改善局部性能當成整體 AI 訓練加速

若某個 R1 運算子的尾延遲下降，而 AI 訓練整體瓶頸其實是 GPU 張量計算或 PCIe 搬移，則局部改善可能無法改善每秒訓練 token、每秒有效 gradient step 或實際收斂時間。這是效能歸因與 Amdahl 類限制，應由 Paper 10 完成整體實測。

19. AI 訓練、推論與其他負載的適用域

19.1 大型模型推論的稀疏路由

Mixture-of-Experts（MoE）中，工作流可能分別管理路由、專家激活、局部候選及結果驗證。R1 適合研究特定高尾延遲專家路徑的安全重試；R2 可以研究不同候選路由決策的異源證據；但不能把兩個 expert 輸出都當作「同一答案」直接丟給 first-valid，除非模型架構原本定義了等價性或可接受的近似契約。

19.2 Retrieval／Agent 的候選佐證

多個資訊來源或工具可以回答同一問題，R2 的血緣標示有助辨識同一文件的重複轉述，避免把多個索引片段誤算成獨立外部證據。這裡的佐證品質主要來自來源可靠性及可檢查性，而非 CPU 幾顆核心在運行。

19.3 梯度計算及訓練狀態

同一梯度分片的重送應按操作身分去重；不同樣本／不同 micro-batch 的梯度需要依模型訓練定義進行累積，不可因向量值相同就丟棄；不同 step 或參數快照的梯度不得自動合併成同一次更新。

若存在非同步 SGD、梯度延遲或 mixed precision，需另指定 optimizer step、parameter version、loss scaling 及精度。gradient_equal_bytes 絕不等於 same_training_contribution。對模型參數真正的權威更新由 Paper 04 的提交模型管理。

19.4 推測型解碼與候選驗證

若有一個較快但未達終局品質的預測分支，以及一個具既定驗證器的較慢分支，允許主工作流利用前者進行可撤銷的推測運算，待後者完成後採納或回滾。這個場景與 Paper 04 有關；Paper 03 只能安全輸出驗證證據與相容性結果，不替代模型特定的 speculative decoding acceptance rule。

19.5 多模態資料傳輸

較大的影像、聲音或感測流可能適合 R3 擦除編碼，尤其跨異質／分散儲存或具丟包風險時。單機 CPU 快取至記憶體的極低延遲短訊息，則可能完全不需要 R3。所有優勢取決於真實載荷、傳輸路徑及故障特性。

19.6 非 AI 的負面控制必要性

應同時測試簡單計數、排序、單純位元搬移、不可合併狀態更新、非交換性交易等非 AI 負載。若 SMPDC 只對少數高延遲或高錯誤風險工作有利，這就是其適用域；不能藉重新定義 AI 計算掩蓋其它負載上的成本。

20. V0：確定性模擬器與有限狀態驗證

20.1 為什麼先模擬

實體 CPU 的非決定性排程、時間測量干擾與 trace 成本，容易掩蓋語義錯誤。V0 應先驗證：重送不增加候選、兩候選衝突不能自證真值、R3 不會因錯誤 shard 身分而非法解碼，以及舊 owner 沒有新權威。

20.2 有限模型範圍

實驗者可用 TLA+、PlusCal、Alloy、Proptest／QuickCheck 或自製確定性事件模擬器；工具選擇不得被冒充為本篇已執行的驗證證據。

20.3 建議最小狀態變數

simulation_state:
  epochs: Map[EpochId, EpochState]
  active_flow_generations: Map[FlowId, Generation]
  owner_leases: Map[ResultKey, OwnerLease]
  credit_ledger: UniqueTokenOwnership
  queues: BoundedQueueSet
  messages: Map[MessageId, Message]
  attempts: Map[AttemptId, AttemptState]
  candidates: Map[CandidateId, CandidateEvidence]
  seen_keys: Set[DedupNamespaceKey]
  reconciliation_rounds: Map[ResultKey, RoundState]
  trace: CausallyLinkedEventLog

20.4 狀態探索必須包含的轉移

OpenEpoch、AdmitBranch、ReserveCredit、SendAttempt、Receive、DuplicateDelivery、RejectPayload、Compare、AddShard、Decode、ConflictHold、CancelBranch、LoseACK、RestartOwner、MigrateOwner、SealEpoch、QuiescenceDetect、ExportProposal。

20.5 V0 應檢查的核心性質

1. 同一 token 沒有兩名有效 owner。
2. 相同 message 在同一 dedup namespace 至多登錄一次新候選。
3. R1 同候選重送不增加 R2 獨立佐證數。
4. 異源佐證的「未知獨立性」不會被當成獨立。
5. 沒有比較器時，R2 不執行不合法比較。
6. 兩候選衝突且沒有 witness 時不能輸出「已確定正確」。
7. R3 無足夠有效、不同索引的份額時不得成功解碼。
8. 同一 shard index 的 bytes 衝突必須可觀測。
9. 只有有效 owner generation 可以修改受控聚合狀態。
10. 舊 epoch／plan／拓撲版本不能繞過接收守衛。
11. TransportReceived 不能授權 AuthoritativeCommit。
12. 取消、重試與故障後，所有在途責任仍可計數。
13. 未完成任何有效聚合時不會輸出成功。
14. 承載遷移不允許兩個同時有效的局部結果 writer。
15. 已封閉 epoch 不會由 R1 retry 產生新的外部 root。
16. 基礎限額同時約束 messages 和 bytes。

20.6 活性與安全分開判定

即使前述安全性質均成立，也可能有 NeedsWitness 永遠等待、控制通道阻塞、資源飢餓、候選計算不終止或無限上游新事件。這些是活性／進度問題，需要額外公平性、超時與可失敗終局假設，不可由安全不變量推導出「一定完成」。

21. V1：一般消費級 CPU 的性能與正確性對照

21.1 第一輪不購買昂貴 CPU 的理由

第一輪可以在現有一般桌機 CPU 上進行 R1/R2/R3 邏輯與傳輸測試；不必先購買新型 P/E 核或多 CCD 平台，也不需要讓 GPU 介入每一個消息。研究可以由軟體模型開始，再針對核心能力差異、快取域和 NUMA 進行擴展。

使用者現有桌機的已知配置為舊款 AMD CPU、RTX 3070、32GB RAM；沒有購買 MINISFORUM N5 Pro。文件不虛構 CPU 的確切型號、核心數或實測效能。測試前應以可重現的硬體探測建立平台資訊。

21.2 公平的比較組

B4–B6 的用途及品質契約與 B0 不同，不能把它們放入單一「平均速度排行」當作相同任務。必須在相同目的與品質約束的子實驗中分組比較。

21.3 主要工作負載矩陣

• tiny_msg：16–256 bytes，測協議 header、原子競爭與 queue 成本。
• medium_payload：4–64 KiB，測快取與傳輸成本。
• large_payload：1–16 MiB，測記憶體頻寬與 R3 編解碼。
• variable_latency：受控制的長尾服務延遲，測 R1 hedging。
• highly_correlated_delay：兩路共同受單一限速器或共享熱點影響。
• different_source_same_bug：兩個候選使用同一錯誤輸入，測 R2 假佐證。
• known_erasure：有限份額遺失，測 R3 recovery。
• unknown_corruption：無有效校驗的內容損壞，測拒絕與不確定狀態。
• non_idempotent_side_effect：必須拒絕重複應用的工作。
• stale_gradient：不同模型 step 的更新資料，測版本守衛。

21.4 必須固定的條件

1. 同一硬體、OS、BIOS、頻率策略及散熱條件。
2. 每組相同合法工作輸入、相同成功／失敗定義與驗證範圍。
3. CPU affinity／NUMA placement 的實際觀測值必須記錄；不能只報使用者設定的 desired CPU mask。
4. 若 GPU 被使用，輸入輸出 bytes、傳輸方式、queue 與 kernel 時間均需記錄。
5. Trace overhead 須以 instrumentation on/off 對照估計。
6. 對隨機負載使用固定 seed 的可重現序列；實驗順序隨機化以緩解熱與背景工作趨勢。
7. 報告完整負面場景，不只選取有利的 workload。

21.5 量測與統計

優先報各試驗重複的原始分布、p50/p95/p99、信賴區間或 bootstrap 區間及效應大小。預先選定至少一個關鍵成功指標，例如在相同錯誤放行率和容量限制下的 p99 降低、或同一尾延遲界限下的資源費用減少。若多路只在挑選最佳一次時較快，而整體分布改善不穩定，不能宣稱具可重現收益。

21.6 可直接推翻的判準

• R1 的多路延遲沒有可重現改善，或改善不抵額外資源成本。
• R2 只有相同來源重複輸出，未增加錯誤檢出能力。
• R3 的解碼／傳輸總成本在預定丟失率下全面高於 R1。
• 加入相位／credit 後的局部協議完全被傳統高效隊列 + explicit validation 等價或超越。
• 分支取消與 owner 遷移在故障注入中破壞授權和聚合不變量。
• 增加冗餘帶來額外的 queue 尾延遲與 cache thrash，淨效益為負。

任何一項結果均應如實報告，其研究價值不因否定 SMPDC 效能假說而下降。

22. 與成熟研究及相鄰 EveMissLab 理論的精確邊界

22.1 Hedged Requests／The Tail at Scale

Dean 與 Barroso（2013）討論大型系統的尾延遲及備援請求等技術 [E1]。因此，副本競速降低尾延遲並不是 SMPDC 首次提出的原理。本篇要驗證的是它被嵌入 CPU 每核持續工作流、具型別擴散與局部主節點聚合後，是否能在小尺度異質系統上取得新的淨效益。

22.2 Diffusing Computations／終止偵測

Dijkstra–Scholten（1980）已經建立對傳播式計算的終止偵測方案 [E2]。本篇不重新發明 quiescence。真正需要整合的是：多路冗餘消息及控制 ACK 必須歸入 Paper 02 的在途義務；即使某條冗餘支路被取消，也不能使 epoch 的責任帳本憑空消失。

22.3 冪等消息／Exactly-once 邊界

Apache Kafka 的設計文件對 at-most-once、at-least-once、冪等 producer、交易與對外系統處理邊界有成熟說明 [E3]。本篇不能宣稱新的全域 exactly-once；它只建立在限定狀態和正確持久化／仲裁前提下的候選登錄去重。真正的跨域外部效果仍交付 Paper 04。

22.4 Reed–Solomon／其他編碼方案

Reed 與 Solomon（1960）建立具明確數學規則的有限域多項式編碼 [E4]。SMPDC 的 R3 是對這類已有編碼方案的工作流協議化，不是新發明了容錯碼。可用不同碼族，但必須提供可核查的 scheme id、參數、錯誤模型與解碼器。

22.5 CRDT／受限的可合併資料

Shapiro 等人對 CRDT 的研究已說明某些複製資料型別如何在適當條件下收斂 [E5]。本篇只能在已滿足該資料型別數學性質時借用此機制；任意語義差異、權威決策、交易或浮點累加不能直接宣稱 CRDT 式去重收斂。

22.6 Raft 與受控權威

Ongaro 與 Ousterhout（2014）的 Raft 是管理複製日誌的共識演算法 [E6]。SMPDC 的多主 PWN 並不意味整台機器所有 CPU 核都在對同一筆權威結果跑共識；本篇只要求每個受控聚合域有明確的 owner/fencing 機制。若真的跨故障節點複製某個不可分裂的權威狀態，仍需可證明的共識或其他適當安全協議。

22.7 NCCL 與異質硬體的減縮運算

NVIDIA NCCL 提供成熟的 GPU 群體通訊、Reduce 和 AllReduce 等操作 [E7]。與本篇不同，NCCL 集體通信的數學縮減並不自行判定任意兩個候選的真偽或授權可提交性。SMPDC GPU 協作層可利用現有 primitives，而不應重新命名它們來主張新穎性。

22.8 與 GCCFT／GCCWT／GCM 的關係

• GCCFT： 提供更廣義的相位耦合、計算場與動態拓撲語義；本篇縮窄到近 CPU 訊息接收與聚合協議。
• GCCWT： 處理跨 CPU/GPU/Memory/Agent 與多世界的動態資源執行域；本篇沒有宣稱跨世界正式共識。
• GCM： 已有可驗證的資源分配與執行規劃研究；本篇可作為一種候選 executor／通信策略，不應推翻舊有已封存 baseline。
• PCMT： 既有相位本體、表示、演化及承載分類；本篇只使用 Paper 02 已選定的具體執行相位。
• ISQL-CMF： 可作未來資料表示與驗證候選，但本篇不要求所有 payload 改成任何單一原創格式。

總結而言，本篇若有新意，應落在既有方法的具型別整合、工作流執行尺度、相位信用約束及可測驗的綜合效能假說，而不是把整套已存在的技術宣稱是第一次被發現。

23. 對後續論文的嚴格交接

23.1 Paper 04：推測運算與權威提交

Paper 04 至少須接受本篇輸出：

LocalReconciliationOutcomeV0_1 {
    result_key, event_epoch, input_snapshot_id
    plan_id, plan_version, round_id
    owner_flow_id, owner_generation, owner_fencing_token
    mode, terminal_state
    selected_candidate_ids, valid_shard_ids
    comparison_evidence_ref, provenance_ref
    verification_policy_id, local_verification_status
    audit_trace_ref, outstanding_obligation_summary
}

Paper 04 應新增 AuthorizedToCommit、外部副作用隔離、正式提交唯一鍵、持久化去重、故障恢復及可撤銷推測結果的完整處理。不能把本篇 LocalVerified 默認轉為權威提交。

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

應考慮以下候選高階語義，而非直接假定是 CPU opcode：

REDUNDANCY_PLAN(result, mode, budget, evidence_policy)
BRANCH_ADMIT(candidate, target, phase_guard, credit)
MESSAGE_REGISTER(message_key, digest, epoch)
RECONCILE_COMPARE(result, comparator, evidence_refs)
RECONCILE_SELECT(result, quality_contract)
CODED_RECOVER(group, scheme, indexed_shards)
CONFLICT_HOLD(result, reason)
RECONCILE_SEAL(result, round_id)
RECONCILE_EXPORT(result, proof_or_evidence)

每個原語必須公開前置條件、記憶體／狀態副作用、失敗狀態及資源上界。MESSAGE_REGISTER 不應自動視為新 ISA 的原子硬體指令。

23.3 Paper 06：擴散程式語言與型別系統

語言應至少區分 Message、DeliveryAttempt、Candidate、VerifiedEvidence、Shard、LocalOutcome 及 CommitProposal 型別，並拒絕：

• 將 R1 的 DeliveryAttempt 隱含轉為 R2 的 IndependentWitness；
• 將 R3 的 Shard 隱含當作完整 payload；
• 將沒有比較器的候選執行語義合併；
• 將 LocalVerified 直接轉為 CommitAuthorized；
• 在不能支付 send credit 時照樣 DIFFUSE_SEND。

23.4 Paper 07–09：OS、GPU 與物理承載

OS/Runtime 至少要提供有限佇列、owner fencing、可觀察的 PWN 與硬體承載映射；GPU 只負責適合的批量／平行處理，並在 C_h2d + C_kernel + C_d2h + C_sync 的成本下和 CPU 實測對照。硬體論文可研究快取、NoC、SMT、P/E 核及 CCD，但不能由聚合協議自動推論電晶體級拓撲。

23.5 Paper 10–11：AI 適用域與可證偽結案

Paper 10 應在固定模型、固定資料集、固定 correctness／quality contract 下測實際訓練或推論；Paper 11 必須能接受 SMPDC 在某些或全部工作負載都沒有淨效益的結論，不得因當前理論命名或早期投資而維持不可反駁的成功敘事。

24. 結論

Paper 03 的核心貢獻是為 SMPDC 的「多路資訊先流動，主要節點再合併」構想建立具型別、具權限及具故障邊界的接收與聚合協議。 相位擴散決定何時與向誰傳送，冗餘模式決定多份資訊之間究竟具有什麼關係，聚合契約決定何時可選擇、比對、拒絕或恢復，而權威提交仍由後續獨立機制決定。

本篇建立四個不可混淆的結論：

1. R1 可能降低尾延遲，但不會因複製就創造獨立正確性證據。
2. R2 可以發現衝突並在條件下提高錯誤偵測能力，但兩個不一致的候選不能自行裁決真值。
3. R3 的可恢復性依賴明示的編碼定理及有效份額，不等於任意相似位元的資訊相加。
4. 局部聚合完成不代表外部權威提交；所有實體傳輸、驗證與恢復成本均必須入帳。

因此這個研究的下一個精確問題，不是「冗餘資訊能不能用」，而是：

當每個 CPU 主工作流維持自己的執行責任，並在有界相位擴散網路內交換具型別冗餘資料時，能否在既有硬體及嚴格正確性契約下，以可量測且可證偽的方式降低關鍵路徑等待，或增加有效驗證能力？

這仍是一項尚待實作及實驗的假說，不是已證明更快、更準的新硬體定理。

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

附錄 B｜可以逐步重演的三種微型案例

B.1 同一候選的兩路傳輸

設 PWN-A 產生候選 $c_7$，透過路徑 A→C 與 A→B→C 傳給 PWN-C；兩條路的送達 attempt 為 $u_1,u_2$，但共用同一邏輯結果與同一候選血緣。

logical result: K=demo/result/7
candidate: C=(K,branch-A,execution-1)
logical message: M=(C,message-7)
attempts: u1 (A->C), u2 (A->B->C)

receive u2 first:
    EnvelopeAccepted
    CandidateRegistered(C)
    PayloadChecked
    LocalSelected(C)

receive u1 later:
    EnvelopeAccepted
    DuplicateDeliveryNoNewEvidence
    acknowledge transport and settle obligations

final local candidate count = 1
final authoritative commit count = not determined here

此案例可以展示延遲競速與合法去重，但不證明兩路一定較快，也不證明候選計算正確。

B.2 兩份異源候選衝突

PWN-A 計算 $7$ ；PWN-B 計算 $9$，兩者皆與同一 result_key 綁定，皆通過 bytes 完整性與來源驗證，但沒有足夠的目標函式驗證器。

A: candidate value = 7
B: candidate value = 9
Comparator: numeric equality, same input snapshot
Relation: Conflict
Witness: absent
Outcome: NeedsWitness / ConflictHold

Forbidden: first arrival wins and claims correctness
Forbidden: "both valid hashes" implies either result is correct

若日後增加真正可信的證明或客觀計算規範，才可更新證據集。單純添加更多重送包不會解決這個分歧。

B.3 最小 XOR parity 的一份擦除恢復

使用兩個資料塊 $A,B$，以及校驗塊 $P=A\oplus B$：

A = 1010
B = 0110
P = 1100

if B is known-erased and A,P are intact:
    recovered B = A XOR P = 0110

此簡化 (3,2) 單重 parity 架構可處理已知的一份擦除。若 A、B、P 有不明來源的未知錯誤，單靠這三份資料不一定能確定是哪一份損壞；若 A 和 P 共同由有錯誤的編碼器產生，還會有共同故障風險。實際 R3 須保留 coding_scheme_id、份額索引與正確性限制。此案例僅作教學，不是新編碼定理，也不是實測結果。

附錄 C｜建議的 Trace Schema 與 V0 自動化檢查

C.1 Trace Schema

RFRTraceEventV0_1 {
    trace_id: TraceId
    local_sequence_number: MonotonicLocalNumber
    causal_parent_event_ids: BoundedEventReferences
    event_epoch: EpochId
    phase_kind: TypedPhaseKind
    event_kind: TypedEventName
    flow_id: FlowId
    flow_generation: Generation
    owner_flow_id: OptionalFlowId
    owner_generation: OptionalGeneration
    result_key: OptionalLogicalResultKey
    candidate_id: OptionalCandidateId
    message_id: OptionalMessageId
    attempt_id: OptionalAttemptId
    credit_token_id: OptionalCreditId
    plan_id: OptionalPlanId
    plan_version: OptionalVersion
    redundancy_mode: OptionalRedundancyMode
    payload_digest: OptionalVersionedDigest
    observed_status: Observed | Accepted | Rejected | Deferred | Failed
    reason_code: TypedReasonCode
    measured_bytes: OptionalNonNegativeInteger
    monotonic_clock_sample: OptionalClockReading
}

相同 trace file 的日誌行順序不能自行取代跨核心事件偏序。必須用因果父事件或明確排序關係重建。

C.2 V0 基準測試案例表

說明： 表內的「預期結果」是待實作的規範條件，不是 PASS 記錄。

附錄 D｜研究成熟度、正式原稿與版本治理

D.1 主張成熟度四級

• L0 — Concept: 理論提案與研究問題。
• L1 — Formal/Protocol: 有可檢查契約、前提、反例、轉移和預期性質。
• L2 — Simulator Verified: 已有實際可重現 V0 模型檢查或測試 log。
• L3 — Hardware Benchmarked: 已在受控實體 CPU/GPU 上完成可重現 A/B、完整資源／品質測量。

本篇標示 L0–L1；沒有宣稱 L2/L3。任何未來實驗若改變安全前提，需版本化改寫命題，不能把原稿保留原文卻換解釋。

D.2 正式 UTF-8 source 是 canonical artifact

1. 本文件的原始 .md bytes 是提交版正式文本；聊天畫面只是討論／渲染介面。
2. 只使用 $...$ 與 $$...$$ 作為數學原始碼 delimiters，不使用其他數學 delimiters，不將 LaTeX 轉為 Unicode 形式替代 canonical source。
3. 必須在 commit 前完成 UTF-8、delimiter 配對、Markdown 結構、章節、引用、版本與研究成熟度驗證。
4. 不採用會重新編碼反斜線的 unicode_escape 往返處理。
5. 程式碼區塊、偽程式碼及協議欄位不能被自動渲染器改寫後再回存為 canonical source。
6. 若修訂 Paper 00–02 的前置契約，應在 revision notes 中列出影響的 SMPDC 篇號與欄位版本。

參考文獻與原始研究來源

內部正式原稿與相關前史

• [I0] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 00｜群星多主節點持續擴散計算論：形式總綱》，v0.1。Canonical source：SMPDC_Paper00_Stellar_Multi_Primary_Persistent_Diffusive_Computing_v0.1_2026-10-16.md。
• [I1] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 01｜多主工作流節點論》，v0.1。Canonical source：SMPDC_Paper01_Multi_Primary_Workflow_Nodes_v0.1_2026-10-16.md。
• [I2] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 02｜相位耦合與有界持續擴散動力學》，v0.1。Canonical source：SMPDC_Paper02_Phase_Coupling_and_Bounded_Persistent_Diffusion_v0.1_2026-10-16.md。
• [I3] Neo.K（既有雲端研究）。《群星架構在計算機系統中的應用與改良計畫》。
• [I4] Neo.K（2026-07-25）。《相位計算機理論 v0.1》。無界智庫公開版：https://unboundedaxiom.org/p/lm-001850/。
• [I5] Neo.K × Aletheia（2026-09）。《GCCFT Paper 02｜計算相位與耦合激活》。
• [I6] Neo.K × Aletheia（2026-09）。《GCCFT Paper 06｜從 Scheduler 到 Coupled Computation Planner》。
• [I7] Neo.K × Aletheia（2026-09）。《GCCWT Paper 04｜計算場與資源激發》。無界智庫公開版：https://unboundedaxiom.org/p/lm-004846/。
• [I8] Neo.K（既有研究）。《GCM Phase C — AI-assisted Compute Orchestrator Engineering Blueprint v0.1》。

外部學術論文及工程規範（2026-10-16 核對）

• [E1] Dean, J., & Barroso, L. A. (2013). The Tail at Scale. Communications of the ACM, 56, 74–80. Google Research：https://research.google/pubs/the-tail-at-scale/。用途：R1 競速與尾延遲既有先例。
• [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；作者原稿：https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD687a.html。用途：Paper 02 傳播靜止義務。
• [E3] Apache Kafka. Design — Message Delivery Semantics / Exactly-Once. 官方設計說明：https://kafka.apache.org/35/design/design/；目前來源程式文件：https://github.com/apache/kafka/blob/trunk/docs/design/design.md。用途：冪等與跨外部系統 exactly-once 的必要界線。
• [E4] Reed, I. S., & Solomon, G. (1960). Polynomial Codes over Certain Finite Fields. Journal of the Society for Industrial and Applied Mathematics 8(2), 300–304. DOI：https://doi.org/10.1137/0108018。用途：R3 編碼冗餘數學先例。
• [E5] Shapiro, M., Preguiça, N., Baquero, C., & Zawirski, M. (2011). Conflict-Free Replicated Data Types. SSS 2011, 386–400. DOI：https://doi.org/10.1007/978-3-642-24550-3_29；作者著作表：https://perso.lip6.fr/Marc.Shapiro/pubs.html。用途：可合併資料型別與收斂條件。
• [E6] Ongaro, D., & Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm. USENIX ATC '14, 305–319. https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro。用途：權威複製及 fault model 的既有共識先例。
• [E7] NVIDIA. NVIDIA Collective Communications Library (NCCL) Documentation. https://docs.nvidia.com/deeplearning/nccl/user-guide/index.html；API 例示：https://github.com/NVIDIA/nccl/blob/master/docs/userguide/source/usage/collectives.rst。用途：CPU/GPU 或多 GPU 系統上的成熟批次縮減及通訊先例。

引文、原創性與證據聲明

本文使用過往成熟技術作為可比較的基礎，不將既有 Hedged Requests、冪等處理、CRDT、擦除碼、GPU reduce、分散式終止偵測或 Raft 共識聲稱為 SMPDC 的原創發現。Neo.K 本輪提出的主要研究構想是：讓多個 CPU 核心可承載持續主工作流，並在中觀計算尺度藉相位擴散、多路資訊協議及局部聚合組織特定異質計算任務；本篇協作工作是將其中的冗餘／聚合部分收束成可檢查的形式契約及實驗綱領。

本文件中的表格、偽程式碼、有限狀態檢查清單及結果示意均屬研究規格或教學案例。未聲稱已完成模擬器、TLA+、GPU kernel、CPU benchmark、演算法正確性機械驗證，亦未宣稱實測達成速度或準確率提升。 任何正式對外聲稱都需先有對應版本的可重現程式、原始結果與實驗環境。

SMPDC Paper 03 v0.1 — End of Canonical UTF-8 Research Manuscript