互联网协调系统的最小初始规范、后续决策本地化与自愿采用

接口达成一致，设计保留余地。Lu Heng 主张，共同规则应限于互操作所必需的部分，后续选择则由参与者自己作出。

摘要

本文描述一种互联网协调系统的设计模式：提供共同的技术参照点，同时不在实际运行系统的参与者之上建立持续存在的权威。它定义了三项相互关联的原则：最小初始规范、后续决策本地化、自愿采用。

在这一模式下，初始规范只定义维持唯一性、互操作性、共同安全与安全防护所必需的确定性规则，而且这些规则必须能够在本地验证。初始规范之后的变更，不由中央机构批准，而由实际运行代码的参与者采用、忽略、分叉或放弃。

不采用，不构成违规。参与者不采用后续变更，仍可留在原有的兼容集合中。如果某个参与者发出的状态，不符合另一个参与者所接受的确定性规则，后者可以在本地忽略发出该状态的参与者。由此产生的是兼容关系的选择、分叉、隔离或选择性互操作，而不是机构性惩罚。

本文不定义线协议（wire protocol）。它为协议、注册系统、标识符系统以及协调机制的设计规定一种最佳当前实践；这些系统与机制不得演变成永久的治理机构。

1. 引言

许多互联网系统最初都有一个狭窄的技术目的：让彼此独立的主体通过共享参照点、标识符空间、验证规则或类似注册系统的记录，实现互操作。随着时间推移，这些系统往往积累起初始互操作根本不需要的权威。

这通常分三步发生。

第一，在技术上尚无必要时，就把未来的问题放进奠基层。

第二，本应由运行各自系统的参与者作出的选择，变成依赖某个持续存在的机构作出承认、解释或身份状态裁定。

第三，把发布、登记、建议或程序性批准，当作足以产生运行义务的依据，即便参与者并未在实际运行的系统中采用该变更。

结果是一个脆弱的系统。技术参照层变成治理层。记录维护者变成守门人。协调载体变成控制未来的来源。

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

– 最小初始规范：只规定维持基本互操作性、唯一性、共同安全与安全防护所必需的确定性共同规则。
– 后续决策本地化：初始规范之后，把后续选择留给实际运行代码的参与者。参与者可以采用、拒绝、分叉、断开连接，或选择性地互操作。任何参与者，都不能改变其他继续运行相互兼容规则的参与者之间的互操作关系。
– 自愿采用：后续变更只有经过实际运行代码的参与者实施、运行、验证和采用，才成为现实。

这三项原则彼此关联。一个系统如果在开始时规定太多，就会把对未来的控制预先装进共同层。一个系统如果保留持续存在的承认层，就会允许权威在部署之后重新出现。一个系统如果把发布当作现实，就会把文档变成命令。

这里的设计直觉很简单：有效性必须由参与者能够在本地验证的确定性规则来判定。参与者可以采用后续变更，也可以拒绝、分叉、断开连接，或选择性地互操作。它最多只能让自己退出某个兼容集合。它不能仅凭拒绝一项变更，就破坏其他继续运行相互兼容代码的参与者之间的互操作。

Bitcoin 等系统也体现了同样的一般性教训：共识规则由运行验证代码的人执行，而不是由凌驾于他们之上的机构执行。

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 NOT）将一项规则纳入初始规范，除非该规则是维持某项已明确列出的全局不变量，或实现首次部署所必需的。
4. 必须（MUST）将验证规则与政策偏好、商业安排、机构角色、治理愿景及裁量判断分开。
5. 必须（MUST）允许参与者在本地验证日常有效性，而无须询问任何机构、注册机构、委员会、政策机构或其他权威。
6. 应当（SHOULD）定义本地验证所必需的数据结构、签名、证明、状态转换规则、冲突规则或其他机制。
7. 在可以预见未来变化的情况下，应当（SHOULD）定义扩展信号、版本机制、兼容性标记或分叉标识。
8. 必须（MUST）确保必需的协调载体可迁移、可审计、可复现且可替换。
9. 应当（SHOULD）优先采用客观、可由机器验证的条件，而不是对优劣的主观评判。
10. 不得（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 NOT）授权任何机构、注册机构、委员会、政策机构或其他主体，仅因参与者拒绝后续变更，就宣布该参与者无效。
9. 应当（SHOULD）明确标示分叉、版本、配置规范或兼容集合，让参与者知道自己运行哪些规则，以及可以与哪些其他参与者互操作。
10. 应当（SHOULD）避免任何让既有记录维护者能够阻止原本有效的参与者继续互操作的设计。

6.3. 对设计的含义

后续决策本地化，不意味着由中央权威把未来决策分配给本地主体。它意味着，系统从设计上就让初始规范之后的日常后续选择，无须经过这种分配。

初始规范预先完成划定边界的工作。它定义维持唯一性、互操作性、共同安全与安全防护所必需的最小不变量。其余一切留在共同层之外。

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

拒绝一项变更的参与者，可以留在该变更形成的兼容集合之外。它可以断开自己与其他参与者的连接，可以继续留在旧的兼容集合中，可以分叉，也可以选择性地互操作。但它不能破坏其他继续运行相互兼容规则的参与者之间的互操作。

无效或不兼容状态带来的是本地拒绝，而不是惩罚。没有人需要裁定某个参与者处于不合规身份状态。运行兼容验证规则的参与者，只是不接受那个无效或不兼容的状态。

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）分析拒绝、分叉及替换路径中的滥用与拒绝服务风险；
– 兼容性标记应当（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. 与 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. 系统是否避免了任何裁定参与者日常身份状态的持续性权威？

作者地址

H. Lu