客户端多样性：识别共同故障依赖

客户端多样性研究要判断的是，看似独立的验证者是否可能因同一段软件而一起故障。只知道运营者数量无法回答这个问题。需要把共识客户端、执行客户端、版本和运营服务放进依赖矩阵，并明确哪些字段来自观察，哪些只是估计。

以太坊客户端多样性文档说明多种客户端实现对系统韧性的意义。这是机制资料，不是任何运营者当前安装分布的调查。实际分布仍要依靠注明日期的披露或可复现测量，不能把文档中的原则变成实时统计。

软件独立与组织独立分开

先写清所研究的故障。共识实现错误、执行实现分歧、共享云区域中断，影响的集合并不相同。应把它们列为不同情景，而不是压缩成一个没有定义的去中心化分数。只有具体到故障路径，分组才具有解释力。

对每个已识别运营者，同时记录执行客户端与共识客户端。只知道一侧，仍有重要依赖尚未解决。有版本资料时继续记录，并区分运营者主动披露的版本与外部指纹推断的版本。外部识别方法可能漏掉私有节点或受到配置影响，不能无条件当作精确人口普查。

缺少字段就保留未知。某服务商说支持四种客户端，只能证明可选项存在，不能证明线上验证者各占多少。安装指南同样不等于真实部署证据。把支持列表误写为部署比例，会让看似严谨的矩阵建立在虚构统计之上。

假设三个虚构运营者各控制二十份有效权重，治理彼此独立，但都使用执行客户端E，共识客户端则不同。一个执行客户端专属缺陷可能影响六十份权重，尽管没有任何组织单独控制这六十份。

第四个运营者控制十五份权重，使用另一种执行客户端，却与前两个运营者共用托管区域。若发生区域中断，受影响集合就与软件缺陷情景不同。剩余二十五份没有客户端披露，应分别展示每种情景的已知受影响权重与未知权重。

不能把两个情景的总数相加，当作相互独立的损失，因为其中有重叠。矩阵的意义就是保留重叠关系，解释为什么增加组织数量不必然消除技术相关性。本例所有组织、名称和权重都是假设，不描述真实网络分布。

逐情景计算“已知暴露权重除以全部观察权重”，并在比例旁展示未知部分。可以假设未知部分全部或完全不使用某实现，形成敏感性范围，但端点只是情景假设，不是测量得到的统计置信区间。分母应与验证者集中度研究保持一致，避免两个看似可比的比例实际用了不同集合。

跨期比较必须检查测量方法是否相同。如果指纹算法更新，显示的多样性可能改变，但验证者没有换任何软件。保存识别方法，并把暂时无法解释的跳变列为测量断点，不直接写成真实改善。

还需区分替换发生在故障之前、故障期间，还是人工处理之后。存在另一个客户端，不代表故障时可以立即切换。恢复取决于预案、兼容性和具体故障，不能随意给出统一恢复时间。运营者是否公开演练，也与“理论上可替换”是不同证据。

最终备忘录应报告已观察客户端组合、重要重叠和未解决字段，说明集中来自共享代码、共享基础设施还是测量不确定性。代码经过审计，也不能替代分布证据；广泛采用的已审计实现仍然可能构成共同依赖。

不能。控制权独立的验证者仍可能运行相同实现，因同一软件原因受影响。

不能。支持的选项与实际部署比例是两项主张。没有部署证据时，应把比例保留为未知。