Create metric that listens for event on block proposal

[Lsquared13]

Issue

For network security reasons, it would be helpful for block proposers to emit an event when they propose blocks, so we can know if there are any significant deviations from the expected pattern.

[Lsquared13]

We probably need to listen to the events that Validators listen to for votes

[Lsquared13]

Previous title was misleading. We shouldn't need to add a new event, and we can't rely on that anyway or somebody can just remove our event from their code. We need to listen to the same event that notifies validators that a block is looking for votes, so if they remove that event, validators never vote for them anyway.

Here is the closest example we have. This script creates a filter for new blocks and polls that filter for new blocks, and emits a metric if it generated that new block. We use this metric to determine what regions created blocks are coming from, and if they are heavily skewed.

There are some key differences between this, and what we want here:

• We want a metric that counts proposed blocks, not validated blocks. You will need to listen to the event that requests votes from validators, and you will also be counting the blocks that are never voted into the chain.
• We probably don't need or want the DynamoDB running count
• We cannot rely on nodes self-reporting like we do on the blocks by region, we need to have the validators count them.
• Because we cannot use self-reporting, we need to deal with potentially double counting
• We need to be able to reliably monitor this in a dashboard and set alarms on any particular maker node proposing too many blocks. If we put the maker's identity in a Dimension, we may need to keep track of all the makers so we can have all the alarms, I'm not sure. The maker set changes based on governance at a rate of one maker being swapped for a new one per month (I think) so it doesn't need to refresh quickly, and manual management, while not ideal, may be feasible.

[Lsquared13]

I'm hoping we can do this without modifying quorum. We can if we have to, but let's try not to.

[ExcChua]

I've done something similar a few months back. So the solution I'm thinking of will be a Node.js solution, so the target node running this solution of mine will need to be one of the Quorum nodes.

The solution wouldn't have to modify Quorum.

[Lsquared13]

Ideally I think we want at least the validators using this. They should have node installed. quorum-genesis uses this

[Lsquared13]

Need to rethink this issue with our current model

[ExcChua]

I'm not sure I understand you. Please elaborate.

[Lsquared13]

Just don't start this yet (It's not in our sprint anyway) but at some point we'll need to have a call including @eximchain137 and talk over the design change included in the geth 1.18 rebase