Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

op-proposer: Check most recent proposal at startup #10912

Open
sebastianst opened this issue Jun 12, 2024 · 0 comments
Open

op-proposer: Check most recent proposal at startup #10912

sebastianst opened this issue Jun 12, 2024 · 0 comments
Labels
A-op-proposer Area: op-proposer T-node Team: Node

Comments

@sebastianst
Copy link
Member

sebastianst commented Jun 12, 2024

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

func (f *DisputeGameFactoryContract) GetGamesAtOrAfter(ctx context.Context, blockHash common.Hash, earliestTimestamp uint64) ([]types.GameMetadata, error) {
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.

@BlocksOnAChain BlocksOnAChain transferred this issue from another repository Jun 18, 2024
@BlocksOnAChain BlocksOnAChain transferred this issue from ethereum-optimism/Node-temp_repo-for-public-issue-migration Jun 18, 2024
@BlocksOnAChain BlocksOnAChain added A-op-proposer Area: op-proposer T-node Team: Node labels Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-op-proposer Area: op-proposer T-node Team: Node
Projects
None yet
Development

No branches or pull requests

2 participants