Conversation

3. That said, the penalties that I used were very small, only canceling out signing rewards. Vlad Zamfir joined in mid-2014, and he quickly moved toward requiring validators to put down *deposits*, much larger in size than rewards, that could be taken away for misbehavior.
5
131
5. We spent much of late 2014 trying to deal with "long range attacks", where attackers withdraw their stake from deposits on the main chain, and use it to create an alternate "attack chain" with more signatures than the main chain, that they could fool clients into switching to.
3
114
6. If the attack chain diverges from the main chain at a fairly recent point in time, this is not a problem, because if validators sign two conflicting messages for the two conflicting chains this can be used as evidence to penalize them and take away their deposits.
3
92
7. But if the divergence happened long ago (hence, long range attack), attackers could withdraw their deposits, preventing penalties on either chain.
2
81
9. We realized that we could deal with long range attacks by introducing an additional security assumption: that clients log on at least once every four months (and deposits take four months to withdraw), and clients simply refuse to revert further than that.
3
95
10. This was anathema to PoW proponents because it feels like a trust assumption: you need to get the blockchain from some trusted source when you sync for the first time.
2
90
11. But to us dirty subjectivists, it did not seem like a big deal; you need some trusted source to tell you what the consensus rules of the blockchain are in any case (and don't forget software updates), so the additional trust required by this PoS assumption is not large.
7
135
13. Now that we settled on deposits and penalties, we had to decide what those deposits and penalties _are_. We knew that we wanted an "economic finality" property, where validators would sign on blocks in such a way that ...
2
61
14 ...once a block was "finalized", no _conflicting_ block could be finalized without a large portion of validators having to sign messages that conflict with their earlier messages in a way that the blockchain could detect, and hence penalize.
3
68
16. Consensus by bet was an interesting construction where validators would make bets on which block would be finalized, and the bets themselves determined which chain the consensus would favor.
2
65
17. The theory was that PoW also has this property, as mining is a bet where if you bet on the right chain, you gain (reward - mining cost), and if you bet on the wrong chain, you lose the mining cost, except with PoS we could push the odds on the bets much higher.
3
72
18. The odds on validators' bets would start off low, but as validators saw each other getting more and more confident about a block, everyone's odds would rise exponentially, in parallel, until eventually they would bet their entire deposits on a block. This would be "finality".
2
71
19. In the meantime, Vlad started heavily researching mechanism design, particularly with an eye to making Casper more robust against oligopolies, and we also started looking at consensus algorithms inspired by traditional byzantine fault tolerance theory, such as Tendermint.
2
89
20. Vlad decided that traditional BFT was lame (he particularly disliked hard thresholds, like the 2/3 in PBFT and Tendermint), and he would try to effectively reinvent BFT theory from scratch, using an approach that he called "Correct by Construction" (CBC)
3
88
22. The correct-by-construction philosophy is very different from traditional BFT, in that "finality" is entirely subjective. In CBC philosophy, validators sign messages, and if they sign a message that conflicts with their earlier message...
2
57
23 ... they have to submit a "justification" proving that, in the relevant sense, the new thing they are voting for "has more support" than the old thing they were voting for, and so they have a right to switch to it.
3
66
24. To detect finality, clients look for patterns of messages that prove that the majority of validators is reliably voting for some block B in such a way that there is no way they can switch away from B without a large fraction of validators "illegally" switching their votes.
2
61
25. For example, if everyone votes for B, then everyone votes on a block that contains everyone's votes for B, that proves that they support B and are aware that everyone else supports B, and so they would have no legitimate cause for switching to something other than B.
5
62
26. I eventually gave up on consensus-by-bet because the approach seemed too fundamentally risky, and so I switched back to trying to understand how algorithms like PBFT work. It took a while, but after a few months I figured it out.
2
81
28. I defined a rule for determining when a block is finalized, and proved the key "safety" and "plausible liveness" properties: (i) if a block is finalized, then there is no way for a conflicting block to get finalized without >= 1/3 violating a slashing condition ...
3
59
29. ... (ii) if a block is finalized, 2/3 honest validators can always cooperate to finalize a new block. So the algorithm can neither "go back on its word" nor "get stuck" as long as > 2/3 are honest.
2
64
30. I eventually simplified the minimal slashing conditions down from four to two, and from there came Casper the Friendly Finality Gadget (FFG), which is designed to be usable as an overlay on top of any PoW or PoS or other blockchain to add finality guarantees.
2
89
31. Finality is a very significant advancement: once a block is finalized, it is secure regardless of network latency (unlike confirmations in PoW), and reverting the block requires >= 1/3 of validators to cheat in a way that's detectable and can be used to destroy their deposits
4
120
Show replies