Sui 的技术架构

Sui 是一条高性能的 Layer 1 区块链，由 Mysten Labs 开发。它从底层重新设计了区块链的执行模型——以对象（Object）而非账户为核心，通过对象级别的并行执行与验证者网络对共享状态的一致性处理，实现高吞吐与可扩展性。本节从产品级视角介绍架构要点；共识与排序的具体算法以当前主网及官方文档为准，本书不展开算法名称与演进细节。

对象中心模型 vs 账户模型

以太坊的账户模型

在以太坊中，所有状态都存储在账户下。每个账户有一个余额和一个存储空间（Storage），智能合约的数据以键值对的形式存放在合约账户的 Storage 中。

以太坊账户模型:

账户 0xAlice
├── 余额: 10 ETH
└── Nonce: 5

合约账户 0xERC20
├── 余额: 0 ETH
├── 代码: ERC20 逻辑
└── Storage:
    ├── balances[Alice] = 1000
    ├── balances[Bob] = 500
    └── totalSupply = 1500

这个模型的问题在于：Alice 和 Bob 的代币余额都存储在同一个合约的 Storage 中。当 Alice 和 Bob 同时发起转账时，即使他们的交易完全无关，由于都需要修改同一个 Storage，这两笔交易也必须顺序执行。

Sui 的对象模型

Sui 采用了完全不同的方式——数据以对象的形式存在，每个对象有唯一的 ID 和明确的所有者：

Sui 对象模型:

对象 0x1a2b (Coin<SUI>)
├── 所有者: Alice
└── 余额: 10 SUI

对象 0x3c4d (Coin<USDC>)
├── 所有者: Alice
└── 余额: 1000 USDC

对象 0x5e6f (Coin<USDC>)
├── 所有者: Bob
└── 余额: 500 USDC

在这个模型中，Alice 的 USDC（对象 0x3c4d）和 Bob 的 USDC（对象 0x5e6f）是独立的对象。当 Alice 转账给 Carol 时，她操作的是对象 0x3c4d；Bob 转账给 Dave 时，操作的是对象 0x5e6f。这两笔交易涉及不同的对象，可以被完全并行地执行。

对象模型的优势

特性	账户模型（以太坊）	对象模型（Sui）
并行性	需要复杂的并行化策略	天然支持并行执行
资产表达	余额是合约存储中的数字	资产是独立的一等对象
所有权	由合约逻辑维护	由运行时原生保证
可组合性	通过合约调用组合	对象可以直接嵌套和组合
存储粒度	合约级别	对象级别

并行交易执行

Sui 的并行执行能力是其高性能的核心来源。传统区块链（如以太坊）按顺序逐一执行交易，而 Sui 可以同时处理大量不相关的交易。

依赖关系分析

Sui 在执行交易前，会分析每笔交易涉及的对象集合。如果两笔交易操作的对象集合没有交集，它们就可以并行执行：

交易 A: Alice 转 SUI 给 Bob    → 涉及对象: {0x1a2b}
交易 B: Carol 铸造 NFT          → 涉及对象: {新对象}
交易 C: Dave 转 USDC 给 Eve    → 涉及对象: {0x7g8h}
交易 D: Alice 转 USDC 给 Frank → 涉及对象: {0x3c4d}

依赖分析:
- A, B, C, D 涉及的对象完全不同
- 四笔交易可以完全并行执行！

对比以太坊:
- 所有交易都必须排队顺序执行
- 即使交易之间完全无关

水平可扩展性

由于交易可以并行执行，Sui 的吞吐量可以随着硬件资源的增加而线性提升。增加更多的 CPU 核心和验证者节点，就能处理更多的并发交易。这种水平可扩展性是传统区块链所不具备的。

验证者与全局排序（概要）

Sui 由一组验证者共同维护账本。凡是多方可能争用同一链上可变状态的情形，网络都需要在验证者之间形成一致的排序与提交结果——具体协议名称、模块划分与性能数字会随版本迭代，本书不展开算法课；对象级并行与「共享对象为何更敏感」见第九章 §9.4。

已拥有对象 vs 共享对象

Sui 中的对象根据所有权模型分为不同类型，这直接影响你可用的并行度与交互模式（而非背诵某种「路径」名称）。

已拥有对象（Owned Objects）

已拥有对象是归属于某个特定地址的对象。只有所有者才能在交易中使用它们。

module examples::owned_demo;

/// 只有所有者能使用的资产
public struct MyAsset has key, store {
    id: UID,
    value: u64,
}

/// 创建一个已拥有对象——转移给发送者
public fun create(value: u64, ctx: &mut TxContext) {
    let asset = MyAsset {
        id: object::new(ctx),
        value,
    };
    transfer::transfer(asset, ctx.sender());
}

/// 只有所有者能调用此函数修改值
public fun update_value(asset: &mut MyAsset, new_value: u64) {
    asset.value = new_value;
}

共享对象（Shared Objects）

共享对象可以被任何人在交易中访问。由于多个用户可能同时操作共享对象，涉及共享对象的交易必须经过完整的共识排序。

module examples::shared_demo;

/// 一个共享的计数器，任何人都可以递增
public struct Counter has key {
    id: UID,
    count: u64,
}

/// 创建共享对象
fun init(ctx: &mut TxContext) {
    let counter = Counter {
        id: object::new(ctx),
        count: 0,
    };
    transfer::share_object(counter);
}

/// 任何人都可以调用此函数
public fun increment(counter: &mut Counter) {
    counter.count = counter.count + 1;
}

/// 读取计数值
public fun value(counter: &Counter): u64 {
    counter.count
}

设计选择的影响

理解已拥有对象和共享对象的区别，对于 Sui 开发者来说至关重要。它直接影响了你的合约设计：

module examples::design_choice;

/// 方案 A：共享池（多方写同一状态，需全局协调）
public struct SharedPool has key {
    id: UID,
    total_liquidity: u64,
}

/// 方案 B：个人金库（仅所有者操作，无多方争用同一可变共享状态）
public struct PersonalVault has key {
    id: UID,
    balance: u64,
}

/// 在设计合约时，需要权衡：
/// - 共享对象：适合 DEX、借贷池等必须多方协作的场景
/// - 已拥有对象：适合钱包资产、NFT 等单方主控场景

Sui 的独特特性

终局与体验（定性对比）

不同链的「确认快慢」与共识模型、区块时间有关；Sui 以对象并行与验证者网络为特点，具体数字随版本与负载变化，以官方文档与实测为准。传统对比（数量级仅作直觉）：

区块链	典型确认数量级（示意）
比特币	约数十分钟级（多确认）
以太坊	约数分钟级（视确认习惯）
Solana	约秒级
Sui	以对象类型与交易内容而异，见官方说明

水平可扩展性

传统区块链的吞吐量受限于单条链的处理能力。Sui 通过对象级别的并行执行，实现了真正的水平可扩展性——增加更多的计算资源，就能获得更高的吞吐量，而不需要分片或二层扩展方案。

对象级粒度

Sui 的状态管理精确到单个对象级别，这带来了以下好处：

精确的 Gas 计量：按实际使用的对象存储和计算量收费
存储费退还：当对象被删除时，用户可以拿回预付的存储费
细粒度权限控制：每个对象可以有不同的所有权和访问模式

可编程交易块（PTB）

可编程交易块允许在单笔交易中组合多个操作，实现复杂的原子操作：

PTB 示例：单笔交易完成三个步骤

Transaction {
    // 步骤 1：从 DEX 购买代币
    let coin = dex::swap(sui_coin, usdc_type);

    // 步骤 2：用代币添加流动性
    let lp = pool::add_liquidity(coin);

    // 步骤 3：将 LP 代币质押
    staking::stake(lp);
}

PTB 的优势：

原子性：要么全部成功，要么全部回滚
可组合性：一个步骤的输出可以直接作为下一个步骤的输入
Gas 效率：多个操作合并在一笔交易中，节省 Gas
无需合约串联：不需要编写专门的聚合合约

Sui 架构全景图

┌─────────────────────────────────────────────────────┐
│                    客户端层                           │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐         │
│   │ 钱包应用  │  │  DApp    │  │ SDK/CLI  │         │
│   └────┬─────┘  └────┬─────┘  └────┬─────┘         │
│        └──────────────┼──────────────┘               │
└───────────────────────┼─────────────────────────────┘
                        │ JSON-RPC / GraphQL
┌───────────────────────┼─────────────────────────────┐
│                    全节点层                           │
│              ┌────────▼────────┐                     │
│              │    Full Node    │                     │
│              │  ┌────────────┐ │                     │
│              │  │ 交易路由    │ │                     │
│              │  │ 状态查询    │ │                     │
│              │  │ 事件索引    │ │                     │
│              │  └────────────┘ │                     │
│              └────────┬────────┘                     │
└───────────────────────┼─────────────────────────────┘
                        │
┌───────────────────────┼─────────────────────────────┐
│                   验证者层                            │
│     ┌─────────────────▼─────────────────────┐       │
│     │            交易处理与一致性层              │       │
│     │  （对象调度、共享状态排序等，实现随版本演进）  │       │
│     └───────────────────────────────────────┘       │
│     ┌───────────────────────────────────────┐       │
│     │           Move 虚拟机 (MoveVM)          │       │
│     └───────────────────────────────────────┘       │
│     ┌───────────────────────────────────────┐       │
│     │          对象存储 (Object Store)        │       │
│     └───────────────────────────────────────┘       │
└─────────────────────────────────────────────────────┘

小结

本节从架构视角介绍了 Sui：对象模型带来并行与清晰的资产边界；验证者网络对共享状态提供一致性；具体共识与执行管线以官方文档为准。在下一节中，我们将纵览 Sui 的生态系统，了解在这个基础设施之上构建的各类应用和协议。

Keyboard shortcuts

Move on Sui: 从零到精通