去中心化主张：分开共识与访问依赖

去中心化主张只有落到具体功能上才便于研究：某项服务消失后，用户还能做什么？参与共识、提交交易、读取状态、修改合约和访问网站是不同功能，不能因为其中一层分散，就把整个资产描述成没有任何中心依赖。

以太坊权益证明威胁说明讨论共识行为与防御，并不替某个钱包、网站或RPC服务背书。本文把其他访问层拆成工作表，是研究者的方法，不是协议官方发布的评级。

把口号改成服务问题

先写下用户的确切动作：读取余额、构造交易、广播交易、获得打包、确认最终性，或者改变协议规则。逐步标注所用组件与相关方。某应用前端可能只有一个入口，即便底层合约另有调用方式，用户的日常操作仍有集中依赖。

对每条依赖，要区分“文档写有替代方案”和“目标用户具备可用替代方案”。自己运行节点在技术上可行，不代表普通读者已经具备设备、历史数据、技能与配置。不能因为另一种架构理论上存在，就宣布现有依赖已经消失。

管理权限必须另列。更换前端不能取消合约管理员的特权，代码固定也不能恢复被阻断的网站。这些层会互相影响，但无法相互替代。每种替代方案都应说明它解决哪一种故障，以及哪些依赖仍然存在。

假设一个虚构现货资产应用只有一个官方网站，文档列出两种RPC选择，还公布合约接口。网站停止响应后，准备充分的技术读者可能从另一工具构造交易，但依赖网页的读者不能马上继续操作。

准确结论应分两部分：官方界面当前不可用；文档提供了另一交易路径，且有明确前提。不能直接说全部资产损失，也不能说所有用户完全不受影响。仅观察到网站中断，无法推出其中任何一个结论。

再假设两种RPC品牌实际上依赖同一家上游提供商。表面选择数量就高估了独立性。有证据时标注共同上游，没有披露时保留未知。本例是功能依赖的假设演示，不评价任何真实项目。

补充观察日期、用户准备条件、尚未确认的上游。每项结论写成完整句子：“该功能在这些条件下仍可完成。”这比给一个总分更有用，因为总分容易掩盖用户真正需要的那一层。

可先进行只读核对：阅读替代路径文档、检查服务归属披露、比较接口要求。没有实际恢复演练，就不能把文档路径写成已经测试成功。今天可访问的端点，也不能证明未来一直可用。材料应标记“文档确认”“当前观察”“尚未演练”等不同证据状态。

还要区分正常使用的便利与故障状态的可行性。如果替代路径需要归档数据、特殊软件或另一方签名，它与日常点击界面有实质区别。把这些前提写入备忘录，复查者才能判断可替换程度，而不是只看到一个看似充分的备用链接。

常见错误包括把品牌数当独立基础设施数量、用验证者数量回答网站访问问题，以及把开源误认为线上服务持续可用。最后的研究结论应指出集中在哪些功能、哪些证据仍缺失，不预测停机概率、参与方意图或现货价格。

不能。网站托管和交易访问都有自己的依赖与替换条件，需要单独核对。

不能。还要确认所需调用、数据、权限和网络条件，才能描述替代路径是否可用。