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

ADVZ PayloadProver support requests that span multiple polynomial #424

Closed
ggutoski opened this issue Nov 22, 2023 · 0 comments · Fixed by #438
Closed

ADVZ PayloadProver support requests that span multiple polynomial #424

ggutoski opened this issue Nov 22, 2023 · 0 comments · Fixed by #438
Assignees
Labels

Comments

@ggutoski
Copy link
Contributor

ggutoski commented Nov 22, 2023

tl;dr

ADVZ PayloadProver currently fails if a proof request spans multiple polynomials. Remove this restriction.

// TODO TEMPORARY: forbid requests that span multiple polynomials
if range_poly.len() != 1 {
return Err(VidError::Argument(format!(
"request spans {} polynomials, expect 1",
range_poly.len()
)));

Background

Distilled from zulip:

  • In the past we vaguely intended that each namespace would correspond to 1 polynomials in the ADVZ payload partition. In this case the sequencer must take into account these polynomial boundaries when it builds the block payload bytes. ie. sequencer must leave zero padding between namespaces so that each namespace starts a new ADVZ polynomial.
  • Complication: how to handle small namespaces? The vague intuition is to pack many small namespaces into a single polynomial. I guess it would be the sequencer who decides which namespaces get packed and which get their own polynomial.
  • It's hard to do this without breaking abstraction: an abstract VID scheme doesn't know anything about polynomial boundaries.
  • A hacky solution: defining an abstract notion of "alignment" in a general VID scheme. So we could have next_alignment_boundary(index) -> Option<usize>. A VID scheme that doesn't care about alignment can just return None, ADVZ can return the next polynomial boundary.
  • Alternative: abandon the rule of 1 namespace per polynomial and just accept the fact that jellyfish namespace proofs might not align well with polynomial boundaries.

Conclusion

Ignore polynomial boundaries for now. We'll revisit later if we run into perf issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant