Accountability and fault detection (AFD)
Autonity’s Accountability Fault Detection model – reporting mechanism, temporal constraints, and economics for reporting offences and penalties for Byzantine behavior.
Overview
This section describes the Autonity accountability and fault detection protocol, the role of validators in submitting and verifying accountability event proofs (fault, accusation, innocence), the lifecycle for fault accountability and detection, and slashing.
Autonity implements an accountability and fault detection (AFD) protocol for detecting infractions of consensus rules by validators participating in consensus as consensus committee members. Consensus rules govern committee behavior while participating in block proposal and voting. Failure to adhere to these rules is a rule infraction.
Proven rule infractions are reported as faults and slashing makes faults accountable. Faults are detected by validators and submitted on chain as accountability events providing proof of misbehavior. Proofs are derived from cryptographically signed messages broadcast between committee members during Tendermint consensus rounds as validators propose, prevote, and precommit blocks (see the concept description Consensus round and internal state). The proofs are then submitted on-chain to the Accountability Contract.
It is important to note that AFD runs alongside Autonity’s Tendermint proof of stake consensus implementation and is fully automated: accountability events are generated and processed by protocol; no manual intervention by validator operators is required.
AFD functions by submitting, verifying, and processing accountability event proofs for Rule infractions by epoch. There are two ways for Rule infractions to be created.
Rule infractions can be directly submitted as a fault proof by a reporting validator.
Rule infractions can also be promoted from accusations. In this case, the Rule infraction is reported as an accusation, submitted by a reporting validator against an offending validator. An accusation may be defended by an innocence proof submitted by the offending validator within a proof submission window measured in blocks. If not defended against, the accusation may be promoted to a fault by the protocol once the innocence window has expired.
Slashing penalties are computed by protocol and applied for proven faults at epoch end. The penalty amount is computed based on a base slashing rate and slashing factors including the total number of slashable offences committed in the epoch (collusion) and the individual offending validator’s own slashing history.
Slashing is applied as part of the state finalization function. As the last block of an epoch is finalized, the Autonity contract will: apply accountability for faults to offending validators, slashing self-bonded and delegated stake according to Autonity’s Penalty-Absorbing Stake (PAS) model.
Rewards are paid for reporting a slashable fault at epoch end. The offending_ validator’s_ share of the epoch’s staking rewards is forfeited and paid to the reporting validator treasury account for distribution along with the staking rewards at epoch end.
Accountability prerequisites
To participate in AFD a validator must be a consensus committee member.
Accountability and Fault Detection protocol
AFD roles, core concepts, and the lifecycle of accountability event processing from accusation to slashing.
Roles
As a consensus committee member the validator may play the roles in the table beneath during AFD processing.
| Role | Description |
|---|---|
| reporting | as the validator reporting a (suspected) rule infraction and submitting new fault proof / accusation on-chain |
| offending | as the validator committing a suspected rule infraction and being requested to submit innocence proofs on-chain |
| committee member | as a validator in the consensus committee executing Autonity’s consensus protocol and for AFD handling and processing accountability events, maintaining system state for accountability events, and computing and applying slashing penalties |
The economic impact of the AFD protocol on a validator depends on their role.
| Role | Economic impact |
|---|---|
| offender | loss of stake, validator reputation, staking reward revenue as the offending validator of a slashed fault |
| reporting | gain of the offending validator’s protocol rewards as the reporting validator of a slashed fault |
The Autonity community is also a beneficiary of AFD processing as slashed stake tokens will be used for community funds.
Protocol primitives
Essential primitives of AFD are: accusation, innocence, and fault proofs; slashing and severity; jailing.
Accusations
An accusation is a claim that a consensus committee member has failed to participate correctly in consensus. The protocol only allows a validator to have one pending accusation at a time. New accusations are made by submitting evidence of an accusable rule infraction on-chain as an accountability event of type Accusation.
Accusations do not automatically cause slashing, as an innocence proof window measured in blocks gives the accused offending validator a window to detect an accusation and prove innocence by submitting an innocence proof on-chain.
If the offending validator already has an accusation pending, the accountability protocol determines the offender is not currently accusable. This is because the protocol has to wait to determine if the pending accusation has been defended or, if not, promoted to a fault. Until then, it cannot determine if the offending validator has committed a rule infraction with a higher severity than the new candidate accusation in the epoch or not.
After successful handling and verification of an accusation on-chain, a NewAccusation event is emitted logging the offending validator identifier address, severity of rule infraction, and the event ID.
There are protocol constraints on when an accusation can be made. A reporting validator can only submit an accusation against an offending validator within the constraints described in the table beneath.
| Constraint | Description |
|---|---|
| A fault with a higher severity has not already been reported for the epoch | The offending validator does not already have a fault in the current epoch n with a higher severity than the fault of the new accusation being made. If the accusation is for an earlier epoch, e.g. n-1, then the protocol checks that the offending validator has not already been slashed in that epoch for an offence with a higher severity. Slashing history is checked to determine this. |
| There is not a pending accusation | The offending validator does not already have an accusation for committing a rule infraction in the epoch. If there is a pending accusation, then the accountability protocol has to wait until the innocence proof submission window for the pending accusation expires to determine whether a new accusation can be made or not. This creates a deadline measured in block height before it becomes possible to submit a new accusation. The innocence proof submission window length is set in the slashing protocol configuration. |
| The accusation is being made within a number of blocks after the detected rule infraction | An accusation must be made within an accusation window that is <= 256 blocks after the detected accountability event. This creates a deadline measured in block height after which an accusation cannot be submitted. |
As each block is finalized, AFD will attempt to promote expired accusations (where the innocence proof submission window has elapsed) to proven faults.
Innocence
Accusations do not automatically cause slashing. An offending validator can present a claim of innocence to refute a pending accusation for an accusable rule infraction.
Claims of innocence are made by submitting an innocence claim on-chain as an event of type InnocenceProof. If successful, the proof of innocence cancels the pending accusation.
An innocence claim must be submitted within an innocence proof submission window to be accepted. The window length is measured as a count of blocks set as a parameter in the slashing protocol configuration. The window begins at the block height number at which the accusation was reported and gives the accused validator a window of opportunity to detect if an accusation against it has been made, and if so to defend itself and prove innocence by submitting an innocence claim on-chain. Otherwise, the accusation may be promoted to a fault and become slashable at the end of epoch.
If the innocence claim is successfully verified, then the accusation queue is checked and the corresponding accusation is cancelled. The pending accusation state is cleared and a reporting validator is now able to submit a new accusation against the offending validator.
After successful handling and verification of an innocence claim on-chain, an InnocenceProven event is emitted that logs: offending validator identifier address, and 0 indicating there are no pending accusations against the validator.
Faults
A fault is a proven consensus rule infraction in an epoch. A fault is created directly or by promotion of an accusation.
In the direct submission method a fault proof is submitted on-chain directly by a reporting validator. This method of fault reporting is reserved for rule infractions that rely on unforgeable evidence. It does not offer the possibility of defence.
A pending accusation can be automatically promoted to a fault after expiry of an innocence proof submission window. This method offers the possibility of defence by submission of an innocence proof. If the offending validator has not submitted a successfully verified innocence claim within the window, and a fault with a higher severity for the epoch has not already been proven against the offending validator during that epoch, then the accusation is promoted to a fault.
Unlike accusations where an accusation must be made within a <= 256 block window of the rule infraction, there is no window constraint for direct fault submissions.
A direct fault proof can be reported at any time.
After successful handling and verification of a directly submitted fault on-chain, a NewFaultProof event is emitted logging the offending validator identifier address, severity of rule infraction, and the event ID.
Slashing and severity
The AFD protocol will apply slashing to an offending validator for the fault with the highest severity reported in an epoch. A validator can only be slashed more than once in an epoch in the case where faults committed in different epochs are reported and applied in the same epoch.
In certain cases, a validator can be slashed for committing a fault in an epoch more than once. For example:
- Epoch
n: The offending validator is slashed for a fault committed in epochn. - Epoch
n+1: New faults are reported for the offending validator: (1) one for the current epochn+1; (2) one for epochnwith a higher severity than the fault already slashed in epochn. - Slashing applied in epoch
n+1: The offending validator is slashed twice: (a) once for the fault committed in epochn+1, and (2) once for the fault committed in epochn.
Rule infraction severity has two key influences. Firstly, it will determine if a new fault is created or not. New fault creation is conditional on whether the offending validator already has an existing fault with a severity >= to that of the candidate new fault for the epoch. Secondly, severity will determine the amount of the slashing applied.
The slashing amount is calculated from a number of parameters, including severity. For slashing calculation and parameters see Slashing. For the severity taxonomy see Rule severity.
Jail
Jailing is a protocol action that excludes a validator from consensus committee selection. Jailing may be applied as part of a slashing penalty depending on the severity of the fault being slashed.
Jailing transitions the offending validator from an active to a jailed or jailbound state. Jailing is either temporary or permanent:
On temporary jailing the validator enters a jailed state and is impermanently jailed for a number of blocks, the jail period. The validator’s jail release block number is computed based on its proven fault history as described in Jail period calculation. After expiry of the jail period a validator may get out of jail by re-activating to revert to an active state and resume eligibility for consensus committee selection.
The offending validator will remain in a jailed state even after jail period expiry. The validator operator must manually re-activate by calling the activateValidator() function to get out of jail.
The protocol does not automatically revert validator state from jailed to active at the jail release block number.
On permanent jailing the validator enters a jailbound state and is permanently jailed. It becomes jailbound and cannot get out of jail. Permanent jailing is only applied in the case where a validator is found guilty by the accountability and fault detection protocol of a fault with a 100% stake slashing penalty as a member of the consensus committee.
Accountability event lifecycle
Accountability event lifecycle management comprises: accountability event submission on-chain, event handling on-chain, accusations, innocence, fault promotion, and slashing. Rule infractions are detected by validators and submitted on-chain. As noted under Protocol Primitives above, Faults may be directly submitted as FaultProofs or promoted from Accusations.
Rule infractions can be directly submitted as a fault proof by a reporting validator or promoted from an accusation. In the latter case, they they are promoted when: - reported as an accusation, submitted by a reporting validator against an offending validator - eventually defended by an innocence proof, submitted by the offending validator within a proof submission window measured in blocks - if not defended, promoted to fault by the protocol once the innocence window has expired.
The sequence of lifecycle events for an accountability event is:
- An accountability event is detected by the AFD protocol and submitted on-chain by a reporting validator.
- Event handling takes place. The event is verified and processed based on event type:
FaultProof: If the severity is greater than the severity of a fault in the offending validator’s slashing history for the epoch, the event is recorded. Else, discarded.Accusation: If the severity is greater than the severity of a fault in the offending validator’s slashing history for the epoch, and the validator does not already have a pending accusation, then the event is recorded. Else, it is discarded.InnocenceProof: If the innocence proof matches to a pending accusation against an offending validator, then the event is recorded and the correspondingAccusationis deleted. Else, it is discarded.
- Fault promotion is tried. Each block until epoch end, the protocol attempts to promote
Accusationsto newFaultProofs. Promotion only takes place if the proof innocence window has expired and the severity is greater than the severity of an existing fault in the offending validator’s slashing history for the epoch. Else, it is discarded. - Faults are queued for slashing. Accountability
FaultProofevents are placed on a slashing queue for slashing at the end of epoch. For each offending validator with one or more proven faults, a slashing penalty is applied for theFaultProofwith the highest severity for its fault epoch. - Validators are jailed. Validators may be jailed as part of the slashing penalty for a fault. The validator’s node transitions from
activeto ajailedstate and is barred from consensus committee selection. (The validator will only resume anactivestate whenre-activatedby the validator operator after the jail period expires.)
Slashing
Slashing penalties are computed by the protocol and applied for proven faults at epoch end. The penalty amount is computed based on a base slashing rate and slashing factors including the total number of slashable offences committed in the epoch and the individual offending validator’s own slashing history. For parameters see slashing protocol configuration beneath.
Slashing is applied as part of the state finalization function. As the last block of an epoch is finalized, AFD will apply slashing for proven faults to validator stake, slashing stake per Autonity’s Penalty-Absorbing Stake (PAS) model, and applying validator jailing.
Slashing protocol configuration
Accountability protocol parameters are set by default to:
| Protocol parameter | Description | Value |
|---|---|---|
| innocence proof submission window | the number of blocks within which an accused offending validator can submit a proof of innocence on-chain refuting an accusation |
100 |
| base slashing rate low | the base slashing rate for a fault of Low severity | 1000 (10%) |
| base slashing rate mid | the base slashing rate for a fault of Mid severity | 2000 (20%) |
| collusion factor | a factor that measures the number of validators committing slashable offences in the same epoch. The factor is applied as a multiplicand to the total number of slashable offences committed in the epoch when computing the slashing amount of a penalty | 500 (5%) |
| history factor | a factor that measures the number of proven faults committed by a validator since registration. The factor is applied as a multiplicand to that proven fault count when computing the slashing amount of a penalty | 750 (7.5%) |
| jail factor | the number of epochs applied as a multiplier to the proven fault count of a validator. The factor is applied when computing the jail period of an offending validator | 48 (1 day at 30 mins epochs) |
| slashing rate precision | the division precision used as the denominator when computing the slashing amount of a penalty | 10_000 |
Slashing amount calculation
The economic cost of a stake slashing is calculated by applying a slashing rate to a validator’s bonded stake to compute a slashing amount.
The slashing rate is calculated by the formula base rate + epoch offences count * collusion factor + history * history factor where:
base rate: is determined by the severity of the rule infractionepoch offences count: is the count of proven faults created by all validators in the epoch, which is used as evidence of collusionhistory: is the count of proven faults committed by the offending validator since it first registeredcollusion factorandhistory factor: are used to compute a percentage of individual and total validator offence counts to supplement thebase rateand scale the slashing rate according to the individual validator history and evidence of general validator collusion in the current epoch.
The slashing amount is calculated by the formula (slashing rate * validator bonded stake)/slashing rate precision, applying the computed slashing rate as a multiplier to the validator’s bonded stake amount divided by the slashing protocol configuration slashing rate precision.
The slashing fine is then applied to validator bonded stake according to the protocol’s Penalty-Absorbing Stake (PAS) model: self-bonded stake is slashed before delegated stake. The validator state is updated: (a) the self-bonded and total staked amounts adjusted, (b) the slashing amount is added to the validator’s totalSlashed counter. The slashed NTN stake token is then transferred to the Autonity Protocol global treasury account for community funding.
Jail period calculation
Depending upon fault severity, a slashing penalty may apply temporary or permanent validator jailing.
If temporary, jailing will bar the validator from committee selection for a number of blocks known as a jail period. The jail release block number is computed by the formula current block number + jail factor * history * epoch period where:
current block number: The block number at the time of computation (i.e. the last block of an epoch when slashing is applied).jail factor: A multiplier measured as a number of epochs, defined as a protocol parameter in the slashing protocol configuration.history: The number of faults that the validator has been slashed for since registration. This applies a reputational factor based on the validator’s slashing history over time.epoch period: The period of time for which a consensus committee is elected. This is defined as a number of blocks in the Autonity network’s protocol parameterisation and set in the network’s genesis configuration.
If permanent, the validator becomes jailbound and there i sno jail release block. Permanent jailing is only applied in the case where a validator suffers 100% stake slashing as a member of the consensus committee.
Penalty-Absorbing Stake (PAS)
Slashing penalties for accountability events are applied according to Autonity’s penalty-absorbing stake model.
The offending validator’s own self-bonded stake is slashed before delegated stake when applying slashing penalties for accountability events.
To learn more about PAS, see the section on Penalty-Absorbing Stake (PAS) in Staking.
Rules
Accountability rules
Accountability rules are applied to detect faults in the three Tendermint consensus round phases propose, prevote, and precommit.
The table below lists each of the rules defined in the AFD rule engine, identified by a unique Rule ID.
The ID prefixes P, PV, and C that are used in Rule IDs correspond to Tendermint consensus phases:
P: proposePV: prevoteC: precommit
| Rule ID | Description |
|---|---|
PN - PO |
Propose step related consensus rule infraction. |
PVN - PVO - PVO12 - PVO3 |
Prevote step related consensus rule infraction. |
C - C1 |
Precommit step related consensus rule infraction. |
InvalidProposal |
Proposer has proposed a block that fails blockchain validation. |
InvalidProposer |
Proposer of a block proposal is not the committee’s elected Proposer. |
Equivocation |
Validator has sent conflicting messages during a consensus round: a committee member sending multiple prevotes/precommits for different values, or a proposer has broadcast conflicting block proposals to different committee members. |
InvalidRoundStep |
Consensus round message contains invalid round number or step. |
WrongValidRound |
Consensus round message contains wrong valid round number. |
GarbageMessage |
Consensus round message was signed by sender, but it cannot be decoded. |
Rule severity
Rules are given a severity rating according to the risk that failure to adhere to the rule brings to block chain finality and integrity.
In this release all offences are treated as Mid severity.
Future releases will introduce an offence scale range.
Events
Event handling
Accountability events are submitted on-chain by validator’s submitting proofs of behavior from consensus messaging. See handleEvent() for a description of event handling logic.
Event types
There are three accountability event types in AFD:
| Event type | Description |
|---|---|
Accusation |
an accusation of a committee member validator failing to adhere to, or violating, a consensus rule submitted by another validator committee member |
InnocenceProof |
a proof of innocence from an accusation submitted by the accused committee member, which refutes and cancels the accusation if the proof is valid |
FaultProof |
a misbehavior fault |
See distinction between direct and promoted in Faults above.
Event structure
struct Event:
| Field | Datatype | Description |
|---|---|---|
chunks |
uint8 |
Counter for the number of chunks in an oversize accountability event. (Large events are chunked into smaller segments with ID’s and stored in a map; see handleEvent()). |
chunkId |
uint8 |
Chunk index to construct an oversize accountability event. |
eventType |
EventType |
The accountability event type, one of: FaultProof (proven misbehavior), Accusation (pending accusation), or InnocenceProof (proven innocence). |
rule |
Rule |
The identifier of the accountability Rule defined in the Accountability Fault Detector (AFD) rule engine. Enumerated values are defined for each AFD Rule ID. |
reporter |
address |
The node address of the validator that reported this accountability event. |
offender |
address |
The node address of the validator accused of the accountability event. |
rawProof |
bytes |
The rlp encoded bytes of the accountability proof object. |
block |
uint256 |
The block number in which the accountability event occurred. Assigned during event handling by internal processing of raw proof data. |
epoch |
uint256 |
The epoch identifier in which the accountability event block occurred. Assigned during event handling by internal processing of raw proof data. |
reportingBlock |
uint256 |
The number of the block at which the accountability event was verified. Assigned during event handling by internal processing of raw proof data. |
messageHash |
uint256 |
Hash of the main evidence for the accountability event. Assigned during event handling by internal processing of raw proof data. |
Slashing economics
There are two aspects to the economics of slashing: slashing penalties for offending validators and slashing rewards for reporting validators.
Slashing penalties
The economic loss to validators and their delegators from slashing penalties covers stake token and staking rewards.
| Economic loss | Receiving account | Distribution | Description |
|---|---|---|---|
| Slashing of stake token | Autonity Protocol treasury account |
epoch end | The offending validator’s bonded stake is slashed for the penalty amount. Slashing is applied at epoch end according to the protocol’s Penalty-Absorbing Stake (PAS) model. The amount of stake token slashed varies according to the severity of the fault committed and the slashing factors applied. The slashed NTN stake token are transferred to the Autonity Protocol global treasury account for community funding. |
| Loss of current epoch staking rewards | reporting validator treasury account |
epoch end | The offending validator loses staking rewards earned if a member of the consensus committee in the epoch when the slashing penalty is applied. The forfeited staking rewards are distributed to the reporting validator. |
| Loss of future staking rewards - ‘jailing’ | n/a | n/a | If the slashing penalty applies jailing for the fault, then the validator is temporarily or permanently barred from selection to the consensus committee. The offending validator loses the opportunity to earn future staking rewards as a committee member until it resumes an active state. |
Slashing rewards
Slashing rewards are provided by forfeiture of an offending validator’s staking rewards.
Slashing rewards are distributed for reporting provable faults committed by an offending validator to the reporting validator. Rewards are only distributed to the last reporter of a slashing penalty applied to an offending validator in an epoch. Reward revenue is determined by the offender’s share of the stake active (voting power) in the committee at the time the slashing penalty is applied.
Slashing rewards earned by a reporting validator are conditional on the offending validator being a member of the consensus committee in the epoch when the slashing penalty is applied. If multiple slashing events are committed by the same offending validator during the same epoch, then rewards are only distributed to the last reporter for the last slashing penalty applied to an offending validator in the epoch.
Staking rewards earned by the offending validator for the epoch are distributed to the reporting validator at epoch end.
| Economic gain | Receiving account | Distribution | Description |
|---|---|---|---|
| slashing rewards | treasury account |
epoch end | The staking rewards earned by the offending validator for the epoch are forfeited and become the slashing rewards sent to the reporting validator |
The protocol distributes rewards for reporting provable faults committed by an offending validator to the reporting validator.
If multiple slashing events are committed by the same offending validator during the same epoch, then rewards are only distributed to the last reporter.
If the distribution of rewards to the reporting validator’s treasury account fails, then the slashing rewards are sent to the Autonity Protocol treasury account for community funds.