You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should define slashing behavior, to make sure we are not being too lax or harsh, and are encouraging high validator uptime while accepting that occasional mistakes happen.
Context
In Cosmos blockchains there are mechanisms to incentivize validator operators to run a good service. Validators should take part in the consensus algorithm, rather than idle, and they should not try to trick network participants by signing more than one block for a given consensus round. The notions downtime and double signing (also known as equivocation) capture these two wishes.
Downtime is automatically detected by on-chain code, while double signs are observed by the network and can be submitted in evidence packets to be processed on-chain. When either is detected, the validator in question is punished by slashing.
A slash event burns some tokens from the misbehaving validator and optionally jails them: prevents them from taking part in consensus (and thus receiving rewards) for a period. In the case of double signing, the validator is additionally tombstoned. A tombstoned validator is bricked; all its delegators have to undelegate from it to get their tokens back, and the validator can never take part in consensus again.
Interchain Security expands the concepts because the same validators, backed by the same stake, are active across many chains. Downtime messages or evidence from consumer chains who are inheriting security from the staked tokens, are submitted to the provider chain, where the staked tokens are stored. Thus the validators lose their tokens on the provider chain if they misbehave, and any impact from jailing or tombstoning feeds back to the consumer chain as per the communication protocol.
Detailed problem
We should define rules for slashing exactly. For example, what should happen when double sign evidence arrives on the provider chain? Presumably the validator should be slashed and tombstoned. Should further slashing be possible after this? (Consider that there are multiple consumer chains who can submit evidence or downtime messages).
The text was updated successfully, but these errors were encountered:
Problem
We should define slashing behavior, to make sure we are not being too lax or harsh, and are encouraging high validator uptime while accepting that occasional mistakes happen.
Context
In Cosmos blockchains there are mechanisms to incentivize validator operators to run a good service. Validators should take part in the consensus algorithm, rather than idle, and they should not try to trick network participants by signing more than one block for a given consensus round. The notions downtime and double signing (also known as equivocation) capture these two wishes.
Downtime is automatically detected by on-chain code, while double signs are observed by the network and can be submitted in evidence packets to be processed on-chain. When either is detected, the validator in question is punished by slashing.
A slash event burns some tokens from the misbehaving validator and optionally jails them: prevents them from taking part in consensus (and thus receiving rewards) for a period. In the case of double signing, the validator is additionally tombstoned. A tombstoned validator is bricked; all its delegators have to undelegate from it to get their tokens back, and the validator can never take part in consensus again.
Interchain Security expands the concepts because the same validators, backed by the same stake, are active across many chains. Downtime messages or evidence from consumer chains who are inheriting security from the staked tokens, are submitted to the provider chain, where the staked tokens are stored. Thus the validators lose their tokens on the provider chain if they misbehave, and any impact from jailing or tombstoning feeds back to the consumer chain as per the communication protocol.
Detailed problem
We should define rules for slashing exactly. For example, what should happen when double sign evidence arrives on the provider chain? Presumably the validator should be slashed and tombstoned. Should further slashing be possible after this? (Consider that there are multiple consumer chains who can submit evidence or downtime messages).
The text was updated successfully, but these errors were encountered: