This will be used to send the short proof ids of our proofs to our peers. The radix tree is copy-on-write, which makes it possible to store a copy of the tree in the remote node data, so even if the proof set keep evolving we can retrieve the missing proofs based on an index snapshoted at the time of the copy, while only duplicating the subset of the tree that has changed.
- Group Reviewers
- rABC87b4609c7efe: [avalanche] Maintain a radix tree of the proofs
Generally true throughout this diff: the naming is too dependent on the underlying proofs database being a radix tree. A simple example at the peer manager interface is getProofRadixTree(). Does the caller care that the DB is a radix tree? If we change to some other COW DB, we'll end up with a lot of renaming to do.
|319 ↗||(On Diff #33486)|
Is synchronize necessary on insertions?
|1654 ↗||(On Diff #33486)|
In addition to counting the leaves, is it worth keeping a list of proofs you built and ensuring each leaf can be found in that list?
|1698 ↗||(On Diff #33486)|
The above comment is even more relevant here.
Rename to shareableProofs and getShareableProofsSnapshot(), because these proofs are intended to be shared with our peers.
Update the test to check against a list of expeced proofs rather than relying on the count.
|319 ↗||(On Diff #33494)|
It is not needed. If it is needed, it is almost certainly a bug. Did ASAN yell at you before you put these barriers in place?
|513 ↗||(On Diff #33494)|
|699 ↗||(On Diff #33494)|
You probably want a way to early exit the iteration, no?
|162 ↗||(On Diff #33494)|
Something doesn't make sense. The proof are duplicated between here and the various pools, no?
That makes no sense, you want a tree of proofs, not a tree of gizmos that copy the proofs.
If the main problem is that you want a Uint256KeyWrapper (which is a pretty bad name, what is this wrapper, why would I want to wrap my Uint256? What does this do?), then just pass an adapter to the radix tree to tell it how to get the id.
|376 ↗||(On Diff #33494)|
You probably don't want to eagerly copy and leave that to the caller, considering there is a synchronize operation involved.