Neo3 should provide readonly identifier on manifest. When these functions are demanded, two things happen: offchain services execute operations by themselves (unless forced to send to chain); and two, a readonly storage context is provided. This way, a readonly invoked method will.not be able to invoke a read write method.
igormcoelho
All 21 comments
in order to implement it, could you especify what methods?
shargon
on 17 Jul 2019
The simplest example I have in mind is: balanceOf.
Suppose you do the appcall contractX "balanceOf" myscripthash. Neo3 would look into contractXmanifest, and notice that balanceOf has readonly flag (similar to safe flag, or is it the same?). If it's readonly, the application engine is loaded in readonly mode, and syscall GetCurrentContext would fail, for example (it would require GetReadOnlyStorageContext).
On C# devpack, it could be an attribute:
[ReadOnlyMethod]
BigInteger balanceOf(byte[] me)
What happens, from wallet side, is that it process locally this invocation instead of issuing a transaction (unless you are forced to, via sendrawtransaction). To do that efficiently, we would need the state messages from blockchain or p2p, in order to properly calculate locally the whole state, with 100% confidence. Once in readonly application mode, you can never get out of it, even using dynamic/static invokes.
igormcoelho
on 17 Jul 2019
@erikzhang is it exactly the same concept as safe flag? if it's the same, I then propose to rename safe to readonly.
igormcoelho
on 17 Jul 2019
Same.
erikzhang
on 17 Jul 2019
Maybe is better to call it readonly
shargon
on 17 Jul 2019
Agree. And also we can move it to ABI.
erikzhang
on 17 Jul 2019
@igormcoelho isn't this the same as #829 ? We can keep the discussion here if you guys prefer
lock9
on 17 Jul 2019
No, we need to put this on NEP-3 Ammendment... another one.
igormcoelho
on 18 Jul 2019
@igormcoelho could you describe the difference between this one and #829? Maybe we need to rename one of them because they look equal to me 馃槀
lock9
on 18 Jul 2019
Ok, perhaps this is why I didn't understand it at first :joy:
There are many situations where you could possibly "lock" state updates.
The proposal here is to lock it during invocation of a Neo Standard Method (these methods with strings and parameters), which is already what Erik had proposed months ago (but by the name of
safemethods). This is a lock specially related to ABI invocation of methods, and indirectly connected to NEP-3At #829 I saw a different perspective, for example, by locking methods when invoked from inside a smart contract. I mean, during a
CALL, or anAPPCALL(nowSystem.Call). Or even during multiple transactions (I didn't get that part). That one is a very different perspective, because it affects how neovm-appengine would process everything after jumps (or calls), so I didn't understand how to do that.
In short, if both are the same, good for us: we just need to rename safe to readonly and close two issues ;)
igormcoelho
on 18 Jul 2019
No need to lock this feature to me. Focusing on other things first.
igormcoelho
on 1 Aug 2019
Sorry @igormcoelho . I assigned you because you said you would like to work on this task later. I suppose someone else can do this while you are working on other tasks?
lock9
on 5 Aug 2019
@igormcoelho do you want to implement this? otherwise @lock9 you can assign it to me
shargon
on 12 Aug 2019
In order to proceed with this change , we need to be able to store some information inside ExecutionContext because currently there are no way to store a flag in this class.
I propose to modify neo-vm for be able to extend the ExecutionContext class, this could allow to add the script hash in the future in this class too
Proposed changes : https://github.com/neo-project/neo-vm/pull/191
shargon
on 13 Aug 2019
@shargon, I'm not sure that extending ExecutionContext is a good path... but I understand why you need this.
Perhaps we just need a flag field on ExecutionContext, and reuse it, for many things.
igormcoelho
on 13 Aug 2019
Today is one flag, tomorrow two flags xD i don't like this model 馃槄
shargon
on 13 Aug 2019
Ok, it's approved on the vm side: https://github.com/neo-project/neo-vm/pull/191
We can advance on this one now, to validate those changes before merging.
igormcoelho
on 14 Aug 2019
shargon
on 22 Aug 2019
This will be do o should be closed?
shargon
on 18 Oct 2019
This will be merged or should be closed? @neo-project/core
shargon
on 8 Nov 2019
Hi @shargon, let's continue the discussion here: https://github.com/neo-project/proposals/pull/104
We need to update NEP-3 before continuing.
lock9
on 17 Nov 2019
Related issues
coranos
路
85Comments
igormcoelho
路
34Comments
erikzhang
路
43Comments
EdgeDLT
路
59Comments
brianlenz
路
37Comments
Most helpful comment
Ok, it's approved on the vm side: https://github.com/neo-project/neo-vm/pull/191
We can advance on this one now, to validate those changes before merging.