本研究比较了两种完整实现的架构。第一种架构在递归证明完成前就把区块加入规范链，随后由三阶段后台流水线生成区块证明、将其接入递归历史，并推进另一条已证明链尖。第二种架构把区块、对应的 HistoryStep 终端、State 与索引作为同一个原子结果提交。它把证明准备纳入挖矿关键路径，却消除了持久任务队列、部分提升与含糊的重启状态：每个已接受高度上的区块与递归证明始终同时存在。
区块何时才算完整？
State 是由当前未花费输出与共识计数器组成的认证集合。HistoryStep 是递归终端证明：它证明一个区块从父 State 到子 State 的精确转换，并验证前一个终端证明。本研究要回答一个直接的问题：区块能否在自己的 HistoryStep 就绪前进入规范链，还是二者必须同时被接受？两种架构均已实现，以比较其共识状态机、重启行为与挖矿关键路径。
实验一：后台证明流水线
实验按证明容量把区块分为四个固定类别：B8、B32、B64 和 B255。名称中的数字表示该类别最多能够证明的用户交易数。每个类别都有一份经过密码学认证的约束矩阵用于描述区块转换，另有一份矩阵用于把该区块证明接入递归历史；第九份矩阵用于锚定创世起点。
递归链接关系是一套约束系统：它同时验证一个区块证明和前一个 HistoryStep，并生成已证明历史中的下一个链接。四种此类关系都采用参数 m = 22。这里的 m 是填充后见证域与约束域大小的以二为底对数，因此每个关系占用 2^22 个域位置。随后，任务依次经过三个需要把中间状态持久化到磁盘的阶段：
三个较小类别覆盖最多 64 笔用户交易，允许最多三个区块高度并行处理。容量最大的 B255 可覆盖 255 笔用户交易，但因内存占用更高而一次只处理一个高度。并行处理提高了吞吐量，却让共识同时出现两个位置：规范链尖，以及已被递归证明覆盖的链尖。持久化证明任务、按顺序提升、重启恢复与部分流水线状态，全部只是为了使这两个位置保持一致。
实验二：原子化 PoW 与 HistoryStep
另一种设计只定义一个可接受单元：
在终端证明绑定候选区块的精确语义区块头与 State 转换之前，候选区块不能修改 State、创建区块奖励或向网络公布。区块字节、终端证明、State 与收据索引被原子提交。重启后，节点要么恢复完整单元，要么该高度不存在区块。
状态机对比
| 属性 | 后台流水线 | 原子 HistoryStep |
|---|---|---|
| 共识进度 | 规范链尖加递归覆盖链尖 | 一个已接受高度 |
| 持久中间任务 | 区块、链接与提升状态 | 无 |
| 重启情况 | 恢复并完成部分流水线 | 完整原子包或缺失高度 |
| 证明延迟 | 可以落后于区块生成 | 接受前支付 |
| 网络对象 | 区块加稍后产生的覆盖状态 | 一个完整原子包 |
取舍
原子性并不会消除证明成本。确定性的 HistoryStep 准备被移到挖矿路径，其预算必须保证受支持硬件仍能按网络节奏持续生成候选。工作量证明的 nonce 搜索仍是概率过程，并且依赖网络难度；它不是一项固定在十五秒内完成的本地任务。证明类别的测量单独记录在《HistoryStep 为何采用两种证明类别》中。
收益不是单纯提速，而是删除了一整套对共识可见的积压状态机。
结果
如果递归证明决定区块是否完全有效，就应当把该证明纳入被接受的区块对象。后台证明适合可选索引与缓存，不应再引入第二套共识可见的进度状态。