Baking and verification - comparison by computation amount needed

What is the relation between computation processing amount versus the processing amount on verification of the baking results?

Why I ask this is that I am wondering is it really that baking is done once and needs then 32 verification events. Is the 32 times bigger amount of verification events so much easier to implement and count that double or triple baking and their comparison is useless / wasteful approach?

This became to my mind when I thought what happens if the calculation fails, but that is another topic.

• It's not clear what you're asking. What is "double or triple baking" for instance and what do you means by a "verification event" Feb 8 '19 at 11:44
• You bake a block, right? Then 32 others verify results. 'Why the relation is 1 to 32?' is my real question. Why is not as efficient to bake twice or triple and verify the bake result is the same?
– mico
Feb 8 '19 at 12:01
• @mico, would this be a good rephrasing of your question? Feel free to edit using this suggestion if I understood correctly what you meant :) What is the relation between computation processing amount versus the processing amount on verification of the baking results? I ask this because baking is done once and then is verified by 32 endorsers. Is this done to reduce the amount of computation (if verification is easier than baking)? Couldn't we instead have 32+1 bakers all produce a block independently, and then check that all of these blocks are identical? […] Feb 8 '19 at 12:14

@ArthurB please correct me if I said anything silly :)

Nondeterminism: two bakers won't produce the same block

The baking process is not deterministic. Among other things, if several people bake independently, the list of transactions included in the block will not be the same (e.g. one might include a transaction that the other never heard about, due to network lag).

Therefore, we need to pick a single block baked by one person. To do this, we let one node bake, and then the others put a stamp on it.

You can think of it as the first node making a block, and informing the others of the list of transactions it chose to include, so that they can then verify.

Endorsers

The goal of the verifications (endorsements) is not to reduce the amount of computation that needs to be performed. Their goal is to speed up a consensus on which block to pick in the case where two distinct bakers produce two distinct blocks at roughly the same time (due to network lag, it won't be clear to everybody which block was baked first, so we cannot use this to decide which one to pick).

If two distinct bakers release two distinct blocks `b₁` and `b₂` at roughly the same time, one part of the network would continue the chain believing that `b₁` is the current head, while the other part would continue while believing that `b₂` is the current head. Eventually, as information is propagated across the network, the majority would win (if more nodes / bakers think that `b₁` is the correct head, more blocks will be built on that one, it will get noticeably longer and look like a better bet, therefore incentivizing nodes to switch to that head).

To reduce the likelihood of that short period of confusion (a short-lived fork where transactions which only exist or are only valid in one branch would be dropped when everybody moves to the other), we have endorsers which put their stamp on the block that they believe is the best one. If they guessed correctly (the majority chooses that block) then they get a small reward, otherwise they do not. This incentivizes the endorsers to wait a few seconds so that if a better-looking block comes with a slight network delay, they will pick this one instead.

You can think of this as a sort of pre-election poll for a vote where everyone is incentivized to vote along with the majority (thankfully we are not talking about politics here!). You first poll a small number of people (the endorsers). When the rest of the nodes make their vote, they will pick the option chosen by the most endorsers, knowing that everybody will likely do the same, and therefore knowing that they have a high chance of picking the correct chain.

Double baking

If the same baker produces two distinct blocks `b₃` and `b₄`, and tries to feed b₃ to some nodes, and b₄ to others, it could on purpose try to fork the chain. As discussed above, this is not something good, I suspect it could be used in some circumstances to double-spend (by including a transaction which sends the same tokens to `x` in `b₃` but to `y` in `b₄`).

Eventually, the majority will decide on one block or the other, and will drop the other (so only one transaction will be kept, the one to `x` or the one to `y`).

However, if all bakers are double-baking willy-nilly to satisfy their own interest, the network is going to have a hard time dealing with all these useless forks.

Therefore, we punish double-baking. The protocol is that you should bake only one block, so if you diverge from the protocol, you get punished, which incentivizes good behaviour. If I recall correctly, there is also a small reward for the person who reported the double-baking, to incentivize people to check for that, and make sure they do report it.