this is rather a simple and fundamental question but nevertheless i couldn't find any solution for it and now I'm worried if it can cause real attacks to slow blockchains.

imagine in a form of committee some users are chosen to propose blocks. for some reason this committee stalls to send the blocks to the rest of the network just until a few milliseconds before the time window is ended. for the few nodes near them, the blocks are sent in the right time window but for the rest of the network they received the block after the window is ended. now we have a situation where some nodes say this block is valid and propagated in the tight time span but some users saying otherwise because they received a block in an invalid time. therefore to overcome this issue one way that comes to mind is to stall the rest of the network and accept the late delivered block in which case the network can be easily slowed down constantly. is there any point I'm missing here or is this a real concern? how is it that ethereum claims this would not happen in its network once a peer asks a trusted source (weakly subjective)?

also this problem in tron is refereed to as temporary fork. so in a simpler manner how does the network recover from temporary forks due to partitioning and keeping the finality of the transactions happened in both forks as they propose they do?

  • Why do you imply there is a good and bad time to distribute a block ? Sep 1, 2021 at 10:57
  • if im right it was told in the documentation of ethereum 2.0 that for every validator in prrof of stake there is a time window for them to submit a block. Sep 1, 2021 at 12:38
  • Also the same problem occurs in tron as temporary forks Sep 1, 2021 at 13:04
  • I believe that the validity is given by the timestamp of the submission moment, not the time when the nodes receive the block
    – Stormsson
    Sep 1, 2021 at 13:57
  • if so even worse since someone can just forge the time span. Sep 1, 2021 at 20:29

1 Answer 1


Good question, what happens when blocks are published with a delay?

First, you seem to think that delayed blocks aren't valid anymore which isn't the case. Late received blocks remain valid blocks. However, you're right that this delay changes the way the validator receiving the block sees this block. There is a change in how the block is perceived because of proposer boost.

Before the proposer boost update proposed by Vitalik here, there wasn't a difference between blocks received on time and received late.

So let us focus on the mechanism to handle network's delay of block propagation without the somewhat involved proposer boost. In this case, your question is one of the paramount question of distributed systems: how can we reach a consensus if different processes view different states? To this question, Bitcoin answer's was the Nakamoto consensus: the longest chain rule. Ethereum 2.0 has chosen LMD-GHOST as fork choice rule.

To sum up, in every blockchain delay can cause forks, the solution to that is to define a fork choice rule that every validator/process will use to determine the correct chain.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.