VIP: override storage slots using @ slot annotations

[banteg]

Simple Summary

• deprecate --storage-layout-file option in favor of storage slot override syntax
• introduce name: type @ slot syntax for storage slot override

Motivation

• overriding all storage slots is cumbersome and rarely needed. partially overriding storage slots can make it possible to support certain eips like eip-1967 that require certain positions in a very clear manner.
• --storage-layout-file is little known and has poor tool support. neither of vyper's own standard json input (until recently), etherscan verification, ape-vyper or vvm have support for it. having it in the contract itself makes the support from upstream tools follow naturally.

Specification

• deprecate --storage-layout-file option of the compiler
• introduce new syntax to partially override storage layout using the @ aka matmul operator, which doesn't require any special parsing since it's a native python operator. the slot value must be a uint256 literal value.

Example usage

implementation: public(address) @ 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
admin: public(address) @ 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103

Alternatives considered

one of the rejected alternatives was supporting a common convention of uint256(keccak256("text")) - 1 natively. note that this example needs either parenthesis or special handling from the compiler because @ has higher precedence than -.

implementation: public(address) @ (keccak256("eip1967.proxy.implementation") - 1) 
admin: public(address) @ (keccak256("eip1967.proxy.admin") - 1) 

Backwards Compatibility

this vip deprecates functionality in favor of new design. it doesn't introduce backwards incompatibility for contracts that don't use storage slot overrides.

Dependencies

this vip doesn't have any dependencies blocking it.

References

this vip supersedes https://github.com/vyperlang/vyper/issues/2572

Copyright

Copyright and related rights waived via CC0

[charles-cooper]

my biggest concern here is "partially overriding storage slots". it seems like a footgun, where some slots are overridden (ostensibly for the purpose of making a contract upgradeable) and some other slots are not, and then they get trampled during a contract upgrade.