Why Ouroboros Chronos and Proof-of-History need synchronization of time?

Question

Which problem is solved if the time is synchronized between nodes?

I know of two protocols which implement time synchronization: Ouroboros Chronos and Proof-of-History, how do they differ?

Answer 1

Having an internal clock greatly reduces the overhead for block propagation, as it would allow for a more forward, almost "UDP"-like, block stream. Nodes are then able to order blocks locally, rather than having to wait for sequential sharing of blocks.

The Ouroboros Chronos paper was submitted in July of 2019. https://eprint.iacr.org/2019/838.pdf

Solana Proof of History went live on Mainnet Beta mid-2020.

In my limited (non-PhD) understanding, both allow for the aforementioned internal clock, but are designed for completely different ledger styles (UTXO vs Accounts). Both allow for great increases in block-prop time.

Answer 2

In classic PoS there was a block "drift" consensus element that was needed to help properly order blocks.

A block-chain can be viewed as a set of sequential time-stamps moving from the past to the future, but if the nodes making the blocks dont have synchronized clocks time stamps can be out of order.

Block "a" being at time "t" while block "a + 1" is at time "t - 1" is tricky to manage, especially if people might try to front run or pre-compute valid block-hashes to create forks. Like I said there was often a +/- drift factor and if block timestamps were outside of that the block might be rejected. Blocks with inverse timestamps could have odd effects like messing up block difficulty Targets and make the chain run too fast or too slow etc.

I dont know Ouroboros well enough to know how critical time is, but its a really good thing to have consensus over ordering of blocks and transactions, and this becomes especially important where blocks are potentially coming every few seconds or even less.