区块链（42）：Solana 的 PoH、账户并行与共识升级各做什么把一个验证者的传播、执行和投票拆开；这里对比的是多个应用网络如何各自定义这些职责。Cosmos 是 SDK、CometBFT/ABCI 和 IBC 等技术与生态组合，**Cosmos Hub 不等于所有 Cosmos 链**。Avalanche 把 P-Chain、C-Chain、X-Chain 等不同用途与 VM、子网/独立 L1 路线组合起来，不能把 C-Chain 的 EVM 行为说成每条 Avalanche L1 的默认语义。

Cosmos：应用、共识、跨链各有接口

flowchart LR
  U[用户交易] --> A[应用: Cosmos SDK 等状态机]
  A <--> B[ABCI 接口]
  B <--> C[CometBFT: 网络/排序/提交]
  A --> S[本应用链状态与验证者治理]
  S <--> I[IBC: 轻客户端/连接/通道]
  I <--> R[独立对端链 + relayer]

历史 Tendermint 路线后，CometBFT 延续共识引擎与 ABCI 应用接口分层；某条链使用 Cosmos SDK 不推出它和 Cosmos Hub 共用全部验证者。IBC 消息的安全来自两端对连接、证明、超时和对端状态的正确核验，relayer 是提交消息者，不是凭空创造互信的第三方。共享安全与 Cosmos EVM 属于具体可选架构，具体部署、已激活/未来功能需按链分别查，不可把生态路线图当所有链的主网配置。

Avalanche：多链职责与可定制 L1

flowchart LR
  U[交易请求] --> X[X-Chain: 资产相关语义]
  U --> C[C-Chain: EVM VM 与账户状态]
  U --> P[P-Chain: 平台/验证者管理]
  P --> L[Subnet/L1: 自己的 VM 与验证者规则]
  C <--> M[跨链/跨域消息边界]
  X <--> M
  L <--> M

Avalanche 各 VM 和网络的共识选择需要分别核对；历史白皮书对 DAG 的描述，不能代表如今每条链如何执行交易。Subnet 到 L1 验证者管理变化需要核对具体激活、费用和管理员规则；一个 L1 可拥有自己的验证者，不等于无条件继承其他链的交易正确性和退出权限。P/C/X 各自的状态与迁移也不应被“多链很快”一句代替。

跟踪一次跨链订单的授权边界

在 Cosmos 体系内，应用状态机先决定合成订单的有效性；CometBFT 型共识确定记录该状态变化的历史，ABCI 连接两者。IBC 的发送端状态承诺需要在接收链所维护的对端轻客户端假设下验证，relayer 把证明与消息递交给对端；收据、超时、通道或客户端失效分别影响重试路径。对端验收了数据也不代表实体商品交付。若一条应用链选择其他共识或不同账户层，就不能从“属于 Cosmos 生态”推定它使用完全相同的验证者名单；Cosmos Hub 不会替全部链自动签名。

在 Avalanche 体系内，P-Chain 的管理数据与应用执行所在的 C-Chain 或某个 L1 的账本并非同一份可花费状态。订单若从 C-Chain 迁到另一条 L1，先确定发起资产的锁定/销毁条件、目标链的消息验证权限、VM 执行结果和两端状态同步；单凭来源链交易已确认不能声称目标合约余额增加。网络名称与一个共享客户端程序也不能替代具体 VM、验证者集合和管理员变更时的迁移检查。

两条演进线的共同问题是“应用要谁的验证者、谁提供状态同步、跨链怎样验证”，但答案不同。练习一：IBC relayer 停机，对端历史是否因此自动变为无效？答案：不能这样推断；传递活性受影响，安全验证仍由两端协议和轻客户端决定。练习二：应用部署在一个 Avalanche L1，能直接把 C-Chain 交易回执当成本链终局证据吗？答案：不能，先核对消息桥、VM、验证者与确认规则。

本篇的“早期→变化→职责”是结构性草稿；CometBFT、IBC、AvalancheGo、Etna 等具体网络已激活状态、发布 SHA、验证者配置与真实链间消息均 NOT_VERIFIED / NOT_RUN。可迁移原则：对比应用链时同时写出成员、执行 VM 与跨域信任根。参考：CometBFT、IBC、Avalanche 节点架构（未抓取）；导航：区块链（42）：Solana 的 PoH、账户并行与共识升级各做什么 · 43 · 区块链（44）：Sui 对象与 Aptos 账户不是一个 Move 数据模型。