BSV 交易序列化：从对象到广播的必经之路

先讲结论

在 BSV 应用开发中，你会用 SDK 构造和签名交易对象，但网络只接受按比特币协议编码的二进制数据。序列化就是将内存中的交易对象转换成标准字节格式（通常表示为 hex 字符串），用于广播、保存或调试。本文帮你理清序列化的核心概念、结构、SDK 用法及常见误解，让你不只“会调 SDK”，更能“读懂链上数据”。

为什么需要序列化

在代码中，你可以很直观地构建交易：

但矿工节点和广播服务并不知道你的 JavaScript 对象，它们只接受严格按规则编码的交易数据。所以最终你需要把它转成标准格式：

这个 txHex 就是交易的十六进制表示，可以在网络中传输或被区块浏览器识别。

标准交易结构

根据 BSV TypeScript SDK 文档，一个标准交易的序列化结构大致如下：

每个 input 包含：

每个 output 包含：

序列化不是随意将 JSON 字符串化，而是比特币协议定义的二进制格式。你不需要手写每个字节，但必须明白这个结构，才能理解交易是如何被编码的。

hex 是什么

hex 是十六进制字符串，一个字节用两个十六进制字符表示。比如 48 65 6c 6c 6f 就对应文本 Hello。交易 hex 就是一长串十六进制字符，区块浏览器、广播 API 和调试工具都常用它来表示裸交易（raw transaction）。

用 SDK 序列化和反序列化

SDK 提供了方便的方法：

toHex() 常用于广播、保存日志或与其他服务交互。Transaction.fromHex() 则常用于读取上一笔源交易、调试裸交易或从外部服务加载交易。

除了 hex，SDK 还支持 BEEF、Atomic BEEF 和 binary 等格式。入门阶段先掌握 raw transaction hex，后续学习 SPV、BUMP 和 BEEF 时再深入其他格式。

txid 与序列化的关系

交易 ID（txid）源自交易内容的哈希。SDK 中可用：

txid 是交易的唯一标识，当其他交易引用本交易的某个输出时，就会使用该 txid 加 output index。务必注意：一旦修改交易（如签名或调整输出），txid 就会变化，不要过早将其视为最终结果。

序列化前需要完成哪些步骤

序列化本身只是编码，不会自动保证交易有效。在调用 toHex() 前，通常要确认：

• inputs 已正确引用可花费的 UTXO
• outputs 已正确设置金额和锁定脚本
• 找零已处理
• 费用已计算
• 每个需要签名的 input 已签名
• 交易验证通过

未签名的交易同样能得到 hex，但不代表它能被网络接受。

大小端与调试

比特币交易格式中存在大小端混用的情况。比如，txid 在 raw hex 里看上去字节顺序可能反转，这是比特币交易格式的常见现象。新手阶段不必手写解析器，但遇到类似“顺序反了”的疑问时，不要惊讶，这正是调试交易构造时需要留意的地方。

在 BSV 技术栈中的位置

序列化是应用代码与网络协议之间的边界：

• 应用层操作交易对象
• 钱包层构造和签名对象
• 广播层需要发送编码后的交易
• 区块浏览器和索引服务解析编码后的交易
• SPV 和证明格式围绕交易编码、txid、Merkle path 和区块头展开

理解序列化是从“会调 SDK”迈向“能调试链上数据”的关键一步。

新手常见误解

• hex 不是加密：它只是二进制数据的文本表示。
• 能 toHex() 不代表交易有效：未签名或结构错误的交易也可以被编码。
• txid 和 raw transaction 不是同一个东西：txid 是交易内容的哈希标识。
• 修改交易后 txid 可能变化：不要过早记录 txid。
• 大小端问题会影响调试显示：不要只靠肉眼判断交易引用是否正确。

参考来源

• Transaction Encoding
• Transaction reference
• Transaction Inputs and Outputs
• Direct Transaction Creation