Solana 上的 Preconfirmations (Preconfs) 是什么？

领导者内部的交易生命周期

下面将刻意聚焦于领导者内部与 preconfirmations 和可观测性相关的交易生命周期。如需全面了解 Solana 上的交易生命周期，请参阅我们的 Solana 虚拟机 (SVM) 技术概述。

到达领导者之前

在 Solana 上，已签名交易会直接发送给区块生产者（即领导者）和后续领导者。交易通过 QUIC 到达，连接容量按质押权重分配，因此通过质押连接中继的交易在高负载下更有可能被接收。

此时，只有发送方以及将交易中继给当前和后续领导者的 RPC 节点或交易落地服务能够看到该交易。 

在这个阶段，交易的最终命运完全无法确定。 

阶段 1：摄取与 SigVerify

领导者的交易处理单元 (TPU)以数据包形式接收交易，对其进行反序列化、验证签名并丢弃重复项。在高负载下，格式错误的数据包和垃圾交易会在消耗更多资源前被丢弃。

被摄取并在 SigVerify 阶段通过签名验证的交易仍然只是候选项；每个时隙都会收到数千笔候选交易，其中许多永远无法进入区块。

这个阶段不存在有意义的可观测性，因为流式传输这些交易就等于流式传输噪声。 

阶段 2：调度器

区块生产发生在 Banking Stage。自 Agave 1.18 起，其核心一直是中央调度器：一个调度线程全局掌握所有待处理交易，并将工作分派给执行工作线程池。其思路是，一个掌握完整上下文的线程在打包区块时产生的锁冲突，远少于 n 个线程贪婪争抢共享队列的情况。

本质上，调度器会让交易经过三个主要步骤：

1. 缓冲与优先级排序

传入交易进入调度器的 receive and buffer 组件。系统会计算每笔交易的优先级和成本，并将其插入按优先级排序的容器中。

此时，一笔交易仍只是数千个“可能入选项”之一。如果缓冲区被更高优先级的工作填满，它就可能被逐出。

2. 调度 

调度器控制器中的控制循环会反复从容器中取出优先级最高的交易，检查是否存在账户锁冲突，并将交易分批送去执行。

自 Agave 2.3 起，默认采用的调度算法是贪婪调度器。测试表明，贪婪方法能以更低开销打包区块，因此取代了早期的 prio-graph 设计。

3. 分派 

已调度的批次会通过通道发送给执行工作线程。此时，领导者已为这笔特定交易投入实际资源，包括工作线程、账户锁以及正在组装的区块中的一个位置。

此时交易仍处于待处理状态。领导者打算执行它，但尚未实际运行，因此没有结果可供报告。Preconfirmations 会在下一步出现。

Firedancer 的调度器架构与 Agave 有何不同？

Firedancer 通过略有不同的架构到达同一节点。Firedancer 不使用共享内存的线程，而是运行通过共享内存队列连接的隔离 tile，其调度逻辑位于 pack tile 中。 

pack tile 保存所有待处理交易，跟踪每个 bank tile 当前持有哪些账户，并选择无冲突且手续费收益最高的交易组成微区块，再交给 bank tile 执行。 

这里会发生同样的移交：选中的交易从打包逻辑流向执行单元，并在那里确定结果。

阶段 3：执行

Agave 中的工作线程或 Firedancer 中的 bank tile 会基于当前 bank 执行已调度的交易批次，包括加载账户、运行程序和提交结果。

已调度交易也可能在此因多种原因失败，包括余额不足、程序错误、滑点检查回滚或其他运行时条件。无论结果如何，此时它都只存在于领导者的机器本地。

preconfirmation 正是在这一刻发出。领导者会在每笔交易执行完成的瞬间将其与状态一起流式传输，此时结果尚未记录到条目中，距离任何区块数据离开机器还早得多。

这是整个生命周期中交易结果首次既已存在又可报告的时刻。执行之前只有一组没有结果可供传输的待处理候选项；执行之后，信息已经开始被打包进区块，并向网络其余部分快速传播。

因此，执行阶段是这类早期信号唯一可能存在的位置。这也解释了为什么每条 preconfirmation 携带的都是交易的实际结果，而不是预测。

但 preconfirmation 无法告诉你，包含该交易的区块最终是否会成为规范区块。该区块尚未切分为数据分片、传播或接受投票。 

因此，preconfirmations 是一种信号，而不是保证。

阶段 4：历史证明与条目

已执行的批次会被记录到历史证明流中以生成条目。条目是由交易组成的哈希数据包，会被编织进领导者的可验证时钟。条目是账本的原生格式，但目前仍只存在于领导者的机器上。

对于领导者之外的任何人来说，此时的可观测性实际上为零。

请注意，Alpenglow 更新将移除历史证明，因为 Rotor 和 Votor 让 Solana 不再需要去中心化时钟。preconfirmation 模型不受影响：领导者仍会先执行交易，再将其传播出去，因此最早可观察的信号仍是领导者的本地执行结果。 

阶段 5：切分与广播

条目会被切成数据分片，即采用纠删码以提高丢失容错能力的 MTU 大小片段。这些数据分片会经过签名，并通过 Turbine 的质押权重树广播。

可观测性的大门在这里完全打开。数据分片是特定区块中首个离开领导者机器的产物，因此 Solana 上包括数据分片流在内的所有其他早期数据产品都从这里开始。相较于 RPC 确认级别，从数据分片重建交易已经很快；但相较于 preconfirmation 仍然更晚，因为领导者在数据分片出现前就已执行交易。 

之后，验证者会重放区块、投票，交易也会逐步达到 processed、confirmed 和 finalized 确认级别。 

preconfirmations 位于延迟阶梯的哪个位置？

与包括原始和已解码数据分片、LaserStream 及其他数据流方法在内的所有信号相比，Preconfirmations 是 Solana 上最快的信号。 

不过，理解 preconfs 的最佳方式，是将其视为延迟阶梯中的一级：每向上一级，都会用某种完整性或确定性换取更早的观察时间。

从最早到最晚依次为：

从此表可以得出两个结论。 

第一，这些信号彼此互补，而不是严格意义上相互替代。

例如，preconfirmations 会在网络得知之前报告领导者刚执行的内容，而 LaserStream 消息则会提供事件的完整元数据。

生产系统通常需要同时使用两者：根据 preconfirmations 采取行动，再用下游信号进行验证。  

第二，各级之间的时间差并不均匀。

从 processed 流向上跨越到数据分片，只能节省个位数毫秒；而从数据分片向上跨越到 preconfirmations，则会跳过区块生产流水线的其余部分（即条目记录、数据切分和传播）。这是因为观察点从区块的首个公开产物，移到了只存在于领导者内部的执行结果。 

因此，preconfirmations 比数据分片快约 5 到 50 毫秒。 

Preconfirmations 信任模型：信号，而非保证

preconfirmation 承诺的一切可以浓缩成一句话：领导者已经执行了这笔交易，并得到了这个结果。preconf 不承诺的一切也源于同一句话。

已执行的交易尚不等于已落地的交易，这意味着承载该交易的区块尚未被切分为数据分片、传播或接受投票。该区块仍可能在获得网络确认前被跳过或从分叉中移除。几乎所有获得 preconfirmation 的交易最终都会成功上链。但是，任何基于 preconfirmations 采取行动的系统都必须通过其他可观测性检查确认结果，然后才能将其视为最终结果。

覆盖范围在设计上也是不完整的。Preconfirmations 仅存在于其领导者将已调度交易流转发给 Helius 的时隙。因此，覆盖范围会随参与网络质押份额的增加而扩大，数据流也不一定连续。

如果服务必须获得绝对保证的连续覆盖，则应考虑在出现空档时回退到 LaserStream 或 Shred Delivery。

由于 preconfirmations 在执行后发出，订阅者看到的是已经确定的结果，而不是等待利用的待处理订单流。这意味着，在区块内抢到该交易之前的机会窗口已经关闭。这正是出售早期可见性与泄露调度前订单流之间的关键区别：前者让订阅者比网络其余部分更快响应，后者则会让他们针对正在传输的交易本身采取行动。Preconfirmations 严格属于前者。

这一信号如实反映自身性质：preconfirmation 没有任何经济承诺作为担保，也从未声称有此类担保。领导者会报告其本地结果，但不会为后续执行质押任何资产。对于 preconfirmations 所服务的策略而言，这是正确的权衡。

例如，清算机器人并不需要一项绝对可靠、可罚没且保证交易落地的承诺；它需要的是比竞争对手提前几毫秒知道特定交易的结果。

Helius Preconfirmations 如何工作？

Helius Preconfirmations 通过单个 WebSocket 订阅交付。客户端可以连接到我们的 Gatekeeper 端点（即 wss://beta.helius-rpc.com），并发送 preconfSubscribe 请求：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

筛选器由服务器端根据账户（即包含、排除、必需）、区域和状态应用，并支持查找表 (LUT)，因此订阅者只会收到与其策略相关的已调度交易，也只需为这些交易付费。 

由于 preconfirmations 在执行后发出，状态筛选器处理的是真实结果。设置 failed: false 后，失败交易不会被交付，也不会按消息收费。

Preconfirmations 适用于 Helius 的所有付费计划：Developer、Business、Professional 和 Enterprise。未交付任何消息的时隙不消耗积分。当一个时隙至少交付一条消息时，每个打开的 preconfSubscribe 订阅将按 300 积分或每条已交付消息 10 积分中的较高者计费。

之后，每笔符合筛选条件的已调度交易都会以紧凑二进制帧形式到达。该帧包含固定的 18 字节标头，其中记录交易版本、交易被调度到的时隙、交易在该时隙内的索引和状态，后面紧跟完整的交易字节。 

这种格式刻意保持精简，因为固定标头可以在纳秒内完成解码，无需在热路径中解析 JSON。为方便起见，此交互中唯一需要的 JSON 是订阅确认消息。 

请注意，preconfirmation 只完成了交易的一半。只有响应也能率先落地，率先看到交易才有意义。为此，我们还推出了 Sender Max，这是性能最高的 Helius Sender 层级。

Sender Max 会通过所有可用的高速路径发送一次提交（即单笔交易或最多包含四笔交易的原子捆绑包），并进入优先小费缓冲区，其中小费最高的提交优先。最低小费为 0.001 SOL。

使用 preconfSubscribe 获取信号，使用 Sender Max 让交易落地。  

你可以使用 preconfirmations 构建什么？

从交易结果确定到被观察到的这段时间里，利润每过一毫秒都会降低的策略，都能从 preconfs 中受益。用例包括但不限于： 

抢购

新的流动性池创建和代币发行会在部署交易于领导者内部执行的瞬间变得可见。使用 preconfirmations 的抢购者已经开始响应，而监控数据分片的人仍在等待区块的首批片段到达。 

跟单交易

目标钱包的动向会在领导者执行交易的瞬间出现在 preconfirmation 流中。使用 accountInclude 按目标地址筛选，可以将数据流变成专门的镜像信息流，在其他跟单交易者之前洞察其动向。

清算

将仓位推入资不抵债状态的预言机更新，在执行瞬间即可获知。在此时看到更新的清算机器人，会比监控数据分片或 processed 确认级别的机器人提前启动整条流水线，因此 preconfirmations 对清算活动极为重要。

做市和 propAMMs

在执行瞬间看到传入流量，可以让 propAMMs 和其他报价系统提前重新定价，或在流量公开前撤下过时报价。 

在所有情况下，preconfirmations 都会将策略的响应点从“网络得知之后”提前到“领导者执行的瞬间”。

通过转发 Preconfirmations 获得收益

Preconfirmation 的覆盖范围具有网络效应，而验证者位于供给侧。任何验证者都可以将其数据流转发给 Helius 并从中获得收入，将区块生产的副产品转化为收入来源，无论该验证者是否通过其他方式将其位置变现。

参与的质押份额越多，覆盖范围就越广。有意参与的验证者可以联系我们，并在我们的面向验证者的 preconfirmations 文档中了解更多信息。 

Ethereum preconfs 与 Solana preconfs 有何区别？

Ethereum preconfirmations 是提议者承诺，保证交易将进入未来区块；Solana preconfirmations 则是实时链上交易信号，适用于领导者刚刚在本地为当前区块执行的交易。前者关注更早确定，后者关注更早看到。

Ethereum Preconfirmations

在 Ethereum 上，preconfirmations 在研究文献中通常写作 based preconfs。这一设计由 Justin Drake 于 2023 年首次提出，本质上是一种纳入承诺。提议者会在自己的时隙到来前，提前承诺将某笔交易纳入未来区块，并通过罚没等经济机制为该承诺提供担保。 

目前已有多个实际运行的实现： 

• Primev 的 MEV-Commit：一个由钱包、搜索者和意图协议向执行提供商（即区块构建者和排序器）竞价购买承诺的市场
• ETHGas：一个有经济担保的 preconfirmation 网络
• Chainbound 的 Bolt：提供无需许可且兼容 MEV-Boost 的提议者承诺

最重要的是，Ethereum preconfirmations：

• 针对你自己的交易
• 在执行之前发出
• 针对确定性优化

Ethereum preconfirmations 会在你的交易实际落地前，保证它将会落地。

Ethereum 之所以需要这套机制，是因为其区块构建方式。大多数提议者会通过 MEV-Boost 在最后一刻拍卖区块构建权，因此在拍卖结束前，无法对区块内容作出可信承诺。但 Solana 从未存在这一空档。领导者调度表提前已知，没有内存池，而且一个领导者会在时隙内持续接收、排序、执行并流式传输其区块。Ethereum 必须用经济机制构建的早期信号，原生存在于 Solana 的区块生产流水线中，只需将其公开即可。

Solana Preconfirmations

Solana preconfirmations 是实时链上信号，而不是对未来的承诺：领导者会在交易传播到网络其余部分前，报告其已经执行的交易。

最重要的是，Solana preconfirmations：

• 包含所有人的交易
• 在执行之后发出
• 针对延迟优化

Solana preconfirmations 让你可以比数据分片或标准确认级别的 RPC 请求提前几毫秒看到已执行交易。

在 Solana 上，与 Ethereum 区块空间预留式 preconfirmation 最接近的是 Raiku 为 Ahead-of-Time (AOT) Transactions 提供的计算单元市场，它允许应用预留未来区块中的保证纳入资格。

总结

Solana 上的每笔交易都会经历一个命运从未知转为确定的时刻：领导者执行它的瞬间。Preconfirmations 就是对这一时刻的流式传输，早于网络其余部分看到交易。它们在延迟阶梯上位于数据分片之上，因为观察的是领导者的执行结果，而不是区块的公开产物。Preconfirmations 是信号，而不是保证，因为只有获得网络确认后，区块才会被视为规范区块。

对于抢购者、跟单交易者、清算者、做市商和搜索者等对延迟敏感的系统，请使用 preconfSubscribe 订阅，筛选重要账户，通过 Sender Max 响应信号，并使用标准确认检查进行验证。

完整的订阅参考、消息格式和集成示例均可在我们的 preconfirmations 文档中查看。