English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC051
区块链应用可能无法使用，而底层链仍在运行。应用可能依赖网站、名称解析路径、托管RPC网关、搜索索引、签名界面或外部文档存储。诊断时，应先说清用户要完成什么，再追踪这项任务实际需要哪些组件。
两个名称不同的端点，并不能证明有两条独立路径。反过来，失去一个便利服务，也不能证明读取链的所有方式都已消失。真正有用的问题是：在题目给出的故障下，哪些功能仍然可用？拟议替代路径又改变了哪些假设？
本文用虚构博物馆目录来回答这些问题。它是一项架构练习，不涉及真实端点、凭证、交易提交或生产系统变更。依赖边都是明确给出的假设，不是对某个服务商的事实断言。
选择适合你的阅读路线
本篇目录
- 1. 先定义任务，再画网络
- 2. 博物馆的给定组件
- 3. 四项功能，四种不同约定
- 4. 第一组故障：先预测，再解释
- 5. 共享网关改变了答案
- 6. 找出R的最小故障集合
- 7. 共享网站故障属于另一层边界
- 8. 备用路径可能改变信任假设
- 9. 外部内容增加了第二个可用性问题
- 10. 让练习表有用，同时守住结论范围
- 11. 练习与答案
- 12. 常见问题
- 资料来源与继续阅读
第1至3节建立应用地图；第4至7节进行故障计算，并分析共享网关；第8至10节说明如何理解备用路径，而不夸大其恢复能力。练习答案可用于完整核对主要推理。
若需了解依赖、传播和隔离的一般机制，可阅读耦合如何运作。本篇把该基础应用到具体区块链功能，不对网络去中心化程度进行排名，也不重复一般性的级联故障讨论。
1. 先定义任务，再画网络
“应用正常”太宽泛，难以测试。访客可能需要搜索目录，管理员可能需要把获授权的更新交给节点，研究者可能需要获取目录所指向的文档，技术人员则可能只需要读取某个确定区块上的一项记录。
这些任务有重叠，却不能互相替代。搜索可能失败，直接读取记录却成功；文档可能无法取得，链上引用却仍可读取；只读诊断可能正常，却既不能签名，也不能提供合格的公众界面。
以太坊JSON-RPC文档描述了应用读取数据、向节点发送交易所用的接口，并区分执行客户端RPC、共识客户端接口和客户端间接口。这足以确立一个重要边界：应用接口是通向节点的路径，不是整个网络。以太坊JSON-RPC API
每项任务都应写出成功条件。目标若是“取得指定区块上的指定记录”，就不能仅用“收到响应”代替；目标若是“已纳入且执行成功”，就不能只写“已提交”。依赖图只能解释它实际定义的任务。
2. 博物馆的给定组件
虚构应用包含以下组件。标为正常的组件，被假定能针对本次请求正确履行规定职责；标为故障的组件，在练习期间无法履行该职责。本例不模拟部分损坏、慢响应或恢复时间。
- D：新访客会话使用的名称解析路径。
- F：公众前端及其必需资源。
- I：目录索引服务，所需覆盖范围已得到确认。
- X：两条RPC路径都必须经过的共享托管网关。
- P和Q：两个分别命名的RPC路径服务。
- Np和Nq：分别供P和Q使用的节点后端。
- W：管理员正常工作的签名界面，并具有适当的既有权限。
- G：文档网关。
- V：该网关可访问的保留文档副本。
- T和M：已准备好的诊断工具及其独立节点连接。
两条托管路径为X→P→Np和X→Q→Nq。选定路径上的每个组件都不可缺少；任一完整路径即可支持托管RPC功能R。图中没有绕过X的路径。
T和M被明确设定在这些托管依赖之外。诊断工具已可使用，知道正确网络和指定区块，在本练习中不依赖D、F、X、P或Q。这些是题目给出的强假设，不能仅凭工具标志不同就自行推断。
3. 四项功能，四种不同约定
目录搜索需要D、F、I和R。本例索引服务处理请求时，必须执行一次RPC检查，因此即使已有索引数据，托管路径仍不可缺少。其他应用可能可以直接提供缓存搜索结果，但本例不允许。
文档查看需要D、F、G和V。这项任务的正确文档标识由题目独立提供，因此不会暗中增加一次先搜索目录的要求。如果必须通过搜索取得标识，就应在图中增加这项依赖。
已签名请求交接需要D、F、W和R。成功表示：在题目条件下，正确获授权的请求到达正常工作的节点接口。它不表示区块纳入、执行成功或最终性；这些后续结果被明确排除在该功能约定之外。
独立诊断读取需要T和M。在给定节点与上下文假设下，它提供指定的只读答案，但不恢复搜索、不取得外部文档字节，也不能签署更新。
对于R，X必须正常，且至少有一条完整后端路径正常。简写就是：X，并且“P与Np”或“Q与Nq”至少一组正常。“或”允许两组同时正常；“与”要求所列组件全部正常。这些规则构成玩具可用性模型的全部定义。
4. 第一组故障：先预测，再解释
从所有组件正常开始，四项功能都能按各自约定工作。下面每张卡只改变所列条件；进入下一张卡前，其余组件都重置为正常。
卡A：I故障。 目录搜索失败。文档查看、已签名请求交接和独立诊断读取仍可使用。给定图中，索引不是这三项功能的前提。
卡B：G故障。 文档查看失败。搜索、交接和诊断读取仍可使用。网关故障不能证明V已被删除，只能说明这条文档访问路径不可用。
卡C：W故障。 交接失败，因为所需签名功能缺失。搜索、文档查看和诊断读取仍可使用。能读取链上记录，不能代替缺失的签名能力。
卡D：P故障。 四项功能仍可使用，因为X、Q和Nq仍支持R。这是一条模型中真实存在的替代路径，而不是故障发生后临时想象出的路径。
这些结果来自明确给出的依赖边，不需要预测真实停机，不需要建议修改生产配置，也不需要声称某组件的故障概率是多少。
5. 共享网关改变了答案
卡E：X故障。 尽管P、Q、Np和Nq正常，两条托管路径仍同时失败。目录搜索和已签名请求交接不可用；文档查看与独立诊断读取继续工作，因为给定模型中它们都不使用X。
若报告写成“两家RPC服务独立发生故障”，就超出了证据。题目给出的原因是一个共享依赖。路径名称不同，并没有消除对X的共同依赖。
再看卡F：P与Nq同时故障。第一条路径在P处中断，第二条在Nq处中断。虽然Q和Np正常，R仍失败。当正常服务与正常节点分属不同路径，而且模型没有跨接线时，仅有这两个正常组件还不够。
这是读图的重要测试。人们很容易数出两个幸存组件，就宣称系统仍有冗余。但功能需要完整路径，不是只看正常方框的总数。若新增Q到Np的连接，就改变了图，不能悄悄把它放进答案。
卡E和卡F中，诊断读取都仍可工作。这个观察证明的是指定独立读取路径可用，不能证明每个网络参与者都正常，也不能证明链的所有功能都在正常推进。
6. 找出R的最小故障集合
最小故障集合，是指该组组件同时故障会使目标功能失效，而其中任何真子集都不足以使目标失效。“最小”表示没有多余成员，不一定表示在所有集合中组件数量最少。
对于托管RPC子系统R，完整列表是：
- 只有X。
- P与Q。
- P与Nq。
- Np与Q。
- Np与Nq。
为什么恰好五组？X若故障，模型内无论选择哪个后端都无法恢复R。X若正常，就必须同时破坏两条后端路径。破坏第一条需要P或Np故障，破坏第二条需要Q或Nq故障。分别从两组中选一个，就得到四个二元组合。
对于每个二元组合，若移除其中一个故障、其余组件均正常，就会恢复一条完整路径，因此这些集合确实最小。P、Q、Np同时故障也会禁用R，但该集合不是最小的，因为P与Q已经足够。
这份列表只针对R，不是整个应用的全部故障集合。只有D或F故障，就可能使目录搜索失效，而R本身仍正常。只有I故障会禁用搜索，却不禁用交接。因此，提出割集结论时，必须同时写明目标功能。
题目没有给出故障概率。这份列表不能告诉我们哪种事件最可能、多久发生一次，或数字化的正常运行百分比。它只说明模型中哪些组合在结构上足以造成失效。
7. 共享网站故障属于另一层边界
卡G：新访客会话的D故障。 搜索、文档查看和交接都失败。独立诊断读取仍可用，因为准备好的连接被明确设定为不依赖D。若某会话允许使用已缓存的解析结果，答案可能不同，但本例没有这条路径。
卡H：F故障。 同样三项公众界面功能失败，T和M仍可使用。这不表示普通访客已经拥有诊断工具，或具有解释其结果所需的知识。
这些卡揭示了技术可达性与服务恢复之间的区别。维护人员有一条读取路径，不会自动让博物馆的公众搜索界面恢复可用。如果承诺的服务包括无障碍展示、搜索筛选和清晰结果，这些要求就应写入成功约定。
不要从网站故障推断整个区块链停止，也不要因为某节点仍有响应，就淡化严重的用户服务中断。两件事可以同时成立：应用没有满足用户需求，而现有证据不能说明链已经停止。
8. 备用路径可能改变信任假设
独立路径之所以有用，是因为模型明确提供了它所需的条件。真实审阅中，这些条件需要证据：正确网络、预期区块上下文、支持的查询、足够的数据，以及明确的答案来源。
以太坊节点文档描述了不同节点能力，以及执行客户端和共识客户端的关系。因此应说明某条节点连接实际提供什么，而不能把它当作所有服务的通用替代品。以太坊节点与客户端
假设备选项不是预先准备的T与M，而是另一个区块浏览器的截图。它可能是值得调查的证据，但不会自动继承诊断工具的假设。来源、观察时间、网络上下文和验证责任都已经改变。
类似地，两个相同答案可能共用上游数据源。一致性可以提供信息，却不能证明独立性。图中应记录已知的共享服务商、网关、数据源或配置依赖；无法确认独立时，就标为未知。
备用路径评估应同时说明能力与限制：“在这些假设下，该路径能回答指定读取问题，但不能提供缺失的签名功能。”这比笼统宣布整个应用恢复更清楚。
9. 外部内容增加了第二个可用性问题
目录可以存储文档引用，而文档字节保存在别处。引用与检索路径应放在地图的不同位置。在玩具模型中，V表示保留的字节，G表示配置好的访问网关。
IPFS文档说明，内容持久保存依赖节点保留数据，其中pinning机制可以保护保留内容不被垃圾回收删除。文档也提醒，第三方pinning服务不保证永远持续。因此，内容寻址引用仍需要说明保留与检索安排。IPFS持久保存与pinning
G故障而V仍在时，给定路径中断，但保留副本仍然存在。V故障而G正常时，正常网关也不能制造缺失字节。若有另一副本或网关，应先明确加入模型再重新计算；不能只因系统原则上支持复制，就假定它实际存在。
这是依赖练习，不是历史数据发布评估，也不是证明所有副本都消失。一次失败请求支持关于观察路径的结论；全球范围的不存在，是需要其他证据的更强主张。
10. 让练习表有用，同时守住结论范围
有用的应用地图应包括被测试功能、组件职责、必需与替代依赖边、观察条件，以及排除项。真实依赖边应附带依据，而不是仅凭服务商名称或架构口号画出。
二元模型的限制是有意保留的。真实依赖在慢响应、容量耗尽、陈旧缓存或数据不一致时，可能表现不同。看起来正常的组件，也可能返回不符合请求上下文的答案。因此，在本入门计算之外，还应分别检查可用性与答案正确性。
同样，一条逻辑上存在的备用路径，未必有能力在切换后承担全部负载。本例只假设每条完整路径能满足这一次请求，没有证明它能满足高峰时所有用户的需求。
宣称某项重新设计具有韧性前，应问：图发生了什么变化，信任假设又发生了什么变化？在X后增加另一个品牌，不会消除X这个单点故障；增加独立只读路径可能有助诊断，却仍不能提交；移除必需依赖可能提升可用性，但若未谨慎重新设计功能，也可能移除必要检查。
练习结果应是有边界的陈述，而不是产品推荐：“在这些条件下，此功能能承受这些故障，同时仍依赖这些组件。”
11. 练习与答案
问题1。 X正常，但P和Nq故障。因为Q和Np正常，R就能工作吗？
答案。 不能。没有完整的给定路径。Q连接Nq而不是Np，两条原路径都已中断。
问题2。 I故障时，哪些功能仍可使用？
答案。 文档查看、已签名请求交接和独立诊断读取。目录搜索失败。文档标识独立提供，因此文档任务不依赖搜索。
问题3。 X与P是R的最小故障集合吗？
答案。 不是。只有X就能禁用R，P是多余成员。
问题4。 公众前端故障，但T与M完成指定读取，公众应用是否已恢复？
答案。 没有。诊断能力仍在，但模型中的公众界面功能仍不可用。
问题5。 报告声称两个端点带来99.99%的可用性，图能核实这个数字吗？
答案。 不能。没有给出组件概率、相关性模型、观察窗口或实际服务结果。结构性路径计算不能产生运行时间估计。
问题6。 V正常而G故障，是否意味着文档一定已删除？
答案。 不是。情境卡明确保留了副本，故障涉及配置好的检索路径。
12. 常见问题
节点正常能证明应用正常吗？
不能。任务可能还需要前端资源、索引、签名能力或外部内容，应追踪完整任务。
两家服务商一定优于一家吗？
问题缺少条件。应确定哪些依赖真正独立，以及每条路径能满足哪项功能。玩具模型说明，两条路径若共用必经网关，就仍有这个共同故障点。
只读备用路径会授权新操作吗？
不会。它只在给定假设下提供读取能力，不会创造签名权限或变更系统的许可。
这是一项生产可靠性测试吗？
不是。它是明确的模型和检查结论的方法。实际可靠性工作需要核实架构、相关负载、正确性检查和受控操作程序。
资料来源与继续阅读
一手文档核查日期为2026年10月12日：
- 以太坊JSON-RPC API，用于界定应用与节点接口。
- 以太坊节点与客户端，用于理解具体节点能力。
- IPFS持久保存与pinning，用于理解保留内容的依赖。
博物馆、组件标签、功能约定、故障卡和最小集合计算均为原创教学构造，其结论以明确给出的图为条件。