Half-Baked is Always Better than Double-Baked — What is at Stake in the Tezos Protocol?

Many of you have seen on Reddit or Twitter that a Baker on Tezos had been losing XTZ at an alarming rate: more than 25,178 XTZ (~$32,227.84, at a valuation of $1.28) in less than 48 hours. Recently, another baker lost more than 24,293.33 XTZ. Ever since the betanet launch, there have been many occurrences of bakers committing safety-faults, but the recent events set the perfect precedent to dig a little bit deeper into Liquid Proof-of-Stake (LPoS).

Half-baked is always better than double-baked is a series of articles on the security behind the Tezos protocol.

Unlike my previous articles on expected rewards from solo-baking or offering baking services, in this first part of the series, we will talk about the other side of the oven: the risks that every baker in Tezos is assuming. In order to understand the latter, one must first understand how Liquid Proof-of-Stake works and what the security assumptions the Tezos protocol is making.

My Oven Exploded and the Kitchen Caught on Fire — by It’s all in the wrist

The Nothing-At-Stake Problem

To understand what security assumptions the Tezos protocol makes, as well as why the term Proof-of-Stake has the word Stake on it and why LPoS was designed the way it is, let us make a recap on the so-called Nothing-At-Stake Problem (NASP).

The Nothing-At-Stake problem is a phenomenon that occurs when the validating nodes in a protocol can generate and maintain multiple forks at no cost. Mechanisms such as Delegated Proof-of-Stake (DPoS) have been under large scrutiny because they suffer from such problem: any block producer in EOS could be signing at multiple block heights with the same keys, creating and maintaining multiple histories.

Even though there is no notion of stake in the EOS protocol, one could argue that EOS block producers have their reputation at stake, with the major assumption of: if a block producer deviates from the protocol, it will lose votes until they do not rank on top 21 or the upcoming 100 anymore. However, the previous relies on, but not limited to, the following two assumptions: first, that the token holders are able to detect when a block producer creates forks; and second, that the token holder is incentivised enough to monitor and act upon in the latter.

How Does Tezos Avoid the Nothing-At-Stake Problem?

There are many approaches mechanism designers can take to avoid the NASP. Tezos’ LPoS handles it in a particular way: first, for someone to become a baker, there is a minimum of 10,000 XTZ that the baker must own to be eligible to participate in consensus; and second, the amount a baker can take in delegations is limited by the amount in self-bond or balance available for security deposits. In other words, to become a baker (validating node on Tezos), you must have something, if not quite a bit, at stake. Double-signing or double-endorsing (committing safety faults) will result in losing the a portion or the entirety of the that stake.

This is an example of how cryptoeconomics play a crucial role in Proof-of-Stake protocols. Cryptoeconomics, a word that you will certainly bump into more and more frequently, are nothing else but mechanisms implemented in protocol that economically incentivise or disincentivise certain behaviours in stakeholders of a network.

The Tezos protocol shows many cryptoeconomic instances. For the scope of this article, we will focus on the security deposits that a baker must possess in order to participate in consensus, which can be lost in case the baker commits safety faults. By requiring that bakers possess a minimum amount of XTZ as well as the amount to be larger in order to take more delegation, the protocol is disincentivising bakers to double-bake and -endorse. Because if they do so, they can lose 512 XTZ per double-baked block and 64 XTZ per double-endorsed block, the maximum being the entirety of the baker’s self-bond.

In addition to the losses per block or endorsement, the baker also loses all the rewards and fees that were locked together with the security deposits (~5 cycles during which the rewards are frozen).

There are further implications. The larger the baker, measured by staking balance, the more funds and potential rewards at stake, since the maximum amount of delegation a baker can take relies on how large the self-bond is (find more on overdelegation in this article: Is Your Favourite Baker Overdelegated? Understanding Self-Bond Requirements in Tezos).

A Clarification of the Slashing Conditions

Because it was news to most of the bakers, including us, and to avoid any confusion, I wrote this explanation on the actual losses in the event of committing a double-baking or double-endorsement: https://www.reddit.com/r/tezos/comments/a4l0pe/punishment_for_doublebaking_or_doubleendorsing/.

Why Do Bakers Continue Baking?

For the Tezos network to exist and continue processing transactions, there must a set of bakers, because they are the ones in charge of maintaining the network active and baking blocks. While Tezos disincentivises the bakers to commit safety faults, at the same time it incentivises token holders to become bakers: by baking and endorsement rewards or inflation. To get an idea on how much a baker could potentially earn, take a look at these articles:

Grosso modo, costs and risks aside, baking and offering baking services potentially generates more earnings than simply delegating the funds. Needless to say, running baking operations comes with costs, and most importantly, baking is not a risk-free-activity, as we have seen at the beginning of this article.

[To be continued in Part II: Half-Baked is Always Better than Double-Baked — How to Double-Bake and How to Prevent Double-Baking?]