链上日志是便宜又重要的数据源：谁转了什么、哪个合约调了谁，全在收据的日志里。但”查日志”这件事一直是黑箱——你问 RPC 服务商某个地址发过哪些事件，对方给你一张清单，你没有任何办法验证清单全不全。EIP-8304（Trustless log and transaction index）想把日志和交易的查询做成可证明的：区块处理逻辑顺手生成索引表，表的根哈希进系统合约，查询方从此能拿到一份”没漏没改”的证明。提案 2026 年 6 月 17 日提交，状态 Draft，依赖 EIP-4788。
布隆过滤器为什么不中用了
区块头里原本挂着每块的布隆过滤器，用来快速排除”这块肯定没有”的情况。提案的批评很直接：当年的过滤器设计如今已经饱和——日志太多，过滤器几乎什么都”可能有”，作为排除工具基本失灵。全节点当然可以自建索引，问题是绝大多数用户不跑全节点，只能问远程服务商，而服务商给不出结果正确性的证明。链越扩容，这种信息不对称越严重：协议把数据放在了一个去中心化的账本上，读它的入口却是一个个无法验证的中心。
索引表与根上链的结构
方案的核心物件叫索引表：一系列索引条目按二进制编码的字典序排好，哈希成固定深度的二叉树，每棵树的根哈希存进系统合约的存储里。参数表给了五档尺寸，TABLE_SIZES 为 1、4、16、64、256 个区块一级，每级的表根用长度 1024 的环形缓冲存放——单块生成的表会被逐层合并成覆盖几十上百块的大表，查一段历史不必从一块块拼。条目有多种类型、各有编码规则，表由 first_block 与 table_size 定位。设计目标是让生成与合并的代价足够低，低到值得塞进每个区块的处理逻辑里顺手做掉。注意它不改区块头里的布隆过滤器，两者并存。
对查账意味着什么
对用户侧最实际的变化：钱包或浏览器插件可以验证”服务商给的这份事件清单是真的、完整的”，就像验证余额有 Merkle 证明一样；跨链场景收益更大——只要知道对方链上一个近期区块哈希，就能用索引证明把那边的日志作为差分更新喂给本地合约，这是提案列出的动机之一，其信物核验依赖 EIP-4788 提供的区块哈希入口。这与监控工具怎么知道事件发生了：轮询与订阅推送的分工讨论的轮询与订阅分工是正交的：订阅解决”何时知道”，可证明索引解决”知道的是不是全部”。
它不是什么
先把期望钉住：EIP-8304 是草案，规范里系统索引合约的地址仍是待定项；它不取代收据字段——今天读一笔转账仍然按交易回执里的Logs是什么？链上转账“收据”的字段与读法讲的 topics 与 data 结构来；也不解决”链下服务商该不该收钱”这类索引 API 商业化问题，更不替代归档节点的按高度历史查询（那条路见想查某个区块高度的历史代币余额？归档节点与查询参数的边界）。提案针对的是最基础的一问：查询结果的可信性从”信这家公司的名声”变成”验证一份几 KB 的证明”。
查账场景的一次沙盘推演
设想一个具体需求：核对某合约过去一年发出的全部提现事件。今天的路径是翻服务商的事件分页接口，或者自己跑节点重扫收据，前者的完整性只能靠信任，后者的成本劝退个人。索引表落地后同一条需求的形状变成：先向任意提供证明的端点按地址条目拉一段表的包含证明，本地对根哈希与系统合约里的记录做验证，再对证明里的每条日志回查收据字段确认内容。整条链上你只信任协议参数和一个区块哈希，服务商从”必须诚实”降级为”必须响应”。对普通用户还轮不到这套流程，但它预支了一个值得留档的核对坐标：索引根所住的那份系统合约——地址仍在草案里待定，上线后第一时间把它写进自己的查账工具箱。
读这类提案的方法
分三层核对：数据结构层（索引表如何编码、根存在哪）归本提案；客户端是否实现、公共 RPC 是否开放证明查询，是另一回事；钱包愿意不愿意把”结果已验证”显示在界面上，又是生态问题。任何一层被宣传成”已经可用”，都值得回官方仓库核对 status 字段。参数与条目编码以提案文本为准。本文为机制科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。