So if I understand correctly, memory is reclaimed (hopefully zeroed) and reused by subsequent calls after a call returns. This differs from solidity’s memory management, where every allocation increments the free-pointer and memory is never reclaimed.
To make sure I understand, I’ll use an OS analogy. Sounds like it’s behaving similarly to the how memory management works on Linux: The brk/sbrk syscalls increase the memory size, setrlimit syscall can limit this size for the entire process, but higher level lib functions like malloc/free manage and reuse the memory, calling brk/sbrk only when they’re out of memory. Is that how memory managed for each transaction?
If that’s the case then indeed my EntryPoint example is incorrect. I assumed that each call counts towards the limit - separately. UserOps will not be able to affect each other.
However, subcalls are still affected. This can be abused by transactions that wrap 3rd party calls, such as intent protocols. A malicious solver may cause user calls to fail, while still getting paid for making them.
Well-written protocols mitigate the gas case by letting the user specify the required gas, checking for it using the GAS opcode and rejecting the entire transaction if user calls are given insufficient gas. EntryPoint for example is immune to this attack because it reverts the entire transaction if a UserOp is executed with less gas than it requested.
We’ll need a similar opcode to check available memory in order to mitigate such attacks. And another one for available transient slots with EIP-7971.