钱包同步一条交易时，日志会把这次调用改了什么交代清楚。但 ETH 余额有几类变化天生没有交易可挂：出块者收下的优先费、验证者提款落进执行层的 ETH、以及创世分配。这些钱在状态里确实动了，eth_getLogs 却查不到任何记录，因为日志历来必须是某条交易执行的产物。EIP-7799 提议增加一类区块级系统日志，把这类事件纳入同一套查询接口。
盲区是怎么暴露出来的
这个问题是被 EIP-7708 逼出来的。那份提案让原生 ETH 也能像 ERC-20 一样通过 Transfer 事件被索引，钱包于是可以用一条日志查询做增量对账。方案一路顺畅，直到有人去查提款：账上钱到了，日志里没有。出块收益同理——一个只收小费的区块，收益方余额增加，区块里却没有任何交易执行这笔转账。结果是钱包与索引服务必须为这几类事件写特例，而且特例无法用日志接口实现，只能重新执行区块或依赖自建的私有数据库。系统日志的目标就是把这些特例消掉。
要做几件事
机制上，提案给区块引入一组不属于任何交易的事件，并把事件列表纳入区块承诺，因为任何非确定性都会直接变成分叉风险。接口层因此出现三处变化。JSON-RPC 层面，eth_getLogs 的返回会包含这类区块级条目，钱包可以像处理普通事件一样处理它们。执行区块与引擎 API 层面，需要新增承载字段，让事件列表进入区块头承诺，这样所有客户端与索引器对同一批事件得到同一哈希。规则层面，事件的生成必须是纯确定的：提案把清单拆成优先费处理、提款处理、创世处理三类，逐项规定涉及哪个地址、金额多少、按什么顺序排列，并在共识层执行载荷结构中相应扩展。
对索引生态的意义
今天要把一个地址的 ETH 余额历史算准，索引服务通常要重放区块并额外处理提款队列，工程量与出错面都不小。系统日志把这部分规则搬到协议层，索引器与轻钱包可以直接把事件流当事实来源，余额增量对账变成一次查询。需要划清的是它与信标层机制的分工：验证者的退出资格、提款金额与时机由信标层规则决定，系统日志只记录这些结果在执行层落地的那一刻，两者是同一件事的两端，不是两套账。
当前状态
截至本文写作时，EIP-7799 处于草稿状态（Draft），创建于 2024 年 10 月 29 日，声明依赖 EIP-4895（信标层提款）、EIP-6466（版本化执行载荷）、EIP-7708（ETH Transfer 事件）、EIP-7916 与 EIP-8115。事件编码格式与区块头字段位置仍可能随讨论调整，未关联已激活升级。
一个对账场景
拿最常见的钱包对账来说：用户收到一笔质押提款，余额增加三千分之一 ETH。今天的钱包要发现它，要么轮询历史并模拟出块收益与提款应用逻辑，要么订阅第三方提款数据库，两条路都慢且各有精度坑。系统日志落地后，同一个问题变成一次 eth_getLogs：按地址过滤提款类事件，拿到区块号与金额，对账即完成。对索引服务商，这等于把一块长期存在的脏活退回协议层，行业里的对账类接口会明显简化。
快速问答
问：这算链上事件推送吗？ 答：不是推送，是查询接口的补全。事件仍然存在区块里，由节点与索引器供查询。 问：为什么以前没人做？ 答：原生 ETH 长期被认为不需要索引，余额追踪靠代币事件足够；EIP-7708 打通 ETH 事件后盲区才显形。 问：会额外收 Gas 吗？ 答：系统日志由协议在区块处理中生成，不向交易发送者收费，成本体现在区块承诺与节点处理上。
风险提示：本文为接口与机制科普，不构成投资建议；事件定义与字段以官方规范当期文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。