I would love to take this up if still needed :)

Hi guys!
Can I take this up?

Hi @potuz!

I have a question related to this issue.

I understand that the slashing logic for an equivocating block is done in the slasher service which runs as a routine listening to the BeaconBlockHeadersFeed.

Breaking down what the slasher does when receiving a new block, we have:

• detectProposerSlashings (read and write ops)
• processProposerSlashings

At the moment, my PR simply implements the detectProposerSlashings read op bit in the beacon chain. I am not sure if you are expecting me to implement the write op too - which is merely saving the proposerSlashings to the database.

Also, I am not sure that implementing the broadcast in the beacon chain is what you are expecting as I would bypass the processProposerSlashings which first verifies the block headers signatures, log the slashing proposal and then insert it in the becon node's operations pool.

Could you give some pointers. Thanks!

Maybe two different possible roads would be:

1. The BN also write the detectProposerSlashings write bit, which would result in sending a new type of event to the slasher in order to avoid stressing the DB and for further processing (verify the header signatures)
2. The BN is the source of truth when it comes to flagging equivocating blocks and fills a cache (something along the lines of [epoch-1, epoch] as a range).

Let me know what you think.

Apologies for being late here. What I want in the issue is to act completely independent of the slasher: when the BN receives a block on gossip and it already has imported a different one for the same slot and proposer, it should immediately construct the slashing message and broadcast

And yes, I would expect you to bypass the db writing indeed, I'll review this tomorrow morning (without a computer today)

Oh, I see, you want it completely independent, I used the slasherDB which is wrong, I am going to remove that. My bad!

I guess the best course of action here would be to use a cache as proposed here:

The BN is the source of truth when it comes to flagging equivocating blocks and fills a cache (something along the lines of [epoch-1, epoch] as a range).

I am thinking about retaining the block_roots >= finalized_slot and having an enum that would flag whether the block_root already exists or different and broadcast a potential slashing message looking into the cache after the validation of the block signature. Does that sound good to you?

I've made a PR for resolving this issue, it's work in progress but wanted to check if the approach looks correct. If yes, I can add unit tests later cc: @potuz