Make ERC1967Upgrades a library instead of an abstract contract #4325
Conversation
🦋 Changeset detectedLatest commit: 875b37b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Amxx
force-pushed
the
refactor/ERC1967Upgrade-library
branch
from
b2c680e
to
33f0adc
Compare
|
Sorry for asking this now but can you remind me why we want this to be a library? I don't see a clear benefit at the moment. |
|
Ok, this seems like one of the strongest reasons for me. My main concern was that the functions implicitly access storage, which is not something I'd usually expect from a library. What do you think about this? |
|
I don't see that as an issue. IMO it's explicit that the ERC1967Upgrade library provides helper to interact with the ERC1967 storage slots. It's not like the abstract contracts was declaring the storage explicitely either. |
| // Upgrades from old implementations will perform a rollback test. This test requires the new | ||
| // implementation to upgrade back to the old, non-ERC1822 compliant, implementation. Removing | ||
| // this special case will break upgrade paths from old UUPS implementation to new ones. | ||
| if (StorageSlot.getBooleanSlot(_ROLLBACK_SLOT).value) { | ||
| _setImplementation(newImplementation); |
There was a problem hiding this comment.
It looks like we should be able to remove this in 5.0 since we are not guaranteeing upgradeability from 4.x versions.
Additionally, I don't understand why this function is in ERC1967Upgrade. It's not really ERC-1967 and if we rename this to ERC1967Utils this becomes even clearer IMO.
It's not exactly ERC-1822 either because we never submitted an update to extend the ERC with the semantics of proxiableUUID we're using.
I don't see why we can't put this logic directly inside UUPSUpgradeable. What do you think?
There was a problem hiding this comment.
I implemented this change but I think it deserve a dedicated PR
(two small PR are easier to review then one big IMO)
WDYT?
frangio
changed the title
| @@ -29,7 +29,7 @@ npx @openzeppelin/upgrade-safe-transpiler@latest -D \ | |||
| -x 'contracts/proxy/**/*' \ | |||
| -x '!contracts/proxy/Clones.sol' \ | |||
| -x '!contracts/proxy/ERC1967/ERC1967Storage.sol' \ | |||
| -x '!contracts/proxy/ERC1967/ERC1967Upgrade.sol' \ | |||
| -x '!contracts/proxy/ERC1967/ERC1967Utils.sol' \ | |||
There was a problem hiding this comment.
Aren't we ignoring libraries for transpilation already?
If so, let's also create an issue with good-first-issue label
There was a problem hiding this comment.
That is part of the partial transpilation proposal
There was a problem hiding this comment.
Basically the library are needed by the contracts, so if we don't transpile them we need to get them from somewhere.
The partial transpilation proposal is to not transpile the libraries and the interfaces, and import the vanila version instead. (this creates a dependency from the upgradeable contracts to the vanilla contracts)
Fixes #4204
Fixes LIB-880
This PR requires 0.8.20, and forces it in
ERC1967Upgrades.solfor the following bugfix:PR Checklist
npx changeset add)