运行代码优先——保护互联网原始设计所需的修补

Heng.lu 在这一系列中的前七篇笔记是：

笔记 52：当注册机构权力脱离责任：为什么现行 RIR 协调模式无法以当前形式存续
笔记 53：互联网号码资源不是政治财产
笔记 56：区域互联网注册机构的厚重治理如何把唯一性变成双重榨取
笔记 58：从双重榨取到主权倒置：国家如何因 100 美元而把主权控制交给 RIR
笔记 59：贫困惩罚：RIR 模式如何把税加在穷人身上，却称之为平等
笔记 61：对运行代码的背叛：RIR 系统如何让共识反过来对付技术社区
笔记 62：授权洗白：从 RIR 幻想到过渡架构

前七篇文章不是一套针对区域互联网注册机构的改革方案。

它们是一份尸检报告。

它们沿着不同层面追踪同一种制度病理：责任与后果脱钩；号码资源被重新命名为政治财产；唯一性变成双重榨取；主权倒置；以平等之名向贫困征税；共识被转向对付它本应服务的网络；最后，授权被洗白，直到一名行政人员听起来像主权者。这一顺序很重要，因为失败不是某个糟糕的董事会、某个糟糕的注册机构、某起诉讼或某个令人不适的市场事件。它是一个系统性缺陷以不同伪装反复出现。CircleID 的作者页面现在清楚展示了这一序列，其中包括 Running-Code Betrayal 和 Mandate Laundering。（circleid.com）

本文不是要把 RIR 变成更好的统治者。

本文要解释为什么现行注册秩序不能成为终点，以及为什么破坏性最小的修复，是对互联网原始技术设计的补充。

这个补充就是运行代码优先（Running-Code Primacy）。

其必要性已经不再是理论问题。在 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 时代的设计准则。

补丁的三条规则

建设性的语法来自修订后的笔记 64：《互联网协调系统的初始最小规范、局部化未来决策与自愿采用》：初始最小规范、局部化未来决策与自愿采用。

名称保持不变。逻辑必须精确。

初始最小规范意味着，共同层只包含唯一性、互操作性、控制证明、共享安全和安全声明所必需的确定性、本地可验证规则。它不包含商业模式偏好、定价理论、区域政治情绪、自由裁量执行权或制度使命扩张。

局部化未来决策并不意味着由某个机构决定哪些未来决策属于本地。那会重新引入权威层。它意味着，初始规范预先完成了限制工作。部署之后，普通未来决策留在运行代码的参与者手中。参与者可以采用、拒绝、分叉、断开连接或选择性互操作。任何参与者都不能改变继续运行相互兼容规则的其他参与者之间的互操作性。

自愿采用意味着，后续变化只有通过实现、验证、部署和使用才会成为现实。发布不是现实。建议不是现实。制度承认不是现实。不采用不会产生无效状态。未采用后续变化的参与者保留在现有兼容性集合中。如果某个参与者发出的状态按照另一参与者的确定性规则属于无效状态，后者可能会在本地忽略该参与者。其效果是兼容性选择，而不是制度惩罚。

这三条规则不会恢复注册机构的主权。

它们防止主权以另一种名称重新出现。

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

APNIC 展示了第一种失败：一开始从未足够严格地规定最低限度。

这不是一段行为准则的故事。不是礼仪的故事。也不是某位批评者对现任机构是否足够礼貌的故事。

这是一个法律结构的故事。

2023 年 3 月，LARUS 发布了一份法律审查，警告 APNIC 的治理结构带来的风险不仅影响布里斯班的一家公司，也影响整个亚太地区的互联网治理。审查称，APNIC 总干事拥有关闭 APNIC、罢免民选执行委员会的最终法律权力，因此亟需治理改革。审查还指出，这一结构使亚太地区超过十亿用户的互联网治理安全受到质疑。（larus.net）

第一份附件是 ASIC 摘录，提供了公司层面的基础。APNIC Pty Ltd 注册为一家按股份有限公司形式成立的澳大利亚私人公司，登记地在昆士兰。Paul Byron Wilson 列为董事和秘书。股份信息显示，已发行一股普通股，而 Paul Byron Wilson 是该股份的唯一持有人。（larus.net）

这不是承载区域互联网关键协调职能的正常形式。

第二份附件是 Peter Felter 博士的法律意见，提出了治理结论。意见把 APNIC 的公共结构——成员、选举、执行委员会、总干事和秘书处——描述为依据 APNIC Pty Ltd 公司章程第 9.3 条建立的特别委员会。意见称，25 年来，APNIC Pty Ltd 一直是一家由一名董事、一名股东和一名秘书控制的私人公司，而三者都是同一个人。（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 的成员资格；2021 年 12 月，新的取消尝试又被阻止。（btw.media）这一序列不是一个冷静保护互联网的注册机构的故事，而是注册机构权威遭遇普通司法体系的故事。

制度崩溃也不是因为注册机构权力太大。更深层的问题是结构性锁定。如果注册机构垄断了对高价值活跃资产的承认，任何内部故障都会变成互联网连续性风险。如果成员无法离开承认体系，注册机构故障就会变成扣押人质式的权力。

注册机构可以纠正自己数据中可证明的注册欺诈。

只要注册模型存在，它可以防止重复分配。

只要参与者依赖它，它可以维持安全声明。

但这些都是旧架构的过渡性职能。

在后 RIR 架构中，这些职能不由注册机构执行，而是编码在分布式账本状态、控制证明规则、冲突规则和本地可验证的转换中。

私人机构不应把租赁变成对地区的背叛。

不应把客户地理位置变成撤销触发器。

不应把商业分歧当作技术无效。

不应把资产连续性变成许可。

AFRINIC 说明了正确理解局部化未来决策的必要性。不存在一个中央机构来决定未来的商业决定“属于本地”。相反，初始规范必须确保这些决定一开始就不会进入共同层。租赁、客户地理位置、商业使用、定价、融资、客户组合和部署战略都应排除在确定性有效规则之外，除非它们直接影响唯一性、安全性、控制证明或互操作性。

运营者租赁地址，不会破坏其他运营者的互操作性。

为历史注册区域之外的客户提供服务，也不会破坏互操作性。

使用注册机构不赞成的商业模式，同样不会破坏互操作性。

在任何情况下，运营者都可能不遵守其他参与者执行的确定性规则。此时，其他参与者在本地拒绝无效状态。没有惩罚层。没有合规法庭。没有区域主权者。

这条界线不是意识形态。

它是运营性的。

代理人问题不是细节

AFRINIC 的选举争议暴露了第二个缺陷：代表权。

NRS 以直接的法律语言说明其代表基础。NRS 声称，列名成员委托 NRS 代表其处理 RIR 治理事务，并且每一名列名成员都出具了经公证的授权委托书（power of attorney）。（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 制裁透明度）

这不是批评 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 基金会和我愿意支持并资助这一方向的严肃研究。

RIR 系统在最初设计上失败，是因为它从未问过运行代码究竟需要什么。

它问的是谁可以在会议上发言。

下一个系统必须颠倒这一顺序。

不是授权洗白。

不是背叛运行代码。

运行代码优先。

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

笔记 64

摘要

本文描述一种互联网协调系统设计模式，旨在提供共享的技术参考点，而不在运行系统的参与者之上建立持续性权威。它定义三个相互关联的原则：初始最小规范、局部化未来决策和自愿采用。

在该模型中，初始规范只定义唯一性、互操作性、控制证明、共享安全和安全性所需的确定性、本地可验证规则。初始规范之后，未来变化不由中央机构批准，而是由运行代码的参与者采用、忽略、分叉或放弃。

预期的设计模式是有效状态的分布式账本，或等效的分布式可验证状态机制，而不是注册机构层级。不存在决定普通有效性的永久注册机构。参与者在本地验证状态，自愿接受交易对手，并决定运行哪些兼容性集合。

不采用不是违规。未采用后续变化的参与者保留在现有兼容性集合中。如果某个参与者发出的状态按照另一参与者接受的确定性规则属于无效状态，后者可以在本地忽略该参与者。其效果是兼容性选择、分叉、隔离或选择性互操作，而不是制度惩罚。

本文不定义网络协议（wire protocol）。它规定的是协议、标识符系统、分布式账本和协调机制的当前最佳实践（BCP），这些系统不应变成永久治理机构。

1. 引言

许多互联网系统以有限的技术目的开始：让独立参与者通过共同参考点、标识符空间、验证规则、账本状态或共享的控制证明登记册实现互操作。随着时间推移，这些系统常常积累超出初始互操作所需的权力。

这通常分三步发生。

第一，在技术上尚未必要时，就把未来问题写入基础层。

第二，本应由运行自身系统的参与者决定的事项，转而依赖永久机构的承认、解释或状态决定。

第三，即使运行系统中的参与者尚未采用变化，也把发布、登记、建议或程序批准视为足以创造运营义务。

结果是一个脆弱系统。技术参考层变成治理层。注册机构变成控制点。协调工件变成未来控制来源。

本文提出另一种设计纪律：

初始最小规范：只定义基本互操作性、唯一性、控制证明、共享安全和安全性所需的最低限度确定性共同规则。

局部化未来决策：初始规范之后，把未来决策留给运行代码的参与者。参与者可以采用、拒绝、分叉、断开连接或选择性互操作。任何参与者都不能改变继续运行相互兼容规则的其他参与者之间的互操作性。

自愿采用：让后续变化仅通过运行代码的参与者实现、运行、验证和采用而成为现实。

这些原则彼此关联。一开始规定过多的系统，会把未来控制预先装入共同层。保留持续承认层的系统，会让权威在部署后重新积累。把发布当作现实的系统，会把文档变成授权。

设计直觉很简单：有效性应由参与者可以针对共享状态在本地验证的确定性规则来决定。参与者可以采用、拒绝、分叉、断开连接或选择性互操作。最多，它只能退出某个兼容性集合。它不能因为拒绝变化，就破坏继续运行相互兼容规则的其他参与者之间的互操作性。

这是分布式账本设计的一般教训：共识规则由运行验证代码的参与者执行，由参与者决定接受哪种状态，而不是由位于其上的机构执行。

2. 范围

本文适用于互联网协调系统，包括但不限于标识符系统、名称和编号框架、协议扩展机制、控制证明系统、可移植性系统、分布式账本，以及独立行为者依赖共同技术参考点的其他架构。

本文不反对共同规则，而是主张共同规则必须是确定性的、最低限度的、可在本地验证的，并且只限于系统真正运行所需的内容。

本文不要求任何特定的分布式账本实现，而是要求一种设计属性：参与者必须能够把初始规范本地应用于共享或可复制状态，在无需向永久权威请求许可或状态的情况下确定有效性。

3. 约定与定义

3.1. 要求语言

本文中使用大写的要求术语，应按照 BCP 14，特别是 RFC 2119 和 RFC 8174 中的定义解释。

3.2. 术语

初始规范：
系统首次部署所需的规则、数据结构、格式、不变量、验证程序、状态转换规则和冲突规则集合。

共同层（Common Layer）：
独立参与者互操作所需的最低限度共享规则或参考结构。共同层不是机构，而是参与者实现和验证的技术实质。

分布式账本（Distributed Ledger）：
对状态转换进行复制或以其他方式分布的记录，使参与者无需依赖永久注册机构、委员会或其他权威即可验证普通有效性。该术语不要求任何特定共识算法或实现。

确定性验证规则（Deterministic Validation Rule）：
一条规则，使参与者能够通过本地计算或本地验证，依据规定的规则集合判断状态、记录、转换、声明或消息是否有效。

全球不变量（Global Invariant）：
为保持唯一性、基本互操作性、控制证明完整性、共享安全或安全性，兼容性集合内必须保持共同的一项属性。

参与者（Participant）：
运行、验证、部署或依赖该系统的运营者、实现、节点、网络、组织或其他行为者。

兼容性集合（Compatibility Set）：
验证规则实现允许彼此互操作的一组参与者。如果部分参与者采用后续变化而其他参与者不采用，该变化可以创建新的兼容性集合。

采用（Adoption）：
运行系统的参与者进行的实际实现、部署、验证和使用。

交易对手接受（Counterparty Acceptance）：
参与者根据其运行的验证规则，自愿决定接受另一参与者的状态、与其交易、互操作或信任该状态。

不采用（Non-Adoption）：
参与者决定不实现或不使用提议的变化。不采用不会产生无效状态，只表示参与者尚未进入该变化创建的兼容性集合。

本地拒绝（Local Rejection）：
参与者根据其运行的验证规则，忽略、拒绝或不与无效或不兼容的状态、消息、记录或转换互操作的本地决定。

分叉（Fork）：
验证规则或运营实践发生分歧，从而创建两个或更多兼容性集合。

协调工件（Coordination Artifact）：
帮助参与者协调的文件、建议、实现说明、配置文件、参考实现、账本浏览器、复制品或其他工件。协调工件只有在参与者把它采用到运行系统中时，才会形成具有约束力的实际运行状态。

4. 问题陈述

设计者常试图通过在基础层写入过多内容，或把未来问题的解释权交给永久机构，来降低未来不确定性。这看似谨慎，却常常危险。

基础层过度规定有三项成本。

第一，它把未来决策转移到共同层，而共同层更难改变，捕获的影响也更大。

第二，它在技术有效性与制度承认之间制造歧义。

第三，它会激励维护记录、发布文件或召集参与者的机构，把这些行为当作对未来现实的权威。

部署之后也会出现同样问题。如果系统需要永久机构批准变化、确定状态或解释普通运营，那么系统就创造了一个基础之后的控制层。这个层可以从管理开始，变成治理，再变成咽喉点。

本文的设计目标不是更好的制度自由裁量，而是避免自由裁量成为必要。

设计良好的互联网协调系统，应从一开始定义确定且可在本地验证的有效性规则，以分布式或可复制形式表示有效状态，把非不变量决策留在共同层之外，并让后续变化只有在参与者自愿采用到运行系统中时才成为现实。

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

5.1. 声明

初始规范应当只定义基本互操作性、唯一性、控制证明、共享安全和安全性所需的最低限度确定性共同规则。

5.2. 要求

采用这一原则的设计：

• 必须明确识别其全球不变量。
• 必须为每项全球不变量定义确定性验证规则。
• 必须定义有效状态如何表示、复制、验证和更新。
• 不得将某条规则纳入初始规范，除非该规则对于保持已声明的全球不变量或实现首次部署是必要的。
• 必须把验证规则与政策偏好、商业协议、制度角色、治理愿望和自由裁量判断分开。
• 必须允许参与者在本地验证普通有效性，而不向任何机构、注册机构、委员会、政策机构或其他权威请求信息。
• 应当定义本地验证所需的数据结构、签名、证明、状态转换规则、冲突规则或其他机制。
• 应当在未来变化可预见时，定义扩展信令、版本控制、兼容性标记或分叉识别。
• 必须确保所需协调工件可移植、可审计、可复现和可替换。
• 应当优先采用机器可验证的客观条件，而不是主观的价值判断。
• 不得把未来制度承认作为获知、登记或使用有效状态的唯一途径。

5.3. 设计含义

初始最小规范并不意味着规范含糊，而意味着只对必须共同的内容进行严格规范。

系统仍需要足够的共同结构才能运行。纪律在于区分：

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

无法清楚表达全球不变量和确定性验证规则的设计，应当假定自己规定了过多自由裁量、过少可验证实质。

6. 原则 2：局部化未来决策

6.1. 声明

初始规范之后，未来决策应当留在运行代码的参与者本地。未来决策只对采用它的参与者所在兼容性集合生效。不需要永久权威批准，不采用也不会产生无效状态。

6.2. 要求

采用这一原则的设计：

• 不得要求参与者为不改变其所属兼容性集合确定性验证规则的决定，向现任机构、注册机构、委员会、理事会、政策机构或其他权威取得许可。
• 不得创建一个永久机构，使其承认成为后续变化变成运营现实的唯一途径。
• 必须区分初始规范下的有效性与对可选后续变化的兼容性。
• 不得把不采用后续变化视为无效。
• 必须允许不采用后续变化的参与者留在现有兼容性集合中。
• 必须允许参与者通过采用新的验证规则或运营配置文件加入新的兼容性集合。
• 必须允许参与者根据其运行的验证规则，在本地拒绝无效或不兼容的状态、记录、转换或消息。
• 必须允许参与者根据其接受的验证规则和兼容性集合，自愿选择交易对手。
• 不得授权任何机构、注册机构、委员会、政策机构或其他行为者，仅仅因为参与者拒绝后续变化，就宣布其无效。
• 应当明确分叉、版本、配置文件或兼容性集合，使参与者知道运行哪些规则、可以与哪些参与者互操作。
• 应当避免采用任何使现有注册机构能够阻止仍然有效的参与者继续互操作的设计。

6.3. 设计含义

局部化未来决策并不意味着中央权威把未来决定分配给本地行为者，而是意味着系统设计使初始规范之后的普通未来决定无需这种分配。

初始规范预先完成限制工作，定义唯一性、互操作性、控制证明、共享安全和安全性所需的最低不变量，其余全部留在共同层之外。

未来变化不会由中央批准，而是由运行代码的参与者采用、忽略、分叉或放弃。

拒绝变化的参与者可以留在该变化创建的兼容性集合之外，可以与其他参与者断开连接，可以继续使用旧集合，可以分叉，也可以选择性互操作。但它不能破坏继续运行相互兼容规则的其他参与者之间的互操作性。

无效或不兼容状态的效果是本地拒绝，而不是惩罚。无需任何人认定某个参与者处于不利地位。运行兼容验证规则的参与者会直接不接受该无效或不兼容状态。

7. 原则 3：自愿采用

7.1. 声明

互联网协调系统中的变化应当通过实现、验证、部署、交易对手接受和参与者采用，成为运营现实，而不应仅仅通过发布或声明实现。

7.2. 要求

采用这一原则的设计：

• 不得把发布、建议、会议批准或程序批准视为创造普遍运营义务的充分条件。
• 必须允许参与者逐步部署其决定运行的新规则、扩展、配置文件或程序。
• 必须允许参与者拒绝后续变化而不获得无效状态，只要其自身状态转换遵守所属兼容性集合的确定性规则。
• 必须允许参与者在初始规范允许连续性的情况下继续使用旧兼容性集合。
• 必须允许在某一兼容性集合中运行的参与者，在规则不兼容时，在本地拒绝或忽略另一集合的状态。
• 应当为重大变化定义采用路径，包括版本信令、兼容性标记、过渡指南和测试向量。
• 应当为重大变化定义拒绝路径，包括不采用者如何继续运行、识别其兼容性集合以及避免歧义互操作。
• 必须确保必要协调工件可以放弃、复制、重新实现或替换，而不会产生无法承担的转换成本。
• 应当让记录、建议和协调工件描述已采用的现实，而不是试图宣布尚未采用的未来现实已经存在。
• 不得设计只有现任机构预先承认才能使变化成为现实的系统。

7.3. 设计含义

自愿采用是检验变化是否有用、可容忍且兼容真实部署的运营测试。

提案不是现实。建议不是现实。文件不是现实。现实出现在参与者实现、验证、部署、接受交易对手并依赖该变化时。

不采用不会产生违规状态，只产生一个事实：参与者尚未进入该变化创建的兼容性集合。

这并不取消标准流程、文档、实现说明、浏览器、复制品或审查，而是限制其范围。它们可以帮助参与者协调、发布参考材料、描述采用情况和提出建议，但它们不能仅凭自身的声明，就让尚未采用的未来现实对未运行它的参与者具有约束力。

8. 三项原则之间的关系

三项原则相互强化，单独使用并不有效。

初始最小规范确保共同层包含确定性验证规则，而不是自由裁量权威。

局部化未来决策确保未来决定留在运行代码的参与者手中，而不是被中央批准层重新夺回。

自愿采用确保后续变化必须经受实现、验证、交易对手接受和使用的考验。

只采用其中一两项原则的系统，可能通过其他手段重现同样的集中化。

没有局部化未来决策的初始最小规范，仍可能允许部署后权威积累。
没有初始最小规范的局部化未来决策，可能产生歧义，因为参与者无法在本地确定有效性。
没有确定性验证的自愿采用，可能产生混乱，因为参与者无法区分兼容变化与无效状态。
没有分布式状态的确定性验证，仍可能让参与者依赖特权注册机构。
没有分叉可见性的分布式状态，可能把分歧隐藏到运营失败发生时。
缺少自愿接受交易对手这一条件的分布式状态，可能通过另一接口重新引入强制。

综合起来，这些原则构成一个共同层薄、有效性可在本地验证、未来变化自愿、状态分布式且无需永久机构决定普通运营的系统。

9. 推荐的设计模式

9.1. 确定性的分布式共同层

共同层 应当仅限于：

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

共同层 不应包含：

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

9.2. 运营者决策面

以下内容应当留在共同层之外，除非其直接改变已声明的全球不变量：

• 部署时机；
• 商业使用；
• 客户地理位置；
• 租赁、融资或转让协议；
• 本地资格偏好；
• 运营时序；
• 非共享有效性所需的路由实践；
• 商业模式；
• 组织结构；
• 自愿迁移时机；
• 可选配置文件或扩展；
• 交易对手选择。

参与者可以在这些领域采取不同决定。这些决定可以产生不同的兼容性集合、商业关系、对等互联协议或运营社区，但不会产生无效性，除非它们违反某个兼容性集合内的确定性验证规则。

9.3. 采用周期

在可能情况下，重大系统变化的首选顺序是：

• 提案；
• 实现；
• 测试向量或确定性验证方法；
• 由愿意采用的参与者进行有限部署；
• 观察互操作性和安全效果；
• 标记兼容性集合；
• 发布描述已采用现实的文档或建议。

协调工件应当在采用之后跟进，而不是试图抢在采用之前出现。

9.4. 分叉、本地拒绝与交易对手接受

符合要求的设计 应当把分叉、本地拒绝和交易对手接受视为正常设计要求，而不是失败。

系统 应当定义参与者如何：

• 继续处于旧兼容性集合中；
• 采用新的兼容性集合；
• 分叉到不同兼容性集合；
• 在不依赖现任注册机构的情况下验证状态；
• 自愿接受交易对手；
• 在本地拒绝无效或不兼容状态；
• 在兼容时进行选择性互操作。

如果系统无法在不摧毁有效运营的情况下被分叉、本地验证或选择性互操作，那么它很可能把治理权力隐藏在注册职能中。

10. 适用性与边界

这种设计模式尤其适用于：

• 多参与者、多司法辖区系统；
• 独立部署很重要的系统；
• 协调层按设计应保持精简的系统；
• 未来变化可能存在但无法详细预测的系统；
• 锁定或依赖会造成治理风险的系统；
• 有效性可通过确定性规则判定或在本地验证的系统；
• 分布式状态能够降低制度俘获风险的系统。

以下情形可能不太直接适用：

• 预期架构是单一行政领域；
• 强实时耦合要求始终统一的行为；
• 生命安全要求立即实现全球一致性；
• 有效性无法通过任何实际机制在本地验证。

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

11. 非目标

本文不：

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

12. 安全考量

更薄的协调层可以降低俘获风险，缩小制度错误的影响半径，并提高可替换性。然而，更大的本地自由裁量和分布式状态也可能产生不一致的安全立场、降级路径、碎片化压力、含糊的兼容性声明、不安全分叉、账本状态争议和伪造证明的尝试。

因此，采用本文的设计者必须明确规定安全不变量。尤其是：

• 共享有效性所需的认证和授权要求必须是确定性的且可在本地验证；
• 控制证明机制必须抵抗伪造、重放和未经授权的转移；
• 当安全受到影响时，版本协商和扩展处理必须避免静默降级；
• 拒绝、分叉和替换路径必须针对滥用和拒绝服务风险进行分析；
• 兼容性标签应当足够清晰，以避免不兼容规则集合之间意外互操作；
• 分布式状态应当可审计、可复现，以发现不一致视图；
• 本地变化不得具备虚假声明与其不符合的规则集合兼容的能力。

安全例外的存在，不足以证明一般权限层合理。它只证明需要保护已声明全球不变量的确定性安全规则是必要的。

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. 和 B. Aboba，《协议扩展的设计考量》，RFC 6709。
• RFC 7282 — Resnick, P.，《关于 IETF 中的共识与哼鸣》，RFC 7282。

附录 A。设计检查清单

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

• 全球不变量是什么？
• 哪些确定性验证规则保持这些全球不变量？
• 初始规范中的哪些规则是首次部署严格必需的？
• 有效状态如何表示和验证？
• 状态是否分布式、复制或以其他方式可独立验证？
• 哪些未来问题被有意留在共同层之外？
• 参与者可以作出哪些未来决定而不改变所在兼容性集合？
• 参与者如何采用后续变化？
• 参与者如何拒绝后续变化而不被赋予无效状态？
• 兼容性集合如何标记或发现？
• 当状态根据参与者运行的规则无效或不兼容时，本地拒绝如何运作？
• 分叉路径是什么？
• 持有人如何在没有现任注册机构的情况下证明控制？
• 交易对手如何在没有注册机构的情况下验证状态？
• 参与者能否在不依赖现任注册机构的情况下验证普通有效性？
• 注册和协调工件是描述已采用的现实，还是试图宣布尚未采用的未来现实已经存在？
• 系统是否最小化了纳入共同层的决定数量？
• 系统是否避免了任何决定参与者普通状态的永久权威？
• 参与者能否自愿接受或拒绝交易对手？
• 所有现任注册机构消失后，系统能否继续？

作者地址

Lu
[TBD]