Description
The PeerMinBlock/SendMessageByMinBlock API acts as a peer filter for sending messages to a subset of peers.
A mapping between peer_id and min_block is maintained on the sentry side.
Note: min_block should be called "known best/max/highest" block number.
Sentry in fact knows nothing about the nature of min_block or where it is coming from.
This API acts as a cached filter, while the node is the source of truth.
If this mapping is maintained on the node side, the SendMessageByMinBlock is not needed.
SendMessageById could be used instead.
An initial known best/max/highest block number of a peer is received in an incoming eth Status message.
The sentry should remember peer status messages, and expose them via a new API call.
Then if the node crashes, the mapping could be recovered.
Proposal
Add a new method:
rpc PeerStatus(PeerByIdRequest) returns (StatusData);
Manage a mapping between peer_id and its StatusData on the sentry side.
Use this to build and maintain the peer_id/best_block_num mapping on the node side.