Skip to content
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

Merged
merged 40 commits into from
Sep 16, 2022

Conversation

rootulp
Copy link
Collaborator

@rootulp rootulp commented Sep 8, 2022

Implementation for #659

Note this may be easier for reviewers to review after #718 is completed. In the interim #660 may be helpful.

@rootulp rootulp self-assigned this Sep 8, 2022
This was referenced Sep 8, 2022
@rootulp rootulp changed the title Implement universal share encoding for compact shares Implement universal share encoding Sep 15, 2022
@codecov-commenter
Copy link

codecov-commenter commented Sep 16, 2022

Codecov Report

Merging #691 (b067e48) into main (566b3d4) will increase coverage by 0.16%.
The diff coverage is 63.79%.

@@            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     
Impacted Files Coverage Δ
pkg/shares/parse_sparse_shares.go 83.52% <54.54%> (-5.08%) ⬇️
pkg/shares/split_compact_shares.go 83.21% <60.00%> (-0.79%) ⬇️
pkg/shares/split_sparse_shares.go 66.66% <62.50%> (-2.85%) ⬇️
pkg/shares/parse_compact_shares.go 82.35% <75.00%> (+4.57%) ⬆️
pkg/shares/share_splitting.go 59.75% <100.00%> (-0.49%) ⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@rootulp rootulp marked this pull request as ready for review September 16, 2022 02:56
Copy link
Member

@evan-forbes evan-forbes left a 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

Copy link
Member

@evan-forbes evan-forbes left a 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?

Comment on lines +125 to +163
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)
}
Copy link
Member

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)

Copy link
Collaborator Author

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

Copy link
Member

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

@evan-forbes
Copy link
Member

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

@rootulp rootulp changed the title Implement universal share encoding Add InfoReservedByte to compact and sparse shares Sep 16, 2022
@rootulp
Copy link
Collaborator Author

rootulp commented Sep 16, 2022

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.

Is this question specifically for parse_sparse_shares.go? If so, good call! Done in 5c4fef7

There is some ambiguity on when the start indicator should be 1 for compact shares, see #660 (comment)

Perhaps this was just confusion from the name of this PR?

Agreed. Renamed PR to clarify.

celestia-node should be able to call a function on any set of shares and get a message out.

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.

this does break #692, and I consider it to be blocking, since that PR should handle adding the info byte

Sorry I don't quite understand. For clarity: this PR is blocking #692 so you want to expedite merging this PR - correct?

@evan-forbes
Copy link
Member

evan-forbes commented Sep 16, 2022

Is this question specifically for parse_sparse_shares.go? If so, good call! Done in 5c4fef7

also for compact shares, as I think that makes sense, wdyt?

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?

yeah

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.

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

@rootulp
Copy link
Collaborator Author

rootulp commented Sep 16, 2022

also for compact shares, as I think that makes sense, wdyt?

Makes sense, thanks for clarifying that only the first share of a reserved namespace should have the start indicator = 1. Addressed in b067e48

Is this just to split up the changes necessary?

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:

  1. Cut a release of celestia-app that includes the refactored share logic
  2. Upgrade celestia-node to ^ this version. Replace core on this line with an import from celestia-app (defined here)
  3. Add ParseShare API in celestia-app
  4. Cut a new release of celestia-app
  5. Upgrade celestia-node to ^ this version

but also want to limit the number of changes they need to make

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.

@evan-forbes
Copy link
Member

evan-forbes commented Sep 16, 2022

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

Copy link
Member

@evan-forbes evan-forbes left a 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

:shipit:

@rootulp rootulp merged commit b98f9ab into celestiaorg:main Sep 16, 2022
@rootulp rootulp deleted the rp/universal-share-encoding branch September 16, 2022 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants