Blockchain

Sharing the costs of securing a Proof of Stake blockchain.

Photo by Nicolai Dürbaum on Unsplash

Proof of Stake blockchains secure their network with the mechanism of requiring validators to stake tokens. Their is a condition attached that if the validators “misbehave” such as going offline for a period of time or double sign, then a proportion of the staked tokens are “slashed” which means the tokens are either burned or sent to a community fund. For securing the network validators are rewarded with transaction fees and in some cases block rewards.

Each chain has their own set of rules, and it is common that punishable events (slashing) are for prolonged downtime, double signing, or deliberately including an illegal block. The consequence of this is for the validators to invest heavily in infrastructure to mitigate events such as DDOS attacks that could bring them offline and build in redundancy into their infrastructure in case of hardware or network failure. This all comes at a cost which means that the validators need to earn sufficient revenue to cover it and make a return, and additionally it may exclude validators who are unable to finance the required infrastructure.

The exclusion of validators unable to finance the infrastructure is an issue for blockchains as it potentially reduces the available validator set. It should be noted that staking and infrastructure costs are not tightly coupled as a validator without deep pockets to fund the required stake can collect delegated stakes in return for sharing their revenue.

What if a validator could build a slightly less resilient infrastructure and buy some sort of insurance to cover being offline and the cost of being slashed?

Photo by Craig Whitehead on Unsplash

A Stake Slash Swap (SSS) is a candidate for this and works in a similar way to a Credit Default Swap (insurance for a default event with a fixed income product). The SSS functions by a party entering into an agreement with the validator to cover the cost of a slashing event where the validator has gone offline in return for a premium. Note that the SSS would not cover a double signing event or the illegal block inclusion as that could produce a poor incentive.

The premium is determined by the likelihood of the validator suffering a prolonged period offline based on their track record. By using the data from the chain it to calculate the premiums, it is conceivable that the premiums would be lower if the validator had 99.5% Uptime compared to 98% Uptime. This would only work if the metrics were available for a given infrastructure, and could thus create a situation where a validator has a “good enough” set up but no metrics so could not get cover from a SSS. A solution for this would be for a validator to participate in a testnet for a period of time to establish the relevant metrics.

Let’s say that a validator has invested in the infrastructure and has been running in the testnet environment for three months. This has established the metrics on up time. The calculated Uptime for the 90 period for the validator was 99.5% meaning there were few blocks missed. There has been no slashing event in this period but the Uptime can be used to calculate the probability of an event occurring.

That information then feeds into the calculation to determine what premium would be required to cover the potential slashing events based on the total staked amount.

The SSS can either be individual products based on a single validator or could be collected into a basket of validators.

The buyers of the SSS do so with the incentive of being paid a premium for an event that may not happen, and they have made the calculations of the probability of the event occurring.

It would be conceivable that these instruments could be interesting for a blockchain wishing to have a broader set of validators by encouraging honest validators with lower infrastructure costs.

They are also of interest to people who risk having to payout but gain a nice yield from the premium payments.

At Confio, we are doing deep thinking on the next generation of DeFi protocol. We are drawing on Financial Engineering in the traditional markets and applying them to digital assets.

To learn more follow us on medium, or reach out to us on Telegram

TgradeFinance

Author TgradeFinance

More posts by TgradeFinance

Leave a Reply