-
Notifications
You must be signed in to change notification settings - Fork 305
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
ADR 013: Non-Interactive Default Rules for Zero Padding #1161
Conversation
docs/architecture/adr012-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
docs/architecture/adr012-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
docs/architecture/adr012-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
docs/architecture/adr012-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
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.
mostly nits, thanks for the diagrams!
|
||
![Worst Case Padding In Blob Size Range](./assets/worst-case-padding-in-blob-size-range.png) | ||
|
||
This means that you get more padding for fever data in small blobs. This is not ideal as we want to have as little padding as possible. As padding is not being paid for there is no incentive to use larger blobs. |
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.
[typo]: "for fever data"
Apologies for no suggestion. I'm not sure what it meant to say.
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.
I rephrased: This means small blobs generate more possible padding in comparison to the data they provide. This is not ideal as we want to have as little padding as possible. As padding is not being paid for there is no incentive to use larger blobs.
docs/architecture/adr013-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
docs/architecture/adr013-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
docs/architecture/adr013-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
Not sure why this housekeeping workflow is breaking |
seems like a bug with forks. I'm working on it. celestiaorg/.github#19 |
docs/architecture/adr013-non-interactive-default-rules-for-zero-padding.md
Outdated
Show resolved
Hide resolved
docs/architecture/adr013-non-interactive-default-rules-for-zero-padding.md
Show resolved
Hide resolved
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.
Overall I really like this proposal!! It makes a lot of sense.
Soon we will have multiple blobs per a single PFB. We might want to also want to include some discussion of how this proposal would affect those as well. If there are many small blobs, then might need to use the same threshold mechanism used for large blocks.
[kinda orthogonal discussion]
I believe there was some discussion during the onsite of incorporating resource pricing into a similar proposal, and it might work here as well. Provided we have precise insight into the actual cost to the network each of these options bring, then we can change the cost of gas accordingly. For example, if your blob can have a suitably small inclusion proof while also not taking any padding, then we might want to decrease the amount of gas used for that blob.
What are the specs/ideas for ordering those blobs? What does the commitment of this PFB look like? |
Currently, the PR has a merkle tree over all of the commitment, but as discussed in #1154 and #1231, we will revert that and simply include each share commitment in the PFB. Originally we decided to move writing the ADR until after the feature freeze, but we might have to start it before that, as this topic requires more thought and buy-in |
|
||
The picture below shows the difference between the old and new non-interactive default rules in a square of size 8 and a threshold of 8. | ||
|
||
![Blob Alignment Comparison](./assets/blob-alignment-comparison.png) |
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.
I might be missing something but can you elaborate on how this works with the commitments that are independent of square size?
For example, the orange blob would appear to me to have different commitments in the two examples, and so I'd assume it would have a different commitment based on what other data is include in the block.
Or is the intent of this ADR only to focus on reducing padding to the absolute minimum, and not necessarily have padding independent commitments.
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.
It is conseues breaking as it changes the non-interactive default rules. The 2 pictures have 2 different NI-Rules. One before and one after. If you decide on one NI rule it can be either independent of square size or not. In this case both are independent of square size. My goal was to reduce padding and it just happened to almost eliminate padding.
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.
continuing from #1161 (review)
I think the remaining question is that if there are use cases where we need to verify many blob inclusion proofs, which afaiu is the only case where this would have an effect. State fraud proof producing partial nodes might be that case, where we are increasing the average size for all of the proofs that they have to download, but perhaps they could rely on other nodes to produce fraud message inclusion fraud proofs.
Despite that, I think this would make a great addition and makes a lot of sense! I will defer to other reviewers though, and am looking forward to other's opinions
Can we merge this as proposed? been idle for a while |
@nashqueue yeah we can imo. I'd still like to get an accepted tbh, as I think its a really good optimization |
4d37a03
to
6d4dff0
Compare
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.
Great work @nashqueue ! Really informative ADR
Btw I think the |
Addresses #1161 (comment) ## Questions 1. Do we want to make the same change across other celestiaorg repos? 2. Should we consider an org wide ADR template? 1. #1415
merging as proposed, but we will have a sync discussion over this during the onsite |
Congrats, your important contribution to this open-source project has earned you a GitPOAP! GitPOAP: 2023 Celestia Contributor: Head to gitpoap.io & connect your GitHub account to mint! Learn more about GitPOAPs here. |
Addresses celestiaorg/celestia-app#1161 (comment) ## Questions 1. Do we want to make the same change across other celestiaorg repos? 2. Should we consider an org wide ADR template? 1. celestiaorg/celestia-app#1415
Overview
This ADR looks at the possibility of reducing intra-blob padding to close to zero in most cases.
rendered
closes rollkit/rollkit#640
Todo:
Checklist