-
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
docs: update the blob module specs part 1 #1906
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1906 +/- ##
=======================================
Coverage 21.25% 21.25%
=======================================
Files 121 121
Lines 13679 13679
=======================================
Hits 2907 2907
Misses 10484 10484
Partials 288 288 |
the markdown lint will continue to fail until we merge #1905 |
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 PR with great details and information! 👍
I have included my comments below. However, please feel free to address them either in this PR or in subsequent PRs as you deem appropriate.
x/blob/README.md
Outdated
1. `NamespaceId []byte`: the namespace this blob should be published to. | ||
1. `Data []byte`: the data to be published. | ||
1. `ShareVersion uint32`: the version of the share format used to encode this blob into a share. | ||
1. `ShareVersion uint32`: the version of the share format used to encode | ||
this blob into a share. | ||
1. A single `sdk.Tx` which is composed of: |
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 think it would be beneficial to mention that the sdk.Tx
represents the encoded version of one or multiple MsgPayForBlobs
, and then introduce Signer
, NamespaceIds
, and ShareCommitment
as the components of MsgPayForBlobs
(basically what is already in the specs after the is composed of:
)
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.
added a link to the sdk ADR that discusses the structure of sdk.Tx, but perhaps we can talk about this more elsewhere? I'm quite sure what to do yet.
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] there's another param in the blob module for GovMaxSquareSize
apologies for the delay on incorporating all the great feedback here! I need to debug a few more things in node for the testnet hardfork and then I'll get to this 🙂 |
Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]>
….com/celestiaorg/celestia-app into evan/update-blob-module-specs-part-1
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.
Thanks for addressing the comment, it looks good to me!
In order for a proposal block to be considered valid, each `BlobTx`, and thus | ||
each PFB, to be included in a block must follow a set of validity rules. | ||
|
||
1. Signatures: All blob transactions must have valid signatures. This is |
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.
[Question for my own understanding] When the term "proposal block" is used in the context of "In order for a proposal block to be considered valid," does it refer to a block proposed during the consensus (and yet to be voted and committed) or one that has received the majority vote (hence committed)? I'm curious about when signatures and nonces are verified – during the voting phase or at the time of block execution (which I think corresponds to the processProposal). If signature verification is required during the voting process, then we would need to track the state changes resulting from proposals (but not committed blocks) in order to do so.
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.
does it refer to a block proposed during the consensus (and yet to be voted and committed) or one that has received the majority vote (hence committed)?
both! we call ProcessProposal on proposals beofore voting, and while consensus nodes sync the chain
signatures, and therefore their nonces, are verified before the block is actually applied to the state in both cases. State can then be tracked rather easily since we already have the state from the previous block, which is all that is needed.
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.
Only one blocking comment
x/blob/README.md
Outdated
in this message. See | ||
[ADR014](../../docs/architecture/adr-014-versioned-namespaces.md) for more | ||
details on how this effects the share encoding and when it is updated. |
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] ADR-014 doesn't describe share versions, it describe namespace versions.
ADR-007 introduces a share version: https://github.com/celestiaorg/celestia-app/blob/main/docs/architecture/adr-007-universal-share-prefix.md
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.
my bad thanks for catching 920760c
Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]>
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.
🚀
* docs: minor update to the blob module * docs: add validity rules * docs: update event field * docs: Apply suggestions from code review Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]> * docs: minor update * docs: fill out fields of PFB in new format and link to ADR014 for share verison * docs: elaborate on size consistency * docs: link to reserved namespaces * docs: clarify and add link * docs: share commitments * docs: typo and link to reserved name space * docs: add link to sharesize * docs: add more info for shares commitments * docs: review feedback Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]> * docs: use adr 007 * docs: add link --------- Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]>
* docs: minor update to the blob module * docs: add validity rules * docs: update event field * docs: Apply suggestions from code review Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]> * docs: minor update * docs: fill out fields of PFB in new format and link to ADR014 for share verison * docs: elaborate on size consistency * docs: link to reserved namespaces * docs: clarify and add link * docs: share commitments * docs: typo and link to reserved name space * docs: add link to sharesize * docs: add more info for shares commitments * docs: review feedback Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]> * docs: use adr 007 * docs: add link --------- Co-authored-by: Sanaz Taheri <[email protected]> Co-authored-by: Rootul P <[email protected]>
Overview
mostly a minor update to the blob module specs, but this PR also adds some validity rules for BlobTxs/PFBs
part of #650
Checklist