From ced8d24e61f870048f8685125f0027fc6710f2a3 Mon Sep 17 00:00:00 2001 From: Zsolt Felfoldi Date: Thu, 18 Jul 2024 12:14:19 +0200 Subject: [PATCH] changed title --- EIPS/eip-7745.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-7745.md b/EIPS/eip-7745.md index 2c34be129ec527..625691f31c01e7 100644 --- a/EIPS/eip-7745.md +++ b/EIPS/eip-7745.md @@ -1,9 +1,9 @@ --- eip: 7745 -title: New log filter data structure +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-new-log-filter-data-structure/20580 +discussions-to: https://ethereum-magicians.org/t/eip-7745-two-dimensional-log-filter-data-structure/20580 status: Draft type: Standards Track category: Core @@ -298,7 +298,7 @@ Searching for a certain _log value_ requires access to a given row index that is On the other hand, _log values_ added during block processing typically placed into many different rows but occupies a continuous _log value index_ range which in most cases falls into the range of a single _filter map_. A column-major indexing (`log_filter_tree[map_index][row_index]`) places all rows of the same filter map next to each other, ensuring that during block processing typically only the subtree belonging to a single _filter map_ and the `map_index` path leading up to it needs to be re-hashed. -In order to achieve good performance in both aspects, a third, mixed index ordering approach has been chosen for `log_filter_tree` that splits `map_index` into two parts, `epoch_index = map_index // MAPS_PER_EPOCH` and ` map_subindex = map_index % MAPS_PER_EPOCH` and indexes the tree as `log_filter_tree[epoch_index][row_index][map_subindex]`. This approach allows efficient Merkle proofs like row-major ordering for entire epochs and actually performs even better when multiple epochs are proven because the expensive `epoch_index` path needs to be proven only once instead of once per epoch. Tree update hashing cost is higher than in case of column-major ordering because it hash to also update a `map_subindex` path for every updated row. As calculations below show though, the extra cost is significantly smaller than in case of row-major ordering which has to update an entire `map_index` path for every updated row. +In order to achieve good performance in both aspects, a third, mixed index ordering approach has been chosen for `log_filter_tree` that splits `map_index` into two parts, `epoch_index = map_index // MAPS_PER_EPOCH` and `map_subindex = map_index % MAPS_PER_EPOCH` and indexes the tree as `log_filter_tree[epoch_index][row_index][map_subindex]`. This approach allows efficient Merkle proofs like row-major ordering for entire epochs and actually performs even better when multiple epochs are proven because the expensive `epoch_index` path needs to be proven only once instead of once per epoch. Tree update hashing cost is higher than in case of column-major ordering because it hash to also update a `map_subindex` path for every updated row. As calculations below show though, the extra cost is significantly smaller than in case of row-major ordering which has to update an entire `map_index` path for every updated row. The calculations below are based on the proposed constants: