From 2008840d2bfa125adcdbe07e53f1abbca4e60a03 Mon Sep 17 00:00:00 2001 From: Philip Offtermatt Date: Thu, 18 Jul 2024 10:58:10 +0200 Subject: [PATCH] Start writing some testing scenarios --- .../adr-017-allowing-inactive-validators.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/docs/docs/adrs/adr-017-allowing-inactive-validators.md b/docs/docs/adrs/adr-017-allowing-inactive-validators.md index 52d8d9328a..42eec9978b 100644 --- a/docs/docs/adrs/adr-017-allowing-inactive-validators.md +++ b/docs/docs/adrs/adr-017-allowing-inactive-validators.md @@ -75,6 +75,46 @@ disables the main feature described in this ADR. Additional risk mitigations are to increase the active set size slowly, and to monitor the effects on the network closely. For the first iteration, we propose to increase the active set size to 200 validators (while keeping the consensus validators to 180), thus letting the 20 validators with the most stake outside of the active set validate on consumer chains. +## Testing Scenarios + +In the following, +- bonded validators refers to all validators that have bonded stake, +- active validators refers to the validators that take part in consensus, +- inactive validators refers to bonded validators that are not active validators. + +### Scenario 1: Inactive validators should not be considered by governance + +Inactive validators should not be considered for the purpose of governance. +In particular, the governance module should not allow inactive validators to vote on proposals, +and the quorum depends only on the stake bonded by active validators. + +This can be tested by creating a governance proposal, then trying to vote on it with inactive validators. +The proposal should not pass. +Afterwards, we create another proposal and vote on it with active validators, too. +Then, the proposal should pass. + +### Scenario 2: Inactive validators should not get rewards from the provider chain + +Inactive validators should not get rewards from the provider chain. + +This can be tested by starting a provider chain with inactive validators and checking the rewards of inactive validators. + +### Scenario 3: Inactive validators should get rewards from consumer chains + +An inactive validator that is validating on a consumer chain should receive rewards in the consumer chain token. + +### Scenario 4: Inactive validators should not get slashed/jailed for downtime on the provider chain + +This can be tested by having an inactive validator go offline on the provider chain for long enough to accrue downtime. +The validator should be neither slashed nor jailed for downtime. + +### Scenario 5: Inactive validators *should* get jailed for downtime on the provider chain + +This can be tested by having an inactive validator go offline on a consumer chain for long enough to accrue downtime. +The consumer chain should send a SlashPacket to the provider chain, which should jail the validator. + +* **Mint**: + ## Consequences ### Positive