区块链（43）：Cosmos 与 Avalanche 是两条不同的应用链路线的应用链可能各有验证者或互操作规则。Polkadot 历史设计强调 relay chain 与 parachain 在验证和跨链消息层的分工：应用链生产自己的候选状态，底层共享验证体系对其有效性和可用性承担约定责任。不能只因链之间可以发消息就推断它们共用安全，也不能把 relay 链想象成以太坊 L1 的复制品。 
flowchart TD
  A[应用交易/平行链执行] --> C[候选块/状态承诺]
  C --> V[relay 验证与可用性条件]
  V --> F[共享共识/最终性]
  A --> M[跨链消息通道]
  M --> P[另一平行链应用]
  F --> M

网络若允许链自定义执行 VM，应用错误仍可能给出不符合验证函数的状态转移；跨链消息还要约定顺序、重试和超时。共享安全范围受实际加入方式、验证者分配和当前协议版本限制，不能从早期白皮书断言今日每条应用链均按原结构运行。JAM 等演进提案如无主网激活资料，不写成已上线设计。与 Cosmos IBC 的主要比较点是验证权和互操作通道从哪里来，而不是吞吐排名。

对照 Cosmos 和 Avalanche 时问同一组问题

一笔跨应用链的合成付款至少走“源链资产状态→跨链消息可证明→目标链执行→收款人可兑现”。Polkadot 历史方案的 relay 验证路径让应用链共享一部分底层验证者与数据可用性规则，但不能把源应用业务逻辑错误消除；目标平行链也须按它自己的状态规则消费消息。Cosmos 生态里的 IBC 通常强调两端分别运行链与轻客户端，不应误以为 Cosmos Hub 统一给所有链签安全证书。Avalanche L1 又可能有自己成员与 VM，消息桥必须解释信任从哪条链转到另一条。三条路径的协议部署、治理权限和退出时间不能用同一个交易确认数概括。

如果中继或 relayer 消失，应问消息是只延迟投递还是资产可能已在来源锁住而目标永久不可达；如果 relay 或目标链升级，谁能改变验证函数、旧跨链消息是否重放，历史数据如何保留。Polkadot 的路线图项目 JAM 及其它网络升级在没有主网激活与实现来源前只视为提案，不加入现行架构图。用户选择应用链时，应按该链目前使用的验证者、消息格式、可用数据和管理员权力独立核对。当前无法进行链间运行测试，所以本文交付的是依赖对照而非性能排名。

练习一：A 链通过 relay 链完成有效性验证，B 链的应用代码必定没有逻辑漏洞吗？答案：不能，验证器只按被定义的状态规则验证。练习二：relay 共识最终确认一条跨链消息，目标链处理失败能否直接宣称业务交付？答案：不能，还要跟踪目标执行及恢复。当前原文/客户端不可用，对照只到机制层，真实链间消息 NOT_RUN。

可迁移原则：共享验证范围与应用语义各有负责方。参考：Polkadot docs、Polkadot spec（部署状态/SHA 待核）；导航：区块链（E06）：CID、存储证明与能下载交付文件之间差多少 · E07 · 区块链（E08）：有限模型、fuzz 与形式化证明的边界。