New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve GetCandidate request mechanism #1359
Comments
As stated above, Option: 1 For making it explicit and decouple it from Option: 2 |
As it was raised by @herr-seppia the above statement We have 3 receivers (if K_BETA=3) per a height which means that we could expect up to 384 receivers (K_BETA*128) in worst case scenario. Based on that, we should consider NB. Option_1 means to use |
At this stage, it should be enough to implement Option_1. |
Describe the bug
Current implementation. In an edge case, a provisioner may discard the iteration candidate block. As a result, this provisioner will rely on the
GetCandidate
request mechanism to fetch it from the entire network.GetCandidate` request mechanism does propagate a request to the entire network and waits a few seconds for a valid respond. This mechanism introduces an inefficiency in consensus and different option could be discussed to improve it.
The text was updated successfully, but these errors were encountered: