Omission Fault Detection (OFD)

Autonity’s Omission Fault Detection model – reporting mechanism, temporal constraints, and economics for reporting consensus activity and penalties for failure to participate.

Overview

This section describes the Omission Fault Detection protocol. It covers the role of the block proposer in creating proof of which committee members have participated in consensus voting, the role of validators in validating that activity proof, and the incentives and disincentives applied for proven inactivity during consensus.

Autonity implements an Omission Fault Detection (OFD) protocol for detecting if consensus committee members are actively participating in consensus voting rounds. To ensure the maximum level of network liveness committee members should be online and participating in each consensus voting round. An inactive committee member is a committee member that is failing to do this. To be inactive the validator is either not sending consensus messages when it should (failure to vote) or it is sending consensus messages too late to be included in a consensus round (failure to vote on time). In either scenario the validator is considered to have lost liveness and is deemed inactive by protocol.

Autonity’s Tendermint BFT consensus is coordinated by committee member voting via the broadcasting of consensus messages in the communication layer. It assumes a stable broadcast communication channel and a semi-synchronous network timing model (GST & Delta) for message reception. The Tendermint algorithm assumes that at GST + Delta, all the consensus messages sent at GST should have been received by committee members.

The OFD protocol is based upon the processing of consensus messages and their timing, allowing for \(\Delta\) blocks of latency. Consensus committee members participate in consensus rounds with block proposal, prevote, and precommit stages before a block is committed to system state. (See the concept description Consensus round and internal state).

A committee member is considered online by another node if the latter receives the consensus messages it expects in a timely manner. This information is then used to generate the activity report of the consensus participants.

Note that every committee member node generates an activity report based on its local view of network activity. Local views may differ across committee members depending on the network and individual committee member liveness. For example, node X sent a message which never arrived at node Y due to networking issues.

Inactivity is detected by the use of BLS signatures to prove activity. Validators sign consensus messages using their consensus key. During block proposal, the block proposer for height \(h\) will aggregate the precommit signatures of height \(h - \Delta\) into an \(ActivityProof\), which is included in the header of \(h\). \(\Delta\) is defined as a number of blocks, so each block header contains a historical record of committee activity at block height \(h - \Delta\). For example, the activity proof for block height \(h\) is not computed until block height \(h + \Delta\).

What is BLS signature aggregation?

The BLS signature scheme is based on elliptic curve cryptography and provides the following useful properties:

Allowing signature aggregation, therefore enabling storage consumption reduction.
Efficient verification of aggregates, thus reducing CPU consumption.

Autonity uses the BLS signature scheme to cryptographically verify which consensus committee members posted a precommit vote and therefore are actively participating in consensus. A large committee size is an Autonity design goal for scalability. The BLS property of verification efficiency makes it suited use as a signature aggregation algorithm in consensus computation.

Autonity Go Client uses the BLS12-381 blst C library (https://www.supranational.net/press/introducing-blst).

For a deep-dive into BLS signature aggregation some great resources are the eth2 book section BLS Signatures or the IETF research group Internet-Draft BLS Signatures.

It is important to note that OFD runs alongside Autonity’s Tendermint proof of stake consensus implementation and is fully automated: omission accountability events are generated and processed by protocol; no manual intervention by validator operators is required.

As noted above the block proposer generates and includes a BLS aggregate of precommit signatures of height \(h - \Delta\) into the \(ActivityProof\) included in the header of \(h\). Then, at block finalisation, the Omission Accountability Contract is invoked to inspects the \(ActivityProof\) and determine committee inactivity. Committee members are deemed inactive based upon the current \(ActivityProof\) and their historical performance over a rolling block window defined by configuration parameter \(LookbackWindow\). The \(ActivityProof\) is stored as a part of the blockchain, as it is included in the block header.

Inactivity scores and consequent penalties are computed and applied at epoch end. Penalty severity is proportional to validator’s inactivity, which is measured by the inactivity score. The inactivity score of a validator in an epoch is simply the % of blocks in the epoch in which the validator was deemed inactive by the OFD, aggregated with the previous epochs inactivity score.

Penalty scope covers:

withholding of ATN staking rewards proportionally to the inactivity score of the validator in the epoch.
withholding of Newton inflation rewards proportionally to the inactivity score of the validator in the epoch.
jailing and probation if the validator’s inactivity score in the epoch is greater than a permitted threshold set by the OFD protocol.
stake slashing if the validator breaks the permitted threshold while in probation.

Part of the epoch rewards are allocated to incentivize block proposers to include as many signatures in the \(ActivityProof\) as possible. The block proposer’s reward amount is computed based on the proposer effort that he provided in the epoch. The proposer effort of an \(ActivityProof\) is determined as the voting power of the signatures exceeding the quorum value. ATN rewards are paid to the reporting validator treasury account, while NTN rewards are autobonded.

Omission accountability prerequisites

To participate in OFD a validator must be a consensus committee member.

Omission Fault Detection protocol

OFD roles, core concepts, and the lifecycle of omission accountability processing from detection to applying penalties at epoch end.

Roles

As a consensus committee member the validator may play the roles in the table beneath during OFD processing.

Role	Description
committee member	as a validator in the consensus committee executing Autonity’s consensus protocol. For OFD generating and validating activity proofs, maintaining system state for inactivity scores, and computing and applying slashing penalties
block proposer	as the validator proposing blocks, generating an activity proof and including that in the block header for validation and submission on-chain
offender	as the validator found to be inactive by the OFD and the object of slashing penalties

The economic impact of the OFD protocol on a validator depends on their role.

Role	Economic impact
offender	loss of stake, validator reputation, withholding of ATN staking rewards and NTN inflation rewards, and jailing as the offending validator found inactive during an epoch
block proposer	gain of OFD proposer fee rewards for generating activity proofs with precommit signatures \(> \frac{2}{3}\) quorum voting power

The Autonity community is also a beneficiary of OFD processing. Slashed stake token, withheld proposer fee rewards, and withheld Newton inflation rewards will be used for community funds.

Protocol primitives

Essential primitives of OFD are: activity proof; delta; lookback window; inactivity score and thresholds; jailing.

Activity proof

An activity proof is a BLS signature aggregation of committee member precommit votes submitted for a block during a consensus round. The block proposer includes an activity proof in the block header, which is then validated by the other committee members as part of block validation.

Each block header \(h\) contains a historical record of committee activity at block height \(h - \Delta\). This information is used for activity signalling.

Delta \(\Delta\)

The delta \(\Delta\) is the number of blocks that a block proposer waits for before generating the activity proof for a consensus instance. It allows for the p2p network’s GST + Delta latency assumption for timely consensus gossiping.

If the activity proof is empty past the first \(\Delta\) block of the epoch, then this is an omission fault (offence) and the block proposer is subject to penalty. The \(\Delta\) period is set as a protocol configuration parameter.

The initial delta value is set by default in the OFD protocol configuration at genesis. It can be changed post-genesis by governance setDelta().

Lookback window

The lookback window (\(L_{P}\)) is a rolling window of blocks over which OFD searches to determine activity at a certain block.

A validator is considered active for block \(h-\Delta\) if its precommit signature was included in at least 1 \(ActivityProof\) in the range (\(h - \Delta - L_{P},h-\Delta\)].

The lookback window is extended by 1 for each empty \(ActivityProof\) it includes. I.e. if there are 2 empty \(ActivityProof\) in the lookback window, \(L_{P}' = L_{P} + 2\), with \(L_{P}\) being the default value.

The lookback window default value is set in the OFD protocol configuration at genesis. It can be changed post-genesis by governance setLookbackWindow().

Inactivity score

The average offline percentage of a committee member for an epoch is computed as an inactivity score. The offline percentage is measured as the % of blocks in an epoch that the validator has failed to timely participate in consensus for.

The inactivity scores for the current and past epoch are combined to compute an aggregated inactivity score. Penalties are applied only if a committee member’s aggregated inactivity score breaks the inactivity threshold during an epoch. Penalties are then computed based on the validator’s historical omission fault history. A validator’s history of omission faults is maintained by an offence counter. The counter increments by 1 for each omission fault committed, but is reset to 0 if a validator’s probation period expires without the validator committing an offence while on probation. The validator’s aggregated inactivity score and offence count are used as weighting factors when computing omission penalties.

Probation

To incentivise liveness OFD sets a probation period measured in epochs. The duration of the probation period for a validator is determined by the protocol’s initial probation period configured value multiplied by the individual validator’s offence count squared. Until the validator has committed a first offence its probation period is nil (0) epochs. Once offence count is >0 the validator is in probation and its probation period will begin to number epochs. As soon as an offending validator completes an entire probation period without offences its offence count is reset to 0, taking the validator out of probation.

Thresholds

Thresholds set ceilings which if broken trigger omission penalties. OFD has multiple thresholds:

The inactivity threshold sets a ceiling for a validator’s inactivity score in an epoch, above which it will be determined to be an offending validator at the end of the epoch.
The withholding threshold sets a ceiling for a validator’s inactivity score in an epoch, which if exceeded triggers withholding of staking rewards and Newton inflation rewards.

Inactivity penalties

The OFD protocol will apply penalties to an offending validator for proven omission faults after a threshold has been crossed. Penalties applied to an offending validator are:

on breaking the withholding threshold: withholding of staking rewards and newton inflation rewards for the epoch proportionally to the validator’s inactivity score in the epoch. The lost rewards are transferred to the withheld rewards pool for community funding.
on breaking the inactivity threshold: jailing and withholding of all staking rewards and newton inflation rewards for the epoch. The offending validator is jailed for a number of epochs determined by the protocol’s initial jailing period and the number of repeated inactivity offences committed by the validator. The lost rewards are transferred to the withheld rewards pool for community funding.
on committing an offence while on probation: slashing and jailing. The offending validator is slashed according to the protocol’s initial slashing rate configuration, validator’s offences squared, and the number of other validators committing omission offences in the epoch (collusion degree). If the slashing penalty is 100% of the validator’s stake, then the validator is permanently jailed.

Jail

Jailing for omission accountability is as described in the concept Accountability Fault Detection (AFD), Protocol primitives, Jail with the exception that:

jailing for inactivity may be applied as part of a slashing penalty if the offending validator commits an offence while on probation.
jailing transitions the offending validator from an active to a jailedForInactivity or jailboundForInactivity state. Jailing is either temporary or permanent.

On temporary jailing the validator enters a jailedForInactivity 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.

Note

The offending validator will remain in a jailedForInactivity 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 jailedForInactivity to active at the jail release block number.

On permanent jailing the validator enters a jailboundForInactivity state and is permanently jailed. The validator becomes jailbound and cannot get out of jail. Permanent jailing is only applied in the case where a validator on probation commits an offence that results in 100% of the validator’s stake being slashed.

How AFD and OFD differ in distributing staking rewards lost through validator jailing

Validator jailing has a penalty of losing all staking rewards earned by the validator for its share of voting power in the epoch. I.e. there is no validator commission paid on the rewards earned and no distribution of staking rewards for stake delegated to that validator for that epoch.

Both AFD and OFD have the concept of jailing, the distinction being OFD jails for inactivity and AFD jails for accountability faults.

If a validator has been jailed by AFD then all staking rewards earned by the validator in the epoch are forfeited and distributed to the reporting validator as described in Accountability fault Detection (AFD), Slashing penalties.

If a validator has been jailed by OFD then all staking rewards earned by the validator in the epoch are withheld and distributed to the withheld rewards pool account for community funding as described in Slashing penalties on this page.

Protocol configuration

Slashing penalties for an offending validator are computed by the protocol based on the offending validator’s aggregated inactivity score, its offence history, if it is on probation, and the total number of offences committed in the current epoch by other committee members, i.e. a collusion degree. For the omission fault parameters see slashing protocol configuration beneath.

Applied slashing penalties cover withholding of ATN staking rewards and NTN Newton inflation rewards proportional to the % of offline blocks in the epoch, probation, jailing, and slashing a percentage of stake. Slashing and probation scale up quadratically by the number of repeated offences.

Penalties are applied as part of the state finalization function. As the last block of an epoch is finalized, OFD will apply penalties for proven omission faults, thus withholding ATN staking rewards and NTN inflation rewards, jailing validators and slashing validator stake per Autonity’s Penalty-Absorbing Stake (PAS) model if detected committing an omission fault while on probation.

Protocol parameters

OFD protocol parameters are set by default to:

Protocol parameter	Description	Value
inactivity threshold	the threshold to determine if a committee member is an offending validator at the end of the epoch	`1000` (10%)
lookback window	the number of blocks over which the protocol will look for activity	`40` (40 blocks)
past performance weight	a factor that determines how much weight is given to past performance of the validator	`1000` (10%)
initial jailing period	the initial number of block(s) that an offending validator will be jailed for	`10_000` (10000 blocks)
initial probation period	the initial number of epoch(s) that an offending validator will be set under probation for	`24` (24 epochs)
initial slashing rate	the initial slashing rate used together with the offence count and collusion degree when computing the slashing amount of a penalty	`25` (0.25%)
delta	the number of blocks to wait before generating an activity proof for a consensus instance. E.g. activity proof of block `x` is for block `x - delta`	`5` (5 blocks)
slashing rate scale factor	the division precision used as the denominator when computing the slashing amount of a penalty	`10_000` (0.01%)

A note on the initial value settings

Initial values for jailing, probation, and slashing are used to determine the scaling up a validator’s jailing period, probation period, and slashing percentage by the number of repeated offences quadratically.

Slashing will also scale up linearly with the collusion degree, thus helping to safeguard the liveness of the network.

Inactivity score calculation

Validator inactivity is calculated as an aggregated inactivity score, which is computed based upon the validator’s participation in consensus during the current and preceding epochs.

If the score is above the OFD thresholds, then penalties are applied accordingly.

The inactivity score of a validator for one epoch is computed as:

\[in_{i}(e) = \frac{Nin_{i}(e)}{el(e)}\]

where

\(in_{i}(e)\) is the inactivity score for validator \(i\) at epoch \(e\)
\(Nin_{i}(e)\) is the number of block(s) during which validator \(i\) was deemed as inactive in epoch \(e\)
\(el(e)\) is the epoch length (in blocks) of epoch \(e\)

The aggregated epoched inactivity score is a weighted sum of the validator’s current epoch performance and the past epoch’s performance:

\[Ain_{i}(e) = in_{i}(e) * (1-k) + Ain_{i}(e-1) * k\]

where

\(Ain_{i}(e)\) is the aggregated inactivity score for validator \(i\) at epoch \(e\)
\(in_{i}(e)\) is the inactivity score for validator \(i\) at epoch \(e\)
\(k\) is the governable protocol parameter past performance weight which determines how much weight is given to the validator’s past performance. It has to respect the relation \(0 =< k < 1\).

Rewards withholding calculation

The epoch rewards withheld amount of a validator for the epoch is computed as:

\[ewh_{i}(e) = EpochReward_{i}(e) * Ain_{i}(e)\]

where

\(ewh_{i}(e)\) means the withheld reward of validator \(i\) at epoch \(e\).
\(EpochReward_{i}(e)\) means the original PoS distributed reward of validator \(i\) at epoch \(e\) without accounting the omission fault.
\(Ain_{i}(e)\) is the aggregated inactivity score for validator \(i\) at epoch \(e\)

Applied to the reward withholding calculation for both ATN and NTN rewards

This calculation is used to compute the withholding of rewards for both ATN staking rewards and NTN Newton inflation rewards.

At code-level the ATN and NTN rewards for a validator are calculated proportionally to the validator’s voting power share of the consensus committee’s total voting power.

Jailing period calculation

The jailing period for a validator is calculated as:

\[JailingPeriod_{i} = InitialJailingPeriod * {offence_{i}}^2\]

where

\(JailingPeriod_{i}\) is the number of epochs validator \(i\) will be jailed for
\(InitialJailingPeriod\) is a governable protocol parameter
\(offence_{i}\) is the number of repeated offences committed by validator \(i\).

The \(offence_{i}\) counter is reset as soon as an entire \(ProbationPeriod\) is completed without offence.

Probation period calculation

The probation period for a validator is calculated as:

\[ProbationPeriod_{i} = InitialProbationPeriod * {offence_{i}}^2\]

where

\(ProbationPeriod_{i}\) is the number of epochs validator \(i\) will be set under probation for
\(InitialProbationPeriod\) is a governable protocol parameter
\(offence_{i}\) is the number of repeated offences committed by validator \(i\).

The \(offence_{i}\) counter is reset as soon as an entire \(ProbationPeriod\) is completed without offence.

Slashing amount calculation

The slashing amount is calculated by the formula:

\[ep_{i} = BondedStake_{i} * InitialSlashingRatio * {offence_{i}}^2 * {CollusionDegree_{e}} \]

where

\(ep_{i}\) means the epoch omission fault slashing penalty of validator \(i\).
\(BondedStake_{i}\) means the bonded stake of validator \(i\).
\(InitialSlashingRatio\) is the system parameter of the initial slashing percentage which is configurable.
\(offence_{i}\) means the number of offences (jailed times) that a validator \(i\) committed in the history. This counter gets reset as soon as an entire \(ProbationPeriod\) is completed without offences.
\(CollusionDegree_{e}\) means the number of omission faulty nodes that are addressed on current epoch \(e\), it indicate that the more omission faulty node there are, the heavier slashing will be applied. Only validators which get jailed due to omission are counted for collusion.

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.

Proposer reward calculation

Block proposer rewards are calculated by the formula:

\[epr_{i} = er_{e} * aprr_{e} * {cs_{e} \over MCS} * {eec_{i} \over \displaystyle\sum_{k=1}^{cs_{e}} eec_k }\]

where:

\(epr_{i}\) means the epoch proposer reward for validator \(i\).
\(er_{e}\) means the accumulated fee reward of the epoch \(e\).
\(aprr_{e}\) means the activity proof reward ratio of the epoch \(e\), it is configurable and it describe a fraction of the epoch fee reward.
\(cs_{e}\) means the committee size of epoch \(e\).
\(MCS\) means the maximum committee size of the protocol.
\(eec_{i}\) means the epoch effort count, it counts the efforts/signatures for more than quorum of the voting power.

Info

Proposer rewards are an incentive for the proposer to include as many signatures as possible in an activity proof.

A percentage of both the ATN staking rewards coming from transaction fees and NTN rewards coming from the Newton inflation mechanism are allocated for proposer incentivisation.

Only signatures that contribute further than the \(\frac{2}{3}\) voting power are incentivized. In other words:

if the proposer provided an empty \(ActivityProof\) and we are not at the first \(\Delta\) block of the epoch, the proposer is considered as faulty and does not receive any incentive.
if the proposer includes signatures for exactly \(\frac{2}{3}\) of the voting power, the \(ActivityProof\) is valid BUT the proposer does not receive any incentive.
if the proposer includes signatures for more than \(\frac{2}{3}\) of the voting power, then he starts to get incentives.

OFD economics

There are two aspects to Omission Fault Detection economics: inactivity penalties for offending validators and proposer rewards for block proposers.

Inactivity penalties

The economic loss to consensus committee members and their delegators from inactivity penalties covers loss of staking and Newton inflation rewards, block proposer rewards, jailing, and stake slashing.

Economic loss	Receiving account	Distribution	Description
Loss of current epoch staking rewards	`withheldRewardsPool` account	epoch end	The offending validator loses a % of staking rewards proportional to its inactivity score in the epoch the omission penalty is applied. The forfeited rewards are transferred to the withheld rewards pool account for community funding. Amount is determined by the Rewards withholding calculation.
Loss of current epoch Newton inflation rewards	`withheldRewardsPool` account	epoch end	The offending validator loses a % of Newton inflation rewards proportional to its inactivity score in the epoch the omission penalty is applied. The forfeited rewards are transferred to the withheld rewards pool account for community funding. Amount is determined by the Rewards withholding calculation.
Loss of current epoch block proposer rewards	n/a	n/a	The block proposer does not earn proposer rewards for a block if it includes an activity proof that does not contain signatures for \(> \frac{2}{3}\) of block quorum voting power. See Proposer reward calculation formula.
Loss of future staking rewards - ‘jailing’	n/a	n/a	If the inactivity 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. Jail period determined by the Jailing period calculation.
Slashing of stake token	Autonity Protocol `treasury` account	epoch end	The offending validator’s bonded stake is slashed for the omission penalty amount. Slashing is applied at epoch end according to the protocol’s Penalty-Absorbing Stake (PAS) model. Amount determined by the Slashing amount calculation.

Rewards

Economic rewards are provided to block proposers and through the withholding of staking and Newton inflation rewards to the community.

Proposer rewards are distributed as incentive for block proposers that have submitted activity proofs where the number of signatures is greater than the \(\frac{2}{3}\) quorum of voting power. See Proposer reward calculation for the formula.

Withheld rewards distributed to the community are conditional on the extent to which the offending validator was inactive during the epoch, if it was jailed, and the amount of stake delegated to it.

Economic gain	Receiving account	Distribution	Description
proposer rewards	`treasury` account	epoch end	The OFD proposer rewards earned by the validator for the epoch. Amount determined by the Proposer reward calculation formula.
withheld rewards	`withheldRewardsPool` account	epoch end	ATN staking rewards and NTN inflation rewards earned by the offending validator for the epoch are forfeited and are sent to the withheld pool account for community funding. Amount determined by the validator’s share of the committee’s voting power, the number of transactions processed during the epoch, the emission of the Newton inflation mechanism.