Solana交易生命周期与Sui对象运行时的比较

Helius 发布于 2025-04-14 阅读 2238

本文深入比较了Solana和Sui区块链的交易生命周期，探讨了它们各自通过不同的执行模型实现高吞吐量和低延迟的方式。Solana采用账户中心模型，通过动态冲突检测实现并行处理，而Sui采用对象中心模型，通过对象所有权分析实现静态冲突避免，从而优化交易处理效率和可扩展性。

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

29 分钟阅读

2025 年 4 月 13 日

Solana 内容马拉松 — 第一名

本文由 Prince Israel 撰写，并因我们在 2025 年 Solana 内容马拉松期间的“Solana vs. 世界”赏金而获得一等奖。

Solana 和 Sui 是杰出的高性能 Layer 1 区块链，能够在不牺牲可扩展性、速度或去中心化的前提下，以极低的成本处理大量的交易。

这两种协议都已在业内获得认可，被认为是解决以太坊和比特币等较旧区块链的许多局限性的前沿区块链。

这些协议旨在并行处理数万笔交易，从而在理论和实践中实现极高的吞吐量。 例如，Solana 在理想情况下可以达到每秒 65,000 笔交易 (TPS)，并且在现实场景中始终如一地达到大约 4,000 TPS。

另一方面，Sui 已展示了 297,000 的理论最大 TPS，但自成立以来已处理了最多 3,500 TPS，平均每天处理大约 400 TPS 的用户交易，外加 600 TPS 的系统交易用于检查点构建。

如今，Solana 在 400 毫秒内实现乐观确认，在大约 12.8 秒内达到完全最终性，并且预计通过即将到来的 Alpenglow 共识升级，在 100-130 毫秒内实现完全最终性。 由于其强大的乐观设计，Sui 在第 90 个百分位延迟 (P90) 实现了亚秒级最终性。

在这篇研究文章中，我们通过分析两条链的交易生命周期来研究驱动高交易性能的底层机制，并全面地对它们不同的执行模型如何使它们能够以低时间最终性实现高吞吐量进行并排比较。

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

区块链处理交易。交易影响状态（即，区块链上账户的更新视图）。理解交易的生命周期可以最清楚地表达区块链的设计理念，为技术利益相关者提供关于链如何针对吞吐量和安全性、确定性保证、相对工程成本以及在真实条件下可能出现的潜在痛点进行优化的重要见解。

在后续章节中，我们将研究交易从提交到完成的不同阶段，以及这个过程如何影响这些链中各个级别的执行。

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 存在是为了验证条目。

Solana 验证器在领导者模式下的图

从高层次的概述来看，交易通过客户端提交，并通过 Gulf Stream 通过 QUIC 转发到领导者的 TPU。 交易经过验证检查，然后由银行业务阶段安排执行。 状态更新被写回到银行的内存状态中。 验证器通过 gossip 对区块进行投票，并且区块使用 Tower BFT 最终确定，这是一种具有 stake 加权锁定机制的 PBFT 变体。

Gulf Stream

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

Solana 通过依赖于由 stake 加权算法（称为 Stake-Weighted Quality of Service (SWQoS)）影响的确定性领导者计划来消除对全局 mempool 的需求，以优先考虑通过 staked 验证器路由的交易消息。

由于所有活动节点都提前知道领导者计划，因此可以有效地分发交易消息，从而确保即将到来的领导者在计划生成区块之前已经有足够的交易要处理。 此机制使验证器能够预处理交易，从而验证签名并预先消除重复或格式错误的交易。

Stake 加权服务质量

Gulf Stream 的另一个优点是，与使用 mempool 的传统链相比，区块生产者还必须在区块中重新传输相同的交易，这意味着每笔交易都至少通过网络传播两次。 Solana 不需要过度使用 gossip 来同步挂起的交易，并且交易不需要通过 gas 拍卖来争夺区块空间； 相反，它们是根据计划进行分配的。

交易处理单元 (TPU)

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

然后，数据包被传输到 Sigverify Stage，在那里使用特殊的负载卸载机制对其进行重复数据删除，以删除过多的数据包。 现在过滤掉重复数据删除的数据包，以删除那些具有无效签名的数据包，并将其转发到银行业务阶段。

银行业务阶段是 Solana 运行时执行的关键组件。 它安排传入数据包，进一步过滤它们以查找冲突，并评估它们是否有资格分批处理、保存或转发。 如果它检测到该节点是区块生产者，则它使用 Bank 组件处理保存的和新接收的数据包。 Bank 组件是给定插槽中账本完整状态的内存表示。

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

  • 交易可用于调度的未处理状态
  • 交易当前正在被调度或正在处理的挂起状态

当交易完成处理时，它可能是可重试的。 如果交易是可重试的，则它会转换回未处理状态； 否则，应删除该状态。 有效的处理交易通过 PoH tick形成“条目”，捆绑到区块中，并通过 Turbine（Solana 的区块传播协议） 以 shreds 的形式广播到网络对等方，该协议生成 erasure 代码以“重新生成”丢失的数据包，然后再将数据包传输到广播阶段中的相应网络对等方。

历史证明(PoH)服务

交易验证单元 (TVU)

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

在 Shred Fetch Stage 和 Shred Verify Leader 签名阶段，非领导者通过 UDP 从其他节点接收 shreds 并执行批量签名验证。 有效的 shreds 在 Retransmit Stage 中被重传到对等节点，并且每个交易在 Replay Stage 中按顺序重放。

Solana 交易生命周期的重传阶段

在重放阶段，运行时被调用以确定性地重新执行所有交易，从而确保所有状态更改、程序属性和银行哈希与领导者的输出完全匹配。

如果一个区块被评估为有效，则验证器会签署一个投票交易并将此投票发送给领导者以包含在后续区块中。

Solana 交易验证单元

运行时

运行时是 Solana 的并发交易处理器，在 TPU 和 TVU 之间共享。 交易预先指定其数据依赖项（即，它们希望从中读取和/或写入的帐户）以启用显式动态内存执行。 因此，读取状态可以很好地与程序执行隔离，从而使运行时可以编排并发访问。

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

在运行时中，交易是原子执行的； 交易中的所有指令都必须成功执行，该交易才能提交到银行，否则该交易将失败。

运行时通过具有明确定义的接口的入口点与给定的程序进行交互。 此入口点只是一个 Rust 函数，所有链上程序都干净地将其公开为执行的起点，并用作 Solana 运行时和程序的接口。 它的执行引擎将公钥映射到帐户并将它们路由到此入口点。 但是，它会强制执行一些关键约束来指导其执行逻辑，这些约束由虚拟机指令集架构定义：

  • 只有所有者程序才能修改帐户的内容。
  • 在执行交易之前和之后，所有帐户上的总余额都相等，但这仅适用于聚合。 Lamports 不会为系统转移和销毁而保留。
  • 执行交易后，只读帐户余额必须等于交易前的余额。
  • 交易中的所有指令都是原子执行的。 如果一个失败，则会丢弃所有帐户修改。

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

Solana 交易流水线图

共识

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

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

  • 统一协议：没有两个节点做出不同的决定。
  • 完整性：没有节点多次决定。
  • 有效性：如果一个节点决定一个值，那么该值是由其他某个节点提出的。
  • 终止：每个没有崩溃的节点最终都会决定某个值。

从表面上看，共识的目标是让节点就某些事情达成一致。 对于 Solana，在几种情况下节点需要达成一致。 这在三种情况下最为突出：

领导者轮换

所有节点都必须就谁是领导者达成一致，因为网络故障可能会中断通信并导致脑裂情况，在这种情况下，多个节点错误地认为它们同时是领导者。

领导者计划是使用具有以下算法的预定义种子生成的：PoH tick高度（即，单调递增的计数器）会定期用于为稳定的伪随机算法播种。

在该高度，银行会针对在集群配置数量的tick内投票的所有具有领导者身份的 staked 帐户进行采样。 该样本称为活动集，它按 stake 权重排序。 然后，随机种子用于选择按 stake 加权的节点以创建 stake 加权排序，该排序在集群配置数量的tick后变为有效。

同步

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

“领导者节点使用加密证明为区块“盖时间戳”，证明自上次证明以来已经过去了一段时间。 所有哈希到证明中的数据肯定发生在生成证明之前。 然后，节点与其他节点分享新区块，其他节点能够验证这些证明。 区块可以以任何顺序到达其他节点，甚至可以在几年后重放。 借助这种可靠的同步保证，Solana 可以将区块分解为称为条目的较小批次的交易。 然后，在任何区块共识概念之前，条目会实时传输到其他节点”。

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

原子提交

节点需要达成一致的另一个必要过程是原子提交。 在像 Solana 这样的高性能系统中，交易可能会在某些节点上失败，而在其他节点上成功。

为了避免部分执行，Solana 确保运行时内的原子性，在 ACID 的意义上，并且还确保所有节点都对交易的结果达成一致：要么它们回滚（如果出现任何问题），要么它们提交（如果没有出现任何问题）。

Solana 中的承诺根据已投票的验证器的数量以及他们在 Tower BFT 锁定机制中的投票深度来衡量区块（插槽）的最终性。 它反映了网络基于验证器进行的投票对给定插槽达成一致的程度。 每个验证器都对插槽（特别是区块高度）进行投票，并承诺不对冲突的分叉进行投票； Tower BFT 中的锁定确保强制执行此机制。

Solana 有 三种承诺状态：已处理、已确认和已最终确定。 当绝大多数 staked 验证器 (≥66%) 对一个区块进行投票时，据说该区块已被确认，并且当至少 32 个已确认的区块建立在其之上时，该区块已最终确定。

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

Alpenglow

截至本文撰写之时，Solana 使用 Tower BFT 和 PoH 账本来确保即使某些参与者失败，网络也能达成共识状态。

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

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

Votor 是一种两层投票机制，旨在如果 80% 的 stake 有响应，则在单轮中实现区块最终性，如果至少 60% 的 stake 有响应，则在双轮中实现区块最终性。

Rotor 通过采用单层中继节点来处理 shred 传播，从而改进了现有的 turbine 协议。 Rotor 还利用参与节点的带宽（与其 stake 成比例）来减少跳数并优化 Solana 的吞吐量。

如何在 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 币，即使该币已更改其所有者。 然后按顺序执行每个交易命令。

注意：

Sui 还有另一种交易，称为 赞助交易。 它们的结构与 PTB 相同，但在这种情况下，一个称为赞助商的 Sui 地址会为另一个地址初始化的交易支付 gas 费用。 简而言之，赞助商会提供 gas 币并与用户一起签署交易，主要目标是承担用户的成本。

提交后，完全节点通过将交易发送到验证器节点（认证阶段）来认证所有提供的元数据。 验证器节点对交易执行所有必要的有效性检查，并在检查通过后对其进行签名以确认其有效性。 为了使交易被验证器节点视为有效交易，它必须：

  • 具有有效的用户签名。
  • 确保交易发起者可以访问交易使用的所有拥有的输入对象。
  • 确保交易使用的共享输入对象存在。
  • 包含的 gas 至少与交易的 gas 预算中指定的 gas 一样多。

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

如果锁定过程成功，则验证器会对交易进行签名，并将签名返回到完全节点。

Sui 完全节点本质上是网络状态的只读视图。 与验证器节点不同，完全节点无法对交易进行签名，尽管它们可以通过重新执行先前由法定数量的验证器提交的交易来验证链的完整性。 完全节点不仅仅收集单个验证器签名，而是尽可能多地并行收集验证器签名； 但是，只需要超级多数（⅔+ 的 stake）即可形成交易证书。

Sui 交易生命周期如何工作

执行和检查点

一旦交易获得证书，它们就会被发送到验证器委员会（即，一组独立的验证器，每个时代固定）以供执行。 验证器不需要重新验证交易：它要做的就是验证证书上的签名。 如果证书上的签名有效，则验证器可以确定交易是有效的。

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

拥有的对象交易

拥有的对象交易 不访问任何共享输入对象，并且会立即执行。 这些交易也称为快速通道交易，即，它们在验证后执行并提交到规范链。 这些交易不会“通过”共识（快速通道交易最终会通过共识，但仅用于生成规范排序以包含在检查点中）。 从技术上讲，这是可能的，因为不存在冲突写入的风险，因为只有所有者才能修改该对象。

共享对象交易

共享对象交易 访问共享对象，因此需要通过共识与其他使用相同共享对象和执行它们的交易进行排序。 这些也称为慢速通道交易。 它们必须经过完整的共识过程才能确保一致性，因为所涉及的对象可以被多个用户访问和修改。

以前，Sui 的 mempool Narwhal 通过将交易传播与排序分离来避免典型的拥塞，从而在有向无环图 (DAG) 中保存经过认证的已签名交易，而无需自行对其进行排序。 然后，Bullshark 提供了共识排序。

为了进一步提高性能和弹性，引入了 HammerHead 协议作为对 Bullshark 的增强，实现了动态的、基于分数的领导者选择。 这大大降低了延迟并提高了吞吐量，尤其是在出现故障或崩溃的领导者的情况下。

在这些进展的基础上，Mysticeti 现在取代了 Narwhal 和 Bullshark，将交易传播和排序统一到一个协议中。 Mysticeti 以总顺序对交易进行排序，从而进一步简化了该过程并实现了更低的延迟和更高的吞吐量。 此外，由于 Sui 以对象为中心的拥有权模型，大多数交易保持独立，不需要争夺全局排序槽。

交易执行后，验证器会对交易的效果进行签名，并将它们返回到完全节点。 交易效果本质上是交易采取的所有操作的列表，例如所有被改变的对象、花费的 gas 以及交易的执行状态。

效果签名构成了由完全节点从大多数验证器收集的效果证书的集合，从而保证了交易已最终确定。

当交易包含在 检查点 中时（表示它在其生命周期中的最后阶段），由该交易产生的状态更改已最终确定并应用于网络。

对于仅涉及拥有的输入对象的交易，验证器会在将这些交易提交到共识层以进行排序之前执行并最终确定它们。

相比之下，涉及共享输入对象的交易会在执行之前提交给共识以进行排序，并且不会为了包含在检查点中而重新提交。

验证器从共识层收集因果排序和完整的交易块，并构建一个检查点，其中包含交易摘要列表以及每个交易效果的相应摘要。 因此，检查点充当网络中所有最终确定的状态转换的不可变记录。

图解说明交易如何在 Sui 区块链上工作

最终性

Sui 交易最终性图

Sui 上的交易会立即实现最终性，只要超级多数 (2? + 1) 的验证器接受交易证书并对其进行反签名，即使证书尚未通过共识进行排序或执行。 此时，不会发生冲突的交易，并且该交易无法撤销。 对于仅涉及拥有的对象的交易，执行结果在最终确定后立即知道； 对于共享对象交易，结果仅在证书通过共识排序后确定。 交易最终性在两次网络往返中实现。

当交易由大多数验证器执行并且形成了效果证书时，就会发生清算。 对于拥有的对象交易，此执行会立即发生，而无需等待共识。 对于共享对象交易，执行和清算发生在证书通过共识排序之后。 在这两种情况下，清算都不会因检查点创建而延迟，从而导致比检查点过程更低的延迟。

虽然交易证书强烈表明了最终性，但只有效果证书或包含在经过认证的检查点中才能提供绝对保证，因为这些都需要大多数验证器执行和提交交易效果。

从宏观层面来看，Sui 交易生命周期利用以对象为中心的模型来最大化并行性和效率。 当提交交易以进行认证时，验证器会尝试锁定其引用的输入对象的特定版本。

对于拥有的对象，这些锁会在认证期间立即获得，从而确保独占访问并防止 double-spending。 对于共享对象，只有在通过 Sui 的共识协议对交易进行排序后，才会建立锁。

一旦获得所有必需的锁，就会安排交易以供执行。 此设计允许独立且并行地执行对不相交的对象集进行操作的交易，从而显着减少了整个状态的无关部分的争用和拥塞。

成功执行后，验证器会对交易效果进行签名，并且一旦收集到大多数签名，就会形成效果证书。 此证书可保证清算最终性，表明该交易现在是不可逆转的，并且其效果是永久性的。

检查点不是交易执行或最终性的关键路径的一部分。 相反，它们是在执行后构建的，以提供交易的规范排序并促进未直接参与执行的节点的状态同步。

Sui 的对象模型能够在对象级别进行精确的依赖关系跟踪，从而无需全局状态同步。 这种架构支持在通用硬件上进行可扩展的分布式执行，而不是依赖于硬件性能的进步来实现更高的吞吐量。

对执行、可扩展性和设计权衡的见解

如前所述，理解交易的生命周期可以最清楚地表达区块链的设计理念。 Solana 和 Sui 之间交易生命周期的差异揭示了跨三个关键向量的深度执行模型理念：执行效率、可扩展性阈值和设计权衡。

执行

Solana 作为一个以帐户为中心的链，通过银行业务阶段期间的帐户锁定来动态检测帐户冲突，从而确保不修改同一帐户的交易并行处理，而冲突的交易按顺序处理。

即使这种帐户检测机制可能会在繁重的 DeFi 情况中引入额外的运行时成本，特别是在程序需要执行在其他程序中找到的逻辑时（一种称为跨程序调用的机制），Solana 的执行引擎仍然能够通过其动态冲突检测来实现大规模并行性，从而使链能够以极低的费用几乎瞬间执行交易。

另一方面，Sui 不需要担心冲突的交易，因为它的并行性是在编译时推断出来的，这要归功于它以对象为中心的拥有权模型。 共享对象和拥有的对象模型使得可以静态地推断冲突，并为拥有的对象交易实现几乎为零的运行时成本。

可扩展性阈值

在扩展方面，Sui 实现了水平可扩展性，并且可以通过在没有全局共识的情况下处理拥有的对象交易来使用对象分区线性扩展，从而实现接近即时、亚秒级的最终性和吞吐量，这仅受可用硬件的限制。 共享对象交易需要共识，但通过 Mysticeti 升级，它们现在也实现了亚秒级的最终性和高吞吐量。 Sui 的架构允许通过添加更多资源来弹性地扩展区块传播和执行，从而使系统能够高效地处理增加的工作负载，尽管共识路径不像拥有的对象的快速路径那样无界。

Solana 凭借其单领导者方法和执行扇出（受帐户争用限制），由于全局单分片状态模型及其以领导者为中心的每槽交易摄取，确实似乎达到了某种水平扩展阈值，但通过其定义明确的流水线在此阈值内进行了积极优化，PoH 对其进行了补充。 交易可以准确排序，在不到 400 毫秒内处理，并在不到一秒内实现乐观确认。 在垂直扩展方面，Solana 使用验证器硬件（尤其是 CPU 内核和 RAM）大规模扩展，因为这与其固有的设计完美契合。

重要的是要划定，Solana 选择垂直扩展而不是水平扩展，并且由于设计权衡而不是架构故障而达到上限。 一些水平方法（例如，本地费用市场、虚拟子网和通过 CMT 进行的状态最小化）目前正在开发中。

设计权衡

Solana 通过严格的运行时约束、帐户隔离和确定性领导者调度来保证确定性。 它的动态帐户争用解决和定义明确的流水线有利于深度程序间交互，使其能够实现强大的可组合性。 Sui 通过由对象所有权分析确定的内置执行路径来实现确定性保证。同时，Sui 的以对象为中心的模型通过共享对象和可编程交易块（PTB）实现可组合性，从而允许跨多个合约和用户的复杂交互和原子操作。 这是可能的，因为对象的所有者可以是另一个对象，从而实现对象级别的互操作性以及将对象组织成所有权树。当对象经常一起使用，或者在运行时需要查找以确定在执行期间要操作哪个对象时，这种结构特别有用。

总结

交易从提交到最终确认的处理机制是 Solana 和 Sui 令人难以置信的高性能的基础。 通过检查交易生命周期，我们可以深入了解精心设计的流水线，这些流水线可确保两条链的低延迟和高吞吐量。

Solana 是在以账户为中心的模型上设计的，交易经历一系列多线程流程和流水线，以确保其有效性。 交易被提交给领导者，领导者运行 TPU 流水线以确保交易得到验证并进行相应的调度； 如果它们不冲突则并行，如果冲突则串行。当验证者不生成区块时，它会运行 TVU 流水线来复制和验证交易。 TPU 和 TVU 都使用运行时。 因此，Solana 可以在很短的时间内处理数千笔交易，因为运行时可以预先且确定性地推断出非重叠的账户，并并行执行不冲突的交易，这使得 Solana 非常适合现实世界的案例，例如高频交易、深度可组合的 DeFi、基础设施繁重的 dApp 和低延迟的消费者 dApp。

另一方面，Sui 使用以对象为中心的模型，其中唯一的标识符跟踪每个对象。 通过推断对象所有权，它可以静态地确定交易是否可以在并行执行，如果它触及不相交的对象集。 通过其双重执行路径模型（即将交易分离为自有对象交易和共享对象交易，并使用签名检查点来保持完整节点同步），它可以在不给共识层带来负担的情况下处理轻量级交易，同时仍然实现可靠、快速的最终性和高效的新节点同步。 这使其能够随着负载的增加而水平扩展，并且对于具有大量对象交互的应用程序非常有用，例如 DeFi、游戏、以资产为中心的交易所和可编程资产。

参考文献

  • 原文链接： helius.dev/blog/solana-v...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
微信扫码分享

相关文章

0 条评论

登录后发表评论