Sui 为什么只有部分交易要过共识？地址所有权与共享对象的快慢分界

多数公链对每一笔交易走同一套共识流程，Sui 是一个明显的例外：它的文档明确写着，地址独占对象的交易可以完全跳过共识，只有涉及共享状态的交易才交给共识层排序。快慢的分界线画在哪里、为什么敢这样画、代价是什么，是理解 Sui 执行模型的关键，也是这篇文章要讲清楚的三件事。

一切状态都是对象

Sui 官方文档把对象定义为链上存储的基本单元：每个资源、资产和数据都是一个带全局唯一 ID 的对象，此外还带有所有者、版本号和元数据。这和以太坊把状态组织成账户下的键值存储不同——Sui 的状态是一张以对象为节点的关系网，交易声明自己要用哪些对象输入，网络据此判断冲突。

所有权字段决定对象的命运。地址独占意味着只有一个地址能使它，例如你钱包里的 NFT；共享对象则是任何地址都可以引用的公共可变对象，市场、流动性池、对局棋盘都属于这一类；官方文档还列出不可变对象与由共识排序但单一地址拥有的 party 对象等形态。所有权类型不是标签，而是执行路径的开关。

两条执行路径：快速路径与共识排序

文档给出的分工很清楚。地址独占对象走快速路径：验证者通过对本纪元有效地址集的加权法定投票签名即可确认交易，不需要全体对全局顺序达成一致，延迟最低。共享对象走共识路径：因为任何人都可能同时对它发起交易，必须由共识给这些交易排出一个所有人认可的先后顺序，再交给执行层，所以延迟与gas成本更高。

关键在版本推进方式的区别。地址独占对象的交易要显式引用某个具体版本，用旧版本会被拒，这天然防止两笔交易悄悄覆盖彼此；共享对象则不需要指定访问版本，共识在调度时决定下一个版本，前一笔的输出版本就是后一笔的输入版本。官方文档描述这套方案使用了 Lamport 时间戳，保证对象每被更新一次版本严格增大，即使字段被删除后重建，新的版本也严格大于旧版本。

并行不是魔法：争用怎么让热度对象变慢

Sui 常被称为并行执行公链，但并行的前提在文档里写得比宣传严谨：互不相关的交易可以并行处理，触碰不同共享对象的交易也能在多个核心上并行执行；而如果同一批处理里有大量交易写同一个共享对象，它们就会被串行排序而不是并行执行，该对象的吞吐随之下降。官方文档给出的优化建议也很务实——把一个热门共享对象按维度拆成多个（例如按价格区间分片订单簿），或者尽量把能私有化的状态放回地址独占对象。

换句话说，Sui 的速度不是全链统一的标签，而是逐交易的属性：转账一个只属于你的 NFT，和在一池人同时抢的共享订单簿里挂单，走的是两条性能截然不同的路。比较公链性能时把这两种交易混在一个平均数里，会得出误导性的结论。

普通用户与开发者分别看什么

用户层面，最直接的体感是同类操作有时快有时慢：涉及共享池子的交易要等共识排序，比转一个自己的对象更慢，这在高峰期尤其明显。开发者层面，文档的安全提示值得逐条对照：任何人都能提交引用共享对象的交易，运行时不做访问控制，所有特权操作必须在 Move 代码里自行校验授权；共识提交若超过执行成本阈值，交易甚至可能在共识之后被取消以保护系统。

常见误区与边界

三个容易出错的说法。其一，跳过共识不等于跳过验证：快速路径仍然需要验证者法定签名，跳过的只是全局排序这一步。其二，共享对象延迟高不等于不安全：它的顺序来自 BFT 共识，恰恰是多方可信协作的来源。其三，官方文档还提醒，对同一地址独占对象并发提交冲突交易可能被版本保留机制拒绝，应用应当合并交易块或借助 SDK 的并发管理，性能优势是用正确用法换来的，不是白拿的。

风险提示

本文仅解释公链执行模型与数据结构的机制差异，不构成任何投资建议。文中表述以 Sui 官方文档为准，协议升级可能调整路径划分与参数，引用前应核对最新文档。