week- 3-4 Update

## Week 3 & 4 - Updates Spent week3 and week4 to evaluate the project i.e Pureth [EIP-7919](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7919.md), Decided to work on Log reform starting with `EIP-7745: Two-Dimensional Log Filter Data Structure`. Some brief pointers of the Project are following. ### Bloom Filter The Bloom filter is a 2048-bit bitmask. - For each log entry, up to 3 bits are set based on the least significant 11 bits of the first three 16-bit words of keccak256(bloom_entry) (address or topic). - Same method is used to check if the value is present in Bloom filter - No false negatives (if bits are absent, no match), but false positives are possible (bits present don’t guarantee a match). - logsBloom A 2048-bit field in each block header and transaction receipt, aggregating Bloom filters for all logs in the block or receipt. - Clients query eth_getLogs by filtering logs by address, topics, or block range. Bloom filters in logsBloom allow clients to check block headers first, avoiding full receipt downloads for blocks with no potential matches. - If logsBloom bits for a query’s address/topics are absent, the block is skipped, reducing data retrieval. ### Problems in Bloom Filter Currently there are some inconsistencies in the logs due to Bloom filter. - Smart contract wallets have to fetch and verify additional transaction receipts within a queried block range because Bloom filters produce false positives, leading to inefficient log retrieval. - Fetching full receipts because of false positives is impractical for Light clients and mobile devices with resource constraints. - With ~100 transactions/block, each emitting 2 logs (1 address + 3 topics), false positive rate is ~33%, forcing clients to download unnecessary receipts. - As log volume grows (e.g., L1 scaling), false positives increase, degrading query efficiency for light clients and dApps. ### EIP-7745 [EIP-7745:Two dimensional log filter data structure](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7745.md) focusses on enabling trustless log queries by indexing logs using an SSZ-based structure. It targets efficient retrieval of events like ERC-20 Transfer or Uniswap Swap events, with metadata such as address, topics, and block number. - EIP-7745 replaces Ethereum’s Bloom filter-based log indexing with a Simple Serialize (SSZ) structure to enable trustless, scalable, and verifiable log queries for smart contract events. - Logs are stored as SSZ LogEntry containers, combining Log (contract address, up to 4 topics, and data) with LogMeta (block number, transaction hash, indices) for precise tracking. - Indexed properties (address and topics) are assigned sequential indices in a stateful SSZ Vector[LogEntry], storing LogEntry at address indices and topic indices as default(LogEntry) for Merkle proof-based completeness verification. - Logs are grouped into epochs (LogIndexEpoch) , retaining hash_tree_root of older epochs to support Merkle proofs. ### Current focus Currently focussing on Project proposal, i have created an [Initial draft](https://hackmd.io/@vineetpant/SJzcWzYBeg). I am going through Nimbus EL and implementation details for EIP 7745 and will starting working on code from this week, i.e week5. ### Resources | Resource | link | | --------------------------------------- | ---------------------------------------------------------------------- | | Pureth guide | https://pureth.guide/ | | EIP-7745 : 2D log filter data structure | https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7745.md | | EIP-7745 details by Zsolt | https://eips.ethereum.org/EIPS/eip-7745#updating-the-log-index |