Unbond/Deactivate inactive validators

[adrianbrink]

Implement liveness protection.

In particular, the current idea would be to jail a consensus validator who has not voted on enough blocks within some past interval.

Started implementation here: #981

[cwgoes]

We should be able to copy the Cosmos SDK model:

• https://github.com/cosmos/cosmos-sdk/tree/main/x/slashing#signing-info-liveness
• https://github.com/cosmos/cosmos-sdk/blob/main/x/slashing/keeper/signing_info.go#L78

Let me know if you have any questions /cc @grarco @brentstone

[brentstone]

Some initial notes to spec out how to do this specifically in Namada. Please comment.

• In finalize_block, expose two functions from the PoS crate: record_liveness_data, which takes the req.votes as input and is called every block, and jail_for_liveness, which is called upon a new epoch.
  • Upon a new epoch, jail_for_liveness should be called before record_liveness_data.
  • QQ: in this scheme, jailing should prob occur at the following epoch, otherwise we cannot communicate the validator set change to CometBFT in time. Is this concerning?
  • QQ: is it preferable to call jail_for_liveness every block too?
• Use a lazy data structure in storage of the form LazyMap<Address, LazyMap<BlockHeight, bool> that records a bool indicating if a validator Address signed the block in some BlockHeight.
  • Use some parameter perhaps in PosParams called max_num_liveness_blocks: u64 (or similar) to remove map elements for which the height < current_height - max_num_liveness_blocks.
  • At the start of a new epoch, clean the data in storage. Remove data for validators that were previously in the consensus set but have now fallen out of it. Persist the data for those that remain in the consensus set. For new validator to the consensus set, the call to record_liveness_data will instantiate their data.
• record_liveness_data(votes)
  • for each validator in votes,
    • insert (height, vote.signed_last_block) into validator_liveness_data
    • get earliest height in the map, if height < current_heigh - max_num_liveness_blocks, remove the key-val
• jail_for_liveness
  • for each validator in validator_liveness_data,
    • count the number of true values. Use another PosParam called liveness_protection_threshold: Dec such that if sum(true) / max_num_liveness_blocks < liveness_protection_threshold, then the validator is jailed and the validator set is appropriately updated.
    • if the validator is no longer in the consensus set for the new epoch, remove its data from validator_liveness_data

Not positive if jailing or deactivating is the proper thing to do, or if it even matters. Also please comment on whether we think it is better to call jail_for_liveness upon a new epoch or every block. The downside of calling it upon a new epoch is that we cannot jail/deactivate misbehaving validators until the following epoch, letting them remain for one more whole epoch if they are in consensus.

[adrianbrink]

jail_for_liveness should be a cheap call so I think we can do it every block.

Validators should be jailed but without being slashed and they can unjail themselves.

[adrianbrink]

The threshold for liveness should be something like missed more than 10% of the last 10,000 blocks. That means that the sliding windows is ~12 hours with 5 second blocks, which means that you can be down for about 1.5 hours.

[cwgoes]

• It would be preferable to call jail_for_liveness every block; this would allow the network to respond more quickly.
• Your proposed measurement method requires iteration, which I think may be too expensive. We can either change the method to "no signatures in last N blocks" (vs "less than k signatures in last N blocks"), which is less precise but easier to implement, or we can implement the bitfield technique described in the Cosmos SDK code, which basically just keeps a running counter (thereby avoiding the need to iterate over all of the blocks and count the number of true values).

[adrianbrink]

bitfield is good.

we can port the code over from the sdk.

[brentstone]

Cool, this sounds good. Chatted with @grarco about what we will do too.

[cwgoes]

Is this really completed already? 😮