The NYC Blockchain Workshop was really cool. I got to meet a lot of people I have sent emails to in the past. The most interesting interaction I had was discussing how Casper works with Vlad and Greg. When I first read about Casper I mostly ignored it because I didn’t understand what it provided or why it would be required. Here I will be distilling my thoughts on the matter mostly for my own sanity, hopefully this distillation will help you and any errors I make will be cleared up by the community (Vlad, Gred, Vitalik, Jae, Ethan, et al).

Purpose

Casper will allow for the maximum amount of concurrently executing smart contracts sharing global state with the minimum amount of trust given the constraints of a pseudonymous Proof of Stake consensus algorithm.

The first thing I did when reading about Casper was compare it to Tendermint. Although they are both “Proof of Stake” Byzantine Fault Tolerant Consensus Systems, they have very different requirements regarding trust and concurrency. Both algorithms have the ability to blame and punish byzantine nodes. But without named nodes and/or some form of network extrinsic trust, it is impossible with Tendermint to have many classes of parallelism. (I don’t want to state this too strongly because I’m actually not sure what the limits are, but it’s clear that Casper-style sharding is out of scope.) The Stellar Consensus Protocol actually supports this worldview as well, since quorum slice selection is based on network extrinsic information.

If we take a step back it actually makes a lot of sense that BFTCSs have this odd issue with concurrency and trust. BFTCSs requires that 2/3rds of the nodes agree on any true statement, so if we want to increase performance by having some number of nodes fewer than than 2/3rds engage in verified computation, we need a way for the remainder of the quorum requirement to verify the sub-quorum’s computations are correct. Casper achieves this by providing two different types of confirmation. The I-Know-Something-About-Bitcoin version is: Casper gives us sub-quorum confirmations on transactions entering the mempool that should always receive quorum confirmation within some fixed block-time/real-time interval. With the caveat that if the application above Casper is written incorrectly, that first confirmation could be invalid. (I think this caveat is fine as long as it’s programs writing the applications, which is the plan.)

How it works

Casper is a unique guessing game. The goal is to correctly guess the next block, those who do, receive a reward. A Casper game consist of a fixed duration of time, which can contain any number of rounds; rounds can contain any number of plys. Players are attempting to maximize their individual rewards.

Every player has the same set of rules for what is acceptable as the next block, but in order for that to actually be the next block 2/3rds of us need to agree upon it. Before any blocks are presented to us, we all agree to buy into this game. For the sake of simplicity we all buy in at the same amount. BUT! We don’t play this game on a table, we play it over the internet, so any of us can buy in any number of times! We then use our buy-in to make a signed wager on which block we think will be next, for an arbitrarily sized pool of blocks. At the start of every round, every player antes, if some of us do not wager on at least one block during one ply within the round, those players lose their ante. The round ends when 2/3rds or more of the remaining buy-in is wagered on a single block. We are then presented with a new set of blocks and the game continues until we run out of time. It is important to note that 2/3rds of the buy-in must be online and playing the game for it to continue, if that amount of buy-in is not wagering, for whatever reason, game progress halts. (This is actually might not be correct, as this is a point of confusion for me. If literally no one made a wager within the window, progress halts. But if even one player makes a wager, progress should continue. How game rejoins work in this case is complex and undetermined, so we just assume that less than 1/3rd of players drop within a single ply timeout.)

Metagame and challenges

One of the interesting properties of this game is we can wager up to our remaining buy-in on any number of blocks in a ply or round. Whatever bets we make on a block stay with that block, so if we wager everything on two blocks and one block loses, we lose everything, we then get paid the reward for wagering on the correct block as well. So if you place all of your money on 3 different blocks in a round you will be out of the game. It’s important to remember here that only a cheater would bet on more than one block anyway, since we all know what the correct block during any round and its plies should be.

The point of this game is to make money, we lose money when we wager against the quorum, and the “only way” we can communicate is with wagers. Thus the optimum, and ideally only, strategy is for each player to initially wager an extremely small amount of their buy-in until it’s clear to that player the quorum agrees on the block. Then, to maximize profits, all of the participating players should wager their entire remaining buy-in on that block.

So far it appears that even a malicious actor would be a fool to vote against what they know should be the correct block. This is because I have not explained that the blocks contain information about financial transactions. The challenge in designing this game is proving that the players will always use the optimal strategy, if, for all of the blocks in the round, the sum of the value of the transactions in a block is less than the total initial buy-in.

Mitigations and Conclusions

Within the larger context of a blockchain we can apply further restrictions to make this challenge easier, for example, we can automatically reject any transaction that is obviously for more than the total initial buy-in. But the whole purpose of this system is to underwrite/insure network extrinsic value so there is always a risk that a transaction will contain greater value than the total initial buy-in, in which case there is an incentive for some number of the players to cheat.

Using Casper we will be able to blame and punish those cheaters. Depending on various externalities, we may also be able to blame and punish these cheaters in some greater context, but given the pseudonymous nature of the game, our ability to do so is severely constrained.