EIP-7668 Remove bloom filters
Hegota Considered for Inclusion · Networking & nodes · EIP status Stagnant · created 2024-03-31
Forces the log bloom filters in execution blocks and transaction receipts to be empty. The bloom filter processing that every client performed goes away.
Why it is needed
Logs on Ethereum are a feature that lets apps record what happened on chain so they can find it easily later. A bloom filter is a summary structure that helps with that search. Its original goal was to quickly narrow down which blocks are relevant to your app without scanning the full history. In practice, however, this approach is far too slow. Most apps that query historical logs do not ask an Ethereum node directly and instead use centralized services outside the protocol. Even so, every client has to compute a bloom filter that no one uses each time it builds and validates a block. This proposal acknowledges that reality and proposes removing bloom filters from the protocol. Apps that need history queries are encouraged to use decentralized protocols that build verifiable log indexes with techniques such as zero-knowledge proofs.
What changes
Today
- Every execution block and receipt contains a log bloom filter, and clients compute it every time
- Past logs can be found with the bloom filter, but it is too slow in practice and is rarely used
- Most apps that need history queries depend on centralized external services
After EIP-7668
- The logs bloom field in blocks and receipts must be empty (0 bytes), and clients no longer compute the bloom
- Log lookup methods that relied on the bloom filter no longer work
- Apps are encouraged to use decentralized alternatives such as verifiable log indexes based on zero-knowledge proofs
Who is affected
- Client teams: The bloom filter computation done on every block build and validation goes away, which reduces the processing load.
- App developers: Apps that read events through the bloom filter stop working. The source says very few apps currently depend on this feature.
- Light client: The source states that light clients were originally designed to be the main beneficiaries of the bloom filter, but long history queries are especially slow, so there was no real benefit.
- Indexing services: Development of decentralized protocols that build verifiable log indexes is encouraged.
In depth
Specification: force the bloom field to be empty
The logs bloom of an execution block must be empty (0 bytes long). The logs bloom of a transaction receipt must likewise be empty (0 bytes long). The approach requires the value to be empty rather than deleting the field itself. The specification is simple enough that these two sentences are all of it.
Why emptying was chosen over deleting the field
The source describes this approach as the least disruptive way to make clients no longer need to process blooms. Because it only empties the value without changing the block and receipt data structures right away, the implementation changes are small. Removing the field entirely is left for a later separate EIP, to be cleaned up together with other fields that have already been deprecated.
LOG gas costs are not reduced
The external cost of polluting the bloom filter no longer needs to be counted, but the source does not reduce the gas cost of LOG. It explains that hashing costs have risen because of the needs of ZK-SNARK-based EVM implementations. In other words, the argument is that as one cost goes away another grows, so the reasons for a price cut cancel out.
Backward compatibility: why the impact is considered small
Apps that read events by relying on the bloom filter stop working. However, the source judges that very few apps currently depend on this feature. This is because, at current gas limits, the bloom filter's false positive rate is too high and processing logs in long history queries is too slow. It points out that this is especially so for light clients, the feature's original main beneficiaries. It states that no security concerns are raised because no new functionality is added and nothing is made cheaper.
Alternative: provable log indexes
Instead of the protocol taking responsibility for history queries, the source recommends developing and using decentralized protocols that build provable log indexes with techniques such as ZK-SNARKs and incrementally-verifiable computation. Since most apps already query history through services outside the protocol, the direction is that it makes sense to make that query layer verifiable.
Document status and fork discussion
The status of the source document is Stagnant, meaning updates have stopped as far as the repository is concerned. Discussion has nonetheless continued on core developer calls. It was accepted as a Hegota candidate (PFI) at ACDE #242 on 07.30, and at ACDE #246 on 09.24 it was moved up to Considered for Inclusion (CFI) for Hegota together with EIP-7906, EIP-8250, EIP-8272, EIP-8253, EIP-3298, EIP-8131 and others. Inclusion is not confirmed, and the content may still change.