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

Use namespaced storage for state variables when upgradeable #383

Open
ericglau opened this issue Sep 3, 2024 · 1 comment
Open

Use namespaced storage for state variables when upgradeable #383

ericglau opened this issue Sep 3, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@ericglau
Copy link
Member

ericglau commented Sep 3, 2024

From https://wizard.openzeppelin.com/#erc721, enable "Mintable -> Auto Increment Ids" and "Upgradeability". This adds state variable uint256 private _nextTokenId;to the code, and this can be enhanced to use namespaced storage as a best practice for upgradeable contracts.

(This is currently the only state variable added by Wizard, but this should apply for any state variable(s) being added by Wizard when upgradeability is enabled.)

@ericglau ericglau added the enhancement New feature or request label Sep 3, 2024
@ericglau
Copy link
Member Author

ericglau commented Sep 3, 2024

We should consider what to use as the namespace id here. Since this namespace belongs in the user's contract rather than in a contract library, this id should be somewhat unique for each user and reflect something that they can add variables to. In that case, we might want to allow users to customize this with a prefix like myproject, which results in a namespace id like myproject.MyToken.

However, namespace id conflicts could occur if different users inherit each other's code that uses the same namespace id if they don't change the defaults. The Upgrades Plugins will detect this though, and I'm not sure how likely this conflict scenario would be in the first place.

Ideally, users would just see a namespace in their contract and then use https://github.com/OpenZeppelin/openzeppelin-vscode to edit the namespace id and hash to whatever they want :) So perhaps having a generic default is enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant