-
Notifications
You must be signed in to change notification settings - Fork 297
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
Adjust share size to match the spec and add namespaces to each Message #53
Comments
To clarify:
|
Yeah, that should definitely be clarified. When generating the commitments for The (WIP) ll-core PR #235 is using a const AdjustedMessageSize, and I think the app should import this. |
There is also something else to consider here: the spec currently assumes SHARE_RESERVED_BYTES to be one byte. That almost works because it is an index pointing to some starting point in a 256 bytes long slice. "almost" because if the index is > 127, its encoding currently will actually be 2 bytes long: https://play.golang.org/p/C_wN1E-lKRY That is bc varint encoding encodes 7 bits at a time. See https://golang.org/pkg/encoding/binary/ for details on varint encoding. The implementation uses this encoding for unsigned ints (lengths/indexes), as almost all protobuf implementations will support this: https://developers.google.com/protocol-buffers/docs/techniques#streaming Also, note that independent of the above issue, the current implementation does not use this index but rather length prefixed all messages (see celestiaorg/celestia-core#234) |
So...in my head canon I assumed it would just be 1 byte, but you're correct that canonical serialization is prescribed
Now we have a problem: if we use canonical protobuf, this could be 1 or 2 bytes.
|
I think this will be our best choice. It would work for the index that points to the start of a message. So it could always fit in one byte. IMO, the other thing, the length prefixing, should stay varint encoded. Simply because we don not really want to cap how long messages can get, right? |
Yes, the length can still be varint encoded because it doesn't affect chunking logic (there's only a single length). |
Can this be closed? |
I'm not sure, I asked about this during the off-site and didn't get a conclusive answer on whether it was implemented. cc @evan-forbes |
Sorry, I should have been clearer. The commitments that are generated do include the namespace of the message, but they do not add the length delimiter. We also need more testing to compare the generated commitments with the subtree roots of an actual square, to make sure that we are doing this important step correctly in the future. This would also help test #49 celestia-app/x/payment/types/payformessage.go Lines 140 to 147 in 1fcccc4
|
Was thinking about his more, and while we could use code from core that already exists (done on the celestia-app/x/payment/types/payformessage.go Lines 111 to 127 in ad49814
we could also move the commitment creation code to celestia-core, that way it would easier to roundtrip test |
I don't think we need this any longer, and am unsure of the context |
Namespaces are now kept in the actual message to ensure that they are recoverable, see the spec PR. This should also be accounted for in the app, specifically
SHARE_SIZE - NAMESPACE_ID_BYTES - SHARE_RESERVED_BYTES
The text was updated successfully, but these errors were encountered: