neo3 ABI readonly methods

[igormcoelho]

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.

[shargon]

in order to implement it, could you especify what methods?

[igormcoelho]

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]

@erikzhang is it exactly the same concept as safe flag? if it's the same, I then propose to rename safe to readonly.

[erikzhang]

Same.

[shargon]

Maybe is better to call it readonly

[erikzhang]

Agree. And also we can move it to ABI.

[lock9]

@igormcoelho isn't this the same as #829 ? We can keep the discussion here if you guys prefer

[igormcoelho]

No, we need to put this on NEP-3 Ammendment... another one.

[lock9]

@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 😂

[igormcoelho]

Ok, perhaps this is why I didn't understand it at first 😂

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 safe methods). This is a lock specially related to ABI invocation of methods, and indirectly connected to NEP-3

• At Add storage access restriction at method level #829 I saw a different perspective, for example, by locking methods when invoked from inside a smart contract. I mean, during a CALL, or an APPCALL (now System.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]

No need to lock this feature to me. Focusing on other things first.

[lock9]

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?

[shargon]

@igormcoelho do you want to implement this? otherwise @lock9 you can assign it to me

[shargon]

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.

neo/neo/SmartContract/InteropService.cs

Line 554 in cf768c6

ExecutionContext context_new = engine.LoadScript(contract.Script, 1);

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 : neo-project/neo-vm#191

[igormcoelho]

@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.

[shargon]

Today is one flag, tomorrow two flags xD i don't like this model 😅

[igormcoelho]

Ok, it's approved on the vm side: neo-project/neo-vm#191
We can advance on this one now, to validate those changes before merging.

[shargon]

Require #1048

[shargon]

This will be do o should be closed?

[shargon]

This will be merged or should be closed? @neo-project/core

[lock9]

Hi @shargon, let's continue the discussion here: neo-project/proposals#104
We need to update NEP-3 before continuing.