下面给你一张 “Hyperchain 从交易到回执”的完整流程图（包含：接收交易 → 校验 → 交易池/广播 → 打包出块 → 共识 → 执行（EVM/HVM/BVM）→ 落块/落状态 → 回执可查/通知）。我尽量按联盟链/Hyperchain 的典型实现把关键节点都画出来，你可以直接拿这张图去对照日志/模块代码。
完整流程图（交易 → 回执）
flowchart TD%% =========================%% Client side%% =========================A[客户端/SDK\n构造交易 Tx\n- to/nonce/data/namespace\n- gasLimit/gasPrice(若启用)\n- 签名(如SM2)\n=> 得到 txHash] --> B[发送交易\nJSON-RPC / SDK / Gateway]%% =========================%% Node ingress%% =========================B --> C[接入节点 Ingress\n(HTTP/JSON-RPC/gRPC handler)]C --> D{基础校验\n- 格式/字段\n- 签名/证书\n- 权限/黑白名单\n- nonce/重放保护\n- gas参数合法(若启用)\n- namespace合法}D -- 校验失败 --> R1[返回错误响应\n(未入池)\n如: INVALID_SIG / PERMISSION_DENIED / BAD_NONCE]D -- 通过 --> E[进入本地交易池 TxPool/Mempool]%% =========================%% Propagation%% =========================E --> F[交易传播/同步\n向其他节点广播tx\n(减少单点接入)]F --> G[其他节点也做同样基础校验\n并入各自TxPool]%% =========================%% Propose block%% =========================E --> H[出块者/Leader(当前轮)\n从TxPool选交易\n- 排序(按nonce/策略)\n- 去重/过滤过期]H --> I[组装区块 BlockBody\nTx列表]I --> J[计算根/摘要\nTxRoot/MerkleRoot(若协议使用)\nReceiptRoot(可选)\nStateRoot(可选)]J --> K[组装BlockHeader\nprevHash,height,time,roots,...]K --> L[计算 BlockHash\n= Hash(BlockHeader)\n(出块/验证模块做)\n并对提案签名]%% =========================%% Consensus%% =========================L --> M[发起共识提案\nPropose(blockHeader, blockBody, sig)]M --> N[验证节点 Validators\n验证提案:\n- header/body规则\n- tx合法性(可做轻/重校验)\n- BlockHash复算\n- prevHash/高度/时间窗口\n然后投票]N --> O{共识达成?\n(如BFT/RAFT等)}O -- 否 --> H2[换轮/超时重试\n可能更换leader\n重新打包/再提案] --> HO -- 是 --> P[提交 Commit\n区块被确认(最终一致)]%% =========================%% Execute & receipts%% =========================P --> Q[执行器 Executor\n按区块内顺序执行Tx\n读取当前状态State]Q --> VM{选择虚拟机/合约引擎}VM -- EVM --> EVM[EVM执行\n- 解析calldata/ABI\n- gas计费\n- 产生logs/ret\n- 写入状态变更]VM -- HVM --> HVM[HVM执行\n- 运行Java合约\n- 产生logs/ret\n- 写入状态变更]VM -- BVM --> BVM[BVM执行(系统内置合约)\n- 提案/权限/证书/存证等\n- 写入系统状态变更]EVM --> Q2[生成TxReceipt\nstatus/ret/logs/gasUsed/error]HVM --> Q2BVM --> Q2%% =========================%% Persist: block + state + index%% =========================Q2 --> S[落库/落盘 Persist\n1) 写区块数据 BlockStore\n(header/body)\n2) 写回执 ReceiptStore/索引\n(txHash->receipt)\n3) 提交状态 StateDB\n(失败Tx通常回滚其状态写集)\n4) 更新高度/检查点]S --> T[区块对外可查询\nblock_getBlockByNumber/hash\ntx_getTransaction/Receipt\nstate查询等]%% =========================%% Client receipt%% =========================T --> U{客户端获取回执方式}U -- 轮询 --> V[tx_getReceipt(txHash)\n直到查到]U -- 订阅/推送 --> W[事件/WS/回执推送\n(若部署了订阅服务)]V --> Z[客户端拿到回执\n- 成功/失败\n- ret/logs\n- blockNumber/blockHash\n- gasUsed(若启用)]W --> Z%% =========================%% Optional failure points after acceptance%% =========================E --> X1[可能被丢弃/延迟\n- TxPool满\n- tx过期\n- nonce缺口长期未补齐\n- 与已上链冲突]N --> X2[提案拒绝/交易剔除\n- 验证失败\n- 不满足策略]Q2 --> X3[执行失败但仍入块\n- revert/异常\n- Out of Gas(若启用)\n=> receipt失败\n=> 状态不变(通常)]
你用这张图定位问题的“抓手”（最常见的断点）
-
收不到回执，先判断卡在哪一段：
- 没入池：Ingress 校验失败（签名/证书/权限/nonce/namespace）→ 立刻返回错误
- 入池但不上链：TxPool 过滤、交易过期、nonce 缺口、共识没打包到
- 已入块但失败：执行阶段 revert / Out-of-Gas → receipt 是失败，但一定能查到（除非落库/索引没写好）
-
“共识是不是合约实现的？”
图里共识（M/N/O/P）是节点共识模块；合约执行在 Q/VM 分支。合约只影响业务状态，不负责共识过程本身。 -
“区块 hash 在哪算？”
图里 K→L：组装 header 后算 BlockHash；验证节点在 N 会复算验证。
如果你愿意，我也可以把这张图再“工程化”成你们排障最常用的 日志关键字清单（每一步应该出现哪些日志/指标、对应到 Hyperchain 的哪些模块/端口），这样你拿到一段节点日志就能快速判断卡点在哪。