fix: Verify that unmerged leaves are sorted #321
Merged
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.
The RFC requires that unmerged leaves MUST be sorted. Moreover, some of our mechanisms rely on this to work correctly. This PR enforces this when validating the tree on join and inserts the leaf in the correct position when updating the list of unmerged leaves.
I believe that the motivation behind the RFC's requirement is the fact that in a normal execution the list will always be sorted if upon updating the list the new index is simply pushed to the end. The reason is that the list of unmerged leaves of N can only be emptied (when a member in N's subtree is removed, updates or commits) or, when a member is added, extended by the first free leaf index in N's subtree for the new member.
However, I think that one can (maliciously) craft a valid tree where this argument does not hold. For example, a tree with 8 leaves where leaf 3 is an unmerged leaf of its grandparent and leaf 2 is empty.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT license.