BSV 交易广播：从构造到提交的完整指南

先讲结论

广播交易，就是把已经构造并签名好的交易发送给交易处理服务或网络，让它被验证、传播，并最终进入区块。

在本地生成 tx hex，只说明你构造了一段交易数据。广播成功，才说明这笔交易开始进入网络处理流程。新手常把这些状态混成一个“成功”，实际开发必须分开处理。

---

创建交易不等于广播交易

手动构造交易时，需要分清以下几个状态：

• 已构造：交易对象存在。
• 已签名：inputs 有有效的 unlocking scripts。
• 已序列化：交易能表示成 raw hex。
• 已广播：交易被提交给广播服务或节点。
• 已接受：服务或网络认为交易可处理。
• 已打包：交易进入区块。
• 已证明：可以用 Merkle proof / SPV 证明交易进入某个区块。

理解这些状态有助于定位问题，比如签名失败、广播超时、打包延迟等。

---

用 SDK 广播交易

BSV SDK 的 Transaction 类提供 broadcast() 方法，可以传入不同的 broadcaster。

使用 WhatsOnChain 广播

使用 ARC 广播

不同服务需要不同配置。生产环境不要把 API key 写进代码仓库。

---

广播前要检查什么

广播前至少检查以下事项：

1. 交易已经签名
   TypeScript

   1await tx.sign()
2. 交易结构可以验证
   TypeScript

   1const ok = await tx.verify()
3. 手续费合理
   不要过低，也不要因为忘记找零而过高。
4. inputs 仍然未花费
   过期 UTXO 会导致广播失败。
5. 网络选择正确
   testnet 和 mainnet 不能混用。
6. 服务配置正确
   ARC、WhatsOnChain 或其他服务可能需要不同 endpoint、API key 或网络参数。

---

广播返回值怎么理解

SDK 的 BroadcastResponse 成功结构包含 status: "success" 和 txid。失败结构包含 status: "error"、错误码、描述和可能的 txid。

应用不能只写：

然后假设一切完成。应该读取结果：

---

广播后还要查询

广播后，交易可能需要一段时间才会被区块浏览器或查询 API 看到。官方广播教程也展示了通过 WhatsOnChain API 查询交易是否出现的模式。

应用可以查询：

• txid 是否可见。
• 是否已进入区块。
• block height。
• confirmations。
• 是否出现竞争交易或双花相关状态。

注意，区块浏览器查询不是 SPV 验证。它适合调试和状态观察，正式验证还需要学习第 9 阶段的 Merkle proof、BUMP、BEEF 和 SPV。

---

广播失败的常见原因

• 手续费太低。
• input 已经被花费。
• 签名无效。
• source transaction 或 output index 错误。
• 交易不符合服务的策略。
• 网络 endpoint 用错，例如 testnet 交易发到 mainnet。
• 广播服务不可用或认证失败。
• 交易太大、祖先交易未处理、依赖交易缺失。

这些都不是“SDK 坏了”，而是交易处理流程中的正常失败面。

---

在 BSV 技术栈里的位置

广播连接了应用侧交易构造和矿工侧交易处理。

BSV 生态里可能使用：

• 钱包服务自动广播。
• ARC 交易处理服务。
• WhatsOnChain 广播接口。
• 节点或矿工提供的接口。
• 自定义 broadcaster。

不同方式的控制权、认证、反馈信息和稳定性不同。入门阶段可以用公开教程跑通，生产阶段要选择可靠的交易处理路径，并做好状态跟踪。

---

新手常见误解

• 本地有 tx hex，不代表交易已广播。
• 广播成功，不代表交易已确认。
• txid 可查询，不代表你已经完成 SPV 验证。
• 广播失败不一定是代码语法错误，也可能是费用、UTXO 状态、网络策略或服务配置问题。
• 重试广播要做幂等设计。否则同一业务动作可能被重复提交。

---

参考来源

• Transaction Broadcasting tutorial
• ARC GitHub
• WhatsOnChain
• Transaction reference