单线程 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 的数据库直觉之上，也建立在对工作负载热点的诚实评估之上。