什么是 Solana 承诺级别？

什么是 Solana 承诺级别？

Solana 承诺级别是一种标准化方式，用于衡量网络对给定区块或交易的共识程度。当你向 Solana RPC 节点查询交易状态或账户数据（例如 getTransaction）时，可以指定承诺级别，表示你希望数据达到何种最终确认程度。Solana 通过承诺级别让客户端在延迟与确定性之间权衡：较低的承诺级别能更快反馈，而较高的承诺级别则让开发者更有把握确定状态不会回滚。

Solana 定义了三个主要承诺级别（按最终性从高到低排列）：

Finalized

确定性最高的级别，表示该区块已获绝大多数质押权重（≥66%）确认，并且其上又构建了至少 31 个已确认区块，使该 slot 达到最高的 32 票锁定。已最终确认的交易实际上不可逆转。

Confirmed

中间级别，表示该区块已获得绝大多数质押权重（≥66%）投票，但尚未经过更长时间的持续投票而达到难以逆转的最终确认状态。这通常称为乐观确认，能够有力保证交易位于“主分叉”或规范链上。

Processed

Processed 表示交易刚刚由 leader 处理，并被纳入节点已知的最新区块。但该区块可能尚未获得集群范围内的任何投票。如果它最终未进入多数分叉，这笔交易仍可能被丢弃。

这些级别代表交易生命周期中的不同阶段。 

一笔刚提交的交易会随着更多网络节点观察并投票支持包含它的区块，以及后续区块在其上构建，而依次经历 Processed → Confirmed → Finalized。承诺级别越高，表示越多节点认同该交易已被纳入账本，从而降低发生分叉或回滚的风险。 

下面详细了解每个级别。

Processed 承诺级别

一旦验证者节点（即当前 leader）将交易纳入区块，该交易就会被标记为 Processed。这是最早的确认：交易已被接收，并在本地纳入账本状态。

Processed 级别的主要特点包括：

• **已纳入区块：**交易位于验证者生成的区块中。
• **不保证位于多数分叉：**该区块可能会，也可能不会最终进入多数（最长/最重）分叉
• **反馈最快：**它会立即反馈交易已由节点处理。这对快速更新客户端界面很有帮助（例如在钱包 UI 中显示待处理交易）。
• **并非完全安全：**在此阶段，无法保证其他验证者已经看到该区块或为其投票。集群仍可能“跳过”这个区块，或用另一个分叉覆盖它。换言之，Processed = 已纳入区块，但尚未获得其他节点确认。

Processed 区块示例： 

假设 Alice 在 Solana 上提交了一笔转账。当前 leader 将其添加到区块（slot N）后，这笔交易会立即被标记为 Processed。Alice 的钱包可能马上将其显示为待处理/已处理。 

但是，如果该 leader 的区块未被多数验证者接受（例如 leader 响应缓慢或离线，导致另一条分叉占据主导地位），Alice 的交易可能会消失（即被丢弃），因为该已处理区块未能成为主链的一部分。

Confirmed 承诺级别

Confirmed 承诺级别表示交易所在区块已被集群的绝大多数节点接受，并且极有可能位于规范链上。从技术上讲，“confirmed”意味着质押权重合计达到或超过 66% 的验证者已直接为该区块投票。 

主要特点：

• **位于多数分叉：**包含该交易的区块被视为账本多数分叉的一部分。这意味着网络将其视为规范区块。

• **绝大多数投票：**至少三分之二的总质押权重已投票确认该区块。这些投票通过 Solana 的传播机制汇集，意味着验证者已在整个网络中广播并观察到对该区块的投票。此阶段采用 Solana v1.3 引入的乐观确认机制，只要绝大多数节点已为区块投票，节点就可以将其视为已确认，即使它尚未最终确认。

• **回滚风险低：**在共识权重达到 66% 以上后，冲突分叉取代该区块的可能性极低，但并非完全不可能。除非发生重大链重组，否则所有诚实验证者实际上都已承诺支持该区块。Solana 五年历史中从未发生过已确认区块被回滚的情况。

• 快于 Finalized：区块或交易被标记为 processed 后，通常很快（一两秒内）就会达到 confirmed 状态，因为验证者会迅速对新区块投票。它不需要等待许多后续区块。因此，在正常情况下，confirmed 能很好地兼顾速度与可信度。

• **乐观最终性：**鉴于 Solana 的共识速度很快，在大多数实际场景中，开发者通常会将 confirmed 交易视为基本不可逆。但在最终确认之前，仍有很小的回滚概率。

Confirmed 区块示例： 

当集群中的验证者对区块 N 投票后，上述 Alice 的交易就会变为 Confirmed。实际运行中，如果接下来的几个验证者（位于 slot N+1、N+2 等）投票并观察到区块 N，使投票权重达到 66% 的门槛，网络就会将区块 N 标记为 confirmed。此时，Alice 的钱包可以放心地向用户显示该交易已确认。 

此时 Alice 的转账被回滚的概率非常低，只有发生罕见的分叉或网络问题时才可能出现。这类似于其他链上的“N 次确认”，但 Solana 依据的是质押权重投票，而不是固定数量的区块确认。

Finalized 承诺级别

当交易所在区块获得绝大多数节点投票，并且其上已构建足够多的后续区块时，该交易就会达到 Finalized 状态。在 Solana 共识中，这表示区块已达到最大锁定，通常需要连续 32 次投票（slot）予以确认。Finalized 是最强的承诺级别，最大程度保证交易不会被逆转。 

Finalized 的特点包括：

• **不可逆区块：**集群已将该区块认定为最终确认，这意味着它已在账本状态中生根。验证者不会将其回滚，因此实际上具有永久性。

• **绝大多数投票 + 锁定：**与 Confirmed 一样，至少 66% 的质押权重支持该区块。此外，其后还添加了 31 个以上的后续已确认区块。换言之，网络已在该区块之上构建了一条深度足够的链，达到几乎无法发生重组的锁定深度。

• 最大锁定（32 票）：Solana 的 Tower BFT 机制会以指数方式将投票锁定期翻倍。当一个区块在投票塔中累积 32 票时（意味着它在接下来的 32 个 slot 中始终属于分叉头部），就会达到最大锁定并获得最终确认。此时，任何试图为替代分叉投票的验证者都会违反共识规则。

• **最安全、确认最慢：**最终确认通常比 processed 和 confirmed 晚一段时间（正常情况下约为 ~10-20 秒，因为 32 个 slot × 每个 slot ~400ms ≈ 13 秒）。这是获得 Finalized 确定性所需的代价。等待最终确认可以消除交易被丢弃或逆转的全部风险，但会增加延迟。

• **已确认 + 后续区块构建：**也可以这样理解最终确认：它是一个已被更多区块深埋的 confirmed 区块。所有诚实节点都已通过可验证方式将该区块锁定为永久账本的一部分。

Finalized 区块示例：

当网络继续生成 slot N 之后的区块时，Alice 的交易会达到 Finalized 状态。假设到 slot N+32 时，绝大多数验证者已经为直到 N+32 的每个连续区块投票，期间没有其他分叉占据主导地位，那么区块 N（包含 Alice 的交易）现在就已最终确认。 

此时，Alice 的交易在 Solana 账本中具有绝对永久性——无论她等待多久，包含该转账的状态都不会改变。 

任何要求强最终性的应用（例如交易所释放资金）现在都可以安全地依据这笔交易采取行动。需要注意的是，如果攻击者试图回滚它，就必须控制超过三分之一的质押权重并违反共识。

已弃用的承诺级别

早期版本的 Solana（2021 年之前）还公开了其他承诺级别，后来这些级别均已弃用，由上述三个级别取代。

为便于完整了解，下面列出旧术语及其与当前级别的对应关系：

• recent – 已弃用；等同于 Processed。在旧版文档中，“recent”仅指节点已知的最新状态。

• single 和 singleGossip – 已弃用；等同于 Confirmed。这些术语指由单个验证者或通过 gossip 进行的确认，与 confirmed 的定义一致。

• root 和 max – 已弃用；等同于 Finalized。“Root”指集群中已生根并最终确认的状态，“max”指最大锁定，两者实际上都表示已最终确认。

现在，开发者在指定承诺级别时应只使用 processed、confirmed 或 finalized。从 v1.5.5 开始，Solana JSON-RPC API 默认使用这些术语，并将已弃用的术语作为对应级别的别名处理。 

此外，如果 RPC 请求未指定承诺级别，默认值为 Finalized（即节点默认返回最终确认程度最高的状态）。

承诺级别之间的差异

要理解 Processed、Confirmed 与 Finalized 之间的区别，可以关注网络中有多少节点已认可该交易，以及交易被逆转的可能性。下表改编自 Solana 官方文档，总结了关键区别：

总之，Processed 只表示交易已位于某个区块中，除此之外不作任何保证。Confirmed 表示集群已就该区块达成一致（获得绝大多数投票），但它仍接近链的顶端。Finalized 表示该区块已位于链的深处并获得多次确认，深度足以使其实际上不可更改。

还可以从交易随时间推移继续保留在规范账本中的概率来理解这些差异。 

交易刚达到 processed 状态时，这个概率并非 100%，因为仍可能发生分叉或故障。一旦获得超过 66% 质押权重的确认，交易被纳入规范账本的概率就会大幅上升。当其上已构建数十个区块并达到 finalized 状态时，纳入概率约为 ~100%。 

下图对此进行了说明，展示了随着更多 slot 经过且承诺级别提高，交易最终确认概率如何上升：

交易被纳入最终规范链的可能性会随时间增加。最初在 slot n（交易已处理）时，交易仍有可能被“跳过”或因分叉而被排除。达到乐观确认（confirmed）后，随着验证者投票，交易被纳入的可能性会急剧上升。当其上构建了足够多的连续分叉区块（finalized）后，逆转概率实际上降至零。这说明承诺级别越高，回滚风险越低。

Solana 如何确定承诺级别？

了解 Solana 共识机制的“底层”运作方式，有助于理解为什么需要这些承诺级别：

历史证明（PoH）与区块生成

Solana 的 leader 会快速连续生成区块（每个 slot 一个 leader，每个 slot 约 ~400ms）。交易被流式传入历史证明（PoH）哈希链，形成区块中的条目。区块通过 Turbine（Solana 的区块传播协议）在网络中快速传播。当 leader 生成包含你交易的区块时，该区块会立即传播，但尚未获得确认，这对应 Processed 阶段。

投票（Tower BFT）

Solana 使用一种名为 Tower BFT 的 BFT 共识算法。验证者（各自控制一定质押权重）会为其认为应成为账本下一部分的区块投票。投票本身也是 Solana 交易，并包含锁定概念。每当验证者为 slot N 的区块投票时，就会产生锁定；如果它之后为冲突分叉投票，可能会在一段时间内失去投票能力。 

在同一分叉上每进行一次连续投票，锁定期就会以指数方式翻倍（锁定 1、2、4、8... 个 slot），并以 32 票为上限。如果验证者在某个分叉上连续投票 32 次（意味着 32 个 slot 前的区块仍属于最重分叉），该区块就达到最大锁定。此机制激励验证者继续支持多数分叉并最终确认区块。

确认（乐观确认）

区块生成后，验证者会广播对它的投票。一旦质押权重达到绝大多数（≥66%）的验证者为区块投票，Solana 节点就会将其视为乐观确认。这就是 Confirmed 承诺级别。由于投票通过 gossip 传播，这通常会在区块生成后的一两个 slot 内迅速完成。 

重要的是，Solana 的实现不要求等待区块在账本中生根；它会信任绝大多数投票，将其作为该区块最终会获得最终确认的乐观信号，除非行为不当的质押权重达到 <33%。 

这就是它被称为乐观确认的原因：在正常的拜占庭容错假设下（不诚实方最多占三分之一），绝大多数投票意味着该区块不会被推翻。如果某个分叉要覆盖它，必须有超过 33% 的验证者为替代链投票，这会打破上述假设。

最终确认（区块生根）

随着新区块不断生成并获得投票，每个已确认区块都会在分叉中变得更深。当某个区块在其后的连续 32 个 slot 中累积投票后，就会达到最大锁定。此时，网络会让该区块生根，将其标记为已最终确认且不可逆。最终确认意味着该区块至少落后链头 31 个区块，并且从未因其他分叉而被放弃。现在所有节点都将其视为不可变历史的一部分（截至该 slot 的账本状态被冻结）。 

类比 PoW 链，Finalized 承诺相当于“区块已获得 ≥32 次确认”，但 Solana 通过有时间锁定的投票，而不是工作量证明确认来实现这一点。32 个 slot 的规则源自 Tower BFT 的设计（锁定期不断翻倍，直至 2^32），并在三分之一容错假设下提供最终性的数学保证。

分叉选择与回滚

Solana 的共识机制会持续评估分叉。验证者使用最重分叉选择算法（基于质押投票权重）决定在哪个分叉上继续构建。如果某个区块仅由部分验证者处理且未能获得投票，其他分叉就可能覆盖它。因此，Processed 交易可能会被丢弃。 

区块获得三分之二确认后，替代分叉必须得到超过三分之一质押权重的支持才能胜出。这种情况极不可能发生，并且意味着存在恶意行为。 

最终确认后，除非发生灾难性的共识故障，否则能回退该区块的分叉实际上不可能出现。即使网络停止运行或遭受攻击，要回滚已最终确认的 slot，也需要在协议规则之外进行协调。

总结其机制：Processed = 区块已生成（PoH），但尚未得到广泛投票；Confirmed = 集群投票（Tower BFT）已对该区块达到绝大多数（乐观共识）；Finalized = 区块经过更多轮投票后持续作为链的“根”（绝对共识最终性）。Solana 的设计确保已确认区块在短暂延迟后获得最终确认，从而同时提供快速确认和最终的绝对最终性。

各承诺级别的开发者使用场景

在 Solana 上进行开发时，选择合适的承诺级别至关重要。不同应用对速度和确定性有不同要求。 

以下是每个级别的典型使用场景和最佳实践：

使用 Processed 获取即时反馈并执行非关键操作

在速度最为重要，并且可以接受一定回滚风险的场景中，开发者可能会使用 Processed 承诺。例如，在开发和测试期间，你可能希望立即确认交易已被验证者接收。 

为了改善用户体验，UI 应用（例如钱包或游戏）可以在交易完成处理后立即以乐观方式显示交易（例如显示“待处理”状态）。 

但是，由于 processed 交易不保证会保留，该级别不建议用于生产环境中的关键流程。如果使用，应仅用于低价值或非关键交易，确保潜在回滚不会造成严重问题。

大多数交易使用 Confirmed

对于 Solana 上的许多使用场景，通常建议默认使用 Confirmed 级别。它能提供有力的成功保证，同时对延迟影响很小。 

例如，执行代币兑换的 DeFi 应用或转移资金的用户通常会依赖 confirmed 状态：交易一经确认，应用就可以在正常情况下将其视为已完成。与 Processed 相比，该级别能显著降低交易被丢弃的概率。最佳实践是使用 Confirmed 承诺级别，尤其是在查询近期 blockhash 和发送交易时，因为它能更好地平衡延迟与安全性。

高价值和关键交易使用 Finalized

当场景要求绝对确定性时，例如高价值资产转移、跨链桥或交易所充值确认，开发者应使用 Finalized 承诺级别。这通常适用于无法接受任何微小回滚风险的场景。 

例如，交易所可能会等待交易最终确认后，再将充值记入用户账户，以避免后续链重组撤销充值的任何可能性。 

它也可以用于一系列交易完成之后：在将复杂操作视为完成前，确保最终状态已获得最终确认（例如需要最终账本状态的审计或结算流程）。 

开发者应注意，要求 Finalized 承诺会增加延迟，并且在网络负载较高时，可能提高交易过期的概率，因为你实际上是在等待较旧区块的哈希获得最终确认。Finalized 应谨慎使用，仅用于最关键的交易，此时额外安全性值得以延迟为代价。

总之，Processed 主要用于快速反馈和非生产环境，Confirmed 是大多数操作的首选，能够平衡安全性与性能，而 Finalized 则适用于即使需要等待也必须获得真正最终性的场景。 

许多应用会混合使用这些级别：在 Processed 时更新 UI，在 Confirmed 时将操作视为完成，并在 Finalized 时写入日志。

对交易可靠性、性能和安全性的影响

承诺级别的选择会直接影响可靠性（交易能否保留）、性能（延迟）和安全性（双花或分叉问题的风险）：

可靠性

更高的承诺级别能提高交易被永久记录的可靠性。就交易是否位于账本中而言，已最终确认的交易可靠性实际上为 100%（特殊事件除外）；已确认交易的可靠性非常高，但并非 100%；已处理交易的可靠性则更低。 

如前所述，如果仅以 processed 为准，约有 ~5% 的交易可能最终被丢弃（原因是分叉变动），而 confirmed 能将这一风险降至接近 0%。 

在关键应用中，使用 finalized 承诺可以消除交易位于后来被丢弃分叉中的风险。

性能（延迟）

确认速度与承诺级别之间存在明显的权衡。 

Processed 确认几乎是即时的（在一个区块时间内，通常不到一秒）。 

Confirmed 会增加少量延迟（大约一两个 slot，可能额外增加 ~0.5–1 秒）以收集验证者投票，但速度仍然很快，实际使用中用户通常不会察觉。 

Finalized 增加的延迟最大，因为只有在其后生成约 30 个以上的区块后，交易才会被报告为已最终确认。通常需要 ~10-20 秒才能达到最终性。 

在网络拥堵或区块生成缓慢期间，这一延迟可能会更长。因此，过度要求 Finalized 承诺会降低用户体验和吞吐量。如果应用需要等待最终确认，就必须考虑这段额外时间。但这并不表示交易本身在链上执行得更慢，只是客户端会等待更长时间来确保它已最终确认。在此期间，Solana 仍会继续处理新交易。

吞吐量与过期

另一个需要注意的影响是交易过期和 blockhash 的使用。Solana 交易包含一个近期 blockhash，并且仅在该 blockhash 之后的约 ~150 个 slot 内有效。 

如果你请求使用 finalized blockhash 签署交易，该 blockhash 会更旧（因为 finalized 落后于链头），交易过期前剩余的 slot 也会更少。如果网络拥堵且交易未能快速处理，这会提高过期概率。 

使用更新的（Confirmed）blockhash 可以获得更长的有效窗口。官方建议为 getLatestBlockhash 使用 Confirmed，以降低过期风险。 

因此，将 Finalized 用于预检或 blockhash 会略微缩短交易被接收处理的时间，从而影响高负载下的可靠性。 

简而言之，Finalized 承诺可能会在高负载期间牺牲部分活性：你获得了确定性，但如果网络接近容量上限，也可能付出交易超时增多的代价。

安全性

从安全角度来看（例如防止双花和确保分叉安全），Finalized 最为安全。 

交易一旦最终确认，逆转它就需要超过三分之一的总质押权重实施恶意行为，这种行为很可能会被发现并受到惩罚。 

在正常情况下，Confirmed 非常安全。攻击者必须创建冲突分叉，并在绝大多数节点已投票后，说服超过 33% 的验证者支持该分叉。如果没有大规模协同攻击，这种情况极不可能发生。 

不过，Confirmed 在理论上仍存在一种情况：如果略低于 33% 的验证者拒绝投票，或者分叉正处于临界点，已确认区块可能会成为孤块。但 Solana 的设计（乐观确认）以诚实多数为假设来防止这种情况。 

Processed 提供的安全性最低：在投票完成前，无法保证任何其他验证者知道这笔交易。恶意 leader 甚至可能纳入交易，却未能正确传输区块等。 

因此，任何安全关键型确认都不应依赖 Processed，它更像是一条通知，表示流程已经开始。 

总结：在抵御分叉和双花的安全性方面，Finalized > Confirmed > Processed。

读取与写入中的承诺级别使用方式

从 Solana 读取状态时（例如通过 RPC 检查账户余额），也需要指定承诺级别。如果读取时使用 Processed 承诺级别，你可能会看到非常新的数据，但这些数据可能来自尚未最终确认的分叉。使用 Finalized 读取可以获得绝对一致性（即所有节点都同意的状态），但数据可能会落后几个 slot。与交易一样，在大多数情况下，为状态查询使用 Confirmed 可以很好地取得平衡。这可以避免你依据可能回滚的分叉做出决策。 

对于写入查询（即发送交易），承诺级别主要影响客户端库等待确认的方式。常见做法是使用特定的 preflightCommitment 发送交易（可能会根据最新状态模拟 TX），然后使用相同承诺级别调用 confirmTransaction。开发者可以根据需要选择等待 finalized 确认。

用实际数字说明：根据近期测量，Solana 在约 ~0.4 秒内将交易处理到 processed 状态，在约 ~0.6 秒内达到 confirmed 状态，并在约 ~13 秒内完成 finalization。 

如果你的应用（例如支付应用）无法为每笔交易等待约 ~13 秒，应使用 confirmed，它仍能提供强大的安全保障。 

如果你要在不同链之间转移大额资产，可以选择等待完整的约 ~13 秒，以获得完全确定性。另一方面，如果你正在构建速度至关重要且可以接受少量风险的功能，例如乐观更新 UI，则可以依赖 processed 状态提供敏捷流畅的用户体验。

结论

Solana 的承诺级别——Processed、Confirmed 和 Finalized——是一项核心功能，让开发者可以针对每笔交易调整速度与确定性之间的平衡。

Processed 提供即时但不确定的结果，Confirmed 可在一两秒内提供接近最终确认的有力保证（足以满足大多数应用），而 Finalized 则会在额外等待一段时间后提供绝对最终性。 

在底层，这些级别对应 Solana 共识的推进过程：从区块生成，到绝大多数节点为其投票，再到区块以最大锁定状态在账本中生根。

在 Solana 上进行开发时，必须为具体任务选择正确的承诺级别：

• 对快速反馈或非关键操作使用较低的承诺级别
• 对同时要求速度与安全性的标准操作使用 confirmed
• 对只能接受完全最终性的场景使用 finalized

每个级别都会影响交易被可靠纳入的程度，以及你需要等待的时长。 

通过理解其技术含义（66% 投票、32 个区块、分叉、锁定）并遵循最新最佳实践，开发者既能获得 Solana 承诺的性能，又不会牺牲应用的一致性和安全性。

其他资源

• Solana 文档 – 配置状态承诺、承诺状态表
• Helius 博客 – Solana 共识（共识与最终性机制）