Skip to content

staking(tests): add validator tombstoning scenarios #4149

@erwanor

Description

@erwanor

This is perhaps best to split into multiple tickets, but at a high-level we want to:

  • Enshrine in tests that Tombstoned is a terminal state
  • Check that exchange rates and validator rewards are always penalized
  • Check that new delegations are impossible
  • Check that that undelegation claims are instantaneous
  • Check that claims are always factoring in the penalty even if tombstoning happened after undelegating

For context, the application receives misbehavior evidence from comet in the BeginBlock packet (and starting in 0.38, FinalizeBlock either way we want to process evidence before tx execution), the application then forwards it to the staking component in ValidatorManager::process_evidence which then records the appropriate penalty and trigger a state transition.

/// Evidence of validator misbehavior.
///
/// [ABCI documentation](https://docs.tendermint.com/master/spec/abci/abci.html#evidence)
#[derive(Clone, PartialEq, Eq, Debug)]
pub struct Misbehavior {
    /// The kind of evidence.
    ///
    /// Note: this field is called `type` in the protobuf, but we call it `kind`
    /// to avoid the Rust keyword.
    pub kind: MisbehaviorKind,
    /// The offending validator.
    pub validator: Validator,
    /// The height when the offense occurred.
    pub height: block::Height,
    /// The corresponding time when the offense occurred.
    pub time: Time,
    /// Total voting power of the validator set at `height`.
    ///
    /// This is included in case the ABCI application does not store historical
    /// validators, cf.
    /// [#4581](https://github.com/tendermint/tendermint/issues/4581)
    pub total_voting_power: vote::Power,
}

Ostensibly, there is very little validation done by the application because we assume that CometBFT has done it for us. We can't however assume that the evidence gets only delivered once or make any assumptions that are downstream of validator behavior (since it is byzantine!).

This is good news, because this means that to test this part of the staking logic we just need to:

  • have a method that creates a stub Misbehavior datum that specifies some cometbft address (that's the only data we need to populate!)
  • have a hook that inject Misbehavior into a BeginBlock packet

And then we "just" need to inspect the staking state to assert the various invariants that we are looking for.

Originally posted by @erwanor in #4049 (comment)

Metadata

Metadata

Assignees

Labels

A-mock-consensusArea: Relates to the mock consensus engineA-stakingArea: Design and implementation of staking and delegationA-testingArea: Relates to testing of Penumbra

Type

No type

Projects

Status

Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions