In Casper FFG, to finalize a checkpoint, it needs to get >2/3 votes.
What will happen if two checkpoints (of the same height) each get voted by >1/3 of the validators (by deposit)? In this case, no checkpoint would get >2/3 votes.
In Casper FFG, to finalize a checkpoint, it needs to get >2/3 votes.
What will happen if two checkpoints (of the same height) each get voted by >1/3 of the validators (by deposit)? In this case, no checkpoint would get >2/3 votes.
Neither checkpoint would be finalized, as you say, but one of their descendants could be finalized later on.
As an example, given this checkpoint structure
b – d
/
a
\
c – e
Say a
is finalized. If the votes are split 50/50 between a → c
and a → c
, then neither will be finalized. But later on, there could be a supermajority vote for a → d
, finalizing d
. Then b
would be “effectively final”, since any branch conflicting with b
would also conflict with d
.
In order to get supermajority vote for a → d
, some of the voters for a → c
would have to switch to vote for a → d
; these voters would lose their staking rewards in the branch a → c
.
Either voters for a → b
switch or voters for a → c
switch, but both are not incentivized to do so.
Interesting question, especially given the design goal of Casper to the WW3-proof.
Actually, validators voting for a → d
after a → c
will not get slashed, so it is ok. (You only get slashed for conflicting votes at the same height or skipping over your previous votes, both of which would not be happening here)
Thats one of the weaknesses … Theoretically this could go on forever unless someone runs a binary consensus protocol to select one of the two trees …
I agree with Dankrad – switching branches isn’t necessarily slashable. In this case it’s not since the source of each vote is the same (a
).
@kladkogex technically most consensus protocols could go on forever, right? (Excluding protocols which assume full synchrony or tolerate zero faults.) Although granted, Casper could be particularly slow in practice since it essentially runs one step of a consensus algorithm at each checkpoint.
Ah I see. Well the spec says that validators should use LMD GHOST as their fork choice rule. Validators could ignore that and follow the branch that they had accumulated more rewards on, but wouldn’t that be a suboptimal strategy since nobody would receive rewards if consensus gets stuck? Whereas if a validator switches branches, at least their second vote would be rewarded.
From a game theoretic perspective, it seems like the strategy of not switching branches after a 50/50 split would be a Nash equilibrium, since no single player could change the outcome; consensus would get stuck regardless. But that equilibrium would have a payoff of zero, so the equilibrium where everyone follows LMD GHOST would be payoff dominant.
Yes, the worst case can go forever, but the average time is bounded.
Here the average time can be unbounded . If the attacker has full info about the network, the attacker can make the thing stuck forever.