26年4月来自美国Kean大学、Norte Dame大学和南佛罗里达大学的论文“HadAgent: Harness-Aware Decentralized Agentic AI Serving with Proof-of-Inference Blockchain Consensus”。

工作证明（PoW）区块链共识机制消耗大量计算资源却无法产生有效输出，而大语言模型（LLM）智体的快速增长又对GPU计算提出了前所未有的需求。提出HadAgent，一个去中心化的智体AI服务系统，它用推理证明（PoI）共识机制取代基于哈希的挖矿。在PoI共识机制中，节点通过执行确定性的LLM推理任务来获得区块创建权。由于验证只需在相同条件下重新执行一次前向传播，因此跨节点验证可以以共识速度运行。HadAgent将已验证的记录组织成一个三通道区块体，分别包含专用的数据通道、模型通道和证明通道，每个通道都由独立的默克尔（Merkel）根保护，以实现细粒度的篡改检测。双层节点架构根据历史行为将辅助节点分类为可信节点或非可信节点：可信节点通过乐观执行实时提供推理结果，而非可信节点则必须经过完整的共识验证。安全层通过心跳探测、基于确定性重计算的异常检测和自动化信任管理来监控节点行为，从而创建一个自我纠正的反馈回路，隔离恶意或不可靠的参与者。

---

近期关于“驾驭工程”（Harness Engineering）的研究指出，具备能动性的 AI 系统的可靠性不仅取决于模型本身的能力，还依赖于其周边的编排、可观测性及反馈机制 [22]。本系统秉承这一理念，在去中心化推理网络中引入一个“驾驭层”（Harness Layer），专门负责监控、异常检测及信任管理。

在这一技术谱系中，本文工作占据着一个独特的定位。与 Bittensor 采用的主观评分机制不同，其要求每一个推理结果都必须能够通过确定性的重计算过程实现独立复现。与 Ritual 不同，本文充分利用确定性推理过程中固有的“执行与验证成本不对称”特性，从而避免了对硬件信任的假设，同时也规避了昂贵的密码学证明开销。借鉴 TensorOpera 的核心理念——即主节点应负责将请求分发至分布式工作节点——但本文将这一拓扑结构嵌入到一个基于区块链共识的框架之中，并辅以跨节点验证机制。此外，尽管与 Gensyn 一样致力于实现确定性执行，但本文将重心聚焦于推理服务领域；具体而言，将“确定性评估”本身直接作为共识机制，从而将区块的创建权与可验证推理结果的产出紧密地耦合在一起。

如图1展示 HadAgent 的分层架构，该架构包含：智体交互层；由主节点和次级节点构成的双层节点层；负责通信与容错的网络及驾驭（harness）层；以及具有独立 Merkle 根的三通道区块体，分别用于存储 DATA、MODEL 和 PROOF 记录。

A 系统概览

1. 设计目标：本系统旨在用具有实际意义的AI计算来取代传统的“工作量证明”（PoW）机制，使节点在参与共识的同时，能够贡献有用的工作——具体而言即大语言模型的推理计算。其核心目标是实现“确定性评估”：在给定完全相同的模型权重、输入数据和解码参数的前提下，每一个合规节点都必须产生“比特级一致”的输出结果；这使得任何提交的证明都能通过对单个前向传播过程进行轻量级重计算来独立验证，而无需执行完整的模型训练过程。

除了结果的正确性之外，该设计还致力于实现三个运营目标。首先是“实时服务”：受信任的节点应通过“乐观执行”机制即时交付推理结果，无需等待共识达成。其次是“安全性与防篡改性”：通过数字签名和“三通道默克尔根”（three-lane Merkle roots）机制，确保所有记录均经过身份验证，且任何篡改行为均可被检测出来。第三是“容错性”：系统内的“驾驭机制”（Harness mechanism）必须在异常节点行为（如任务超时、提交错误证明或节点故障等）对共识进度或服务质量造成影响之前，及时检测并隔离这些异常行为。

2. 架构概览：如上图1所示，HadAgent系统在逻辑上划分为四个层级。“智体交互层”（Agent Interaction Layer）作为系统的入口点，外部智体（Agents）通过该层提交推理请求，并指定相应的输入提示（Prompt）、模型引用信息及解码参数。“双层节点层”（Two-Tier Nodes Layer）将参与者划分为两类：负责任务路由、结果评估及区块提议的“主节点”（Master nodes），以及负责执行具体推理计算的“次节点”（Secondary nodes）。次节点根据其历史行为进一步细分为“受信任节点”和“非受信任（新加入）节点”：受信任节点可通过“乐观执行”机制即时返回计算结果；而非受信任节点则必须等待完整的共识验证流程完成后方可返回结果。“网络与驾驭层”（Network and Harness Layer）包含负责消息路由的“信息枢纽”（Information Hub）、用于暂存已验证记录的“AI记录记忆池”（AI Record Mempool），以及一系列驾驭服务——包括心跳监测、故障转移、沙箱隔离、流量限速及日志记录等。“区块层”（Block Layer）负责将已验证的记录提交并固化至“三通道区块体”（包含 DATA、MODEL 和 PROOF 三个通道）中，其中每个通道均由独立的默克尔根（Merkle root）提供安全保护（参见图2所示）；最终仅有哈希值、元数据、评分结果及数字签名等信息会被记录在链上。
   

一个完整的推理周期流程如下所示（参见图3所示）：(1) 外部智体提交推理请求；(2) 主节点将该任务路由分配给相应的次节点； (3) 次节点执行确定性推理并返回结果；(4) 主节点评估结果，并生成 DATA、MODEL 和 PROOF 记录；(5) 记录在通过模式和签名验证后进入记忆池（mempool）；(6) 多个主节点参与跨主节点的投票；(7) 达成共识的记录被提交至新区块；以及 (8) 经验证的响应被交付给请求智体。

3. 威胁模型：采用拜占庭容错模型，在该模型中，N 个节点中最多有 f 个节点可能任意偏离协议。

伪造的推理结果。恶意次节点可能会提交伪造的 PROOF 记录，其中包含错误的分数或被替换的哈希值。由于推理过程是确定性的，任何诚实节点都可以通过重新执行同一任务并比对输出来检测此类偏差。这一防御机制是通过“推理证明”（Proof-of-Inference）共识机制实现的。
不诚实的主节点。受损的主节点可能会丢弃有效的证明，或为与其串通的次节点虚高分数。HadAgent 通过跨主节点验证机制来缓解这一威胁：区块提案需要通过多主节点投票机制获得多个主节点的共识，因此任何单一主节点都无法单方面决定区块的内容。

女巫攻击（Sybil attacks）。攻击者可能会创建大量次节点，试图以此操控共识过程。双层架构限制了这一威胁：新加入的节点被归类为“非受信任”节点，且必须对每一项任务执行完整的验证性计算；因此，女巫节点无法绕过验证环节，必须为生成每一份证明投入实实在在的计算资源。

值得注意的是，具备消息延迟、重排或选择性丢弃能力的网络层攻击者可能会扰乱共识的正常推进。驾驭层（Harness Layer）通过心跳监测和故障转移机制提供基础性的缓解措施，但当前的系统原型尚未能全面应对诸如“日蚀攻击”（Eclipse attacks）之类的威胁。利用生产级 P2P 协议对通信层进行加固的工作，将作为未来的研究方向。

4. 假设：HadAgent 的正确性与安全性保障依赖于以下三个核心假设。

假设 1（确定性推理）：在给定完全相同的模型权重、输入数据以及解码参数的前提下，每一个符合协议规范的节点都将产生完全相同的输出结果。这使得任何节点都能通过重新执行同一任务并比对结果，来验证所提交的证明。通过要求所有节点使用标准化的执行环境来实现这一强制约束，该环境具有固定的框架版本和数值精度。

假设 2（主节点中的诚实多数）：严格超过半数的主节点忠实地遵循协议。在此假设下，跨主节点的投票能够产生正确的共识决策；且任何由非诚实主节点组成的联盟，既无法批准伪造的证明，也无法审查有效的证明。

假设 3（模型与数据可用性）：所有参与特定推理任务的节点，均可通过链下分发渠道获取相同的模型权重和评估数据集。链上存储的内容哈希值允许每个节点验证其所获取的工件（artifacts）是否与其余参与者所使用的工件相一致。

其他实际考量因素——包括有限的时钟漂移、密码学难度以及动态的节点成员管理——将在第五节中作为系统局限性进行探讨。

B. 区块结构与数据模型

图 2 概述了区块的设计方案。每个区块均由区块头（Header）和区块体（Body）两部分组成。区块头存储了用于验证所需的元数据，其中包括区块高度、前一区块的哈希值，以及用于归纳区块内容的各类根哈希值（Root Hashes）。凭借这些根哈希值，节点无需逐一处理区块内的所有记录，即可完成完整性验证。

区块体容纳从记忆池（Mempool）中收集并经由验证的各类记录。这些记录按类型进行归类组织，并共同参与其对应根哈希值的计算过程。这种结构设计在确保不同类别数据之间保持清晰界限的同时，也实现了高效的验证机制。

1. 三通道式区块体：上图 1 展示 HadAgent 系统的分层架构以及三通道式的区块体结构；上图 2 则进一步提供了各通道的详细结构图（Schema）。区块体在逻辑上被划分为三个独立的通道：DATA（数据）、MODEL（模型）和 PROOF（证明）。每个通道专门存储特定类型的记录，从而支持各通道内容的独立处理与验证。具体而言，DATA 通道用于存储数据承诺（Data Commitments）；MODEL 通道用于存储模型引用信息；而 PROOF 通道则用于记录评估结果。

这种通道分离的设计简化了验证流程，因为它在区块内部对不同的职责进行了明确划分。此外，该设计也为根哈希值的计算提供了支持，因为每个通道的内容均独立参与计算，并共同构成了区块头中的唯一哈希值。

2. 记录类型：本系统定义三种主要的记录类型：DATA、MODEL 和 PROOF。每种类型均对应并捕获了基于 AI 的共识工作流中的特定环节；同时，每种类型均遵循一套结构化的数据模式（Schema），以此为后续的验证工作及数据的安全存储提供基础支持。

DATA 记录用于表示对输入数据集或数据工件的承诺。其字段包括内容哈希、时间戳、所有者或发送者标识符、可选元数据以及数字签名。内容哈希唯一地标识了链下数据，并允许其他节点在无需将原始数据存储在链上的情况下验证其完整性。

MODEL 记录用于描述与推理任务相关的模型配置或模型工件。其字段包括 model_hash、model_version、模型标识符、配置元数据、时间戳以及数字签名。model_hash 将该记录绑定到特定的模型配置或序列化的模型工件上，而 model_version 则用于区分同一模型的不同修订版本。

PROOF 记录存储评估运行的结果，并作为共识过程中使用的主要证据。其字段包括 dataset_hash、model_hash、validation_score、任务或证明标识符、时间戳以及数字签名。dataset_hash 将该证明链接到确切的评估数据集，而 validation_score 则记录了在既定配置下进行确定性推理所产生的结果。

在任何记录被接受之前，它都必须经过模式验证（schema validation）。此过程检查所有必填字段是否均已存在，每个字段是否符合预期的类型和格式，以及诸如哈希值之类的定长数值是否满足大小限制。例如，加密哈希必须具有正确的字节长度，版本字段必须是有效的标识符，且分数必须以预期的数值格式进行编码。未能通过这些结构性检查的记录将被立即拒绝。

完成模式验证后，系统将执行签名验证。记录的有效载荷（payload）会被处理为一种统一格式，随后利用发送者的公钥对其中包含的数字签名进行验证。这一步骤同时确认了记录的真实性与完整性：它既证明了是哪个节点创建了该记录，又确保了其内容在签名之后未曾遭到篡改。唯有那些既通过了模式验证又通过了签名验证的记录，才会被准许进入记忆池（mempool），并被纳入考虑以最终打包进区块中。

3. 链上（on-chain）存储与链下（off-chain）存储：区块链内部包含多种不同的存储方法，用于决定应如何存储数据。针对不同的数据集类型，每种存储方法都能提供各具特色的优势。区块链的这一概念至关重要，因为它构成了区块链体系本身的坚实基础。它确保了所有数据的安全性，并保障了数据的准确传输 [10]。

首先，链上方法通过将数据直接存储在区块链上，从而确保了数据的不可篡改性和可靠性；尽管如此，这种方法也存在其局限性。其主要弊端在于高昂的交易成本以及可扩展性的不足 [10]。相比之下，链下方法在成本和性能方面更具优势，但也伴随着数据完整性受损的风险。链下存储模式将数据存放于区块链系统之外，仅将数据的引用指针或加密哈希值记录在链上。

通过引入“推理证明”（Proof-of-Inference，简称 PoI）机制，系统消除了对原始数据进行全流程记录与传输的需求。以供应链场景为例：尽管诸如货物在运输途中的位置信息等各类数据会被持续采集，但这类原始数据并不会被直接存储在链上。机器学习算法会对这些数据进行分析处理；随后，PoI 机制不再将所有的物流原始数据全盘记录，而是仅将经过验证的“推理结果”存储在链上。这一机制在理念上与链下存储模式有异曲同工之妙，但 PoI 的实现方式显然更为高效。

C. 网络与通信

该系统包含一个轻量级的通信层，旨在促成各节点之间的数据记录交换与验证信息的传递。该通信层的设计理念侧重于简洁性，既支持进行受控的实验性测试，又能确保与去中心化架构保持良好的兼容性。

1. 信息枢纽层（Information Hub Layer）：信息枢纽层充当所有入站消息的接收入口。它负责解析结构化的数据包，并将其分发至相应的系统组件进行处理（例如发送至验证模块或记忆池）。该通信机制基于 Socket（套接字）技术实现。

该信息枢纽以异步模式运行，从而使各节点能够同时处理多项并发请求。所有入站消息在进入后续处理流程之前，均需经过严格的有效性验证，以确保数据的准确无误。

2. 记录记忆池（Record Mempool）：记忆池（Mempool）作为数据的暂存区，用于临时存放那些已通过有效性验证、但尚未被打包进区块的记录。它针对不同类型的记录维护着独立的集合，并在接收新记录入池之前强制执行严格的验证流程。

此外，记忆池还具备防止重复记录入库的功能，并能在区块构建过程中实现对记录的高效筛选与提取。这一机制确保了仅有那些经确认有效的记录才会在整个系统中进行广播与传播。

3. P2P 泛洪协议与节点发现（P2P Gossip and Peer Discovery）：在完全去中心化的部署环境中，各节点将依托于 P2P 泛洪协议（Gossip Protocol）及其内置的自动节点发现机制，实现在全网范围内对数据、模型参数以及证明记录的高效广播与同步。妥善解决这一问题本身就是一个独立的研究课题，因为 NAT 穿透、具备 Sybil 攻击抵御能力的对等节点选择，以及在节点频繁进出（node churn）环境下实现高效的 Gossip 协议传播，每一项都绝非易事，且在很大程度上独立于在此重点关注的共识机制。此外，在测试床目前的规模（包含 X 个节点）下，采用生产级 Gossip 层所带来的收益微乎其微：每个节点都能与其他所有节点建立直接连接，无需担忧带宽或连接能力方面的限制。
   因此，本文采用一种简化的通信设计：节点通过点对点的 TCP 连接交换特定类型的报文——即 NEW_DATA_RECORD、NEW_MODEL_RECORD 和 NEW_PROOF_RECORD——这一过程利用 Python 语言中基于 asyncio 的网络编程框架来实现。每个节点仅与一组已知的对等节点建立连接；对于评估共识机制本身的正确性与性能而言，这样的连接规模已绰绰有余。这种基于直接套接字（direct-socket）的架构无法完全模拟现实世界中 P2P 覆盖网络所特有的延迟波动与消息丢失模式；将系统与成熟的泛洪协议（例如 libp2p）进行全面集成，将作为未来的工作重点。

D. 推理证明（Proof-of-Inference）共识机制

在“推理证明”（PoI）共识机制中，节点通过执行确定性的大语言模型（LLM）推理任务来赢得区块创建权；这些推理任务的正确性，仅需通过一次前向传播（forward pass）的重计算即可完成验证。整个共识流程共包含八个步骤，具体如上图 3 所示。

首先，一个智体（Agent）节点提交一份推理请求（步骤 1）；随后，一个主节点（Master Node）将该任务分配给一个或多个次节点（Secondary Nodes）。每个次节点在既定的模型权重、输入数据及解码参数配置下执行推理计算，并生成一个具有确定性的输出结果（步骤 2）。接着，主节点通过重新执行相同的前向传播计算来对结果进行评估，并生成一份包含数据集哈希值、模型哈希值、验证得分及数字签名的“证明记录”（PROOF record）（步骤 3）；该证明记录随后会被存入记忆池（Mempool）中等待处理（步骤 4）。

系统会周期性地触发一个“跨主节点验证周期”（步骤 5）；在此期间，各个主节点将独立地对近期任务中的一个随机抽样子集进行重新评估。这些待验证的任务均选自 MMLU 和 HellaSwag 等标准化的基准测试集。采用随机抽样的方式，旨在防止次节点预判哪些任务将会被纳入审计范围。随后，各主节点将通过“主节点投票”（Master Voting）的方式，对各自的验证结果进行汇总与聚合（步骤 6）。如果投票确认了各独立重算结果之间的一致性，相关记录将被作为最终确定的区块提交至链上（步骤 7），随后响应将被发送给智体（步骤 8）。

E. 推理任务生命周期

推理任务生命周期描述了评估任务在系统中如何被执行、验证及记录。这一流程取代了传统的“挖矿”模式，转而要求节点执行确定性的模型评估，并将评估结果作为“证明”进行提交。

该生命周期始于节点利用共享数据集及预先定义的模型配置来准备一项评估任务。该数据集通过其加密哈希值进行引用，以确保所有节点之间的数据一致性。随后，节点在固定条件下执行该模型，从而产生具有确定性且可复现的输出结果。

执行完毕后，节点通过将模型输出结果与预期结果进行比对，计算出一个验证得分。该得分反映了模型在特定任务中的性能表现。接着，节点生成一份“证明”记录，其中包含数据集的哈希值、模型配置的引用信息、验证得分以及数字签名。

这份证明记录通过信息枢纽提交至系统，并在该处接受验证。其他节点通过重新执行评估任务，并核对所得结果是否与提交的得分相吻合，以此来对该证明进行验证。此外，系统还会执行签名验证，以确保记录的真实性。

一旦通过验证，该记录便会被暂存至记忆池（mempool）中；随后在区块生成过程中，该记录将被打包并纳入至新的区块之中。这一生命周期机制确保了所有的推理任务均具备可复现性与可验证性，并能以一致且可靠的方式被整合进区块链网络之中。

F. 双层节点架构

HadAgent 根据次节点的历史行为，将其划分为两个层级，如图 4 所示。受信任的次级节点是指那些已积累了足够多的正确证明记录且未出现任何异常的节点。当受信任节点从主节点接收到任务时，它会执行推理计算，并通过“乐观执行”机制将结果直接返回给请求智体，从而实现实时服务。主节点仍会在后台对结果进行评估，并将相应的记录存入记忆池（mempool）中，但请求智体无需等待共识验证完成。

非受信任的次节点要么是新加入的节点，要么是因过往故障而被降级的节点。其推理结果不会立即交付给请求代理。相反，该结果必须通过主节点的评估，存入记忆池，并经过完整的共识验证流程后，方可被系统接纳。这种经过验证的执行路径确保了未经证明的节点无法向系统中注入错误的结果。

若要从非受信任状态晋升为受信任状态，节点必须连续完成一系列经验证的任务，且期间不得有任何任务被驳回。当“驾驭”（Harness Layer）检测到诸如提交错误证明或反复超时等异常行为时，便会触发降级操作。这种机制在成本上形成了一种天然的不对称性：赢得信任需要持续保持正确的行为，而失去信任往往只需一次经确认的故障。

G. 旨在维护系统稳定性的驾驭工程（Harness Engineering）

驾驭层（Harness Layer）持续监控各节点的行为，并负责执行信任层级转换机制。在每一个共识轮次结束时，该驾驭层会按序执行三个阶段的操作。

在第一阶段，心跳监控器会向所有次节点发送存活探针（liveness probes）。任何未能在预设的可配置超时时限内做出响应的节点，将被标记为“无响应”状态；其名下所有待处理的任务随后将被重新分配给当前可用的其他节点。

在第二阶段，异常检测器会对本轮次内提交的所有证明记录进行逐一核验。针对每一条记录，检测器会通过重新执行同一项确定性推理任务，来重新计算预期的验证得分，并将其与节点提交的得分进行比对。若两者之间的偏差超过了预先设定的阈值，则表明该结果可能存在伪造或质量受损的情况，该记录随即会被标记为“异常”。

在第三阶段，信任管理器会依据此前累积的各类证据，对每个节点的信任层级进行相应的更新调整。若某个节点连续触发的异常或超时事件超过了降级阈值（例如，连续发生两次故障），该节点将被从“受信任”状态降级为“非受信任”状态，或从“非受信任”状态降级为“已排除”状态。反之，若某个“非受信任”节点连续完成了足够数量的正确证明（例如，连续五个轮次未被驳回），该节点将被晋升为“受信任”状态。“已排除”节点将被彻底移出任务分配范围。

这一三阶段流水线构建一个自我纠正的反馈闭环：提交虚高分数的恶意节点将通过确定性重计算机制被检测出来并逐步隔离；而行为始终如一的诚实节点则会逐步获得晋升，从而具备提供实时服务的能力。利用 CrewAI 实现该流水线的一个原型系统，其中每个阶段都被建模为一个自主智体（包括 HeartbeatMonitor、AnomalyDetector 和 TrustManager），并在每个轮次中按序执行任务。

---

实验设置

本实验利用所提出的区块链系统的一个基于 Python 的原型实现进行。该系统包含用于区块验证、记录验证的组件，一个用于消息处理的信息枢纽（Information Hub），以及一个用于临时存储已验证记录的记忆池（Mempool）。

所有实验均在一台运行 macOS 的本地机器上执行，并在虚拟环境中使用 Python 3.14。测试套件采用 pytest 实现，从而能够自动执行测试用例并验证预期结果。系统中的异步组件则利用基于 asyncio 的执行方式进行了测试。

评估过程分为三个阶段：(1) 基线正确性评估，(2) 规模评估，以及 (3) 综合评估。基线阶段通过使用有针对性的有效和无效输入（包括被篡改的记录和区块）来验证系统的正确性。规模阶段通过处理大量有效记录来评估系统性能，旨在模拟实际的工作负载条件。综合阶段将基线测试与规模测试整合为单次运行，从而能够同时评估系统在负载条件下的正确性、拒绝准确率以及性能表现。

在每次测试过程中，系统均利用高分辨率计时器记录验证操作开始与结束时的时间戳，从而能够精确测量单个操作的延迟。收集的指标包括有效与无效用例的数量、检测率、误报率以及验证延迟。所有实验结果均被记录下来，并以结构化的 JSON 文件格式导出，以便后续分析。
所有实验均在单节点测试环境中进行，未涉及分布式网络环境；其主要目的是在受控条件下，重点验证系统的逻辑、正确性以及性能表现。

用于确保系统稳定性的“驾驭工程”（Harness Engineering）

“驾驭层”（Harness Layer）对推理管道（Inference Pipeline）进行封装，旨在检测、隔离并永久性地纠正节点出现的异常行为。遵循“驾驭工程”范式 [23]，系统对于检测的任何故障，不仅仅是简单地予以拒绝，而是会利用该故障信息来收紧针对涉事节点的约束条件，从而确保同一类故障在后续的运行轮次中不再重现。

在每个共识轮次结束时，该驾驭将按序执行三个阶段的操作。在“心跳阶段”（Heartbeat Phase）中，驾驭会向所有次节点（Secondary Nodes）发送存活探针（Liveness Probes）。若某节点未能在预设的可配置超时时限内作出响应，系统便会将其标记为“无响应”状态；随后，该节点名下所有待处理的任务将通过故障转移机制，立即重新分配给当前可用的次节点。这一机制有效防止因单个节点无响应而导致整个共识管道陷入停滞的局面。在异常检测阶段，驾驭（harness）会对本轮提交的每一条证明记录进行验证。对于每一条 PROOF 记录，驾驭都会在完全相同的条件下（包括模型权重、输入数据和解码参数）重新执行一遍相同的推理任务，并将重新计算得出的验证分数与提交的原始数值进行比对。如果两者之间的绝对偏差超过了预设的容忍阈值，该记录即会被标记为异常。鉴于推理过程具有确定性（如假设 A1 所述），任何超出数值容忍范围的非零偏差，都表明该记录存在伪造或损坏的情况。

在信任更新阶段，驾驭会依据前两个阶段所累积的证据，对每一个节点应用相应的层级转换规则。若某节点累积的连续失败次数（包括异常或超时）超过了降级阈值 τ_d，该节点即会被降级：从“受信任”层级降至“非受信任”层级，或从“非受信任”层级降至“已排除”层级。一旦被列入“已排除”层级，该节点将被彻底移出任务分配池。反之，若某“非受信任”节点连续完成正确证明的次数超过了升级阈值 τ_p，该节点即会被晋升为“受信任”节点，从而获准通过“乐观执行”模式来处理后续的请求。在原型系统中，将 τ_d 设定为 2，将 τ_p 设定为 5；这一设定体现设计原则：即失去信任的过程应当迅速，而赢得信任的过程则应循序渐进。

这一由三个阶段构成的流水线机制，在驾驭层与双层级节点架构之间建立起一个具备自我纠错能力的反馈闭环。那些通过提交虚高分数企图作恶的恶意节点，将通过确定性重计算机制被检测出来，并在短短两轮之内被逐步隔离。而那些因反复超时而表现不稳定的不可靠节点，也将通过同样的降级路径被排除出系统。与此同时，那些始终保持行为一致且诚实的节点将逐步获得晋升，从而有效提升系统中具备实时服务能力的“受信任”节点的占比。