-
Notifications
You must be signed in to change notification settings - Fork 270
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
Implement rsmt tree wrapper for nmt #238
Conversation
|
||
// if the data is erasure data use the parity ns | ||
default: | ||
copy(nsID, types.ParitySharesNamespaceID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that when celestiaorg/nmt#27 lands, and if we attach the parity nID when calling Push, then this method can be simplified to just calling push on the underlying NMT, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately we will still need a wrapper, because rsmt2d.RepairExtendedDatasquare
is not aware of how we erasure namespaces and NamespacedMerkleTree
would always assume that the first 8 bytes is the namespace. Now that we're erasuring namespaces, the first 8 bytes of the the 2nd half of the tree is not a namespace, it's just erasure data. nmt.Push
would panic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we're erasuring namespaces, the first 8 bytes of the the 2nd half of the tree is not a namespace,
I might still be missing something but why can't the caller of the NMT do the "preprocessing" and add the parity namespace in front of the parity shares (basically the same thing the wrapper currently does)? The tree (wrapper) would then not need any counter bc the calling code already knows when the erasured part starts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do that in lazyledger-core, but we would also have to do that in rsmt2d.RepairDataSquare
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see now. Thanks 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 lgmt 👍🏼
Co-authored-by: John Adler <[email protected]>
Co-authored-by: John Adler <[email protected]>
Description
This PR was mostly taken from the closed PR from nmt. As mentioned in the comments their, it makes more sense to keep the lazyledger-core login in lazyledger-core. This PR should be merged before for #235 and #232.
Closes: #237