Would the overhead be too large if the SSTORE cost was dynamically calculated for each msg.sendertx.origin? Something like
where is the the current SSTORE operation cost for a given EOA i and N is the number of storage slot currently used for EOA i.
The cost doesn’t need to be linear. It seems to me like this creates an incentive for users to “clean” their storage or they pay a premium for every new operation. With this simple scheme, users could, however, just always create new accounts to reset the counter. This could perhaps be mitigated if the first SSTORE is much more expensive and if we use a logarithmic curve instead of a linear one when calculating SSTORE_i.
The advantages of a scheme like this would be that the UX would be identical as it is now and I believe it would be backward compatible with currently existing contracts.
That seems risky. That would mean that once a contract becomes big enough it’s unusable. Also, it is circumventable by creating child contracts that store storage keys and calling them to read/write to storage.
Sorry, I should’ve specified tx_origin, not msg.sender (basically track the EOA that calls the SSTORE). Hence it’s independent of contract size, but tracks how much each user fills storage slots in the contracts they use. I don’t think this could be avoided by using child contracts or some proxy contracts.
It does become a bit weird when thinking of Meta-tx and relayers/operators, but that could be solved by having them find a L2 fee structure that makes sense to cover the costs.
I have some doubts in understanding the proposal completely.
Regarding Step-1, In case of eviction, will state data along with the account information of the contract will be deleted. If that is the case, then when reviving the contract, a Merkle proof of the account information should be provided. So we will know the nonce information during revival. So can you please help me understand what am I missing as a new replay protection mechanism was described ?
In an eviction transaction, SYSTEM account makes a call to the <writer> contract with the call data containing the address of the <owner> contract, with a stipend proportional to the size of evicted storage.
How is an eviction transaction triggered, if a contract is untouched for a long time as it was mentioned that calculation of dues happen only when account is modified by EVM ?
On Step-2, only non-contracts are evicted, and they don’t have meaningful state data, apart from balance (which would be 0 at the time of eviction), and nonce (which will be changed at the revival).
At Step 4, when contracts are getting evicted, the recovery scheme is provided.
It is triggered by priority queue, which is described on pages 31-38
is the the current SSTORE operation cost for a given EOA