frangio
commented
2 years ago This is planned for the next major release. See prior discussion about this and an unofficial fork in https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2964. Feel free to chime in over there.
mdnorman
🧐 Motivation I used OpenZeppeiln 3.0 upgradeable base contracts back in the day for my system's contracts, and when I went to upgrade to OpenZeppelin 4.0, I ran into a ton of storage problems. Some of my contracts were pretty complicated, and the linearization of the several base contracts I had changed between 3.0 and 4.0 due to some requirements. Even something as simple as interface changes can cause linearization to change.
When using fields on a contract, linearization defines the order of the fields, so if linearization changes, it cause the upgraded contracts to look for data in different places than the original.
I eventually decided to move to the Diamond pattern, which meant rewriting all of the contract implementation into facets, but one of the things that I learned through this process is the Diamond Storage model. This avoids the issues I ran into above because fields aren't used at all: the only storage in the contract is stored in explicit locations.
I'm working on a new shared project, and I'd like to use OpenZeppelin upgradeable contracts because they're great, but I'd prefer to not run into this kind of issue again.
📝 Details See this article about the Diamond Storage model.
The Diamond Storage model avoids many of the storage issues around upgrades without needing "gaps" and getting around the linearization problem.
I realize this would be a breaking change, so it would need to go into the next major version, but just some thoughts around how we might make OpenZeppelin contracts even more upgradeable in the future.
It would be great in the future if there were an OpenZeppelin "Diamond Facets" set of contracts, and this could be a great stepping stone to that as well.