IBC客户端过期后怎么恢复？

IBC通道依赖链上轻客户端验证对方链状态。客户端长时间没有收到新头、超过trusting period后，会进入Expired，而不是简单的“Relayer卡住”。恢复的核心也不是重启中继器，而是让治理认可一个仍然活跃、参数兼容的替代客户端，把可信状态迁回原来的subject client。

先判断是落后、过期还是冻结

落后的客户端仍在信任期内，Relayer通常可以连续提交头追上链头；过期客户端已经不能再用旧可信状态验证跨越信任期的新头；冻结客户端则通常因为提交了可验证的misbehaviour证据。三种状态的处理权限不同。

状态	普通更新是否可用	首要证据
Active但落后	通常可以	latest height与剩余信任时间
Expired	不可以	最后共识时间与trusting period
Frozen	不可以	frozen height与冲突头证据

查询时要同时保存subject client ID、chain_id、latest height、trusting period和节点时间，避免把RPC缓存或本地时钟误差写成过期。

替代客户端不是随便新建一个

恢复提案中的substitute client必须代表同一对手链，并与subject client具有兼容的客户端类型和关键链参数。文档示例要求除latest height、frozen height和chain ID等允许差异外，客户端参数保持一致。替代客户端本身必须处于Active，并在治理投票期间持续更新，避免提案通过时它也已经过期。

创建替代客户端之后先独立核对其共识状态与对手链头，再提交治理消息。只看“客户端创建交易成功”不够，因为错误的对手链、信任参数或升级路径会让恢复在执行阶段失败。

治理恢复经过哪些状态

一个稳妥的恢复记录可以拆为五步：确认subject状态、创建并维护substitute、提交MsgRecoverClient提案、等待链上投票与执行、重新查询subject的最新高度和状态。每一步都有独立交易哈希或查询证据。

提案通过只是治理授权完成；仍应确认执行事件确实写入客户端状态。提案被否决、存款不足、投票期内substitute过期或参数校验失败，都不能靠重复广播旧消息解决。需要先定位失败层，再决定重建替代客户端还是重新提案。

客户端恢复不会自动补救所有数据包

subject client恢复后，依附它的连接和通道重新获得验证对方状态的能力，但先前数据包仍有自己的sequence、acknowledgement、timeout height和timeout timestamp。已经超时的数据包可能需要在源链提交timeout证明并由应用回滚；已在目标链执行但回执未带回的包，则需要Relayer补交acknowledgement。

因此验收不能只看客户端由Expired变成Active。还要按通道列出未完成packet，分别核对目标链receipt、ack写入、源链ack处理或timeout结果。资产应用的退款和凭证销毁属于应用逻辑，IBC核心不会替它决定。