Content
@
0 reply
0 recast
2 reactions
Mikko Ohtamaa
@moo
Ethereum's EIP-1153 and why transient storage is needed https://etherworld.co/2024/01/08/eip-1153-and-transient-storage/
1 reply
0 recast
4 reactions
bbuddha
@bbuddha
Good read. Dyk why the prices of the opcodes are as high as they are? I would have guessed they would be much closer to the prices of memory operations…
1 reply
0 recast
1 reaction
Mikko Ohtamaa
@moo
State growth. More on this old post of mine https://capitalgram.com/posts/scaling-evm/
1 reply
0 recast
1 reaction
Mikko Ohtamaa
@moo
Also even if you release the space at the end of TX, normal sstore opcode still needs to go through the full process of updating the global state of EVM
1 reply
0 recast
1 reaction
bbuddha
@bbuddha
I think state growth isn't a concern since the storage is discarded. Looking at the EIP it seems like the concern is with reverts because each slot written to needs to be erased. I guess erasing different slots from a "not in linear memory" map encounters a lot more overhead than erasing linear memory...
1 reply
0 recast
1 reaction
Mikko Ohtamaa
@moo
Yep the problem is also you need to load the state with sload to know if the value is 0 or not
1 reply
0 recast
1 reaction
bbuddha
@bbuddha
Ah, would that encounter more overhead than a regular MLOAD? seems like they're both an indexed inmem lookup?
1 reply
0 recast
1 reaction
Mikko Ohtamaa
@moo
Memory is only within the contract (internal per call) - transiet stays across contract calls
1 reply
0 recast
1 reaction
