A place for developers to talk about building on Farcaster.

/dev

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:

▫️v0.8.29 brings us syntax for relocating a contract's storage variables to an arbitrary location, one of the oldest and most discussed feature requests in our issue tracker.

[EIP-7702: Set EOA account code] in the Pectra upgrade has made this feature critical for safe… https://t.co/fBLeuRyAPI

Finally!!! I spent months toiling away in mines of solidity storage. This pattern will significantly improve security for EIP-7702

A quick thread on why this is necessary for the security of EIP-7702: https://t.co/RchelK3kZe

eric.base.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

leading DevRel @base | former founder building onchain since '17 | sharing insights from the onchain frontier

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?

Designing and building AI systems

https://agents.gladio.ai

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

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

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