from the L2 interop working group:
would you confirm that arbitrary storage access is safe / storage limitations disappear w 7701? This feels at odds with the abstract of 7562 as I currently understand it (ERC-7562: Account Abstraction Validation Scope Rules)
Technically, we could add any slot that contain “A” at any offset. however, we tried to stick to common usages, by popular languages (solidity, vyper): “mappings” and “arrays”
No, this is a mistake: the validation rules come to protect the mempool for DoS attacks, and are applied similarly erc-4337 and eip-7701
This is a very interesting suggestion.
If I understand correctly, you are referring to the storage slot key (location) starting with the address, i.e., SLOAD( address << 96 | ... ).
Theoretically, this should actually be easier for bundlers to validate than the current keccak rule. With the current rule, the bundler needs to know the pre-image of the hash to verify it is “associated” with the entity. With your proposed rule, the association is explicit and visible directly in the slot key itself without needing to resolve a hash.
This would allow for highly optimized Yul/Assembly accounts that skip the hashing cost. Do you have a specific implementation or modular account design that is currently hitting this limitation?
Using an address directly as an index is making the address an array index, not a mapping key.
This works, but it blocks common use-cases. Since it requires 160 bits of the slot address range, you can have just a single such array in your contract
Eg. Go can’t create a token using this “indexing”. a token need one array of values, and a second 2-d mapping of approvals.
In order to use multiple mappings (or multi-dimensional mappings) in a contract, you must make the mapping keys a hash.
This part is especially interesting to me:
Having accounts depend on each other as part of the UserOperation validation presents a serious challenge.
One framing I’ve been exploring is whether some of this pressure can be reduced by making the account’s lifecycle more explicitly phase-separated:
In other words, instead of trying to make validation itself expressive enough to depend on more external smart-account behavior, maybe the safer direction is to make validation intentionally narrow and move richer coordination into later phases with clearer boundaries.
Do you think ERC-7562 would benefit from more explicit guidance in that direction for modular / multi-module smart accounts?
For example: “cross-account or cross-module dependencies should be represented as execution-phase checks unless the depended-on component is promoted to a first-class staked entity.”
I’ve been thinking about this from the modular AA side here as well:
