什么是 Solana 上的 Preconfirmations (Preconfs)？

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

以下内容会有意聚焦于交易在领导者内部的生命周期，以及它与 Preconfirmations 和可观测性的关系。如需全面了解 Solana 上的交易生命周期，请参阅我们的 Solana 虚拟机 (SVM) 技术概览。

进入领导者之前

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

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

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

阶段 1：接收与 SigVerify

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

被接收并在 SigVerify 阶段通过签名验证的交易仅仅是候选项；每个时隙都会收到数千笔候选交易，其中许多最终无法进入区块。

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

阶段 2：调度器

区块生产发生在 Banking 阶段。自 Agave 1.18 起，其核心一直是中央调度器：一个可以全局查看所有待处理交易的调度线程，负责将工作分派给执行工作线程池。其理念是，相比 n 个线程贪婪地争抢共享队列，一个掌握完整上下文的线程可以用少得多的锁冲突来填充区块。

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

1. 缓冲与优先级排序

传入交易会进入调度器的 接收与缓冲组件，在这里计算每笔交易的优先级和成本，再将其插入按优先级排序的容器。

此时，一笔交易仍只是数千个“可能项”之一。如果缓冲区被更高优先级的任务填满，它可能会被淘汰。

2. 调度 

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

自 Agave 2.3 起，随版本发布的调度算法是贪婪调度器。测试表明，贪婪方法能够以更低开销填充区块，因此取代了早期的优先级图设计。

3. 分派 

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

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

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

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

pack tile 维护所有待处理交易，跟踪每个 bank tile 当前持有哪些账户，并选择不存在冲突且可最大化费用的交易，将其组成微区块后交给 bank tile 执行。 

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

阶段 3：执行

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

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

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

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

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

但 preconfirmation 无法告诉你，包含该交易的区块是否会成为规范链的一部分。该区块尚未被切分为 shred、传播或投票。 

因此，Preconfirmations 是一种信号，而非保证。

阶段 4：历史证明与条目

执行完毕的批次会被记录到历史证明流中，以生成条目。条目是嵌入领导者可验证时钟中的交易哈希包，也是账本的原生格式，但目前仍只存在于领导者的机器上。

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

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

阶段 5：切分 shred 与广播

条目会被切分成 shred，也就是 MTU 大小的片段，并通过纠删码实现丢失容错。这些 shred 随后会被签名，并通过 Turbine 的质押权重树广播。

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

此后，验证者会重放区块、投票，而交易会依次达到 processed、confirmed 和 finalized 承诺级别。 

Preconfirmations 位于延迟阶梯的什么位置？

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

不过，更准确的理解是：Preconfs 是延迟阶梯中的一级，每一级都通过牺牲某种完整性或确定性，换取更早的观察时机。

从最早到最晚依次为：

从这张表可以得出两点。 

第一，这些信号彼此互补，而不是直接相互替代。

例如，Preconfirmations 会在网络知晓前报告领导者刚刚执行的内容，而 LaserStream 的消息则会通过完整元数据说明发生了什么。

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

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

从 processed 流上移到 shred 只能节省个位数毫秒，而从 shred 上移到 Preconfirmations 则会跳过区块生产流水线的剩余部分（即条目记录、切分 shred 和传播），因为观察点从区块的首个公开产物移到了仅存在于领导者内部的结果。 

因此，Preconfirmations 比 shred 快约 5 到 50 毫秒。 

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

preconfirmation 所承诺的一切可以归结为一句话：领导者已执行这笔交易，并得到了这个结果。Preconf 不承诺的一切也源于同一句话。

已执行的交易尚不是已落地交易，这意味着承载它的区块还没有被切分为 shred、传播或投票。该区块在被网络确认前仍可能被跳过或因分叉而被丢弃。几乎所有经过 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，这意味着失败的交易永远不会被流式传输或计费。

定价采用点数制，与其他 Helius WebSocket 订阅一致：每条消息 10 点，每笔流式传输的交易对应一条消息，适用于 Professional 及更高级别的套餐。 

此后，每笔与筛选器匹配的已调度交易都会以紧凑的二进制帧到达。也就是一个固定的 18 字节头部，其中包含交易版本、交易调度所在的时隙、交易在该时隙中的索引及其状态，后面紧跟完整的交易字节。 

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

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

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

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

你可以用 Preconfirmations 构建什么？

在交易结果确定到被观察之间，每多一毫秒利润就会减少的任何策略，都能从 Preconfs 中获益。使用场景包括但不限于： 

抢购

新流动性池创建和代币发行会在部署交易于领导者内部执行的瞬间变得可见。使用 Preconfirmations 的抢购者可以立即响应，而监控 shred 的参与者还在等待区块的首批片段到达。 

跟单交易

领导者一执行目标钱包的操作，这些活动就会出现在 preconfirmation 流中。使用 accountInclude 按目标地址进行筛选，可将该数据流变成专用镜像源，从而比其他跟单交易者更早洞察其活动。

清算

预言机更新一旦执行，就能确定某个头寸是否已陷入资不抵债。此时看到更新的清算机器人，可以比监控 shred 或 processed 承诺的机器人提前启动整套流水线，因此 Preconfirmations 对清算活动至关重要。

做市与 propAMMs

在传入订单流执行的瞬间看到它，可以让 propAMMs 和其他报价系统率先重新定价，或在订单流公开前撤销过时报价。 

在所有场景中，Preconfirmations 都会将策略的响应点从“网络知晓之后”提前到“领导者执行的瞬间”。

通过转发 Preconfirmations 赚取收益

Preconfirmations 的覆盖范围具有网络效应，验证者位于供给侧。任何验证者都可以将自己的数据流转发给 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，你可以比全网通过 shred 或标准承诺级别的 RPC 请求观察到交易早数毫秒看到已执行交易。

Solana 中最接近 Ethereum 区块空间预留型 preconfirmation 的方案，是 Raiku 面向提前执行 (AOT) 交易的计算单元市场。它允许应用预留进入未来区块的保证名额。

结论

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

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

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