One key way in which eth2’s fork choice differs from that of eth1, as well as “chain-based” PoS algorithms (eg. older algorithms like Peercoin and NXT, but also newer ones like Tezos, Ouroboros…) is that in eth2, there are many messages affecting the “score” of a block arriving in parallel.
Chain-based algorithms are easier to prove liveness for (and indeed, in some cases liveness has been proven), because there is generally a single actor acting at one time, allowing them to act as a “coordinating bottleneck” getting everyone to agree on the same score.
Here is a “strawman proof sketch” for liveness in chain-based algorithms.
Suppose that:
We model the time during which nodes receive a message sent at time t as a “cloud” in the interval (t,t+δ) (so far, this is just stating the standard academic presentation of a synchrony assumption). Thus there are two cases:
Notice that the disagreement case happens only when the participant in slot N is dishonest. Hence, if the participant assigned to some given slot is honest, then either (i) at the end of that slot everyone agrees what the correct chain is, because they are calculating the fork choice based on the same information, or (ii) the attacker “used up” some saved participation rights from an even earlier slot in which they did not participate. Hence, a disruption can only continue if the attacker has at least one saved participation right per honest participant, ie. if the attacker is assigned to more slots than honest nodes (ie. the honest majority assumption is violated).
Now, let’s look at the “many parallel attestations” case. In the case where there are many parallel attestations that contribute to the score of a block, there is no single actor that creates a bottleneck in this way. Hence, an attacker could manipulate the network (plus strategically broadcast a few of their own validators) in such a way as to create a state of disagreement at the end of each slot about which messages count toward the fork choice, and therefore which of multiple chains is the winning chain.
See here, particularly pages 4-5, for an exposition of this kind of attack. Note that this attack does depend on networking assumptions that are highly contrived in practice (the attacker having fine-grained control over latencies of individual validators), but nevertheless a protocol that is secure against such attacks is better than one that is not.
The proposed solution is to introduce an explicit “synchronization bottleneck” gadget into the fork choice. In particular, we add the following rules:
(Note: for ease of analysis, we pretend that clocks are perfectly synchronous, and that any actual clock disparity is part of the network delay)
At the end of slot N, all validators have received some set of attestations. If there is an attack going on (ie. there were k≥1 malicious attesters that revealed attestations during slot N), the validators will likely disagree on the score of each block. But the range of their disagreement will be bounded-above by k. Suppose (without loss of generality) that there are two competing blocks, A and B, and A “wins” if score(A)−score(B)≥0 and otherwise B wins. The range of disagreement in score(A)−score(B) will be bounded above by 2k (ie. each validator’s opinion on the value score(A)−score(B) will be in some range [z,z+2k] for a fixed z)
Let Wp be the weight of the proposer (Wp=W4 in the exposition above). If the proposer is honest, they are guaranteed to follow two behaviors:
Let [z,z+2k] be the range of disagreement on score(A)−score(B). We distinguish three cases:
In case (1), the proposer wil vote for B, and so attesters will see adjusted scores in the range [z−Wp,z+2k−Wp]; this entire range is negative, and so there is full agreement on B.
In case (3), the proposer will vote for A, and so attesters will see adjusted scores in the range [z+Wp,z+2k+Wp]; this entire range is positive, and so there is full agreement on A.
In case (2), effectively the proposer decides. Depending on where in the range the proposer’s own opinion falls, either the proposer favors A or B. Hence, the range will be either (i) [z−Wp,z+2k−Wp] or (ii) [z+Wp,z+2k+Wp].
Consider the case where Wp≥2k. Note that from the definition of case (2), −2k≤z<0 In case (2.i), z<0 and 2k−Wp≤0, so the upper end of the range z+2k−Wp is negative, so the entire range is negative. In case (2.ii), z>−2k and Wp≥2k, so z+Wp>0, so the entire range is positive. Hence, there is full agreement on either A or B, depending on the proposer’s pick.
Now, let’s get back to the exposition, where Wp=W4. To prevent the proposer synchronization bottleneck from working, the key premise in the above reasoning that Wp≥2k must be broken; hence, there must be >W4 attesters that reveal themselves during each slot.
If the proposer synchronization bottleneck works during any single slot, all honest attesters will vote in that direction, further pushing score(A)−score(B) away from zero. To prevent one side or the other from winning at this point, the attacker must reveal enough attestations to counteract all honest validators during that slot (minus 14 to counteract the loss of the proposer vote’s efficacy at the end of the slot); this will take much more than W4 attestations.
Hence, maintaining a persistent liveness break requires at least W4 malicious validators per slot, or ≥14 of validators to be dishonest.