SIMD-0212: Slashing On Solana

Written By

Rex St. John

January 17, 2025

A Closer Look At SIMD-0212

In this article, we cover SIMD-0212: Slashing. Slashing on Solana is currently under active discussion which will involve community input and ultimately a governance vote. The goal of this SIMD is to propose specifics around the economics and implementation of how validators are slashed should they be found to be engaging in adverse behavior to the network. This SIMD covers three different topics:

Introduces a function to derive the amount of stake to slash for each offense
Runtime changes to consume the slashing program's results and subtract stake from delegations at epoch boundaries
Future work to shore up faults in the proposed slashing mechanism

SIMD-0212 proposes one possible method for punishing slashable infractions via burning delegated stake. The proposal is currently in discussion phases with the community and participants are encouraged to contribute commentary. SIMD-0212 is currently undergoing a phased rollout which begins with the introduction of the SIMD, followed by a period of discussion finalized by a governance vote then rollout broadly.

The Proposed Slashing Function

The heart of the proposed slashing economics will revolve around the design and implementation of a quadratic function which determines the economics and consequences for punishing bad behavior. While the Solana protocol has proven robust and secure up until this point without slashing, the addition of slashing provides an added layer of additional security to further ensure proper behavior of validators in the network.

With the current parameters, an optimistically confirmed block in Solana will always be finalized unless a portion of the stake is eligible to be slashed. Certain classes of behavior are not detectable in real time but can still be harmful to the network. Using an on-chain verifiable proof submission mechanism, community members can report slashable events and help keep the network safe.

We begin with the following formula which specifies “Stake weighted slashable offenses based on max stake in the reporting period.” Basically what this is saying is that “based on the number of offenses “num(t,v)” which occurred during the reporting period, add up the stake assigned to that node and determine how heavily to weight the penalty. Voting violations are penalized at a weight of 1 (they are less severe). Duplicate block violations are weighted at 10 (a much higher penalty as they are considered more severe.

We are not conclusively covering the entire formulations in this article and recommend reading the SIMD itself for the full details.

Once the slashable stake for offending validators is located, and the penalty is weighted (based on the type of violation), a quadratic function is proposed which offers a slow rate of growth. The idea here is that that minor infractions are not harshly penalized (this means a "slow rate of climb" is preferred). Such errors might be explained by operator error and do not warrant harsh penalties for the sake of giving the network the freedom to make occasional mistakes. Highly aggressive slashing would disincentive small operators because the penalty for making mistakes would ensure only larger or more skilled operators would want to risk the threat of being slashed.

A slow rate of climb quadratic function is proposed (Bottom dark red line) which is calculated using:

This quadratic function results in a gradual and proportional punishment based on the severity of infractions such that very harsh penalties only come into play when the network reaches higher stages of bad behavior. The slow rate of growth allows network participants time to adapt before facing more harsh punishments.

Checking For Slashable Validators

The slashing logging monitor program introduced in SIMD-0204 covered in our last article performs the function of creating a record of any misbehaving validators from the last epoch by storing their PDAs (program derived accounts). In essence, these PDAs identify validators who have been flagged to be eligible for slashing penalties. Users are able to submit proof reports using the on-chain program which demonstrate slashable behavior.

What To Expect Next

Implementing slashing on Solana is a serious undertaking requiring careful analysis and thoughtful discussion. These SIMDs will undergo a period of significant discussion and testing leading ultimately to a governance vote to see them implemented in the network. Anza core engineering and the broader Solana community are encouraged to participate in the discussion leading up to a proposed governance vote to finalize implementation.

Timeline

2024-17-17: Initial Proposal Created

Credits

Thanks to everyone who took the time to give feedback on this post including Wen Xu, Tim Garcia, Ashwin and Ben Hawkins: