Disputes Pallet
After a backed candidate is made available, it is included and proceeds into an acceptance period during which validators are randomly selected to do (secondary) approval checks of the parablock. Any reports disputing the validity of the candidate will cause escalation, where even more validators are requested to check the block, and so on, until either the parablock is determined to be invalid or valid. Those on the wrong side of the dispute are slashed and, if the parablock is deemed invalid, the relay chain is rolled back to a point before that block was included.
However, this isn't the end of the story. We are working in a forkful blockchain environment, which carries three important considerations:
- For security, validators that misbehave shouldn't only be slashed on one fork, but on all possible forks. Validators that misbehave shouldn't be able to create a new fork of the chain when caught and get away with their misbehavior.
- It is possible (and likely) that the parablock being contested has not appeared on all forks.
- If a block author believes that there is a disputed parablock on a specific fork that will resolve to a reversion of the fork, that block author has more incentive to build on a different fork which does not include that parablock.
This means that in all likelihood, there is the possibility of disputes that are started on one fork of the relay chain, and as soon as the dispute resolution process starts to indicate that the parablock is indeed invalid, that fork of the relay chain will be abandoned and the dispute will never be fully resolved on that chain.
Even if this doesn't happen, there is the possibility that there are two disputes underway, and one resolves leading to a reversion of the chain before the other has concluded. In this case we want to both transplant the concluded dispute onto other forks of the chain as well as the unconcluded dispute.
We account for these requirements by having the disputes module handle two kinds of disputes.
- Local disputes: those contesting the validity of the current fork by disputing a parablock included within it.
- Remote disputes: a dispute that has partially or fully resolved on another fork which is transplanted to the local fork for completion and eventual slashing.
When a local dispute concludes negatively, the chain needs to be abandoned and reverted back to a block where the state does not contain the bad parablock. We expect that due to the Approval Checking Protocol, the current executing block should not be finalized. So we do two things when a local dispute concludes negatively:
- Freeze the state of parachains so nothing further is backed or included.
- Issue a digest in the header of the block that signals to nodes that this branch of the chain is to be abandoned.
If, as is expected, the chain is unfinalized, the freeze will have no effect as no honest validator will attempt to build on the frozen chain. However, if the approval checking protocol has failed and the bad parablock is finalized, the freeze serves to put the chain into a governance-only mode.
The storage of this module is designed around tracking DisputeState
s, updating them with votes, and tracking blocks included by this branch of the relay chain. It also contains a Frozen
parameter designed to freeze the state of all parachains.
Storage
Storage Layout:
#![allow(unused)] fn main() { LastPrunedSession: Option<SessionIndex>, // All ongoing or concluded disputes for the last several sessions. Disputes: double_map (SessionIndex, CandidateHash) -> Option<DisputeState>, // All included blocks on the chain, as well as the block number in this chain that // should be reverted back to if the candidate is disputed and determined to be invalid. Included: double_map (SessionIndex, CandidateHash) -> Option<BlockNumber>, // Whether the chain is frozen or not. Starts as `None`. When this is `Some`, // the chain will not accept any new parachain blocks for backing or inclusion, // and its value indicates the last valid block number in the chain. // It can only be set back to `None` by governance intervention. Frozen: Option<BlockNumber>, }
byzantine_threshold
refers to the maximum numberf
of validators which may be byzantine. The total number of validators isn = 3f + e
wheree in { 1, 2, 3 }
.
Session Change
- If the current session is not greater than
config.dispute_period + 1
, nothing to do here. - Set
pruning_target = current_session - config.dispute_period - 1
. We add the extra1
because we want to keep things forconfig.dispute_period
full sessions. The stuff at the end of the most recent session has been around for a little over 0 sessions, not a little over 1. - If
LastPrunedSession
isNone
, then setLastPrunedSession
toSome(pruning_target)
and return. - Otherwise, clear out all disputes and included candidates entries in the range
last_pruned..=pruning_target
and setLastPrunedSession
toSome(pruning_target)
.
Block Initialization
This is currently a no op
.
Routines
-
filter_multi_dispute_data(MultiDisputeStatementSet) -> MultiDisputeStatementSet
:- Takes a
MultiDisputeStatementSet
and filters it down to aMultiDisputeStatementSet
that satisfies all the criteria ofprovide_multi_dispute_data
. That is, eliminating ancient votes, duplicates and unconfirmed disputes. This can be used by block authors to create the final submission in a block which is guaranteed to pass theprovide_multi_dispute_data
checks.
- Takes a
-
provide_multi_dispute_data(MultiDisputeStatementSet) -> Vec<(SessionIndex, Hash)>
:- Pass on each dispute statement set to
provide_dispute_data
, propagating failure. - Return a list of all candidates who just had disputes initiated.
- Pass on each dispute statement set to
-
provide_dispute_data(DisputeStatementSet) -> bool
: Provide data to an ongoing dispute or initiate a dispute.- All statements must be issued under the correct session for the correct candidate.
SessionInfo
is used to check statement signatures and this function should fail if any signatures are invalid.- If there is no dispute under
Disputes
, create a newDisputeState
with blank bitfields. - If
concluded_at
isSome
, and isconcluded_at + config.post_conclusion_acceptance_period < now
, return false. - Import all statements into the dispute. This should fail if any statements are duplicate or if the corresponding bit for the corresponding validator is set in the dispute already.
- If
concluded_at
isNone
, reward all statements. - If
concluded_at
isSome
, reward all statements slightly less. - If either side now has supermajority and did not previously, slash the other side. This may be both sides, and we support this possibility in code, but note that this requires validators to participate on both sides which has negative expected value. Set
concluded_at
toSome(now)
if it wasNone
. - If just concluded against the candidate and the
Included
map contains(session, candidate)
: invokerevert_and_freeze
with the stored block number. - Return true if just initiated, false otherwise.
-
disputes() -> Vec<(SessionIndex, CandidateHash, DisputeState)>
: Get a list of all disputes and info about dispute state.- Iterate over all disputes in
Disputes
and collect into a vector.
- Iterate over all disputes in
-
note_included(SessionIndex, CandidateHash, included_in: BlockNumber)
:- Add
(SessionIndex, CandidateHash)
to theIncluded
map withincluded_in - 1
as the value. - If there is a dispute under
(SessionIndex, CandidateHash)
that has concluded against the candidate, invokerevert_and_freeze
with the stored block number.
- Add
-
concluded_invalid(SessionIndex, CandidateHash) -> bool
: Returns whether a candidate has already concluded a dispute in the negative. -
is_frozen()
: Load the value ofFrozen
from storage. Return true ifSome
and false ifNone
. -
last_valid_block()
: Load the value ofFrozen
from storage and return. None indicates that all blocks in the chain are potentially valid. -
revert_and_freeze(BlockNumber)
:- If
is_frozen()
return. - Set
Frozen
toSome(BlockNumber)
to indicate a rollback to the block number. - Issue a
Revert(BlockNumber + 1)
log to indicate a rollback of the block's child in the header chain, which is the same as a rollback to the block number.
- If
Disputes filtering
All disputes delivered to the runtime by the client are filtered before the actual import. In this context actual import means persisted in the runtime storage. The filtering has got two purposes:
- Limit the amount of data saved onchain.
- Prevent persisting malicious dispute data onchain.
Implementation note: Filtering is performed in function filter_dispute_data
from Disputes
pallet.
The filtering is performed on the whole statement set which is about to be imported onchain. The following filters are applied:
- Remove ancient disputes - if a dispute is concluded before the block number indicated in
OLDEST_ACCEPTED
parameter it is removed from the set.OLDEST_ACCEPTED
is a runtime configuration option. Implementation note:dispute_post_conclusion_acceptance_period
fromHostConfiguration
is used in the current Polkadot/Kusama implementation. - Remove votes from unknown validators. If there is a vote from a validator which wasn't an authority in the session where the dispute was raised - they are removed. Please note that this step removes only single votes instead of removing the whole dispute.
- Remove one sided disputes - if a dispute doesn't contain two opposing votes it is not imported onchain. This serves as a measure not to import one sided disputes. A dispute is raised only if there are two opposing votes so if the client is not sending them the dispute is a potential spam.
- Remove unconfirmed disputes - if a dispute contains less votes than the byzantine threshold it is removed. This is also a spam precaution. A legitimate client will send only confirmed disputes to the runtime.
Rewards and slashing
After the disputes are filtered the validators participating in the disputes are rewarded and more importantly the offenders are slashed. Generally there can be two types of punishments:
- "against valid" - the offender claimed that a valid candidate is invalid.
- "for invalid" - the offender claimed that an invalid candidate is valid.
A dispute might be inconclusive. This means that it has timed out without being confirmed. A confirmed dispute is one containing votes more than the byzantine threshold (1/3 of the active validators). Validators participating in inconclusive disputes are not slashed. Thanks to the applied filtering (described in the previous section) one can be confident that there are no spam disputes in the runtime. So if a validator is not voting it is due to another reason (e.g. being under DoS attack). There is no reason to punish such validators with a slash.
Implementation note: Slashing is performed in process_checked_dispute_data
from Disputes
pallet.