Content
@
https://opensea.io/collection/dev-21
0 reply
0 recast
2 reactions
eric.base.eth 🔵
@ericbrown.eth
Solidity v0.8.29 includes syntax for relocating a contract's storage variables to an arbitrary location. This is necessary to make EIP7702 secure. Put together a quick thread that makes clear why this is the case: https://x.com/0xEricBrown/status/1900189049026998457
1 reply
2 recasts
10 reactions
Mo
@meb
Super cool, is there any reason to not continue using hard coded storage locations ie. hashing a variable name into a pointer and using that pointer directly?
1 reply
0 recast
0 reaction
eric.base.eth 🔵
@ericbrown.eth
I’d only recommend custom storage implementations (at the contract or variable level) when there’s a clear need due to clashing risk. Otherwise you’re introducing unnecessary attack surface and making code less legible
1 reply
0 recast
0 reaction
Mo
@meb
Interesting, assuming we are using something like open zeppelin storage slot to manage the getters and setters, and we don’t have methods that allow writing code to arbitrary locations, what is the security risk? And secondary question, with this new upgrade you’ve developed, will it fix the issue of consecutive memory slots? I’d like to be able to clean up contracts and reorder variables without that
1 reply
0 recast
0 reaction
eric.base.eth 🔵
@ericbrown.eth
To clarify, I didn’t do anything here it was all the Solidity team. Just excited about the change they made. This specific change doesn’t relate to consecutive memory (and for everyone else remember memory doesn’t use slots like storage, it’s one long byte string that gets appended to) From your description there shouldn’t be any risk, ofc can’t say for certain without seeing the code itself. Really I’m just evangelizing the YAGNI coding best practice of only implementing complex logic if it’s truly necessary
1 reply
0 recast
1 reaction
