Thoughts on Ouroboros Chronos

I spent a little bit of time to understand the new Ouroboros Chronos paper today (not a detailed review, just a cursory glance). I just wanted to share some food for thought around it.

For those who don’t know, our consensus mechanism is based off of Ouroboros Praos, with some extended rules to add similar long fork protection as Ouroboros Genesis in a succinct manner. Ouroboros Chronos is a new consensus mechanism which was published by IOHK recently, and it is an extension of Ouroboros Genesis. The main addition in Ouroboros Chronos is that it no longer requires nodes to all have access to a global clock in order for the network to remain synchronized, and instead, the nodes on the network can synchronize the network’s clock by analyzing blocks they receive over time. This means that one can use Ouroboros Chronos to build blockchain protocols that do not rely on a centralized service for time synchronization, such as NTP, in order to participate on the network.

This is very nice feature, but in order to achieve it, there is a good deal of added complexity to the consensus mechanism. I haven’t analyzed the paper fully yet, but it does appear as though this would also have a constant impact on bootstrapping time, even if you have recently persisted state from the network available at client initialization. However, I think the basis it provides of having a network wide synchronized time step in a permissionless system could actually be pretty useful. In theory, it would allow for another consensus layer to be built on top of Ouroboros Chronos that could take advantage of this property and potentially create a less wasteful, stronger proof of stake consensus mechanism. This could be of particular interest for us since we incur a very long block finalization time due to our large slot windows.

Basically, Ouroboros gives very good properties in regards to security, but creates an environment in which blocks are often wasted and finalization is very slow. This slow finalization gets amplified greatly by our long slot windows. If a more efficient consensus mechanism could be implemented as a second layer on top of Ouroboros Chronos using the new network synchronization properties that are available, it could (in theory) be possible to split our currency blockchain out into this second layer. This would mean that the first consensus mechanism layer could have extremely short slot windows since it wouldn’t require (or would require dramatically less) snark work to generate a block on that chain. The first chain would merely be used for time synchronization, but stake distribution and incentives would be controlled by the second chain.

Under this model, it might be a little bit tricky to determine how to handle chain incentives on the Ouroboros Chronos chain (since, in order to keep the slot windows small, we aren’t producing snarks for each block on that chain), but one potential way to handle this would be to have the primary blockchain periodically run a lottery on a range blocks in the Ouroboros Chronos chain and only award stake to one of those block producers. That would keep the required number of required constraints in the primary chain’s snark realistically small (though still very large).

This is far from a fully fleshed out concept, but I think it’s an interesting thing that we could think about and consider as a future solution to optimizing our blockchain. Future work towards this direction would be researching permissioned distributed protocols and seeing various systems that have been implemented on top of the assumption of trustable time synchronization to see what would be in the realm of possibility for implementing a more efficient consensus mechanism with this property.

1 Like