`MinerGetBaseInfo` returns too few beacon entries after a null round

[LesnyRumcajs]

Note

This was AI found and seems correct, but do your own checks. Regardless of that, a test will be useful.

Location: src/beacon/drand.rs#L115-L118, in beacon_entries_for_block (#L76-L131). Reached only via miner_get_base_info (src/state_manager/mining.rs#L83-L90) → the Filecoin.MinerGetBaseInfo RPC.

Current behavior

The post-quicknet (unchained) branch unconditionally returns a single entry:

// We only ever need one entry after drand quicknet upgrade (FIP-0063)
if curr_beacon.network().is_unchained() {
    let entry = curr_beacon.entry(max_round).await?;
    Ok(vec![entry])
}

The comment holds only when the parent is exactly one epoch back. A block covers every epoch since its parent, contributing one beacon entry per covered epoch. When one or more null rounds sit between parent and current epoch, the block must carry one entry per covered epoch.

Correct behavior

Lotus BeaconEntriesForBlock (chain/beacon/beacon.go#L115) loops currEpoch from epoch down to parentEpoch+1, emitting MaxBeaconRoundForEpoch(currEpoch) for each — epoch − parentEpoch entries. The loop runs for chained and unchained alike; Forest special-cased unchained to one entry and lost the null-round case.

On-chain confirmation

Mainnet epoch 6216199 is null; the block at 6216200 (parent 6216198) carries two entries — rounds 30662992 (for null epoch 6216199) and 30663002 (for 6216200). Forest's beacon_entries_for_block(epoch=6216200, parent=6216198) returns only [30663002].

Impact

An external miner (lotus-miner / Venus / curio) using Forest as its full node builds a block missing a beacon entry whenever the previous epoch was null. The rest of the network rejects it (Lotus ValidateBlockValues requires the per-epoch entries), so the miner orphans its own block and loses the reward. Intermittent (null rounds are low-single-digit % of epochs) but not rare. Not a chain-safety issue — Forest serves wrong mining base info, it does not produce the block.

Fix

Replace the single-entry shortcut with the same per-covered-epoch loop the chained branch (#L119-L130) already uses — iterate parent_epoch+1..=epoch, one entry(max_beacon_round_for_epoch(e)) per epoch.

Test

MinerGetBaseInfo at an epoch whose parent tipset is 2+ epochs back must return epoch − parent_epoch entries at the per-epoch rounds; the 6216200 case above is a ready fixture.

[EclesioMeloJunior]

I was running a calibnet local node to reproduce the error locally, this was the step:

1. Following @hanabi1224 guidance I got the latest 1000 chain head entries using forest-cli chain list --count=1000 > chain-list.out, the output was a file with {epoch}: [ {block-header}: {miner-address} ]
2. From the output I found a null-round between epochs 3929307 and 3929309 (missing 3929308). To confirm I call the RPC method Filecoin.ChainGetTipSetByHeight for the missing epoch 3929308 on Lotus & Forest node, and they always returned the tipset for epoch 3929307 confirming the null-round

Reproducing the bug:

On the forest side I executed "method":"Filecoin.MinerGetBaseInfo","params":["t0143103", 3929309, null] and I got the following BeaconEntries

"BeaconEntries": [
      {
        "Round": 30800752,
        "Data": "kJ1bTg6wZcfIJyR/KrwmqEzH6BOy/rV7XBhKHMSFdrdklD/TzQ4BZpI4sisQvhOv"
      }
],

On the lotus side I executed "method":"Filecoin.MinerGetBaseInfo","params":["t0143103", 3929309,[{"/":"bafy2bz...fdeeov7n2jx5la6walecw"},{"/":"bafy2bzacea...5g2lmk2"}] and I got the following BeaconEntries

 "BeaconEntries": [
      {
        "Round": 30800742,
        "Data": "gbaxOmL99VsuzPz49jO9C0Y/MYMYp0QjuqPKpYALVMFEuLSHwxhknUzFDjXvVwzX"
      },
      {
        "Round": 30800752,
        "Data": "kJ1bTg6wZcfIJyR/KrwmqEzH6BOy/rV7XBhKHMSFdrdklD/TzQ4BZpI4sisQvhOv"
      }
],

OBS: the Lotus client requires the last argument to be a non-null tipsetkey while forest allow it to be null, I have raised the side issue #7422

So here I already could reproduce the problem, now after the suggested fix I we got the same output as Lotus.

Extra tests

I tested how Forest behave when passing the tipset argument as a future round and they always returned null beacon entries and that was the same behavior in Lotus