主链 + 二叉树分片共识设计

日期：2026-07-19
类型：选型 / 架构设计
状态：已对齐需求，待实现立项

1. 目标与约束

建设高性能区块链系统：

• 主链 + 分片链；分片区块 hash 写入父链区块头的定制化属性
• 验证者：各链独立集合（非共享安全）
• 正确性：父链仅锚定子块 hash，不验证子链状态机（信任子委员会）
• 网络：开放质押公链
• 跨层延迟：接受 ≥60s

1.1 节拍与拓扑（硬约束）

flowchart TB
  M["第一条链 id=1<br/>创世无子链<br/>唯一创链入口"]
  M -->|CreateChild + 费用<br/>parent=1| A["左子 id=2"]
  M -->|CreateChild + 费用<br/>parent=1| B["右子 id=3"]
  M -->|CreateChild + 费用<br/>parent=2| A1["挂到 id=2 下 → id=4"]
  A1 --> Dn["更深子链仍须在 id=1 上付费创建"]

2. 共识选型结论

推荐实现参考：HotStuff / Jolteon（流水线 BFT）+ 质押选主；具体密码学可用 BLS 聚合签名降低 QC 体积。

3. 角色分工

flowchart TB
  Ln[Ln 叶子：执行负载]
  L1[L1…L(n-1) 中间层：执行 + 锚定子链]
  L0[第一条链 id=1：全局创链入口 + 锚定直接子链]
  Ln -->|child/parent hash 锁定| L1
  L1 -->|规则递归相同| L0

• 每一层协议同构：任意链对其子链都是「父链」角色；每链只处理父 + 最多两子（GOVM）
• 子链：独立委员会出块与执行；即时安全性取决于本链质押；续任资格可受跨链投票约束（见 §6.2）
• 信任边界：父链只保证「某子块 hash 曾被本链最终收录」，不保证子状态正确；深树下路径上每一层委员会都是信任短板；跨链投票提供事后落选问责，不改变「仅锚定」语义

3.1 区块结构（对齐 GOVM 字段语义）

参考 GOVM 区块结构，本设计区块头至少包含：

每条链只需关心父链 + 至多两个子链（GOVM 核心简化点），无需同步整棵树。

3.2 子链创建流程（本设计：仅第一条链）

硬性要求：无论新链挂在树的哪一层，创链交易都只在 第一条链（id=1） 上提交并支付费用。
（GOVM 是在父链上 OpsNewChain——此处不照搬。）

sequenceDiagram
  participant U as 创建者
  participant L0 as 第一条链 id=1
  participant P as 指定父链
  participant C as 新子链

  Note over L0: 创世时无任何子链；之后所有 CreateChild 仅在此链
  U->>L0: CreateChild(parent_id, side...) + 支付费用
  L0->>L0: 校验 parent 已注册、孩子位未满、先左后右、费用足够
  L0->>L0: 分配 child_id=2*parent 或 2*parent+1，写入全局树注册表并最终确认
  L0-->>P: 父链观察到注册生效
  P->>C: 开始按时间差写入对应 child_hash
  C->>C: 子链出块，块头写入 parent_hash

规则摘要

第一条链 = 全局树注册与创链收费唯一入口；父子哈希锁定仍在相邻链之间完成。

4. 锚定规则（本设计 60s；GOVM 为 4–5 分钟窗口）

设槽时长 (2s)，固定落后 30 块 = 60s（相对 GOVM「时间戳差 ∈ (4min, 5min)」的简化版，便于与固定出块对齐）：

• 父块写入的 left/right_child_hash 对应约 60s 前 的子块
• 子块写入的 parent_hash 对应约 60s 前 的父块（双向哈希锁定，对齐 GOVM 链间区块关系 思路）
• 子块尚未可见时：对应 child hash 可空，不阻塞父链出块

sequenceDiagram
  participant C as 子链
  participant P as 父链
  C->>C: 高度 h 于 t 最终确认（正常块或空块）
  P->>P: 高度 h+30 于 t+60s
  P->>P: header 写入 child_hash(h)
  C->>C: 稍后块头写入 parent_hash(对应父块)
  Note over C,P: 跨一层可靠依赖该锁定关系

跨层延迟：每跨越一层 ≥60s。深度 (d) 到根约 ≥ (60s \times d)。
GOVM 表述为：跨 n 条链最大约 (n \times 5) 分钟，用「链间距离 × 最大时间差」判断跨链数据有效性——本设计同构，仅把单层窗口改成 60s。

5. 区块类型、奖励与惩罚

5.1 三类区块

要点：

• 无交易 ≠ 空块。无交易但完成 HotStuff 并带 QC，仍是正常块，正常拿奖励。
• 空块 = 本 2s 槽内未能形成带 QC 的块，为维持节拍与 (H-30) 可算性而写入的确定性占位块。

5.2 空块内容（确定性）

空块体仅包含：

• prev_hash（前置区块 hash）
• 父子相关 hash 字段（本层对子链 (H-30) 的 commit；以及协议规定的父链关联字段，若有）

无交易、无验证者签名。给定前置状态与锚定公式，全网可 本地算出同一 block_hash。

5.3 槽内决策流程

flowchart TD
  S[2s 槽开始] --> V{槽内是否达成 QC?}
  V -->|是| N[正常块<br/>允许 0 笔交易<br/>发放块奖励]
  V -->|否| E[确定性空块<br/>无奖励 + 惩罚]
  N --> H[高度 +1，节拍不漂移]
  E --> H

5.4 空块惩罚（已选 C）

• 对象：当前 epoch 全体验证者均摊
• 效果：空块无人获得出块奖励，并额外施加协议规定的活性惩罚（具体比例/上下限为经济参数，实现阶段再标定）
• 目的：把「出不出块」变成委员会共同责任，避免仅罚领导者导致的策略性行为讨论复杂化

作恶类惩罚（双签等）仍按可证明过错单独 slashing，与空块活性税分离。

6. 共识运行细节

6.1 开放网络下的配套约束

6.2 投票系统与跨链问责

跨链操作允许跨链投票，作为投票系统的一部分，补足「独立验证者 + 仅锚定」下父链不验子状态的安全短板：

• 各自验证不变：每条链仍由本链委员会独立出块与最终确认；父链仍只锚定子块 hash，不验证子状态机。
• 跨链投票约束验证资格：若某链验证者作恶（或出现可被社区/协议认定的不当行为），其他链参与者可通过跨链投票对其施压；票权按投票系统规则累计后，可使其落选，无法继续担任验证者。
• 定位：这不是共享安全（不是全局委员会替分片出块），而是跨链治理/选举通道——用跨链可传递的投票结果，约束各链本地验证者集合的续任资格。

flowchart LR
  A[链 A 验证者作恶] --> B[跨链操作发起/传播投票]
  B --> C[投票系统累计跨链票权]
  C --> D{是否落选?}
  D -->|是| E[失去验证者资格<br/>无法继续出块/轮值]
  D -->|否| F[继续担任本链验证者]

具体票权来源、投票阈值、落选阈值与是否同步 slash 质押，属投票/治理参数，实现前标定；本设计先固定：跨链投票属于投票系统能力，且可改变验证者续任结果。

6.3 明确不做（本设计范围）

• 欺诈证明 / ZK 有效性证明随锚定提交
• 共享安全（全局验证者池抽签保护所有分片）
• 十秒级跨层 UX

7. 选型对照（为何是 HotStuff 而非 Tendermint/PoW）

8. 风险摘要

1. 独立验证者 + 仅锚定：叶子作恶时父链会诚实锚定错误状态；即时正确性仍依赖本链委员会。缓解路径：跨链投票（投票系统）可使作恶验证者落选、无法续任；极端情形仍可辅以治理应急（停子链/社会共识）。
2. 空块均摊惩罚：网络分区时可能连坐诚实节点；需合理上限与 epoch 长度，避免 intrashard 死亡螺旋。
3. 确定性空块无 QC：分叉选择规则必须写清「空块何时合法纳入规范链」（建议：仅当该槽超时条件客观可验证时）。
4. 跨层 ≥60s/层：产品与桥/钱包确认数需按路径深度计时，不能按单链 2s 宣传跨片体验。
5. 深度不限：树越深，累计延迟与「路径上多委员会同时诚实」假设越苛刻；深叶适宜弱跨根、强本地业务，不宜默认把全局结算放在很深的叶子上。
6. 跨链投票滞后：投票与落选相对作恶有确认/传播延迟（受跨层时间窗约束），不能替代即时 slashing；作恶窗口期内仍可能造成局部损害。

9. 需求决策记录

10. 后续实现前待标定参数（非共识算法本身）

• 出块奖励数额、空块均摊罚金上下限
• CreateChild 创建费用公式（可参考 GOVM：与块奖励、平均块大小相关）
• epoch 长度、领导者轮换策略
• 各深度委员会规模与最低质押（可随深度递减，但不得低于下限）
• 空块「超时」的客观判定阈值（网络延迟假设）
• 跨层消息 / logSync 类对象与沿路径有效性（距离 × 单层时间窗）
• 是否引入 GOVM 式「平均块大小」创链门槛
• 双向 parent_hash / child_hash 的精确高度对齐公式
• 跨链投票：票权来源、发起条件、落选阈值、与本链选举/epoch 的衔接、是否叠加 slash

11. 与 GOVM（孚衍）对照

资料：官方介绍 · GitHub govm-net/govm（已 archive）

11.1 共识为何不照搬 GOVM 的 POW+DPOS

1. 你要求 固定 2s 与 明确跨层锚定：BFT 最终性比 PoW 最长链更易保证「已写入的 parent/child hash 不被浅重组打掉」。
2. GOVM 用监督节点补空块，偏 DPOS 治理角色；你已定义空块惩罚均摊，更贴近 委员会活性税，与 HotStuff 超时→空块自然衔接。
3. 多链 + PoW 时，算力在深树上的分配与攻击面更复杂（GOVM 白皮书亦提到纯 POW/POS 多链的问题，才走向 DPOS+POW）。本设计用每链独立质押委员会换取实现清晰度（代价是弱叶子风险，需最低质押）。

11.2 建议从 GOVM 借鉴（不含创链入口）

1. Chain ID 算术编号（左 2p、右 2p+1）
2. 先左后右挂载顺序
3. 创链费用可随拥堵调节（防刷链；费用在首链收取）
4. 跨链数据有效性 = 链间距离 × 单层最大时间窗
5. 区块头四哈希：prev + parent + left_child + right_child
6. 每链只同步父 + 两子

明确不采用：在父链本地创链（GOVM 方式）。

本文档与 区块链共识算法分析.md 配套；拓扑与哈希锁定可参考 GOVM，创链入口与共识层按本项目约束定制。

• Previous
  Claude Code Series 12 Prompt Index
• Next
  智能合约 Design