Timekeeping idea

This is fully based on @000’s ingenious revelation about timekeeping.

A network-wide clock at the expense of 8 extra bytes in the message headers.
And another 8 bytes for in-group messages, and the same for our list of close group members.

The idea of timekeeping came up multiple times, but it was deemed impossible without having to rely on external references. For most practical purposes*, however, it would be enough to establish the order of events. I believe we may achieve this entirely within the network by exploiting that information can propagate through the network only with a finite speed.

The method I’m proposing is very simple:

  • Network messages will have a field for the time, which is a simple counter.
  • When a node receives a message from outside its close group, it will update its idea of the current time.
    • This is not the time the node uses when sending a message; that is coming from the close group’s agreement, for which its idea of time is used as one of the inputs.
  • When a node sends a message, it will send the time that its close group decided based on these rules:
    • When more than half of the nodes agree on the time, all nodes in the group start using it.
    • When an actual quorum is achieved, the time is incremented.

I think this method will provide a way to establish an approximate order of events, with higher and higher reliability as the difference between two timestamps grows. It would be lovely to run an actual simulation though.


* What these purposes should be is outside the scope of this post.

4 Likes

I haven’t woken up yet but perhaps that falls in to what data chains would be and timestamping relative to a data chain would allow for consensus on when something occurred.

2 Likes

It’s much simpler than data chains. It’s just a network-wide clock at the expense of 8 extra bytes in the message headers.

It would be a pretty fast ticking clock, too; its speed would depend on how fast the tick information could saturate the network. As such, it could double as a sort of measurement tool for the current network speed.

3 Likes

If you need quorum, you need a lot of messages between the nodes of the group to achieve this quorum.

The DataChain, for example using the links, seem a much more easy and simple solution.

1 Like

Not necessarily. It’s an application where we don’t need to strive for a quorum; it’s perfectly fine to wait until it is achieved as a side-effect of the regular message flow. (Basically, we don’t need to use the official quorum mechanism, because something simple and slow will do as well.)

Messages to group members should have another 8-byte integer field to send their idea about what the time should be; it’s not the same number that they send as the actual time filed, but what they think it should be. This time is based on the messages they received from outside the group.

Every node should maintain a table for the nodes in its close group to keep track of what others in the group think the time should be. This table is updated opportunistically: whenever the node gets a message from another node in its close group. Therefore, we don’t need extra messages.

When the node sees that more than half of its close group thinks the time should be N, it starts using N for its time field. When all but 2 nodes think the time is at least N, the node starts using N+1.

Could you explain how this voting on the time within a group leads to a network-wide consensus on the time?

I don’t follow that explanation. And what is “all groups”? There is no roster of all the groups.

Maybe @Tim87 could give me an explanation of the idea. This forum is turning into an indigestible firehose.

I’m was not asking for an explanation of how the in-group consensus is to be achieved. I am asking how this mechanism propagates across the network to achieve a common network time. That is necessary because it is implied by the concept that the order of events is what matters, and such a ranking of events will, over a long enough period, include any pair of nodes in the total network.

No common time, no virtual clock: the network is not permanently segregated into groups. The groups continually swap out members, and the new members might come from anywhere. Those new members have a store of data of all kinds, including data about data. How is this to be incorporated into the ranking using this “low resolution clock”?

Whoa what happened here while I was having my mid-morning / afternoon / late evening / etc nap? :scream_cat:

It’s really not as complicated as most responses in this thread make it to be.
For one, no SD or any other blocks are involved, and neither are extra messages.

We just need to keep track of a number for each of our close group buddies, send the time in every message (this is what we as a group think, based on 2 simple rules), and send another number only in the messages that are directed to our group buddies (this should contain what we think the outside world thinks about the time, from the messages that we received from outside). This is the part where the world meets the group.

This whole thing is based on that we have a randomly connected graph, where all nodes are “close” – that is, within a few hops. As a result, we can expect that there will be a chain of messages between any two nodes very often (not as a part of communication between those two nodes, but as segments from communication between other nodes.)

Therefore, I think we can trust that a single counter (with group consensus as filter / regularizer / break, forming opportunistically as regular messages travel around) can ripple through the network fast enough that it can be useful as a timekeeping mechanism.

I may try to simulate it to verify and demonstrate the idea.

1 Like

Yes, it’s mine. I hope you get the idea :smirk_cat: << EDIT: CAT EMOJI ADDED

I have proof people make it into something super complex though I already said the same things above, much simpler.

How have I “made it super complex”? I haven’t received a lucid explanation for how the proposed mechanism is a substitute for a system-wide clock, or how timestamping is to be done throughout the network without such a system-wide clock.