Timestamp

The transaction timestamp defines a time frame during which the transaction is considered to have occurred. The choice to represent timestamps as windows stems from the inherent challenges of precise timekeeping in distributed systems, where numerous unsynchronized clocks are in use. This asynchrony arises not only from the constraints of physical laws but also from the collaborative nature of shared transactions. Particularly, when a transaction requires multiple authorizations for signatures, the process of creating a collective transaction can extend over hours or days.

It's worth emphasizing that the primary purpose of a transaction timestamp is to align with the logical requirements of smart contract code and communicate the transaction's position along the time continuum to the contract code. While the same timestamp can serve other purposes, such as regulatory reporting or event organization in user interfaces, there's no strict requirement to utilize timestamps for these additional functions. In some cases, opting for locally observed timestamps, even if they don't precisely match timestamps observed by other participants, may be a more practical approach. Alternatively, when precision along the timeline is essential and requires consensus among multiple participants, conventionally using the midpoint of the time window can serve as a suitable reference point. Although this midpoint doesn't correspond precisely to a specific event (like a keystroke or verbal agreement), it can still be a valuable marker.

Timestamp windows can be open, indicating that a transaction occurred before or after a specific time, with the exact duration being less critical. The verification of the timestamp is conducted by notary services. Since notary service participants themselves may lack perfectly synchronized clocks, determining whether a transaction submitted at the edge of a given time window is deemed valid at the time of submission can be unpredictable. Nevertheless, from the perspective of other observers, the notary service's signature holds the decisive role.

When a transaction bears the notary service's signature, it is assumed to have taken place within the specified time frame. It's noteworthy that the Java timeline used in DigiNetGuard adheres to UTC time, including leap seconds within the final 1000 seconds of a day, ensuring that each day comprises exactly 86400 seconds. Careful consideration is required to handle changes in the GPS leap second counter accurately, thereby maintaining synchronization with Java time. When defining a transaction's time window, precautions must be taken to accommodate network propagation delays during communication between users and notary services, as well as within the notary service itself.