Besu is not reporting bad blocks

[shemnon]

Steps to Reproduce

Besu has not been reporting bad blocks, specifically invalid blocks produced by other members of a eof devnet environment. For example on https://forkmon.eof-devnet-0.ethpandaops.io/ only geth and nethermind are reporting blocks they disagree with.

Expected behavior: Besu's bad blocks RPC returns bad blocks recently seen

Actual behavior: No bad blocks seen

Frequency: whenever a blad block occurs

To reproduce run this Kurtosis environment:

participants_matrix:
  el:
    - el_type: besu
      el_image: ethpandaops/besu:main
    - el_type: nethermind
      el_image: ethpandaops/nethermind:feature-evm-eof-e1e375c
    # - el_type: reth
    #   el_image: ethpandaops/reth:main
    - el_type: geth
      el_image: ethpandaops/geth:osaka-mega-eof
  cl:
    - cl_type: prysm
      cl_image: ethpandaops/prysm-beacon-chain:develop-557c5be    
network_params:
  electra_fork_epoch: 1
  fulu_fork_epoch: 2
  seconds_per_slot: 4
additional_services:
  - dora
  - el_forkmon
  - assertoor
assertoor_params:
  image: "ethpandaops/assertoor:latest"
  tests:
    - file: https://gist.githubusercontent.com/shemnon/3854a75448dff222b04a09909ad1394c/raw/fulu-activated.yaml
    - file: https://gist.githubusercontent.com/shemnon/3854a75448dff222b04a09909ad1394c/raw/EOF-create-with-short-container.yaml

Using the forkmon we should start seeing a fork very early in epoch 2, with bad blocks reported by nethermind sometime before block 70. Besu never reports Nethermind's produced blocks as bad, whereas Geth does.

To update besu you will need to deploy a local docker version and update the el-image tag. The nethermind image is a version with a known bug that will produce bad blocks associated with the assertoor test.

Logs

No relevant logs

Versions (Add all that apply)

master

Additional Information (Add any of the following or anything else that may be relevant)

Perhaps the fork choice rule is preventing the block from being considered?

[shemnon]

This participant list may produce quicker results, although nethermind doesn't finalized (unexpectedly)

participants:
  - el_type: besu
    el_image: ethpandaops/besu:main
    cl_type: prysm
    cl_image: ethpandaops/prysm-beacon-chain:develop-557c5be    
    validator_count: 33
  - el_type: nethermind
    el_image: ethpandaops/nethermind:feature-evm-eof-e1e375c
    cl_type: prysm
    cl_image: ethpandaops/prysm-beacon-chain:develop-557c5be    
    validator_count: 134
  # - el_type: reth
  #   el_image: ethpandaops/reth:main
  #   cl_type: prysm
  #   cl_image: ethpandaops/prysm-beacon-chain:develop-557c5be    
  - el_type: geth
    el_image: ethpandaops/geth:osaka-mega-eof
    cl_type: prysm
    cl_image: ethpandaops/prysm-beacon-chain:develop-557c5be    
    validator_count: 33   

[jframe]

This might be fixed by this PR #8207

[shemnon]

Sounds like the same root cause, just manifesting in a different use case.