Proof of Stake - Timeslots

English Education
,
1

In PoW several nodes compete to be elected. If n1 does not get elected eventually nX will be elected. So PoW does clearly not need such a concept of timeslots.

In PoS lets say a node gets elected via random election. If that node is byzantine we clearly need a mechanism to achieve liveness. Every PoS algorithm (including Ouroboros) that I’ve seen so far does introduce the concept of time-slots.

  1. How do nodes reach consensus about the current time?

  2. How does Ouroboros ensure that the time-source is not centralized?

  3. How does Ouroboros ensure that the time-source is in sync?

  4. How do you come to a consensus if a block was delivered in time? I mean even two non-byzantine nodes cannot possibly come to a consensus if an elected producer produced a block in time. Maybe n1 (honest) received the block in time and n2 (honest) has not received the block in time.

1 Like
2

When node is starting it compares your local time with a time-server and gives error if it’s differs for more than 20 seconds.

It does not

Currently, trust

Eventual consensus

6 Likes
3

He does not say a single word about this scenario, so the video does not answer the question where your answer was Eventual consensus. Can you please elaborate?

4

He did and it does.

How two bitcoin nodes can possibly come to a consensus if there are two blocks produced at the same time, and n1 (honest) receives one block and works on it and n2 (honest) receives another block and works on it?

5

In Bitcoin there are no timeslots. In Bitcoin a node does not reject a block if it was not delivered in time, because there are no timeslots in Bitcoin. In Bitcoin it doesen’t matter if the block came 2 seconds later, when it’s the only block that you received (you will build on it). In Ouroboros by rejecting the block you become dishonest from the point of an honest node who recieved the block in time (or from the point of view of who does the security analysis), because you rejected it and built a fork.

Ouroboros does not exactly resemble Bitcoin but with stake. It is something different. Bitcoin does not have the concept of a timeslot, you should not sweep that under the carpet. Note that I’m perfectly fine with what Cardano is building, I think it’s great, because such chaos-scenarios are highly unlikely in case the time-buffer is big enough.

Do timeslots in Cardano adjust somehow dynamically to network-size (if that is even possible)?

6

Building a fork is not considered a dishonest act, since it might be caused by network delays.

I don’t sweep anything under the carpet. You don’t understand how two nodes with a different view of a chain might reach an eventual consensus, and I provided a counter-example that might help you to understand it.

Do you understand how two nodes in bitcoin can possibly reach consensus if they build on two different blocks at the same time?

No.

7

afaik this 20-seconds per slot is one of the compromises they had to accept when defining certain values in Ouroboros. … who then get compared to the 0.5s of EOS, which seems very close to me, on what light speed around the globe with a couple of crypto-required handshake-steps will physically allow under perfect circumstances.
From my understanding Ouroboros does not assume and expect always perfect circumstances and clearly says: 20 seconds is what we probably require for a global decentralized, uncoordinated consensus in worst case scenarios (including unexpected behaviours like packet loss or out of time sync of single nodes).
It could turn out later that it can be tuned to 15 or 10 seconds and keeps still offering safe probabilities against unexpected situations or planned attacks.

2 Likes
8

Absolutely.

https://iohk.io/blog/on-the-ouroboros-design-how-rigour-and-engineering-are-essential-for-critical-infrastructure/

9

You brought up a totally different example. In my example we have one block and in your example we have 2 blocks at a certain height.

I do not say that they do not reach consensus under normal conditions. The scenarios that I mention are highly unlikely, but possible. My answer to your next statement goes more into detail.

Of course Ouroboros has a fork-choice rule, that is not the problem.

Ouroboros works in case the timeslots are big enough.

Problem is that the fault taulerance is not as high as in the mathematical proofs under certain conditions which are possible during the execution of the Ouroboros protocol. The “problem” arises when the timeslots do not have a huge enough buffer. There is a difference between a party that plans to act honest and an honest party in the execution of the protocol. In theory you assume 51% honest parites (parties that act honest in the execution of the protocol). Lets say 51% plan to act honestly and then the time-buffer is too small and some of them therefore become dishonest from the point of view of the security analysis. So in case the time-buffer is too small you need more the 51% parties who plan to act honestly. Mathematical proofs (including Ouroboros proofs) work with ‘honest parites (parties that act honest in the execution of the protocol)’ and not ‘parties who plan to act honestly’.

In my opinion Fault taulerance has two sides.

  • The proofs which involves honest parites (parties that act honest in the execution of the protocol)
  • The actual fault taulerance in the practical implementation. Parties who plan to act honestly can become dishonest in the execution of the protocol under certain practical protocol implementations.

This is the case in every protocol that is != PoW and has a speaker component (a speaker component demands timeslots). So whgen the protocol has a speaker component, the actual fault taulerance is actually lower then the FT in the proofs.

Note that I write “problem” under quotes, because I think in practice it is no showstopper.

Of course this is also the case in Bitcoin (a node can be faulty even when run by an honest party), but here in Ouroboros there is a contraint of a timeslot, which makes such scenarios more likely due to having this additional constraint. They are still unlikely.

I’m very interested in if you agree with that.

1 Like
10

Is there in your opinion a way to solve this centralization? I mean we must agree on some time in Ouroboros’ design and I guess it has to be a centralized source, right?

What happens when this source gets DOS attacked?

11

Of course I agree. You just described how network failing will break the consensus assumptions. What’s the problem?

20 second slot time is specifically selected as a “sanity” choice that is both long enough to ensure proper signal traversal in case of a fairly healthy overall (average) network and short enough to be 3rd-gen usable.

But that’s not the same thing as you were asking initially. You were saying: “two nodes cannot reach consensus if one of them did not get a block in time”. No, they can. And that’s not the same statement as you are saying now.

Now you are saying (if I understand it correctly): “If many nodes along the whole execution will fail to receive blocks - this will break the security proofs”. Yes. All proofs assume two things:

  1. More than 50% of nodes are honest
  2. More than 50% of slots are successfully filled with blocks

All security proofs, in my understanding, are based on these assumptions and only answer the question: “how we can run a secure network, given those two properties.”

The extreme case of this problem is when network gets bad enough (cut off, for example) so that majority of nodes, already selected for slots, are not reachable. This might happen in the case of a minority subnetwork being isolated due to some problems. For now, I cannot say, with enough certainty, what will happen with the subnetwork in this case, and I don’t want to lie.

If the subnetwork gets reattached before the end of the epoch - it just follows the fork-selection rule and switches to the main-network view (all local transactions in the time of the separation are lost). For example - the same thing will happen with the bitcoin, in such a case - subnetwork will just continue to mine “lighter” blocks, and when reattached - local chain will be replaced with the main view.

If epoch end happens during separation - it gets very much more complex and I don’t know enough details. Will be glad if someone can link some sources about it (or code).

P.S. Have you read “Ouroboros Praos”? I haven’t got to it yet, so I might miss some details, but it specifically called “semi-synchronous proof-of-stake protocol”. You might find some answers there.

I am not competent enough in a “time-server decentralisation” topic to have any credible opinion about this. I guess we can just use multiple independent global time providers. There are enough of those.

P.P.S. Next time please try to provide as much details with your question as possible from the beginning. The discussion looks like I’m trying to forcefully pull what you actually want to know out of you )

12

Those two problems are assumed in the Ouroboros itself (still not sure enough about Praos, might miss some details), cuz they are “epi-consensual”. These problems are not the part of the consensus mechanism itself, but rather they provide the “medium” in which the provable consensus is happening. This is my understanding.

This is why IOHK solve these problems separately. On one hand - you have Ouroboros-family papers that provide consensus proofs. On the other hand - you have Incentive papers (coming up) from Prof. Koutsoupias that ensure node honesty. On the third hand - you have network engineering that is by far more mundane than all the academic research, and that should provide the fair average network stability, or a stable recovery.

The network part is customisable and may be tweaked even after the network launch. So time-slots, delays, time-synchronisation, some engineering assumptions and approximations - they all may be changed later. The proofs are the hard part.

13

They do not reach consensus about that immidiatley in Ouroboros, but over time. That means you are right. It’s just weird, but that’s how most protocols work.

In Ouroboros we have one additional assumotion and that is the timeslot. My statement was that this makes network failure more likely even though it is highly unlikely that this makes a difference. I think we agree with that?

Not so far.

14

That’s what “Eventual consensus” means. Every blockchain system that I ever heard of, except “Algorand”, implements eventual consensus. Synchronised consensus is not practical, imo. (And apparently market is agreeing with me.)

So your main problem is with the time synchronisation between nodes?

15

Did you ever hear about http://www.pool.ntp.org/ ?
I mean that big virtual cluster of timeservers available as open source where everyone can join and become one of the currently ~4000 active reachable pool servers.

1 Like
16

Just that we speak the same language:

Ouroboros’ eventual consensus assumes that honest parties do not build on all forks right (this is part of the definition of an honest party on Ouroboros right)? They choose one fork and build on it.

Conclusion:

Since 2 honest parties cannot possibly come to a consensus (not eventual consensus, but immidiate consensus, which leads to inability to come to eventual consensus as I will point out) wheter a block was delivered in time or not they cannot know if the are building on the consensus-chain, which is a huge problem, because therefore they are incentiveced to build on every chain even if the incoming block which would form a the fork was from their point of view not delivered in time. So a block that would be the start of a fork could arrive 1 year later and every party is incentiviced to build on it, this is essentially what’s called as Nothing at Stake. You cannot come to a consensus when every honest party has to build on forks and they are incentiviced too, because they cannot know (no proof) if what they think is true (that the block was delivered in time or not). You could say hey after 1 year it should be clear to honest nodes that it was not delivered in time, but the same scenario will also accure about block that were closely deliverd to 1 year and it will go on indefenitely.

Of course you can say hey these are no honest parties when they build on something that was clearly not delivered in time, but as mentioned before there is no proof that it was not delivered in time, h1 may think it was h2 may think it was not.

So as a summary, because there is no immidiate consensus about wheter a block was deliver in time or not, every node (doesen’t matter if honest or dishonest) is incentiviced to build on all forks which is called as nothing at stake.

I’ve gone through that thread again and none of the answers (eventual consensus), resources or research papers does answer this question. Eventual consensus assumes that honest nodes to not build on every fork, but as mentioned every node in incentiviced to build on all forks, because there is no immidiate consensus about wheter a block was deliverd in time or not.

Btw Charles mentioned in a reddit post solutions to this problem, can you please explain them in more detail?