Skip to content
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

Closed
goshawk-3 opened this issue Apr 5, 2022 · 3 comments · Fixed by #1427
Closed

Improve GetCandidate request mechanism #1359

goshawk-3 opened this issue Apr 5, 2022 · 3 comments · Fixed by #1427
Assignees
Labels
mark:testnet type:tech-debt the issue is a tech debt that needs fixing

Comments

@goshawk-3
Copy link
Contributor

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.

@goshawk-3 goshawk-3 self-assigned this Apr 5, 2022
@herr-seppia herr-seppia added the type:tech-debt the issue is a tech debt that needs fixing label Apr 29, 2022
@goshawk-3
Copy link
Contributor Author

goshawk-3 commented Jun 1, 2022

As stated above, topics.GetCandidate message is a Kadcast.Broadcast message. However this message is never re-propagated as per implementation. That said, topics.GetCandidate does not introduce any stress to the network as it should not reach more than K_BETA nodes per a single request (K_BETA is default redundancy factor for broadcast in Kadcast).

Option: 1

For making it explicit and decouple it from Kadcast.K_BETA config, instead of Kadcast.Broadcast we could use Kadcast.AliveNodes + Kadcast.Send

Option: 2
To simplify and stabilize the implementation, we could allow both Reduction_1 and Reduction_2 to always verify and accept topics.NewBlock of current consensus iteration. In that way, any provisioner will always know the proposed candidate block of the current iteration and will not need to send topics.GetCandidate requesting it from random set of nodes.

@goshawk-3
Copy link
Contributor Author

goshawk-3 commented Jun 29, 2022

As it was raised by @herr-seppia the above statement topics.GetCandidate does not introduce any stress to the network as it should not reach more than K_BETA nodes per a single request (K_BETA is default redundancy factor for broadcast in Kadcast). is incorrect.

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 Option_1 and Option_2.

NB. Option_1 means to use topics.KadcastSendToMany instead.

@goshawk-3
Copy link
Contributor Author

At this stage, it should be enough to implement Option_1.
Option_2 should be considered after fetching more getcandidate-related stats from testnet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mark:testnet type:tech-debt the issue is a tech debt that needs fixing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants