Harmony’s whitepaper states the following:
- If a leader fails to finish the consensus process and triggered the view change process, P_vote staked tokens will be slashed
- If validators are proven to sign a dishonest block, all of their stake under the same shard will be slashed
- Any validator can submit a transaction to prove the misbehavior of another validator and if verified, the slashed token will be rewarded to the prover
Different Protocol’s Slashing Mechanism
Ethereum
- A validator acts as a “whistleblower” — a validator that monitors for slashable events
- Whistleblower must create and disseminate a specific message outlining the infraction, which a propose then adds to a block
- To compensate the block proposers for slashing the bad validator, they are rewarded with the offender’s effective balance divided by 512 (e.g. roughly 0.06 ETH if the offender’s balance is 32 ETH)
- Whistleblower themselves are not rewarded; the reward is purposefully small as these acts are meant to be a selfless gesture, not a means to profit
The above is pre-Bellatrix; the below contains information from Bellatrix upgrade (https://eth2book.info/bellatrix/part2/incentives/slashing/)
- Slashing triggered by the evidence of the offense being included in a beacon chain block
- Initial Penalty
- Offender immediately has 1/32 of its effective balance deducted from its actual balance (maximum of 1 ETH due to the cap on effective balance)
- Introduced to make it costly for validators to self-slash for any reason
- Validator is queued for an exit with withdrawability epoch set to around 36 days (~8192 epochs)
- Correlation Penalty
- Occurs at the halfway point of its withdrawability period (18 days after being slashed)
- Based on the total amount of stake slashed during the 18 days before and after the validator was slashed
- The idea is to scale the punishment according to the events that happened during the time
- Calculated as follows:
- Compute the sum of the effective balances of all validators slashed in the 36 days span
- Multiply the sum by
PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIXbut cap the result at total_balance, the total active balance of all
Harmony’s Implementation
When a new node is started through New(...) (node.go) function, the following goroutine is started:
If a doubleSign record is received in the SlashChan, it is processed by the node (TODO: When and where is the doubleSign message formed in the first place?). Depending on whether the node is a running in beacon chain or not, the record will either be added to the pending slashing candidates or broadcasted respectively.
For the nodes in non-beacon shards, BroadcastSlash will be called, which is implemented as follows:
The slash message gets constructed with the witness as a part of the message. This message then gets sent out to the groups within the beacon chain (TODO: Why only the beacon chain? Is slashing processed only in the beacon chain?). (TODO: Why is only the witness part of the message?
For the nodes in beacon shards, AddPendingSlashingCandidates is called with the received slashing message. In the current state, since slashing has not been enabled, the implementation is as follows:
However, the actual implementation that will replace it is as follows:
Applying slashes are included in the ValidateNewBlock method, which is also blocked out by the stub method. However, the actual implementation is as follows (Question: Then how is the block validated currently? ALSO, when is a method directed to the stub vs actual implementation).
TODO: Now where is the previously constructed message received? In the channel above?