专家专栏 | RFC 9518：中心化、去中心化与互联网标准

互联网的成功离不开其去中心化的本质特征，即不存在单一的控制点。然而，随着互联网与政治经济耦合不断加深，在基础设施与应用服务的技术、产业和治理的各个层面，原本的中心化问题凸显，并且一些原本分散的情况逐渐呈现出各种形式的集中化趋势，这引起互联网社群的广泛担忧。在这一背景下，互联网标准化组织IETF成立了互联网去中心化研究组（DINRG）开展相关讨论；国内社群也对该问题高度关注。然而，相关讨论始终较为开放，缺乏一个阶段性共识。2023年12月，RFC 9518：Centralization, Decentralization, and Internet Standards 发布，对相关问题进行了系统性且富有洞察力的讨论，对推动相关问题的研究具有积极意义。因此，我们对该文档进行了翻译，供国内的互联网社群参考。

互联网的一个显著特征是没有任何单一的技术、政治或经济控制点。可以说，这一特征有助于互联网的早期应用和广泛普及：连接互联网、在互联网上部署应用程序或出于特定目的使用互联网都不需要获得许可，因此互联网可以满足不同的需求，并可在许多不同的环境中部署。

尽管保持这种状态仍是人们广泛支持的目标，但要在人们视为“互联网”的各种服务和应用中始终保持这种状态已经被证明是难以实现的。网络新闻传输协议（NNTP）和电子邮件等早期服务有多个可互操作的提供商，而如今的许多内容和服务平台则由单一的商业实体运营，没有任何可互操作的替代方案——以至于有些平台已经变得如此知名，对人们的体验如此重要，令人们通常误认为它们就是互联网本身[Komaitis]。

这些困难使人们对体系架构设计——特别是由IETF等开放标准机构所监督的体系架构设计——在控制互联网中心化方面能够且应该发挥什么作用产生了疑问。

本文档认为，虽然去中心化的技术标准可能对于避免互联网功能中心化是必要的，但并不足以实现这一目标，因为中心化往往是由标准机构无法控制的非技术因素造成的。因此，标准机构不应一味地防止一切形式的中心化；相反，它们应采取措施，确保其制定的规范能够实现去中心化操作。

尽管本文档已在IETF社群进行了广泛讨论（参见致谢部分），但它仅代表作者的观点，而非社群的共识。它的主要读者是设计和规范互联网协议的工程师。专属协议和应用程序的设计者可以从考虑这些问题中获益，特别是如果他们希望自己的工作被考虑最终标准化的话。政策制定者可以使用本文档来帮助描述涉及中心化协议和应用程序的滥用情况，并评估针对这些情况提出的补救措施。

第2节定义了中心化，解释了其为何通常是不可取的，但有时是有益的，并调查了其是如何在互联网上产生的。第3节探讨了权力下放问题，并强调了一些相关策略，及其局限性。第4节对互联网标准在对中心化进行控制方面可以发挥的作用提出了建议。第5节最后指出了未来工作方向。

在本文档中，"中心化"是指单个实体或一小部分实体可以排他性地观察、捕获、控制或出租互联网功能的运行或使用的状态。

这里的“实体”可以是个人、团体或公司。一个组织可能受制于降低中心化风险的治理(参见第3.1.3节)，但该组织仍然是一个中心化实体。

“互联网功能”在本文档中被广泛使用。最直接的，它可能是一个已经由标准定义的使能协议，如IP [RFC791]、BGP [RFC4271]、TCP [RFC9293]或HTTP [HTTP]。它也可能是一个新的使能协议的提议或对现有协议的扩展。

由于人们对互联网的体验并不局限于标准定义的协议和应用，本文档还考虑了建立在标准之上的功能的中心化问题，例如社交网络、文件共享、金融服务和新闻传播。同样，作为互联网使能技术的网络设备、硬件、操作系统和软件也会对中心化产生影响。向特定地区或位置的终端用户提供互联网接入，以及为网络之间提供中转（即所谓的 "Tier 1 "网络），都会表现出中心化。

这种中心化的定义并不能涵盖所有类型的中心化。值得注意的是，技术性的中心化（例如，一台机器或网络链接是单一故障点）相对来说较容易被工程师所理解；通常通过将一个功能分散到多个组件可以缓解这种中心化。正如我们将看到的，这些技术手段可能会解决这种中心化问题，但却无法防止功能控制权落入少数人手中。技术界对电缆被切断、停电或服务器故障造成的故障非常了解，但这与有守门人的核心互联网功能所遇到的问题有本质区别。

同样，政治中心化（例如，一个国家能够控制一项功能在整个互联网的供应方式）也同样令人担忧，但在此不作深入讨论。

即使某项功能目前不存在中心化，某些条件也会令未来出现中心化的可能性增大。本文档使用“中心化风险”来描述这种可能性。

2.1. Centralization Can Be Harmful 中心化可能有害

许多参与互联网标准制定工作的工程师倾向于防止和抵制中心化，因为他们认为互联网的历史和架构与中心化不相容。作为一个“大型、异构的互联系统集合”[BCP95]，互联网通常被描述为一个“网络的网络”，其运营商之间是对等关系，他们同意促进通信，而不是受到胁迫或被要求服从于他人。这种对行动独立性的关注在互联网的设计中非常普遍——例如在“自治系统”的概念中。

不愿支持中心化还源于与之相关的许多潜在破坏性影响，包括:

这些危害与中心化之间的关系往往很复杂。中心化并不总会导致这些问题；当中心化导致这些问题时，并不总是有直接和简单的权衡。

例如，考虑中心化和可用性之间的关系。中心化操作系统的可用性可能更高，因为大型运营商可以获得更多的资源，但是当遇到故障时，它们的规模会产生更大的影响。

去中心化系统在面对某些形式的故障时可能更有弹性，但在其他方面就不那么有弹性了；例如，它们对系统性问题的反应能力可能较差，并且可能暴露在大量的安全漏洞中。因此，不能说中心化在所有情况下都会降低可用性，也不能说它在所有情况下都会提高可用性。

这种紧张关系可以在云计算和移动互联网接入等领域看到：如果一个流行的云托管提供商变得不可用(无论是由于技术还是其他原因)，许多互联网体验可能会中断(特别是由于现代网站经常具有的多重依赖关系；详见[Kashaf]。同样，大型移动互联网接入提供商可能会中断服务，影响数十万或更多用户——就像以前大型电话公司的问题导致大范围中断一样[PHONE]。

在这两种情况下，服务在技术上都不是中心化的；这些运营商有很强的动力来安装多个冗余装置，并使用各种技术来降低任何一个部件失效的风险。然而，它们通常依赖于单一的代码库、有限的硬件选择、统一的控制平面和统一的管理实践：每一个都可能导致大范围故障。

如果这些服务只有一个提供商(如旧的电话网)，那么它们很容易被认为是集中的，从而对可用性产生重大影响。然而，许多云提供商也提供类似的服务。在大多数地方，有多个移动运营商可用。这削弱了中心化与可用性之间存在联系的论点，因为功能的用户可以切换到其他提供商或同时使用多个提供商;参见章节4.4。

在考虑特定功能的中心化与可用性之间的关系时，这些情况提出了一个值得调查的领域：切换到其他提供商(从而令任何中断是暂时性的和可管理的)或同时使用多个提供商(以屏蔽单个运营商的故障)有哪些障碍?

需要细致考量的另一个例子可以在评估竞争限制时看到。虽然让各种互联网功能供应更具竞争性是许多工程师的动机之一，但只有法院(有时是监管机构)有权定义相关市场并确定一种行为是反竞争的。特别地，市场中心化并不总是表明竞争存在问题；因此，不受技术社群欢迎的中心化可能并不会引起对竞争的监管。

2.2. Centralization Can Be Helpful 中心化可能是有益的

上述集中化的潜在破坏性影响已广为人知。但一些协议和应用程序依赖中心化来提供功能的问题，却没有得到广泛的探讨。

中心化的出现通常是由于技术上必要性。例如，单一全球协调的“真相来源”本质上是中心化的——例如在域名系统(DNS)的根区中，它允许以全球一致的方式将对人友好的命名转换为网络地址。

同样，IP地址分配也需要中心化。互联网路由要求地址被唯一地分配，但如果一个政府或公司掌握了编址职能，那么整个互联网将面临该实体滥用的风险。类似地，Web的信任模型需要一个证书颁发机构(CA)作为浏览器和服务器之间通信的信任根，这带来了中心化风险，需要在该系统设计中予以考虑。

需要解决“会合问题”的协议也需要中心化，以协调不直接接触的双方之间的通信。例如，聊天协议需要协调交谈双方之间的通信；虽然它们之间的实际通信可以是直接的(只要协议提供便利)，但端节点之间的相互发现通常需要第三方的参与。从这两个用户的角度来看，会合功能存在中心化风险。

中心化即使不是绝对必要的，也可以为一项功能的用户以及社会创造收益。

例如，人们早就认识到，规模经济带来的效率可能导致中心化[Demsetz]。这些效率可以通过更高质量的产品和更低的成本传递给用户，甚至可以提供在较小规模上不能提供的功能。

复杂和有风险的功能，如金融服务(例如，信用卡处理)通常集中在若干专门组织中，在那里可以得到所需要的集中关注和专业知识。

中心化还可以为实施有益的控制提供机会。[Schneider2]指出，“中心式结构有其优点，比如使公众能够将有限的注意力集中在监督上，或者形成一个权力阵营，能够对可能出现的缺乏可问责性的阵营进行挑战。”近几个世纪以来，包括政府、公司和非营利组织在内的中心化结构赢得了广泛的尊重，这在很大程度上是因为这些结构之中的有意设计。

当一项功能需要通过治理手段来实现共同目标和保护少数人的利益时，就可以看到这一好处。例如，内容审核功能推行社会价值，这被许多人认为是有益的。当然，如果治理机制缺乏足够的监督、透明度或可问责性，那么也可以被视为一个施加不当控制的卡点。

最终，对中心化何时是有益作出决定需要主观判断。有些协议没有中心化功能就无法运行；有些协议如果功能是中心化的，则对于某些用例可能会得到显著增强，或者可能更有效。一般来说，中心化在下列情况中是非常令人担忧的：被广泛认为不是必要的或有益的时候；没有检查、制衡或其他问责机制的时候；“最爱”的选择难以(或不可能)被取代时；以及威胁到令互联网成功的架构特征时。

虽然“去中心化”一词在经济、政治、宗教和国际发展领域有着悠久的使用历史，但[Baran]给出了与计算机网络相关的第一个定义，即满足“并不总是要完全依赖于单一点”的条件。

这种技术上的中心化(虽然不是一个小话题)相对来说很容易理解。只使用技术工具(如协议设计)来避免所有形式的中心化——包括非技术的中心化——是很困难的，会遇到若干问题。

首先，也是最关键的，技术性的去中心化措施只能对非技术形式的中心化产生有限的影响。或者，根据[Schneider1]的观点，“去中心化技术本身并不能保证去中心化的结果”。正如下面3.1节所探讨的那样，技术性措施对于实现功能的完全去中心化，是必要但不充分的。

其次，对功能去中心化需要克服中心化功能并未面临的挑战。去中心化功能可能更难以适应用户需求(例如，引入新功能，或者新的用户界面实验)，因为这样做通常需要许多不同参与者之间的协调[Marlinspike]。中心化功能更容易获得规模经济，也更容易获得用于改进功能设计的数据。所有这些因素都使中心化的解决方案对服务提供商更具吸引力，并且在某些情况下，可能令去中心化解决方案并不盈利。

第三，确定要对哪些方面的功能去中心化可能很困难，因为在不同的中心化类型与来源之间通常存在许多交互，而且有时只有在功能大规模部署后中心化才会显现。去中心化的努力通常只会带来将中心化转移到不同地方的效果——例如，在治理、实现、部署或辅助功能方面。

例如，Web在其早期被设想并被广泛认为是一种去中心化的力量。只有当大型网站成功地利用网络效应(并确保法律上禁止互操作性，从而增加切换成本)，它作为中心化推手的潜力才变得明显；参见[Doctorow]来了解如何获得社交网络、市场和类似功能的主导地位。

第四，不同的相关方可能会基于他们的信仰、观念和目标，对“充分去中心化”的含义存在善意的分歧。正如中心化是一个连续体一样，去中心化也是，并不是每个人都对以下问题达成一致：什么是“恰当”的去中心化级别或类型，如何在不同形式的中心化之间权衡，或者如何在潜在的中心化与其他体系架构目标(如安全或隐私)之间权衡。

这些紧张关系可以在DNS中看到。虽然DNS系统的某些方面是去中心化的——例如，将查找功能分散到用户可以手动选择的本地服务器——但DNS本质上中心化特征是其作为一个名字空间的操作：一个单一全局“真相来源”，具有在管理上固有的(如果有益的话)中心化。ICANN通过多利益相关方治理降低相关风险(参见第3.1.3条)。虽然许多人认为这种安排是足够的，甚至可能具有理想的功能(例如在名字空间操作上强加社群标准的能力)，但也有人认为ICANN对DNS的监督是不合规的，他们赞成基于分布式共识协议的去中心化而不是人的治理[Musiani]。

第五，去中心化不可避免地涉及对协议参与者之间权力关系的调整，特别是当它为其他的中心化开辟了可能性时。正如[Schneider2]所指出的，去中心化“似乎是一种修辞策略，将注意力引向所提出的社会秩序的某些方面，而远离其他方面”，因此“我们不能用技术来代替对社会、文化和政治因素的认真考虑”。或者更直白地说，“如果没有适当的治理机制，节点可能勾结，人们可能相互欺骗，市场可能被操纵，人们进入和退出市场可能会付出巨大的代价”[Bodo]。

例如，虽然基于区块链的加密货币旨在通过技术手段解决现有货币固有的中心化问题，但由于投票/挖矿能力、资金分配和代码库的多样性的因素，许多加密货币表现出相当大的权力集中[Makarov]。对技术措施的过度依赖也为潜在的、非正式的权力结构带来了机会，这些权力结构有其自身的风险——包括中心化[Freeman]。

总的来说，对一项功能去中心化需要大量的工作，本质上是政治性的，并且涉及到对结果的很大程度的不确定性。如果将去中心化视为一个更大的社会目标(就像这个术语在其他非计算环境中的用法一样)，那么仅仅重新安排技术功能可能会导致挫败。“分布式网络不会自动产生平等，公平或公正的社会、经济、政治面貌”[Bodo]。

3.1. Decentralization Strategies 去中心化策略

本节研究用于互联网功能去中心化的一些常用策略，并讨论其局限性。

3.1.1. Federation 联盟

协议设计者经常尝试通过联盟来解决中心化问题，即在设计一项功能时，使用多个独立的实例来提供单一整体的服务，这些实例维护连通性和互操作性。联盟承诺，允许用户选择与之关联的实例，并允许用一个实例替换另一个实例，从而降低切换成本。

然而，仅靠联盟不足以防止或减轻功能中心化，因为非技术因素可能迫使采用中心化解决方案。

例如，电子邮件协议套件需要将消息路由到用户，即使该用户更改了网络位置或长时间断开连接。为了实现这一点，SMTP [RFC5321]定义了一个特定的角色来路由用户的消息，即消息传输代理(MTA)。通过允许任何人部署MTA并定义互连规则，该协议避免了在该角色中使用单个中央服务器的要求；用户可以(而且经常)选择将MTA委托给其他人，或者自己运行MTA。

多年来，管理自己的MTA变得相当繁重，部分原因是为打击不受欢迎的商业邮件而引入的日益复杂的机制。这些成本促使人们将自己的MTA委托给拥有合适的专业知识和资源的第三方，从而推动了市场集中度[Holzbauer]。

此外，MTA用来识别不受欢迎的商业邮件的措施通常是针对特定站点的。由于大型MTA管理如此多的地址，因此与较小的MTA存在权力不平衡；如果大型MTA决定不接收来自小型MTA的电子邮件，则会对小型MTA的功能产生重大影响，并且几乎没有应对办法。

可扩展消息传递和状态协议(XMPP) [RFC6120]是一个聊天协议，它展示了联盟的另一个问题：技术标准的自愿性。

与电子邮件一样，XMPP是联盟式的，以方便来自不同系统的用户相聚(如果用户同意的话)。虽然一些XMPP部署确实支持真正的联盟式消息传递(即使用服务A的人可以与使用服务B的人互相聊天)，但许多大型部署并不支持。由于联盟是自愿的，一些运营商将其用户控制在单个服务中，故意剥夺了他们从全局互操作性中获得的好处。

上面的例子说明，虽然联盟可以为功能去中心化创造必要的条件，但它并不能保证结果。

3.1.2. Distributed Consensus 分布式共识

越来越多的分布式共识技术(如区块链)被推崇为应对中心化的解决方案。对这个迅速变化的领域的全面调查超出了本文的范围，但我们可以概括一下它的性质。

这些技术通常使用密码学技术(通常是只追加的事务账簿)保证功能的适当性能。他们试图通过将一项功能的运营分散给一个有时很大的协议参与者集合中的成员来避免中心化。通常，参与者是未知和不可信的，并且分配给一个节点处理的特定任务也无法被预测或控制。

假人攻击(一方或协调的各方廉价地创建足够多的协议参与者来影响共识的判断方式)是这些协议的主要关注点，因为它们会将权力集中到攻击者手中。因此，他们鼓励使用间接技术来增加参与者集合的多样性，例如通过工作量证明(每个参与者必须展示出大量的资源消耗)或权益证明(每个参与者有一些正确执行的其他激励)。

虽然这些措施可以有效地对一项功能的运营进行去中心化，但该功能供给的其他方面仍然可以集中：例如，该功能设计的治理、共享实现的创建和网络协议的登记。

这种对协调工作的需求是中心化的途径，即使该功能的运营仍然是去中心化的。例如，以太坊“合并”表明，区块链可以解决环境问题，但必须通过协调的社群努力和治理：协调在大多数人看来是良性的，但却是中心化的[ETHEREUM]。

此外，由许多功能组成的协议或应用程序可以对某些功能使用分布式共识，但仍然在其他地方被中心化——要么是因为其他功能不能被去中心化(最常见的是交会和全局命名;参见第2.2条)，要么是因为设计者考虑到相关成本和机会损失而选择不采用分布式共识。

这些潜在的缺点并不是要在所有情况下都排除使用分布式共识技术，但确实要慎重，不要不加批判地依靠这些技术来避免或减轻中心化。比较常见的情况是，使用分布式共识被认为是将项目的所有部分都进行“去中心化”。

3.1.3. Operational Governance 运营治理

令一项功能由多个提供商来提供，联盟和分布式共识都可以为此创造条件，但并不能保证。然而，当提供商需要获取资源或与他人合作才能提供服务时，这一 "卡点 "本身就可以用来影响提供商的行为，包括以抵消中心化的方式影响提供商的行为。

在这种情况下，有必要对该“卡点“进行某种形式的治理，以确保取得预期结果。这通常是通过建立一个多利益相关方机构来实现的，该机构包括受系统运行影响的各方代表（"利益相关方"），旨在做出合理、合法和权威的决定。

该技术的一个被广泛研究的例子是DNS名称空间的管理，它体现了作为"唯一真相来源 "的集中化[Moura]。这一真相来源由互联网名称与数字地址分配机构ICANN监督，这是一个全球多方利益相关者机构，代表来自终端用户、政府、运营商等等。

另一个例子是网络信任模式的管理。网络浏览器作为依赖方，有强烈的动机保护用户隐私和安全，而 CA 作为信任锚，有强烈的动机被纳入浏览器的信任库。为了提升所需的运营和安全要求，CA/Browser Forum作为一个监督机构被成立，双方作为利益相关方都参与其中。

这些例子中值得注意的是，治理机制并没有在协议文档中直接规定，而是在运营中形成的，但其方式是利用协议特点来实施治理。

这种治理方式适用于非常有限的功能，如上述例子。即便如此，治理机制的建立和持续运营也并非易事，其合法性可能难以建立和维持（例如，见[Palladino]）。就其本质而言，治理机制很容易被所治理的利益集团所掌控。

考虑到联盟和分布式共识等去中心化技术的局限性、标准遵守的自愿性，以及可能推动中心化的强大力量，我们有理由问，像IETF这样的标准化工作可以做些什么，来适应有益的中心化，同时避免相关的危害，同时承认这种好坏的区分本身就是一种判断，因此具有内在的政治性。

下文各小节提出了标准化机构可以采取的一些具体且有意义的措施。

4.1. Bolster Legitimacy 加强合法性

技术性的标准在控制互联网中心化方面的能力有限，而法律性的标准（无论是法规、法律还是判例法）显示出更大的前景，各个司法机构都在积极考虑和实施。然而，如果不从技术角度充分了解互联网架构所受的影响，对互联网进行监管是有风险的。

此类技术观点不仅可以，而且也应该由互联网标准社群来提供。为了有效地做到这一点，相关机构必须被相关各方——例如竞争监管机构——视为合法机构。如果IETF被视为代表"大科技企业"或仅受美国公司控制，那么其对影响互联网决策的指导能力将大打折扣。

可以说，IETF已经具备了一些特点以提供比较大的合法性。这些特点包括：公开参与和由个人而非公司代表，这两点都增强了输入合法性；具有多层申诉和透明度的明确流程，这有助于提高自始至终的合法性；以及成功制定互联网标准的悠久历史，这或许是IETF最强大的合法性来源——产出。

然而，人们也普遍认识到，成功参与IETF所涉及的巨额成本（不仅仅是财务成本）往往有利于大公司，而不利于小公司。此外，工作的专业性和高度技术性也为非技术利益相关者的进入制造了障碍。这些因素有可能降低IETF决策的合法性，至少在某些人看来是这样。

解决这些不足的努力仍在继续，例如可参阅[RFC8890]。总之，加强本组织的合法性应被视为一项持续的工作。

在参与外部工作时，IETF社群（尤其是其领导层）应牢记，当关注技术和体系架构影响时，IETF 的声音才最具权威性。

4.2. Focus Discussion of Centralization 聚焦中心化讨论

在技术标准讨论中，中心化和去中心化的问题越来越多。任何说法都需要经过严格评估。如 第 2 节 所述，并非所有的中心化都是有害的。根据第 3 节，去中心化技术不会自动消除所有中心化的危害，而且可能带来自身的风险。

然而，标准的参与者很少具备全面评估这些要求的专业知识或信息，因为分析不仅涉及技术因素，还涉及经济、社会、商业和法律方面。例如，规模经济会由于相关的效率[Demsetz]而导致集中，因此要确定这种中心化是否合适，就需要进行详细的经济分析，而这并不在技术标准机构的工作范围之内。此外，中心化的主张可能还有其他动机；特别是，它们可能是利益竞争者之间权力斗争的代名词，中心化的主张可能被用来剥夺市场参与者和（也许更重要的）用户从标准化中获得的好处。

因此，要求在文件中加入"中心化考虑因素 "部分、对中心化审查的出版物进行把关，或投入大量资源搜索协议中的中心化内容等做法，都不可能改善互联网。

同样，如果因为某个协议不能主动防止所有形式的中心化而拒绝将其标准化，那么就会忽视标准制定工作在这方面的有限能力。几乎所有现有的互联网协议——包括 IP、TCP、HTTP 和 DNS——都无法阻止中心式的应用程序使用它们。虽然标准通道[RFC2026]的批准并非没有价值，但仅仅拒绝批准并不能阻止中心化。

因此，讨论应重点突出，范围有限，任何非集中化建议都应详细说明，以便评估其全面影响。[Schneider1]恳求那些提出去中心化建议的人"真真正正清楚地了解某个设计试图分散系统中的哪些特定特征"，并提倡深思熟虑地使用"旧的、制度化的自由主义政治理论"中的分权和问责制等工具。

在评估某项提案是中心化的说法时，应审查这些说法的上下文，以确定是否存在预设、假设和遗漏。[Bacchi] 提供了一个批判性质询的框架，可用于与中心化有关的讨论：

4.3. Target Proprietary Functions 针对专属功能

对于被广泛使用但缺乏互操作性的功能，其标准化时机已成熟。针对其中重要的专属功能（如聊天）进行标准化是合适的，但针对特定功能的互操作性和可移植性的小型标准化工作也是合适的。

对这种方法的一个常见反对意见是，对标准的采用是自愿的；没有“标准警察”来强制使用或强制正确实现。例如，类似[ACTIVITYSTREAMS]的规范已经存在了一段时间，但商业社交网络提供商并未以联盟的方式加以使用。

这种反对意见忽视了一个事实，即虽然标准不是强制性的，但法律监管却是强制性的。政策制定者越来越多地提出互操作性的法律授权，作为解决竞争问题的补救措施（例如，参见[DMA]）。在法律授权的支持下，结合不断变化的规范和由此产生的市场力量，这种对监管的渴望为将这些功能去中心化的新规范提供了机遇[Lessig]。

如果由此产生的法律法规与互联网体系架构不一致，那么这种机遇也会带来风险。要成功创建与法律法规相配合的标准，会有许多潜在的隐患，需要新的、更好的能力（尤其是联络能力）和大量的努力。如果技术社群不做出这样的努力，监管机构很可能会转向其他渠道来获取互操作性规范。

4.4. Enable Switching 令切换成为可能

在不同的功能提供商之间切换的能力是对中心化进行控制的核心机制。如果用户无法切换，就无法行使选择权，也无法充分实现其努力的价值。其原因在于，举例来说，“学习使用一个厂商的产品需要时间，如果标准化不足，所习得的技能可能无法完全迁移到一个竞争对手的产品上”[FarrellJ]。

因此，标准应有一个明确的目标，即方便用户在标准所定义或启用的功能的不同实现与部署之间进行切换。

切换的一个必要条件是有替代可用；实现和部署的广度和多样性是必需的。例如，如果一个协议只有一个实现，那么使用该实现的应用程序就很容易受到该实现对其运行的控制。即使是开源项目在这方面也可能存在问题，如果某些因素导致分叉困难（如维护分叉的成本）。[RFC5218]的第 2.1 节探讨了协议设计中促进实现多样性的一些因素。

用户使用替代实现或部署的成本是另一个需要考虑的重要因素。这包括最大限度地减少使用不同提供商或实现所需的时间、资源、专业知识、协调、功能损失和精力——这意味着标准必须在功能上是完整的，并精确到足以允许替代。

完整性和多样性这两个目标有时会发生冲突。如果一个标准变得极其复杂，可能会阻碍实现的多样性，因为完整实现的成本太高（考虑网络浏览器）。另一方面，如果规范过于简单，则可能无法实现轻松切换，尤其是在需要专属扩展来令规范完备的情况下（见第 4.7 节）。

一个反对易于切换的协议的观点是，这会降低商业提供商实现协议的积极性。虽然一个完全商品化的协议可能不允许各个实现的差异化，但它们为价值链上其他环节的专业化和改进提供了机会[Christensen]。适时的标准工作可利用这些力量，将专利利益集中在开放技术之上，而不是取而代之。

4.5. Control Delegation of Power 控制权力的委托

如果在通信中由第三方提供某些功能，用户可能会受益匪浅。在通信中加入新的参与方可以获得以下改善：

但是，如果新的参与方能够使其参与具有“粘性”——例如，利用其在网络中的地位要求使用中介，滥用其对数据的访问权，或者因为很难转到另一个功能提供方——就会出现中心化的风险。

最常见的情况是，第三方作为“中间人”或指定的“代理人”角色加入到功能中。在设计此类功能时，对这些角色进行深思熟虑的限制，至少可以防止最严重的权力滥用行为。

在为某项功能增加新的参与方时，有两条准则已经被证明是有用的。首先，只有在至少有一方主要当事人采取积极行动的情况下，第三方才能介入通信。其次，第三方观察或控制通信的能力应仅限于履行其预期功能所必需的范围内。

例如，HTTP的早期部署允许网络在端点不知情的情况下设置中介，这些中介默认可以看到和更改流量的全部内容——即使它们只是为了执行缓存等基本功能。由于引入了 HTTPS 和 CONNECT 方法（见[HTTP] 第 9.3.6 节]），再加上鼓励采用HTTPS的努力，现在这些中介必须由一个端点明确地加入其中，而且它们只能访问基本的路由信息。

有关协议中介的更多指导，请参阅[THOMSON-TMI]。

“中介”一词的使用范围（通常在法律和监管背景下）比在协议设计中更广；例如，在买卖双方之间起中介作用的拍卖网站被视为中介，尽管它在 HTTP 中并不是正式的中介（见[HTTP]的第 3.7 节）。协议设计者可以通过将功能标准化而不是限制底层协议的能力来解决与此类中介相关的中心化问题；参见第 4.3 节。

4.6. Enforce Boundaries 强制层间边界

大多数互联网协议和应用程序都依赖于其他“底层”功能及其实现。这些依赖关系的特点、部署和运行可能会给“顶层”构建的功能和应用程序带来中心化风险。

例如，应用协议需要网络才能运行；因此，网络提供商对通信有一定程度的控制权。他们可能会出于经济、政治、业务或非法原因，阻止访问、放慢或更改特定服务的内容，从而遏制（甚至去除）使用特定提供商的能力。通过有选择地阻碍使用某些服务而非其他服务，网络干预措施可以有意无意地制造压力，迫使用户使用其他服务。

加密等技术可以通过强制执行这种上下层边界来阻止这种中心化。当可以访问通信内容的各方数量有限时，就可以防止其他处理通信但不是通信方的各方干扰和观察通信内容。虽然这些参与者仍有可能阻止通信，但加密也使从其他用户的流量中分辨目标变得更加困难。

4.7. Consider Extensibility Carefully 斟酌可扩展性

互联网的演进能力至关重要，它可以满足新的要求，适应新的条件，而不需要“旗帜日”来升级实现。通常情况下，功能通过定义扩展接口来适应演进，这些接口允许以可互操作的方式添加或更改可选功能。

然而，如果一个强大的实体能够通过在标准中添加专属扩展功能来改变有意义的互操作性目标，那么这些接口也可以被其利用。尤其是当核心标准本身不能提供足够的实用性时，情况更是如此。

例如，SOAP[SOAP]具有极大的灵活性，但无法单独提供重要的价值，这使得厂商可以要求使用他们偏好的扩展，从而有利于那些拥有更大市场权力的厂商。

因此，标准工作的重点应该是在发布后为大多数用户提供具体的实用性，而不是成为一个无法立即提供互操作性的“框架”。互联网功能不应使其运营的每一个方面都具有可扩展性；模块之间边界的设计应允许演进，同时仍能提供有意义的功能。

除了允许演进之外，经过深思熟虑的接口还可以帮助去中心化工作。功能子模块之间以及与相邻功能子模块之间出现的结构边界，为互操作性提供了接触点，也为替代提供商提供了机会。

特别是，如果某项功能的接口定义明确且稳定，就有机会为该功能使用不同的提供商。当这些接口是开放标准时，变更控制权就掌握在技术社群手中，而不是专属者手中，从而进一步提高稳定性，令去中心化成为可能（但不是确保）。

4.8. Reuse What Works 重复使用有用的

当互联网功能被有意允许中心化时，协议设计者通常会尝试使用联盟（见第 3.1.1 节）和运行治理结构（见第 3.1.3 节）等技术措施来降低相关风险。

成功做到这一点的协议通常会被重复使用，以避免重新实现这些缓解措施所带来的巨大成本和风险。例如，如果一个协议需要一个协调的全球命名功能，采用域名系统通常比建立一个新系统更可取。

本文档认为，虽然标准机构几乎没有办法通过协议设计来有效控制或防止互联网的中心化，但它们仍然可以采取一些具体而有用的措施来改进互联网。

这些措施可以在今后的工作中加以阐述和扩展；但是，无疑还有更多的工作可以做。如可以提出和调查新的权力委托技术；可以记录从与该领域其他更有效的监管机构的关系中学到的东西。

一些人建议为处理中心化问题制定一份运营指南或清单。由于中心化与具体情况密切相关，其表现形式也多种多样，因此最好是在非常有限的范围内进行尝试，例如，针对特定类型的功能或特定层中的功能。

中心化的本质也值得进一步研究，特别是其原因。虽然对网络效应和切换成本等因素有很多评论，但对其他方面，如行为、认知、社会和经济因素的关注相对较少，尽管这种情况正在发生变化（如[Fletcher]）。

本文档对互联网协议没有直接的安全影响。尽管如此，缺乏中心化的考虑可能会导致无数的安全问题；相关初步讨论，请参阅第 2.1 节。

本文档没有IANA操作。

参考文献和致谢略