Note:65:运行代码优先：维护互联网原始设计所需的补丁

本序列前七篇 Heng.lu 笔记如下：

1. Note:52 当注册管理机构的权力与责任脱钩：为什么现有 RIR 协调模型无法以当前形式继续存在
2. Note:53 互联网号码资源不是政治财产
3. Note:56 区域互联网注册管理机构的厚重治理如何将唯一性变成双重榨取
4. Note:58 从双重榨取到主权倒置：国家如何为了 US$100 将主权控制权输给 RIR
5. Note:59 贫困惩罚：RIR 模型如何以平等之名向贫者征税
6. Note:61 运行代码的背叛：RIR 系统如何把共识转向对抗技术社群
7. Note:62 授权洗白：从 RIR 幻想走向过渡架构

前七篇文章并不是一套针对区域互联网注册管理机构的改革方案。 它们是一场解剖。 它们从不同层面追踪同一种制度病理：责任与后果脱钩；号码资源被重新贴上政治财产的标签；唯一性被变成双重榨取；主权被倒置；贫困以平等之名被征税；共识被转向对抗它本应服务的网络；最后，授权被洗白，直到一个文书机构开始听起来像主权者。这个序列很重要，因为失败并不是某一个糟糕的董事会、某一个糟糕的注册管理机构、某一场诉讼，或某一个令人不适的市场事件。它是同一个系统缺陷以不同外衣出现。CircleID 的作者页面如今清楚显示了这一序列，包括 Running-Code Betrayal 和 Mandate Laundering。(circleid.com) 本文不是关于如何让 RIR 成为更好的治理者。 本文要解释的是，为什么现有注册管理秩序不能成为终点，以及为什么最少扰动的修复方式，是对互联网原始技术设计作出补充。 这个补充就是 运行代码优先原则。 它的必要性已经不再只是理论。在近期一次 CircleID 交流中，John Curran 提出了现有制度立场中最强的论证。他认为，RIR 系统的权威并不只是狭义技术协调的副产品，而是一个历史链条的结果：白皮书、ICANN、ASO、ICP-2、IANA 管理权移交，以及持续的私营部门多利益相关方治理。他表示，RIR 系统的权威来自其在美国政府所指引的私营部门多利益相关方模型内运作。(circleid.com) 这个论证很有用，因为它让争议变得可见。 问题不再是历史授权是否存在。当然存在。问题是，一个历史上被授权的协调功能，是否可以后来通过它自己控制的同一套程序机器，把自己扩大成一种持续性的治理授权。现有制度的答案是可以：授权、承认、制度连续性和社区程序，成为一种自我续期的授权。 互联网原始技术设计所要求的答案是否定的。 互联网的原始传统更狭窄、更严厉，也更好。RFC 3935 说，IETF 的目标是“让互联网更好地运作”；它把工作建立在技术能力、现实世界实现，以及“粗略共识和运行代码”之上。它还指出，当 IETF 不负责某项协议或功能时，它不会试图对其施加控制。(rfc-editor.org) RFC 7282 重申了 David Clark 的老话：“我们拒绝：国王、总统和投票”，以及“我们相信：粗略共识和运行代码”。(rfc-editor.org) RFC 9592 把反主权的观点说得更清楚：IETF 不运行、不控制，也不巡逻互联网，并不是“协议警察”。(rfc-editor.org) 这一传统从来不是说文件有魔力。它的意思是，当文件帮助系统运行时，文件才重要。它的意思是，程序之所以被容忍，是因为它服务于部署。它的意思是，一个会议室只有在围绕运营现实自我约束时，才有用。 注册管理层借用了这种合法性。 但它从未完全接受这种纪律。 这就是缺失的补丁。

运行代码优先原则是什么意思

运行代码优先原则意味着，互联网协调系统必须参考运行网络最初所正当化的最低技术功能，进行狭义解释。 号码资源层存在的目的，是保护运行中的系统：唯一性、互操作性、与路由相邻的连续性、安全断言、控制权证明，以及独立网络共同工作所需的最低共同语义。 它不是为了制造政治权威而存在。 它不是为了监管商业道德而存在。 它不是为了把服务地理范围转换成所有权而存在。 它不是为了把邮件列表变成立法机构而存在。 它不是为了让私人注册管理机构因为内部政策理论改变，就让已经运行的网络资产消失而存在。 注册管理机构不是国家。 数据库联系人不是公司的授权委托书。 服务区域不是一个人民共同体。 政策会议室不是立法机构。 注册记录可以描述运营现实。它并不创造运营现实。 这不是保守主义。运行代码优先原则并不是说已部署系统永远不能改变。它说的是，对变化的制度权力，不能用历史授权、循环承认或仪式化程序来正当化。它必须由运营者可以本地验证的确定性规则，以及运行系统中的实际采用来正当化。 正确顺序是：初始规范、分布式账本状态、本地验证、运行实现、自愿采用、兼容性集合，然后才是文档。 错误顺序是：政策会议室、声明、声称义务、合规标签、强制运营合规。 RIR 系统之所以失败，是因为它越来越多地选择了第二种顺序。 关键修正是：在初始规范之后，不再有一个持续存在的机构可以请愿。没有委员会决定不采用是否构成违规。没有注册管理机构仅仅因为某个参与者拒绝后来的变更，就宣布该参与者无效。剩下的只有代码、账本状态、验证、采用、兼容性、本地拒绝、分叉，以及选择性互操作。 拒绝后续变更的运营者并不会破坏互联网。它可以留在较旧的兼容性集合中。它可以分叉。它可以断开连接。它可能无法与采用了不兼容规则的参与者互操作。但它不能破坏那些继续运行相互兼容代码的其他参与者之间的互操作性。 这个设计直觉与分布式账本之所以有用的直觉相同：普通有效性不需要一个持续存在的机构来决定。参与者根据确定性规则在本地验证状态转换。无效状态不是由机构惩罚，而是被不接受它的参与者忽略。 这正是号码资源协调中缺失的核心补丁。

设计失败从一开始就存在

最初的 RIR 设计假设的是一个低价值世界。 号码资源看起来是技术性的、充足的、文书性的、低冲突的。在那个世界里，非正式性显得高效。开放邮件列表看起来具有代表性。基于联系人的管理似乎足够。有限责任合同似乎无害。一个区域注册管理机构可以看起来像一本地址簿。 IPv4 稀缺摧毁了这个前提。 IPv4 地址变得稀缺、可转让、可融资、可租赁、可资本化、可诉讼、可制裁，并嵌入实时网络之中。注册管理层不再只是位于文书条目之上。它位于生产性基础设施之上。它位于资产价值之上。它位于客户连续性、云部署、电信运营、国家连接性、法院命令和资本配置之上。 制度形态并没有收缩，以匹配这种新的风险。 它反而扩张了。 结果是，一个系统仍然使用技术协调的语言，却产生了基础设施治理的效果。它要求运营者把注册管理程序视为中立，而注册管理决定却影响商业命运。它称参与者为“社区”，而许多承担后果的人，从未向会议室里的人提供清晰的法律代表授权。 NRS 清楚说明了这个结构性问题：互联网号码注册管理机构最初被设计为技术协调机构，但当 IPv4 稀缺使地址变成有价值的资产时，注册管理机构的自由裁量就变成了经济权力；当协调系统控制资本时，中心化就成为结构性风险，而去中心化则成为系统工程，而不是意识形态。NRS 也说明了相反的设计方向：一个互联网、开放且自治的基础设施，以及以最低人类参与为核心的去中心化治理。(nrs.help) 这才是真正的问题。注册管理层从未为协调表变成资产闸门的那一刻打上补丁。 运行代码优先原则就是这个补丁。 它不是一种更好的 RIR 教义。 它是一种后 RIR 纪律。

补丁的三条规则

建设性语法来自修订后的 Note 64：互联网协调系统的最小初始规范、本地化未来决策与自愿采用：最小初始规范、本地化未来决策、以及 自愿采用。 名称保持不变。逻辑必须精确。 最小初始规范意味着，共同层只包含唯一性、互操作性、控制权证明、共享安全和安全性所需的确定性、可本地验证规则。它不包含商业模式偏好、定价理论、区域政治情绪、自由裁量执法权，或制度使命扩张。 本地化未来决策并不是说由某个机构来决定哪些未来决策属于本地。那样已经重新引入了权威层。它的意思是，初始规范提前完成限制工作。部署之后，普通未来选择仍留给运行代码的参与者。参与者可以采用、拒绝、分叉、断开连接，或选择性互操作。任何参与者都不能改变那些继续运行相互兼容规则的其他参与者之间的互操作性。 自愿采用意味着，后来的变化只有通过实现、验证、部署和使用，才会成为现实。发布不是现实。建议不是现实。现有机构承认不是现实。不采用并不会产生无效状态。未采用后续变更的参与者仍留在其现有兼容性集合中。若某参与者发出的状态在另一参与者的确定性规则下无效，则后者可以在本地忽略它。其效果是兼容性选择，而不是制度惩罚。 这三条规则并不是为了修复注册管理机构主权。 它们是为了阻止它以新名称重新出现。

APNIC：法律结构本身就是风险

APNIC 展示了第一种失败：最小部分从一开始就没有被足够严格地规定。 这不是行为准则的故事。不是礼貌问题的故事。也不是批评者是否对现有机构足够礼貌的故事。 这是法律结构的故事。 2023 年 3 月，LARUS 发布了一份法律审查，警告 APNIC 的治理结构不仅对布里斯班的一家公司构成风险，也对整个亚太地区的互联网治理构成风险。该审查称，APNIC 的总干事拥有关闭 APNIC 和罢免民选执行委员会的最终法律权力，并认为需要紧急修改治理安排。它还指出，该结构引发了对超过十亿亚太互联网用户互联网治理安全性的疑问。(larus.net) 第一份附件，即 ASIC 公司摘录，提供了公司层面的基线。APNIC Pty Ltd 被列为一家在昆士兰注册的澳大利亚股份有限公司。Paul Byron Wilson 被列为董事和秘书。股份信息显示已发行一股普通股，Paul Byron Wilson 被列为持有该股份的成员。(larus.net) 这不是承载一个关键区域互联网协调功能的正常方式。 第二份附件，即 Dr Peter Felter 的法律意见，得出了治理结论。它把面向公众的 APNIC 结构——成员、选举、执行委员会、总干事和秘书处——描述为建立在 APNIC Pty Ltd 公司章程第 9.3 条基础上的特别委员会。它指出，APNIC Pty Ltd 25 年来一直是一家由一名董事、一名股东和一名秘书控制的私营公司，而三者均为同一人。(larus.net) 这个区别很重要。 面向公共社区的机构并不是最终法律容器。它是一座建立在私人公司结构之上的建筑。 该法律意见随后解释了为什么这个区别重要。APNIC 的附则被认为受公司章程以及公司、董事、高级职员和成员权力的约束。按照这种解读，公共 APNIC 结构可由 APNIC Pty Ltd 的董事决议改变；该意见实际上将 APNIC 描述为 APNIC Pty Ltd 的一个部门。(larus.net) 该意见最具破坏性的一点，并不是说 APNIC 在技术上违法。而是说，合法性与正当性不是同一回事。该意见认为，信托安排并未解决问题，因为执行委员会的权力仍来自设立该特别委员会的董事决议。它还指出，APNIC Pty Ltd 是一家私人股份公司，其结构和宗旨并不像大多数人会联想到的区域公共利益注册管理机构的非股份、非营利模式。(larus.net) 这就是第一种设计失败最清晰的形式。 一个区域级号码协调系统不应依赖一种需要律师解释的结构：为什么一家单股私人公司、一个特别委员会、一份信托契约和一个民选委员会，可以组合成对亚太号码注册管理机构的合法控制。 关键协调层应当从外部就能看清。 它不应要求人们信任文件背后的文件。 它不应要求成员在多年制度依赖之后才发现，民选层可能不是最终法律层。 它不应表现出成员治理的外观，却把正式权力留在别处。 这就是为什么最小初始规范必须包含分布式有效性，而不是制度信任。不是因为未来机构需要更好的治理。是因为未来的后 RIR 系统必须避免需要这个机构本身。 共同层不应依赖一家私人公司的隐藏控制结构。它应定义确定性验证规则、控制权证明状态、状态转换规则、冲突规则、账本复制、退出路径、分叉路径和兼容性集合。如果 APNIC 消失、自我捕获、改变法律姿态，或拒绝承认有效状态，运行网络不应依赖 APNIC 的持续承认来知道谁控制哪些号码资源。 注册管理机构不应成为有效性的来源。 在初始规范下验证的分布式账本状态才应是有效性的来源。

ARIN：政策遇到了资产现实

ARIN 展示了第二种失败：法律和市场现实可以超越注册管理理论。 决定性事件是 Nortel/Microsoft 交易。当 Nortel 申请破产时，其 666,624 个 IPv4 地址成为破产程序中的有价值资产。这些地址以 750 万美元出售给 Microsoft。ARIN 介入，理由是这些地址不是财产，不能脱离注册管理政策被自由清晰地出售。加拿大工业部支持这一观点。破产法院没有接受这一点；Microsoft 后来签署了遗留协议；实际结果很清楚：一旦法院和市场把号码资源视为资产，注册管理政策就不能继续成为唯一现实来源。(btw.media) 重要教训不是 ARIN 独有缺陷。 教训是，注册管理层已经进入了一个新的类别。 注册记录之所以有价值，是因为运营者、法院、买家、卖家、债权人和网络依赖它。它并不会因为否认这种依赖而变得权威。它只有在足够贴合法律、市场和运营现实时，才继续有用并值得信任。 一旦 IPv4 变得稀缺，注册管理程序就成为市场接口。转让规则、需求评估、承认延迟和区域限制不再是文书细节。它们成为资产摩擦。公开分析现在描述了一个碎片化的 RIR 规则体系：五个区域系统治理着一个每个地址约 18–45 美元交易价格的市场，而相互冲突的规则可能使资产搁浅、延迟并购，并迫使企业建立单独结构来持有号码块。(btw.media) 这不是中立协调。 这是没有监管责任的监管效果。 ARIN 证明了为什么自愿采用重要。注册管理政策只有在描述行为者实际实施、交易、融资、诉讼和依赖的现实之时，才可信。当发布被视为足以制造现实，它就会变得危险。 拒绝现实的注册管理机构不会成为主权者。 它会成为一个过时的数据库。 在运行代码优先原则的设计中，教训更尖锐。法院和市场不需要现有注册管理机构来决定价值是否存在。运营者不需要委员会来知道某个区块是否能路由。参与者需要的是允许控制权证明、冲突解决、账本可见状态转换和兼容性的确定性规则。旧注册管理机构可以发布一个视图。软件客户端可以显示一个视图。账本浏览器可以显示一个视图。没有任何一个是有效性的来源。 没有注册管理机构可以迁移过去。 没有注册管理机构需要请求。 只有一个由参与者验证、接受、拒绝、分叉或互操作的分布式状态。

AFRINIC：当注册管理理论威胁运行中的资产

AFRINIC 是核心案例，因为它把问题剥离到了本质。 错误的故事是，一个麻烦成员瘫痪了一个区域注册管理机构。 这是现有制度的道德剧本。 结构性故事不同。AFRINIC 试图把商业用途、客户地理、租赁、成员关系和内部政策解释，转换成一种声称有权注销已经运行号码资源的权力。一旦这个主张被提出，冲突就不可能继续停留在政策会议室分歧。它变成了一项测试：一个私人注册管理机构是否可以利用区域话语和政策沉默，威胁已经嵌入运营的资产。 事实不需要戏剧性膨胀。公开报道把 AFRINIC 争议描述为一场围绕 IP 地址的简单商业纠纷，后来变成非洲最大的互联网治理故事。它还报道称，Cloud Innovation 经常被描绘成反派，而后来的文件材料指向 AFRINIC 内部的破坏性力量，以及诉讼被 AFRINIC 代表以 AFRINIC 成本延迟、拖长和继续。(btw.media) 这很重要，因为它颠倒了通常的故事。 诉讼并没有创造结构性失败。 诉讼暴露了它。 相关失败早在一个私人注册管理机构把缺乏明确许可视为强制控制基础时就已经存在。租赁不是对唯一性的威胁。客户地理不是重复分配。商业用途不是路由安全失败。一个注册管理机构不喜欢的商业模式，不是全球不变量。 然而，注册管理机构的主张把这些问题放进了撤销框架。 这就是协调变成治理的时刻。 报道记录称，AFRINIC 于 2021 年 3 月向 Cloud Innovation 发函，指控其违反政策并威胁终止成员资格；2021 年 7 月，毛里求斯最高法院禁止 AFRINIC 终止 Cloud Innovation 的成员资格；AFRINIC 后续再次试图取消成员资格，也在 2021 年 12 月被阻止。(btw.media) 这个序列不是一个注册管理机构冷静保护互联网的故事。它是注册管理权威遇到普通法律的故事。 更广泛的制度崩溃也不是由于注册管理权力太少。更深层的问题是锁定。如果一个注册管理机构对有价值的实时资产拥有垄断承认权，那么每一次内部失败都会变成互联网连续性风险。如果成员无法离开这个承认系统，注册管理机构失败就会变成绑架权力。 注册管理机构可以纠正其自身记录中的可证明注册欺诈。 在注册管理模型仍然存在时，它可以防止重复分配。 在参与者仍依赖它时，它可以维护安全断言。 但这些只是旧架构的过渡功能。 在后 RIR 架构中，这些功能不是由注册管理机构执行。它们被编码进分布式账本状态、控制权证明规则、冲突规则和可本地验证转换之中。 一个私人机构不应把租赁变成区域叛国。 它不应把客户地理变成撤销触发器。 它不应把商业分歧视为技术无效。 它不应把资产连续性变成许可。 AFRINIC 证明了正确理解本地化未来决策的必要性。并不存在一个中央机构来决定某个未来商业决策“属于本地”。相反，初始规范必须确保这些决策一开始就不会进入共同层。租赁、客户地理、商业用途、定价、融资、客户组合和部署策略，都应留在确定性有效性规则之外，除非它们直接影响唯一性、安全性、控制权证明或互操作性。 运营者不会因为租赁地址而破坏其他运营者的互操作性。 运营者不会因为服务历史注册区域之外的客户而破坏其他运营者的互操作性。 运营者不会因为使用注册管理机构不喜欢的商业模式而破坏其他运营者的互操作性。 最多，运营者可能无法满足其他参与者运行的确定性规则。在这种情况下，其他参与者在本地拒绝无效状态。没有惩罚层。没有合规法院。没有区域主权者。 这条线不是意识形态。 它是运营性的。

代理问题不是细节

AFRINIC 选举争议暴露了第二个缺陷：代表性。 NRS 以直接法律语言说明其代表基础。它表示，列名成员委托 NRS 在 RIR 治理事项中代表他们，并且每一名列名成员都提供了授权委托书。(nrs.help) 在 AFRINIC 选举争议期间，NRS 要求成员报告其姓名是否出现在选民登记册上，或是否有投票记录在其未参与情况下出现，并表示此类事实报告将通过合法渠道处理。(nrs.help) 这很重要，因为它显示了法律代表与社区话语之间的差异。 RIR 系统经常把多个类别压缩成一个：公司代表、数据库联系人、技术联系人、雇员、顾问、代理持有人、政策参与者、邮件列表常客。这些不是同一件事。 数据库联系人可以协助管理记录。 授权委托书在有效且范围适当时可以授权代表。 政策参与者可以贡献专业知识。 邮件列表发言人可以表达意见。 但这些都不会自动成为每一个承担注册管理决定后果的公司、客户、国家、债权人、贷款人、买家、承租人或网络的法律委托人。 只有当共同层保持足够薄时，这种区别才可以被忽略。一旦注册管理机构声称对撤销、转让、租赁、市场准入、制裁处理、资产连续性或国家基础设施风险拥有权力，代表性就变成宪法性问题。 一个房间不是授权。 邮件列表不是人民。 联系人记录不是公司的授权委托书。 服务区域不是主权选区。 这不是程序洁癖。 这是协调与统治之间的区别。 运行代码优先系统通过减少需要代表的决策数量来避免这个陷阱。如果有效性是确定性和本地化的，就少了很多需要投票的事项。如果未来变化是自愿的，就不需要决定不采用者是否声誉不佳。如果状态表现为分布式账本，就不需要乞求现有注册管理机构承认自己的持续存在。如果兼容性集合是明确的，参与者无需询问政治会议室，就知道自己可以与谁互操作。 最好的治理问题，是系统设计本身消除掉的问题。

RIPE NCC 和 LACNIC：俱乐部与咽喉点

RIPE NCC 和 LACNIC 并不是证明某些 RIR 比其他 RIR 更文明。它们证明 RIR 模型在技术功能之外还有两个执行层：俱乐部和 咽喉点。 俱乐部决定谁是体面的。 咽喉点决定谁的注册状态可以移动。 RIPE NCC 拒绝接受 LARUS 对 RIPE 90 的赞助，清楚展示了俱乐部层。一个成员提出赞助。注册管理机构一侧的生态系统因为另一个地区无关争议而拒绝它。那不是路由安全决定。不是唯一性决定。不是确定性验证规则。那是通过会议准入进行的私人黑名单。LACNIC 也拒绝了我的赞助。不同地区，同一种本能：注册管理俱乐部通过控制房间、可见性、赞助、声誉和社会合法性来保护自己。 那不是社区。那是守门。 制裁层更糟，因为它以法律形式展示了中央咽喉点。RIPE NCC 表示，由于其设在荷兰，必须遵守欧盟制裁；当制裁适用时，它会冻结 RIPE 数据库中的注册，阻止获取和转让，并且当一方无法提供足够文件时，可能将案件视为冻结。它还筛查 OFAC 名单，因为银行关系会影响付款。(RIPE NCC sanctions transparency) 这不是批评 RIPE NCC 遵守法律。荷兰实体必须遵守荷兰和欧盟法律。问题在于架构：为什么一个荷兰私人实体应当成为跨越许多国家、运营者和法律系统的号码资源流动中央承认点？ 制裁可以约束银行。制裁可以约束荷兰实体。制裁可以约束选择不交易的相对方。它们不应成为所有其他人的全球技术有效性条件。 这就是设计失败。 使俱乐部能够排斥批评者的同一中心性，也使某个司法辖区能够冻结注册流动性。一个是社会执行。另一个是法律执行。两者之所以有效，只是因为注册管理机构位于有效性不应所在的位置。 这直接连接到三项原则。 最小初始规范：俱乐部体面性、赞助资格、区域政治、制裁分类和声誉，绝不能进入共同层。共同层只应包含唯一性、控制权证明、冲突处理、状态转换和安全所需的确定性规则。 本地化未来决策：法律风险、相对方选择、赞助、商业信任和制裁暴露，应归属于承担它们的行为者。荷兰实体可以拒绝交易。银行可以拒绝付款。相对方可以拒绝往来。但这些都不应成为普遍注册真相。 自愿采用：参与者通过运行代码、验证状态以及选择与谁互操作来接受相对方。不采用不是不当行为。本地拒绝不是全球无效。一个俱乐部的拒绝不应抹去有效状态。制裁义务应约束受其约束的行为者，而不是重写世界的号码资源账本。 这就是为什么分布式账本设计是必要的。在后 RIR 系统中，普通有效性不是由 RIPE NCC、LACNIC、制裁部门、会议委员会或赞助办公室决定。参与者在本地验证状态。相对方自愿接受或拒绝。分叉可见。兼容性集合明确。中央注册管理机构作为事实来源消失。 修复不是更好的礼仪。 修复不是更透明的制裁队列。 修复是把有效性从俱乐部和咽喉点中移除。 分布式状态。本地验证。自愿相对方接受。没有注册管理机构作为有效性来源。

NRO 信函：向上逃逸

最严肃的证据不是 AFRINIC 的企图越权。 而是系统的集体反应。 2022 年，号码资源组织写信给毛里求斯政府。该信将 NRO 描述为全球 RIR 的协调机构，并表示 RIR 在各自区域管理号码资源。信中称，五个注册管理机构都根据区域采纳的规则或一致通过的全球政策履行号码资源管理功能。(nro.net) 同一封信批评了 Cloud Innovation 的诉讼，称已提出超过 25 起诉讼，抱怨法院命令冻结 AFRINIC 账户并阻止选举，并表示 AFRINIC 曾多次要求毛里求斯承认其为国际组织。NRO 敦促政府采取措施保护 AFRINIC 的独立性和非洲互联网稳定。(nro.net) 这是整个故事中最具揭示性的文件。 当一个私人注册管理机构与普通法院发生冲突时，系统的反射动作不是缩小授权。 不是移除注册管理锁定。 不是把记录保存与执行分离。 不是定义分布式验证。 不是询问对运行中资产的单方面注销权是否从一开始就是非法正当的。 其反射动作是向上逃逸。 一个私人协调机构不能在想要自由裁量时说自己是技术性的，在想要合法性时说自己是社区性的，在想要收费时说自己是合同性的，在想要避免所有权责任时说号码不是财产，并在想要免受法院约束时说自己近似国际组织。 这一整套组合不是治理。 这是系统层面的授权洗白。 如果 RIR 想要公法特权，就必须接受公法问责。如果它们想要私法灵活性，就必须接受私法诉讼。它们不能合理地同时要求私人自由裁量、公共基础设施重要性、低责任、弱代表性、垄断地位，以及准外交豁免。 这是一条灾难路径。 运行代码优先原则拒绝它。 当注册管理机构遭遇法律阻力时，它不应向上逃向豁免。架构必须向下收缩，回到最初正当化它的狭义运行代码功能。 更少主权。 没有注册管理机构作为有效性来源。 更少执行。 更多分布式验证。

ICP-2 修订还不够

现有系统知道有东西已经坏了。 ICANN 关于第二版 RIR 治理文件草案的公众意见页面称，该提案将设定承认新 RIR 的规则和标准、RIR 的运营义务和要求，以及撤销承认规则；若被采纳，它将取代 ICP-2。该页面还称，这一过程是在 NRO 要求 ASO 提出更新建议之后启动的，目的是让 RIR 系统对互联网社区承担更大问责。(icann.org) 作为连续性措施，这可能是必要的。 但作为合法性理论，这并不足够。 承认与撤销承认规则回答的是一个较晚的问题：一个注册管理机构失败到什么程度才应被移除？ 更早的问题更重要：为什么一个注册管理机构首先应当强大到足以灾难性失败？ ICP-2 的继任文件如果只是强化承认、审计、交接和撤销承认，可能会改善制度卫生，却保留了类别错误。它仍然假定 RIR 是号码资源协调的主要主权形式。 运行代码优先原则提出的是另一组问题。 如果一个 RIR 崩溃，互联网如何继续？ 号码资源主张如何在没有现有机构许可的情况下保持可验证？ 唯一性如何在没有垄断自由裁量的情况下生存？ 记录如何避免变成执行武器？ 商业决策如何保持在确定性有效性之外，除非真正的全球不变量受到威胁？ 在根本没有权威注册管理机构的情况下，协调如何仍然可用？ 运营者如何在不向持续机构请求状态的情况下验证普通状态？ 拒绝如何避免变成违规标签？ 这些不是改革问题。 它们是后 RIR 问题。

为什么这是对原始设计的补丁

问题不是人们喜欢或不喜欢现有注册管理机构。 问题是，号码资源层是否仍然遵循让互联网运转起来的设计纪律：最低共同规则、本地验证、自愿采用和运行代码。 运行代码优先原则不是公关策略，也不是制度妥协。它是原始设计所暗示的技术修复。如果互联网的建立是为了拒绝国王、总统和投票作为技术真相来源，那么号码资源层就不能通过注册管理程序、历史授权或社区剧场来重建这些形式。 单独的共识可以被仪式化。如果注册管理层位于承认的上游，单独的运行代码也可以被从属化。缺失的规则是解释性和架构性的：当制度程序与运行系统所需的最低技术功能发生冲突时，运行代码优先；当提出后续变化时，它只有通过运行验证规则的参与者自愿采用，才成为现实。 这就是原始设计被保存的方式，而不是被抛弃的方式。 互联网之所以重要，是因为它成为第一个不需要事先获得单一主权、部门、教会、公司或守门人许可的全球通信系统。如果这一成就仍值得捍卫，注册管理层就不能成为吞噬规则的例外。 一个为避免国王而建立的系统，不能允许记账员试演国王。 这个补丁恢复了原始层级：代码优先、运营者优先、确定性验证优先、分布式状态优先；机构即使在过渡期仍存在，也只能是非权威性产物，永远不能成为有效性来源。

后 RIR 协调需要什么

后 RIR 协调并不意味着混乱。 它意味着共同层比现有 RIR 垄断更薄、更客观、更确定、更分布式。 没有注册管理机构可以迁移过去。 没有新的注册管理机构可以加冕。 没有替代祭司阶层。 只有号码资源状态的分布式账本，配合确定性验证规则、控制权证明机制、冲突处理、兼容性集合、状态转换历史，以及参与者的本地验证。 共同层应保护标识符唯一性、控制权证明、转让状态、委派状态、与路由相邻的安全断言、可审计性、冲突元数据和分叉可见性。 运营者层应控制商业用途、租赁、客户地理、路由实践、融资、相对方选择和非不变量商业规则。 采用层应决定什么成为现实。协调规则只有在运营者可以实现、相对方可以接受、市场可以依赖、法院可以理解，并且互操作性可以在不把现有承认作为唯一现实来源的情况下被保留时，才有意义。 执行层不得与状态层合并。分布式账本可以记录状态。可以验证转换。可以暴露冲突。可以使证明可携带。它不能同时成为检察官、法官、制裁机构、市场监管者、商业道德评判者和资产保管人。 最重要的是，必须正确理解可携带性。 在分布式账本世界中，可携带性并不是从一个注册管理机构迁移到另一个注册管理机构。那仍然是注册管理思维。没有注册管理机构可以迁移过去。持有者的控制权证明、状态历史和转让能力，不被困在现有数据库中。它们存在于共享可验证状态之中，由参与者本地验证，并由相对方自愿接受。 没有这一点，每一个注册管理机构都是锁定点。 有了这一点，注册管理机构作为有效性来源消失。 因此，后 RIR 协调需要四个设计属性。 第一，确定性有效性。参与者应能通过本地应用规范，知道某项状态转换、证明、委派、转让或断言是否有效。 第二，兼容性集合。如果参与者采用不同未来规则，系统应清楚描述兼容性边界，而不是把异议视为不当行为。 第三，分布式控制权证明。持有者不应把资源“迁移”到另一个注册管理机构；它应通过账本有效状态展示控制权，任何相对方都可在没有现有机构背书的情况下验证。 第四，分叉可见性。如果规则集分歧，该分歧应明确。参与者决定运行哪个兼容性集合，以及接受哪些相对方。分叉可能隔离参与者。但它不给一方制度权力去抹除另一方。 这不是为五个更好垄断辩护。 这是反对把垄断作为有效性来源。

为什么失败路径是可预测的

如果没有变化，失败路径很清楚。 第一，更多争议会从政策会议室进入法院。稀缺资产会吸引法律审查。法院会被要求冻结账户、保存记录、阻止不当选举、任命接管人、承认转让，或决定谁可以代表注册管理机构行事。 第二，国家将停止把 RIR 视为无害的技术协会。号码连续性触及国家连接性、制裁、执法、电信韧性、云基础设施和经济安全。没有国家会永远接受一个外国私人注册壳体作为国家通信连续性的未经审查上游点。 第三，运营者会在可能时绕过注册管理权威。如果注册记录变得政治化、不安全、缺乏代表性，或脱离资产现实，运营者会依靠私人合同、诉讼支持的转让、替代证明、国家承认，或事实上的路由现实。 第四，ICANN 和 NRO 层会被诱惑走向集中化。除非授权本身被缩小，否则那只会产生同一问题的更厚版本。 第五，政府会被诱惑走向国有化。这是可预测且危险的。如果私人注册管理机构声称拥有准主权权威却没有公共问责，国家最终会收回主权。结果可能是碎片化、报复、相互冲突的注册管理机构，以及政治化路由压力。 互联网并不是只有在数据包停止移动时才会失败。 当描述谁可以使用标识符的机构失去移动数据包的运营者信任时，互联网也会失败。 分布式账本无法解决所有政治问题。它做了一件更重要的事：移除持续注册管理机构作为普通有效性来源的地位。这缩小了攻击面。降低了制度绑架权力。把未来分歧变成兼容性选择，而不是行政战争。

问题发生改变

旧系统问：谁拥有授权？ 这是错误的问题。 更好的问题是：运行代码实际上需要什么？ 这条规则是否保护唯一性？ 它是否保持互操作性？ 它是否通过确定性证据纠正可证明的注册欺诈？ 它是否保护与路由相邻的安全性？ 它是否维护控制权证明准确性？ 它是否支持本地验证？ 它是否移除对单一现有机构的依赖？ 它是在描述已采用现实，还是在宣布未采用义务？ 参与者是否可以拒绝它，而不被贴上无效状态？ 参与者是否可以在不向注册管理机构请求状态的情况下验证普通有效性？ 相对方是否可以自愿接受或拒绝状态？ 分叉是否可以发生，而不让其中一方被机构抹除？ 如果答案并不与确定性运行代码必要性相关，那么这种权力就不应存在于共同层。 这就是运行代码优先原则。

供讨论

本提案供讨论。它不是最终解决方案。 下一步应是一份严肃的 Internet-Draft 或 BCP 风格文件，为互联网协调系统定义运行代码优先原则，并从号码资源开始。该草案不应询问如何修复 RIR 垄断。它应询问如何通过分布式账本状态、确定性验证、自愿采用、相对方接受和明确兼容性集合，构建后 RIR 协调。 它应由运营者、律师、经济学家、协议工程师、路由安全专家、市场参与者、政府和批评者测试。 该草案应提出严肃问题。 什么是全球不变量？ 哪些验证规则是确定性的？ 哪些状态转换必须全球可见？ 哪些旧注册管理权力只是历史残留？ 哪些决策属于运营者？ 哪些决策不需要代表性，因为它们根本不应进入共同层？ 拒绝路径是什么？ 分叉路径是什么？ 本地拒绝路径是什么？ 持有者如何在没有现有注册管理机构的情况下证明控制权？ 相对方如何在没有注册管理机构的情况下验证状态？ 如果一个 RIR 崩溃，互联网能否继续？ 号码资源能否在没有现有机构许可的情况下保持唯一？ 参与者能否在没有持续机构的情况下验证普通状态？ 政策过程能否区分运行代码不变量与制度胃口？ 旧注册管理层能否在不失去可验证状态的情况下消失？ 记录能否描述现实，而不成为现实的主权者？ 有兴趣者可通过 LinkedIn 联系我。希望协助将其发展为第一份 Internet-Draft，并在社区认为有用的情况下进一步推动为 RFC 或 BCP 讨论的严肃研究者、技术作者、机构或政策专家，欢迎联系我。LARUS Foundation 和我愿意支持并资助这一方向的严肃研究。 RIR 系统的第一版设计失败，是因为它从未询问运行代码实际需要什么。 它问的是谁可以在房间里发言。 下一个系统必须反转这个顺序。 不是授权洗白。 不是运行代码背叛。 运行代码优先原则。

附录：互联网协调系统的最小初始规范、本地化未来决策与自愿采用

Note 64

摘要

本文档描述了一种互联网协调系统的设计模式，其目的在于提供共享技术参考点，而不在运行系统的参与者之上创建一个持续存在的权威。它定义了三项相互关联的原则：最小初始规范、本地化未来决策，以及自愿采用。 在该模型下，初始规范只定义唯一性、互操作性、控制权证明、共享安全和安全性所需的确定性、本地可验证规则。初始规范之后，未来变更并不由中央机构批准。它们由运行代码的参与者采用、忽略、分叉或放弃。 预期的设计模式是有效状态的分布式账本，或等效的分布式可验证状态机制，而不是注册管理层级。不存在一个持续注册管理机构来决定普通有效性。参与者在本地验证状态，自愿接受相对方，并决定自己运行哪些兼容性集合。 不采用不是违规。未采用后续变更的参与者仍留在其现有兼容性集合中。若某参与者发出的状态在另一参与者所接受的确定性规则下无效，则该参与者可被后者在本地忽略。其效果是兼容性选择、分叉、隔离或选择性互操作，而不是制度惩罚。 本文档不定义线缆协议。它为协议、标识符系统、分布式账本和协调机制的设计规定一种最佳当前实践，尤其适用于那些不得变成永久治理机构的系统。

1. 引言

许多互联网系统起初都有狭窄的技术目的：让独立行为者通过共享共同参考点、标识符空间、验证规则、账本状态或控制权证明记录来实现互操作。随着时间推移，这些系统常常积累起初始互操作并不需要的权威。 这种情况通常分三步发生。 第一，未来问题在技术上尚无必要时就被放进创始层。 第二，本应由运行自身系统的参与者作出的选择，变得依赖于一个持续机构的承认、解释或状态决定。 第三，发布、注册、建议或程序性批准被视为足以创造运营义务，即使参与者尚未在运行系统中采用该变更。 结果是一个脆弱系统。技术参考层变成治理层。记录者变成守门人。协调产物变成未来控制的来源。 本文档提出一种不同的设计纪律：

• 最小初始规范：只规定基线互操作性、唯一性、控制权证明、共享安全和安全性所需的确定性共同规则。
• 本地化未来决策：初始规范之后，将未来选择留给运行代码的参与者。参与者可以采用、拒绝、分叉、断开连接，或选择性互操作。任何参与者都不能改变继续运行相互兼容规则的其他参与者之间的互操作性。
• 自愿采用：让后续变化只有通过运行代码的参与者实现、运行、验证和采用，才成为现实。

这些原则相互关联。一个系统若在一开始规定过多，就会把未来控制预置进共同层。一个系统若留下持续承认层，就允许权威在部署后重新出现。一个系统若把发布视为现实，就会把文档转换成命令。 设计直觉很简单：有效性必须由参与者可以针对共享状态在本地验证的确定性规则决定。参与者可以采用后续变更，拒绝它，分叉，断开连接，或选择性互操作。它最多可能把自己移出某个兼容性集合。它不能通过拒绝某项变更，破坏继续运行相互兼容代码的其他参与者之间的互操作性。 这是分布式账本设计的一般教训：共识规则由运行验证代码并决定接受何种状态的参与者执行，而不是由凌驾于他们之上的机构执行。

2. 范围

本文档适用于互联网协调系统，包括但不限于标识符系统、命名和编号框架、协议扩展机制、控制权证明系统、可携带性系统、分布式账本，以及其他独立行为者依赖共同技术参考点的架构。 本文档并不反对共同规则。它主张共同规则应当是确定性的、最小化的、本地可验证的，并限于系统实际运行所需的内容。 本文档不要求任何特定分布式账本实现。它要求一种设计属性：参与者应能够在不向持续权威请求许可或状态的情况下，通过在本地将初始规范应用于共享或可复制状态来判断有效性。

3. 约定与定义

3.1. 要求用语 本文档中的大写要求术语应按 BCP 14，尤其是 RFC 2119 和 RFC 8174 所定义的含义解释。 3.2. 术语 初始规范： 系统首次部署所需的规则、数据结构、格式、不变量、验证程序、状态转换规则和冲突规则集合。 共同层： 独立参与者实现互操作所需的最小共享规则集或参考结构。共同层不是一个机构。它是参与者实现和验证的技术实质。 分布式账本： 状态转换的复制式或其他分布式记录，使参与者能够在不依赖持续注册管理机构、委员会或其他权威的情况下验证普通有效性。该术语不要求任何特定共识算法或实现。 确定性验证规则： 使参与者能够通过本地计算或本地验证，判断某项状态、记录、转换、断言或消息在指定规则集下是否有效的规则。 全球不变量： 为了保持唯一性、基线互操作性、控制权证明完整性、共享安全或安全性，在某个兼容性集合内必须保持共同的属性。 参与者： 运行、验证、部署或依赖该系统的运营者、实现、节点、网络、组织或其他行为者。 兼容性集合： 一组参与者，其实现的验证规则允许它们相互操作。如果部分参与者采用后续变更而其他参与者不采用，则该后续变更可能创建新的兼容性集合。 采用： 运行该系统的参与者实际实现、部署、验证和使用。 相对方接受： 参与者根据其运行的验证规则，自愿决定接受、交易、互操作或依赖另一参与者状态的行为。 不采用： 参与者选择不实现或使用某项提议变更。不采用不会创造无效状态。它只意味着该参与者尚未加入由该变更创建的兼容性集合。 本地拒绝： 参与者根据其运行的验证规则，对无效或不兼容的状态、消息、记录或转换作出的本地忽略、拒绝或不互操作决定。 分叉： 验证规则或运营实践出现分歧，从而创建两个或更多兼容性集合。 协调产物： 帮助参与者协调的文档、建议、实现说明、配置文件、参考实现、账本浏览器、镜像或其他产物。除非参与者在运行系统中采用，否则协调产物不会创造有约束力的运营现实。

4. 问题陈述

设计者常常试图通过在创始层写入过多内容，或留下一个持续机构来解释未来问题，以减少未来不确定性。这看似谨慎。实际上往往危险。 创始层的过度规定有三项成本。 第一，它把未来选择移入共同层，而共同层的改变更困难，且被捕获后的影响更大。 第二，它在技术有效性与制度承认之间制造模糊。 第三，它鼓励维护记录、发布文档或召集参与者的机构，把这些行为视为对未来现实的权威。 部署后同样会出现这个问题。如果一个系统需要持续机构批准变更、决定状态或解释普通操作，那么该系统就创建了一个创始后的控制层。这个层最初可能是行政性的。它可能变成治理。之后可能变成咽喉点。 本文档的设计目标不是更好的制度自由裁量。设计目标是避免需要这种自由裁量。 一个设计良好的互联网协调系统应当从一开始定义确定性、本地可验证的有效性规则；以分布式或其他可复制形式表示有效状态；将非不变量选择留在共同层之外；并让后续变更只有在参与者于运行系统中自愿采用时才成为现实。

5. 原则一：最小初始规范

5.1. 陈述 初始规范 SHOULD 只定义基线互操作性、唯一性、控制权证明、共享安全和安全性所需的最小确定性共同规则。 5.2. 要求 采用本原则的设计：

1. MUST 明确识别其全球不变量。
2. MUST 为每个全球不变量定义确定性验证规则。
3. MUST 定义有效状态如何被表示、复制、验证和更新。
4. MUST NOT 将某条规则放入初始规范，除非该规则是为了保护某个已声明全球不变量或实现首次部署所必需。
5. MUST 将验证规则与政策偏好、商业安排、制度角色、治理抱负和自由裁量判断分离。
6. MUST 允许参与者在不询问任何机构、注册管理机构、委员会、政策机构或其他权威的情况下，在本地验证普通有效性。
7. SHOULD 定义本地验证所需的数据结构、签名、证明、状态转换规则、冲突规则或其他机制。
8. SHOULD 在可预见未来变化时，定义扩展信令、版本控制、兼容性标记或分叉识别。
9. MUST 确保所需协调产物具有可携带性、可审计性、可复现性和可替换性。
10. SHOULD 优先采用客观机器可验证条件，而不是主观优劣判断。
11. MUST NOT 使未来制度承认成为有效状态可被知晓、记录或使用的唯一路径。

5.3. 设计含义 最小初始规范并不意味着模糊规范。它意味着只严格规定必须共同的内容。 系统仍需要足够共同结构才能运行。纪律在于区分：

• 为了唯一性、互操作性、控制权证明、共享安全和安全性而必须共同的内容；以及
• 因为涉及运营者偏好、商业实践、相对方选择、部署时间或后续采用选择，而可以留在共同层之外的内容。

一个无法清楚说明其全球不变量和确定性验证规则的设计，应假定自己规定了过多自由裁量，而规定了过少可验证实质。

6. 原则二：本地化未来决策

6.1. 陈述 初始规范之后，未来决策 SHOULD 留给运行代码的参与者本地作出。未来决策只对采用它的参与者所在兼容性集合生效。不需要持续权威批准它，不采用也不会产生无效状态。 6.2. 要求 采用本原则的设计：

1. MUST NOT 要求参与者就不改变其所在兼容性集合确定性验证规则的选择，向现有机构、注册管理机构、委员会、董事会、政策机构或其他权威取得许可。
2. MUST NOT 创建一个持续机构，使其承认成为后续变更实现运营现实的唯一路径。
3. MUST 区分初始规范下的有效性与后续可选变更的兼容性。
4. MUST NOT 将不采用后续变更视为无效。
5. MUST 允许参与者在不采用后续变更时，留在现有兼容性集合中。
6. MUST 允许参与者通过采用新验证规则或运营配置文件加入新的兼容性集合。
7. MUST 允许参与者本地拒绝在其运行的验证规则下无效或不兼容的状态、记录、转换或消息。
8. MUST 允许参与者根据其接受的验证规则和兼容性集合自愿选择相对方。
9. MUST NOT 授权任何机构、注册管理机构、委员会、政策机构或其他行为者，仅因参与者拒绝后续变更就宣布其无效。
10. SHOULD 使分叉、版本、配置文件或兼容性集合明确，以便参与者知道自己运行哪些规则，以及可以与哪些其他参与者互操作。
11. SHOULD 避免任何让现有记录保存者能够阻止其他有效参与者继续互操作的设计。

6.3. 设计含义 本地化未来决策并不是说由中央权威把未来决策分配给本地行为者。它的意思是，系统被设计成在初始规范之后，普通未来选择不需要这种分配。 初始规范提前完成限制工作。它定义唯一性、互操作性、控制权证明、共享安全和安全性所需的最小不变量。其余一切都留在共同层之外。 未来变化不是中央批准的。它由运行代码的参与者采用、忽略、分叉或放弃。 拒绝某项变更的参与者可以留在该变更创建的兼容性集合之外。它可以让自己与其他人断开。它可以继续留在较旧兼容性集合中。它可以分叉。它可以选择性互操作。但它不能破坏继续运行相互兼容规则的其他参与者之间的互操作性。 无效或不兼容状态的效果是本地拒绝，而不是惩罚。无需有人决定某参与者声誉不佳。运行兼容验证规则的参与者 simply 不接受该无效或不兼容状态。

7. 原则三：自愿采用

7.1. 陈述 互联网协调系统中的变化 SHOULD 通过参与者的实现、验证、部署、相对方接受和采用而成为运营现实，而不是仅凭发布或声明。 7.2. 要求 采用本原则的设计：

1. MUST NOT 将发布、建议、会议批准或程序性批准视为足以创造普遍运营义务。
2. MUST 允许选择运行它们的参与者增量部署新规则、扩展、配置文件或程序。
3. MUST 允许参与者拒绝后续变更而不获得无效状态，只要其自身状态转换满足其兼容性集合的确定性验证规则。
4. MUST 允许参与者在初始规范允许此种连续性的情况下，继续使用较旧兼容性集合。
5. MUST 允许运行一个兼容性集合的参与者，在规则不兼容时本地拒绝或忽略来自另一兼容性集合的状态。
6. SHOULD 为重大变更定义采用路径，包括版本信令、兼容性标记、过渡指导和测试向量。
7. SHOULD 为重大变更定义拒绝路径，包括不采用参与者如何继续运行、识别其兼容性集合并避免模糊互操作。
8. MUST 确保所需协调产物可以退出、镜像、重新实现或替换，而不会产生不可能承受的过渡成本。
9. SHOULD 让记录、建议和协调产物描述已采用现实，而不是把未采用的未来现实声明成存在。
10. MUST 避免设计一种系统，其中某项变更成为现实的唯一路径是现有机构的事先承认。

7.3. 设计含义 自愿采用是检验某项变更是否有用、可容忍且与真实部署兼容的运营测试。 提案不是现实。建议不是现实。文件不是现实。当参与者实现、验证、部署、接受相对方并依赖该变更时，现实才出现。 不采用不会产生违规状态。它只创造一个事实：该参与者尚未加入由该变更创建的兼容性集合。 这并不消除标准流程、文档、实现说明、浏览器、镜像或审查。它限制它们的主张。它们可以帮助参与者协调。可以发布参考材料。可以描述采用。可以建议。但不能仅凭声明，就把未采用的未来现实强加给不运行它的参与者。

8. 三项原则之间的关系

三项原则相互强化，单独使用并不能有效发挥作用。 最小初始规范确保共同层包含确定性验证规则，而不是自由裁量权威。 本地化未来决策确保未来选择留给运行代码的参与者，而不是被中央批准层重新捕获。 自愿采用确保后续变更必须经受实现、验证、相对方接受和使用的检验。 只采用其中一项或两项原则的系统，可能通过其他方式重现同样的中心化。

• 没有本地化未来决策的最小初始规范，仍可能允许部署后权威积累。
• 没有最小初始规范的本地化未来决策，可能产生模糊，因为参与者无法本地判断有效性。
• 没有确定性验证的自愿采用，可能产生混乱，因为参与者无法区分兼容变化与无效状态。
• 没有分布式状态的确定性验证，仍可能让参与者依赖特权记录保存者。
• 没有分叉可见性的分布式状态，可能隐藏分歧，直到运营失败。
• 没有自愿相对方接受的分布式状态，可能通过另一个接口重建强制。

三者合在一起，产生一个共同层很薄、有效性可本地验证、未来变化自愿、状态分布式，且无需持续机构决定普通操作的系统。

9. 推荐设计模式

9.1. 确定性分布式共同层 共同层 SHOULD 限于：

• 稳定标识符语义；
• 确定性有效性规则；
• 保持唯一性所需的冲突解决规则；
• 控制权证明机制；
• 状态转换规则；
• 线缆级或协议级互操作要求；
• 共享安全不变量；
• 可携带且可审计的状态格式；
• 分布式或复制式状态可见性；
• 扩展信令和兼容性集合识别。

共同层 SHOULD NOT 包含：

• 商业模式规则；
• 定价规则；
• 区域政治偏好；
• 与技术不变量无关的资格意识形态；
• 自由裁量执行权；
• 主观优劣评估；
• 制度使命扩张；
• 任何主要功能是保留现有机构权威的规则。

9.2. 运营者决策界面 除非直接改变某个已声明全球不变量，以下内容 SHOULD 留在共同层之外：

• 部署时间；
• 商业用途；
• 客户地理；
• 租赁、融资或转让安排；
• 本地资格偏好；
• 运营排序；
• 共享有效性不要求的路由实践；
• 商业模式；
• 组织结构；
• 自愿迁移时间；
• 可选配置文件或扩展；
• 相对方选择。

参与者 MAY 在这些领域采用不同选择。这些选择可能产生不同的兼容性集合、商业关系、对等安排或运营社区。除非它们违反某个兼容性集合中的确定性验证规则，否则不会创造无效性。 9.3. 采用循环 在可行时，重大系统变更的优先顺序是：

1. 提案；
2. 实现；
3. 测试向量或确定性验证方法；
4. 由自愿参与者进行有限部署；
5. 观察互操作性和安全影响；
6. 兼容性集合标记；
7. 描述已采用现实的文档或建议。

协调产物 SHOULD 跟随采用，而不是试图预先取代采用。 9.4. 分叉、本地拒绝与相对方接受 符合本设计的系统 SHOULD 将分叉、本地拒绝和相对方接受视为正常设计要求，而不是失败。 系统 SHOULD 定义参与者如何：

• 继续留在较旧兼容性集合中；
• 采用较新兼容性集合；
• 分叉进入不同兼容性集合；
• 在不依赖现有记录保存者的情况下验证状态；
• 自愿接受相对方；
• 本地拒绝无效或不兼容状态；
• 在兼容性允许时选择性互操作。

如果一个系统无法在不破坏有效操作的情况下被分叉、本地验证或选择性接受，那么它很可能已经把治理权力隐藏在记录保存功能中。

10. 适用性与限制

该设计模式特别适用于以下情况：

• 系统是多行为者、多司法辖区的；
• 独立部署很重要；
• 协调层意在保持薄层；
• 未来变化可能发生但无法详细预测；
• 锁定会产生治理风险；
• 有效性可以被做成确定性或本地可验证；
• 分布式状态可以降低制度捕获风险。

在以下情况下，它可能不那么直接适用：

• 单一行政域是预期架构；
• 强实时耦合要求所有时候都保持统一行为；
• 生命安全问题要求立即全球统一；
• 有效性无法通过任何实际机制本地验证。

即使在这些情况下，设计者仍 SHOULD 尽可能最小化共同层，并避免自由裁量的未来控制。

11. 非目标

本文档并不：

• 禁止所有协调；
• 要求任何特定分布式账本实现；
• 保证共识；
• 保证政治中立；
• 要求所有参与者采用每一项后续变更；
• 把拒绝采用视为无效；
• 在声称兼容的同时，为不兼容的本地行为赋予合法性；
• 消除对安全关键共同规则的需要。

12. 安全考虑

更薄的协调层可以降低捕获风险、减少制度错误的爆炸半径，并提升可替换性。然而，更高的本地自由裁量和分布式状态也可能产生不一致的安全姿态、降级路径、碎片化压力、模糊兼容性声明、不安全分叉、账本状态争议以及伪造证明尝试。 因此，采用本文档的设计者 MUST 明确规定安全不变量。尤其是：

• 共享有效性所需的认证与授权要求 MUST 是确定性且本地可验证的；
• 控制权证明机制 MUST 抵抗伪造、重放和未授权转让；
• 版本协商和扩展处理 MUST 避免在影响安全时发生静默降级；
• 拒绝、分叉和替换路径 MUST 分析滥用和拒绝服务风险；
• 兼容性标签 SHOULD 足够清楚，以防止跨不兼容规则集的意外互操作；
• 分布式状态 SHOULD 足够可审计和可复现，以检测不一致视图；
• 本地变化 MUST NOT 被允许在不满足某规则集时，虚假声称与该规则集兼容。

安全例外的存在，并不正当化一般许可层。它只正当化为保护已声明全球不变量所必需的确定性安全规则。 13. IANA 考虑 本文档没有 IANA 操作。 14. 参考文献 14.1. 规范性参考文献

• RFC 2119 — Bradner, S., 用于 RFC 中表示要求等级的关键词, BCP 14, RFC 2119。
• RFC 8174 — Leiba, B., RFC 2119 关键词大小写歧义, BCP 14, RFC 8174。

14.2. 信息性参考文献

• RFC 6709 — Carpenter, B. and B. Aboba, 协议扩展设计考虑, RFC 6709。
• RFC 7282 — Resnick, P., 关于 IETF 中的共识与哼声表决, RFC 7282。

附录 A. 设计检查清单

声称符合本文档的设计 SHOULD 能够清楚回答以下问题：

1. 全球不变量是什么？
2. 哪些确定性验证规则保护这些全球不变量？
3. 初始规范中的哪些规则是首次部署严格必需的？
4. 有效状态如何被表示和验证？
5. 状态是否是分布式、复制式，或以其他方式可独立验证？
6. 哪些未来问题被有意留在共同层之外？
7. 哪些未来选择可由参与者作出，而不改变其所在兼容性集合？
8. 参与者如何采用后续变更？
9. 参与者如何拒绝后续变更而不被赋予无效状态？
10. 兼容性集合如何被标记或发现？
11. 当状态在参与者运行的规则下无效或不兼容时，本地拒绝如何运作？
12. 分叉路径是什么？
13. 持有者如何在没有现有记录保存者的情况下证明控制权？
14. 相对方如何在没有注册管理机构的情况下验证状态？
15. 参与者能否在不依赖现有记录保存者的情况下验证普通有效性？
16. 记录和协调产物是在描述已采用现实，还是试图把未采用的未来现实声明成存在？
17. 系统是否已最小化嵌入共同层的决策数量？
18. 系统是否避免了任何决定普通参与者状态的持续权威？
19. 参与者能否自愿接受或拒绝相对方？
20. 如果所有现有注册管理机构都消失，系统能否继续运行？

作者地址

1. Lu [TBD]