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 👍 / 👎.
|
Hey @lukeiannucci, I'm actually not convinced that this approach is a good one because I've discovered that it severely limit's our throughput when we failover to using eth DA (if Eigenda goes down). Detailed description below: The serialization in this PR fixes the nonce-gap hazard, but it turns Serialization isn't actually needed for ordering. The queue assigns nonces synchronously inside Send, under the tx manager's nonce lock, so two back-to-back sends already get consecutive nonces and the auth tx is guaranteed to precede the batch tx on chain. The wait exists only to contain the failure case: if the auth tx dies after the batch tx is broadcast, txmgr resets its nonce, the next candidate refills the auth's slot, and the orphaned batch tx can mine unauthenticated — harmless to safety since derivation drops it, but it cascades into channel rewinds as described in the earlier review comment. Since calldata is the fallback DA we use today, we need a fix for the serialized pair regardless. The natural one is a paired-send primitive in txmgr: a SendPair that holds one MaxPendingTransactions slot per pair, issues both sends back-to-back (ordering is free), and on a permanent leg-1 failure cancels leg 2 by publishing a noop at leg 2's exact nonce. That cancellation is the only genuinely new machinery — txmgr's nonce state is private and nothing today can target a specific nonce. This restores calldata pipelining, which is enough to cover measured peak demand, and it matches the spec's "back-to-back, retry the whole sequence" wording better than the current serialization does. Eventually could also want blob fallback support — even fully serialized, blobs carry ~9 vs ~1.4 MiB/h — and that needs a second modification on top, because geth's cross-pool address reservation won't hold a calldata auth tx and a blob batch tx from one account at the same time, so blob pairs can't pipeline. Two ways to do it:
|
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.