Fix double-submissions to Espresso#375
Fix double-submissions to Espresso#375QuentinI merged 2 commits intocelo-integration-rebase-14.2from
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refactors the Espresso receipt verification timeout mechanism to improve robustness against fluctuating HotShot block times. By transitioning from a fixed time-based timeout to a block-count-based approach, the system can adapt better to network conditions, reducing unnecessary re-submissions. A shared, atomic block height tracker was introduced to efficiently provide current block height information to verification workers, complemented by a generous wall-clock safety timeout to handle edge cases where block height tracking might fail. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request is a solid improvement, replacing the fixed wall-clock timeout for Espresso receipt verification with a more resilient block-count-based approach. The introduction of a shared, atomic block height tracker is a good optimization that avoids redundant queries. My review includes a couple of suggestions: one for a minor efficiency improvement and another to enhance the robustness of the new block height tracking goroutine to prevent potential busy-looping under certain conditions.
…tion Replace the wall-clock VERIFY_RECEIPT_TIMEOUT (4s) with a block-count-based approach (VERIFY_RECEIPT_MAX_BLOCKS = 3). This makes receipt verification resilient to variable HotShot block times across different Espresso networks. A single trackBlockHeight goroutine polls FetchLatestBlockHeight and stores the result in a shared atomic, which all verify workers read from. On the first verification attempt the current height is snapshotted; subsequent attempts compare against it to decide when to re-submit. A wall-clock safety backstop (5 min) is kept in case the height tracker is stale or broken. Co-authored-by: OpenCode <noreply@opencode.ai>
0626a37
into
celo-integration-rebase-14.2
* refactor: use block-count-based timeout for Espresso receipt verification Replace the wall-clock VERIFY_RECEIPT_TIMEOUT (4s) with a block-count-based approach (VERIFY_RECEIPT_MAX_BLOCKS = 3). This makes receipt verification resilient to variable HotShot block times across different Espresso networks. A single trackBlockHeight goroutine polls FetchLatestBlockHeight and stores the result in a shared atomic, which all verify workers read from. On the first verification attempt the current height is snapshotted; subsequent attempts compare against it to decide when to re-submit. A wall-clock safety backstop (5 min) is kept in case the height tracker is stale or broken. Co-authored-by: OpenCode <noreply@opencode.ai> * Pin eth2-val-tools --------- Co-authored-by: OpenCode <noreply@opencode.ai>
This PR:
VERIFY_RECEIPT_TIMEOUT(4 seconds) with a block-count-based approach (VERIFY_RECEIPT_MAX_BLOCKS = 3). After submitting a transaction to Espresso, we now wait for 3 HotShot blocks to pass before re-submitting, instead of a fixed 4-second window.trackBlockHeightgoroutine that pollsFetchLatestBlockHeightevery 100ms and stores the result in a sharedatomic.Uint64. All 4 verify workers read from this — no per-worker height fetching.VERIFY_RECEIPT_SAFETY_TIMEOUT = 5 min) in case the block height tracker is stale or broken.Why:
The old 4-second timeout was tied to an assumption of ~2s HotShot block times. In practice, block times on decaf testnet have been highly variable (2s–66s, currently averaging ~16s), causing every verification to time out and triggering constant unnecessary re-submissions. Using block count instead of wall clock makes us resilient to variable block times across different Espresso networks.
This PR does not:
VERIFY_RECEIPT_MAX_BLOCKS = 3,VERIFY_RECEIPT_SAFETY_TIMEOUT = 5 min) are reasonable defaults for any block time. Can be made configurable later if needed.op-batcher/batcher/espresso.go.Key places to review:
op-batcher/batcher/espresso.go:307-320— new constants replacingVERIFY_RECEIPT_TIMEOUT.op-batcher/batcher/espresso.go:335-374—evaluateVerification()now checks block count first, then wall-clock backstop.op-batcher/batcher/espresso.go:622-626— verify worker snapshotsstartHeighton first attempt.op-batcher/batcher/espresso.go:669-688—trackBlockHeight()goroutine (shared height poller).How to test this PR:
go build ./op-batcher/...— compiles clean.go vet ./op-batcher/...— passes.startHeight,currentHeight, andmaxBlocksfor debugging.