1

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?

2 Answers 2

3

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.

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.

2
  • Doesn't Ouroboros (Ouroboros Genesis and Ouroboros Praos) already have a consensus mechanism for ordering of blocks in a form of slot number? As I understand each newly produced block has a slot number, which acts as a timestamp. Dec 6, 2021 at 6:53
  • 1
    A slot is every one second. So if my clock and your clock are running at slightly different speeds, after some time we may disagree what slot it is now. This could result in the node with the faster clock, creating a block at a future time from the relative perspective of the node with the slower clock. Or the reverse where a block is created in a slot before a block that comes after it. Does that really cause a problem, Im not sure, but avoiding it seems like a benefit.
    – Scalextrix
    Dec 7, 2021 at 10:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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