Gloas range sync

[pawanjay176]

Issue Addressed

N/A

Proposed Changes

Implement range sync in gloas.
Basically requests blocks and payloads post gloas from the same peer, couples them and sends it for processing.
Does not change sync much at all other than adding the machinery for payloads by range requests.

Main changes are:
RangeSyncBlock which used to be a struct is an enum to account for the Gloas case. This allows a clear separation between gloas and pre-gloas code.
AvailableBlockData now has a BlockInEnvelope variant. This is to clearly indicate the post gloas case. I feel this is simpler to follow compared to NoData variant.

Tries to extract post gloas logic into its own functions so that there is minimal logic change in mainnet range sync behaviour.

This is meant as a stable base on which we can iterate further to make range sync cleaner and for unblocking range sync support on devnet. Some ideas for later is removing the retry mechanism in favour of delegating column fetching to lookup sync which can be done post #9155 and batch signature verifying envelopes.

[pawanjay176]

Tested on a gloas kurtosis network and mainnet and it works fine. Some cases where we went into optimistic mode because the parent envelope was not downloaded by range sync. Can be handled with #9039
Does not implement backfill, will be done in a future PR.

[mergify]

Some required checks have failed. Could you please take a look @pawanjay176? 🙏

[eserilev]

Looks good on the whole. Had some thoughts about a few things, lmk what you think

[eserilev]

should be DataColumnSidecarGloas right?

[pawanjay176]

It should be fulu because the check happens based on wall clock based current_digest_epoch. So if we are in gloas and are requesting fulu columns, we start failing because fulu columns are larger than gloas ones.

[eserilev]

This is pretty much good to go, just a few minor suggestions

[pawanjay176]

Thanks for fixing up stuff @dapplion !

[dapplion]

Good to go!

[eserilev]

LGTM

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-06-10 07:25 UTC · Rule: default
• ✅ Checks started · on draft merge queue: embarking unstable (844c6dd) and #9362 together #9443
• ❌ Checks failed
• 🚫 Left the queue — 2026-06-10 07:46 UTC · at 5c1e415b03176279519f7a026bb89dcfcd4f34fb

This pull request spent 20 minutes 40 seconds in the queue, including 19 minutes 3 seconds running CI.

Waiting for

• check-success=local-testnet-success
• check-success=test-suite-success

All conditions

• check-success=local-testnet-success
• check-success=test-suite-success
• #approved-reviews-by >= 1 [🛡 GitHub branch protection]
  • Gloas range sync #9362

Reason

The merge conditions cannot be satisfied due to failing checks

Hint

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

[eserilev]

@mergify queue

[mergify]

Merge Queue Status

🛑 Queue command has been cancelled

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-06-10 10:01 UTC · Rule: default
• ✅ Checks passed · on draft merge queue: embarking unstable (844c6dd) and #9362 together #9445
• ✅ Merged — 2026-06-10 10:31 UTC · at 2e329f5e40c8af3b6e4a2609a4878738fec169ed · squash

This pull request spent 29 minutes 33 seconds in the queue, including 27 minutes 59 seconds running CI.

Required conditions to merge

• #approved-reviews-by >= 1 [🛡 GitHub branch protection]
  • Gloas range sync #9362
• check-success=local-testnet-success
• check-success=test-suite-success