This repository has been archived by the owner on Jun 12, 2023. It is now read-only.
Confirm there are GRPC subscribers before generating PoC keys in heartbeat #1835
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change is indented to prevent poorly configured validators from proposing PoC challenges if they will not be able to receive receipts for those challenges due to their gRPC port being inaccessible. This will enable more of the selected PoC to succeed as validators with the GRPC port blocked will never generate challenges in the first place.
The idea is for the validator to check if it has any GRPC subscribers (i.e. connected hotspots) and only if they do, generate ephemeral PoC keys for including in heartbeat txns. I do this by looking at whether there are any members in the process group for the notifications that hotspots subscribe to. I am open to other ideas for how to do this check. I was not familiar enough with Sibyl and GRPCBOX to figure out if there was an easier/better way for getting a count of connections, streams, or sessions from one of them.
Validators will still heartbeat and will still be eligible for the consensus if gRPC is not open. However, they will miss out on PoC reward and no longer contribute to a lower PoC completion rate.
Note, this is a "self-policing" type approach. Someone could workaround this check by modifying the code and there is no consensus mechanism to prevent this. However, there is precedent for this. The check that the validator is not relayed before generating a heartbeat is in the same situation. However, that has shown to be quite effective because most inaccessible ports are the result of misconfiguration rather than malicious intent.
DEPENDENT ON: helium/sibyl#75