The current version of 8038 still charges in a very INEFFICIENT and harmful way to users, and although I have warned this out, the core devs seem to deliberately ignore it. The 8037 performed very well, but the 8038 seems to have been designed simply to fill the gaps left by previous proposals, it’s rough and full of areas that need optimization.
First, the cost for read-only operations (like SLOAD, EXT*), which read data from cache, so their warm access cost must be less than 100, perhaps only slightly more expensive than MLOAD. However, the cost of 100 is still valid for operations that include path processing REVERT (like xCALL, CREATEx). This means we need to have two types of warm access costs for each different group of operations.
Second, the refund for state access costs is sent directly to the refund counter, which is extremely inefficient because this gas gets stuck there and cannot be used effectively for subsequent operations. The principle is that only external fee sources should be controlled, such as the cost of refunding a slot clearing, in this case, a refund counter is necessary. Conversely, state access costs are internal resources, so including them in a refund counter is illogical. Ideally, we should add a separate counter for them, similar to the one used in the 8037.
Third, there is a lack of warm access cost for subsequent ether transfers on the same account. Currently, the cost per transfer is set as ACCOUNT_WRITE + CALL_STIPEND and is not differentiated between warm and cold cases while slot updates benefit from this incentive, this continues to create a barrier to the use of ether, which 2780 is trying to avoid. This disadvantage is evident in multisend operations, where continuously updating the ERC20 balance on the same account is cheaper than continuously updating the ETH balance on the same account.
Fourth, the refunds in this eip are unclear. Will refund if reverted? Will refund if an account updates its balance in the pattern x -> y -> x? In conjunction with the second point, the semantics of refund need to be reconsidered, perhaps splitting it into refund and refill similar to 8037. Currently, I only see refunds applied to storage updates.
Fifth, this is just a minor point. If an account has already had its balance updated before it becomes the target of CREATE, then we must discount the ACCOUNT_WRITE on the CREATE_ACCESS cost.
It’s almost impossible to remove it from Glamsterdam as it’s nearly complete, but I’d like to negotiate the calculations to be more advantageous for users before it’s integrated into the network. You can’t just increase fees without offering reasonable incentives to users.
