You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As opposed to what I would expect, RunCode and RunCall actually edits the state. When coming from the web3 world, where one can call/send, we know that if we call then the state does not change, but if we send and the transaction gets mined, then the state does change.
I know that we are talking about the context of Transactions in the web3 variant, but I think the assumption that runCall / runCode does not change state is a logical one when coming from the web3 world.
I therefore propose that we add a flag to RunCodeOpts and RunCallOpts which is false by default: editState or something similar would this option be called. When set to true, the state is committed at the end of runCode / runCall, if not, the state is rolled back at the end of those function calls. Of course, if this happens internally in the VM, we set this option to true.
Related: #613, I think we could merge these two issues into a single PR after we had a discussion here.
The text was updated successfully, but these errors were encountered:
As opposed to what I would expect,
RunCode
andRunCall
actually edits the state. When coming from theweb3
world, where one cancall
/send
, we know that if wecall
then the state does not change, but if wesend
and the transaction gets mined, then the state does change.I know that we are talking about the context of Transactions in the
web3
variant, but I think the assumption thatrunCall
/runCode
does not change state is a logical one when coming from theweb3
world.I therefore propose that we add a flag to
RunCodeOpts
andRunCallOpts
which isfalse
by default:editState
or something similar would this option be called. When set totrue
, the state iscommitted
at the end ofrunCode
/runCall
, if not, the state is rolled back at the end of those function calls. Of course, if this happens internally in the VM, we set this option totrue
.Related: #613, I think we could merge these two issues into a single PR after we had a discussion here.
The text was updated successfully, but these errors were encountered: