AppVersion should be present in structs that use versioned consts

Celestia Improvement Proposals (CIPs)
1

Hey! I’m from Lumina team. We started implementing versioned consts from appconsts and we encounter some issues while incorporating them in our celestia-types crate.

These are the issues:

  • SubtreeRootThreshold is used when Blob.Commitment is computed, however AppVersion is only present in ExtendedHeader. So if a user requests a Blob, they need first to request ExtendedHeader, then Blob and then pass the AppVersion in order to get the Commitment. In celestia-node you workaround this by having a fixed version of constants, which we believe it is going to be an issue later on.
  • ExtendedDataSquare has a theoretical MAX_EXTENDED_SQUARE_WIDTH, which is SquareSizeUpperBound * 2. We use this value to validate EDS, but now this check can not be really done. We are unsure what to do about it. In order to keep this check then we need to apply restrictions on type-level and force user to give us the ExtendedHeader on validation.
  • DataAvailabilityHeader has also a theoretical MAX_EXTENDED_SQUARE_WIDTH, however DataAvailabilityHeader exists in ExtendedHeader and you can not retrieve it independently. Because of that we can pass ExtendedHeader.Header.Version.App when we do the validation.

We believe AppVersion should be added in all structs that need versioned consts and can be fetched on independently with an API call.

1 Like
2

Adding to that, CIP-21 introduced a namespace version 1, which is only valid for blocks in appversion v3. So to validate any shares obtained from the rpc, the appversion is required too.

3

Thank you for adding this to the forum. In an effort to get more visibility on this discussion, it’s been recommended in Core Devs Call 18 to move this to Issues · celestiaorg/celestia-app · GitHub

Can you please repost this there @oblique ? I’m sorry for the confusion here.