Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reasoning behind the pull request
The smart contract results (SCRs) can carry value and data. The same is valid with the regular transactions which can carry value and data. We can also have 0 value transactions, and those transactions still need to cover the base cost of their processing which is 50k gas limit for processing and 1500*len(transaction.Data) for the data field. This leads to a disproportionate processing gas cost for the smart contract results when compared to regular transactions, even though the time cost for executing the smart contract results is similar.
Proposed changes
As the current code goes, we take from the sender the baseCost*gasPrice + extraGas * gasPrice/100, and we have to start by changing this to take into account allGas * gasPrice and give back to the user after the processing ends the refunded amount. Any way, for 100% of the SC executions we create a refund, there is no EXACT gas computation done for apps, everyone is overestimating a little bit, as that is comfortable. There will be a bigger upfront cost for the transaction, but with more refunds. This is a must change for any txType which is other than SCExecutionOnDestionation - for others, we know the exact gasCost.
The next change which has to be done is when computing the refund. Right now the refund is equal with gasPrice/100 * gasRemaining. Here a more complex operation is going to take place as we will check how much is the sum of all the SCR.Data from the VMOutput and how many SCRs were generated. For every SCR generated we take the basePrice of 50K (same as moveBalance) with full price, and for the sum we take 1500 with full price.
GasUsedForProcessing = VMOutput.GasUsed - 50K * number of SCRs - 1.5K * SUM (len(SCR.Data)_for all SCRs generated)
Refund = VMOutput.GasRemaining * GasPrice + GasUsedForProcessing * (1 - factor)
By doing this change, SC developers will get a higher return as well.
Testing procedure
Run all the tests and see that balances are correct.
Pre-requisites
Based on the Contributing Guidelines the PR author and the reviewers must check the following requirements are met:
feat
branch created?feat
branch merging, do all satellite projects have a proper tag insidego.mod
?