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

ADR 013: Non-Interactive Default Rules for Zero Padding #1161

Merged
merged 4 commits into from
Mar 16, 2023

Conversation

nashqueue
Copy link
Member

@nashqueue nashqueue commented Jan 3, 2023

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:

  • Add Graphics

Checklist

  • New and updated code has appropriate documentation
  • New and updated code has new and/or updated testing
  • Required CI checks are passing
  • Visual proof for any user facing features like CLI or documentation updates
  • Linked issues closed with keywords

@nashqueue nashqueue changed the title inital draft ADR 012: Non-Interactive Default Rules for Zero Padding Jan 3, 2023
@nashqueue nashqueue changed the title ADR 012: Non-Interactive Default Rules for Zero Padding ADR 013: Non-Interactive Default Rules for Zero Padding Jan 5, 2023
Copy link
Collaborator

@rootulp rootulp left a 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.
Copy link
Collaborator

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.

Copy link
Member Author

@nashqueue nashqueue Jan 6, 2023

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.

@nashqueue nashqueue marked this pull request as ready for review January 6, 2023 14:12
@nashqueue
Copy link
Member Author

Not sure why this housekeeping workflow is breaking

@MSevey
Copy link
Member

MSevey commented Jan 6, 2023

Not sure why this housekeeping workflow is breaking

seems like a bug with forks. I'm working on it. celestiaorg/.github#19

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.

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.

@nashqueue
Copy link
Member Author

Soon we will have multiple blobs per a single PFB.

What are the specs/ideas for ordering those blobs? What does the commitment of this PFB look like?

@MSevey MSevey requested a review from a team January 11, 2023 13:08
@evan-forbes
Copy link
Member

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)
Copy link
Member

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.

Copy link
Member Author

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.

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.

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

@nashqueue
Copy link
Member Author

Can we merge this as proposed? been idle for a while

@evan-forbes
Copy link
Member

evan-forbes commented Feb 20, 2023

@nashqueue yeah we can imo. I'd still like to get an accepted tbh, as I think its a really good optimization

Copy link
Collaborator

@rootulp rootulp left a 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

@musalbas
Copy link
Member

Btw I think the status field in these ADRs should be at the top so people can immediately see if they're proposed or accepted etc instead of only realizing it when they get to the bottom.

@rootulp rootulp mentioned this pull request Feb 20, 2023
rootulp added a commit that referenced this pull request Feb 22, 2023
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
@evan-forbes
Copy link
Member

merging as proposed, but we will have a sync discussion over this during the onsite

@evan-forbes evan-forbes merged commit c9dfc54 into celestiaorg:main Mar 16, 2023
@gitpoap-bot
Copy link

gitpoap-bot bot commented Mar 16, 2023

Congrats, your important contribution to this open-source project has earned you a GitPOAP!

GitPOAP: 2023 Celestia Contributor:

GitPOAP: 2023 Celestia Contributor GitPOAP Badge

Head to gitpoap.io & connect your GitHub account to mint!

Learn more about GitPOAPs here.

0xchainlover pushed a commit to celestia-org/celestia-app that referenced this pull request Aug 1, 2024
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
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.

ADR 013 Zero Padding for an upperBound FraudProofSize
6 participants