early epoch end

[SurfingNerd]

Early epoch stop should occur, if to many participants an the network are not participating in the HBBFT Process,
leading to a situation where the fault tolerance is about to be reached.

The fundamental part is the block seal, so the feature of triggering an early epoch stop can be fully implemented by only judging other nodes if they did send valid block seals or not.

Design proposal:

Nodes should NOT interact with each other to judge if or if not there should be an early stop.
instead they should send their observations to a smart contract that should decide on the early epoch stop.
Those observations are only sent, if there is new missing communication with other nodes, or the communication recovered.

Pro arguments

• No further P2P coordination required
• Data gets monitored on the blockchain.
• No coordination for a system transaction required

Contra arguments

• More overhead on the Blockchain. (more transactions)

Since HBBFT is limited by exponential overhead costs to the number of Nodes, and DMD at current maximum allows 25 Nodes, we can use Bit Fields to reach this goal.
The native WORD on Ethereum has a size of 256 - that is even enough for 256 nodes, but we need only 25 of them.
If we want to store more information, we have enough of Space, and could even use 10 bits per Node.

Up to date checks

To avoid to include outdated information to the blockchain,
senders should include block number and block hash information to verify that their chain data is up to date.
we need to configure the max age of a report.

Malice Reports

Maybe the use of bit fields does not help that much, and just creates an over complicated system.
a report in the format:
reportMissingConnectivity(validatorAddress: address, block_number: u64, block_hash: U256)
and
reportReconnect(validatorAddress: address, block_number: u64, block_hash: U256)
makes things a lot more easy.

Interpretation on the Smart Contract Side:

On the Smart Contracts, we get the individual reports from all Nodes about "their" specific connectivity,
and the smart contract needs to decide if the Communication is good enough to continue the epoch, or it is already risky and it is time for an early epoch switch.
Smart Contract Implementation details are discussed here: DMDcoin/diamond-contracts-core#92

details about the malice reports are discussed here: DMDcoin/openethereum-3.x#75

Settings

Some parameters must be configureable.

• devp2p warmup time: how much time do we give the devp2p communication until we have
• report treshold: how many blocks a validator can be behind at maximum, until he gets reported ?

Implementation tasks overview

• new hbbft validator action: Check for connectivity changes.
• retrieve the current connectivity state from the chain (this is important for restarted clients)
  • Do not, if we are still syncing up.
• send reports for connectivity state changes
  • report connection lost
  • report reconnect
• respect devp2p warmup time, find meaningful values and reduce warmup time
• cache last written observations in memory, so they do not need to get retrieved from the chain over and over
• no EarlyEpochEnd manager and operations if the node is not a Validator.
• no Reporting if the node is a validator, but currently syncing
• handle epoch switches
• prometheus Metrics
• develop an automated test for early epoch end (early epoch end: automated test honey-badger-testing#93)
• unit tests

Change request:

• change treshold from being time based instead of being block based.

Since the reactions of the Node Software for new epochs is already implemented, there should be no need for further changes in starting key gen and ending epochs. (BlockRewardContract handles this)