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.
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
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.
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.
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.
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.
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:
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.
OR your APP more likely unfortunately uses a Bad actor Node.
REMEMBER your APP requesting the value is not running on a node and since its not using section consensus you have no way of controlling if you get connected to a bad node or not. The bad node can simply lie.
Can you check your reference? Because in current code someone needs to do an action to increment a version:
The version of a MD is incremented when the permission set or the owner changes.
The version of an entry is incremented when the value is updated.
This means you must trust someone to do an update to increment the counter. Of course, you could do the update yourself but then this isn’t an automatic increment (and you must be pay a fee to do it).
It was in these forums by one of the dev team when being questioned about the very issue of how the version is updated. The answer was along the lines the purpose of version number is for the section and not the users and is updated at various stages in the datachain and events operations.
If it ends up being only when users updates MD, then its a simple rule that to use it you must update it. The OP was not worried how often it was updated, just that it got updated when “needed”. So updating it when used should suffice. If noone is willing to update it then is it needed???
Firstly, no APP is requesting anything. My design states this number is sent as part of each message between nodes, not as responses to requests.
Secondly, can you estimate the probability that the majority of the peers a node is connected to are all bad actors? Otherwise, the median will be unaffected and the attack fails.
It would take a coordinated attack at an unsustainable scale to ensure enough nodes would connect to enough bad agents because directed attacks are impossible as nodes have no control over whom they get connected to.
Moreover, just because random nodes can’t verify who they are connected to, it could be verified within sections, where the peers know each other’s age and reliability. In other words, the moment an attack reached a section boundary, it would stop spreading further in that direction.
So no one uses it. Then why have it?
That is for nodes. But what of the person requesting the value in order to have it in their contract!
This is a cross purposes communications. You are talking of the node updating its value and I am pointing out the use of the value is what can be subverted.
Anyone can use it the moment they need it. It’s there, all the time, rippling across the network, slowly increasing. You either don’t understand what I’ve been talking about or…
They don’t request it, they already “know” it because they’ve been in touch with numerous nodes, all of which sent their present idea of the correct value in every message. As long as the majority of those nodes are honest, SafeTime will keep behaving as described. If the majority of the nodes on the network are dishonest, we have a bigger problem.
It would take the majority of a node’s peers to conspire against it for such a subversion to be able to happen. However, the network is built in a way that such directed attacks are inherently impossible.
Only the nodes see it. The users don’t nor do the APPs. The users are not running on nodes
So what use is it
Ehm… Could maybe an API call return it to the APPs? How else could that “anyone can use it the moment they need it” snippet be understood? I’m somewhat speechless at this point.
Yes because you are missing what I am trying to point out to you.
Now we are getting somewhere.
So now we need an API. Is that API only going to talk to a Node or a section?
If a node then that node could be a bad actor and undo all your good work
If a section then you are reintroducing consensus mechanism.
And the MD system provides all this without needing core code or extra fields in the packets being sent.
And customisable for the application allowing for future adaptations without worrying about affecting other existing systems or requiring core code updates, testing etc
Anyhow I feel there is a solution without core code changes that implements your opening post and topic. So I’ll leave it there for my input and let others have their say