[OP Stack Deployment] Dropping unsubmitted channels

[dewpe]

Issue Description

Is there a way to get the OP-batcher caught up to the most recent L2 block without submitting the missed channels from the time it ran out of L1 funds to now? The batcher wallet ran out of funds due to the l2OutputOracleSubmissionInterval being too low when I initially deployed it. I was able to patch it by upgrading the L2OO implementation according to the comments within the L2OO contract. No real transactions occurred during this period so no transaction calldata will be lost if these channels are dropped. The proposer wants around 0.5E to submit the past channels to catch up.

As far as I know, everytime op-batcher starts up, it asks the op-node for its sync status and walks from that past L2 block to now. Is there a way to force it to skip this catch up phase as a one off?

Additional Information

No response

[sbvegan]

Hey @dewpe, sorry for the long delay. Can you please clarify a few things for us:

• is this a testnet or mainnet chain?
• which of your components are running/stopped (op-node, op-geth, batcher, proposer)?
• what are the wallet balances for each component?

For some clarity the batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1, to make it available for verifiers. Whereas the proposer's role is to construct and submit output roots, which are commitments to the L2's state, to the L2OutputOracle contract on L1 (the settlement layer).

Any additional context like configurations and logs are also helpful.

[sbvegan]

Hey @dewpe just following back up here. Did y'all figure out an approach?

[dewpe]

is this a testnet or mainnet chain? - Mainnet
which of your components are running/stopped (op-node, op-geth, batcher, proposer)? - Batcher is the only component offline
what are the wallet balances for each component? - 0.5E for proposer and 1E for batcher

We are just changing the DA as our current approach

[imtipi]

seems you want to save gas while no transaction in your network.testinpod team is digging something like this
docs:https://op-tip.notion.site/Span-Batch-Design-Docs-b85e599a47774dcdb8171cc84cab2476
but currently it is still in development, and they say this aiming to deploy in Delta hard fork(the next hardfork after Canyon)

[ajsutton]

Batches have to be submitted in order to be valid so the batcher can't just skip them. That said, the sequencing window setting (12h on op mainnet) provides an upper bound on the amount of time the batcher has to catch up because after that period the derivation process in op-node will insert empty blocks because there were no batches published. That updates the safe head of op-node and the batcher will need to begin submitting from that point onwards.

[github-actions[bot]]

Hey @dewpe, We hope your recent question was resolved to your satisfaction. Your feedback is invaluable and helps us improve our support services. Could you spare a moment to fill out a short feedback survey. Thank you for helping us improve our developer community.