Scoped Execution GAS

[igormcoelho]

Summary or problem description
This change makes it easier for contracts to decide during verify() if they should authorize or not the spending of its assets. I believe that contracts are likely to authorize GAS spendings only if executions are limited to the scope of that contract itself, or contract group.

Related to: neo-project/proposals#137

Do you have any solution you want to propose?
Update ApplicationEngine and include scope together with variables such as GasLeft and other GAS controlling systems. The gas taken from signers[0], aka sender, should respect the scope of this signature/verification (if global, then GAS is global; if limited, then GAS is limited).
There can exist situations where one wants to have global GAS, while limiting signature into some specific contract (or calledByEntry). We can discuss if these cases are real problems on practice, or if some other behavior needs adjustments for this to work.

Neo Version

• Neo 3

Where in the software does this update applies to?

• Ledger
• Other: ApplicationEngine

[igormcoelho]

@erikzhang @shargon @roman-khimov

[shargon]

The problem could be solved with #2444 . Isn't it?

[roman-khimov]

Sender's GAS is spent for paying fees, it's written off before transaction execution and to me that's the scope it has --- for paying fees, if you don't want to pay fees just don't be a sender. So if contract doesn't want its GAS to be spent in some ways it just should be careful with its verify method (and it has to be careful with it anyway). I think we already have all possibilities covered:

• if contract never wants to pay fees it just fails to verify any transaction where contract is a sender
• if it wants to pay fees in some cases it only approves transactions it wants to in verify
• any witness (sender or non-sender) still has regular scoping (CalledByEntry, Global, etc) for other purposes

I can only see these potential problems:

• as you've mentioned in Transfer to Transaction NEP-TTT proposals#137 checking transaction inside verify can be non-trivial
• witness scope is not really accessible from the verify, so it's hard for contract to check for that

Essentially it's the question of the amount of processing needed to decide whether transaction should be approved to use contract's GAS in some ways or not. And this decision can be moved to contract's backend processing and completing notary payloads (hi, #1573), it can implement any kind of script parsing/checking as well as scoping checks before adding some missing signature that will make the transaction valid.

[igormcoelho]

The problem could be solved with #2444 . Isn't it?

@shargon that only makes it easier to estimate gss costs on complex invocations, by adding more gas (refuel) during the process (but also helps giving more GAS during execution, if necessary).

Here, the issue is how to give the starting GAS, in order to begin the process.
This issue here would require, in my point of view, to have two Gas counters inside ApplicationEngine: one global (which is current one) and another with constrained scope of SIGNERS[0], aka "sender". Just store the Signer scope inside ApplicationEngine and consume this gas only when scope is valid, otherwise break execution.

Like @ixje mentioned above, this is related to the issue of a contract providing GAS to user that is bound to some specific scope. For example, I give you gas and you use it to execute other contract, not mine... I feel this is not desired on practice.