奖励机制
Note
本文档仅供参考。最终参数和技术细节可能发生变化，因此在依赖本文档前，请务必核实最新的链上状态及相关 GitHub 仓库。
代币经济概览
Core 激励计划为矿工（6.8 亿枚 gonka (GNK) 代币，占总供应量的 68%）设立，旨在奖励为去中心化网络贡献算力的矿工。在类比特币奖励系统下，每个纪元（epoch）会固定铸造一定数量的 GNK，并根据各矿工的“算力证明”（Proof of Compute, PoC）权重按比例分配。随着网络增长，更多 GPU 竞争相同的固定奖励，每台 GPU 获得的 GNK 数量将减少，从而引入类似比特币挖矿的稀缺性驱动价值机制。矿工的长期收益来源于推理服务需求的增长、固定发行量带来的稀缺性，以及随着挖矿竞争加剧而上升的 GNK 市场价值。奖励计划遵循可预测的指数衰减模式，纪元奖励逐步减少，大约每 4 年减半一次。
Gonka 网络奖励系统
Gonka 网络采用双轨奖励机制，旨在平衡长期稀缺性激励与即时经济实用性。矿工通过两种互补的奖励渠道获得报酬：
- 协议层发行奖励（类比特币模式）
- 基于实际推理需求的工作奖励
类比特币奖励系统
Gonka 网络引入一种受比特币启发的固定奖励机制，每个纪元铸造预定数量的奖励代币，并根据每个矿工的“算力证明”（PoC）权重进行分配。
该模型的关键特性包括：
- 纪元铸造奖励代币：每个纪元基础奖励为 323,000 GNK（由治理决定，可能调整），该金额将分配给所有活跃矿工。此数值按指数衰减（每纪元衰减率 -0.000475，相当于约每 1,460 个纪元或 4 年减半一次），计算公式为：
当前纪元奖励 = 初始奖励 × exp(衰减率 × 自创世以来的纪元数) - 稀缺性驱动价值：随着更多 GPU 加入网络，每台 GPU 每纪元获得的 GNK 减少。单位 GNK 的挖矿成本上升，从而产生内在价值，并形成类似比特币的正向反馈循环：
更多矿工 → 每 GPU 获得更少 GNK → 更高稀缺性 → 潜在价格支撑与增长
基于工作的奖励
与此同时，Gonka 网络还会根据实际经济活动分发“工作代币”（Work Coins）：
- 开发者为实际的推理和计算任务支付费用
- 这些费用将根据矿工实际完成的计算量按比例分配给矿工
奖励归属机制（Vesting）
Gonka 网络分发的所有奖励，包括纪元铸造的奖励代币和基于使用量的工作代币，均需遵循由专用归属系统管理的确定性、协议强制执行的归属计划：
- 按矿工归属记账：网络为每个矿工维护独立的释放计划，按日跟踪其奖励，确保分配的公平性和可预测性。所有矿工遵循相同的归属规则和参数。
- 确定性奖励分配：当矿工获得新奖励时，系统会将总额平均分配到整个归属周期内。任何因四舍五入产生的微小分数金额将在第一天累加，以避免代币损失。
- 自动管理：系统自动处理所有归属操作，无需矿工干预，既保持高效又防止系统臃肿。
- 每日释放：每天，每个矿工最旧的一笔归属记录将自动释放至其可用余额，形成稳定的解锁代币流。
截至 2026 年 3 月，归属期设定为 180 个纪元（约 180 天）。有关最新的归属计划，请始终参考当前的链上实现。
任何链下描述可能因协议升级、参数变更或治理决策而过时。
该机制将矿工的奖励与网络的长期稳定和发展相绑定，防止短期投机行为，确保可靠矿工具备可预期的收入流。
矿工可查询：
- 待归属代币的总数量
http://<ip>:<public_http_port>/chain-api/productscience/inference/streamvesting/total_vesting/<Host_address>他们解锁计划的详细分解（未来解锁的时间表数组）。http://<ip>:<public_http_port>/chain-api/productscience/inference/streamvesting/vesting_schedule/<Host_address>## 奖励领取流程 Gonka 链仅在第 N+1 轮次中发放在第 N 轮次所获得的奖励。奖励无法提前或延后领取。
主机的 API 节点会在第 N+1 轮次期间，自动使用在第 N 轮次开始时记录签名的种子（seed）执行奖励领取操作。若领取失败，节点会每 30 分钟重试一次。
然而，领取奖励要求节点在此有限的时间窗口内保持在线，并通过所有验证步骤，直至奖励成功领取。如果无法完成验证，链将无法最终确认奖励，奖励将保持未领取状态。
关键运行说明
奖励领取操作仅由主机的 API 节点执行。
如果 API 节点在第 N+1 轮次期间的任何时刻停止、重启或不可用， 则第 N 轮次的奖励可能会永久丢失，即使：
- 已成功完成计算证明（PoC）
- 推理请求已正确响应
- ML 节点始终在线
仅靠 ML 节点无法领取奖励。为确保奖励被安全领取，API 节点必须保持在线并同步状态，直至前一轮次的奖励被确认已成功领取。
在领取奖励时，链需要验证主机是否已完成该轮次的所有必要工作。链还允许主机在奖励领取窗口期内提交逾期的推理验证。这些检查要求保留所有推理输出及其元数据。
种子承诺与验证
种子是由每个网络节点在新一轮次开始前独立生成的一个秘密值。在轮次开始前，网络节点通过向链提交该种子的数字签名，完成对种子的承诺。
在轮次结束时，为了获得奖励，节点必须公开该种子本身。链随后验证所公开的种子是否与其先前记录的签名相匹配。
示例结构：{
"seed": 5839402176541298043, // the seed itself, revealed during the claim
"epoch_index": 101,
"signature": "a5910d9b4156e403494a0ba148e6fb67e101ab2a7b7cf54eb15fa5bb5a46a2fdb1435a14954221008d294987075b75d247f26fa7d273720478f0ffb3189132f6", // the seed signature, committed beforehand
"claimed": false
}该机制确保每个主机在验证过程中真正随机选择推理请求，且无法操纵选择过程。同时，其他主机无法推断该节点的随机选择方式，从而防止对抗性适应行为。
相关实现参考
Event_listener.gohttps://github.com/gonka-ai/gonka/blob/aa85699ab203f8c7fa83eb1111a2647241c30fc4/decentralized-api/internal/event_listener/event_listener.go#L319Reward_recovery.gohttps://github.com/gonka-ai/gonka/blob/aa85699ab203f8c7fa83eb1111a2647241c30fc4/decentralized-api/internal/startup/reward_recovery.go#L44
奖励未申领的原因
尽管申领流程是自动的，但并非无条件执行。
在第 N+1 轮期间，若出现以下情况，奖励可能未被申领：
- API 节点离线或正在重启
- 节点无法提供正确的种子（终端性故障）
- 所需的推理-验证数据无法验证（终端性故障）
- 网络不稳定导致最终确认失败（可重试故障）
区块链不会在申领窗口期后保留推理数据，也无法处理逾期申领。
此前各轮次中未申领的奖励将被永久销毁。
奖励申领失败情况矩阵
| 失败条件 | 发生时机 | 结果 | 是否自动重试 | 是否支持手动申领 | 最终状态 |
|---|---|---|---|---|---|
| 临时网络不稳定 | 第 N+1 轮期间 | 申领尝试失败，奖励保持待定状态 | 是（每30分钟一次） | 是（可选） | 在第 N+1 轮结束前可恢复 |
| API 节点临时停机 / 重启 | 第 N+1 轮期间 | 申领延迟 | 是（节点恢复后） | 是（可选） | 在第 N+1 轮结束前可恢复 |
| 节点在线但链上最终确认失败 | 第 N+1 轮期间 | 申领未完成最终确认 | 是 | 是 | 在第 N+1 轮结束前可恢复 |
| 种子错误或缺失 | 第 N+1 轮期间 | 申领被拒绝 | 否 | 否 | 只要种子可恢复，则在 N+1 轮内可恢复 |
| 本地种子丢失 | 第 N+1 轮期间 | 无法授权申领 | 否 | 否 | 永久不可恢复 |
| 推理-验证数据缺失或损坏 | 第 N+1 轮期间 | 验证失败 | 否 | 否 | 永久不可恢复 |
| 过多无效或遗漏的推理请求 | 第 N 轮期间 | 主机被取消资格 | 不适用 | 否 | 第 N 轮奖励作废 |
| 随机性 PoC 验证失败 | 第 N 轮期间 | 主机被惩罚并禁用 | 不适用 | 否 | 第 N 轮奖励作废 |
| API 节点在申领完成前关闭 | 第 N+1 轮期间 | 无法完成申领 | 是（若节点及时恢复） | 是（若在 N+1 轮内） | 在第 N+1 轮结束前可恢复 |
| 申领窗口过期（第 N+1 轮结束） | 第 N+1 轮之后 | 不再允许申领 | 否 | 否 | 永久销毁 |
手动申领奖励
手动申领功能适用于以下操作人员：
- 正在停用或退役节点
- 在修复了导致第 N+1 轮期间无法自动申领的问题后，需主动触发申领
- 希望强制立即尝试申领，而不愿等待自动重试周期
运维说明
在第 N+1 轮期间短暂离线无需手动申领。
系统会在整个第 N+1 轮期间每约 30 分钟自动重试申领。
仅当节点无法及时恢复服务，或操作员希望比下一次计划重试更早触发申领时，才需要手动操作。
手动申领不能恢复已过期轮次的奖励。
若 API 节点在第 N+1 轮期间离线且申领窗口已关闭，则第 N 轮的奖励将永久无法恢复。
手动申领仅适用于上一个轮次，且前提是本地仍保存有正确的种子。
手动奖励申领：curl -X POST http://localhost:9200/admin/v1/claim-reward/recover \
-H "Content-Type: application/json" \
-d '{"force_claim": true, "epoch_index": 106}'此端点仅在有效的申领周期（N+1）内有效。申领窗口关闭后，过期的奖励将无法恢复。
申领验证流程
申领依赖于节点在推断验证中的参与情况。为确保随机性，每个主机（Host）会在周期开始时提交其将用于选择待验证推断任务的随机种子（random seed）的签名。 在执行申领操作时，节点需提供其在周期开始时已上链签名记录的随机种子。
链上系统会验证所有用于验证的推断抽样事件是否均使用了该确切的种子生成。
为完成此验证，系统需要访问所有推断数据，但由于存储成本较高，这些数据仅保留一个周期。
您可使用以下 API 查询推断性能相关信息：GET /chain-api/productscience/inference/inference/epoch_performance_summary/<epochId>/<HostAddress>示例export NODE_URL=http://46.4.101.189:8000/
curl $NODE_URL/chain-api/productscience/inference/inference/epoch_performance_summary/84/gonka1q0a3u8s2azydlu2s2902qxwfz8d7mkze4lf45f | jq这将返回指定纪元（epoch）和主机（Host）的性能摘要。
奖励可能被没收的条件
在以下情况下，主机可能失去获得奖励的资格：
1. 在奖励申领完成前关闭节点
如果主机的 API 节点在奖励成功申领之前被停止、重启或变得不可用，区块链将无法完成申领流程。
2. 过多未完成的推理请求
在整个纪元期间，系统会持续评估推理的正确性。系统跟踪两种独立的故障模式：
- 过多无效推理（Invalid Inferences）
- 过多未完成推理（Missed Inferences，未完成率超过 10%，在样本量较小时会进行统计误差调整；详情请参见代码实现）
这两个指标在整个纪元期间持续采样。如果任一指标在任何时刻超过协议定义的故障阈值，主机将立即面临以下后果：
- 从活跃主机列表中移除
- 抵押品被罚没（Collateral slashing）
- 没收当前纪元的所有奖励
该纪元内主机的所有工作将不获得任何补偿；所有已贡献的推理请求均视为无报酬。具体参数由协议层定义，并可能通过链上治理机制进行更新。主机应始终以当前链上实现为准，以获取权威行为规范。
3. 提前关闭或管理不当
在证明计算（PoC）完成或奖励申领最终确认前过早关闭节点，将导致奖励丢失。
这些条件由协议层强制执行，且不可逆转。
4. 确认阶段（随机）PoC 失败
未能通过确认阶段的随机 PoC 将对主机的收益产生直接且重大的影响。由于确认阶段 PoC 的目的是确保主机持续维持其声明的计算能力，因此失败将被视为该主机不再提供其声明 PoC 权重所依赖的算力。为此，协议将实施严格的经济惩罚措施：
- 没收当前纪元的全部奖励
- 奖励通过比例再分配机制隐式重新分配给其他符合条件的主机
- 抵押品被罚没
- 之前保留的 PoC 权重在奖励计算中作废