Slashing Time
What is Slashing and how is it used?
Welcome to the new Bearmint Investigation Series. As we near the public release, this extensive series will dive into the brand new ARK framework and consensus called Bearmint while breaking it down as simply as we can.
In our last episode, we went over passphrases, keys and the new 2 key system for validators in the upcoming Bearmint consensus and framework. In this episode we’ll cover a short technical topic regarding slashing and penalties that help to protect the network.
This article may be a bit more technical than others, but our goal here is to explain things easily so by the end of the article, every reader can walk away with important knowledge and understanding of the new framework.
What is Slashing?
Slashing is a method to protect a decentralized network from complacency and misbehavior. It’s like a punishment for misbehaving at the consensus level. This is a technique that motivates validators to improve their infrastructure and security. It also holds voters more accountable for their choice of validator.
There are several different types of misbehaviors that validators can engage in, and at present, they are limited to an unknown misbehavior, downtime, a light client attack, duplicate signing and duplicate voting on a proposal. Now let’s take a closer look at what those behaviors mean:
A double proposal misbehavior is recorded when a faulty validator proposes two different blocks for the same height and round during consensus.
A double signing misbehavior is recorded when a validator sends multiple prevote and/or precommit messages for different values for the same height/round.
A light client attack misbehavior is recorded when conflicting headers for a given height are detected. A light client attack is defined in the context of the interactions that take place between a light client and two peers. One of the peers (known as ‘primary’) defines a trace of verified light blocks (the ‘primary trace’) that are checked against the trace of the other peer (the ‘witness trace’). Simply put, a valid light client attack contains two components, namely a common light block and a single conflicting light block.
An unknown misbehavior is recorded if something seems amiss, but the exact cause could not be determined.
Downtime happens when a validator is missing blocks, can’t connect to the network or peers and is not validating blocks for a certain amount of time.
This is just a sample of the misbehaviors that can be punishable by slashing. These punishments generally employ percentage-based penalties that affect rewards for validating blocks. These penalties are meant to deter misbehavior by implementing a penalty that reduces a validators and/or voters rewards. This can be a percentage of rewards removed over a period of time or a complete removal from the network to avoid further damage.
This technique is another way for the network to heal itself incase of bad actors or simple misbehavior. In some networks, slashing can even trickle down to the voters/stakers of the validator in question. Doing this holds everyone backing the questionable validator responsible as well.
The severity of slashing implemented towards a validator and it’s voters is based on duration of misbehavior in most cases.
How do I know if a validator is misbehaving?
The simplest ways for the non-technical would be to look at the Delegate tab on the ARK blockchain explorer, https://arkscan.io. As you can see, there are green circles with check marks in them, which represent the last 5 blocks that each validator has successfully validated. If a validator fails to validate a block, this green circle will show red as seen in the images below. There is also a productivity percentage next to each delegate name that shows the amount of uptime and blocks validated over the previous 30 days.
There is also a quick method to see when exactly blocks are missed and by which validator by joining the ARK Community Discord and watching the #arkbot channel.
How will Bearmint implement Slashing?
Once Bearmint is live on the ARK mainnet itself, it will support slashing at the voter level and jailing at the validator level. As validators themselves have little at stake and cannot attain a forging position without an address voting for them, it is only logical for the slashing to include both validator and voter. This combined technique will affect a voters rewards with a percentage cut for their validators missed blocks. The more missed consecutively, the more the percentage cut or slash. This can also result in the validator being “jailed” for a certain amount of time (ie: number of blocks) and excluded completely from consensus until the network itself deems it is safe to rejoin, or to remain jailed indefinitely.
The current form of slashing is the most basic at the moment, according to the team at Basecode.
Misbehavior is reported at the consensus level and then voters get their stakes slashed for a configured percentage as soon as misbehavior is reported.
This exact percentage is not currently known, but expected to be finalized during or prior to the public testing phase.
There are many variations and configurations to slashing, and Bearmint will support most of these. This will be very handy for any projects looking to build using ARK. Giving developers and projects custom options and ease of use is something that ARK has always held to be a priority as seen in the ARK Launcher product.
Conclusion
Slashing can be an effective way to mitigate misbehavior on a network. It holds validators and their voters accountable for securing the network properly. It can also help with complacency in that it gives voters more reason to pay attention to whom they are electing to run and secure the entire network.
There are more nuances to slashing and in some networks validators even offer slashing protection, but that is a topic for a future post. For now, we want everyone to understand that slashing is coming to ARK and voters need to be aware of who they are voting for and hold them accountable for properly securing the network.
We know that this topic will raise some questions among the community so please rest assured that we will revisit this topic in more detail once Bearmint is into it’s testing phase and more data can be scraped from the network.
This is episode 4 of our extensive blog overview, with many more to come. Stay tuned for more from this series as we get closer to the Bearmint public testing release. Be sure to subscribe to our blog and follow us on social media to stay up to date, and don’t forget to jump into the conversation on the ARK Community Discord as well.
If you enjoy our content, please consider voting for our validator, more information can be found here https://strake.foundation/delegate/.