attestation rewards如何对账？

验证者余额在一个epoch后变化，不能只用“证明奖励”解释全部差额。Beacon验证者还可能承担提议区块、同步委员会等职责，也可能经历惩罚；执行层费用和MEV又属于另一套证据。attestation rewards端点的价值，是把证明职责中的理想值与实际分项单独拉出来。

请求主键是epoch加验证者

Beacon API定义按epoch查询attestation rewards的POST端点，可在请求体中筛选validator index或公钥。

端点使用epoch路径参数，并允许在请求体中按validator index或公钥筛选。大规模对账分批请求，保存请求集合、响应集合、Beacon节点、网络、客户端版本与采样时点。返回少了某个验证者时标为missing，不填零。

validator index更适合数据库关联，公钥便于外部核对。两者映射应来自同一链状态并带有效时点；不要把测试网index带到主网，也不要把退出或尚未激活的状态简单归类为接口错误。

响应把ideal_rewards与total_rewards分开，并包含source、target、head和inactivity等分项。

ideal_rewards按有效余额档位描述理想参与条件下的参考分项，total_rewards给出目标验证者在该epoch的实际结果。对账时先将验证者有效余额对齐到相应ideal档，再逐项比较实际值。它不是直接用ideal减total就能得到唯一故障根因。

某分项为负或低于ideal时，先保存原始结果和当时链状态，再结合客户端日志、证明包含和规范规则解释。不要把所有差异统一写成“验证者离线”。

奖励字段采用Gwei整数字符串，采集时应保留原始单位并在展示层换算ETH。

API奖励字段以Gwei整数字符串表达。采集层使用任意精度整数保存，不先转浮点ETH；展示时再除以十亿，并标出舍入位。汇总多个验证者与epoch时先在Gwei上求和，避免小数累计误差。

报表同时显示原始Gwei和可读ETH值，导出文件注明单位。若系统还有wei或ETH字段，列名必须带单位后缀，禁止一个amount列混存。负值、零与缺失各自保留，不用空字符串代替。

端点还携带execution_optimistic和finalized语境；单epoch证明奖励不包含全部验证者收入、执行层费用或MEV。

响应所处的执行乐观和最终性语境必须进入对账主键。未finalized的epoch可能在后续状态中变化，先标暂定；处于execution optimistic状态时，执行层有效性尚有额外边界。财务结算等待内部规定的最终性条件，再锁定报表版本。

同一epoch的复采结果若变化，保留A、B两个版本和节点链头，不覆盖原始记录。确认是链状态推进、客户端修复还是数据源差异后，再选择结算版本。

证明奖励、sync committee奖励、区块提议共识奖励、惩罚和余额调整分别进入子账；执行层priority fee与MEV另建账本。最后用验证者余额快照做总账校验。差额存在时列为unexplained，不能把它塞回attestation项使报表看似平衡。

8月6日的sync committee端点按区块和成员职责核对，本页按epoch处理证明参与，两者时间粒度和入选条件不同。验证者没有进入同步委员会，不代表它没有普通证明奖励。

验证者表现、全网参与、有效余额、协议参数和职责分配都会变化。把一个高或低epoch乘以全年epoch数，会制造误导。趋势报告用较长窗口展示分项分布、缺失率和最终性状态，并把任何年化模型的假设单独列出。

最终对账记录包含network、epoch、validator index、公钥、effective balance档位、ideal分项、total分项、单位、finalized、execution_optimistic、节点与客户端版本。第二位复核者可以从原始API重新计算每个小计，才算通过。

先用validator index、epoch和Gwei建立可复算分项，再与余额、其他职责和执行层收入单独对账。无法证明最终性或数据完整时，保留待核验状态，不做年化承诺。

资料访问时间为2026-08-07。当前仍需按部署核验：客户端历史保留、端点性能和协议升级会影响可查询范围，文章不承诺任意旧epoch都可用。

相关站内主题：sync committee rewards、验证者状态、Beacon事件流。本文用于技术教育与节点运维参考，不构成投资、收益或资产安全承诺。