互联网工程师工资高吗，互联网网络工程师薪资？

摘要

尽管互联网是作为一个去中心化的网络中的网络来设计和运作的，但它却不断受到鼓励中心化的力量的影响。

本文提供了一个中心化的定义，解释了为什么中心化是不可取的，确定了不同类型的中心化，列出了常见的去中心化方法的局限性，并探讨了互联网标准工作可以做什么来解决这个问题。

本备忘录的状态

本互联网草案是完全按照BCP 78和BCP 79的规定提交的。

互联网草案是互联网工程任务组（IETF）的工作文件。请注意，其他团体也可以将工作文件作为Internet-Draft分发。当前互联网草案的列表在https://datatracker.ietf.org/drafts/current/。

互联网草案是有效期最长为6个月的草案文件，并可能在任何时候被其他文件更新、替换或淘汰。使用互联网草案作为参考材料或引用它们而不是作为 "正在进行的工作 "是不合适的。

本互联网草案将于2023年1月10日到期。

版权声明

Copyright (c) 2022 IETF Trust和被认定为文件作者的人员。保留所有权利。

本文档受BCP 78和IETF Trust在本文档出版之日有效的IETF文档相关法律条款（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了你对本文档的权利和限制。从本文档中提取的代码组件必须包括Trust Legal Provisions法律条款第4.e节中描述的修订版BSD许可文本，并且不提供修订版BSD许可中描述的保证。

1. 简介

互联网的成功在很大程度上是由于它有目的地避免了任何单一的控制实体。这一立场源于防止单一技术故障产生广泛影响的愿望[BARAN]，也使得互联网得以迅速采用和广泛传播。互联网可以满足各种需求，现在被定位为全球公共产品，因为加入、在互联网上部署应用或使用互联网不需要得到另一个实体的许可或让出控制权。

虽然避免互联网的中心化仍然是一个广泛的共同目标，但要持续实现这一目标已被证明是困难的。今天，互联网上许多成功的协议和应用都是以中心化的方式运作的–以至于一些专有的、中心化的服务已经变得如此知名，以至于人们通常将其误认为是互联网本身。即使协议采用了旨在防止中心化的技术，经济和社会因素也会促使用户更喜欢用所谓的非中心化技术建立的中心化解决方案。

这些困难使人质疑架构监管–特别是由IETF等开放标准机构执行的监管–在防止、减轻和控制互联网中心化方面应发挥什么作用。本文讨论了与互联网标准工作有关的中心化的各个方面，并认为尽管IETF可能无法防止中心化，但我们仍然可以采取有意义的措施来抵制它。

第2节定义了中心化，解释了为什么中心化是不可取的，并调查了互联网上的一些中心化类型。第3节探讨了去中心化，并强调了一些相关的技术，以及它们的局限性。最后，第4节考虑了互联网标准在避免中心化和减轻其影响方面所起的作用。

本文件的主要读者是设计和规范互联网协议的工程师。然而，专有协议的设计者可以从考虑集中化的各个方面中受益，特别是如果他们打算将他们的协议考虑为最终的标准化。同样地，政策制定者也可以使用本文件来帮助识别和纠正不适当的中心化协议和应用。

2. 中心化

本文对 “中心化"的定义是：一个实体或一小群实体能够专门观察、捕获、控制或从互联网功能的操作或使用中提取租金。

在这里，"实体 "可以是一个人，一个公司，或一个政府。它不包括以有效缓解中心化的方式运作的组织（例如，见第3.1.2节）。

"互联网功能 "的定义很广。它可能是已经由标准定义的启用协议，如IP [RFC791]、BGP [RFC4271]、TCP [RFC793]或HTTP [HTTP]。它也可能是一个新的使能协议的建议，或对现有协议的扩展。

然而，互联网的功能并不限于标准定义的协议。建立在标准协议之上的用户可见的应用也容易受到中心化的影响，例如，社交网络、文件共享、金融服务和新闻传播。同样地，网络设备、硬件、操作系统和软件也是可以表现出中心化的使能技术。向特定地区或情况下的终端用户提供互联网连接也会受到中心化的影响，网络之间的传输供应（所谓的 "一级 "网络）也是如此。

中心化不是一个二元条件；它是一个连续体。在一个极端，一个由单一实体绝对控制的功能（见第2.2.1节）代表了完全的中心化；在另一个极端，一个其价值可以由任何两方实现而没有任何外部干预或影响的可能性的功能代表了完全的去中心化（有时被称为 "分布式 "或 "点对点"）。

虽然少数功能可能占据了这一频谱的两端，但大多数功能都位于两个极端之间。因此，考虑与一个功能相关的中心化风险的数量通常是有用的，这取决于对它的影响的规模、范围和性质。请注意，一个功能可能有不止一个中心化风险的来源，每个都有自己的特点。

当中心化风险影响到整个互联网时，它是最强的。然而，当互联网的相当一部分用户缺乏对某一功能的选择时，它也可能存在。例如，如果在一个地区或法律管辖区只有一个功能供应商，那么该功能对这些用户来说实际上是中心化的。

中心化的风险最明显是由直接将一个角色分配给一个实体造成的，但当一个实体因其他原因承担该角色时，也会造成中心化的风险。例如，对切换到一个功能的替代提供者的摩擦常常导致中心化（见第2.2.3节）。如果转换需要大量的时间、资源、专业知识、协调、功能损失或努力，则表明中心化风险。相反，一个基于定义明确的、开放的、旨在最小化转换成本的功能可能被认为具有较小的中心化风险，即使只有几个大型供应商。

这种中心化的定义主要集中在通信各方的关系上，而不是系统设计。例如，一个云服务可能使用去中心化的技术来提高其弹性，但仍然由一个实体来操作，从而表现出本文所关注的那种中心化。由于电缆被切断、停电或服务器故障而导致的故障与互联网核心功能有门卫时遇到的问题有质的区别。

因此，可用性的概念与中心化是不同的，如果不仔细分析中心化发生的地点和方式，就不能假设它们之间的任何关系。中心化的系统可能由于其可用的资源等因素而更加可用，但当其出现故障时也会产生更大的影响；去中心化的系统在面对局部故障时可能更有弹性，但对系统性问题的反应能力较差。

例如，大量的网站可能依赖于云主机供应商或内容交付网络；如果它不可用（无论是技术原因还是其他原因），许多人的互联网体验可能会被破坏。同样，一个移动互联网接入供应商可能会发生故障，影响到数百、数千或更多的用户。在这两种情况下，中心化并不因可用性的丧失或其规模而受到影响，但如果依赖该功能的各方在对所提供的服务的可用性不满意时没有合理的选择可以转换，或者反对转换的摩擦太大，那么中心化就很可能受到影响。

此外，将中心化与反竞争问题（也称为 "反垄断"）区分开来也很重要。虽然这些概念之间有许多相互作用，而且使互联网更具竞争力可能是避免中心化的动机，但只有法院有权定义相关市场并确定该行为是反竞争的。此外，技术界可能认为不理想的整合可能不会引起竞争监管，反之，如果其他缓解措施被认为是充分的，那么可能引起竞争监管的东西可能不会被技术界所关注。

2.1. 当中心化是不可取的

互联网功能的中心化有三个主要原因。

首先，互联网的本质与中心化是不相容的。作为一个 "大型、异质的互联系统集合"[BCP95]，互联网通常被描述为 "网络的网络"。这些网络作为同意促进通信的同伴而联系在一起，而不是有一种服从他人要求或受他人胁迫的关系。这种对行动独立性的关注贯穿了网络的架构方式，例如，在 "自治系统 "的概念中。

其次，当第三方不可避免地接触到通信时，所获得的信息和位置优势允许观察行为（"全景效应"）和塑造甚至拒绝行为（"阻塞点效应"）[JUDGE]–这些能力是这些当事方（或对其拥有权力的国家）可以用来进行胁迫的目的[FARRELL]，甚至扰乱社会本身。正如国家的良好治理需要分权一样[MADISON]，互联网的良好治理也要求权力不能集中在一个地方而没有适当的制约和平衡。

最后，某项功能的中心化会对互联网本身产生有害的影响，包括：

• 限制创新。中心化可能排除了 "无许可创新 "的可能性——部署新的、未预见到的应用的能力，而不需要与你正在沟通的其他各方进行协调。
• 限制竞争。当许多供应商提供应用和服务时，互联网和它的用户会从激烈的竞争中受益，特别是当这些用户可以根据可互操作的标准建立自己的应用和服务。当一个集中的服务或平台因为没有合适的替代品而必须使用时，它就有效地成为一种基本设施，这就鼓励了权力的滥用。
• 减少可用性。当有许多方法可以获得访问时，互联网（以及建立在它之上的应用和服务）的可用性就会提高。虽然中心化服务的可用性可以受益于他们所需要的重点关注，但大型中心化供应商的失败会对可用性产生不成比例的影响。
• 创造单一文化。中心化服务或应用的规模可以将功能上的小缺陷放大到一定程度，从而产生广泛的影响。例如，一个单一的路由器代码库提高了错误或漏洞的影响；一个单一的内容推荐算法可以产生严重的社会影响。从系统上看，这些功能实施的多样性导致了更强大的结果。[ALIGIA]
• 自我强化。正如人们广泛注意到的那样（例如，见[VESTAGER]），中心化服务对数据的访问使它有机会对其产品进行改进，同时拒绝对其他人进行这种访问。

关于中心化如何影响互联网的进一步探讨，也请参见[KENDE]。

正如下文第2.2.2节所讨论的，并非所有的中心化都是不可取的或可避免的。[SCHNEIDER]指出，"集权结构可以有一些优点，比如使公众能够集中有限的注意力进行监督，或者形成一个权力集团，能够挑战可能出现的不太负责任的集团。近几个世纪以来，赢得广泛尊重的中央集权结构——包括政府、公司和非营利组织之所以如此，在很大程度上是因为这些结构的有意设计。"

所以，互联网上的集权风险在以下情况下最令人担忧：它没有被广泛认为是必要的，它没有制衡或其他问责机制，它选择了难以（或不可能）被取代的 "宠儿"，以及它具有上述的破坏性影响或潜在影响。

2.2. 中心化的种类

互联网上的中心化并不统一，它以不同的方式呈现，取决于它与相关功能的关系和基本原因。下面的小节描述了互联网中心化的不同方面。

2.2.1. 专有的中心化

为特定的一方创建具有固定作用的协议或应用程序是最直接的一种中心化。目前，许多消息、视频会议、聊天、社交网络和类似的应用都以这种方式运作。

因为它们允许由单一实体控制，所以与去中心化的替代方案相比，专有协议通常被认为设计更简单，更容易进化，更容易满足用户需求[MOXIE]。然而，它们也有相应的中心化风险——如果该功能没有替代的提供者，或者切换到这些提供者太困难，其用户就会被 "锁定"。

专有协议和应用程序不被认为是互联网本身的一部分；相反，它们被更恰当地描述为建立在互联网之上的。除了底层协议（如TCP、IP、HTTP）施加的限制外，互联网架构和相关标准并没有对它们进行监管。

2.2.2. 有益的中心化

一些协议和应用的目标需要引入中心化的功能。在这样做的时候，他们明确地依靠中心化来提供一个特定的好处。

例如，需要一个单一的、全球协调的 "真理之源 "的功能从本质上来说是中心化的，例如在域名系统（DNS）中，它允许以全球一致的方式将人类友好的命名转换为网络地址。

另一个表现出有益中心化的功能是IP地址分配。互联网路由需要地址的唯一分配，但如果一个政府或公司掌握了寻址功能，整个互联网将面临被该实体滥用的风险。同样，由于证书颁发机构在客户和服务器之间的通信中的作用，网络信任模型中的协调需要带来中心化的风险。

需要解决 "会合问题 "以协调没有直接联系的两方之间的通信的协议也受到这种中心化的影响。例如，聊天协议需要协调希望交谈的两方之间的通信；虽然实际的通信可以在他们之间直接进行（只要协议促进了这一点），但端点的相互发现通常需要在某些时候有第三方的参与。从这两个用户的角度来看，会合功能有中心化的风险。

同样，当一个功能需要治理来实现共同的目标和保护少数人的利益时，所选择的治理机制自然会形成一个 "阻塞点"，增加中心化风险。例如，定义和应用内容控制政策都有中心化风险。

决定什么是有益的是一种判断。有些协议在没有中心化功能的情况下无法运作；如果某项功能是中心化的，其他协议可能会在某些用例中得到显著增强，或者只是更有效率。这种判断应该根据既定的架构原则和最终用户的收益情况来进行。

当有利的中心化出现时，互联网协议通常试图使用诸如联盟（见第3.1.1节）和多利益相关者治理（见第3.1.2节）等措施来减轻相关风险。成功缓解有益中心化的协议经常被重复使用，以避免重新实施这些缓解措施所带来的巨大成本和风险。例如，如果一个协议需要一个协调的、全球性的命名功能，重用域名系统通常比建立一个新系统要好。

2.2.3. 集中的中心化

即使一个功能避免了专有的中心化，并减轻了存在的任何有益的中心化，当外部因素影响其部署时，它也可能在实践中变得集中化，从而使少数甚至只有一个实体提供该功能。这通常被称为 “中心化"。尽管协议本身没有这样的要求，但鼓励使用中央职能的经济、法律和社会因素会导致中心化。

通常，驱动中心化的因素与互联网上经常看到的网络效应有关。虽然在理论上，互联网上的每个节点都是平等的，但在实践中，一些节点比其他节点的联系要多得多：例如，只有几个网站驱动着网络上的大部分流量。虽然在许多类型的网络中都可以看到，网络效应将不对称的权力授予作为通信中介的节点。[BARABASI]

例如，社交网络是一个目前由少数专有平台提供的应用，尽管有标准化的努力（例如，见[ACTIVITYSTREAMS]），因为相关的强大网络效应。虽然在社交网络中存在一些竞争，但由于转移到一个新的服务需要协调，一群希望交流的人往往被他们的同伴的选择所锁定。

参见[ISOC]对中心化的深入探讨。

中心化在协议设计中很难避免，联合协议特别容易受到中心化的影响（见第3.1.1节）。

2.2.4. 继承的中心化

大多数互联网协议和应用都依赖于其他 "低层"协议及其实现。这些依赖关系的特点、部署和操作可以使中心化浮出水面，成为建立在其 "之上 "的功能和应用。

例如，端点之间的网络可以为应用层协议引入中心化的风险，因为它是通信的必要条件，因此对它有权力。一个网络可能会出于金融、政治、运营或犯罪的原因，阻止对各种应用协议或特定服务的访问，放慢速度，或改变其内容，造成使用其他服务的压力，这可能会导致其中心化。

同样，只拥有一个协议的单一实现也是一种继承的中心化风险，因为使用它的应用程序容易受到它对其运行的控制。即使它是开源的，如果有一些因素使分叉变得困难（例如，维护该分叉的成本），也可能存在继承的中心化。

当网络效应限制了选择时，就会出现继承性中心化，但也可能是由法律授权和激励措施造成的，这些措施限制了某种功能（如互联网接入）的选择、其提供或可用的实现范围。

某些类型的继承性中心化可以通过使用加密等技术来执行层的边界来防止。当能够接触到通信内容的各方的数量受到限制时，可以防止较低层的各方干扰和观察它。尽管这些下层的各方仍可能阻止通信，但加密也使其更难从其他流量中分辨出目标。

请注意，当大部分（如果不是全部）通信都被加密时，加密对继承中心化的禁止性影响最为明显。也见[RFC7258]。

2.2.5. 平台中心化

继承的中心化的补充是平台中心化—— 一个函数不直接定义中心角色，但可以促进它所支持的应用中的中心化。

例如，HTTP不被认为是一个中心化的协议；可互操作的服务器很容易实例化，而且有多个客户端。它可以在没有中央协调的情况下使用，除了上面讨论的由DNS提供的协调之外。

然而，建立在HTTP之上的应用（以及 "网络平台 "的其他部分）经常表现出中心化（例如，社交网络）。因此，HTTP是中心化平台的一个例子——虽然协议本身不是中心化的，但它促进了中心化服务和应用的创建。

与中心化一样，平台中心化也很难用协议设计来防止。由于互联网的分层性质，大多数协议在使用方式上允许有相当大的灵活性，往往在某种程度上，对某一方的操作形成了依赖性，从而变得很有吸引力。

3. 去中心化

虽然 "去中心化 "一词在经济、政治、宗教和国际发展中有着悠久的使用历史，但在[BARAN]中，Barans给出了与计算机网络有关的最早的定义之一，即当 "不总是需要完全依赖单点 "时的一种情况。

这个看似简单明了的技术定义隐藏着几个问题。

首先，确定一个功能的哪些方面需要去中心化以及如何去中心化是很困难的，这是因为一个功能通常有很多方式可以被中心化，而且中心化有时只有在功能被大规模部署后才会显现出来。

例如，一个云存储功能可以使用分布式共识协议来实现，确保任何一个节点的故障都不会影响系统的运行或可用性。在这个意义上，它是去中心化的。然而，如果它是由一个单一的法律实体运作，那就会带来非常不同的中心化风险，特别是在很少有其他选择的情况下，或者有反对选择其他选项的摩擦。

另一个例子是互联网，它在早期被设想并广泛认为是一种去中心化的力量。只有当大型网站成功利用网络效应在社交网络、市场和类似功能中占据主导地位时，其固有的平台中心化才变得明显。

第二，不同的人可能会根据他们的信念、看法和目标，对 "充分去中心化 "的含义产生善意的分歧。正如中心化是一个连续体，去中心化也是如此，并不是每个人都同意什么是 "正确 "的水平或类型，如何权衡不同形式的中心化，或者如何权衡中心化与其他架构目标（如安全或隐私）。

这在DNS中可以看到，它是一个单一的、全球性的 "真理之源"，具有固有的（如果是有益的）中心化。相关的风险通过ICANN的多利益相关者治理得到了缓解（见第3.1.2节）。虽然许多人认为这种安排是充分的，甚至可能具有理想的品质(如对名称空间的运行施加社区标准的能力)，但其他人则认为ICANN对DNS的监督是非法的，他们赞成基于分布式共识协议的去中心化，而不是多利益攸关方主义。[MUSIANI]

第三，去中心化不可避免地涉及到对协议参与者之间权力关系的调整，特别是当去中心化的功能开启了其他地方中心化的可能性。正如Schneider在[SCHNEIDER]中指出的，权力下放 "似乎是作为一种修辞策略来运作的，它将注意力引向拟议的社会秩序的某些方面，而不是其他方面"，所以 "我们不能接受技术来替代对社会、文化和政治的认真考虑"。或者，正如[BODO]中更直截了当地说，"如果没有治理机制，节点可能会串通，人们可能会互相撒谎，市场可能会被操纵，人们进入和退出市场会有很大的成本"。

例如，虽然基于区块链的加密货币可能通过技术手段解决传统货币中固有的中心化问题，但许多人在投票/采矿权、资金分配和代码库的多样性方面表现出的权力集中导致一些人质疑它们实际上是如何去中心化的。[AREWEDECENTRALIZEDYET]正式结构的缺乏为潜在的、非正式的权力结构带来了机会，这些权力结构有其自身的风险，包括中心化。[FREEMAN]

在实践中，这意味着职能下放需要大量的工作，本质上是政治性的，并且对结果有很大程度的不确定性。特别是，如果人们把去中心化看作是一个更大的社会目标（按照这个词在其他非计算机背景下的使用方式的精神），仅仅重新安排技术功能可能会导致挫败。"一个分布式网络不会自动产生一个平等的、公平的或公正的社会、经济、政治景观"。[BODO]

3.1. 去中心化技术

在互联网标准化的背景下，去中心化的实施是一个两步的过程：评估中心化风险的性质，然后应用技术来减少或减轻风险。下面的小节研究了其中的一些技术。

选择适当的分权技术需要平衡功能的具体目标和中心化风险，因为通过技术手段完全排除所有形式的中心化是很少能实现的。如果执行得当，分权可能会产生一个仍有中心化风险的结果，但这种风险应该被理解、接受，并在可能和适当的情况下被减轻。

值得注意的是，去中心化并不要求提供的功能需要以特定的方式或特定的程度分布。例如，域名系统[RFC1035]被广泛认为具有可接受的中心化风险，尽管它是由一组有限的实体提供的。

3.1.1. 联盟

管理互联网协议中的中心化的一个广为人知的技术是联盟——把它们设计成任何中心化功能的新实例都容易创建，并能与其他实例保持互操作性和连接性。

例如，SMTP[RFC5321]是电子邮件协议套件的基础，它有两个具有中心化风险的功能：

1. 给予每个用户一个全球唯一的地址，以及
2. 将信息路由给用户，即使他们改变网络位置或长时间断开连接。

电子邮件重用DNS，以帮助减轻第一种风险。为了减轻第二种风险，它定义了一个特定的角色来路由用户的信息，即信息传输代理（MTA）。通过允许任何人部署MTA并定义它们之间的相互连接规则，该协议的用户避免了对单一中央路由器的要求。

用户可以（而且经常）选择将这个角色委托给其他人，或者运行他们自己的MTA。然而，运行自己的邮件服务器已经变得很困难，因为一个小的MTA有可能被归类为垃圾邮件源。因为大型MTA运营商广为人知，如果他们的运营受到影响，影响更大，所以他们不太可能被归为此类，集中了协议的运营（见2.2.3节）。

另一个联合互联网协议的例子是XMPP [RFC6120]，支持 "即时通讯 "和类似的功能。像电子邮件一样，它重用DNS来命名，并需要联盟来促进来自不同系统的用户的会合。

虽然XMPP的一些部署确实支持真正的联合消息（即，一个使用服务A的人可以与使用服务B的人进行互操作性的聊天），但许多最大的部署并不支持。因为联合是自愿的，一些运营商把他们的用户抓到一个单一的服务中，剥夺了他们全球互操作性的好处。

上面的例子说明，虽然联盟可以是一种有用的技术，避免专有的中心化和管理有益的中心化，但它并不能防止中心化或平台中心化。如果一个单一的实体可以抓住一个协议所提供的价值，他们可能会利用该协议作为一个平台来获得 "赢家通吃 “的结果，这是许多互联网协议的一个重大风险，因为网络效应往往会促进这种结果。同样，外部因素（如垃圾邮件控制）可能会自然地将 "桌子 "向少数运营商倾斜。

3.1.2. 多利益相关者治理

协议设计者可以通过将该功能的管理委托给多方利益相关者机构来减轻与有利的集中功能相关的风险（见第2.2.2节）——该机构包括受系统运行影响的不同类型的各方代表（"利益相关者"），试图做出合理、合法和权威的决定。

这种技术最广为研究的例子是DNS的管理，它作为一个 "单一真理源"，在其命名功能以及整个系统的运行方面表现出有益的中心化。为了减少操作上的中心化，多个根服务器由独立的运营商（他们自己也有不同的地理区域）和来自许多司法管辖区和附属机构的公司实体、非营利组织和政府机构的选择来执行这项任务。名称空间本身由互联网名称与数字地址分配机构（ICANN）管理，这是一个全球多方利益相关者的机构，其代表来自最终用户、政府、运营商和其他机构。

另一个例子是网络信任模式的管理，由作为依赖方的网络浏览器和作为信任锚的证书授权机构实施。为了确保所有各方都能满足提供所需属性的操作和安全要求，CA/浏览器论坛被设立为一个监督机构，涉及双方的利益相关者。

另一个多方利益相关者的例子是互联网协议本身的标准化。由于规范控制了实施行为，标准化过程可以被看作是一个单一的控制点。因此，像IETF这样的互联网标准机构允许公开参与和贡献，以公开和负责任的方式做出决定，有一个明确的过程来做出（必要时上诉）决定，考虑不同利益相关者群体的意见[RFC8890]。

这种方法的一个主要缺点是，多利益相关者机构的建立和持续运作并非易事。此外，他们的合法性不能被假定，而且可能难以建立和维持（例如，见[PALLADINO]）。如果被协调的功能是广泛的、复杂的和/或有争议的，这种担忧就尤为重要。

3.1.3. 分布式共识

越来越多的分布式共识技术（如区块链）被吹捧为中心化问题的解决方案。对这个快速变化的领域进行完整的调查超出了本文的范围，但我们可以对其属性进行概括。

这些技术试图通过将功能分配给有时很大的协议参与者的成员来避免中心化风险。它们通常使用加密技术（通常是只附加的交易账本）来保证一个功能的适当性能。一个特定的任务分配给一个节点处理，通常无法预测或控制。

Sybil攻击（一方或协调各方廉价地创造足够的协议参与者，以影响对共识的判断）是这些协议的一个主要问题。他们使用间接技术鼓励参与者池的多样性，如工作证明（每个参与者必须显示大量的资源消耗）或股权证明（每个参与者有一些其他激励措施来正确执行）。

使用这些技术可以为专有和继承的中心化创造障碍。然而，根据有关的应用，中心化和平台中心化仍然是可能的。

此外，分布式共识技术有几个潜在的缺点，可能使它们不适合——或至少难以使用，许多互联网应用，因为它们的使用与其他重要目标相冲突：

1. 分布式共识对隐私有重大影响。由于用户活动（如查询或交易）与许多未知方共享（并且由于区块链的性质往往是公开可见的），它们的隐私属性与传统的客户端/服务器协议非常不同。潜在的缓解措施（例如，私人信息检索；见，例如，[OLUMOFIN]）仍然不适合广泛部署)。
2. 它们的复杂性和 "聊天性 "通常会导致网络的使用效率大大降低（通常，达到几个数量级）。当分布式共识协议使用工作证明时，能源消耗会变得非常大（以至于一些司法管辖区已经禁止使用）。
3. 分布式共识协议仍未被证明可以扩展到成功的互联网协议所期望的程度。特别是，依靠未知的第三方来提供功能，可以在延迟、可用性和吞吐量方面引入显著的变化。这对那些对这些特性有很高期望的应用来说是一个明显的变化（例如，面向消费者的网站）。
4. 根据设计，分布式共识协议将一个功能的责任分散到几个难以识别的各方。虽然这可能是防止某些类型的中心化的有效方法，但它也意味着让某人对该功能的执行方式负责是很困难的，而且往往是不可能的。虽然协议可能会使用加密技术来保证正确的操作，但它们可能没有抓住所有的要求，也可能没有被协议设计者正确使用。
5. 分布式共识协议通常依靠密码学来确定身份，而不是相信第三方对身份的断言。当一个参与者失去了他们的钥匙，恢复他们身份的过程会暴露出额外的中心化风险。

同样重要的是要认识到，一个协议或应用程序可以在某些功能上使用分布式共识，但在其他地方仍有中心化的风险——要么是因为这些功能不能被去中心化（最常见的是会合和全局命名；见第2.2.2节），要么是因为设计者选择不这样做，因为相关的成本和失去的机会。

即使分布式共识被用于服务的所有技术功能，一些协调仍然是必要的——无论是通过对功能本身的治理，创建共享的实现，还是共享的线程协议的文档。这代表了中心化的风险，只是在不同的层（继承的或平台的）。

这些潜在的缺点并不排除在每一种情况下使用分布式共识技术。然而，它们确实提醒我们不要不加批判地依赖这些技术来避免中心化。

4. 互联网标准应该怎么做？

中心化是由强大的力量（包括经济和社会力量）以及互联网规模带来的网络效应所驱动的。由于无许可创新是互联网的核心价值，而在互联网上看到的大部分中心化是由利用这一性质的专有平台完成的，因此标准工作可用的控制非常有限。

虽然标准机构本身不能防止中心化，但下面的小节提出了可以采取的有意义的步骤。标准工作对其他相关形式的监管也有宝贵的贡献。

4.1. 现实点

有些中心化的风险在标准工作中是很容易管理的。例如，如果向IETF提出一项专有协议，它将被立即拒绝。在管理有益的中心化风险方面，有越来越多的知识和经验，并且强烈倾向于在可能的情况下重新使用现有的基础设施。如上所述，加密通常是管理继承中心化的一种方式，并且已经成为标准协议的规范。这些反应是互联网标准管理中心化风险的适当方式。

然而，在标准工作中，减轻中心化和平台中心化要困难得多。因为我们没有 "协议警察"，所以不可能要求某人停止使用所谓的联盟协议来建立一个专有服务。我们也无法阻止有人在不放弃无许可创新等架构目标的情况下在标准协议的 "顶部 “建立中心化服务。虽然互联网标准的印记并非没有价值，但仅仅扣留印记并不能阻止这些中心化的行为。

因此，投入大量资源审查协议的潜在中心化风险——特别是中心化和平台风险——不太可能有效防止互联网中心化。几乎所有现有的互联网协议——包括IP、TCP、HTTP和DNS–都表现出中心化或平台中心化。拒绝对一个较新的协议进行标准化，因为它面临着类似的风险，这将是不公平的，相称的，或有效的。

当我们发现中心化风险时，在考虑如何解决这个问题时，我们应该考虑它与其他架构目标的关系。特别是，应该注意标准（作为架构监管的一种形式）在实现每个目标方面的有效性。

例如，与事后的法律监管相比，事先的技术约束往往能更有效地保证隐私。相反，（正如所讨论的）某些类型的中心化可能通过法律监管更好地解决。因此，作为第一顺序的关注，平衡这些关注的标准努力可能主要集中在隐私上。然而，这些往往不是完全可分离的目标——中心化可能导致一个或几个实体拥有更多的数据量和种类，只对他们开放，从而引起重大的隐私和安全问题。

4.2. 去中心化专有功能

为那些目前只能由专有供应商满足的功能创建规范是值得的。通过在已经建立的标准之上建立开放的规范，可以创造出中心化功能的替代方案。

对这种努力的一个常见的反对意见是，采用是自愿的，而不是强制的；没有 "标准警察 "来强制使用它们或强制正确的实施。例如，像[ACTIVITYSTREAMS]这样的规范）已经有一段时间了，但没有被社交网络供应商广泛采用。

然而，虽然标准不是强制性的，但法律监管却是强制性的，而且全球的监管者现在正把他们的努力集中在互联网上。特别是，对互操作性的法律授权越来越多地被讨论为对竞争问题的补救措施（例如，见[OECD]）。

因此，对互联网监管的胃口不仅给互联网带来了风险；它也构成了新规范的机会，在法律授权的支持下，结合不断变化的规范和由此产生的市场力量，将这些功能去中心化[LESSIG]。

对IETF来说，成功地创建与法律规定相一致的标准是一个新的领域，呈现出许多潜在的陷阱，并需要新的能力（特别是联络，可能源于IAB）和大量的努力。如果互联网社区不作出这种努力，监管者很可能会转向其他来源的互操作性规范——很可能透明度较低，投入较少，经验有限，而且没有参考互联网的架构目标。

4.3. 评估新的去中心化技术

第3.1节中列出的去中心化技术并不是一个封闭的集合；广泛的兴趣刺激了新方法的发展，无论是一般的还是对特定问题的解决方案。

例如，安全的多方计算技术(见，例如，[YAO])可以被组成，以允许各方在不泄露私人输入的情况下进行计算。像[ENPA]和[PRIO]这样的协议使用它们来限制协议中的参与者可用的信息，以实现隐私目标；正如第4.5节中所讨论的，这样做也可能抵消某些类型的中心化。然而，在其他情况下，这些技术并不自动排除所有的中心化；这样的系统往往仍然需要信任，即使它是有限的。这可能会导致其他形式的中心化。

使用这些技术（或其他技术）是否能有意义地抵制中心化，仍然是不确定的。标准机构（包括IETF）可以通过孵化它们，应用（必要时开发）隐私、安全、可操作性和其他目标的架构指南，以及保证互操作性来发挥重要作用。在适当的时候，在标准轨道上发表或作为实验性发表，可以向实施者、用户和监管者发出关于其适用性的信号。

4.4. 建立健全的生态系统

为了最小化继承的中心化风险，标准定义的功能应该有一个明确的目标，即广泛、多样的实施和部署，以便用户有尽可能多的选择。

RFC5218 第2.1节探讨了协议设计中鼓励这种结果的一些因素。

这一目标还可以通过确保切换到不同的实现或部署的成本尽可能低以促进后续的替代来进一步实现。这意味着标准在功能上是完整的，并且规定得足够精确，以导致有意义的互操作性。

完整性和多样性的目标有时是矛盾的。如果一个标准非常复杂，它可能会阻碍实现的多样性，因为完整实现的成本太高（考虑：网络浏览器）。另一方面，如果规范太简单，它可能没有提供足够的功能来完成，而由此产生的专有扩展可能会使转换变得困难（见第4.6节）。

同样值得注意的是实施的基本动机。虽然完全商品化的协议可能不允许实施者区分自己，但它们为价值链中其他地方的专业化和改进提供了机会[CHRISTENSEN]。适时的标准工作可以利用这些力量，将专有利益集中在开放技术之上，而不是作为其替代品。

平衡这些因素以建立强大的生态系统是很困难的，但通常会得到社区建设和良好设计的帮助——特别是适当地使用分层。它还需要对协议进行持续的维护和进化，以确保它们仍然是相关的，并且适合于它们的使用。

4.5. 控制权力的下放

一些功能如果由通信中的第三方来执行，可能会看到很大的好处。如果使用得好，在通信中增加一个新的一方可以改善：

• 效率。互联网上的许多功能在以较高的规模执行时更有效率。例如，一个内容交付网络可以提供服务，其财务和环境成本只相当于提供内容的人自己所支付的一小部分，因为他们的运营规模。同样地，一个双面市场平台可以比一对一的买方/卖方交易引入相当大的效率[SPULBER]。
• 简单性。完全脱媒的通信可以将功能的负担转移到终端上。这可能会导致用户的认知负荷增加；例如，比较商业社交网络平台和自我托管的努力。
• 专业化。将某项功能集中在少数人手中可以改善结果，因为由此产生专业化。例如，由专业管理员监督的服务通常被认为具有更好的安全态势和更好的可用性。
• 隐私。对于某些功能来说，通过集中其活动，防止个别行为被相互区分，可以改善用户的隐私。[CHAUM]引入第三方也可以强制执行功能边界，例如，减少用户对潜在恶意终端的信任，正如在所谓的 "遗忘 "协议（例如，[RFC9230]）中看到的那样，允许终端用户向服务隐藏其身份，同时仍然访问它们。

然而，在通信中引入新的一方会给互联网协议增加中心化和平台中心化的风险，因为它带来了控制和观察的机会。虽然（如上所述）标准工作在防止或控制这些类型的中心化方面的能力非常有限，但在设计协议时对第三方功能进行周到的限制，至少可以防止最恶劣的结果。

最常见的是，第三方作为 "中介 "或指定的 "代理 "角色被添加到协议中。一般来说，他们只应该因为至少一个端点的积极行动而被介入，并且他们观察或控制通信的能力应该限制在执行其预期功能所需的范围内。

例如，HTTP的早期部署允许网络在不了解端点的情况下插入中介机构，这些中介机构可以看到并默认改变通信的全部内容——即使它们只是为了执行基本功能，如缓存。由于引入了HTTPS和CONNECT方法（见[HTTP]第9.3.6节），再加上鼓励采用该方法的努力，现在要求这些中介必须由一个端点明确介入。

参见[I-D.thomson-tmi]以获得更多关于协议中介的指导。

术语 "中介 "的使用（通常在法律和监管背景下）也比在协议设计中更广泛；例如，在买方和卖方之间进行中介的拍卖网站被认为是一个中介，尽管它在HTTP中不是正式的中介（见[HTTP]第3.7节）。协议设计者可以通过标准化功能来解决与这种中介相关的中心化风险，而不是限制基础协议的能力；见第4.2节。

4.6. 目标可扩展性

互联网协议的一个重要特征是它们的演进能力，因此它们可以满足新的要求并适应新的条件，而不需要 "旗帜日 "来升级实现。通常情况下，协议通过扩展机制来适应进化，这些机制允许随着时间的推移，以可互操作的方式增加可选的功能。

可扩展性也可以被看作是一种去中心化的机制——通过允许无协调的进化，它促进了自主性和适应当地需求的功能。然而，如果一个强大的实体可以通过向标准协议添加专有扩展来改变有意义的互操作性的目标，那么协议扩展也会增加平台中心化的风险。当核心标准本身不能提供足够的效用时，这种情况尤其明显。

例如，SOAP协议的极端灵活性和未能提供重要的独立价值，使得供应商能够要求使用他们喜欢的扩展，有利于那些拥有更多市场力量的供应商。

因此，标准工作应该专注于为其公布的大多数用户提供具体的效用，而不是成为一个不能立即提供互操作性的 "框架"。互联网协议不应该使其操作的每个方面都可扩展；扩展点应该是合理的、适当的灵活性和控制的界限。当一个协议定义了扩展点时，他们不应该允许一个扩展点宣布自己是强制性的互操作，因为这种模式会招致滥用。

在允许扩展的地方，应该注意那些出现的扩展；在适当的地方，广泛采用的扩展应该通过一个标准过程，以确保其结果符合架构原则和共同目标（也见第4.2节）。

5. 安全考虑

本文档对互联网协议没有直接的安全影响。然而，如果不考虑中心化的风险，可能会引起无数的安全问题。

6. 信息性参考资料

[ACTIVITYSTREAMS]

Snell, J. and E. Prodromou, "Activity Streams 2.0", World Wide Web Consortium CR CR-activitystreams-core-20161215, 15 December 2016, <https://www.w3.org/TR/2016/CR-activitystreams-core-20161215>.

[ALIGIA]

Aligia, P. D. and V. Tarko, "Polycentricity: From Polanyi to Ostrom, and Beyond", Governance: An International Journal of Policy, Administration, and Institutions, Vol. 25, No. 2, p. 237, April 2012, <https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2149165>.

[AREWEDECENTRALIZEDYET]

bitcoinera, "Are We Decentralized Yet?", 2022, <https://bitcoinera.app/arewedecentralizedyet/>.

[BARABASI]

Albert, R., "Emergence of Scaling in Random Networks", SCIENCE, Vol. 286, No. 15, p. 509, October 1999, <https://barabasi.com/f/67.pdf>.

[BARAN]

Baran, P., "On Distributed Communications: Introduction to Distributed Communications Networks", 1964, <https://www.rand.org/pubs/research_memoranda/RM3420.html>.

[BCP95]

Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.

<https://www.rfc-editor.org/info/bcp95>

[BODO]

Bodo?, B., Brekke, J. K., and J.-H. Hoepman, "Decentralization: a multidisciplinary perspective", Internet Policy Review, Vol. 10, No. 2, June 2021, <https://doi.org/10.14763/2021.2.1563>.

[CHAUM]

Chaum, D. L., "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms", Communications of the ACM, Vol. 24, No. 2, February 1981, <https://dl.acm.org/doi/10.1145/358549.358563>.

[CHRISTENSEN]

Christensen, C., "The Law of Conservation of Attractive Profits", Harvard Business Review, "Breakthrough Ideas for 2004", February 2004.

[ENPA]

Apple and Google, "Exposure Notification Privacy-preserving Analytics (ENPA) White Paper", April 2021, <https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ENPA_White_Paper.pdf>.

[FARRELL]

Farrell, H. and A. L. Newman, "Weaponized Interdependence: How Global Economic Networks Shape State Coercion", International Security, Vol. 44, No. 1, p. 42, 2019, <https://doi.org/10.1162/ISEC_a_00351>.

[FREEMAN]

Freeman, J., "The Tyranny of Structurelessness", Berkeley Journal of Sociology, Vol. 17, 1972, <https://www.jstor.org/stable/41035187>.

[HTTP]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[I-D.thomson-tmi]

Thomson, M., "Principles for the Involvement of Intermediaries in Internet Protocols", Work in Progress, Internet-Draft, draft-thomson-tmi-03, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-thomson-tmi-03>.

[ISOC]

Internet Society, "Consolidation in the Internet Economy", Internet Society Global Internet Report, 2019, <https://future.internetsociety.org/2019/>.

[JUDGE]

Judge, K., "Intermediary Influence", University of Chicago Law Review, Vol. 82, p. 573, 2014, <https://scholarship.law.columbia.edu/faculty_scholarship/1856>.

[KENDE]

Kende, M., Kvalbein, A., Allford, J., and D. Abecassis, "Study on the Internet's Technical Success Factors", December 2021, <https://blog.apnic.net/wp-content/uploads/2021/12/MKGRA669-Report-for-APNIC-LACNIC-V3.pdf>.

[LESSIG]

Lessig, L., "The New Chicago School", Journal of Legal Studies, Vol. 27, June 1998, <https://www.journals.uchicago.edu/doi/10.1086/468039>.

[MADISON]

Madison, J., "The Structure of the Government Must Furnish the Proper Checks and Balances Between the Different Departments", The Federalist Papers, No. 51, February 1788.

[MOXIE]

Marlinspike, M., "Reflections: The ecosystem is moving", May 2016, <https://signal.org/blog/the-ecosystem-is-moving/>.

[MUSIANI]

Musiani, F., "Alternative Technologies as Alternative Institutions: The Case of the Domain Name System", The Turn to Infrastructure in Internet Governance, 2016, <https://link.springer.com/chapter/10.1057/9781137483591_4>.

[OECD]

OECD, "Data portability, interoperability and digital platform competition", June 2021, <https://www.oecd.org/daf/competition/data-portability-interoperability-and-digital-platform-competition-2021.pdf>.

[OLUMOFIN]

Olumofin, F. and I. Goldberg, "Revisiting the Computational Practicality of Private Information Retrieval", 2010, <https://link.springer.com/chapter/10.1007/978-3-642-27576-0_13>.

[PALLADINO]

Palladino, N. and N. Santaniello, "Legitimacy, Power, and Inequalities in the Multistakeholder Internet Governance", 2020, <https://link.springer.com/book/10.1007/978-3-030-56131-4>.

[PRIO]

Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust, and Scalable Computation of Aggregate Statistics", March 2017, <https://crypto.stanford.edu/prio/paper.pdf>.

[RFC1035]

Mockapetris, P., "Domain names – implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.

[RFC5218]

Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/rfc/rfc5218>.

[RFC5321]

Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/rfc/rfc5321>.

[RFC6120]

Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/rfc/rfc6120>.

[RFC7258]

Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/rfc/rfc7258>.

[RFC791]

Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/rfc/rfc791>.

[RFC793]

Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/rfc/rfc793>.

[RFC8890]

Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, <https://www.rfc-editor.org/rfc/rfc8890>.

[RFC9230]

Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. Wood, "Oblivious DNS over HTTPS", RFC 9230, DOI 10.17487/RFC9230, June 2022, <https://www.rfc-editor.org/rfc/rfc9230>.

[SCHNEIDER]

Schneider, N., "Decentralization: an incomplete ambition", Journal of Cultural Economy, Vol. 12, No. 4, 2019, <https://osf.io/m7wyj/>.

[SOAP]

Mitra, N. and Y. Lafon, "SOAP Version 1.2 Part 0: Primer (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part0-20070427, 27 April 2007, <https://www.w3.org/TR/2007/REC-soap12-part0-20070427>.

[SPULBER]

Spulber, D. F., "Solving The Circular Conundrum: Communication And Coordination In Internet Markets", Northwestern University Law Review, Vol. 104, No. 2, 2010, <https://wwws.law.northwestern.edu/research-faculty/clbe/workingpapers/documents/spulber_circularconundrum.pdf>.

[VESTAGER]

Vestager, M., "Defending Competition in a Digitised World, Address at the European Consumer and Competition Day", April 2019, <https://wayback.archive-it.org/12090/20191129202059/https://ec.europa.eu/commission/commissioners/2014-2019/vestager/announcements/defending-competition-digitised-world_en>.

[YAO]

Yao, A. C., "Protocols for secure computations", SFCS '82, November 1982, <https://dl.acm.org/doi/10.5555/1382436.1382751>.

附录A. 鸣谢

本文件得益于我们在互联网架构委员会共同工作期间与Brian Trammell的讨论。

感谢Jari Arkko、Christian Huitema、Eliot Lear和Martin Thomson的评论和建议。

作者的地址

Mark Nottingham

Prahran

澳大利亚

电子邮件: mnot@mnot.net

URI: https://www.mnot.net/