System date/time in canister update functions

In a typical Web2 update endpoint, the system date/time of the application server will be used to set a timestamp with the saved record.

Since Internet Computer updates run on all nodes in the subnet to reach a two thirds consensus, and each node may run the function at different times, and the times are not guaranteed to be the same on all nodes, it does not appear that the result of an update function can be deterministic when including the side-effect of a system date/time.

My solution at the moment is as follows:

  1. Expose a public query function that returns the system epoch time ( from the single node/canister that executes the function.
  2. Call the query function from the front-end to retrieve the node’s epoch time.
  3. Include the epoch time from the query function in the payload to the update function.
  4. In the update function, validate that the time provided is within n seconds of the current epoch time, since each canister executing the function may differ slightly and some time must be allotted for the network calls.

Note that I do not want to rely on the users’ system times since those times can be tampered with.

Is this a necessary workflow to include timestamps with saved records or is there a better way? Thanks!

1 Like

The IC system provides a deterministic “now” timestamp. Why is that not sufficient?

1 Like

Thank you. I just wasn’t aware that it was deterministic. I would love to know the concepts used to achieve determinism when each replica runs the code at different times. Is that what the documentation means by the following statement?

“within an invocation of one entry point, the time is constant.”

The time is simply the time of the block that causes the message to be executed, and thus deterministic.

Now you might say “but I need the time when the actual execution happens”. And then I would say that you probably don’t, and really there is no point in distinguishing between the various points in time before an action was caused and when its effects become observable. That the various replicas might execute the message at slightly different times is really quite irrelevant then.

1 Like

Brilliant! Thank you so much for that explanation!

1 Like