Currently when calculating uptime, calculation only take into account whether the node was restarted or not, based on the uptime events. This means that a single uptime event can prove the node being online the whole period, which is wrong.
The problem is that this method of uptime tracking does not actually confer that the node is online, but rather that it is powered on and properly booted, and was network enabled at some point. However, one of the few given constraints is that a zos node actually (tries to) send uptime periodically, i.e. every X amount of time (currently every 40 minutes).
Considering that sending uptime is a very basic process, we should actually consider the proper functioning of this as the minimal requirement for a healthy node, which we want to award tokens. If uptime reporting does not work, there can be a bunch of issues:
The node has no internet connection (i.e. was disconnected at some point)
The node has internet connection but can't reach the chain nodes
The node can't make chain calls
The chain "is down". This essentially means all public nodes are down. Given that all services would be down then, this should be easily spotted and fixed (and can be worked around then)
All of the above conditions also mean that the node can't process workloads, for which it also needs to make calls on the chain. Therefore, if a node can't report uptime, it can be reasonably assumed it also can't process workloads, meaning it doesn't contribute to the grid, and is down from the perspective of the user. As such it shouldn't get tokens.
Also note that it is fine if the node sends uptime reports earlier, as this can happen (planned shutdown, upgrade, ...)
Considering the above, and the 40 minute delay between uptimes currently, a reasonable check for now would be to verify the last uptime report (for a node which was online) is no more than 1 hour in the past at the time the new uptime report was received. If it was, uptime credit should be no more than the 40 min interval.
Currently when calculating uptime, calculation only take into account whether the node was restarted or not, based on the uptime events. This means that a single uptime event can prove the node being online the whole period, which is wrong.
The problem is that this method of uptime tracking does not actually confer that the node is online, but rather that it is powered on and properly booted, and was network enabled at some point. However, one of the few given constraints is that a zos node actually (tries to) send uptime periodically, i.e. every X amount of time (currently every 40 minutes).
Considering that sending uptime is a very basic process, we should actually consider the proper functioning of this as the minimal requirement for a healthy node, which we want to award tokens. If uptime reporting does not work, there can be a bunch of issues:
All of the above conditions also mean that the node can't process workloads, for which it also needs to make calls on the chain. Therefore, if a node can't report uptime, it can be reasonably assumed it also can't process workloads, meaning it doesn't contribute to the grid, and is down from the perspective of the user. As such it shouldn't get tokens.
Also note that it is fine if the node sends uptime reports earlier, as this can happen (planned shutdown, upgrade, ...)
Considering the above, and the 40 minute delay between uptimes currently, a reasonable check for now would be to verify the last uptime report (for a node which was online) is no more than 1 hour in the past at the time the new uptime report was received. If it was, uptime credit should be no more than the 40 min interval.