Ghosted Blocks - How to optimize Propagation Times - Action Required

[Markus-VITAL]

Hi @7.4d4 !

@7.4d4

The correction I would like to make is in terms of how the protocol resolves which fork (block) is accepted. If we assume that the fork is only 1 block high when each node receives the two alternatives, then in both cases the protocol resolves the issue by picking the block with the lowest VRF score .

Now this can change if one of the forks gets added onto by another pool’s block before the majority of nodes receive the other fork. In that case the longest chain wins rule applies.

In other words, assuming that the block received last (or with the later slot) will be the one orphaned is not correct.

Thanks for the correction! My understanding back at that time was not 100% complete
We had a similar chat over there: Understand the Risk of Slot Battles and Ghosted Blocks which I think already brought us on the same page.

So for everyone catching up here. Please take a look on the other thread as well. It might be interesting for you to understand the current impact of propagation times.

@7.4d4

IOG are on a mission to increase the data throughput of the chain and they seem to be intent on “spending” that 5 second propagation delay budget. I think this means that propagation times are going to increase until we are pushing towards this 5s limit. So, I guess we need to prepare ourselves for more “propagation delay battles”.

Hopefully, “input endorsers” will fix this.

I really hope that pipelining and input endorsers will drastically reduce “the problem”