Issue 7 (Extension) – Block-Level Lag & PreSamplingRange Awareness

[fjribi]

@rtedwardchen, below are some remarks and suggestions concerning issue 7:

The current sync analysis focuses on offset vs. median timestamp. That’s helpful to detect basic lag or drift, but it doesn’t check whether validators submitted their data at the expected block height according to the round schedule.

Also, we should not exclude the possibility that a validator who appears not-synchronized (systematic advance/lag) with peers may actually be using a custom PreSamplingRange (although unlikely, but this could raise the discussion among the community about customized oracle severs). In that case, they’d follow a different timing logic—one that’s valid locally, but inconsistent with the canonical round structure.

Here are two suggested additions to investigate further:

1. Add block-level lag detection: Compare submission block height to the expected one (e.g. endBlock - PreSamplingRange).
2. Estimate effective PreSamplingRange per validator, based on consistent submission offsets.

Why peer-median-only is not enough

Currently, we compute how far each validator's submission timestamp is from the median of the group. That's a good, but not always reliable. Example: If many validators are using outdated machines, poor internet, or laggy RPCs, the median gets pulled late. Then, a properly configured validator submitting at endBlock - 6 (default) could appear too early, even though it's technically correct. Therefore, we shouldn't only look at what the group is doing—we could compare it to the target schedule.

Why PreSamplingRange matters

In config.go, we find:

const PreSamplingRange = 6 // pre-sampling starts in 6s in advance 

Actually, it is in block numbers (see oracle_server.go)

This is a hardcoded compile-time constant. If a validator compiles the Oracle with PreSamplingRange = 3, they'll start sampling 3 seconds (or blocks) later. Such a validator might consistently appear “late” in the current analysis when they are just using a different local rule.

What could be added
If block numbers and round schedules are available, it could be useful to compute:

• How far a submission’s block is from the expected submission block (e.g. endBlock minus 6)
• The average block lag per validator, over time
• Whether some validators always submit 3 blocks “later” than expected—possibly hinting at a custom build using PreSamplingRange = 3 instead of the default 6 defined in config.go

These additions would help spot:

• Validators operating on custom logic
• Hidden timing problems that peer comparison alone can’t reveal
• Gaps between protocol expectations and actual behavior

[fjribi]

@stanleyyong @cmjc FYI