Title: EIP_7745__Two_dimensional_log_filter_data_structur
Category: EIPs

Author: zsfelfoldi
Date: 2024-07-17T14:57:57.627Z

Discussion topic for EIP-7745


github.com/ethereum/EIPs








Add EIP: Two dimensional log filter data structure


master ← zsfelfoldi:new-log-filter



          opened 02:51PM - 17 Jul 24 UTC




            zsfelfoldi
          



+363
-0






An efficient and light client friendly replacement for bloom filters. This EIP p…roposes a new data structure that adds a moderate amount of consensus data that is optional to store long term, has limited processing and memory requirements and allows searching for log events with 2-3 orders of magnitude less bandwidth than what bloom filters allowed back when they were not rendered useless by over-utilization. It also inherently adapts to changing block utilization and maintains a constantly low average false positive ratio.

https://ethereum-magicians.org/t/eip-7745-two-dimensional-log-filter-data-structure/20580








github.com/zsfelfoldi/EIPs


EIPS/eip-7745.md

new-log-filter

---
eip: 7745
title: Two dimensional log filter data structure
description: An efficient and light client friendly replacement for block header bloom filters
author: Zsolt Felföldi (@zsfelfoldi)
discussions-to: https://ethereum-magicians.org/t/eip-7745-two-dimensional-log-filter-data-structure/20580
status: Draft
type: Standards Track
category: Core
created: 2024-07-17
---

## Abstract

Replace the fixed 2048 bit log event bloom filters in block headers with a new data structure that can adapt to the changing number of events per block and consistently guarantee a sufficiently low false positive ratio. Unlike the per-block bloom filters, the proposed structure allows searching for specific events by accessing only a small portion of the entire dataset which can also be proven with a Merkle proof, making the search both efficient and light client friendly.

As an additional benefit, the new structure provides more precise position information on the potential hits (block number and transaction index) allowing the searcher to only look up a single receipt for each potential hit.

## Motivation





  This file has been truncated. show original





An efficient and light client friendly replacement for bloom filters. This EIP proposes a new data structure that adds a moderate amount of consensus data that is optional to store long term, has limited processing and memory requirements and allows searching for log events with 2-3 orders of magnitude less bandwidth than what bloom filters allowed back when they were not rendered useless by over-utilization. It also inherently adapts to changing block utilization and maintains a constantly low average false positive ratio.

Author: wjmelements
Date: 2024-07-17T22:12:44.843Z

Why SHA2 instead of SHA3?

Author: zsfelfoldi
Date: 2024-07-18T09:40:20.232Z

Because log_filter_tree uses SSZ merkleization which uses SHA2. I’m not sure whether and when the existing EL structures will be converted to SSZ but for this purpose a binary tree is absolutely the logical choice, Merkle multiproofs are nice and easy with SSZ hash trees, so I think that sticking with the old hexary MPT format would be really impractical. And if we use an existing format with existing tooling then I don’t see a reason to complicate that by not using the hash function it was specified with.

Author: sbacha
Date: 2025-01-10T02:45:43.508Z

Will there be a test net support for this? Very interested in using this

Author: etan-status
Date: 2025-03-24T15:49:29.663Z

Have split the ProgressiveByteList to its own EIP: Add EIP: SSZ ProgressiveByteList by etan-status · Pull Request #9523 · ethereum/EIPs · GitHub