Casper FFG with one message type, and simpler fork choice rule

Subject: Casper FFG with one message type. Keep source hash?

There are currently two designs for the “Vote” message in Casper. They are:

40

My understanding of the benefit of the Vote message with only three parts (the lower one) is simply that, “it uses less space”. Space efficiency is good, so in principle, :+1: .

However, given that the checkpoint-tree is an Arborescent tree, we could simplify this even further by simplying specifying the source and target checkpoint hashes. Validators can then compute the length (epoch/checkpoint depth) of the source and target checkpoints on the fly, and cache any results.

I mentioned this to Vitalik, and his response was roughly: “Keeping tracking of depths of the source and target of every supermajority link, for every validator, is too high a memory burden for detecting slashing condition violations.” This makes a lot of intuitive sense. But with a mind for greater efficiency, my question becomes:

How necessary is it that every validator immediately know when a slashing condition has been violated (before the evidence transaction)? Because if a validator merely needs to update when it learns slashing condition evidence—then we can further reduce the size of the vote message to simply the two hashs (or alternatively, the epoch-depth of the source checkpoint, and the hash of the target checkpoint).