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

Namespace storage #420

Merged
merged 21 commits into from
Jul 18, 2024
Merged

Conversation

minghinmatthewlam
Copy link

@minghinmatthewlam minghinmatthewlam commented Jul 11, 2024

Why this should be merged

Fixes #415

How this works

Adds namespace storage to all contracts according to ERC7201. Namespace storage helps prevent collision between storage of different logic contracts when used in the context of upgradeable contracts and proxies.

Changes:

  • all state variables are added to the contract's storage struct
  • the storage struct is specified a specific storage slot with @custom:storage-location according to erc7201
  • private variable for getting back the storage location
  • private getter function and assembly to save storage struct inside $ struct

How this was tested

CI
TODO: should ideally have unit tests to make sure that the storage location are computed correctly.

How is this documented

TBD

@minghinmatthewlam minghinmatthewlam marked this pull request as ready for review July 12, 2024 18:11
@minghinmatthewlam minghinmatthewlam requested a review from a team as a code owner July 12, 2024 18:11
*/
mapping(address teleporterAddress => bool paused) private _pausedTeleporterAddresses;
// solhint-disable private-vars-leading-underscore
/// @custom:storage-location erc7201:teleporter.storage.TeleporterUpgradeable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my own understanding, do you know why the custom storage location has three forward slashes? This seems to be the convention in OZ's docs as well as the EIP 7201 spec, but I couldn't find any justification for it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not understanding the rationale behind this was bothering me also...dug into it and my mind was blown 😅
image

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So "///" is for single line natspec comments, and "/**" is for multi-line natspec comments.

(Where all natspec comments start with a @ tag, and can be used to auto-generate docs)

@@ -22,7 +22,15 @@ abstract contract TeleporterOwnerUpgradeable is TeleporterUpgradeable, OwnableUp
address initialOwner
) internal onlyInitializing {
__TeleporterUpgradeable_init(teleporterRegistryAddress);
__Ownable_init();
__Ownable_init_unchained();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, __Ownable_init vs __Ownable_init_unchained doesn't have any functional difference here.

For my understanding, is there a reason why __Ownable_init_unchained should be preferred? Seems like the normal _init would be recommended unless there is a specific need to ensure none of the Ownable parent initializers are called

Copy link
Collaborator

@michaelkaplan13 michaelkaplan13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question, but LGTM

Upgrading to OpenZeppelin v5 and Solidity 0.8.20
@minghinmatthewlam
Copy link
Author

merging into #397

@minghinmatthewlam minghinmatthewlam merged commit 5d0c6d9 into upgradeable-poc-merge Jul 18, 2024
10 checks passed
@geoff-vball geoff-vball deleted the namespace-storage branch August 1, 2024 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants