單執行緒 EVM 把確定性買得相對便宜：順序固定，重放簡單。一旦目標變成「在可驗證正確性不變的前提下提高執行寬度」，設計者就會撞上同一個岔路口：誰來判斷兩筆交易能不能同時跑——開發者事先宣告，還是執行時再發現？
這個問題決定了平台的程式設計模型、生態遷移成本，以及衝突熱點下的真實吞吐量。產業裡已經走出三條相對清晰的路徑：以 Solana Sealevel 為代表的確定性平行、以 Aptos Block-STM 及多條平行 EVM 為代表的樂觀並行控制（OCC），以及以 Sui 為代表的物件模型。三者都在談「平行」，但假設與代價差得很遠。
確定性平行：依賴寫在交易上
確定性路線要求交易在提交時攜帶完整的讀寫帳戶（或資源）清單，並標明唯讀或可寫。執行環境在執行前即可建圖：無寫入衝突則可平行；同讀可共享；同寫則串列。排程器不必在執行中猜測依賴，衝突關係在入隊時已大致可知。Solana 的 Sealevel 是這條路上最常被引用的工程樣本，並與其帳戶模型、執行環境的儲存設計綁在一起。
優點是可預測：接受交易後，執行路徑較少出現「跑到一半才發現衝突、再整筆作廢」的浪費。代價則落在開發者與工具鏈上。簡單轉帳的宣告成本低；分支複雜、存取路徑取決於執行時條件的程式，要嘛過度宣告（縮小平行度），要嘛漏宣告（交易失敗）。對經典 EVM 而言，儲存槽的存取往往由合約內部條件決定，位元組碼本身並不攜帶 Sealevel 式的帳戶清單。若強行要求預先宣告，位元組碼層級的相容性會立刻破裂——合約與稽核的假設都得重寫。
預先宣告也不能消滅應用層的熱點。DEX 池、借貸清算、熱門鑄造仍會把寫集集中到少數帳戶，衝突鏈變長，平行度被狀態設計而不是排程器卡住。確定性路線解決的是「排程階段知不知道依賴」，不是「狀態有沒有被拆散」。工作負載如何製造熱點，需要另文討論；這裡先記下：引擎再聰明，也救不了所有人都搶同一個儲存槽的合約結構。
樂觀並行控制：預設能平行，錯了再收斂
OCC 路線翻轉了假設：多數交易互不衝突，先平行跑，再驗證讀集是否仍然有效；衝突則中止並按規範順序重新執行，直到結果與某個串列順序等價。軟體事務記憶體（STM）與資料庫 OCC 為這條路提供了理論骨架；Aptos 的 Block-STM 是區塊鏈語境裡被廣泛引用的實作之一——按預設順序樂觀執行，協作式排程在執行過程中發現依賴並安排重跑，力求只回滾真正受影響的交易。
公開資料中出現的高 TPS 數字，通常來自特定基準、硬體與交易類型（例如非平凡的 Move 交易在實驗室或測試環境下的結果），不能直接等同於主網混合負載下的使用者體驗。重要的是機制形狀：正確性依賴「最終與給定順序等價」，效能則依賴「衝突率足夠低或重新執行足夠便宜」。
多條追求 EVM 相容的鏈選擇 OCC，理由高度一致：接收交易時無法靜態得知全部的儲存存取，只有執行才能揭曉。在執行環境中記錄實際讀寫集，衝突的子集再串列收斂，其餘交易則保持平行帶來的收益。Monad、Sei 等專案在工程細節上不同——狀態快照、提交順序、共識與執行是否解耦——但共享「不要求開發者預先宣告」這一相容性前提。
OCC 的核心風險也公開：衝突率飆升時，重新執行會吃掉平行紅利，極端情況下吞吐量可能接近甚至劣於樸素的串列加鎖策略。因此選擇性回滾、執行中偵測、批次劃分與讀寫集粒度，決定了樂觀假設失效時的尾端成本。下一篇會從資料庫視角把 OCC 的讀—驗證—寫三階段講清楚。
物件模型：換資料模型來換平行邊界
第三條路不是「在帳戶模型上打補丁」，而是改動帳本結構。Sui 把資產建模為帶唯一 ID 的物件，並區分歸屬物件與共享物件。歸屬物件的寫者唯一，相關交易可走低延遲路徑，弱化全域排序的需求；共享物件允許多方觸達，必須經共識排序協調寫者。平行度問題被改寫成所有權問題：天生為單一所有者的流轉可大規模平行，真正多方共享的狀態才付全域排序的帳。
這套模型對 NFT、點對點資產轉移友善，但對 AMM 池、全域拍賣等共享物件密集的應用，仍會回到熱點競爭——只是競爭發生在物件粒度，而不是帳戶儲存槽粒度。代價是程式設計範式與語言棧的遷移：Move 與物件所有權的心智模型，和 Solidity 帳戶模型不同。現有的以太坊合約、Foundry/Hardhat 工作流程無法「原樣搬遷」，生態要為平行重新付出學習與稽核成本。
物件模型證明了：執行平行不必然只有「宣告」或「樂觀」兩種排程哲學，還可以從狀態拓撲下手。它也提醒 EVM 相容路線：堅持帳戶與全域狀態，就意味著放棄物件模型換來的一部分結構性平行，必須在執行環境的排程上把功課做滿。
三條路線如何對照
| 維度 | 確定性（Sealevel 類） | 樂觀 OCC（Block-STM 類） | 物件模型（Sui 類） |
|---|---|---|---|
| 依賴何時可知 | 提交前宣告 | 執行中/後發現 | 由物件所有權推導 |
| 開發者負擔 | 高（存取清單） | 低（保持原合約寫法） | 高（新模型/語言） |
| 與經典 EVM 相容 | 難（語意衝突） | 相對可行 | 需遷移 |
| 主要失敗模式 | 過度宣告/漏宣告；熱點仍串列 | 高衝突重新執行風暴 | 共享物件熱點；生態遷移 |
規律很清楚：若產品硬性約束是「位元組碼層級相容現有以太坊合約與工具」，確定性預先宣告與物件模型都會強迫開發者改寫法或換棧，現實中的選項往往收斂到 OCC。這不是宣稱 OCC 在所有負載下理論最優——確定性與物件路線在各自生態裡都跑出過強勁吞吐——而是承認相容性約束會壓縮設計空間。
對 Bitroot 這類定位為樂觀平行 EVM 的 L1 而言，選擇 OCC 是約束下的收斂，而不是口號。真正的工程問題變成：如何定義讀寫集、如何盡早發現衝突、如何在熱點負載下控制重新執行的範圍。那些問題建立在 OCC 的資料庫直覺之上，也建立在對工作負載熱點的誠實評估之上。