i don’t know about linear storage i mainly just think that this eip is a good idea and that many instructions could be made easier and even removed if there is a memory like this. it feels like everything that has to do with transaction-wide data and contract-to-contract messaging is a form of hack. that itself is not a problem i guess since it works fine, but maybe the hacks are becoming too many, and it also seems to be the way forward.
actually my solidity evm has linear storage since i wanted it to reside only in the vm memory. it also does all invocations in the same actual vm (only internal functions) - so running it is one single call to a view function. it would probably be easy to emulate the stuff you’re suggesting in there.
you have to be more specific though, are you talking about a space that is editable by any contract? like one single “scratch space” that is read writable by any contract that wants to?
hmm maybe that’s preferable to the behemoth system i am envisioning…
i guess static variables in the way i think about would not be feasible. at least things like reentrancy locks would be better solved with gas netting then putting in a tx wide memory that is not reserved for a single account, but i guess library stuff like you suggest would be plenty more efficient since you would only have to write it once.
and i guess the single scratch space could be used for other call and return data too.
I have thought about this some more, and done some more experimentation.
It seems like the security issue with calldata/returndata is tied to whether or not the transient memory is cleared in combination with a call or return. If not, then it is very bug prone. If it is, that makes it useless for what it was originally intended for which is to store data between calls (all it would become is essentially a merging of the current calldata and returndata memories)
If a map with one memory for every address is implemented, the evm could use address 0 as a combined call/return data storage, used by the various return, calldata, and call instructions, but the other ones would be writable to only by a single contract account each, so the efficient data editing by other accounts would not work. Also, regardless of how it’s implemented, it would be an enormous new component. Real static variables would be fully supported though.
If there is only the scratch space then that would be good for the libraries, who could pass data very efficiently, but that’s all it would be good for - no static variables, not possible to use for regular calls/returns, which means it would require a new memory + new instructions on top of those that already exists.
A more advanced memory model is maybe needed to do the linear memory but it seems it would require either more instructions or modified instructions, and potentially a lot more bookkeeping by the evm. I am not sure how it would work though. Maybe someone already has suggestions out there. I’m gonna look around a bit.