fix: Set DKG pool's initial start height to latest CUP height#9786
Open
fix: Set DKG pool's initial start height to latest CUP height#9786
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Background
The DKG pool's
current_start_heightis initialized once, when creating the pool, and then updated to the height of the new summary block, whenever the DKG pool is purged. Therefore, it serves as a watermark of the latest purge.Apart from that, its main purpose is to enable the bouncer:
Problem
Before this PR, the
current_start_heightwas initialized to1whenever the replica starts. This means that during the very first interval starting at height0(i.e. just after a subnet was created), the bouncer rejects legitimate dealings for start height0. Functionally, the DKG may still be completed, because nodes continue to propagate their own dealings to other peers, by including their own dealings into their own block proposals (as opposed to also including their peer's dealings in their own block proposals).However, this behavior is confusing, and it makes DKG slightly more difficult during the first interval (as no dealings are broadcasted by themselves). This also affects latency of remote DKG request being made during the first interval.
Proposed Changes
Instead of initializing the
current_start_heightwith1, this PR proposes to initialize it to the height of the latest CUP at the time of the replica start. Unlike1, this represents a valid start height, and also makes sense conceptually (lower dealings are rejected, higher dealings deferred until the height is reached).