bLakStArPulse

Here's a concrete example of how Glamsterdam repricing breaks existing assumptions around Uniswap v4 smart contracts. (Not an exploit: nothing is live yet + the problem was already known to security researchers in the summer.) v4 PositionManager allows contracts to subscribe to LP positions and get notified when the position is changed or transferred. This is useful for staking and rewards distribution, but it means calling untrusted 3rd party code from a protocol contract. The protocol wants to ensure that such a subscriber is not able to (1) DoS the operations around the position; (2) consume unlimited gas. Conversely, as long as (1) and (2) hold, an honest subscriber should keep getting notified when something happens to the position. To enforce 1-2 around the `unsubscribe` operation specifically, v4 deployments limit the gas that can be consumed by it. On mainnet, the limit is 150k - a protocol config setting. (It used to be 1% of the block's gaslimit, which is a more futureproof design, but was changed to a per-deployment constant before launch.) Before Glamsterdam, creating new state used to cost around 22k gas per slot - so the 150k limit was plenty for that. Afterwards, it costs around 110k for a single slot, so the subscriber may well run out of gas if it's writing any new slots. The saving grace is that around 90% of that gas is paid from a separate pool - the "state gas reservoir". So if the reservoir is present, it's used until it gets empty; then the tx starts consuming regular gas. The reservoir is only present when the initial tx gas is set above 16M (the max gas limit for normal gas - yes it's confusing!). If the user fails to do that AND the 150k limit is insufficient, they will leave the subscriber in a broken state after an `unsubscribe` call. The mirror reflection of this problem is that when the subscriber wants to go wild, it can. If the user sets the gas limit to 16M + X, the subscriber can spend most of that X - it will not be capped by the 150k gas limit configured in the Uniswap contract. This is a griefing attack, not a DoS. The good news is that the breakage is due to new state creation, it can be prevented if the user sending the tx sets a large enough gas limit. (At the expense of becoming more vulnerable to gas griefing.) But regular gas *also* gets repriced in Glamsterdam. Existing storage writes also get more expensive - and they are not funded from the reservoir - so the user cannot fully prevent breakage in some edge cases. Whether and how these affect some real contracts is something EF must be checking now.