区块链（45）：钱包、RPC、预言机、扩容与应用的依赖地图列了组件，本篇把它们接成三条实际业务路径；每条都要追到交付凭证和最终对账，而不是在拿到哈希时停止。 
flowchart LR
  O[合成订单/交付凭证] --> B[Bitcoin: 钱包→节点→确认观察]
  O --> E[Ethereum/L2: 钱包→排序→托管→争议/退出]
  O --> H[高并发/应用链: 应用→本链执行→跨链]
  B --> R[业务补偿/对账]
  E --> R
  H --> R

Bitcoin 路线：买方钱包选币/签名，经 RPC 和 P2P 提交；卖方节点或有明确信任假设的支付观察端跟踪纳入、冲突与重组，订单服务按风险策略确认交付。若用 Lightning，付款与链上退出换成通道规则和在线监控；矿池不负责证明线下到货。卖方仍要独立保存订单 ID 与支付 outpoint/txid 的对应关系。

Ethereum/L2 路线：用户授权与托管合约保存债权；链下服务持久化 nonce/候选哈希，索引记录块和事件；若在 L2，排序器、L1 结算、DA、跨域桥与挑战/证明策略又添不同失败点。Foundry/OpenZeppelin 帮助开发与测试，不替用户保证升级管理员诚实；Chainlink 提供外部报告的接口，仍需核时效与数据源。Uniswap/Aave 等组合层引入额外参数、授权与清算风险，并非本订单的必要组件。

应用链/高并发路线：若交易共享同一热点订单账户或对象，运行时仍可能串行；Cosmos SDK/CometBFT、Avalanche L1、Sui 或 Aptos 分别有不同成员、并行冲突与状态同步方案。跨域交付需要 IBC 或适配桥，具体轻客户端、验证者和退出通道不可复用另一链的默认值。TRON/ Cardano 同理，只能在各自规则与治理被核对后选入。

同一订单的三种故障位置

以“付款 70、交付凭证为合成签名记录”为不变输入。Bitcoin 路径最可能出现的假完成是只收到钱包 txid 就交付：卖方独立节点尚未接收交易，或者已纳入的分支随后撤销；恢复需要检查收款输出是否仍存在于规范历史，以及付款原输入是否被另一交易占用。卖方后来主动花费收款输出并不使历史付款失效。订单服务再据选定风险规则决定是否要求补偿。若走 Lightning，通道对端停机时还必须确定谁能监控时限、持有什么退出交易；链下支付成功并不能免去订单对账。

Ethereum/L2 路径的假完成是事件已被索引却没有终局或可提现性。另一种失败是重复 RPC 发送造成多个候选哈希，但应用以哈希去重而不是按订单/nonce 对账。L2 再遇桥暂停或数据未取得时，L2 的执行结果不能推出 L1 可兑现；恢复动作分别是回填日志、核对现行根与收款债权，再依据该部署的挑战、证明和退出规则判断是否赔付，不把示例工具默认配置当部署事实。

应用链路径即便执行能并行，也可能因为所有订单都改写同一个共享对象而串行化。把跨链确认当成单步 API 还会漏掉 relayer 中断、对端轻客户端过期、消息超时与目标链应用拒绝。恢复首先辨认哪个链持有资产、哪个链只持有消息、哪方有权重试或撤销；不能拿来源链事务 ID 直接表示目标链交付。三种路径均需链外交付证据，差别在资产争议由谁裁定、可恢复历史由谁保存。

练习一：Bitcoin 收款和 Ethereum 托管使用同一个订单 ID，能当作原子跨链支付吗？答案：不能，跨链关联是业务账本约定，需单独设计双边失败恢复。练习二：L2 执行成功但排序器停机、用户无法取得退出数据，业务能立即宣称“可兑现”吗？答案：不能，需核对 DA、强制包含和退出合约。三条真实端到端路径均 NOT_RUN，不声称当前代表项目实际接入关系。

可迁移原则：评估集成链路时从业务结果反推每个角色可停止的环节。参考：Bitcoin Core、Ethereum nodes、IBC（实际客户端及网络待核）；导航：区块链（45）：钱包、RPC、预言机、扩容与应用的依赖地图 · 46 · 区块链（47）：选数据库、签名日志、许可链还是公链。