I want to understand the main position better in relation to contract storage:
- If currently existing contracts are NOT upgradeable, they will loose their storage and need to be redeployed (potentially at the same address). From this point on they can use either active or reactive maintenance approach.
- If currently existing contracts are upgradeable, they will be able to transition into maintenance without the extra step of redeployment.
In either case their code needs to change.
If so, here comes a proposal in relation with this statement:
If the notion of rent is introduced without a “safe place” to migrate to, the only recourse of current contracts would be to use reactive maintenance approach, in the form of stateless contracts, which might too big of a leap in terms of usability.
If contracts need be updated with new code, do they really need a “safe place”? They could be rewritten into state-minimized versions with slightly modified interfaces. Very simple steps could go a long way:
- increase storage op-code cost a lot.
- create op-code that manages account storage root directly at old sstore/sload price.
- provide a precompile that allows to cheaply verify patricia merkle proofs in solidity.
- extend the ERC20/721 interfaces with a param to pass proofs.
this would give you:
- reduced problem space to managing rent on account-level only.
- contracts are incentivized to be written so that they manage the storage root themselves with off-chain data.
- You have a fallback for all the lazy guys (old sstore/sload) that comes at cost.
- new market of trust-free data service providers that hook as proof-providers into web3.js.