区块链/等级 IV · 深入协议/4.1 Script/课程 6
标准性与策略
网络接受的内容与你的节点转发的内容之间的差异
材料Bitcoin Core 源代码（policy/policy.cpp）Bitcoin Optech 的“Waiting for confirmation”系列一个可显示原始脚本的区块浏览器
好奇
- 为什么一笔有效的交易有时会在到达矿工之前就被钱包拒绝？
- 如果交易对手使用的软件与你的不同，但两者都是“正确的”，会发生什么？
- 将未使用的操作码挡在中继路径之外，如何能保护未来的升级？
探索
- 共识规则定义有效性，决定哪些内容可以出现在区块中并被每个节点接受。标准性则是另一套独立的本地策略，决定某个节点会向其对等节点中继哪些交易，并将哪些交易保留在其内存池中。一笔交易可能在共识层面完全有效，却按默认中继策略属于非标准交易。用户广播这样的交易时，自己的节点可能会立即将其丢弃，尽管矿工在技术上可以将其打包进区块。
- 为保护节点免受拒绝服务攻击和资源耗尽，标准输出类型受到严格限制。这些类型包括 P2PKH、P2SH、P2WPKH、P2WSH、P2TR、小型裸多签脚本（最多三个公钥），以及特定大小的 OP_RETURN 数据输出。使用保留或未知操作码、或超出大小限制的脚本，默认不会被中继。这种过滤确保内存池保持可控，并防止恶意行为者用复杂且计算成本高昂的垃圾数据淹没网络。
- 策略并非一成不变，它随各个节点实现而演变。2025年，Bitcoin Core 开发者决定放宽 OP_RETURN 数据输出的默认大小限制。这一变动在节点运营者之间引发争论，其中一些人反对这一扩展，转而使用 Bitcoin Knots 等替代软件，以维持更严格的旧有限制。这一分歧说明标准性是一项本地设置：运行不同版本或分支的两个节点，可以中继有效交易的不同子集，而不违反共识。
- 一笔非标准但有效的交易，如果完全绕过默认的中继网络，仍然可以被确认。矿工曾提供直接提交服务，让用户不受节点策略限制，将交易直接送入他们的区块。如果某个钱包依赖标准性拒绝来保障安全——假定看似无效的脚本永远不会传播——它就面临风险：能直接接触矿工的交易对手可以让该交易得到确认。这造成的是行为上的分叉，而非事实上的分叉，可能导致意外的资金转移或损失。
- 标准性是未来软分叉升级的安全阀。通过现在就执行更严格的规则——例如在中继时将预留的可升级 NOP 操作码视为非标准——协议确保在升级收紧共识规则时能够平稳过渡。由于使用这些预留操作码的交易默认不会被中继或打包，当软分叉赋予这些操作码含义时，这类交易极少甚至不存在，因此新规则不会使人们所依赖的任何东西失效，未升级的矿工也不太可能挖出被新规则拒绝的区块。
- 亲自阅读这些策略检查：在 Bitcoin Core 的源代码中，policy/policy.cpp 包含 IsStandard 和 IsStandardTx，列出了被接受的输出类型和大小限制；Bitcoin Optech 的“Waiting for confirmation”系列解释了其背后的理由。将它们与验证代码中的共识规则进行比较，注意中继规则要狭窄得多。
关键事实
- 共识规则决定了有效性；标准性则决定了中继行为。
- 标准输出类型包括 P2PKH、P2SH、P2WPKH、P2WSH、P2TR 以及小型裸多签。
- 策略通过过滤复杂或过大的脚本，保护节点免受拒绝服务攻击。
- 非标准交易可通过矿工直接提交服务来确认。
- 2025年，Bitcoin Core 放宽了 OP_RETURN 的大小限制，促使部分用户更换软件。
- 标准性会过滤预留的操作码，为未来的软分叉升级提供便利。
练习 九、六、三、一
9收集列出比特币历史上曾使用过的9种不同的输出脚本类型或格式。对于每一种，说明它目前是否被默认节点策略视为标准格式。
6归类根据结构复杂性，将这9种类型分为6类：简单密钥哈希、封装脚本、原生见证机制、复杂多方结构、数据嵌入，以及传统/实验性类型。
3提炼将这6类归纳为节点对这些特定结构施加标准性限制的3个核心原因。
1凝结写1句话，说明本地策略的差异如何导致共识有效但不符合中继规则的交易被直接发送给矿工。
事实核查
日期、数字及数据均依据下方列出的已发表资料进行核实。