MIP-4: Reserve Balance Introspection

MIPs
1

This MIP adds a new opcode that allows contracts on Monad to detect whether their local execution state is in violation of reserve balance and take action to avoid reverting.

4 Likes
4

Re gas cost

Expected to be `O(N)` in the number of warm accounts (i.e., accounts with modified balances).

Would it be feasible to:

  1. Keep a cache of reserve balance check results per warm account address (with a count of failed checks for quick lookup)
  2. Run the reserve balance check only on crossing boundaries where it actually might change. I think that is at transaction start (after auth processing) CALLwith value!=0 and CREATE and SELFDESTRUCT and call frame reverting.
  3. Run the check and update cache only for affected addresses (1 or 2 max per such op)
  4. Have CHECKRESERVEBALANCE just return the cached result

Then it would be possible to price CHECKRESERVEBALANCE at O(1) (and as cheap as an environment opcode)?

The cost of checking and updating would be assumed to be included in the (expensive) ops from (2.). Cost of memory to hold the extra execution state included in cold access cost.

Motivation

  • simpler testing
  • cheaper for users
  • scales better with # of UserOps in a bundle, i.e. gas cost of a UserOp doesn’t depend on previous ones executed