标准脚本 vs 非标准脚本：BSV 开发中容易被忽略的边界

在 BSV 开发中，有一个容易被忽略的边界：交易“理论上有效”和“现实网络会处理”不是同一件事。

一句话理解

• 标准脚本：更容易被矿工和服务接受。
• 非标准脚本：可能在共识上有效，但不一定会被转发、接受或打包。

共识规则 vs 策略规则

首先需要区分两类规则：

• 共识规则：决定一笔交易放进区块后是否有效。违反共识规则的交易会导致区块被网络拒绝。
• 策略规则（Miner Policy）：决定节点和矿工是否愿意转发、接收和打包某类交易。

简单来说：

• 共识规则：什么是绝对无效。
• 策略规则：我愿不愿意处理。

一个脚本可能不违反共识规则，但如果不符合矿工策略，交易仍可能难以广播或确认。

什么是标准脚本

标准脚本是生态中常见、被钱包和矿工普遍接受的脚本模式，例如：

• P2PKH 普通支付
• 常规 OP_RETURN 数据输出
• 被广泛支持的脚本模板

标准脚本的好处包括：

• 钱包容易生成
• 服务容易解析
• 矿工更可能接受
• 调试资料更多
• 区块浏览器显示更清楚

新手和生产应用应优先使用标准脚本或成熟协议。

什么是非标准脚本

非标准脚本可能包括：

• 很少见的操作码组合
• 过大的脚本
• 不符合当前 Miner Policy 的脚本
• 钱包和服务无法识别的自定义协议
• 超出某些服务限制的交易结构

非标准不一定等于共识无效。它可能在理论上可以被区块接受，但现实中可能：

• 没有矿工愿意打包
• 中间服务直接拒绝

为什么这对 BSV 很重要

BSV 强调 Script 能力和链上应用协议，这给开发者很大空间，但也带来风险。你可能写出一个本地验证通过的脚本，但广播时失败。原因可能不是密码学错了，而是：

• 脚本太大
• 交易太大
• 费率不符合策略
• Output 太小
• 服务不支持该脚本类型
• 矿工不接受该交易模式

这就是为什么开发 BSV 应用时，不能只看本地测试结果，还要看当前网络和矿工策略。

标准性与 SDK

使用 SDK 可以减少很多错误，但 SDK 不能保证你的业务脚本一定会被网络接受。SDK 可以帮助你：

• 构造交易
• 序列化
• 签名
• 生成常见脚本

但如果你创建自定义脚本或大数据交易，仍然要确认：

• 当前矿工是否接受
• ARC 或广播服务是否接受
• 手续费是否足够
• Output 是否符合策略
• 脚本大小和交易大小是否合理

标准性与应用协议

应用协议不一定全部放在 Script 中。有时更合理的做法是：

• 链上脚本保持简单
• OP_RETURN 或 outputs 记录数据
• 业务规则由 Overlay 验证
• 关键授权用签名表达
• 复杂查询放在应用索引层

这样可以减少链上脚本复杂度，同时保持可验证性。BSV 的技术栈不是“所有逻辑都塞进 Script”，而是 Script、交易格式、SPV、Overlay 和应用层共同配合。

如何降低非标准风险

实践上可以做以下几件事：

• 优先使用官方 SDK 和成熟模板
• 先在小额环境测试
• 阅读矿工或交易处理器文档
• 使用 ARC 等服务观察错误返回
• 控制交易大小和脚本大小
• 给数据协议加版本号
• 避免不必要的复杂脚本
• 记录 raw transaction 和错误信息

生产应用需要把广播失败当作正常情况处理，而不是假设所有交易都会被接受。

新手常见误解

• 非标准不一定等于共识无效。
• 本地脚本验证通过，不代表网络会接受。
• 标准性可能受矿工策略和服务策略影响。
• 复杂脚本不一定比简单脚本更好。
• SDK 不能替代对 Miner Policy 的理解。
• 应用层规则可以放在 Overlay 验证，不必全部写入 Script。

参考来源

• Script docs
• ARC GitHub
• Advanced Transaction Construction