Eventually consistent global counter ("SafeTime")

Each section is processing its own events at the rate required for the events it has to do. Section #1234 might be completing 100 events per second but section #1235 might be completing 20 events per second and section #1236 might be completing 5 events per second at a particular point in time.

So there is no correlation between sections and their internal events.

While nodes in a section can be talking to other nodes (hopping chunks etc) there is no way to correlate event “counters” nor is it desirable as once you have 100 sections then there is 100*99/2 (4950) communications between sections to try and correlate event “counts” As one pair correlate they change between their neighbours. You get the idea, the network would be weighed down trying to have a global event “count” because it would be out of sync before you get a few neighbours away.

The solution to that would be a centralisation of event “counters”, but then that centralisation of a function, then there would be calls for centralisation of other functions. Even one function centralised means you do not truly have a autonomous decentralised network. You would have a autonomous partly centralised/decentralised network, with a significant amount of traffic to attempt to have a central event “counter”

The reason for mentioning NTP servers is not to bridge between SAFE and them, but rather to have dedicated time authorities on the network. This is how the current internet solved the time sync issue and is a reasonable way, since it is how all time pieces are synced in the non-internet world. There are time “authorities” that keep super accurate time and sync with each other.

This syncing of the time “authorities” is a complex task and requires there to be a minimal number of them, and the sync is not a internet dependent operation (even though they may use it as a transport layer now-a-days). Similar to the reason why a “centralised” event “counter” on SAFE would fail since there are too many sections to sync.

Thus my suggestion of the time “authorities” having time authoritative machines on the SAFE network is to provide for those people who cannot for whatever reason decide on a timestamp for themselves. The idea is that the piece of data that needs securing is hashed and that hash is sent by secure messaging to the time machine to be timestamped with the ID of the authoritative time machine and returned by secure messaging. Obviously there has to be a public declaration of these authoritative time machines so that any time stamp can be reliably authenticated.

This removes the need for a global event counter and provides for time to be included in the temporal stamping of data. Linux event counters are often the time (secs since epoc)

How that is paid for is to be determined but I can already think of a few and that would allow the authorities to recoup some of the costs where it current is not being done.

Well I am saying that I cannot see how it can be done in a economical (network traffic/coding) way. And why I offered an alternative that actually provides the required functionality and will actually be implemented anyhow if SAFE takes off. Like GPS helps anyone even though its a defence paid for system, NTP servers are paid for by governments, yet everyone can use them. And if SAFE takes off then by necessity the governments will implement a SAFE network version of time authorities.

You seemed to have grossly misread what I wrote, or I am really bad at explaining things.

Time is a very good counter. Linux uses it everywhere a “event counter” is needed. It has served the “event counter” requirements of the computing world since it because available in UNIX many decades ago.

Use it as just an event counter or as a actual time stamp, the choice is up to the developer. It is a multi-purpose solution

Here we go, the word “contracts”. Wow contracts has multiple meanings.

I can buy/sell whatever on the SAFE network, including coins, and that may need an absolute time or it could only require knowing which came first.

So when you say contracts then you are in fact including timestamping. But you then later clarify it as only know which came first.

I hope the above summary analysis helped for you to understand why a centralised event “counter” is not practical in the SAFE network, especially when sections may number in their 1000’s or 100,000’s and still have the “counter” decentralised.

As soon as there is no “feedback” you then are describing a system that progresses from a point to all other points in the system. By definition a centralised system, and the central point is where the progression starts from. Basic control systems theory.

You want a “counter” but call it time. I understand this, but does not help. BTW the linux time is also a event “counter”

The problem with this equation is that for an Application running on a PC does not have any event counter. That only resides for each section. The PC is not connected to “a section”. It depends on what data the PC is trying to transfer to or from the network that determines the section contacted.

Now lets assume that the Application can access a section by using a XOR address it determines from a standard piece of data.

  • That section might have an event time value of 1000000
  • the neighbouring section might have 1234567890123456 as its event count
  • another neighbouring section might have 999999999000 as its event count
  • and so on

So you get a value derived from 3 or 100 peers and its a huge number

But then as the network merges sections and splits sections the other Application that you are trying to compare event counts with might (statistically possible) get mostly new sections split off from others

So then XOR address could yield a newly split off section now looking after that piece of data and the counter calc could be using

  • first section has event counter of 1000
  • the peers could have their event counters as
    • 123456
    • 99221
    • 987654
    • and may more

So then the other Application comes up with a really small event count. But this was done maybe days or months or years later.

Which was first.

How can you correlate these?

Its not a question of being a great idea, but it is fundamentally flawed in a completely decentralised network made up of a really huge number of sections.

7 Likes

This requires a consensus of those nodes. PARSEC is working with less than 30 or 50 nodes, you are talking of millions of nodes when the network is out of early stages.

The communications for PARSEC with 30 nodes is on the order of 435 (30*29/2) (actually there is a couple of communications per possible communication paths).

But for even 10000 nodes (tiny network) the communications is on the order of 50 million.

OK if you do that then you get what I mention in the last part of the previous post. Some will have small event counter value and other parts of the network will have massively large event counter values. There is no correlation unfortunately.

The issue that I think is being missed is that Nodes do not see much of the network traffic. They see only a really really tiny amount of it.

2 Likes

Here is a potential solution and like my other one, does not require core code to be modified at all. Changing core code to implement things is not the best way to go in nearly all cases.

This one is simply have a MD.

The MDs version number is a forever increasing number, cannot be modified by users and could thus be used as a event counter.

The applications that want to have an event counter then simply read the MD and use the version number.

The application then writes new data to the MD and this causes the version number to increase.

Problem solved.

2 Likes

A few questions comes to my mind:

You mean 1 MD per application instance, or per app type, or one global for the network?

Write contention can be quite severe. The core developers would have to enlighten us on the limitations there, but having everything write to one MD I think can be problematic.

And if not using a common MD, how is this useful?

1 Like

My idea has nothing to do with sections. As long as any kind of data is passed around (which is the reason for the network to exist) SafeTime can be attached to the messages, and then it spreads across the world very quickly.

Nodes don’t need to see much of the network traffic. This method requires local action but results in global synchronicity. There’s no “correlating events” and “weighing down the network” because each node has to **keep a counter for the dozen or so nodes it sends any kind of messages (for example, when passing on a chunk as a step between two other nodes) and that’s all.

A “contracts” is anything with signatures that need to be timestamped. We’re good as long as we have a one-directional counter that the participants can agree the value upon so absolute time is unnecessary and the required precision is flexible.

Please stop moving the goalpost. Noise unrelated to the topic:

  • “Time is a very good counter” indeed but it requires an external reference and I already highlighted multiple times that this thread is explicitly not about that.

  • Yes, there are times when absolute time is necessary, but they are out of scope for this proposal so let me not address your comments about that.

  • Why are you bringing up the counters for mutable blocks? That solves a different problem, it doesn’t solve this problem (it’s centralized), so it isn’t related.

  • When I say “the rough idea is that if half the nodes agree on the current value of the counter” you respond with “this requires a consensus of those nodes” which amounts to ignoring everything I previously wrote about how the method works though it’s just a single sentence that I already had to repeat a dozen times.

While sections, just as absolute time, are irrelevant to my idea, let me note that I’m afraid your are mistaken to think some sections will handle significantly more events than others. There will be differences but it’s impossible for events, which are uniformly distributed by XOR space, to exhibit the variance you suggest on the timescales longer than a few seconds. But this thread is unrelated to sections so let me not worry about that more.

Feedback or not. The counter can’t move forward until about half the other nodes caught up. Arguably, it is a kind of feedback because my peer’s decision affects me which, in turn, will affect my peer. Excuse me for the confusion.

Some statistics will follow in a separate post.

1 Like

Let me show it then. I simulated my method for a little over a million nodes, with a median of 16 neighbors (originally 8, but I pruned nodes with fewer than 5 peers and it pushed up the median), initialized with SafeTime between 0 and 99 inclusive, and then updated to be consistent with my algorithm (to contain their peers’ median + 1). After this, I simulated a large number of random messages.

On average, each node sent or received one message every second from all of its neighbors. (If messages would be more or less frequent, scale the results accordingly.) These are not messages for SafeTime but messages that are part of the regular traffic on the network. SafeTime just piggybacks on them as 8 additional bytes somewhere in the packet.

The results: After just one second of simulation time, half the nodes were within 2 steps of the maximum SafeTime and 95% within 6 steps, and this is where they stayed for the rest of the simulation. It took about 2 more seconds for the minimum (of over 1 million nodes) to settle between 30-40 steps within the maximum, where it stayed. I found the counter is increasing 21 steps each second (occasionally 22), and that means 50% of the nodes are within 0.1s of the maximum, 95% are within 0.3s, and even the worst 5% were just between 0.3s and 2.0s behind. Network latency was not simulated so the real values are expected to be somewhat higher, but this does not alter the conclusion:

Contrary to your worries, my method moves towards synchronicity even on a large and extremely sparsely connected network, though each node sees only a tiny part of the whole (no, I did not misunderstood that about the network).

As for whether it’s “economical”:

  • SafeTime needs a few (8?) bytes in each message
  • nodes need to store the latest value of SafeTime received from their peers: 8 bytes for a dozen or so peers
  • nodes need to calculate the new value after receiving or before sending a message: calculating the median of about a dozen numbers, then adding 1

Let me ask you, does this sound like a tough coding task or something that would waste a lot of bandwidth?

8 Likes

Thanks for the clarification. Yes, I see what you were getting at now. I don’t think you would need to worry about peers for your counter though. Any given node might receive a message from any other node with a value of the global eventually consistent counter. Per your original idea, the receiving node would then update their own counter according to :
LocalCounter = max(RemoteCounter, LocalCounter +1)

I think the only way to keep this from getting out of hand with regard to gossip/communication loads and unstable feedback loops is to rely on parsec and tie the counter to the length of the section datachain. (Forgive me Pierre if I’m not recalling the parsec paper correctly) Each time a section reaches consensus and adds a block of data to the local datachain, then the section counter gets incremented by one. The updated counter then gets attached to messages during gossip with neighbors and propagates from section to section through the network as you have discussed above. If relying on parsec in this way, the addition of a block would control counter incrementation + 1. Therefore updating the a local section counter with regard to a remote neighbor’s counter that was received in a message would be a simple max operation.
LocalCounter = max(RemoteCounter, LocalCounter)

Edit: yes, I glossed over a lot of consensus and trust details in the above comments.

4 Likes

I do apologize for getting impatient.

I thought while nodes can get messages from any nodes, it always happens through a small subset that the node is directly connected to at that moment.

If I am wrong that would be better because nodes could rely on a more diverse set of inputs. My original idea would be changed to use a small LRU cache instead of a known list of its peers. Which gets us to your next point, which is a misunderstanding about what I proposed:

You are right, this would quickly get out of hand, but it’s not the formula I proposed.

I use the median of the SafeTime received from all neighbors, so each update works with the whole set, not just the latest piece of information. This stabilizes the process without any of the complicated additions you mention.

The important part, which your simplified update mechanism removed, is that we use the wisdom of a crowd which, in turn, draws from the wisdom of an even larger crowd, and so on, from an exponentially growing number of sources. However, we don’t have an infinite number of nodes, so this process quickly saturates the entire network as the steps going outwards loop around.

3 Likes

Isn’t that the wisdom that parsec offers? I was simply suggesting that your counter idea would work better if it relied on parsec for crowd wisdom. Then the counter updates are trivial to implement.

1 Like

Sorry, I overlooked that part. I don’t have a good intuitive understanding about PARSEC yet. A counter based on PARSEC and datachain blocks may work with the simplified formula, but mine could not.

The good thing about SafeTime as I proposed is that it stands on its own legs without PARSEC or sections, and without complicated consensus protocols. Synchronization “just happens” without additional communication or directed responses.

1 Like

Its whatever you want. It could be “myApp” has its own and “yourApp” has its own.

Or it could be that someone sets themselves up as an “authority” and “guarantees” to kick the version number over once every few seconds or so.

Or a few MDs that everyone on the network uses.

That is the detail that could be formalised.

The point is that whether it is one MD or multitudes of MDs used by different applications, it would provide a event “counter” that would give the OP their event timer.

Nodes do not operate outside of sections. If you try to write core code into the nodes that does operate outside the sections then bad actor nodes can disrupt much more easily, even if it is just to do your event timer.

Which does not happen outside the control of the sections.

Read my explanation again why this cannot give you a globally useful event timer/counter. Your so-called counter could be huge or small depending on where you happen to connect tot he network at a particular time and the opposite minutes later.

And I explained why that cannot happen by simply looking at local traffic.

You keep saying counter as if it is a central counter, but somehow kept locally. As I explained the counter has to be good for you and for me, otherwise I could just use any counter unrelated to other counters.

What good is an event counter that for you is one value but for me is another. Then when I connect to a node again it is the opposite.

Remember that Applications do NOT run on nodes

Remember that nodes do not operate apart from sections and consensus, otherwise it is an avenue for bad actors to disrupt, even if its just your event counter.

Remember that if an App wants a event counter value then it will need to ask a node under your model. That node could be new and its only seen traffic from other new nodes and its value for the event counter is 10. But my Node that i ask say the value is 100 billion. So I think that the data you just “timestamped” must be really old. Now the other way, I timestamped some data with 100 billion and you think I am BS because its so much larger than your 10.

Remember the network is very dynamic and by writing core code that works outside of a section then you are going to get statistically nodes whose neighbours (peers) are also new and thus event counters that are very small.

And statistically speaking your 16 neighbours could also have just started out their life and their event counters are set to 1 because their peers happen to the same 16. So you get an event counter of 1.

How far do you go in asking peers to ensure that your event counter becomes global? And this is where it falls over because for your counter to be useful then it has to be correct 100% of the time, otherwise some very expensive contracts could be either broken or fail due to event counters being uncorrelated.

Remember that nodes are restarting all over the network at random times and many will starting fresh and have many neighbours fresh too. Because you are writing this bit of the core code to work outside of sections then you have no ability for consensus or ensuring a good mix of older nodes in your peers.

Remember, just connecting to one bad actor node could stuff up the whole thing since it can report whatever it wants and your APP has no idea Your APP is not running on a node but simply a PC that connects to nodes elsewhere without being able to specify which one it connects to.

In summary

  • The MD version number does all what you are talking about without core code changes or dangerous operations outside of sections
  • Bad Actor Nodes will be able to fake event numbers that you APP sees.
  • The APP asking for the event counter is not running on a node and is only communicating with a random node on the network, The node could be a bad actor or a new node whose peers are also new nodes and are peering amongst themselves since this is outside of the sections functionality and so has no protection against this statistically possible situation.

Please Ignore all the above and answer why the MD version number does not solve your proposal? Remember version numbers increase only and also change when the network does something with the MD, which also includes non-user actions.

If any idea can be satisfactorily done without changes to core code then it should be done at the APP (or client) level. Every extra bit of core code is yet another thing delaying the network release and also another avenue for attack. Your event timer/counter is perfect for APP level code and use of MD functionality already built into the core code.


EDIT:

And my idea of time authorities are NOT connecting SAFE to external sources, and at no time did I suggest that. And is still a perfectly good way to achieve exactly the outcome you want. Just it doesn’t do it the way you want and require changes to the core code and changing the NODE is a part of a section requirement.

1 Like

It is NOT an event counter. It’s more like a wave rippling along the surface.You may push it down a bit at one point but the effect is short-lasting and self-adjusting.

You still don’t see what I’m talking about and this thread turned into a little debate with you and you alone. I have other things to do.

Yes that is understood. Sometimes terminology doesn’t show understanding. You call it a timer (time), so sue me for calling it an event counter. Like you call it a counter in the title

It still is going to be a value extracted by some means\

Bad assumption on your part. I see it clearly and have been covering other bases in the discussion as well to help discover what might be missing in my thinking. It seems though that a basic misunderstanding of how the nodes will be coming into existence and out of existence will cause situations where the wave is started anew until enough packets have been travelling past to include those statistically possible cases into the wider wave.

And still you IGNORE the solution to

by using a MD (or multiple MDs) to provide this. There is a solution and you ignore it?

Do not change core core when an APP layer solution can provide all you want.

1 Like

But the MD is a centralized solution because it is modified by the owner of the MD. Users of the app must trust the owner to not tamper with it.

Modifying the core is worth the effort if a decentralized solution is found to generate a trustless global counter.

3 Likes

Yes, and additionally, if you let others than owner write to it:

In my previous question I asked if it was supposed to be a single global MD, or one per app or one per user. Response was “all or any”. So let’s look at it:

You can have a single global MD. It is the perfect example of centralisation. But that is not the only problem for someone who wants a decentralised solution (although quite grave to say the least).
Contention is one problem. Can xx billion people and devices write to a single MD at the same time? I don’t think we need the input from MaidSafe to say: No. There’s a limit on the concurrency.
Even if they could, wow here we have spam factor. Someone will want to disrupt. Sure, it will cost a little, but it will yield very well in terms of chaos created, and all vandals’ efforts will aggregate, so there’s not a need for a single powerful attacker. Just the normal set of bad eggs will do to spoil it massively.

And that last part about disruption applies also when an MD is common only per app type, or some other level of granularity.

The least useful example (uhm well, I guess they are all useless if they don’t work, but yeah you get the point) would be the other end of the spectrum, where each user has their own MD that they update to keep a counter. What’s the point in that?

And then there is everything in between these two extremes, but they would all suffer from various degrees of isolation with regards to some global counter.

@neo, that idea, with the information presented, is lacking imo - not the least when it comes to the requirement of decentralisation.

1 Like

The MD can be owned by noone (burn ID) and updates allowed by anyone.

Yes it is a central data object, but being updated in a decentralised way is possible. This wave solution also is seeing updates by the nodes extra to the section consensus and thus prone to problems.

Also remember that we have been told the version number is not a number relating to the number of user updates, but rather is updated by the section whenever something happens involving the MD. So even if no one does a data update on the MD the version number will still be incrementing.

The whole concept here of a consistent global counter (from title of thread) and described in the OP as a “time” is also a centralised concept albeit trying to be handled decentralised. The MD is a central data object and the version number is being updated by a decentralised mechanism (events in the section and also maybe by users).

So using one or many central MDs to provide a global counter/time/whatever is still a valid solution to the OP query and request.


EDIT: the idea of MDs is still decentralised with a network wide (set of?) MD’s version number.

This is not inconsistent with a decentralised network since the updating and access etc is via the decentralised network.

Just like any other data held on the network there is only one copy kept due to dedup (yes 8 copies, but one place/address). So this idea of using the version number of a MD is not inconsistent with the decentralised system the SAFE network implements.

Not a problem for the OP, since they want to have a +1 to be counter when the node decides to do so. How many nodes will do this to their local counter at once. And then they are all supposed to conceptually centralise their value by a decentralised wave.

Lets be clear the concept of a consistent global counter/whatever is a centralised concept and so a solution that can be implemented using the decentralised network with decentralised systems and is automatically incremented anyhow by SAFE’s events does suit as a solution.

Also not a problem since only ONE update is need to keep bumping the version number and if no one does it then the section will anyhow as events involving the MD data object occur from time to time (reading of it, a new node needs to store a copy to maintain 8 copies, etc etc)

Disruption can occur with this or without this. You are talking of an attack that can and will occur at some stage anyhow and is not unique to this idea. And SAFE is expected to handle it with reasonable ease.

Remember it is the version number that gives the value and does not matter what is actually written (or not written) to the MD. Also teh version number is updated by the decentralised network anyhow when events involving the MD occur.

It isn’t consistent. It’s eventually consistent, in the dynamic sense: if a node looks around and, based on the evidence, establishes the value of the counter as X, then it’s guaranteed that no other node is too far behind, too far ahead, and all other nodes will soon reach this same value.

I wrote a simulation that followed my simple rules and the results check out. Your argument that you believe it is impossible add little to the discussion at this point.

I am discussing edge cases. I showed how it can be inconsistent at any time in the network’s life. Now or in ten years. To have a “counter” that is useful for contracts then it needs to be 100% consistent all the time otherwise some contracts can be hacked or disrupted or fail. Look at what happened to another project when a flaw was found.

So what is the actual use case since you cannot provide it for your stated (in the OP) use case of contracts

Now we’re talking. You’re addressing an actual problem here.

Real-life counter example: TLS. When your computer’s clock runs correctly within a certain margin, the connection will be deemed valid. There is no need for millisecond precision.

It’s enough to know that the current SafeTime is somewhere between X+N and X-N. This way, a 3rd party countersigning a contract can ensure that its not giving its name to a fraudulent document.

If a node received highly conflicting SafeTime from its peers, there are a number of simple solutions:

  • never skip more than a small number of steps when updating SafeTime
  • allow to reset the internal SafeTime after attack is detected
  • blindly blacklist the peer with the most offending value
  • build additional connections to see who’s lying

However, for such a thing to happen in the first place, a node would have to be unlucky enough to connect to a significant number of bad agents at the same time, or else the median of the incoming SafeTime values would not be affected.

Additionally, there is also the possibility to leverage the Safe Network’s built-in trust features. As I mentioned early on in this thread:

We can push the floor real high by giving higher priority to SafeTime in messages from nodes with higher age, for example. Yes, this would introduce dependency on sections but it would not require additional network traffic because the necessary information is already available.

The main point in this idea is to create a reliably increasing global counter with a value that is more or less in sync across the network. A simple simulation showed that it is in fact possible.

PS: MD is not a solution, not to the same problem. As others pointed out, it introduces contention, centralization, additional traffic. As it is not a solution, there is nothing to ignore.

1 Like