Tezos Baking: Your Bonds & Their Risks
If you’ve been following Tezos for any length of time, you’ve probably heard of the concept of the “bond” in reference to staking and generating Tezos blocks. Now though, the actual preferred nomenclature for the concept of a bond is “security deposit”. The general idea of this security deposit is that as Tezos uses a PoS (proof of stake) algorithm for block generation, it could greatly benefit from strengthening the specific PoS implementation. The blockchain handling of the security deposit is such to force proper behavior from the “bakers” (block generators and endorsers in Tezos called “bakers”) who are staking their Tezos while generating blocks or endorsements. In case the concept of endorsements are unclear, they are a special type of operation (for operation, think “transaction” in a block where they aren’t quite the same thing, but beyond the scope of this discussion) in a block whereby bakers can vouch that previous blocks they’ve seen are valid. It appears the overall goal of using endorsements is to prevent attacks such as the nothing at stake or eclipse attacks.
You may be a bit puzzled at the article title’s plural usage of the noun “bond” (again, security deposit) in reference to the owner. Its clear from observation of public discourse on Tezos that the concept of the security deposit at large has common a misconception of how it actually works. When the Tezos whitepaper hit the masses about 2 years ago, we all read about how Tezos will use a type of DPoS (delegated proof of stake) whereby Tezos holders can delegate rights to other bakers for block generation, with the presumption that the baking delegate will share rewards in return for those rights. And we all (probably all of us, including the author at first) read and interpreted it such that a baker would have to post up a security deposit equal to 10% of the total Tezos delegated to that baker, and if they “misbehaved” (murky unclear there) they would lose that security deposit. While the official number now is 8.24%, the interpretation of the security deposit as a single monolithic entity is incorrect. This 8.24% figure is not an actual blockchain programmed “constant” but is really a figure that has been derived from other blockchain constants in conjunction with blockchain operation that assumes all 100% of Tezos is staking. This assumption simply won’t be the case when the network is in operation; it remains to be seen on average how much does stake. In reality, when a baker wishes to generate a block they have been given consensus rights to, they first have to post up ꜩ512 as a security deposit that is held which they get back later with the block reward of ꜩ16 assuming they did everything correctly. Security deposit for an endorsement is ꜩ16 and its reward is generally ꜩ2. Those numbers will be defined in the blockchain constants per Tezos Dev Docs. So then this “bond” we all discuss is actually the sum of all the security deposits a baker has posted to generate blocks, in cycles that are not yet considered permanent due to potential forking. Tezos has defined this period for permanency by constants to be 5 cycles where for main-net a cycle length by constants is planned to be 4096 blocks, and Tezos will target for a block every minute.
The more Tezos you stake (sum of all your Tezos combined with sum of all whoever delegates to you) the more blocks that consensus will give you priority to bake, but you can only bake them if you have enough ꜩ in your account to post a security deposit for those blocks. It may not be obvious at first, but consider what happens as the percentage of overall global Tezos that is staking drops. The result is the bakers that are active will get to bake more blocks, assuming they have the security deposit to post it up. Since we cannot expect all 100% of Tezos to stake, this means that the security deposit/stake ratio will indeed go higher than 8.24%, and can potentially put stress on delegates who could then run their account dry until they get future security deposit & rewards back. In this case there will be a short delay before some other baker would have rights to bake that block in the place of the original delegate. There currently is no mechanism in Tezos to help delegates prevent getting overextended and in a position where they cannot pay their constituents as arranged.
At the surface, the security deposit seeks to address 3 main concerns, but I see a 4th point that many may not consider. The first 3 are indeed manners in which a delegate may lose a security deposit (or in some cases, a lot of them at once it turns out, more on that later).
- Prevent bakers from “double baking” a block. This is when a Tezos baker whether by accident or done maliciously in attempt to fork the blockchain, bakes the same block level on the same “head” (a branch or fork is referred to as a “head” in Tezos) twice using the same secret key, but with different baking processes. The different processes will generate separate nonces for the blocks, which result in a fork. This could happen accidentally if a baker started up a baking process with a key where they were already somewhere else running a baking process using that key. For example, a baking system’s misconfigured backup/redundancy system could easily result in this scenario.
- Prevent “double” endorsements. Think of the same concept as above, but for endorsing.
- Ensure bakers reveal nonces if there is a commitment to do so. Every 32nd block in a cycle (starting with the 32nd block of the cycle, zero justified) is “special” in that at some time in the following cycle that the block was baked, the baker of that block must reveal the nonce used to bake that block. This “revelation” is yet another special type of operation that gets baked into a block; then all revelations of a cycle are hashed together via consensus to provide a random seed used for block generation in a future cycle. A security deposit could be lost here if a baker were to bake one of these special blocks that comes with a commitment and then just shuts down the baking software, where then during the next cycle the baker was not available to broadcast the nonce as required. In this case denunciation isnt required — consensus will automatically seize and burn the bond.
- The security deposit and its base requirement being derived @ 8.24% (again, the actual figure in operation will be higher that 8.24%) for security deposit/stake ratio could help to prevent centralization of bakers, since to bake for a majority of the network, you would have to personally own in a single key a tremendously vast amount of ꜩ.
In our next article we will discuss a recent demonstration in the zeronet where we showed how a security deposit was lost due to double baking. In fact, via consensus the security deposit was taken from the double baker and partially given to another baker that provided evidence to the blockchain of this behavior in another type of operation called “double_baking_evidence”. Per docs linked above, half the security deposit is to be given to the denouncer, and the other half is to be burned. There’s actually more to it than this though, things end up being more drastic. We’ll get more into this during the experiment we’ll detail in a later article.
In short — there *are* real risks when baking on your own. But if you fully understand them, then it should be possible to safely bake. In fact, the foundation is funding a project to provide easy baking for the masses. But before you start that baking process, check, and double-check if you have baking already running on any of your other systems. And if you plan to implement some kind of redundant or backup baking node, tread *very* carefully.
Tezzigator will be an already-experienced delegate live at Tezos genesis block launch. Our motto is “When Tezzigator earns, YOU earn!” Your Tezos stake *will* devalue if left alone! Delegate to Tezzigator (even in cold storage!) and INCREASE value. ©2017 Tezzigator LLC