Extending the standard account interface, this proposal aims to standardize storage variable names for accounts where there’s a single signer.
Right now there’s equivalent but not homonymous variables in different account implementations (_signer in the Argent and Account_public_key in the OpenZeppelin one). This makes portability/upgrades unfeasible, since each implementation will look up for the same value in a different storage position. This proposal aims to define a standard variable name to account for it.
Following OpenZeppelin’s extensibility pattern, I believe this variable name needs to be prefixed with Account_ to avoid namespace pollution, preventing clashes with other variables. Alternatively, if this proposal ends up being a SIMP/SIP, then it could also make sense to prefix the variable name with its SIM/P number.
This way, single signer accounts should implement this standard storage:
@storage_var
func Account_public_key() -> (res: felt):
end
Bear in mind that this may require upgrading non-compliant accounts (such as Argent’s, and maybe Braavos’), which is anyway mandatory after StarkNet’s state reset.
25 Likes
Standardizing the storage variable name is unnecessary and risky in my opinion. It seems to imply that a shared variable name is enough to guarantee a successful upgrade, and it should be clear that there’s potentially a lot more that’s needed, if it’s possible to do the upgrade at all. Implementations may just be incompatible even if they use the same variable. For example, it may be the public key for an entirely different signature scheme (like ethereum vs. stark keys).
As far as I can tell, it’s not true that using different variable names makes an upgrade unfeasible, as it should be possible to upgrade to an intermediate migration contract that can copy or move the variable to the location required by the new implementation. This migration contract can perform additional safety checks to make sure the account doesn’t become bricked, like validating a signed transaction that is expected to work with the new account.
An account upgrade is a very sensitive operation so I think we need to promote a lot of caution around it. In summary, I would remove the storage variable name from the specification, or if we keep it I would add a warning to be clear that it’s not enough to guarantee a successful upgrade.
13 Likes