English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC030
一个网络可以有许多可见节点，却由少数运营者控制大部分投票权重。它可以让共识参与较分散，但某个应用仍依赖单一 RPC 提供商。它也可以使用多种客户端，同时把某项升级权限集中在一个控制者手中。这些是不同控制问题，单一节点数量不能全部回答。
本篇为虚构档案网络建立多维控制工作表。你将计算几个简单份额，识别不同分母，并解释为何把它们合成一个没有说明的分数，会隐藏重要信息。以下统计不描述任何真实区块链；课程不对当前网络排名，也不推荐投资。
选择适合你的阅读路线
本篇目录
- 1. 先提出问题，不急着排名
- 2. 虚构档案网络
- 3. 十二个实例不等于十二个独立运营者
- 4. 投票权重回答另一个问题
- 5. 托管集中衡量的是依赖
- 6. 软件多样性关注相关行为
- 7. 应用的 RPC 依赖不是整个网络
- 8. 治理与升级密钥形成另一层控制
- 9. 为什么不能把这些百分比直接平均
- 10. 每一行都加上证据质量和时间
- 11. 检验具体问题，而不是宣布赢家
- 12. 六道练习与答案
- 13. 常见问题
- 资料来源与下一步学习
先看“问题与分母”规则，再分析档案网络的运营者、投票、托管与软件记录。评估应用时，还应阅读 RPC 及升级控制两节。最后工作表与练习说明：如何报告不确定性，而不是用误导分数取代它。
更广泛的决策分配讨论，可参考中心化与去中心化：决定应该在哪里作出？。本篇聚焦区块链可测量的技术控制与依赖，不泛论政治制度。
1. 先提出问题，不急着排名
“这个区块链去中心化吗？”过于宽泛，无法由一次测量回答。更好的问题是：谁能影响某项决定、中断某项服务，或提供应用所依赖的证据？
可以询问谁提议或投票决定区块、谁运营相关签名设施、某组参与者运行什么软件、服务托管在哪里、用户依赖哪些接口，以及谁能更改应用权限。每个问题都有自己的计量单位。
报告应说明系统边界与观察窗口。测量一个档案应用的请求，不等于测量所有用户对底层网络的访问；某时点的可达节点数量，也不能确立全部验证者的所有权。
问题明确后，再定义分母。没有分母的百分比很容易混淆。节点、有效投票权重、观察到的请求、组织和签名密钥，并不是可互换的单位。
2. 虚构档案网络
课堂网络共有十二个节点实例。运营者 A 运行六个，B 运行四个，C 运行两个。题目把这些控制关系作为事实提供，并不是根据 IP 地址或相似行为推断出来的。
网络总投票权重为 100 单位，另行分配为 A 45、B 35、C 20。托管商 X 托管八个节点实例，Y 托管四个。客户端实现 M 用于九个实例，N 用于三个。
在指定的合成观察窗口中，档案应用发出 100 次 RPC 请求，85 次到提供商 R，15 次到 S。这些是应用请求数，不是共识投票，也不是全网使用份额。
最后，虚构应用升级政策要求三把签名密钥中的两把。A 控制两把，B 控制一把。题目假定没有其他审批层或延迟条件。该政策针对档案应用，不针对底层区块链协议。
这些记录刻意描述不同维度。我们没有完整的逐节点映射，无法把运营者、软件、托管及投票权重全部对应起来。这张交叉表的缺失，限制了可计算的组合故障情景。
3. 十二个实例不等于十二个独立运营者
A 运行 6/12，即 50% 的实例；B 占三分之一；C 占六分之一。题目给出的是三个运营者，不是十二个独立决策实体。
节点数对其定义好的用途仍然有价值：它说明练习包含多少实例。但如果问题关注独立管理决定，运营者分组就比原始数量更相关。
真实研究中，运营者标签本身也可能需要核查。两家公司可能具有共同所有权、把签名委托给同一服务，或依赖同一管理团队。反过来，同一服务也可能托管独立控制的客户系统。公开名字本身不能解决这些关系。
负责任的报告应区分直接观察到的实例，与声称或已验证的控制关系。本题直接提供后者；真实测量则需要来源及不确定性标签。
这延续身份计数问题，但任务变为解释实测资料。我们不是询问如何创造更多身份，而是询问已有测量究竟说明什么控制事实。
4. 投票权重回答另一个问题
A 的投票份额为 45%，不是其节点实例份额 50%。B 为 35%，C 为 20%。两种分布不同并不矛盾，因为模型没有规定每个实例一张等值票。
假设另一条课堂决策规则要求严格超过 100 单位投票权重的三分之二。A 单独达不到；A 与 B 合计 80，可以达到；A 与 C 合计 65，不够；B 与 C 合计 55，也不够。
这个算术只回答指定阈值问题，不是完整攻击成本估算、串通证明或通用共识安全性评估。不同动作可能具有不同阈值及其他规则。
不要悄悄把投票权重换成财富、法律所有权或运行控制。委托和托管可以使经济所有权与指挥协议行动的能力分离。真实报告应说明数据衡量的是哪一种关系。
题目也没有确立 A、B 必然协调。它只是说明，按假想联盟计算，给定分配允许什么。能力与已经观察到的意图，是不同主张。
5. 托管集中衡量的是依赖
X 托管十二个实例中的八个，即三分之二；Y 托管四个，即三分之一。这衡量实例放在哪里，不是签名密钥所有权，也不是共识权重份额。
如果在假想练习中 X 不可用，八个托管实例可能受影响。但不能只凭托管数量计算损失多少投票权重，因为工作表没有说明哪些权重依赖哪些实例。
也不能假定同一提供商旗下所有服务在每次事件中都会一起失败。区域、网络、配置和服务边界可能重要。准确陈述是：共享提供商是值得检查的依赖，而某个具体故障情景还需更多细节。
节点表面地理位置也是不完整指标。IP 位置不能证明运营者住所、法律管辖地，或全部相关组件所在地。控制工作表不应把地理估计转成未经支持的法律结论。
因此，托管一栏很有用，却不是完整去中心化分数。它指出可能的共同依赖，同时保留未知部分。
6. 软件多样性关注相关行为
九个实例使用 M，三个使用 N，因此 M 占题设实例数的 75%。这不能确立它占 75% 投票权重；要作该判断，需要客户端与相关权重之间缺失的映射。
不同实现可以减少某一实现特有缺陷带来的暴露，但仅数产品名称不能证明独立性。客户端可能共享库、规范、依赖或运行配置。多样性需要明确分析层级。
以太坊客户端多样性文档讨论独立开发客户端及实现特定故障风险的重要性。本篇只采用概念，不沿用历史市场份额图，也不对当前采用情况排名。
在档案工作表中，如果知道某缺陷影响 M，就应询问哪些职责及权重依赖 M。不能只因九个实例运行 M，就声称恰好 75% 共识权力受影响。
对于区分执行与共识软件角色的系统，这个区别也很重要。合并成一个“客户端份额”栏，可能隐藏到底测量哪种组件。比较百分比之前，先给角色命名。
7. 应用的 RPC 依赖不是整个网络
档案应用观察到的 100 次请求中，85 次发给 R。这表示该窗口里应用请求的 85% 使用 R，不代表 R 控制区块链的 85%，也不代表它服务全部用户的 85%。
RPC 服务会影响可用性、应用取得什么数据，以及如何访问网络。以太坊节点服务文档介绍使用提供商设施，而非在本地运行全部所需节点的方式。由此产生的应用依赖，需要按自己的范围记录。
多个提供商名字，也不自动证明设施独立。它们可能共享上游服务或托管。工作表只提供请求目的地，不提供完整依赖图。
有用报告写法是：“档案应用测得的请求路径集中于 R，上游独立性尚未评估。”误导写法是：“该区块链有 85% 中心化。”后者同时改变了测量边界及含义。
本课不规定更换提供商，也不宣称某配置适用于每个应用。练习是定位依赖，并询问还缺什么证据。
8. 治理与升级密钥形成另一层控制
档案应用升级规则要求三把密钥中的两把。A 控制两把，因此能单独满足该教学规则。这确立的是给定规则下的技术批准能力，不证明机构已经授权某个具体变更，也不证明变更实际发生。三把密钥不等于三个独立决策者，两密钥阈值也不等于两个运营者批准。
这不表示所有多签安排都有相同问题。结论来自题设密钥控制映射及没有其他限制的假设。真实系统可能另有角色、延迟、否决权或限制，均需自己的证据。
应用升级权限也不同于协议治理。以太坊治理概述描述涉及不同参与方的过程，不是简单身份计数。部署在某网络上的应用，可能具有比底层协议治理狭窄得多的管理结构。
因此，控制工作表应询问权限能改变什么：替换应用逻辑、更改成员、调整参数，还是仅更新显示？不说明获准动作就数密钥，会漏掉真正重要的后果。
本节分析虚构权限政策，不授权移动密钥、调查所有权、投治理票或修改真实合约。
9. 为什么不能把这些百分比直接平均
现在有若干数字：A 控制 50% 实例、45% 投票权重；X 托管约 66.7% 实例；M 用于 75% 实例；R 接收一个应用 85% 请求。它们的对象与分母不同。
平均后确实会得到一个数，却没有得到有解释的测量。这个数预测什么事件？为什么请求份额应与升级权限同样重要？计算假定了哪些相关性或缺失资料？
只有目的、定义、加权方式与局限有依据时，综合分数才可能有意义。本课没有提供这样的模型。这里更合适的结果，是保留各行证据及不确定性的分维度控制表。
方向也可能不同。更多实例可能改善某种可用性，却不增加独立控制；更多提供商可能分散请求路径，却共享同一上游依赖。一个“越高越好”的轴，会隐藏这些区别。
10. 每一行都加上证据质量和时间
真实研究的每一行，需要来源、收集方法、日期或观察窗口、单位、覆盖范围及已知不确定性。公开节点扫描、运营者披露与应用日志，确立的是不同事实，局限也不同。
应分开已观察、推断和未知值。“观察到十二个入口”，弱于“确立十二个独立控制的签名权力”。来源只支持前者时，报告不能把后者当成直接观察。
覆盖范围也很重要。可达节点扫描可能遗漏非公开实例；客户端分类器可能误识别某些实现；运营者分组可能没有查明实际所有权。指出缺口会改善报告，不会让它失去价值。
时间重要，是因为分配和依赖会变化。不同月份收集的两个百分比，可能并不描述同一个一致网络状态。即使是概念工作表，也应记录共同快照假设，保证比较可解释。
11. 检验具体问题，而不是宣布赢家
回到档案网络，提出三个具体问题。单个题设运营者能否满足示例“严格超过三分之二”投票阈值？不能。单个运营者能否满足应用升级规则？能，A 可以。档案应用在该窗口是否大量使用一个 RPC 目的地？是，R 接收 85% 请求。
这些答案可以同时成立。它们彼此不抵消，也不会把网络变成简单的是非类别。真正有用的结果，是更清楚地描绘不同决定与依赖。
再问托管商 X 故障会怎样。我们知道八个实例在那里，却不知道对应投票权重分布或冗余行为。因此，“资料不足以判断共识影响”才是正确结论，不应靠虚构假设掩盖。
好的评估会指出回答问题所需的最少缺失证据。这里包括托管、职责与权重的映射，不需要收集每个相关人员的无关个人信息。
12. 六道练习与答案
- 十二个实例属于题设三个运营者，工作表确立多少独立运营者？在给定控制事实下，是三个，不是十二个。
- A 运行一半实例，是否因此拥有一半投票权重？不是。另行给定的权重为 45%。
- A 与 C 合并权重，能否通过严格超过三分之二的规则？不能，100 中的 65 低于阈值。
- M 用于十二个实例中的九个，能否说它代表 75% 投票权重？不能，所需映射缺失。
- A 控制三把升级密钥中的两把，规则要求两把，是否需要第二个运营者合作？在题设没有其他限制的情况下，不需要，A 单独控制足够密钥。
- R 接收档案应用 100 次请求中的 85 次，是否代表它的全网市场份额？不是，这只是给定窗口内档案应用的请求份额。
扩展练习：第二个应用的 100 次请求中，只有 10 次发给 R。合并这两个同样大小的窗口，R 接收 200 次中的 95 次，即 47.5%。这个合并样本仍不能确立全网使用情况，也不会改变第一个档案应用自身 85% 的依赖。
13. 常见问题
节点数量没有用吗？
不是。当问题确实关注所测实例时，它有用。错误在于把它当成所有其他独立性或控制的证明。
网络技术上分布广泛，应用控制仍可能集中吗？
可以。设施、共识和应用权限是不同层面。档案升级例子展示了这种区别。
共享软件是否说明运营者串通？
不能。共用软件可以造成相关技术风险，却不证明协调意图。行为、依赖与归因应分开。
报告应该避免数字吗？
不应该。应使用分母、来源、日期及局限清楚的数字，避免让数字假装回答超出数据支持范围的问题。
资料来源与下一步学习
主要概念资料于新加坡时间 2026 年 10 月 12 日核对：以太坊客户端多样性指南、节点服务指南及治理概述。本篇没有从这些页面采用当前网络份额或比较排名。全部档案数量、权重与权限，均为原创合成教学数据。
下一模块将从网络层假设转向交易机制。继续保留同样的习惯：把观察扩展成宽泛主张之前，先识别准确对象、规则与证据。