TLDR: There exist a financial incentive for the execution payload to be proposed later than the anticipated time window for it. We worry that this might lead to favoring larger validators, encourage attester bribing infrastructure and might contribute to making consensus attacks described in recent papers more likely.

Context:
The beacon chain has slots. A slot is currently every 12s. Within this slot exists an execution chain block as well as consensus objects. While there is theoretically (12s-epsilon) time to put the beacon block together within the slot, there are actually sub-slots within this slot that are softly enforced by consensus clients. These sub-slots are necessary in order to account for propagation time (incl. network delays) to attesters and for the proper construction of a beacon block.

Afaik - an execution chain block is supposed to be proposed in the first 4s of the 12s slot. This gives 8s for it to be voted on by attesters and in MEV-Boost, leaves enough for the body to be revealed by the end of the slot. For eg. see waitToOneThirdOrValidBlock() in Prysm's client here: https://github.com/prysmaticlabs/prysm/blob/8c8f1bb9c18ebbc42241848a328ed275b12587e5/validator/client/attest.go#L250 (thanks @terencechain )

Worry 1: Late execution block proposals:
In theory, the proposer has until 12s-epsilon to submit a beacon block. This means the execution chain block could be constructed maybe at 11s rather than 4s in. This time difference means the builder would have an additional 7s to construct a block. In those 7s, new transactions could’ve come in and made the block more profitable.

The proposer and builders now have an incentive to delay the block submission as much as possible.

This is problematic because:

• a proposer that controls a lot of validators can inherently force them to vote later (by modifying their consensus client source codes) vs a solo validator. This means there is an advantage to controlling a lot of validators that are well-connected to the p2p network.
• another flavor of this problem is that there might exist an incentive to bribe attesters in order to delay their attestations.

Questions:

1. on average, how much more profitable are blocks after X seconds from Flashbots data? This will help us understand how big of an advantage would larger validators get.
2. what is the technical complexity of either bribing attesters and making sure the attesters attest later than expected?
3. what is the financial risk encountered by doing this (later attestations get less rewards + there is a risk of missing the slot afaik which would incur a slashing penalty)? can we surface and calculate the expected value of doing this?
4. Given this information, how expensive would it be to bribe attesters?

The good news is that we have numbers to quantify this, in particular, Flashbots finds that on average, each additional second of waiting is worth 0.034 eth in additional miner payment (incl. 1559 tips). The outlier numbers we have (top 0.1% of blocks excluding tips - only bundle payments) are around 1 eth/s (thx @metachris and @Ruteri ). These numbers generally seem too small for this worry to be relevant.

The bad news is that this quantification is imperfect. In particular, if someone can delay their ultimate proposal to a few seconds later, they are able to do cross-domain arbitrage with low-latency domains more effectively. Priced in, this might be worth large sums of money.

To-do:

• poll relevant parties (searchers who run these type of strategies) to understand what this could amount to for them.

Worry 2: Reorgs
Two papers (https://arxiv.org/pdf/2203.01315.pdf and https://eprint.iacr.org/2021/1413.pdf) were recently released detailing 5 attacks on PoS consensus (co-authored by @casparschwa @barnabemonnot et.al). One attack in particular relies on the timing of a block proposal.

We worry wether the financial incentives outlined above exert an upwards pressure on the likeliness of such a timing attack happening in the wild. I understand these attacks have been fixed and suspect this worry can be easily alleviated by @casparschwa sharing how these attacks were fixed.

We open the discussion here and look forward to your questions and comments :)!