Disputes

Accountability for Parachains

Let’s take a step back

• Our goal is to create economic security for Polkadot’s parachains.
• It only takes a few backers to get a parablock onto the relay chain
• We are most interested in slashing parablocks backers that are backed & available

Path of A Parachain Block

Availability

Availability

Backing

Backing

Disputes

• Validators have skin-in-the-game due to PoS
• Most parachain consensus is done by few validators, but disputes escalate to everyone.
• Previously cast statements may be included in a dispute.

Types of Disputes, relative to the chain

Remote

A dispute concerning a parablock not included in the branch of the chain.

​

Local

A dispute concerning a parablock included in the branch of the chain.

Dispute

Local

Remote

Disputes: order-of-events

• Disputes are coordinated off-chain and played on-chain.
• Local disputes resolving against the parablock result in a chain reversion, to remove the bad parablock.
• A dispute appearing on one chain will be replayed onto all other chains, to ensure that the offenders are always slashed.

Goal: Slashing

Implementation Components

Runtime

Node-side

Disputes

Offences

Inherent

Provisioner

Coordinator

Participation

Distribution

Dispute Coordinator

• Tracks all recent (~1-day) statements by validators about candidates.
• Watches for any conflicts between validators.
• Whenever a conflict exists, download and execute the block and sign a statement.

Dispute Distribution

• Flood-style networking for validators to notify the network of any ongoing dispute.
• Any two conflicting messages may form a dispute
• Import new votes into coordinator and distribute all votes from coordinator to other validators.

Dispute Runtime

• Tracks active and resolved disputes from recent history.
• Accepts new disputes via an inherent data source.
• Triggers slashing of validators on the wrong side of a resolved dispute
• Freezes parachains after a dispute resolves against

​

Finalization Rules vs Voting Rules

• We’d like the network to finalize only blocks which contain ‘good’ parachain blocks
• However, we can only control the behavior that honest nodes have
• We will produce a voting rule that creates our desired finalization behavior in the network

Finality voting rule

• First select a block B to vote on via GRANDPA’s typical mechanism
• Find the highest block B’ which is <= B such that all blocks after the last finalized block up to and including B’ have only parachain candidates which are not actively disputed or have lost a dispute.

Fork-choice rule

• Refuse to accept or build upon any branch of the relay chain containing a parablock which has lost a dispute

Disputes in Action

Finalized Chain

Disputed

Disputes in Action

Finalized Chain

Disputed

Disputes in Action

Finalized Chain

Disputed

Disputed

Disputes in Action

Finalized Chain

Disputed

Disputed

Slashing

Questions?