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

Reserve the last 256 namespaces for the protocol #2253

Closed
Tracked by #2256
evan-forbes opened this issue Aug 11, 2023 · 2 comments · Fixed by #2257
Closed
Tracked by #2256

Reserve the last 256 namespaces for the protocol #2253

evan-forbes opened this issue Aug 11, 2023 · 2 comments · Fixed by #2257
Assignees
Labels
consensus breaking modifies block validity rules in a way that will break consensus unless all nodes update their rules

Comments

@evan-forbes
Copy link
Member

as originally proposed by @cmwaters, in a similar fashion to how we are reserving the first 256 and the last namespace for the protocol, we should also reserve the last 256 namespaces.

@evan-forbes evan-forbes added consensus breaking modifies block validity rules in a way that will break consensus unless all nodes update their rules and removed needs:triage labels Aug 11, 2023
@rootulp rootulp self-assigned this Aug 11, 2023
@rootulp rootulp added this to the Mainnet milestone Aug 11, 2023
mergify bot pushed a commit that referenced this issue Aug 14, 2023
Closes #2253

(cherry picked from commit cb8247e)

# Conflicts:
#	pkg/namespace/consts.go
#	pkg/namespace/namespace.go
#	pkg/namespace/namespace_test.go
#	pkg/shares/padding.go
#	specs/src/specs/namespace.md
@musalbas
Copy link
Member

What's the rationale for this?

@rootulp
Copy link
Collaborator

rootulp commented Aug 22, 2023

IMO the same reason the protocol reserves namespaces at the beginning of the namespace range. With these two namespace ranges, the protocol can introduce new reserved namespaces that have never been used by applications (a.k.a roll-ups). This is beneficial to avoid a breaking change for applications that would force them to migrate namespaces.

Why is the chunk at the beginning of the namespace range (a.k.a primary reserved namespaces) not sufficient? I think the chunk at the end of the range (a.k.a secondary reserved namespaces) is useful if we want a new reserved namespace to come after all blobs in the ODS (similar to tail padding and parity namespaces).

cmwaters pushed a commit to celestiaorg/go-square that referenced this issue Dec 14, 2023
0xchainlover pushed a commit to celestia-org/celestia-app that referenced this issue Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus breaking modifies block validity rules in a way that will break consensus unless all nodes update their rules
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants