Update PROPOSER_SCORE_BOOST to 40 percent

[casparschwa]

PR up for review until May 20

An off-by-one mistake in #2888 led to a reconsideration of the PROPOSER_SCORE_BOOST parameter. This PR updates the parameter to 40%.

The motivation for changing this parameter and arguments for picking the new value can be found here.

[djrtwo]

Leaving this up for review until at least May 20

[terencechain]

Is this update reflected in any of the fork choice spec tests?
That means a test would fail if someone forgets to update 70 -> 40

[potuz]

There are some comments in the document that I don't understand, most probably I am getting this wrong, but anyway, since I started to review here decided to post while I read.

the sandwich is really just an ex-post reorg, which can be done by a minority adversary by abusing boost. The condition is then W_PB > 1 - β

I believe the inequality here is inverted: W_PB is applied to the attacking block and we would want to bound it above. Further in this paragraph

the additional β from the formula above does not apply because it would come from the honest slot and the adversary does not yet have a block to vote for

I believe this β does apply: the attacker releases his block and attestations at N+1 and the proposer of N+2 is is required to account for these attestations before proposing his block therefore the weight of N+1 is W_PB + β and that of N is 1 - β so that we require W_PB < 1 - 2 β, making the general formula in the article W_PB < 1 - (l+1) β valid in all cases l \geq 1.

Using this the intersection point in your graph moves from (1/2,1/2) to (1/3,1/3) so that the optimal point for l=1 is 1/3.

[mkalinin]

I believe this β does apply: the attacker releases his block and attestations at N+1 and the proposer of N+2 is is required to account for these attestations before proposing his block therefore the weight of N+1 is W_PB + β

I am curious about the intention behind the change introduced in this PR #2878. If on_tick happens before the moment when proposer computes the head for its proposal then proposer boost from the previous slot is reset thus not impacting the head computation that a current slot proposer is performing to obtain the head. If on_tick happens after then it's not clear how attestations from the previous slot could be applied (they couldn't because attestation slot is checked against the current slot in the store which is advanced by on_tick) So, my guess is the former but I think the honest validator spec should be more explicit about it.

[potuz]

I am curious about the intention behind the change introduced in this PR #2878. If on_tick happens before the moment when proposer computes the head for its proposal then proposer boost from the previous slot is reset thus not impacting the head computation that a current slot proposer is performing to obtain the head.

Ah ok I think I understand my confusion above: After the attacker's block comes in in N+1 and during that slot, before the proposer of N+2 comes in, it will have W_PB only while N will have 1 - \beta. W_PB is then irrelevant in N+2 for proposals. Ok, I see that then the tradeoff that I pointed in R&D does not really exist.

[fradamt]

I believe the inequality here is inverted: W_PB is applied to the attacking block and we would want to bound it above. Further in this paragraph

Yes, I corrected it. That inequality was what the attacker needs, but everywhere else we wrote security conditions instead

I believe this β does apply: the attacker releases his block and attestations at N+1 and the proposer of N+2 is is required to account for these attestations before proposing his block therefore the weight of N+1 is W_PB + β and that of N is 1 - β so that we require W_PB < 1 - 2 β, making the general formula in the article W_PB < 1 - (l+1) β valid in all cases l \geq 1.

Ah ok I think I understand my confusion above: After the attacker's block comes in in N+1 and during that slot, before the proposer of N+2 comes in, it will have W_PB only while N will have 1 - \beta. W_PB is then irrelevant in N+2 for proposals. Ok, I see that then the tradeoff that I pointed in R&D does not really exist.

Yes, exactly. This is the case for sandwich reorgs for any l: the adversary needs to do the reorg before attestations in their final slot are made, if not the honest slot will gain another 1-beta while they only gain beta

Just to be fully clear, when we said that “the additional beta” does not count, we meant the beta from slot N (the honest slot, if I understand you correctly). This is the case because there is no block which these attestations can be anchored to, in a way which helps the adversary (because they don’t control slot N-1). It really only applies to l=1: for l > 1 the adversary gets a beta for every “ex-ante slot”, plus a beta for the honest slot, which is what goes missing for l=1

[adiasg]

One weak point in the analysis is whether the attacker's strategy for the balancing attack is optimal. The outlined strategy seems reasonable, but whether it is indeed optimal is an open question to me.

That said, 40% seems like the most suitable value.

[casparschwa]

One weak point in the analysis is whether the attacker's strategy for the balancing attack is optimal. The outlined strategy seems reasonable, but whether it is indeed optimal is an open question to me.

You are right in that the inequality we use in the anaylsis $((1-\beta)W_{PB}-\beta(1+W_{WPB})&gt;0)$ is not a strategy as such, but a condition that needs to hold to be protected against balancing attacks in expectation. In other words, the inequality does not account for "favorable starting conditions" for the adversary (i.e. adversary was able to save up votes by being proposer of $l$ blocks in a row). But the inequality says that even given favorable attacking conditions the adversary eventually will run out of votes.

The intuition for why this might be sufficient is the following: Balancing attacks are dangerous if you get to delay finality, but over a long enough time horizon this won't be possible (assuming inequality holds). Short-term balancing in itself is not particularly useful to an adversary, unless it allows them to do longer ex ante reorgs (see section 5 in our paper for longer ex ante reorgs using balancing strategies). But we are already accounting for the worst case (1-block ex ante reorg), for wich balancing is not even helpful!

[fradamt]

One weak point in the analysis is whether the attacker's strategy for the balancing attack is optimal. The outlined strategy seems reasonable, but whether it is indeed optimal is an open question to me.

To add to what Caspar said, here I (more) formally analyze the balancing condition. In the document the protocol is committee-ghost with (an idealized) proposer view merge (instead of boost) and without LMD, but I think that the ideas there are mostly applicable to our protocol. Boost makes things worse but in a manageable way, and LMD also makes things worse, but can be dealt with with different ideas and mild assumptions on what the adversary can do.

Anyway, this is just meant to give us some confidence that, if the adversary wants to maintain balancing as long as possible, they can’t really do better than just immediately using their saved up attestations during a honest slot, to keep the balancing going (by beating boost, or simply restoring balancing after honest voters have voted together), so that they can (for free) save up attestations during adversarial slots. The balancing condition says that this strategy eventually fails, because the adversary has to use up more attestations than they have, in expectation, and the document just tries to show that every other strategy would fail for the same reason

[djrtwo]

I believe we've had (positive) review from all those who follow this problem in detail.

I'm merging and getting this out in the Bellatrix release candidate