Jormungandr: Jormungandr not quarantining pools transmitting multiple blocks from different nodes within the same slot

[aeonpool]

Describe the bug
Pools deliberately create multiple blocks for the same slot, which are transmitted from multiple nodes, in order to increase the chances of a block being accepted.

This contributes to network forks and instability.

Mandatory Information

1. jcli --full-version output;
   jcli 0.8.5 (HEAD-3db06807+, release, linux [x86_64]) - [rustc 1.39.0 (4560ea788 2019-11-04)]

1. jormungandr --full-version output;
   jormungandr 0.8.5 (HEAD-3db06807+, release, linux [x86_64]) - [rustc 1.39.0 (4560ea788 2019-11-04)]

To Reproduce
Steps to reproduce the behavior:

1. Start multiple nodes as leaders with the same pool keys.
2. Wait for leader event.
3. Both nodes broadcast the block to the network.
4. Block received by other pool's nodes contains multiple hashes.

Expected behavior
Jormungandr should place these nodes in quarantine for an extended period of time to disincentive this behaviour.

Additional context
Add any other context about the problem here.

[rickymac68]

This needs to get fixed ASAP. Is there even a known fix?

[SViksha]

@CharlesHoskinson @rickymac68
If the leader creates multiple blocks at the same slot, they should be penalized by 50% reduced blocks in the next epoch. If they do it two time in the same period, it should be further reduced to 25% and so on. The penalty should be by leader id and not by IP as it can be changed. If you quarantine the IP, they can run multiple passive nodes and then run the leader via them so it will never affect the leader. So the penalty on leader id is the only solution.

[mmahut]

@SViksha how would you propose to implement that?

[jam35x]

Possible solution is that all nodes should skip the slot for which multiple blocks created by same pool. If a node receives multiple block by same pool it should broadcast the blocks to the network to prove and verify it's attack and slot should be skipped.

[mmahut]

If a node receives multiple block by same pool it should broadcast the blocks to the network (...)

Most of the time nodes receive only one of the two blocks. That is why it is creating forks.