I would support opening a PR that reduces the costs to the proposed values, there is going to be some overhead in the implementations themselves that would make the maximum memory allocated higher than in the formulas. I have some code locally that uses https://github.com/fjl/memsize to observe the size of the transient storage struct after filling it up with a ton of bytes. If we can come to an agreement on what the safe max size is, then I can add a test to the geth implementation for that. Perhaps 15mb? Would need to run it again with the new values to see where its at.
I think we should also come to agreement on the bytes that represent the opcodes themselves, because in its current state different implementations are using different numbers.
https://github.com/ethereumjs/ethereumjs-monorepo/pull/1768uses0xa5and0xa6https://github.com/tynes/go-ethereum/tree/eip1153uses0x5cand0x5dhttps://github.com/cfromknecht/solidity/tree/5aaf51f82e7acd9c50406332e2acb4e175b7572auses0x5cand0x5dhttps://github.com/vyperlang/vyper/tree/transientuses0x4Eand0x4F
The Ethereum JS VM implements Simple Subroutines which use 0x5c and 0x5d
but I think the codegen would be better if TLOAD and TSTORE were byte addressed instead of word addressed like SLOAD and SSTORE
I’m definitely not opposed to this but would want more feedback from people first. Perhaps @AlexeyAkhunov @axic?
Maybe worth it to price in a transient storage expansion cost, to model cost going up as you approach OOM.
I’d prefer to not have dynamic costs if possible since that would increase the complexity of the implementations, but that would make it much safer against mass TSTORE’ing.