确定性边缘：Solana Sealevel 与 Sui 对象运行时中的交易生命周期

什么是区块链交易的生命周期？

区块链处理交易，而交易会影响状态（即区块链上账户的更新后视图）。理解交易生命周期，或许是认识区块链设计理念最直观的方式。它能帮助技术利益相关方了解区块链如何针对吞吐量与安全性进行优化、提供怎样的确定性保证、需要多少工程成本，以及在真实环境中可能出现哪些问题。

接下来，我们将研究交易从提交到最终确定所经历的各个阶段，以及这一流程如何影响这些链中不同层级的执行。

Solana 交易生命周期

Solana 区块链采用独特设计，以权益证明（PoS）作为其共识机制，并以历史证明（PoH）作为计时机制，从而高效地对交易排序。

Solana 的设计模型以账户为中心，换句话说，“Solana 上的一切都是账户”。

账户用于存储数据，包括状态和可执行二进制文件（即程序代码）。交易包含修改账户状态的指令。网络中参与共识并负责处理交易的节点称为验证者。处理交易以修改账户的过程称为流水线处理，而交易在生命周期中所处的不同节点称为阶段。

一笔 Solana 交易

在 Solana 上，交易是由 Message 账户密钥中的第一个密钥签署的序列化消息签名集合。

交易中的消息是一种包含消息头、账户密钥、近期区块哈希和指令的数据结构。消息头包含 MessageHeader，用于描述 Message 账户密钥的组织方式。

每条指令都会明确规定其可访问的账户以及每个账户所需的权限。这些权限指明账户是只读还是可读写，以及账户是否必须签署包含该指令的交易。

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

每条指令都包含其可能访问的所有账户列表，以及各账户所需的权限。

一个 Message 包含一个共享的扁平列表，其中列出了交易内所有指令需要的全部账户。该扁平列表在构建 Message 时创建，指令则会转换为一组 CompiledInstructions。这些 CompiledInstructions 随后通过索引引用共享账户列表中所需的账户。

共享账户列表按照账户所需权限排序：

• 可写且为签名者的账户。
• 只读且为签名者的账户。
• 可写但不是签名者的账户。
• 只读且不是签名者的账户。

基于这一排序，MessageHeader 的字段描述交易中的哪些账户需要哪些权限。

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

当多笔交易访问同一批只读账户时，运行时可以在同一个 PoH 条目中并行处理它们。访问相同可读写账户的交易则按顺序处理。

交易通过 Gulf Stream，即 Solana 的交易转发协议提交给客户端，随后由验证者中的两个多阶段流水线流程处理，分别是交易处理单元（TPU）和交易验证单元（TVU）。

这些流程与运行时协同工作，确保修改不同账户状态的交易并行处理，而修改同一账户状态的交易按顺序处理。

当验证者处于领导者模式（即生成区块）时，TPU 会运行；当验证者处于验证模式（即验证区块）时，TVU 会运行。两种情况下的流水线硬件都类似，包括网络输入、磁盘写入和网络输出等，但使用这些硬件的方式不同。简而言之，TPU 用于创建账本条目，而 TVU 用于验证条目。

从宏观角度看，交易通过客户端提交，经由 QUIC 和 Gulf Stream 发送至领导者的 TPU。交易通过验证检查后，由银行阶段调度执行。状态更新会写回银行的内存状态。验证者通过 gossip 对区块投票，而区块则通过 Tower BFT 达到最终确定。Tower BFT 是一种采用权益加权锁定机制的 PBFT 变体。

Gulf Stream

在大多数区块链中，用户提交的交易会在内存池（mempool，字面意思是“内存池”）中“排队”，等待网络处理。如果网络未处于最佳状态或不满足执行条件，已签名交易可能长时间甚至无限期停留在内存池中等待执行，最终永远无法被纳入任何区块。

Solana 不需要全局内存池，而是依靠受权益加权算法影响的确定性领导者调度，即权益加权服务质量（SWQoS），优先处理通过质押验证者路由的交易消息。

由于所有活跃节点都能提前得知领导者调度，交易消息可以高效分发，确保即将上任的领导者在计划生成区块前就已拥有足够多的待处理交易。该机制让验证者能够预处理交易，提前验证签名，并剔除重复或格式错误的交易。

Gulf Stream 的另一项优势在于，使用内存池的传统链还要求区块生产者在区块中再次传输相同交易，这意味着每笔交易至少要在网络中传播两次。Solana 无需让 gossip 承担过重负载来同步待处理交易，交易也无需通过 gas 竞价争夺区块空间；它们会根据调度进行分发。

交易处理单元（TPU）

TPU 是验证者负责区块生产的核心逻辑。交易从客户端获取，并通过名为 QUIC streamer 的组件以数据包形式转发。该组件负责分配数据包内存，并从 QUIC 端点读取数据（称为“获取阶段”）。每个流都会在由客户端（IP 地址、节点公钥）和服务器确定的 QUIC 传输约束内发送数据包。

随后，数据包会被发送至签名验证阶段，并通过特殊的负载削减机制进行去重，移除过量数据包。去重后的数据包会再次过滤，剔除签名无效的数据包，然后转发至银行阶段。

银行阶段是 Solana 运行时执行的关键组成部分。它会调度传入的数据包，进一步过滤冲突，并分批评估数据包应被处理、保留还是转发。如果检测到当前节点是区块生产者，它会通过 Bank 组件处理保留和新接收的数据包。Bank 组件是特定槽位中完整账本状态的内存表示。

在银行阶段和调度器组件中，交易以两种状态进行跟踪：

• 未处理状态：交易可供调度
• 待处理状态：交易当前正在被调度或处理

交易处理完成后，可能可以重试。如果交易可重试，它会恢复为未处理状态；否则应丢弃该状态。有效的已处理交易通过 PoH tick 组成“条目”，打包进区块，再以 shred 形式通过 Turbine，即 Solana 的区块传播协议广播给网络对等节点。Turbine 会生成纠删码，以便在广播阶段将数据包发送给相应网络对等节点前“重建”丢失的数据包。

交易验证单元（TVU）

TVU 是非领导者验证节点中负责验证和传播区块的逻辑。在 TVU 中，数据包在最终确定前会经历多个多线程阶段，包括 shred 获取、签名验证、重传和重放阶段。

在 Shred 获取阶段和 Shred 领导者签名验证阶段，非领导者通过 UDP 接收其他节点的 shred，并进行批量签名验证。有效 shred 会在重传阶段转发给对等节点，每笔交易则在重放阶段按顺序重放。

在重放阶段，系统会调用运行时，以确定性方式重新执行所有交易，确保所有状态变更、程序属性和 Bank 哈希与领导者的输出完全一致。

如果区块被评估为有效，验证者会签署一笔投票交易，并将该投票发送给领导者，以纳入后续区块。

运行时

运行时是 TPU 与 TVU 共享的 Solana 并发交易处理器。交易会预先指定其数据依赖关系（即希望读取和/或写入的账户），以支持显式动态内存执行。因此，状态读取可以与程序执行良好隔离，使运行时能够协调并发访问。

Solana 运行时使用名为 Sealevel 的执行引擎，确保访问只读账户的交易可以并行执行。相比之下，访问重叠可写账户的交易会被串行化并按顺序执行。

在运行时内，交易以原子方式执行；只有交易中的所有指令都成功执行，该交易才能提交到 Bank，否则交易失败。

运行时通过具有明确定义接口的入口点与特定程序交互。该入口点只是所有链上程序明确公开的一个 Rust 函数，作为执行起点以及 Solana 运行时与程序之间的接口。其执行引擎将公钥映射到账户，并将其路由至该入口点。不过，它会实施由虚拟机指令集架构定义的一些关键约束，以指导执行逻辑：

• 只有账户的所有者程序可以修改账户内容。
• 交易执行前后所有账户的总余额相等，但这仅适用于总量。系统转账和销毁不遵循 Lamport 守恒。
• 交易执行后，只读账户余额必须与交易前相等。
• 交易中的所有指令均以原子方式执行。如果其中一条失败，所有账户修改都会被丢弃。

TPU 和 TVU 流水线与运行时交互时遵循略有不同的路径。TPU 运行时确保在提交内存前记录“条目”（通过 PoH tick），而 TVU 运行时确保运行时处理任何交易前先验证“条目”。

共识

共识是复杂分布式计算系统中最基础的机制之一。在 Solana 的交易生命周期中，共识发生在区块由 TVU 执行和验证之后、最终确定之前。共识的核心是达成统一协议，确保网络参与者对同一结果形成一致意见，并且一旦作出决定便不能更改。

从形式上看，容错共识机制必须满足以下属性：

• 统一一致性：任意两个节点都不会作出不同决定。
• 完整性：任何节点都不会重复作出决定。
• 有效性：如果节点决定采用某个值，该值必定由某个其他节点提出。
• 终止性：每个未崩溃的节点最终都会决定采用某个值。

从表面上看，共识的目标是让节点就某件事达成一致。在 Solana 中，节点需要在多种情况下形成一致，主要集中在以下三个场景：

领导者轮换

所有节点都必须就谁是领导者达成一致，因为网络故障可能中断通信并导致脑裂，即多个节点错误地同时认为自己是领导者。

领导者调度使用预定义种子通过以下算法生成：系统定期使用 PoH tick 高度（即单调递增的计数器）作为稳定伪随机算法的种子。

在该高度，系统会从 Bank 中采样所有具有领导者身份、已质押且在集群配置的 tick 数量范围内投过票的账户。该样本称为活跃集，并按质押权重排序。随后使用随机种子按质押权重选择节点，创建权益加权顺序。经过集群配置的 tick 数量后，该顺序生效。

同步

如果没有可靠的时间戳，验证者便无法确定传入区块的顺序。Solana 使用名为历史证明的机制作为加密时钟，在交易进入共识前对其排序。根据 Anza 有关同步的文档：

“领导节点使用加密证明为区块‘加盖时间戳’，证明距上一个证明已经过去了一段时间。所有被哈希进证明的数据必然发生在证明生成之前。随后，节点会与验证节点共享新区块，而验证节点可以验证这些证明。区块可以按任意顺序抵达验证者，甚至可以在数年后重新播放。凭借如此可靠的同步保证，Solana 可以将区块拆分为更小的交易批次，称为条目。在形成任何区块共识之前，条目就会实时流式传输给验证者”。

需要牢记，虽然历史证明并不是共识机制，但它对 Solana 权益证明共识的性能有重大影响。

原子提交

节点需要达成一致的另一个必要流程是原子提交。在 Solana 这样的高性能系统中，一笔交易可能在部分节点上失败，却在其他节点上成功。

为了避免部分执行，Solana 会按照 ACID 的含义在运行时内确保原子性，同时确保所有节点就交易结果达成一致：要么回滚（发生任何错误时），要么提交（没有发生错误时）。

Solana 中的承诺度根据对区块（槽位）投票的验证者数量，以及这些投票在 Tower BFT 锁定机制中的深度来衡量区块的终局性。它反映了网络根据验证者投票对特定槽位达成共识的强度。每个验证者都对槽位（具体而言是区块高度）投票，并承诺不对冲突分叉投票；Tower BFT 的锁定机制可确保这一机制得到执行。

Solana 有三种承诺状态：已处理、已确认和已最终确定。当持有绝对多数质押（≥66%）的验证者为某个区块投票时，该区块即被视为已确认；当其上方至少又构建了 32 个已确认区块时，则视为已最终确定。

作为乐观并行执行和异步领导者调度的直接结果，Solana 遵循“先执行，后投票”模型：协议不会等所有验证者就新生成的区块达成一致后才生成下一个区块。这也可能导致分叉（即两条或更多竞争链同时存在的情况）。一旦某个槽位最终确定，所有竞争分叉都会被放弃，而该分叉将成为规范链。

Alpenglow

截至本文撰写时，Solana 使用 Tower BFT 和 PoH 账本，确保即使部分参与者发生故障，网络仍能达成共识状态。

最近，Anza 的研究团队提出了一种更简单、性能更高的新共识协议设计，名为 Alpenglow。Alpenglow 旨在彻底改造当前共识设计中的传统组件，包括历史证明、Tower BFT，以及使用 gossip 传播投票的方式。

Alpenglow 的核心是使用 Votor 和 Rotor 加速 Solana 的共识：

Votor 是一种两级投票机制。当 80% 的质押能够响应时，它可在单轮内实现区块终局性；当至少 60% 的质押能够响应时，则可在双轮内实现。

Rotor 通过使用单层中继节点处理 shred 分发，改进了现有 Turbine 协议。Rotor 还会按参与节点的质押比例利用其带宽，以减少跳数并优化 Solana 的吞吐量。 

Sui

Solana 使用以账户为中心的模型，而 Sui 区块链则采用面向对象的数据模型，将状态数据表示为具有唯一标识符、属性和方法的对象。

在 Sui 中，智能合约也是一种对象，称为 Sui Move 包。它拥有唯一标识符并可操作对象。这些 Sui Move 包由一组 Sui Move 字节码模块组成。每个模块都通过其名称，以及包的链上 ID 与模块名称的组合来唯一标识。

对象设计与元数据的复杂细节不在本文讨论范围内，但务必记住，每个对象都有一个所有者，由其决定该对象在交易中的使用方式。

对象可以采用以下所有权模型：

• **地址所有对象：**地址所有对象归某个特定的 32 字节地址所有，该地址可以是账户地址或对象 ID。只有其所有者可以访问。
• **不可变对象：**不可变对象不能被修改、转移或删除。它们没有所有者，任何人都可在全局访问和使用。
• **共享对象：**共享对象是所有人都可以访问的共享对象。
• 包装对象： 即将一个对象包装在另一个对象中。包装对象不具备独立性，只能通过外层包装对象访问。

一笔 Sui 交易

在 Sui 上，交易由一组针对输入执行的命令组成，用于定义交易结果。这些命令组称为可编程交易块（PTB），用于定义 Sui 上的所有用户交易。PTB 允许用户在单笔交易中调用多个 Move 函数、管理其对象及“代币”，无需发布新的 Move 包。

PTB 的结构定义如下：

{
    inputs: [Input],
    commands: [Command],
}

inputs 是由对象或纯值参数组成的向量。这些对象可以由发送者所有，也可以是共享或不可变对象。commands 字段是高级交易指令的向量。

执行 PTB 时，输入向量会填入输入对象或纯值字节。随后按顺序执行交易命令，并将结果存入结果向量。该向量是一个值数组，其中每个值都可以是对应命令特有的任意 Move 类型；与输入不同，这些值不限于对象或纯值。最后，交易效果会以原子方式应用。 

本文不会讨论 Sui PTB 的内部机制，因为这本身又是一个复杂主题。但需要注意，执行开始时，PTB 运行时会取得已加载的输入对象，并将其载入输入数组。这些对象已经由网络验证，包括检查对象是否存在及所有权是否有效等规则。纯值字节也会载入数组，但直到使用时才进行验证。

在这一阶段，gas 代币所受的影响至关重要。系统会从 gas 代币中扣除最大 gas 预算。最大 gas 预算通常由交易发送者在提交交易时指定，代表该交易最多可以消耗的 gas。执行结束时，所有未使用的 gas 都会退回 gas 代币，即使该代币已经更换所有者。随后，每条交易命令都会按顺序执行。

提交后，全节点会将交易发送给验证节点，以认证所有提供的元数据（认证阶段）。验证节点对交易执行所有必要的有效性检查，如果检查通过，则签名确认其有效。验证节点要将交易视为有效交易，该交易必须：

• 具有有效的用户签名。
• 确保交易发起者有权访问交易使用的所有自有输入对象。
• 确保交易使用的共享输入对象存在。
• 至少包含交易 gas 预算所指定数量的 gas。

如果所有检查均通过，验证者会尝试将所有自有 inputs 对象锁定到给定的“交易摘要”，确保每个自有输入一次只能使用一次。

如果锁定成功，验证者会签署交易并将签名返回给全节点。

Sui 全节点本质上是网络状态的只读视图。与验证节点不同，全节点无法签署交易，但可以重新执行先前由法定多数验证者提交的交易，以验证链的完整性。全节点不只收集单个验证者签名，而是尽可能并行收集更多验证者签名；不过，只需绝对多数（⅔+ 的质押）即可形成交易证书。

执行与检查点

交易获得证书后，会发送给验证者委员会（即一组独立验证者，每个 epoch 固定）执行。验证者无需重新验证交易，只需验证证书上的签名。如果证书签名有效，验证者便能确定交易有效。

执行期间，交易分为两类：自有对象交易和共享对象交易：

自有对象交易

自有对象交易不会访问任何共享输入对象，因此可以立即执行。这类交易也称为快速路径交易，即在验证后执行并提交到规范链。它们不会“经过”共识（快速路径交易最终仍会通过共识，但只是为了生成规范顺序并纳入检查点）。从技术上讲，这是因为只有所有者可以修改对象，不存在写入冲突的风险。 

共享对象交易

共享对象交易会访问共享对象，因此必须通过共识，与使用相同共享对象的其他交易一起排序，然后执行。这类交易也称为慢速路径交易。由于相关对象可由多个用户访问和修改，它们必须经过完整共识流程以确保一致性。 

此前，Sui 的内存池 Narwhal 将交易传播与排序解耦，并将已认证和签名的交易保存在有向无环图（DAG）中，而不自行排序，从而避免常见拥堵。随后由 Bullshark 提供共识排序。

为了进一步提高性能和韧性，HammerHead 协议作为 Bullshark 的增强方案被引入，实现了动态、基于评分的领导者选择。这显著降低了延迟并提高了吞吐量，尤其是在领导者出现故障或崩溃时。

在这些进展的基础上，Mysticeti 现在同时取代 Narwhal 和 Bullshark，将交易传播与排序统一到一个协议中。Mysticeti 以全序排列交易，进一步简化流程，实现更低延迟和更高吞吐量。此外，得益于 Sui 以对象为中心的所有权模型，大多数交易彼此独立，无需竞争全局排序位置。

交易执行后，验证者会签署交易效果并将其返回给全节点。交易效果本质上是交易所执行操作的列表，例如所有被修改的对象、消耗的 gas，以及交易的执行状态。

全节点从绝对多数验证者处收集效果签名，并由此形成效果证书集合，保证交易已最终确定。

当交易被纳入检查点，即进入生命周期的最后阶段时，该交易产生的状态变更早已最终确定并应用到网络。

对于仅涉及自有输入对象的交易，验证者会先执行并最终确定交易，再将其提交至共识层进行排序。

相比之下，涉及共享输入对象的交易会在执行前提交至共识进行排序，且不会为了纳入检查点而再次提交。

验证者从共识层收集具备因果顺序且完整的交易区块，并构建检查点。检查点同时包含交易摘要列表及每笔交易对应的效果摘要。因此，检查点构成网络中所有已最终确定状态转换的不可变记录。

终局性

只要绝对多数 (2𝑓 + 1) 验证者接受并会签交易证书，Sui 上的交易便达到终局性，甚至无需等待证书由共识排序或执行。此时不会再出现冲突交易，该交易也无法撤销。对于仅涉及自有对象的交易，执行结果在达到终局性时即可得知；对于共享对象交易，只有在证书经共识排序后才能确定结果。交易会在两次网络往返内达到终局性。

当绝对多数验证者执行交易并形成效果证书时，即完成结算。对于自有对象交易，执行会立即发生，无需等待共识。对于共享对象交易，执行与结算发生在证书经共识排序后不久。两种情况下，结算都不会因创建检查点而延迟，因此延迟低于检查点流程。

交易证书虽然强烈表明交易已达到终局性，但只有效果证书或被纳入已认证检查点才能提供绝对保证，因为这两者都要求绝对多数验证者执行并提交交易效果。

从宏观层面看，Sui 交易生命周期利用以对象为中心的模型，最大限度提高并行度与效率。交易提交认证后，验证者会尝试锁定其引用的特定版本输入对象。

对于自有对象，这些锁会在认证期间立即获取，以确保独占访问并防止双花。对于共享对象，只有交易通过 Sui 共识协议完成排序后才会建立锁。

获得所有必要的锁后，交易将被调度执行。这一设计允许针对互不相交对象集的交易独立并行执行，显著减少状态中无关部分之间的争用和拥堵。

成功执行后，验证者会签署交易效果。收集到绝对多数签名后，便会形成效果证书。该证书为结算终局性提供保证，表明交易已不可逆转，其效果将永久保留。

检查点不在交易执行或终局性的关键路径上。它们在执行后构建，用于提供交易的规范顺序，并帮助未直接参与执行的节点同步状态。

Sui 的对象模型支持在对象层面精确跟踪依赖关系，无需同步全局状态。该架构支持在通用硬件上进行可扩展的分布式执行，而不是依赖硬件性能进步来提高吞吐量。

执行、可扩展性与设计权衡分析

如前所述，理解交易生命周期可能是认识区块链设计理念最直观的方式。Solana 与 Sui 交易生命周期的差异，从三个关键维度揭示了其执行模型的深层理念：执行效率、扩展阈值和设计权衡。

执行

作为一条以账户为中心的链，Solana 在银行阶段通过账户锁定动态检测账户冲突，确保不修改同一账户的交易并行处理，而冲突交易按顺序处理。

这种账户检测机制可能在高负载 DeFi 场景中增加额外的运行时成本，尤其是程序需要执行其他程序中的逻辑时（该机制称为跨程序调用）。但凭借动态冲突检测，Solana 的执行引擎仍能实现大规模并行，让链能够以极低费用近乎即时地执行交易。

另一方面，Sui 无需担心交易冲突，因为其以对象为中心的所有权模型可以在编译时推断并行性。共享对象与自有对象模型支持静态推断冲突，使自有对象交易的运行时成本接近于零。

扩展阈值

在扩展方面，Sui 可实现横向扩展，并随对象分区线性扩展。它无需全局共识即可处理自有对象交易，实现近乎即时的亚秒级终局性，吞吐量仅受可用硬件限制。共享对象交易需要共识，但在 Mysticeti 升级后，它们同样可以实现亚秒级终局性和高吞吐量。Sui 的架构允许通过添加资源来弹性扩展区块传播与执行，从而高效处理不断增加的工作负载，不过共识路径并不像自有对象的快速路径那样几乎不受限制。

Solana 采用单领导者方案和执行扇出，且后者受账户争用限制。由于全局单分片状态模型，以及每个槽位由领导者主导的交易接收方式，它似乎会触及某种横向扩展阈值。不过，Solana 通过定义明确的流水线在该阈值内进行积极优化，并由 PoH 提供补充。交易能够被准确排序，在 400ms 内完成处理，并在不到一秒内实现乐观确认。在纵向扩展方面，Solana 可以随验证者硬件（尤其是 CPU 核心和 RAM）大幅扩展，这与其固有设计高度契合。

需要明确的是，Solana 选择纵向扩展而非横向扩展，并因设计权衡而触及上限，这并不代表架构失败。目前，一些横向方案正在开发中，例如本地费用市场、虚拟子网，以及通过 CMT 最小化状态。

设计权衡

Solana 通过严格的运行时约束、账户隔离和确定性领导者调度来保证确定性。其动态账户争用解决机制和定义明确的流水线有利于深度程序间交互，使其具备强大的可组合性。

Sui 通过基于对象所有权分析确定的内置执行路径提供确定性保证。同时，Sui 以对象为中心的模型通过共享对象和可编程交易块（PTB）实现可组合性，支持跨多个合约和用户的复杂交互与原子操作。这是因为对象的所有者可以是另一个对象，从而实现对象级互操作性，并将对象组织成所有权树。当对象经常一起使用，或执行期间需要通过运行时查找确定要操作的对象时，这种结构尤其有用。

总结

交易从提交到最终确定的处理机制，是 Solana 和 Sui 实现卓越高性能的基础。通过研究交易生命周期，我们可以深入了解两条链精心设计的流水线如何确保低延迟和高吞吐量。

Solana 采用以账户为中心的模型，交易会经历一系列多线程流程和流水线来确保有效性。交易提交给领导者后，领导者运行 TPU 流水线，确保交易得到验证和适当调度：不冲突时并行处理，冲突时按顺序处理。当验证者不生产区块时，它会运行 TVU 流水线来复制和验证交易。TPU 与 TVU 都使用运行时。运行时能够预先以确定性方式识别互不重叠的账户，并行执行不存在冲突的交易，因此 Solana 可以在极短时间内处理数千笔交易，非常适合高频交易、深度可组合 DeFi、基础设施密集型 dApp，以及低延迟消费类 dApp 等真实场景。

另一方面，Sui 使用以对象为中心的模型，通过唯一标识符跟踪每个对象。通过推断对象所有权，它可以静态判断一笔涉及互不相交对象集的交易能否并行执行。借助双执行路径模型（即将交易分为自有对象交易和共享对象交易，并使用已签名检查点保持全节点同步），Sui 可以在不增加共识层负担的情况下处理轻量级交易，同时仍能为新节点实现可靠、快速的终局性和高效同步。这让它能够随负载增长进行横向扩展，非常适合涉及海量对象交互的应用，例如 DeFi、游戏、以资产为中心的交易平台和可编程资产。

参考资料

• Solana 官方文档
• Anza 官方文档
• Sui 官方文档
• Gulf Stream：Solana 的无内存池交易转发协议
• Sealevel——并行处理数千个智能合约
• 跨程序调用与 PDA——Anchor 上两种强大机制的结合
• Narwhal 与 Tusk：基于 DAG 的内存池和高效 BFT 共识
• 使用 Pilotfish 横向扩展 Sui 执行
• SUI 与 Solana 对比 - TrustWallet
• Tower BFT：Solana 的高性能 PBFT 实现
• David J DeWitt 和 Jim N Gray：“并行数据库系统：高性能数据库系统的未来”，Communications of the ACM，第 35 卷第 6 期，第 85–98 页，1992 年 6 月。doi:10.1145/129888.129894
• Jim N Gray 和 Leslie Lamport：“交易提交共识”，ACM Transactions on Database Systems (TODS)，第 31 卷第 1 期，第 133–160 页，2006 年 3 月。doi:10.1145/1132863.1132867
• Leslie Lamport：“分布式系统中的时间、时钟与事件排序”，Communications of the ACM，第 21 卷第 7 期，第 558–565 页，1978 年 7 月。
• Michael J Fischer、Nancy Lynch 和 Michael S Paterson：“存在一个故障进程时实现分布式共识的不可能性”，Journal of the ACM，第 32 卷第 2 期，第 374–382 页，1985 年 4 月。doi:10.1145/3149.214121
• Kushal Babel、Andrey Chursin、George Danezis、Anastasios Kichidis、Lefteris Kokoris-Kogias、Arun Koshy、Alberto Sonnino、Mingwei Tian：“MYSTICETI：利用未认证 DAG 逼近延迟极限”，[cs.DC]，2024 年 7 月。
• Giorgos Tsimos、Anastasios Kichidis、Alberto Sonnino、Lefteris Kokoris-Kogias：“HammerHead：用于动态调度的领导者声誉机制”，[cs.CR]，2023 年 9 月。