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: https://github.com/DMDcoin/diamond-contracts-core/issues/92
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)
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
Contra arguments
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 ageof 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)andreportReconnect(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: https://github.com/DMDcoin/diamond-contracts-core/issues/92
details about the malice reports are discussed here: https://github.com/DMDcoin/openethereum-3.x/issues/75
Settings
Some parameters must be configureable.
Implementation tasks overview
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)