Send Fallback Batch tx only after Auth tx Confirms (m3)#467
Send Fallback Batch tx only after Auth tx Confirms (m3)#467lukeiannucci wants to merge 5 commits into
m3)#467Conversation
lukeiannucci
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af73e32614
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // The auth tx is confirmed on L1. Now send the batch tx | ||
| batchReceiptCh := make(chan txmgr.TxReceipt[txRef], 1) | ||
| queue.Send(transactionReference, *candidate, batchReceiptCh) | ||
| batchResult := <-batchReceiptCh |
There was a problem hiding this comment.
In post-Espresso fallback-auth mode, dispatchAuthenticatedSendTx is called synchronously from the single publishStateToL1 loop, so this receive keeps the publisher inside sendTransaction until the batch inbox tx has a txmgr receipt. Since txmgr only returns that receipt after the configured confirmation depth, multiple ready frames are now serialized through an auth confirmation plus a batch confirmation cycle, effectively bypassing MaxPendingTransactions and making the batcher publish at most one batch per pair of confirmation waits under load. The batch send only needs to be gated on the auth receipt; after queue.Send for the batch, its receipt should be forwarded without blocking the publisher.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
I believe this is now the intended design after addressing m3. See discussion
#458 (comment)
lukeiannucci
changed the title
m3)
|
One consequence of waiting for the auth receipt before sending the batch tx: txmgr only delivers a receipt after num-confirmations (default 10), so the auth-to-batch block distance now starts at roughly num-confirmations, where the old back-to-back submission gave 0-1. That spends part of the fixed 100-block BatchAuthLookbackWindow before the batch tx even enters the mempool, and nothing validates the two settings against each other. If an operator raises num-confirmations, or L1 congestion delays batch inclusion past the remaining budget, the distance check fails, the frames are requeued, and the retry mints a fresh auth tx that hits the same squeeze — gas paid on both txs each round while the safe head makes no progress. Not blocking: at the defaults there are still ~90 blocks of headroom. A startup check that num-confirmations leaves ample window budget (and perhaps a metric on window-check failures so a retry loop is visible) would cover it, and in the worst case the lookback window can be extended. |
…xRef (#469) The auth tx of a fallback pair was submitted and its failures forwarded under the batch txdata's txRef. With a blob batch, an auth-tx failure surfaced with isBlob=true, so an ErrAlreadyReserved failure (account reserved by a stuck blob tx, e.g. left in the blobpool across a restart) made cancelBlockingTx send a calldata cancel against a blobpool reservation. That cancel is rejected the same way, the txpool state resets to good on its receipt, and the cycle repeats: the blob cancel needed to replace the stuck tx is never sent and no batch ever lands. Derive a calldata-typed authReference for the auth tx's queue.Send and its failure receipts, keeping the batch txdata's id so failures still requeue the right frames.
Hey Piers, Thanks for the review let me know what you think about this commit and if you have any suggestions on how to properly set this |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 47cb2a1c3d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // The auth→batch distance (num-confirmations + inclusion delay) must fit within | ||
| // BatchAuthLookbackWindow, so reserve room for the batch to land or the safe head stalls. | ||
| const fallbackAuthInclusionReserve = 75 // blocks (~15 min at 12s L1 slots) | ||
| if authLookback := derive.BatchAuthLookbackWindow; authLookback < c.TxMgrConfig.NumConfirmations+fallbackAuthInclusionReserve { |
There was a problem hiding this comment.
When any deployment sets --num-confirmations above 25, this new check rejects the CLI config before the batcher has loaded the rollup config, so it also blocks chains that have no BatchAuthenticatorAddress or Espresso fallback-auth path at all. The lookback bound only matters for sendTxWithFallbackAuth; non-Espresso or pre-Espresso batchers can still safely wait for more confirmations, so this should be applied only when fallback auth is actually configured/active, or after rollup config is available.
Useful? React with 👍 / 👎.
2 participants
Aims to fix the nonce-gap hazard from the M3 review comment. See: #458 (comment)
Previously the auth tx and batch tx were submitted together at consecutive nonces. If the auth tx failed asynchronously, txmgr's nonce reset left the in-flight batch tx gapped, colliding with the next pair and forcing channel rewinds.
Now the batch tx is only sent after the auth tx is confirmed; any auth failure stops the pair with an error receipt so the frames are resubmitted. This also lets us delete the receipt-watcher goroutine and authGroup, since receipts are now delivered inline.