区块链里那些看似行话的词——MUST、SHOULD、MAY——其实有一套 1997 年就定下的法律级定义。Zcash 的 ZIP、以太坊的 EIP、比特币的 BIP，乃至 Solana 的 SIMD，规范正文开头几乎都挂着一句同样的话：本文中的 MUST、SHOULD、MAY 等大写词按 BCP 14 / RFC 2119 解释。这套定义出自互联网工程任务组 1997 年 3 月的 RFC 2119，作者是哈佛的 Scott Bradner。它解决的问题很具体：当几百个独立团队各自实现同一份规范时，“必须”和”最好”不能各凭语感理解。
五个词的精确含义
RFC 2119 定义的核心梯度只有五档。MUST（等价词 REQUIRED、SHALL）是绝对要求：不满足就不是合规实现，没有商量余地。MUST NOT（SHALL NOT）是绝对禁止。SHOULD（RECOMMENDED）是强烈建议但承认例外：只有在你完全理解后果并仔细权衡之后，才可以走不同的路线——注意举证责任在偏离者一侧。SHOULD NOT 同理反向。MAY（OPTIONAL）是真可选：一个实现可以做、另一个可以不做，但两边都必须准备好与对方互操作，哪怕功能不完整。规范里还藏着一条容易被忽略的总则：这些命令词必须谨慎、节制地使用，只用在互操作或防止危害真正需要的地方，不能用来强推某种实现方式。
为什么协议文档都要引用它
一份密码学协议如果写”节点应拒绝重复的 nullifier”，不同实现会产出不同的节点；写成”MUST reject”，拒绝就是互操作底线，任何会接受它的实现都是缺陷。工程后果非常实际：钱包能不能把交易广播到任意节点的 RPC、升级后旧客户端会不会静默分叉，都取决于 MUST 与 SHOULD 在实现里被落在了哪一档。协议研究者读规范时先找的就是这个词表——一段要求如果只到 SHOULD 级，说明委员会故意留了自由裁量空间，往往意味着链上参数、默认值或兼容策略允许各客户端自行决定。
读提案时的三个易错点
第一，大小写有意义。中文翻译常把 MUST 和 should 都译成”应该/必须”，把梯度抹平了；读规范英文原文时，句中大写的 SHOULD 是有术语身份的，小写的 should 只是普通叙述。第二，这些词只描述规范要求，不描述链上现状：规范要求节点 MUST 验证证明，不等于网络上每个全节点都在实际执行这条要求，实测部署状态要另查。第三，规范词约束的是实现者，不是用户。“钱包 MAY 提示风险”意味着你可以遇到一个不带该提示的合规钱包——它是选型线索，不是安全承诺。
谱系与使用现状
RFC 2119 以 BCP 14 的形式被互联网标准长期沿用，后续文档常加一句”按 RFC 2119/8174 解释”，其中 2017 年的 RFC 8174 只是澄清了大小写敏感等解释细则，定义本身未变。加密协议社区整体继承了这套词表：ZIP、BIP、EIP 的正文模板里都有那句标准引用。这带来一个意外的好处——你可以用同一套读法横跨所有主流链的规范文档，评估某个”升级要求”到底是硬性分叉条件还是建议项，几乎不需要逐家学习新的术语。
小结
对用户而言，这套定义改变的不是操作而是判断：看到功能要求，先分清它在 MUST 档还是 SHOULD 档，再推断不兼容的代价由谁承担、你的钱包不改会怎样。规范语言不保证安全，但它诚实地标出了委员会划出的底线和留白。一个实用推论是：任何声称”完全兼容某规范”的实现，其承诺强度等于它对每一条 MUST 的实际执行程度——兼容性争议爆发时，回到规范原文数命令词，往往比看双方公告更快定位分歧到底在硬性要求还是建议项上。读协议文档时优先找 RFC 2119 引用和它的命令词，比读十篇转述文章更接近事实本身。本文只解释文档标准与阅读方法，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。