This PR updates get_committee_for_round by removing the condition to use the current_committee if the given round number is in the future. I believe this was a necessity when we did not employ the use of committee lookbacks, and needed to rely on the latest committee.
This is useful because in the scenario observed by https://github.com/AleoHQ/snarkOS/pull/3249, where nodes are processing certificates far in the future. They would erroneously disconnect from the peer due to a difference in committee ID instead of simply ignoring the certificate/proposal that was too far in the future to process.
Below is an example of the disconnect log:
WARN Cannot sign a batch from '{}' - Malicious peer - proposed batch has a different committee ID ({expected_committee_id} != {batch_header.committee_id()})
This is SAFE because we only ever call get_committee_for_round via get_committee_lookback_for_round and this edge case is never hit in the normal/honest operations of nodes.
Motivation
This PR updates
get_committee_for_roundby removing the condition to use thecurrent_committeeif the given round number is in the future. I believe this was a necessity when we did not employ the use of committee lookbacks, and needed to rely on the latest committee.This is useful because in the scenario observed by https://github.com/AleoHQ/snarkOS/pull/3249, where nodes are processing certificates far in the future. They would erroneously disconnect from the peer due to a difference in committee ID instead of simply ignoring the certificate/proposal that was too far in the future to process.
Below is an example of the disconnect log:
This is SAFE because we only ever call
get_committee_for_roundviaget_committee_lookback_for_roundand this edge case is never hit in the normal/honest operations of nodes.