GAS reloading on execution

[igormcoelho]

Summary or problem description
This change allows contracts to add more GAS into engine during execution. This simplifies GAS calculations on complex contracts, so that more and more GAS can be required during runtime, depending on the situation.

Related to: neo-project/proposals#137

Do you have any solution you want to propose?
I propose that GAS Native Contract have some method like GAS.transferToSystem(scripthash, amount), where an amount of GAS is requested to be put on the engine executing the transaction.

Example:

// inside smart contract
RunBigCode();
// check if there's enough gas... if not, top-up more 0.1 GAS
GAS.transferToSystem(scripthash, 0.1);   // this adds more 0.1 into ApplicationEngine, and takes from 'scripthash'
// run more code
RunBigCode();
// check if there's enough gas... if not, top-up more 0.1 GAS
GAS.transferToSystem(scripthash, 0.1); 
// ...

Neo Version

• Neo 3

Where in the software does this update applies to?

• Ledger
• Other: ApplicationEngine

[igormcoelho]

@shargon @erikzhang

[shargon]

// check if there's enough gas... if not, top-up more 0.1 GAS

Is not easier to send the gas before the execution if you will need it?

[roman-khimov]

This change allows contracts to add more GAS into engine during execution

No doubt it is.

This simplifies GAS calculations on complex contracts, so that more and more GAS can be required during runtime, depending on the situation

But I'm not so sure about this part.

It'll work the way it's implemented in #2444, but I doubt it's going to be used a lot. This is contract's logic and you want it to decide how much GAS it's going to spend before exit. It can't be done precisely, so some GAS will inevitably be lost here. It also can be set to some 0.1 GAS by contract, but then ExecFeeFactor will change and this amount won't be enough. And frankly as a contract I'd rather not care about system fee GAS, the sender should just provide enough of it, as a contract I'd like to concentrate on business logic I need to implement.

We usually determine the amount of GAS needed from test runs and it works good enough (although there are cases where on-chain execution differs from test run), transaction will have some sender anyway (it can't exist without it) and this sender has to pay some fees anyway (that's what sender is for), so if we're to ensure that he has enough GAS to pay for whole execution maybe we don't need it at all.

So to clarify, there is nothing really bad about this proposal, it can do what it does and it's rather simple to implement, but I'm not convinced it's useful.

[igormcoelho]

I agree @roman-khimov that this is not trivial to use. But it's yet another possibility for some contract operation starting with virtually zero gas (just to cover basic expenses) and "the rest we see next"... it could bargain with other contracts on execution and find onchain possibilities to fund its operation.

This is quite nice because the any NEP17 can easily provide onchain funds for its users on real time, before "transfer" operation, or any other of interest. The more tools we provide, more alternatives and economic models for contract designers.

[igormcoelho]

It can't be done precisely, so some GAS will inevitably be lost here.

Please take a look at this issue @roman-khimov , it may help: #2448

[igormcoelho]

Thanks for the efforts @erikzhang , this will allow great possibilities for contract developers.

[someone-somenet-org]

Is there a way to actually make it 0 cost for the invoker?

The idea is to make a NEP-Token where the contract pays the user's first transfer of the day, without the user needing any gas at all.

[erikzhang]

The idea is to make a NEP-Token where the contract pays the user's first transfer of the day, without the user needing any gas at all.

Use the contract hash as the sender of the transaction.