[Event] Add support for event timestamps

[velvia]

Today, we don't have the notion of a timestamp for events or effects.
We consider events as a log of the Sui blockchain, a recording of what has been happening. Thus developers will look to query events in the Sui blockchain for many purposes:

• Debugging - finding out events that happened for particular contract over time
• Tracing what has changed for particular objects or addresses or contracts
• Analysis

A notion of time is standard table stakes for event systems and is considered a primary key for all observability and log systems. In most of them, not specifying a time range results in a default time range.

This is a proposal to include a timestamp in TransactionEffects.

Precision and Ordering Guarantees

The intended purpose of a timestamp is not for use for consensus or as a primary key in a database. The timestamp is not meant to uniquely identify an event. It is for the convenience of a user who will want to find events in a given time window, and given a result of events, to be able to roughly trace their order.

In my experience, event and log users are able to tolerate some imprecision in the timestamp timing, but not having a timestamp any all is usually not acceptable.

Local Validator Timestamp

We can start by putting in a local validator timestamp in each TransactionEffects, corresponding to the UTC timestamp when the effects are produced.

For that validator, that timestamp should follow causal ordering, since objects have to be processed in increasing versions.

Global Effects Timestamp / Median Timestamping / Checkpoints

A checkpoint would include a list of events that happened in that checkpoint, and we would desire to build that list of events from the list of transactions/effects that were formed as part of that checkpoint. However, each effect produced by a validator would have its own timestamp. It is desired to come to a single timestamp derived from all the individual validator effects timestamps.

If we had all the effects timestamps, then we can build a vector clock of all the timestamps. A standard way to find a single timestamp from a set of timestamps is using median time stamping. There is literature on this subject, but a median time stamping strategy, assuming there are 2f+1 honest validators whose timestamps are in the middle, gives a guarantee that the median timestamp will come from one of the 2f+1 validators.

Such a median timestamp would be enough to serve the purposes of event observability and filtering.

A Follower-based Median Timestamping Strategy

1. Modify the TX stream sent by each validator to its followers to include not just the TX certificate digest, but also the effects timestamp. This is not a big addition.
2. The follower sync's up different streams from multiple validators. For each TX, it collects the timestamps it sees and finds the median
3. Create a new struct containing the median timestamp, like EffectsWithMedianTimestamp

Transaction vs Effects timestamp

One argument agains the above is that we would need a new mechanism for doing median time stamping of effects. (@oxade 's follower could do this). An easier approach, discussed elsewhere already, involves putting a timestamp into the transaction and then having the gateway code that creates a certificate do median time stamping. However this is the time of the certificate which may be very different from the time the certificate was executed.

[velvia]

@oxade see the section above for follower-based logic to compute median effects timestamp for event purposes

[jumpsiegel]

Any thoughts on when this might be done?

[velvia]

Sorry let me close this. We actually do have event timestamps and have had them for a long time, albeit they are local (on a full node).