[op-batcher] Add support for multiple batcher transactions per L1 block

[mdehoog]

Description

Adds support for sending multiple transactions from the batcher at once. A new flag has been added: --max-pending-tx, which controls the number of pending transactions sent to the txmgr.

The txmgr was refactored to allow concurrent calls to Send. Some internal nonce tracking code was added that manually increments the nonce for each tx (after initially pulling it from an L1 node). If any of the transaction sends experiences an error, the entire set of pending txs is canceled, and the cached nonce is cleared.

Note: currently the batcher only supports a single pending channel, which means that only when channels have multiple frames will multiple txs be submitted at once. Multiple pending channels will come in a later PR.

Tests

Add tests for txmgr nonce management + reset, as well as tests for the new TxQueue.

Additional context

At times we are experiencing more L2 state than the batcher can keep up with, and our safe chain is falling behind our unsafe chain. This PR will allow a greater throughput of batcher transactions by allowing multiple txs per L1 block.

Here's an example block that has 10 transactions from our batcher (0x53394266fc80e5d4e6d25b3d0b7ca243859b7b09).

TODOs

• Author or reviewer has added an entry to the current release notes draft, if appropriate.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 26b46ac

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[netlify]

✅ Deploy Preview for opstack-docs canceled.

Name	Link
🔨 Latest commit	26b46ac
🔍 Latest deploy log	https://app.netlify.com/sites/opstack-docs/deploys/6448243bbce7eb0008a256dd

[tynes]

I feel like the better way to implement this is in the TxManager, having it support concurrent transaction submission. Then any service that uses the TxManager has this ability. It also feels a bit weird to cap the amount for max transactions per block. Does that actually mean "max pending transactions"? I didn't go super in depth into the implementation here to be honest

[mdehoog]

@tynes totally agree 👍 will refactor

[tynes]

@tynes totally agree +1 will refactor

I think @trianglesphere has been thinking about this

[trianglesphere]

I've been thinking about this as well & was going to start work on this as well this week. Some of the refactors we've made to the batcher make it slightly harder to parallelize, but it should still be relatively easy to do async tx sending & async tx confirmation. There might be some slight difficulty with shutdown, but only driver.go should have to be modified in the batcher.

[mergify]

Hey @mdehoog! This PR has merge conflicts. Please fix them before continuing review.

[trianglesphere]

I like the approach. The new functions in driver.go are really nice.
More of an idle thought, I wonder what it’d look like to integrate the concurrency (+ limits into the txmgr or in a layer on top of the txmgr that’s not the in the batch submitter)

[trianglesphere]

Nice. I really like the Queue interface & how it's used. Inside the queue, I think that code is correct, but I don't think we need the full complexity of sync.Cond there.

[sebastianst]

LGTM now! Just a nit about a redundant check in tests.