问题

业务中发送交易后，等待状态变为 confirmed 的时间较长，约 3 秒左右。

环境

• 基于 Solana Agave 部署
• 单 validator 私链

原因分析

confirmed 并不是交易立即执行的状态，而依赖 slot / vote / block commitment。

单 validator 下 confirmed 延迟原因

• processed：leader 已执行交易（最快）
• confirmed：交易所在 block 被投票确认
• finalized：达到 supermajority

单 validator 情况：

• 即便只有一个节点，也必须出 vote
• vote 是单独交易，通常在 下一个或后续 slot 才完成
• slot 时间偏大或交易量低 → vote 延迟 → confirmed 累积到 1–3 秒

即使 slot = 50ms，在低 TPS 私链下，confirmed 仍可能慢，因为 vote 被节流或跨多个 slot 才出。

解决方案

1. 客户端改用 processed

connection.confirmTransaction(sig, "processed")

或

sendAndConfirmTransaction(
  connection,
  tx,
  signers,
  { commitment: "processed" }
)

• processed 延迟：几十 ms
• confirmed 延迟：1–3 秒

单 validator 私链中，processed 基本安全，不会发生共识回滚。

---

2. 风险说明

• 唯一风险来自 节点崩溃/重启：block 未落盘 → 交易可能丢失
• 非共识风险，仅进程级别

---

3. 优化 confirmed 延迟

• 低 TPS 私链可通过增加压测交易：

  • 每个 slot 保持交易 → vote 更快产生 → confirmed 延迟缩短

• 压测交易可使用无害空交易

  • 发送 0 SOL 的转账
  • from/to 同一个账户

---

4. 综合方案（推荐）

目标：保证业务交易快速反馈，同时降低 confirmed 延迟

1. 客户端

   • 使用 commitment = processed
   • 立即返回成功，提升用户体验

2. 后台服务

   • 异步监听交易 signature
   • 等 confirmed / finalized
   • 极端情况（几秒后未 confirmed） → 补偿或重发

3. 压测优化（可选）

   • 在私链 TPS 较低时，可增加持续模拟交易
   • 每个 slot 都有交易 → vote 更快生成 → confirmed 时间缩短
   • 可使用无害空交易，不影响业务逻辑

该方案兼顾速度、确认可靠性，并可通过压测交易进一步降低 confirmed 延迟