-
Notifications
You must be signed in to change notification settings - Fork 290
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
Add InfoReservedByte
to compact and sparse shares
#691
Add InfoReservedByte
to compact and sparse shares
#691
Conversation
…rg#710) * feat: move share consts from celestia-core * feat: new consts for universal share encoding * remove universal share constants * address @sweexordious feedback
…elestiaorg#710)" This reverts commit 75e2b9d.
Makes `TestParsePaddedMsg` pass
2312263
to
ae55527
Compare
Codecov Report
@@ Coverage Diff @@
## main #691 +/- ##
==========================================
+ Coverage 46.22% 46.38% +0.16%
==========================================
Files 33 33
Lines 3217 3251 +34
==========================================
+ Hits 1487 1508 +21
- Misses 1619 1625 +6
- Partials 111 118 +7
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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.
nice work! I need to take a second deeper look, but at first glance this looks like it's as minimal addition as possible, which is impressive given you had to grok all the encoding code lol
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.
[blocking question]
I didn't see anywhere that we were throwing an error if the first share was not the start of the message. If that's missing, then I think we should add that.
[comment on future work]
This does an excellent job of adding the info byte, but we have yet to have a universal share API. celestia-node should be able to call a function on any set of shares and get a message out.
As discussed sync and in other issues (I think?), this might entail a larger refactor of share encoding and decoding in general. Things such as changing the name of Messages to data, maybe refactoring the encoding logic to better fit the new API, and then refactoring the Merge/Split functions to use that new API. I think we still have to write a few issues for this, and should definitely be done in different PRs. I don't think we can close existing Universal share encoding issues until that is completed, and we should update the ADR to reflect the changes to the API there. Perhaps this was just confusion from the name of this PR?
func TestCompactShareContainsInfoByte(t *testing.T) { | ||
css := NewCompactShareSplitter(appconsts.TxNamespaceID, appconsts.ShareVersion) | ||
txs := generateRandomCompactShares(1, 100) | ||
|
||
for _, tx := range txs { | ||
css.WriteTx(tx) | ||
} | ||
|
||
shares := css.Export().RawShares() | ||
assert.Condition(t, func() bool { return len(shares) == 1 }) | ||
|
||
infoByte := shares[0][appconsts.NamespaceSize : appconsts.NamespaceSize+appconsts.ShareInfoBytes][0] | ||
|
||
isMessageStart := true | ||
want, err := NewInfoReservedByte(appconsts.ShareVersion, isMessageStart) | ||
|
||
require.NoError(t, err) | ||
assert.Equal(t, byte(want), infoByte) | ||
} | ||
|
||
func TestContiguousCompactShareContainsInfoByte(t *testing.T) { | ||
css := NewCompactShareSplitter(appconsts.TxNamespaceID, appconsts.ShareVersion) | ||
txs := generateRandomCompactShares(1, 1000) | ||
|
||
for _, tx := range txs { | ||
css.WriteTx(tx) | ||
} | ||
|
||
shares := css.Export().RawShares() | ||
assert.Condition(t, func() bool { return len(shares) > 1 }) | ||
|
||
infoByte := shares[1][appconsts.NamespaceSize : appconsts.NamespaceSize+appconsts.ShareInfoBytes][0] | ||
|
||
isMessageStart := false | ||
want, err := NewInfoReservedByte(appconsts.ShareVersion, isMessageStart) | ||
|
||
require.NoError(t, err) | ||
assert.Equal(t, byte(want), infoByte) | ||
} |
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.
[optional, prefer different PR due to timing]
I think this should be done in a different PR (if at all) since we want to optimize to merge into #692 asap
but we might refactor these tests into a table drive test that tests evidence and the rest of the shares that are exported. another super minor [nit], would be to use a formula to calculate the size of the random compact shares so that we can incorporate appconsts. (we don't do this other places, but should so that can probably be a separate PR too)
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.
can you please elaborate on
would be to use a formula to calculate the size of the random compact shares so that we can incorporate appconsts
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.
yeah sure,
instead of just using the number 100 or 1000, we could say appconsts.TxShareSize / 2
or appconsts.TxShareSize * 4
this does break #692, and I consider it to be blocking, since that PR should handle adding the info byte. We might also want to consider changing the estimation API and fixing tx inclusion before we merge that too |
InfoReservedByte
to compact and sparse shares
Is this question specifically for There is some ambiguity on when the start indicator should be
Agreed. Renamed PR to clarify.
Clarifying question: celestia-node should be able to call a function on any set of shares and get data out (i.e. transactions if the shares provided are transaction shares), right? I think celestia-node is relying on celestia-core's share parsing logic (see here). So I think upgrading them to a release of celestia-app with the existing (refactored) share logic is a prerequisite to converting them to using a new API exposed by celestia-app. So we likely need to cut a celestia-app release ASAP and tackle that separately. Created #723 for new API.
Sorry I don't quite understand. For clarity: this PR is blocking #692 so you want to expedite merging this PR - correct? |
also for compact shares, as I think that makes sense, wdyt?
yeah
not sure I follow entirely, as what we do in #723 will change all of this? The existing logic being this PR and the naming changes? Is this just to split up the changes necessary? edit: agree that we should get something out asap, but also want to limit the number of changes they need to make |
Makes sense, thanks for clarifying that only the first share of a reserved namespace should have the
Yep exactly. I'm proposing we split this process into multiple steps to reduce the size of PRs which may make it easier to identify regressions:
Agreed. Maybe we make the PRs to celestia-node because we're issuing the breaking changes and should know how to use the old / new APIs. |
agree that we need to put more thought into which releases we cut, as we also need to account for non-interactive defaults (which will could effect the plugin and definitely their future planning), qgb state machine (this will change how to initalize a network and therefore their tests) and the other breaking changes we have. We can isolate the encoding changes to their own release, tho yeah. lets discuss this sync outside of this PR |
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 still have a lot things going on with universal shares, but this is ready and isolated. Great work! happy someone else had to grok the encoding logic lololol
Implementation for #659
Note this may be easier for reviewers to review after #718 is completed. In the interim #660 may be helpful.