区块里那排布隆位图想退役：EIP-7668 与日志查询的现实之痛

日志本该是自己查的

智能合约跑完一笔业务，会在收据里留下一条条日志：谁转给谁、仓位开没开、拍卖落没落槌。问题是怎么快速从几千万个区块里把这些散落的日志捞出来。以太坊的原始答案是布隆过滤器：每个区块头和每笔交易收据里都嵌一个 256 字节的位图，把这条日志用到的地址和主题哈希经过几个哈希函数映射到若干比特位上置成一。想知道某笔交易有没有你要的事件，先花几乎为零的成本查位图——位图说没有，那一定没有；位图说有，再去细读日志确认，误报在数据量大的时候高得可观。这一层机制的来龙去脉在 布隆过滤器是什么？区块里快速找交易的捷径 里讲得完整，本文只谈它的退休提案。

十年之后没人真用它查历史

EIP-7668 在 2024 年 3 月 31 日由 Vitalik Buterin 提交，动机一节写得毫不留情：日志本来是为了让去中心化应用能方便地查链上历史，可现实是几乎所有要查历史的 dapp 都不再直接问节点——哪怕问的是远程托管的节点——而是投奔了中心化的索引服务。原因有二。其一是过滤器太钝：按现在的 Gas 上限，区块里塞进的日志越多，布隆位图被点亮的位就越多，误报率水涨船高，扫描一段长历史时你要把海量收据翻出来复核，慢到不可用。其二是节点 RPC 本身对大范围历史扫描不友好，各家服务商对查询范围都有限流。于是链上留着一套为轻客户端设计的快捷结构，链下的真实查询流量全走了另一条路。提案状态停在 Stagnant（停滞）。

提案的动作：置空而非删除

7668 的规范只有两句话：执行区块的 logsBloom 必须为空（零字节），交易收据的 logsBloom 必须为空（零字节）。注意它选择的是置空而非删字段——区块和收据的字段布局不动，老解析器还能工作，只是读到一个永远为空的位图；理由一节说得很务实：这是扰动最小的拆法，等以后统一清理废弃字段的提案出现时再彻底删掉。提案还顺手算了 LOG 操作码的账：费用不调低，因为虽然不用再为污染布隆器的外部性定价了，但零知识证明方向的新需求让哈希成本本身涨了。兼容性一节承认：依赖布隆器读事件的应用会停止工作——但这样的应用现在已所剩无几。安全考量一节只有一句：不引入也不廉价化任何新功能，因此没有新的安全问题。

接班的是什么

把布隆器请出去之后，查日志这件事去哪？提案点名的方向是用零知识_SNARK 或增量可验证计算这类工具做出可证明的日志索引协议，让去中心化的索引服务既快又能自证没撒谎。这条路线到今天仍在推进：各类事件订阅网络、可验证日志索引项目都在填这个位置。对开发者的实际含义是：写依赖事件的应用时，把布隆过滤器当成一个随时可能变空的遗留字段，检索逻辑建在事件服务或自建索引上；对普通用户的含义更简单：你在区块浏览器上按事件筛交易时，背后跑的大概率早就不是协议里那位布隆老兵。

收据格式为什么老在动

布隆器的去留不是收据字段孤立的一桩搬家：收据格式近年反复被重新设计，比如用更紧凑的树结构重排收据的提案，以及给收据换编码方案的提案，都在这片地基上动土。读这类小提案能校准一个认知：协议层的每个字段都是一份维护成本，当某段历史留给快捷结构的收益被链下生态吸收之后，字段本身就进入被淘汰的排队区。布隆位图从 2015 年立项时算作轻钱包的福音，到 2024 年被提案置空，中间隔的是整个索引服务产业的兴起。

一个自查练习

下次用 RPC 拉一段历史日志时做个实验：先用 eth_getLogs 按地址和主题过滤，再随手解析几笔收据里的 logsBloom 字段，对比两种路径的耗时和完整度。你会在几分钟内亲身重演 7668 动机一节写的那段历史——过滤器的误报与节点限流如何把所有人推向第三方索引。机制层的抽象读十遍，不如一次这样的动手对照。

风险提示：本文为协议机制分析，不构成投资建议；依赖事件数据做交易判断前，请核实索引服务的数据口径与延迟。