[SC-295] H-1 add storage slot gaps to layout

[0xNuggan]

What has been done

Added a storage gap to all upgradeable modules.

Open question

I also added gaps to non-upgradeable abstract contracts if they are going to be inherited by upgradeable ones. This specifically applies to the Bonding Curve contracts, where the Base contracts don't inherit from Module_v1. I'd be thankful for a double-check in that department.

[linear[bot]]

SC-295 Bug(H-1): Add storage slot gaps to layout

[marvinkruse]

I took the liberty of just deploying some changes. If you don't like these, feel free to reset to your last commit; no offense taken at all.

• Renamed all to __gap and put them to private
• Added the gap to the elastic receipt token (upgradeable version), to be safe

I just thought it might make more sense just to have them be named __gap and then have them as private, so (a) there is zero chance of interference and (b) some of the scripts that I know that validate the gaps before deployment don't like if they are called anything but just __gap. I know the OpenZeppelin script can work with that and allows __gap_*, but I just thought that there might not be a downside to just having them named uniformly. What do you think?

(As I said, if you don't like it, just revert and add the gap to the ElasticReceiptTokenUpgradeable as well.)

[0xNuggan]

Thanks for the review and the explainer! It makes total sense, let's keep it that way.

[marvinkruse]

As this is a "high" issue, one more review would be great, maybe @FHieser?

[0xNuggan]

But it's not upgradeable right? Am I missing something?

[FHieser]

All of the state it has is immutable Therefor it doesnt need an init So still upgradeable

[0xNuggan]

Added the gap