随笔65：运行代码优先——守住互联网原始设计所需的补丁
哪一个补丁能在注册层恢复互联网的原始设计？
每个参与者都能自行核验。Lu Heng的方案让有效性取决于可在本地验证的规则和实际使用，而非某个常设注册机构的许可。
Heng.lu这一系列此前的七篇随笔分别是：
- 随笔52：当注册权力与法律责任脱钩——为什么现行RIR协调模式无法以目前的形态存续
- 随笔53：互联网号码资源不是政治财产
- 随笔56：区域互联网注册机构的厚重治理如何把唯一性变成双重攫取
- 随笔58：从双重攫取到主权倒置——各国如何因100美元而向RIR丧失主权控制
- 随笔59：贫困惩罚——RIR模式如何向穷人征税，却将其称为平等
- 随笔61：对运行代码的背叛——RIR体系如何让共识反过来对付技术社群
- 随笔62：授权洗白——从RIR的幻想走向过渡架构
此前七篇文章，不是区域互联网注册机构的改革方案。
它们是一场尸检。
它们从不同层面追踪同一种制度病变：法律责任与后果脱节；号码资源被重新贴上政治财产的标签；唯一性被变成双重攫取；主权被倒置；以平等之名向贫困征税；共识反过来对付它本应服务的网络；最后，授权被层层洗白，直到一个办事员开始以主权者的口吻说话。这个脉络很重要，因为问题并非某个糟糕的董事会、某家糟糕的注册机构、某场诉讼，或某次令人不适的市场事件。它是同一个系统缺陷，换着不同的面目出现。CircleID的作者页面如今清楚呈现了这一脉络，包括《对运行代码的背叛》和《授权洗白》。（circleid.com）
这篇文章，不是要把RIR培养成更好的统治者。
我要解释的是，为什么现行注册秩序不可能成为终点，以及为什么干扰最小的修补，是为互联网原始技术设计补上一项原则。
这项补充，就是运行代码优先。
它的必要性已经不再停留于理论。最近在CircleID的一场交锋中，John Curran提出了现有体系一方最有力的论证。他认为，RIR体系的权威不只是狭义技术协调的副产品，而是一条历史链条的结果：白皮书、ICANN、ASO、ICP-2、IANA管理权移交，以及持续至今的私营部门多利益相关方治理。他表示，RIR体系的权威来自其在美国政府指定的私营部门多利益相关方模式内运作。（circleid.com）
这个论证很有用，因为它让争议的实质显露出来。
问题已经不是历史上是否存在授权。当然存在。问题是，一项历史上被授予的协调职能，能否后来借助自己掌控的同一套程序机制，把自身扩张成一项持续的治理授权。现有体系的回答是可以：授权、认可、制度延续和社群程序，共同构成一种能够自行续期的授权。
互联网原始技术设计所要求的回答，是不可以。
互联网原本的传统，边界更窄，约束更硬，也更好。RFC 3935指出，IETF的目标是“让互联网运行得更好”；它把工作建立在技术能力、现实中的实现，以及“粗略共识与可运行的代码”之上。它还明确指出，对于不属于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的会员资格；同年12月，AFRINIC又一次试图取消会员资格，也遭到阻止。（btw.media）这个过程，不是注册机构从容保护互联网的故事。它是注册权威遇上普通法律的故事。
更广泛的制度崩溃，也不是因为注册机构权力太少。更深的问题是锁定。如果一家注册机构对有价值的运行中资产拥有垄断性的认可权，每一次内部失灵都会成为互联网连续性的风险。如果会员无法离开这套认可体系，注册机构的失灵就会变成挟持能力。
注册机构可以纠正自身记录中有证据可证明的注册欺诈。
在注册机构模式仍然存在时，它可以防止重复分配。
在参与者仍然依赖它时，它可以维护安全声明。
但这些都是旧架构的过渡性职能。
在后RIR架构中，这些职能不再由注册机构承担，而是被编码进分布式账本状态、控制权证明规则、冲突规则，以及可在本地验证的状态转换。
私营机构不应把租赁变成对某个区域的叛国行为。
不应把客户地域变成撤销资源的触发条件。
不应把商业分歧视为技术无效。
不应把资产的持续使用变成一项许可。
AFRINIC证明了正确理解后续决策本地化的必要性。不存在一个中央机构，负责决定未来的某项商业决策“属于本地”。相反，初始规范必须确保，这些决策从一开始就不进入共同层。租赁、客户地域、商业使用、定价、融资、客户构成和部署策略，都应留在确定性有效性规则之外，除非它们直接影响唯一性、安全、控制权证明或互操作性。
运营者出租地址，不能破坏其他运营者之间的互操作。
运营者向历史注册区域以外的客户提供服务，不能破坏其他运营者之间的互操作。
运营者采用注册机构不喜欢的商业模式，不能破坏其他运营者之间的互操作。
最多只是某个运营者未能满足其他参与者运行的确定性规则。在这种情况下，其他参与者在本地拒绝无效状态。没有惩罚层。没有合规法庭。没有区域主权者。
这条界线不是意识形态上的。
它是运行层面的。
代理权问题绝不是细节
AFRINIC的选举争议，让第二个缺陷显露出来：代表权。
NRS以直接的法律表述说明其代表权基础。它表示，名单中的会员委托NRS在RIR治理事务中代表自己，而每一名列出的会员都提供了授权委托书。（nrs.help）在AFRINIC选举争议期间，NRS请会员报告自己的姓名是否出现在选民名册上，或是否在本人没有参与的情况下被记录为已经投票，并表示这类事实报告将通过合法渠道处理。（nrs.help）
这很重要，因为它展示了法律代理与社群话语之间的区别。
RIR体系常常把几种身份混成一种：公司代表、数据库联系人、技术联系人、员工、顾问、代理权持有人、政策参与者、邮件列表常客。这些不是同一回事。
数据库联系人可以协助管理记录。
授权委托书如果有效，而且行为在授权范围内，可以赋予代理权。
政策参与者可以贡献专业知识。
邮件列表发言者可以表达意见。
但上述任何一种身份，都不会使其自动成为所有承担注册机构决定后果的公司、客户、国家、债权人、贷款人、买家、承租人或网络在法律意义上的委托主体。
只有共同层保持精简时，这个区别才可能被忽略。一旦注册机构声称自己对撤销、转让、租赁、市场准入、制裁处理、资产连续性或国家基础设施风险拥有权力，代表权就成为宪制层面的问题。
一间会议室不是授权。
一个邮件列表不是人民。
一条联系人记录不是公司授权委托书。
一个服务区域不是主权意义上的选民群体。
这不是在程序上吹毛求疵。
这是协调与统治的区别。
运行代码优先的体系，通过减少那些根本需要代表权的决策，避开这个陷阱。如果有效性是确定性的，而且能在本地判定，需要投票的事情就少了。如果后续变更是自愿的，就不需要决定不采纳者是否属于违规者。如果状态体现在分布式账本上，就不需要乞求现有注册机构承认自己的持续存在。如果兼容集合明确，参与者无需询问一个政治会议室，就知道自己能与谁互操作。
最好的治理问题，是系统设计直接消除了的问题。
RIPE NCC与LACNIC：俱乐部与瓶颈
RIPE NCC和LACNIC并不能证明某些RIR比另一些更文明。它们证明的是，RIR模式在技术职能之外，还有两个执行层：俱乐部和瓶颈。
俱乐部决定谁算体面。瓶颈决定谁的注册状态能够流转。
RIPE NCC拒绝接受LARUS对RIPE 90的赞助，清楚展示了俱乐部这一层。一名会员提出赞助，却被注册机构一侧的生态圈拒绝，原因是另一个区域里一场与此无关的争议。那不是路由安全决定。不是唯一性决定。不是确定性验证规则。而是利用会议准入实施私人封杀。LACNIC也拒绝了我的赞助。不同区域，同一种本能：注册机构俱乐部通过控制会议室、曝光、赞助、声誉和社会正当性来保护自己。
这不是社群。这是把守关卡。
制裁层更严重，因为它以法律形式展示了中央瓶颈。RIPE NCC表示，由于机构位于荷兰，它必须遵守欧盟制裁；制裁适用时，它会冻结RIPE数据库中的注册信息，阻止资源取得与转让，而且当事方无法提供充分文件时，相关个案也可能被视为冻结。它还筛查OFAC名单，因为银行关系会影响付款。（RIPE NCC制裁透明度说明）
这不是批评RIPE NCC遵守法律。荷兰实体必须遵守荷兰法律和欧盟法律。问题在于架构：为什么一家荷兰私营实体，应当成为横跨众多国家、运营者和法律体系的号码资源流转的中央认可点？
制裁可以约束一家银行。可以约束一个荷兰实体。可以约束一个选择不交易的交易对手。但它不应成为其他所有人的全球技术有效性条件。
这就是设计失败。
让俱乐部能够排斥批评者的同一种中心地位，也让一个司法辖区能够冻结注册流转。一个是社会层面的约束，另一个是法律层面的约束。二者之所以能奏效，都因为注册机构占据了一个有效性本不应依附的位置。
这与三项原则直接相连。
初始规范最小化：俱乐部认定的体面、赞助资格、区域政治、制裁分类和声誉，绝不能进入共同层。共同层只应包含唯一性、控制权证明、冲突处理、状态转换和安全所需的确定性规则。
后续决策本地化：法律风险、交易对手选择、赞助、商业信任和制裁风险，应由承担这些后果的行动者处理。荷兰实体可以拒绝一笔交易。银行可以拒绝付款。交易对手可以拒绝往来。但这些都不应成为普遍适用的注册真相。
自愿采纳：参与者通过运行代码、验证状态，以及选择与谁互操作，来决定接受哪些交易对手。不采纳不是不当行为。本地拒绝不是全球无效。俱乐部的拒绝，不应抹去有效状态。制裁义务应约束受其管辖的行动者，而不是改写全世界的号码资源账本。
这就是分布式账本设计不可或缺的原因。在后RIR体系中，日常有效性不由RIPE NCC、LACNIC、制裁部门、会议委员会或赞助办公室决定。参与者在本地验证状态。交易对手自愿接受或拒绝。分叉可见。兼容集合明确。中央注册机构不再是真相的来源。
解决办法不是更好的礼仪。
不是更透明的制裁处理队列。
而是让有效性同时脱离俱乐部和瓶颈。
分布式状态。本地验证。自愿接受交易对手。注册机构不再是有效性的来源。
NRO的信：向上逃逸
最严重的证据，不是AFRINIC试图越权。
而是整个体系的集体反应。
2022年，号码资源组织（NRO）致信毛里求斯政府。信中将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体系最初的设计之所以失败，是因为它从未问过，运行中的代码究竟需要什么。
它问的是，谁能在会议室里发言。
下一套体系，必须把这个顺序倒过来。
不要授权洗白。
不要背叛运行代码。
运行代码优先。
附录：互联网协调体系的初始规范最小化、后续决策本地化与自愿采纳
摘要
本文描述了一种互联网协调体系的设计模式，其目的是提供共享的技术参照点，而不在运行系统的参与者之上设立一个持续存在的权威。本文定义了三项相互关联的原则：初始规范最小化、后续决策本地化与自愿采纳。
在这一模式下，初始规范只定义唯一性、互操作性、控制权证明、共同安全与安全防护所需的确定性规则，而且这些规则可以在本地验证。初始规范确立之后，后续变更不由中央机构批准，而是由运行代码的参与者采纳、忽略、分叉或放弃。
这一设计模式所指向的是有效状态的分布式账本，或等效的分布式可验证状态机制，而不是注册机构的层级体系。不存在一个决定日常有效性的常设注册机构。参与者在本地验证状态，自愿接受交易对手，并决定自己运行哪些兼容集合。
不采纳不是违规。不采纳后续变更的参与者，仍留在原有兼容集合中。如果某个参与者发出的状态，依照另一个参与者接受的确定性规则并不有效，后者可以在本地忽略它。产生的效果是兼容性选择、分叉、隔离或选择性互操作，而不是机构惩罚。
本文不定义线上传输协议。它为协议、标识符体系、分布式账本以及协调机制的设计规定了一套最佳现行实践；这些系统不得演变为永久治理机构。
1. 引言
许多互联网系统起初只有一项狭义技术目的：通过共享参照点、标识符空间、验证规则、账本状态或控制权证明记录，使彼此独立的行动者能够互操作。随着时间推移，这类系统往往积累起初始互操作并不需要的权威。
这通常分三步发生。
第一，在技术上尚无必要之前，就把未来的问题放进创设层。
第二，本应由运行各自系统的参与者作出的选择，开始依赖某个持续存在的机构所作的认可、解释或资格状态决定。
第三，发布、注册、建议或程序性批准，被视为足以产生运行义务，即便参与者尚未在运行中的系统里采纳这项变更。
结果是一个脆弱的系统。技术参照层变成治理层。记录维护者变成守门人。协调辅助产物变成未来控制权的来源。
本文提出另一套设计纪律：
- 初始规范最小化：只规定基本互操作性、唯一性、控制权证明、共同安全与安全防护所需的确定性共同规则。
- 后续决策本地化：初始规范确立之后，后续选择仍由运行代码的参与者作出。参与者可以采纳、拒绝、分叉、断开连接，或选择性互操作。任何参与者都不能改变那些继续运行彼此兼容规则的其他参与者之间的互操作。
- 自愿采纳：后续变更只有经过实现、运行、验证，以及运行代码的参与者的采纳，才成为现实。
这些原则相互关联。一个系统如果在一开始规定得太多，就把未来的控制权预先装进了共同层。如果保留持续的认可层，就允许权威在部署之后重新出现。如果把发布当成现实，就把文档变成了命令。
设计直觉很简单：有效性必须由确定性规则来判定，参与者能够对照共享状态，在本地验证这些规则。参与者可以采纳后续变更、拒绝它、分叉、断开连接，或选择性互操作。它最多只能让自己退出一个兼容集合。它不能因为拒绝一项变更，就破坏那些继续运行彼此兼容代码的其他参与者之间的互操作。
这是分布式账本设计的一般性教训：共识规则由运行验证代码、决定接受何种状态的参与者执行，而不是由凌驾于他们之上的机构执行。
2. 范围
本文适用于互联网协调体系，包括但不限于标识符体系、命名与编号框架、协议扩展机制、控制权证明系统、可携带性系统、分布式账本，以及其他由独立行动者依赖共同技术参照点的架构。
本文不反对共同规则。它主张，共同规则应具有确定性、保持最小化、可在本地验证，并且仅限于系统实际运行所必需的内容。
本文不要求采用任何特定的分布式账本实现。它要求的是一种设计属性：参与者应当能够在本地对共享或可复制的状态应用初始规范，判定有效性，而无需向常设权威请求许可或询问资格状态。
3. 约定与定义
3.1. 要求用语
本文原文中以大写形式出现的要求用语，应按照BCP 14，具体而言是RFC 2119和RFC 8174所定义的含义理解；本译文分别以“必须”“不得”“应当”“不应”和“可以”表达相应的要求等级。
3.2. 术语
初始规范：
系统首次部署所需的规则、数据结构、格式、不变量、验证程序、状态转换规则和冲突规则的集合。
共同层：
独立参与者实现互操作所需的最低限度共享规则集或参照结构。共同层不是机构，而是参与者实现并验证的技术内容。
分布式账本：
以复制或其他分布式方式保存的状态转换记录，使参与者无需依赖常设注册机构、委员会或其他权威，就能验证日常有效性。这一术语不要求采用任何特定的共识算法或实现。
确定性验证规则：
一种使参与者能够通过本地计算或本地验证，判断某个状态、记录、转换、声明或消息在指定规则集下是否有效的规则。
全局不变量：
为了保持唯一性、基本互操作性、控制权证明的完整性、共同安全或安全防护，必须在一个兼容集合内保持一致的属性。
参与者：
运行、验证、部署或依赖该系统的运营者、实现、节点、网络、组织或其他行动者。
兼容集合：
一组参与者，其实现的验证规则允许彼此互操作。如果部分参与者采纳后续变更，而其他参与者不采纳，这项变更可能产生一个新的兼容集合。
采纳：
运行系统的参与者实际进行的实现、部署、验证和使用。
交易对手接受：
参与者依照自己运行的验证规则，自愿决定接受另一参与者的状态、与之交易、与之互操作，或依赖该状态。
不采纳：
参与者选择不实现或不使用一项提议中的变更。不采纳不会产生无效身份。它仅意味着，该参与者尚未加入这项变更产生的兼容集合。
本地拒绝：
参与者在本地决定忽略、拒绝某个状态、消息、记录或转换，或不与之互操作，因为它依照该参与者运行的验证规则属于无效或不兼容。
分叉：
验证规则或运行实践发生分歧，从而产生两个或更多兼容集合。
协调辅助产物：
帮助参与者协调的文件、建议、实现说明、配置规范、参考实现、账本浏览器、镜像或其他产物。除非参与者在运行中的系统里采纳它，否则协调辅助产物不会产生具有约束力的运行现实。
4. 问题陈述
设计者常常试图通过在创设层写入过多内容，或留下一个持续存在的机构来解释未来问题，以降低未来的不确定性。这看似审慎，往往却很危险。
在创设层过度规定，有三项代价。
第一，它把未来选择移入共同层，使变更更难，也使机构俘获造成的影响更大。
第二，它造成技术有效性与机构认可之间的含混。
第三，它鼓励维护记录、发布文件或召集参与者的机构，把这些行为视为支配未来现实的权威。
同一问题也会在部署之后出现。如果系统需要一个持续存在的机构来批准变更、判定资格状态，或解释日常运行，那么系统就创设了一个在成立之后继续控制的层。这个层可能从行政管理起步，继而变成治理，再变成瓶颈。
本文的设计目标，不是更好的机构裁量。设计目标是避免需要这种裁量。
设计良好的互联网协调体系，应当从一开始就定义确定性、可在本地验证的有效性规则；以分布式或其他可复制的形式表示有效状态；把不涉及不变量的选择留在共同层之外；并且只有当参与者在运行中的系统里自愿采纳时，才让后续变更成为现实。
5. 原则一：初始规范最小化
5.1. 原则表述
初始规范应当只定义基本互操作性、唯一性、控制权证明、共同安全与安全防护所需的最低限度确定性共同规则。
5.2. 要求
采用这一原则的设计：
- 必须明确识别其全局不变量。
- 必须为每一个全局不变量定义确定性验证规则。
- 必须定义有效状态如何表示、复制、验证和更新。
- 不得把一项规则放入初始规范，除非它是保持某个已声明的全局不变量，或实现首次部署所必需的。
- 必须把验证规则与政策偏好、商业安排、机构角色、治理愿景及酌情判断分开。
- 必须允许参与者在本地验证日常有效性，而无需询问任何机构、注册机构、委员会、政策组织或其他权威。
- 应当定义本地验证所需的数据结构、签名、证明、状态转换规则、冲突规则或其他机制。
- 在可以预见未来差异时，应当定义扩展信令、版本管理、兼容性标签或分叉标识。
- 必须确保必要的协调辅助产物具有可携带性、可审计性、可复现性和可替换性。
- 应当优先采用客观、机器可验证的条件，而非主观的优劣判断。
- 不得使未来的机构认可成为有效状态能够被知晓、记录或使用的唯一途径。
5.3. 设计含义
初始规范最小化，不意味着规范含糊。它意味着，只对必须共同遵守的内容作严格规定。
系统仍然需要足够的共同结构才能运行。这套纪律要求区分：
- 为了唯一性、互操作性、控制权证明、共同安全与安全防护，哪些内容必须共同遵守；以及
- 哪些内容涉及运营者偏好、商业实践、交易对手选择、部署时机或后续采纳选择，因此可以留在共同层之外。
如果一项设计无法清楚说明其全局不变量和确定性验证规则，就应当假定，它规定了过多的裁量，却规定了过少的可验证内容。
6. 原则二：后续决策本地化
6.1. 原则表述
初始规范确立之后，后续决策应当留在运行代码的参与者本地。后续决策只对其参与者采纳了该决策的兼容集合生效。不需要持续存在的权威来批准，不采纳也不会产生无效身份。
6.2. 要求
采用这一原则的设计：
- 对于不改变参与者所在兼容集合的确定性验证规则的选择，不得要求参与者取得现有机构、注册机构、委员会、董事会、政策组织或其他权威的许可。
- 不得设立一个常设机构，使其认可成为后续变更在实际运行中成为现实的唯一途径。
- 必须区分依照初始规范成立的有效性，与对后续可选变更的兼容性。
- 不得把不采纳后续变更视为无效。
- 必须允许不采纳后续变更的参与者留在原有兼容集合中。
- 必须允许参与者通过采纳新的验证规则或运行配置规范，加入新的兼容集合。
- 必须允许参与者在本地拒绝那些依照其运行的验证规则属于无效或不兼容的状态、记录、转换或消息。
- 必须允许参与者根据自己接受的验证规则与兼容集合，自愿选择交易对手。
- 不得授权任何机构、注册机构、委员会、政策组织或其他行动者，仅仅因为参与者拒绝了后续变更，就宣布该参与者无效。
- 应当明确标示分叉、版本、配置规范或兼容集合，使参与者知道自己运行哪些规则，以及能与哪些其他参与者互操作。
- 应当避免任何允许现有记录维护者阻止本来有效的参与者继续互操作的设计。
6.3. 设计含义
后续决策本地化，不意味着由中央权威把未来决策分配给本地行动者。它意味着，系统在设计上就保证，初始规范确立之后，通常的后续选择不需要这种分配。
初始规范预先完成划界工作。它定义唯一性、互操作性、控制权证明、共同安全与安全防护所需的最低限度不变量。其他一切，都留在共同层之外。
后续变更不由中央批准。它由运行代码的参与者采纳、忽略、分叉或放弃。
拒绝一项变更的参与者，可以留在该变更产生的兼容集合之外。它可以断开自己与其他参与者的连接。它可以继续留在较旧的兼容集合中。它可以分叉。它可以选择性互操作。但它不能破坏那些继续运行彼此兼容规则的其他参与者之间的互操作。
无效或不兼容状态产生的效果，是本地拒绝，而不是惩罚。不需要任何人裁定某个参与者属于违规者。运行兼容验证规则的参与者，只是不接受无效或不兼容的状态。
7. 原则三：自愿采纳
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 Heng