架构

Gonka中的推理流程

下图及描述概述了推理请求如何在Gonka中传输，Gonka是一个旨在平衡性能与密码学保障的去中心化网络。 Gonka仅记录用于推理验证的交易和工件，实际计算在链下进行。

推理请求在独立的Host（所有网络参与者，而非集中式调度器）之间流转。系统是去中心化的，没有单一节点负责将推理请求定向到网络节点。实际上，每个Host至少部署两个节点：

网络节点负责通信，包括：
- 一个连接到区块链的链节点
- 一个管理用户请求的API节点
一个或多个ML节点（推理），执行LLM推理（ML节点可部署在多台服务器上）。

下图展示了推理请求在Gonka网络中的流程。绿色箭头表示通过公共互联网的通信，黄色箭头表示Host内部私有网络中的通信。

以下序列描述了推理请求如何按上图所示在Gonka网络中流转：

步骤1。 客户端（开发者）从活跃参与者（Host）列表中随机选择一个节点。该随机Host作为传输代理（TA），将推理请求发送至其API节点。任何Host均可充当验证者、TA和执行者（这些并非预定义或链上角色，而是在处理请求时动态承担的操作功能）。
步骤2。 TA从所有其他活跃Host中随机选择一个执行者，并将推理输入传递至执行者的API节点。同时，TA的链节点将推理输入记录在链上。请注意，链上记录不会阻塞LLM计算，而是与执行者的计算并行进行。
步骤3。 执行者的API节点将请求转发至其一个ML节点，该节点立即开始推理。
步骤4。 计算完成后，执行者的ML节点将推理输出返回至其API节点。
步骤5。 执行者的API节点将输出发送回TA的API节点，同时执行者的链节点在链上记录一个验证工件。
步骤6。 TA的API节点将输出返回给客户端（开发者），同时TA的链节点将其记录在链上。请注意，虽然这些链上条目会增加整体网络带宽负担，但不会对单次推理计算增加额外开销。

性能与验证

区块链记录既不会延迟推理计算的启动，也不会延迟最终结果交付给客户端。推理是否诚实执行的验证在事后并行进行。如果发现执行者作弊，他们将失去整个纪元的奖励，客户端将收到通知并获得退款。请注意，该图仅以高级别展示推理流程，并未体现网络的全部复杂性。例如，它未显示Host之间链节点的直接通信，也未包含桥接器或其他在此抽象层级无关的内部组件。

计算证明（PoC）时间线

计算证明是一种新颖的共识机制，它保留了传统工作量证明（PoW）的所有优势，即将权重、工作量和奖励与计算能力对齐（不同于权益证明PoS将权重与质押代币对齐）。与工作量证明不同，计算证明将证明部分（冲刺）集中在短暂的限定时间窗口内，从而将其余时间留给有用的工作（本例中为LLM推理）。 Gonka以纪元为单位运行，每个纪元持续15391个区块（约23小时）。

每个纪元遵循严格的序列，将冲刺执行、Host活动和奖励结算整合为一个连贯流程。

所有Host的冲刺同时开始，通过不可预测且不可操控的随机种子确保公平性（类似于赛跑的发令枪，任何Host不得提前开始）。所有拥有投票权的Host共同生成该种子，防止少数Host提前计算或获得不公平优势。

冲刺被有意设计得极短，将计算努力集中在紧凑且高效的窗口内。它们在与区块链区块生成对齐的规则时间间隔内发生，仅占整个纪元长度的一小部分。设计上，冲刺时长被最小化，以便纪元的大部分时间可用于有意义的工作，例如LLM推理和训练。这种可预测的节奏使冲刺执行能够自然融入去中心化AI网络的整体运作，而不干扰生产性工作负载。

纪元以自动申领纪元N的奖励结束。新的计算证明阶段（冲刺）随即开始，以确定下一个纪元的Host权重。一旦冲刺完成且权重分配完毕，即标志着新纪元的开始。

在整个纪元期间，Host运行并验证推理。

如果由于某种原因未能申领纪元N的奖励，每个Host的API节点将在纪元N+1中自动提交针对纪元N的奖励申领交易，使用纪元N开始时签署的种子。该申领每30分钟重试一次，直至成功。重要的是，Host必须在此有限窗口内保持在线并通过所有验证检查，否则链无法最终确认申领，奖励将保持未申领状态。早于纪元N+2的未申领奖励（纪元N）将在纪元N+2开始时永久销毁。

作为申领流程的一部分，链会验证Host是否完成了纪元所需的所有工作。协议还允许在此窗口内提交逾期的推理验证工件，为Host提供最后一次执行待处理验证的机会，以便在奖励最终确定前完成。