How should we handle timestamp
in v1.0?
#23
Replies: 7 comments 16 replies
-
So far there are two main proposals: Proposal 1: Add timestamp offset == to confirmation timeIf the confirmation time is 5 minutes, then we would offset all L1 timestamps by 5 minutes. That would satisfy property (3) and make for a frequently updated, reliable, and accurate timestamp.
Possible amendment to this proposalExpose Proposal 2: Allow sequencer to add their own timestampsIn addition to the
|
Beta Was this translation helpful? Give feedback.
-
Some basic questions about the requirements:
What does 'frequent' mean? Should it be more frequent than the L1 block time of ~15 seconds?
How are these values accessed on L2? Are they opcodes, if so, how does that affect the goal of EVM equivalence? (The question also applies to
I keep hearing this statement, which feels like a mismatch of unit. This will be measured in blocks, not actually minutes right? If so, I think saying "approx 5 minutes of blocks" would be more precise. |
Beta Was this translation helpful? Give feedback.
-
Notes on ReliabilityI just want to add some color around the design goal of "reliable timestamps" -- I think it's worth more precisely defining what this means. In particular, there is a fundamental property of sequencing that cannot be solved by any of these proposals. I think that because this doesn't change, and is the most important timing assumption to consider for developers, this decision isn't best informed by reliability, but rather UX, consistency, and simplicity. I would state it simply as: "The sequencer may insert transactions up to The above statement is how to think of/word it "in L1 time." Conversely, "in L2 time" (i.e. from an L2 smart contract's perspective), given some This is a fundamental requirement of enabling sequencing. To allow sequencing to "lock in" a reliable L2 state ahead of time, the system needs a This manifests in some timing restrictions that cannot be avoided by application developers. The simplest one is that a commit-reveal scheme cannot have a reveal phase which starts < Given this fundamental restriction, the "reliability" that we can give to the L2 timestamps are to have monotonicity: timestamps can be required to strictly increase, between sequencer AND L2 transactions. Enforcing this has the following consequences that application developers can trust:
(note: In principle, we could also very slightly strengthen the last guarantee so that the current L2 timestamp is not greater than Notes on Equivalence Between some of these optionsAs a note, the addendum to Proposal 1. basically makes it equivalent to Proposal 2. This is because the "sequencer sets the timestamp" is equivalent to setting an offset of "whatever timestamp the sequencer wants" - "the actual L1 block timestamp". |
Beta Was this translation helpful? Give feedback.
-
Because of the fundamental security complexity in making L2 timing assumptions, and the desire to provide integrators with something simple, I'm currently an advocate of Proposal 2, with a monotonicity enforcement. I think the argument for this is:
I think that the most likely counterarguments to this would be if:
|
Beta Was this translation helpful? Give feedback.
-
I need to read this thread in more detail, but I just want the following properties out of any proposal:
|
Beta Was this translation helpful? Give feedback.
-
How would timestamps be handled in the case of a reorg larger than the |
Beta Was this translation helpful? Give feedback.
-
hi! just wanted to hop in with a few quick thoughts on the implications of different timestamp schemes for Uniswap oracles, as an example of some of the things an application developer might be thinking about. first, timestamp monotonicity is taken for granted in the logic, so it's important to preserve that. second, third, from my perspective a timestamp update cadence of |
Beta Was this translation helpful? Give feedback.
-
Design Goals
Additional Context
In v1.0 we will be able to supply easy access to all information contained in recent L1 blocks. This is because every L1 block triggers a
deposit block
which updates:lastL1Timestamp
,lastL1BlockNumber
,lastL1BaseFee
, andlastL1BlockHash
. The sequencer will pull blocks trailing L1 byCONFIRMATION_DEPTH
which we expect to be approx 5 minutes, possibly less. This would imply that the L1 timestamp is:Given these design goals, how should we handle
timestamp
in v1.0?Beta Was this translation helpful? Give feedback.
All reactions