-
Notifications
You must be signed in to change notification settings - Fork 383
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
Comments
What's the rationale for this? |
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). |
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.
The text was updated successfully, but these errors were encountered: