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
When the proposer starts up, it just waits for the full configured proposal interval before sending its first proposal. However, this means that the actual interval between proposals will be longer in general, because the time that has passed since the last proposal before the restart occurred is added to the total interval.
We can check the DGF at startup for the submission time of the latest proposal at startup to shorten the initial interval accordingly. This is similar to how the batcher at startup now queries the sync status and uses the latest safe head's L1 origin timestamp as starting point for the next channel's max. duration.
is the method I had in mind. Those contracts are currently in op-challenger which we probably don't want a direct dependency from op-program on, though it wouldn't be a problem necessarily, just a bit ick. The contracts are already shared by op-challenger and op-dispute-mon so pulling them out to a shared module would be quite reasonable. I just haven't done it yet because I'm not sure where it should live or what it should be called - I don't think it should be in op-service because its far too fault proof specific.
The idea behind the above is that we can query GetGamesAtOrAfter at startup for the configured interval and take the latest game into account to calculate the duration until submitting the next proposal. If the returned list is empty, we can propose immediately.
I think it's not very urgent, but a fine improvement to make to guarantee more steady proposal intervals.
The text was updated successfully, but these errors were encountered:
When the proposer starts up, it just waits for the full configured proposal interval before sending its first proposal. However, this means that the actual interval between proposals will be longer in general, because the time that has passed since the last proposal before the restart occurred is added to the total interval.
We can check the DGF at startup for the submission time of the latest proposal at startup to shorten the initial interval accordingly. This is similar to how the batcher at startup now queries the sync status and uses the latest safe head's L1 origin timestamp as starting point for the next channel's max. duration.
From a conversation with @ajsutton
The idea behind the above is that we can query
GetGamesAtOrAfter
at startup for the configured interval and take the latest game into account to calculate the duration until submitting the next proposal. If the returned list is empty, we can propose immediately.I think it's not very urgent, but a fine improvement to make to guarantee more steady proposal intervals.
The text was updated successfully, but these errors were encountered: