将数据写入 BSV 区块链：从 OP_RETURN 到应用协议

BSV 交易不止能转移 satoshis。通过数据输出，你可以在链上记录文本、哈希、协议字段或业务事件。第一笔 Hello BSV! 交易的意义就在于此：它展示了交易既可以表达支付，也可以表达可验证的数据记录。

数据输出 vs 支付输出

普通支付输出表达“未来谁可以花这笔钱”，其锁定脚本常见形式为 P2PKH 或其他可花费脚本。

数据输出则关注“把什么数据记录到交易中”。常见做法是使用 OP_RETURN，这类输出通常不用于未来花费，而是承载数据。

简化对比：

官方第一笔交易教程中，示例用 OP_RETURN 写入 Hello BSV!。

使用 SDK 构造 OP_RETURN

在 SDK 中，可以用 Script.fromASM() 从 ASM 形式创建脚本：

代码分三步：

1. 将文本转为字节：Buffer.from(message)
2. 将字节表示为十六进制字符串：toString('hex')
3. 将 OP_RETURN 和数据组合成脚本，再转成 hex：Script.fromASM(...).toHex()

然后将此脚本放入 createAction() 的 outputs：

这就是“将数据输出到链上”的最小路径。

为什么要转成十六进制

链上交易并非保存“人类可读字符串”的文档系统。交易脚本处理的是字节数据，十六进制是常用的字节表示方式。

Hello BSV! 在代码里是字符串，但放入脚本时须变为字节序列。区块浏览器可能会将这段数据解析回文本，也可能只显示十六进制。

因此新手需区分三个层次：

理解这一点后，再看各种链上协议字段会容易许多。

从自由文本到应用协议

第一笔交易写 Hello BSV! 适合入门，但真实应用不应停留在自由文本。

若要在链上记录文章、凭证、订单、供应链事件或 token 状态，最好设计结构化协议。一个简单数据输出可包含：

• 协议标识
• 协议版本
• 内容类型
• 数据哈希
• 业务字段
• 签名或身份信息
• 指向链下大文件的引用

示例：

这不是固定标准，只是说明思路。链上数据应让别人能解析、验证、索引，协议设计比“能写进去”更重要。

在 BSV 技术栈中的位置

BSV 技术路线强调低费用、大容量和链上数据应用。数据输出是众多应用协议的基础，包括内容发布、凭证、证书、供应链事件、token 元数据和审计记录。

但链上数据不等于将所有东西盲目塞进交易。成熟应用通常组合使用：

本文聚焦最简单的数据输出，后续阶段会进一步展开应用数据协议。

隐私与不可逆

链上数据应默认视为公开、可复制、难以撤回。

不要将身份证号、手机号、未加密私密文本、商业秘密或用户未授权公开的数据直接写入 OP_RETURN。

若必须证明某份隐私数据存在，可写入哈希而非明文。哈希能证明某个数据版本存在过，但不会直接暴露原文。

若需加密，也要谨慎设计密钥管理。加密数据上链后，即使当前不可读，未来密钥泄露也可能导致内容被读取。

新手常见误解

• 能写数据并不代表数据有业务意义。没有协议标识和字段规范，别人很难正确解析。
• OP_RETURN 数据输出通常不是为了未来花费，它与普通支付输出的用途不同。
• 区块浏览器能看到数据，不代表你的应用已完成索引——应用还需自己的查询方式。
• 链上数据不是私有数据库，公开数据要优先考虑隐私与合规。
• 写入数据不等于自动获得可信来源，可信度来自签名、身份、协议和验证逻辑。

参考来源

• First Transaction tutorial
• Script docs
• Overlay Services docs
• Script Templates concept