sync committee奖励怎么对账？

验证者收益出现差异时，直接比较钱包余额很难定位原因。同步委员会奖励是一个更小、边界更清楚的切片：它针对特定区块中的同步委员会参与情况。Beacon标准API提供专门端点，让运营方可以把职责证据与奖励金额逐项核对。

先固定block_id再取奖励

Beacon标准API定义 /eth/v1/beacon/rewards/sync_committee/{block_id} 端点，可按区块查询同步委员会奖励。

端点路径包含block_id。生产对账不应长期使用会移动的head作为唯一标识，最好保存查询时解析出的slot、block root和执行时间。若按slot查询，也要确认该slot是否确有规范区块，避免把空slot与接口故障混为一谈。

客户端可能因历史保留、同步状态或版本支持而无法回答旧区块。采集器应保存HTTP状态、标准错误体和客户端版本；遇到ResourceUnavailable类结果时切换到经过验证的归档Beacon节点，而不是写零奖励。

同步委员会成员在区块中由SyncAggregate记录参与位与聚合签名，奖励与是否正确参与该职责相关。

区块中的SyncAggregate包含参与位与聚合签名。对账时需要知道该周期的同步委员会成员列表，并将位图位置准确映射到validator index。位置错一位，就会把一个验证者的参与归到另一个验证者。

先验证区块与委员会，再比较API奖励。若位图显示参与而返回金额异常，继续检查有效余额、协议参数、客户端实现与区块是否规范；不能仅凭“有签名”假设所有成员金额相同。

API奖励值以Gwei口径表达，采集和数据库应保留整数单位再在展示层换算ETH。

数据库使用整数Gwei可以避免浮点累计误差。展示ETH时在边界层使用定点十进制转换，并明确小数位和舍入规则。CSV导出也同时保留原始Gwei，方便不同系统复算。

对账主键建议包含chain、block root、validator index和奖励类型。重复采集同一区块应执行幂等更新；若重组导致同slot根变化，旧记录标记为非规范并保留审计轨迹，不要直接覆盖成新金额。

单区块sync committee奖励不包含全部共识奖励、惩罚、执行层费用或MEV，不能直接年化。

同步委员会奖励不包含全部证明奖励、提议者奖励、惩罚、执行层交易费或MEV。委员会轮换、有效余额和节点在线率也会变化。拿一个高或低样本乘以全年区块数，会制造没有统计基础的收益率。

报表应把收入按来源分栏：attestation、sync committee、proposal、其他共识项、执行层费用与外部构建者支付。若某项数据源缺失，显示“未计入”，而不是默认为零。

第一步锁定规范block root；第二步读取对应委员会成员快照；第三步解析SyncAggregate参与位；第四步调用奖励端点并以validator index关联；第五步把结果归集到内部validator、集群和客户账户。每步保存来源版本与哈希。

若同一validator由多个实例运行，不要按实例重复计奖；链上validator index才是协议身份。内部故障归因可以再用签名日志、节点标签和监控时间线关联，但不改变链上金额。

工单附chain、slot、block root、validator index、委员会周期、参与位、原始奖励Gwei、API节点与客户端版本。描述是“标准端点返回与内部预期差X Gwei”，而不是先下结论“客户端少发奖励”。复算脚本和原始响应应可重复执行。

同步委员会奖励适合解释某个区块、某组验证者的一项共识职责。保留block root、整数Gwei与映射快照，再与其他奖励和费用分别归集，才能得到可信对账。

复核本文时请从Ethereum Beacon APIs OpenAPI、Ethereum Altair Beacon Chain、Ethereum Beacon APIs Repository开始，并检查访问日期与版本。

当前不能越过的事实边界是：客户端历史保留与端点版本不同，旧block_id可能无法查询。

相关背景可继续查看Beacon RANDAO、proposer duties兼容、validator balances。接口、客户端与网络状态会随时间变化，本文不构成投资、交易或收益建议。