Joint document by Francesco and Caspar. We need to pick a proposer LMD score boost value, $W_{PB}$. Currently $W_{PB}$ is defined in the specs as PROPOSER_SCORE_BOOST: 70. General opinion is that this value is too high. On the one hand, you want the proposer boost to not be too high: The reason is that a high proposer boost enables an adversary to abuse it and do ex post reorgs or sandwich ex ante reorgs. Consider the following sandwich scenario: A 10%-adversary proposing block n and n+2 can reorg block n+1 despite the proposer boost, or in fact because of the proposer boost: 10% (adv. slot n votes) + 10% (adv. slot n+2 votes) + 70% ($W_{PB}$) = 90%, which is equal to honest weight voting for block n+1 (assuming all honest validators vote correctly etc.) On the other hand, you want proposer boost to be high enough to prevent "simple" ex ante reorgs and balancing attacks. So what is the right middle ground? Let's consider the trade off space.
9/21/2022Special thanks to Barnabé and Francesco for discussion and input. Background info A slot is 12 seconds long. The proposer is supposed to release their block at the beginning of it. The spec forsees the following schedule within a slot for an honest validator that is selected to attest: A validator should create and broadcast the attestation to the associated attestation subnet when either (a) the validator has received a valid block from the expected block proposer for the assigned slot or (b) 1 / 3 of the slot has transpired (4s into the slot) -- whichever comes first. Further,
5/12/2022As discussed here and more formally here, the current specifications of Proof-of-Stake Ethereum allow for reorgs to happen relatively easily. A mitigation must be found before The Merge. There are several and open/closed PRs (#1, #2, #3, ...) floating around, but nothing definite yet. This note tries to keep track of various different ideas to mitigate these ex ante reorgs and also why some ideas have been discarded already. Idea 1 - (block, slot)-voting What is (block, slot)-voting? The core idea of (block, slot)-voting is to have honest committee members attest to an empty slot, if they do not see a timely proposal. Currently attestor would attest to the latest block as current head of the chain. It is specified here and described by Vitalik here. At its core this would allow validators to vote for empty slots (if they don't hear a proposal). Why would it help mitigate reorgs? This would prevent reorgs from working (or at least being practically feasible), because the adversary's blocks would not inherit the weight of honest attestations. They would instead accrue to the empty slot, which is in competition with the adversary's privately kept block. Hence, the adversary would compete with all honest committee members.
10/14/2021Flashbot Auction's life cycle Flashbots Auction (will call it Flashbots from here on) provides a private communication channel between Ethereum users and miners for communicating preferred transaction order within a block. Why? For MEV, the normal tx pool has drawbacks $\rightarrow$ gas war + wasted block space + no granular tx ordering possible Flashbots provides a private transaction pool + a sealed bid blockspace auction mechanism which allows block producers to trustlessly outsource the work of finding optimal block construction + reducing negative externalities Architecture overview They are sending Flashbots bundles around...
8/4/2021