You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once #367 is implemented, one can easily use the "asynchronous" verification module to implement a basic notion of time in Trantor blocks as follows:
Whenever a block is proposed, the proposer attaches its local real-world wall clock time to it as metadata. When the receiver verifies the block, its "asynchronous" verification module will not respond until its own local wall-clock time exceeds the attached timestamp.
This guarantees that, as long as correct nodes have their local clocks set up correctly, only blocks with timestamps in the past will be agreed upon. In other words, anyone observing a block produced by Trantor can be sure that the attached time has already passed. Note that, while arguably already useful in this form, this is a rather weak guarantee and should not be mistaken for up-to-date real time. Even monotonicity of the timestamps is not guaranteed across blocks. Two subsequent blocks with a decreasing timestamp values may well be produced, as long as both timestamps are in the past.
The text was updated successfully, but these errors were encountered:
Once #367 is implemented, one can easily use the "asynchronous" verification module to implement a basic notion of time in Trantor blocks as follows:
Whenever a block is proposed, the proposer attaches its local real-world wall clock time to it as metadata. When the receiver verifies the block, its "asynchronous" verification module will not respond until its own local wall-clock time exceeds the attached timestamp.
This guarantees that, as long as correct nodes have their local clocks set up correctly, only blocks with timestamps in the past will be agreed upon. In other words, anyone observing a block produced by Trantor can be sure that the attached time has already passed. Note that, while arguably already useful in this form, this is a rather weak guarantee and should not be mistaken for up-to-date real time. Even monotonicity of the timestamps is not guaranteed across blocks. Two subsequent blocks with a decreasing timestamp values may well be produced, as long as both timestamps are in the past.
The text was updated successfully, but these errors were encountered: