<p>In classic PoS there was a block &quot;drift&quot; consensus element that was needed to help properly order blocks.</p>
<p>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.</p>
<p>Block &quot;a&quot; being at time &quot;t&quot; while block &quot;a + 1&quot; is at time &quot;t - 1&quot; 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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-12-06T06:53:26.403Z
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.
Stanislav Zhdanovich
CC BY-SA 4.0
2021-12-07T10:12:19.513Z
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
CC BY-SA 4.0
2021-12-02T16:36:56.397Z
2021-12-02T16:36:56.397Z
Scalextrix
<p>Having an internal clock greatly reduces the overhead for block propagation, as it would allow for a more forward, almost &quot;UDP&quot;-like, block stream. Nodes are then able to order blocks locally, rather than having to wait for sequential sharing of blocks.</p>
<p>The Ouroboros Chronos paper was submitted in July of 2019. <a href="https://eprint.iacr.org/2019/838.pdf" rel="nofollow noreferrer">https://eprint.iacr.org/2019/838.pdf</a></p>
<p>Solana Proof of History went live on Mainnet Beta mid-2020.</p>
<p>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.</p>

CC BY-SA 4.0
2021-11-26T17:56:48.693Z
2021-12-24T23:15:10.723Z
2021-12-24T23:15:10.723Z
zhekson
<p>Which problem is solved if the time is synchronized between nodes?</p>
<p>I know of two protocols which implement time synchronization: Ouroboros Chronos and Proof-of-History, how do they differ?</p>

<proof-of-stake><ouroboros><proof-of-history>
Why Ouroboros Chronos and Proof-of-History need synchronization of time?
# Why Ouroboros Chronos and Proof-of-History need synchronization of time?

(Asked by: username_0 on 2021-11-26)

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?

**Tags:** proof-of-stake, ouroboros, proof-of-history

---

## 2 answers

### Answer by username_2 on 2021-11-26. Score: 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.


---

### Answer by username_1 on 2021-12-02. Score: 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.

> **Comments:**
> **username_0**: 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.  
> **username_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.  

---

