Offence management

We have to choose a mechanism to manage offense to ImOnline/BABE/GRANDPA.

I think we can adopt the following simple rules:

  • ImOnline offence can happen to anybody because of electricity or network outage, we should immediately trigger the authority removal from the set of authorities
  • BABE/GRANDPA offence can be produced by an attacker or by mistake (multiple validators with same keys), these offence are more problematic and should lead the author to enter a blacklist

The questions are:

  • do we want to increase the penalty for ImOnline offence for example with a blacklist of fees? or do we keep it for human governance (we can exclude someone from the smith if he is offline too often)
  • what are the mechanisms to get out of the blacklist? (decision of technical committee… + fees…)
3 Likes

Let’s keep it simple for a first iteration, i.e. what we agreed on during the hackathon in Bordeaux:

  • ImOnline offence: just auto goOffline. The concerned member will be able to redo goOnline whenever he wants.
  • BABE/GRANDPA offence: auto goOffline AND push the member idty index in a blacklist that will prevent him from doing goOnline again. The removal of this blacklist then requires a manual action of the on-chain governance.
5 Likes

Thanks for this post! Following sentence made me think about this case, I haven’t though about earlier.

As a smith, we should not set up more than one smith/validator node? Of course, it make sense, since it would disturb BABE/GRANDPA algorithm. Coming from v1 ecosystem, this is an interesting point to have in mind. I think this information is relevant to be added to the smith license/charter.

After how many offences, does the smith gets in the black list?