fix(exec3): prevent execution loop on zero-gas block regions during initial sync#151
Open
martianacademy wants to merge 1 commit into
Open
Conversation
During initial sync of chains with extended zero-gas block regions (e.g. early Polygon blocks 0-1.2M), the LoopBlockLimit fires after processing empty blocks but the commitment system cannot save state at the current txNum (between step boundaries). This causes the next ExecV3 invocation to read the same old commitment position, creating an infinite loop. Adding totalGasUsed > 0 to the block limit condition allows execution to continue through empty-block regions until real transactions are reached where commitment can be saved. Fixes: 0xPolygon#150
There was a problem hiding this comment.
Pull request overview
This PR changes the ExecV3 sync-loop exit condition in execution/stagedsync/exec3.go so initial sync can continue through Polygon’s early zero-gas block ranges instead of repeatedly restarting from the same commitment point.
Changes:
- Adds
totalGasUsed > 0to theLoopBlockLimitguard inExecV3. - Alters initial-sync batching behavior so zero-gas batches no longer immediately return
ErrLoopExhausted. - Targets the Polygon bor-mainnet infinite-loop scenario described in issue #150.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // until we reach a transaction whose comittement which is writable to the db, otherwise the update will get lost | ||
| if !initialCycle || lastExecutedStep > 0 && lastExecutedStep > lastFrozenStep && !dbg.DiscardCommitment() { | ||
| if blockLimit > 0 && blockNum-startBlockNum+1 >= blockLimit { | ||
| if blockLimit > 0 && blockNum-startBlockNum+1 >= blockLimit && totalGasUsed > 0 { |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes: #150
Problem
When syncing Polygon
bor-mainnetfrom genesis (--no-downloader), the execution stage enters an infinite loop at ~block 856,625. The node repeatedly processes the same 5,000 block batch without advancing because:LoopBlockLimit(5000) fires and breaks the execution loopExecV3call reads the same old commitment position → infinite loopFix
Add
totalGasUsed > 0to the block limit condition:This lets execution continue through zero-gas block regions (~80K blk/s, essentially free) until blocks with actual state changes are reached where commitment CAN be saved.
Testing
totalGasUsedis already tracked in the execution loop (line 727), no new variables needed