Content
@
0 reply
0 recast
2 reactions
Dragan Rakita
@draganrakita
Why dont we have EXTSTORAGE opcode? I mean, reading storage directly from other contract is probably desirable and data is already public.
6 replies
1 recast
4 reactions
✳️ dcposch on daimo
@dcposch.eth
Hmm, a contract that does “X, but only if slot 100 in contract Y” seems hard to reason about. What makes it desirable? What would you use it for?
1 reply
0 recast
2 reactions
Dragan Rakita
@draganrakita
Why it is hard to reason about that, i mean slot 100 can be a constant or something not exposed, and it should be cheaper to fetch. I dont know about usage, didnt think a lot about it, but it feels like a more open access (with proofs) to public state is nicer to have then closed access.
1 reply
0 recast
0 reaction
Danno Ferrin
@shemnon.eth
A big problem is you may not know how the contract handles or uses it's storage, especially if it is an upgradeable proxy. There could conceivably be "junk" storage with no meaning, or former meaning. "Read the code" isn't too far removed from executing it off chain.
1 reply
0 recast
3 reactions
Dragan Rakita
@draganrakita
Sure, that is a problem, and would argue a bad use case for extstorage where the code can change, but I am unsure what is good one.
1 reply
0 recast
0 reaction
✳️ dcposch on daimo
@dcposch.eth
I think any new opcode would need a really compelling use case, like reentrancy protection for TLOAD/TSTORE
1 reply
0 recast
0 reaction
Dragan Rakita
@draganrakita
push0 had a optimization impact and small effort to add, this is not the same but it is smaller change (at least in revm) than tload/tstore. For the impact and use case I was wondering about it, and what killer feature would this bring, but other than optimization or lack of fn in original bytecode idk.
1 reply
0 recast
0 reaction
