Sui 的技术路线有一个核心主张：大多数区块链用错了数据模型。
比特币、以太坊以及绝大多数公链用的是账户模型——状态是一组账户，每个账户有余额、nonce、代码。交易修改账户状态，一笔接一笔顺序执行。
Sui 用的是对象模型（Object Model）——状态是一组独立的对象，每个对象有唯一 ID 和所有者。交易消费输入对象、产生输出对象。这个转变听起来只是数据结构不同，但它带来了一整套不同的执行和共识机制。
账户模型为什么限制并行
要理解 Sui 的动机，先要理解账户模型的瓶颈。
账户模型下，一笔交易要执行，需要声明它读写哪些账户。但账户之间会互相依赖——如果 A 给 B 转账和 B 给 C 转账同时发生，执行顺序会影响结果。为了安全，节点必须顺序执行涉及同一账户的交易。
这导致了全局的顺序执行。即使用户交易的对象毫无关系（A 在 swap，B 在铸造 NFT），只要它们可能触及相同的状态，就必须排队。
各种并行执行方案（比如以太坊生态的 Block-STM）本质上是在事后检测冲突——先乐观并行，发现冲突再回滚重跑。这能提升吞吐，但冲突检测本身有开销。
Sui 的做法是从数据结构上让冲突变得可判定。
对象模型与所有权
Sui 里的对象有几类所有权状态：
单一所有者对象（Owned Object）。有一个明确的所有者地址。比如你拥有一个 NFT，它就是你的 owned object。
共享对象（Shared Object）。没有单一所有者，多个用户可以访问。比如一个 AMM 的流动性池。
不可变对象（Immutable Object）。创建后不能修改。
关键洞察是：如果一笔交易只涉及owned object（且都是同一个所有者），它就不需要经过共识。
因为只有你能改自己的对象，不存在和其他人冲突的可能。这类交易可以走快速路径（Fast Path）——直接执行，不需要全链共识排序。理论上这是零延迟的。
只有涉及共享对象的交易才需要走共识协议排序。
这个设计的收益很直接：
- 大量简单交易（转账、NFT 铸造与转让、游戏内资产操作）可以并行且免共识
- 只有 DeFi 交互这类涉及共享状态的交易需要排队
- 整体吞吐量因此可以显著高于纯账户模型
并行执行的真实收益与边界
理论上很美好，实践中的边界在哪？
收益最大的场景：高频、大量、彼此独立的简单操作。游戏、社交、NFT 批量操作是典型。这类场景下账户模型会成为瓶颈，而对象模型天然适配。
收益有限的场景：DeFi。因为 DeFi 的核心操作几乎都涉及共享对象——流动性池、借贷市场的全局状态、预言机价格。这些交易必须走共识路径，并行收益有限。
需要注意的一点：Sui 的并行不是"自动免费"的。开发者需要正确地声明交易的输入对象。如果声明得不精确（比如把一个其实不必共享的对象设为共享），交易就会被强制走共识路径，失去并行优势。这意味着性能不仅取决于协议，也取决于应用开发者的实现质量。
Move 语言的作用
Sui 用 Move 语言（从 Diem/Libra 项目演化而来），这不是偶然。
Move 的核心设计是资源（Resource）类型——资源是一种不能被复制、不能被丢弃、只能被移动的类型。这天然适合表示"资产"。
在以太坊上，一个 NFT 实际上是一条记录在合约 mapping 里的数据（「mapping(uint256 => address)」）。"所有权"是靠合约代码维护的，如果合约有 bug，"所有权"就可能被绕过。
在 Move 里，资产是语言层面的一等公民。一个 Token 对象就是一个 resource，它只能被移动，不能被复制或凭空创建。这让一些经典漏洞（双重支付、重复铸造）在语言层面就不可能发生。
这个安全优势是 Move 系公链（Sui、Aptos）的核心卖点之一。代价是生态迁移成本——Solidity 生态的开发者需要学习新语言，工具链也不如以太坊成熟。
Sui 牺牲了什么
第一，复杂度转移给了开发者。 对象模型让开发者需要仔细设计对象的所有权结构。设计得好，性能优越；设计得差，可能比账户模型还慢。这是一套需要理解成本的模型。
第二，可组合性受所有权约束。 在以太坊上，任何合约可以调用任何合约。在 Sui 上，涉及共享对象的调用需要走共识，某些复杂的跨合约组合会受限或成本更高。
第三，生态迁移的冷启动。 一条新公链要建立生态需要时间。Solidity 的开发者基数、审计资源、工具链都是 Sui 需要追赶的。语言更安全不等于生态更繁荣。
第四，共识机制本身的权衡。 Sui 的共识协议（早期是 Narwhal/Bullshark，后演进）需要在低延迟和高吞吐间取舍。免共识路径虽快，但涉及共享对象的交易仍受共识性能限制。
怎么客观评估 Sui 这类新公链
看性能宣称时，需要问几个问题：
这个 TPS 是在什么条件下测的？ 如果是"大量独立转账"，那么对象模型的优势会最大化，但这个数字不反映 DeFi 场景的实际能力。
真实应用的使用量是多少？ 链上交易量里有多少是激励驱动的刷量，有多少是真实需求？这个比例比总量更能说明生态的健康度。
开发者生态的活跃度。 有多少持续迭代的项目、有多少经过审计的合约。这个比"有多少项目上线"更能说明长期潜力。
共享对象路径的性能。 这才是 DeFi 的真实瓶颈。如果这条路径的性能瓶颈明显，那么"高吞吐"的宣传就需要打折。
去中心化程度。 验证者的数量、分布、以及质押的中心化程度。新公链在发展初期通常在这一点上弱于成熟网络。
这个方向的意义
Sui 代表的思路是：与其在账户模型上做优化，不如换一个更适合并行的数据模型。这个思路在技术上是成立的，也的确解决了一类具体的性能瓶颈。
但它也揭示了一个更普遍的现象：区块链的性能优化往往是"把成本从 A 挪到 B"。对象模型把并行成本从协议层挪到了开发者层（需要正确设计对象所有权）。这不是免费的午餐，只是把成本放到了不同位置。
对用户来说，判断这类公链是否值得使用，最终要看你需要什么：如果你做的是高频独立操作（游戏、社交、支付），对象模型的收益是实在的；如果你做的是复杂 DeFi 组合，账户模型的成熟生态可能更实用。
技术路线的优劣不是抽象的，而是相对于具体场景的。 这一点适用于评估所有公链。
常见问题
Sui 的对象模型和以太坊的账户模型有什么区别？
以太坊用账户模型，状态是账户集合，交易顺序执行；Sui 用对象模型，状态是独立对象，只涉及同一所有者的 owned object 的交易可免共识并行执行，涉及共享对象的才需要走共识。
Sui 的高 TPS 在 DeFi 场景也能实现吗？
有限。DeFi 的核心操作大多涉及共享对象（流动性池、借贷市场状态），必须走共识路径，并行收益有限。Sui 的并行优势主要体现在高频独立的简单操作场景。
为什么 Sui 用 Move 语言？
Move 把资产作为语言层面的 resource 类型，不能被复制或凭空创建，这让双重支付、重复铸造等漏洞在语言层面不可能发生，安全性优于靠合约代码维护所有权的 Solidity。
对象模型有什么代价？
复杂度转移给了开发者，需要仔细设计对象所有权，设计不当可能比账户模型更慢；可组合性受所有权约束；生态迁移成本高；涉及共享对象的路径仍受共识性能限制。