Skip to main content

expected_upgrade_data

hotshot_new_protocol::upgrade

Function expected_upgrade_data 

Source 
pub(crate) fn expected_upgrade_data(
    upgrade: &Upgrade,
    view: ViewNumber,
    epoch: EpochNumber,
) -> Option<UpgradeProposalData2>
Expand description

The UpgradeProposalData2 every honest node expects for an upgrade proposed at view in epoch. Voters require full equality, so a leader cannot pick rogue offsets (e.g. a new_version_first_view so close that the wire format would flip before the decided certificate propagates) or an epoch other than the voter’s own.

Unlike the legacy task this ignores T::UPGRADE_CONSTANTS: one-view finality needs no 130-view runway or empty-block transition period.

None when an offset would overflow the view number. No honest node reaches such a view, so nothing is expected there and a peer supplying one is rejected instead of wrapping (release) or panicking (debug).