drop logsBloom support

[advaita-saha]

This PR removes the logsBloom field from stored receipts. The bloom filter can be recomputed when needed (e.g., for networking or RPC), so storing it in the database is unnecessary.

None of the major clients (Geth, Nethermind, Besu, Erigon) store bloom filters in their receipt DB. However, the networking spec still requires logsBloom to be included in receipt responses. As a result, serving peers regenerate ~530GB of bloom data (2.3B txs × 256 bytes) per sync — which is verified and then discarded by the syncing peer.

This is an unnecessary bandwidth and I/O cost.

Historically, bloom filters were included in receipts to support log filtering over the P2P layer. With eth/69 removing that requirement, there's no longer a reason to persist this field. This aligns with real-world client behavior and reduces resource usage.

We still comply with the protocol by computing and returning logsBloom on demand when serving receipts. We are only skipping its storage on disk.

Since this is a pre-release client, we're free to adjust the receipt schema without impacting compatibility.

Advantages:

• Avoids storing redundant data
• Saves ~530GB of network bandwidth during syncs
• Matches behavior of other clients
• Maintains full protocol compliance

---

TODO

• Optimise the usage of Receipts/StoredReceipts
• Complete nim-eth bump and merge master

[advaita-saha]

Needs #3290

[tersec]

Needs #3290

Merged

[arnetheduck]

isn't this on the "declined for inclusion" list? https://eips.ethereum.org/EIPS/eip-7607#declined-for-inclusion

[advaita-saha]

isn't this on the "declined for inclusion" list? https://eips.ethereum.org/EIPS/eip-7607#declined-for-inclusion

We are not removing bloom filters from the execution block. We are just not storing it in receipts, as we don't need to
Also none of the client stores bloom filters along with their receipts
This came with eth69 discussion

We recently discovered that none of the clients store the Bloom field of the receipts as it can be recomputed on demand. However the networking spec requires the Bloom field to be sent over the network. Thus a syncing node will ask for the Bloom filters for all receipts. The serving node will regenerate roughly 530GB of bloom filters (2.3B txs * 256 byte). These 530GBs are send over the network to the syncing peer, the syncing peer will verify them and not store them either. This adds an additional 530GB of unnecessary bandwidth to every sync.

We earlier needed bloom filter in receipts to serve them in p2p layer or rpc, well IMO didn't make sense to store the bloom filters back then also. But now the requirement for p2p layer gone, doesn't make sense a lot more to keep storing them,
Specially when we have the freedom for altering the database with minimal damage, being a pre-release client