eth: `eth_getBlockBy*` / `newHeads` return an all-ones `logsBloom`

[akaladarshi]

Describe the bug

Forest returns a block-level logsBloom with all bits set 1 (0xff…ff, 256 bytes) for every block on eth_getBlockByNumber, eth_getBlockByHash, and the newHeads subscription.

FEVM log indexers use logsBloom as a cheap skip test: if the the block has no logs and can be skipped without an eth_getLogs call. An all-ones bloom matches every query, so indexers can never skip anything and must call eth_getLogs on every block. This is especially wasteful on Filecoin, where the majority of tipsets contain zero EVM events.

The bloom is hardcoded to the full constant in Block::new and never overwritten during block construction:

logs_bloom: Bloom(ethereum_types::Bloom(FULL_BLOOM)),   // FULL_BLOOM = [0xff; 256]

Note: per-transaction receipt blooms are already computed correctly (src/rpc/methods/eth.rs:1383-1390); only the block-level bloom is wrong.

To reproduce

• Run forest node with ChainIndexer turned on
• Call the eth_getBlockByNumber

Log output

Log Output

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "number": "0x...",
    "hash": "0x...",
    "logsBloom": "0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "...": "..."
  }
}

Expected behaviour

The block logsBloom must be the OR of the per-log blooms of exactly the logs the node returns for that block via eth_getLogs. Similarly, the OR of the block's transaction-receipt blooms:

• A block containing EVM events → a bloom with only the relevant bits set (block.logsBloom == OR(receipt.logsBloom for each receipt)), and not all-ones.
• A block with no EVM events → an all-zeros bloom.
• The bloom must be a superset of the block's logs so it never produces a false negative (a missed event). An all-ones bloom (the current value) is "safe but useless".

Other information and links

• Lotus issue: Calculate and return logsBloom on eth_getBlock* API calls filecoin-project/lotus#13546