Hedera Technical Insights: Why is there no Slashing in Hedera's Proof of Stake?
Jul 07, 2020
by Paul Madsen
Technical Lead for Hedera Hashgraph


In Proof of Stake (PoS) systems, 'slashing' refers to the possibility of a node determined to be breaking the rules of the protocol being punished by the loss of some or all of the stake (coins) they had put forward. To make the risk of slashing real, nodes must typically bond their stake (that is, lock it up) for some period of time. It is the bonded coins that are at risk if the node breaks the rules. Depending on the severity of the transgression, all or some of those bonded coins could be either burned or redistributed to other participants. When bonded, the coins are generally unavailable for other purposes so slashing implies both risk of loss and reduced liquidity.

While Hedera Hashgraph is a PoS system, there is no slashing nor associated bonding, and so the nodes do not confront the associated loss of liquidity. Network participants do nominate a particular account as being ‘staked’ (or proxy staked), logically asserting to the network that they wish the hbars within to be accounted for in consensus calculations (and payments), but the hbars are not locked up - they can be spent at any time.

Nor do the nodes confront the risk of those staked hbars being taken from them, that is, slashed.

Why do some PoS systems impose slashing, while others do not? How can we guarantee the security of Hedera Hashgraph without slashing, given that most (but not all) other PoS platforms appear to require it?

Fundamentally, Hedera Hashgraph makes certain guarantees with respect to the safety and liveness of the network and those guarantees are the strongest possible any distributed ledger technology (DLT) can make; slashing would not make those guarantees any stronger. Consequently, we do not require the possibility of slashing (with one exception discussed below) and its associated negatives.

What is Slashing?

The term ‘slashing’ comes from an early PoS system called Slasher. Vitalik Buterin used the term in a post from 2017 called ‘Minimal Slashing Conditions’. The post was a discussion of the proposed transition of Ethereum from Proof of Work (PoW) to PoS – specifically an issue with Proof of Stake called ‘Nothing at Stake’.

Unlike in PoW, where there is an actual physical cost for a miner building on competing forks, in PoS based blockchains, where stake weights the chances of a validator being allowed to propose the next block, a validator could choose to work on two competing forks without significant cost. Unlike a PoW miner, the PoS validator has nothing at stake; that is, ‘no skin the game’.

Nothing at Stake (and the need for slashing to prevent it) stems from a validator being able to choose whether to build on the longest chain, as the rules require, or ‘play two hands at once’ in hopes of profit. It is that discretion, inherent in blockchains, to follow the longest chain rule or not, which validators have, that argues for slashing – a validator can work on multiple forks and so must be discouraged from doing so via the risk of slashing.

The proposed slashing model for Ethereum 2.0 has different amounts of a validator’s 32 bonded ETH being slashed, the amount depending on the nature of the transgression and whether it appears to be coordinated with others. For instance, if a validator signs an invalid transaction, the minimum amount slashed will be 1 ETH, but if other validators are simultaneously acting inappropriately then all the ETH could be lost. There are less draconian punishments for a validator being offline, but, again, if a validator is offline at the same time as others so that at least 1/3 are not participating and so preventing consensus from proceeding, then the slash can be significant.

Downsides of Slashing

First and foremost, slashing introduces complexity into the system and complexity introduces greater scope for attack. Slashing requires another set of parameters that must (or can depending on your PoV) be tuned and so complicates analysis and proof of the system’s security. Additional complexity emerges from the necessary mechanisms for detecting the bad behavior to be slashed. Some slashing systems introduce ‘fishermen’ or ‘whistleblowers’ whose role (and business model) is to report misconduct. In order to make a report (and be eligible for the reward), the fishermen themselves may be required to bond some stake, which could be taken away if the report is spurious.

Slashing also complicate the proof of the security of the ledger. If the security is dependent on human actors and their thinking, feelings, and assessment of risk, then how can we make mathematical guarantees about that security?

As an example, Ethereum 2.0 introduces the concept of ‘economic finality’. Finality is the feature of some DLTs that, once a value has been decided for a given proposition, no subsequent event can change that. Ethereum’s ‘economic finality’ softens that guarantee, adding ‘unless a large number of people are willing to burn very large amounts of money’.

Related, slashing presumes a rational assessment of the trade-offs of an attack; that is, a rational actor will not engage in an attack unless the potential gain exceeds the risk of coins lost to slashing; however, a virus that gets installed on a node, or compromised node software, will not act so rationally, nor will it consider the best interests of whatever node it happens to be installed on. You can’t discourage an actor that doesn’t care about the consequences.

The above highlights the potential for an honest participant to be nonetheless slashed and lose funds through no fault of their own. This risk would surely discourage some of those contemplating running a node. If a node, or more generally any participant in the staking, can lose stake due to their breaking of a rule that was not their fault, then the attractiveness of acting as a node or staking is diminished.

Last but not least, if the slashing requires bonding, then there is an opportunity cost due to the loss of liquidity. By bonding, users generally lock up their coins for a defined period. Once locked up, those coins would be unavailable should there be a sudden downturn or some other investment with a greater rate of return. As an example, early nodes on Ethereum 2.0 may have their 32 ETH stake locked up for over a year.

Hedera Hashgraph and Staking

Slashing in PoS blockchains is a recognition that nodes have a choice on which chain to build. The rule of “longest chain” or variants stipulate how to choose from amongst candidate chains, but a node can break the rules and work on some other chain for potential advantage. Without slashing, nothing prevents a PoS node from building on multiple chains at once – the ‘Nothing at Stake’ attack. The hashgraph protocol does not provide the same opportunity for bad behaviour by such a leader because there is no leader, and so no discretion given that leader to create the next block, nor which chain to build on.

In hashgraph, nodes do not rely on other nodes making an assertion as to what should be the consensus decision on some question; for example, what is the next block. Instead they calculate what the other node would assert if that node were to do so. Honest votes occur as the protocol dictates and all a dishonest node can do is to try to outvote the honest nodes or otherwise skew consensus.

Critically, the votes are virtual. Even if Alice wanted to break the rules by casting a bad vote (on the fame of some witness), then it is the other honest nodes who effectively vote for Alice – and so eliminate her ability to lie. The ‘Nothing at Stake' problem is logically a malicious block validator casting two votes (on which chain is canonical). In hashgraph, other honest nodes cast those votes on behalf of other nodes and the decision is effectively taken out of a dishonest node’s hands.

Hedera uses the stake of a node (both its own and that proxied to it by other accounts) in two ways – to weight 1) the votes of that node when voting on consensus and 2) the payments paid to the node and those accounts to incentivize their participation. Neither the node’s nor the proxying account’s stake is bonded; it can be moved at any time (though the voting and payment weights will be reduced accordingly). For the accounts proxying to a node, there is no risk of losing that proxied stake, should the node break the protocol rules. There is however one scenario where the node itself will be charged a fee should it not perform the expected validation of a transaction. Generally, it is the client (or a designated payer) that creates a transaction and submits it to a particular node for gossip to the network that pays the associated transaction fee (some of which goes to the submitting node and the rest to the Hedera treasury). A tiny fraction of that fee is the “network fee”, which covers just the cost of gossip and consensus for that transaction. The user is charged that fee, assuming they used a valid, non-empty account and properly signed the transaction. The node is responsible to make that single check: can the user afford that small fraction of the fee. If the node fails to do that check and the user’s account cannot pay, then the node must pay that small fraction of a cent. All the other nodes will have performed the small amount of work to gossip and reach consensus on the transaction and so should be compensated.

The fee did not come from any locked up or bonded HBARs, but simply from the node’s associated account. The node only needs to keep perhaps one dollar’s worth of hbars in that account. A node will be removed if its balance drops too low as it might then be unable to pay the fee. Again, any accounts proxying to the node would be unimpacted.

The above fee is arguably a slash as a node that does not follow the protocol does lose funds. But it is less a penalty than the network simply requiring that someone pay the network fee if the user can’t.

Prevention or Punishment

Fundamentally, the hashgraph protocol gives nodes less opportunity for breaking the rules of the protocol than in blockchains and so there is less need to punish them for such rule breaking. Punishing a crime is less desirable than preventing it in the first place. Consequently, Hedera implements neither bonding nor slashing and so does not confront the downsides of both described above.