Question about getFallbackPreconfer in PreconfTaskManager

[dantaik]

The current impl is:

    /// @dev We use the beacon block root at the first block in the last epoch as randomness to
    ///  decide on the preconfer for the given epoch
    function getFallbackPreconfer(uint256 epochTimestamp) public view returns (address) {
        // Start of the last epoch
        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);
    }

It seems if there is no preconfer registered at all, preconferIndex will be 1 and "address(0)" will be returned. Functions that call this getFallbackPreconfer doesn't check if the returned value is "address(0)" or not, which seems to be an issue.

The other minor issue is that the preconfirm at index 1 has twice the odds of being selected. The following change will fix it.

require(preconfRegistry.getNextPreconferIndex() > 1, "no preconfer");
uint256 preconferIndex = randomness % (preconfRegistry.getNextPreconferIndex() - 1) + 1;

[dantaik]

Another question: what's the benefit of using the beacon block root as the random number compared to much cheaper block.difficulty .

From ChatGPT:

The randomness (block.difficulty) in Ethereum 2.0 is derived from the RANDAO process, which involves validators contributing to a collective random value. Each validator submits a random value, and these are combined to produce a final random number used for validator selection and other protocol operations.

[dantaik]

Another minor optimization idea: in proveIncorrectLookahead, _getBeaconBlockRoot can be called twice with the same input, the second call is iniside getFallbackPreconfer.

[AnshuJalan]

It seems if there is no preconfer registered at all, preconferIndex will be 1 and "address(0)" will be returned. Functions that call this getFallbackPreconfer doesn't check if the returned value is "address(0)" or not, which seems to be an issue.
The other minor issue is that the preconfirm at index 1 has twice the odds of being selected. The following change will fix it.

Agreed. Fixed in: NethermindEth/Taiko-Preconf-AVS#180

Another question: what's the benefit of using the beacon block root as the random number compared to much cheaper block.difficulty.

We want to randomness to be constant for an entire epoch, and the source of random for the next epoch should ideally be in the current epoch itself, so that a nodes have advanced knowledge of who is going to be the fallback.

Another minor optimization idea: in proveIncorrectLookahead, _getBeaconBlockRoot can be called twice with the same input, the second call is inside getFallbackPreconfer.

There won't be a situation wherein both the calls end up using the same timestamp, since during fallback preconfer selection, we use a slot from the previous epoch, but the fallback preconfer selection happens only when the slot being proven incorrect is in the current epoch (because the lookahead has lost trust, and we expect a fallback preconfer to take over remaining slots).

[dantaik]

We want to randomness to be constant for an entire epoch, and the source of random for the next epoch should ideally be in the current epoch itself, so that a nodes have advanced knowledge of who is going to be the fallback.

Great, thanks for this information. Very helpful.