seems that those errors and all those warning WARN - Unable to import blocks: DATA_NOT_AVAILABLE are a sync issue in GLOAS:
newb.log
The path is:
- Sync receives a batch and publishes pre-import blocks: BatchSync.java:212
DasPreSampler immediately calls checkDataAvailability(block.getSlot(), block.getRoot()) for those pre-import blocks: DasPreSampler.java:58, DasPreSampler.java:89- The retriever batches many roots into outbound
data_column_sidecars_by_root: DataColumnReqRespBatchingImpl.java:105
- The RPC response validator verifies KZG by resolving the block via
combinedChainDataClient::getBlockByBlockRoot: AbstractDataColumnSidecarValidator.java:58
- That lookup only checks recent/historical chain data, not the pre-import batch: CombinedChainDataClient.java:547
Log evidence is pretty direct:
0x9587…04ac fails from 14:25:54 to 14:27:44; first state regeneration for that root is later at 14:30:45.0x7955…20c9 fails from 14:31:23 to 14:35:25; state regeneration happens later at 14:38:05.- The bursts start while sync says
Batch import: in progress and repeatedly logs Unable to import blocks: DATA_NOT_AVAILABLE.
So I would not read this as “peer sent bad KZG data.” It is a local validation-context problem: the sidecar may be for a block we downloaded/pre-sampled, but the validator is using a resolver that cannot see pre-import/in-flight blocks. Worse, one such BadTiming error currently aborts the batched response and completes all requests in that batch exceptionally: DataColumnReqRespBatchingImpl.java:225.
The clean fix direction is to make outbound by-root validation use a resolver that can see the pre-import block context, or treat GLOAS “known block missing” as local inability to validate yet rather than an invalid peer response.
this is gloas specific because we don't need the block to do KZG validation in FULU, it is only required in GLOAS
seems that those errors and all those warning
WARN - Unable to import blocks: DATA_NOT_AVAILABLEare a sync issue in GLOAS:newb.log
The path is:
DasPreSamplerimmediately callscheckDataAvailability(block.getSlot(), block.getRoot())for those pre-import blocks: DasPreSampler.java:58, DasPreSampler.java:89data_column_sidecars_by_root: DataColumnReqRespBatchingImpl.java:105combinedChainDataClient::getBlockByBlockRoot: AbstractDataColumnSidecarValidator.java:58Log evidence is pretty direct:
0x9587…04acfails from14:25:54to14:27:44; first state regeneration for that root is later at14:30:45.0x7955…20c9fails from14:31:23to14:35:25; state regeneration happens later at14:38:05.Batch import: in progressand repeatedly logsUnable to import blocks: DATA_NOT_AVAILABLE.So I would not read this as “peer sent bad KZG data.” It is a local validation-context problem: the sidecar may be for a block we downloaded/pre-sampled, but the validator is using a resolver that cannot see pre-import/in-flight blocks. Worse, one such
BadTimingerror currently aborts the batched response and completes all requests in that batch exceptionally: DataColumnReqRespBatchingImpl.java:225.The clean fix direction is to make outbound by-root validation use a resolver that can see the pre-import block context, or treat GLOAS “known block missing” as local inability to validate yet rather than an invalid peer response.
this is gloas specific because we don't need the block to do KZG validation in FULU, it is only required in GLOAS