Question Regarding Fallback Logic and Beacon Root Consistency in _selectFallbackPreconfer

[swarna1101]

From the _selectFallbackPreconfer function in PreconfTaskManager, the fallback preconfer is determined by the beacon block root as a source of randomness:

function _selectFallbackPreconfer(uint256 epochTimestamp) internal view returns (address) {
    uint256 lastEpochTimestamp = epochTimestamp - PreconfConstants.SECONDS_IN_EPOCH;
    uint256 randomness = uint256(_getBeaconBlockRoot(lastEpochTimestamp));
    uint256 preconferIndex = randomness % preconfRegistry.getNextPreconferIndex();

    if (preconferIndex == 0) {
        preconferIndex = 1;
    }

    return preconfRegistry.getPreconferAtIndex(preconferIndex);
}

Since the randomness is derived from the beacon block root, which can vary based on slot finality, how do we ensure that the selected fallback preconfer remains consistent ?

Also, if the randomness source shifts mid-epoch, could this impact the lookahead consistency?

Would it be required to add a check for slot finality or anchor the beacon root at a checkpoint to prevent inconsistency in fallback selection?

[AnshuJalan]

We use the first valid root in the previous epoch to find the fallback preconfer in the current epoch, so unless there is a 32 block reorg or 32 skipped slots (both are unrealistic in ETH PoS), we are good.

Also, if the randomness source shifts mid-epoch, could this impact the lookahead consistency?

Fallback preconfer is the same for the entire epoch, so there must be a single consistent random number to determine it.