consensus/clique: add clique_status API method

[holiman]

This PR introduces clique_status which gives info about the health of the clique network.

• Which signers are currently active, and have signed blocks in the last N (set to 64) blocks?
• How many blocks has each signer signed?
• What is the difficulty in the last N blocks, compared to the theoretical max ?

It's currently a bit PITA to find out how a clique network is performing, and it can easily happen that sealers drop off -- and everything is 'fine' until one more signer drops off, and the network suddenly halts.

This is WIP, but before I polish it (e.g. lowercase json), I'd like some feedback / proposals for things to have here.
Currently:

[user@work go-ethereum]$ echo '{"jsonrpc":"2.0","method":"clique_status","params":[],"id":1}' | nc -U /tmp/geth.ipc | jq .
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "MaxDifficulty": 128,
    "ActualDifficulty": 128,
    "SigningStatus": {
      "0x92de766bbe05bf764a4502db0d2cba76ccdecd20": 64
    },
    "NumBlocks": 64
  }
}

So, what do we want to have here?

cc @5chdn -- might be appreciated for goerli too? We should also agree with Parity about this one, if we want it.

[holiman]

Update:
Now,

• returns the percentage of in-turn blocks,
• operates on up to 64 blocks (but smaller chains too, which is nice for testing)

[user@work go-ethereum]$ echo '{"jsonrpc":"2.0","method":"clique_status","params":[],"id":1}' | nc -U /tmp/geth.ipc | jq .
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "inturnPercent": 100,
    "sealerActivity": {
      "0xfe389916ebd2d2513cd95280da400420d0cdd73a": 10
    },
    "numBlocks": 10
  }
}

[holiman]

PTAL, travis is now 💚

[karalabe]

A few nitpicks here and there.

In general, I'm wondering if the call is reporting the results we're really interested in. I think the most important question we would like answered is whether the network is healthy, and if not, who is at fault.

From this perspective, perhaps a better implementation would be to keep going back blocks indefinitely (optionally capped by an argument), until every signer is accounted for. Then we could report the entire set of signers, and when they were last seen.

We could even create a per-signer histogram of how much time and when the signer was online (kind of like the github punchcard chart (https://www.openmymind.net/assets/forposts/punchard/project1.gif)). That might be a bit more useful than just a number of blocks in the last 16 mins (it allows retrospectively checking for issues, not just in the current state).

[karalabe]

Hard coding 64 seems overly arbitrary. We should probably convert it into an optional parameter, defaulting to 64 if unspecified perhaps. Though even then 64 blocks is 16 minutes, not sure if that's relevant enough.

[karalabe]

Perhaps it would be cleaner to make this a mandatory argument (and also drop the numBlocks from the result)?

[holiman]

I agree that 64 is a bit arbitrary, the reason I didn't set an optional parameter is that it would be too easy to send in a very large number and basically DoS the server. If we want larger span of time, then we'd probably have to do the work during normal operation, and have this method just deliver the data we've accumulated over time.

[holiman]

I have fixed the minor concerns that were listed, except for introducing numBlocks as a parameter, for the reason that I don't want to add an endpoint that is so easily DoS:able.

I agree about the general concerns, however, that requires refactoring so that instead of doing all the work when we get the RPC-invocation, we collect this data during normal execution. Please ACK that we want to do that instead, and I can change this behaviour.

Also, regarding reportcard, could you elaborate on how you think the output from this should look?
Or do you mean that instead of this API-call, we should use metrics for that data?

[fjl]

Don't want this to bit-rot. Having this API available is more useful than not having it, even if it isn't perfect just yet. We can improve it further in subsequent PRs if desired.