-
Notifications
You must be signed in to change notification settings - Fork 118
[Standard] Fixed/Dynamic Gas Contract Method Pricing #204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
I think that it's a good idea |
This is a good feature,@cschuchardt88 . Maybe we can have limits set by the storage of the contract with some fixed prefix that contract can update under its preference without redeploying. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we have a similar problem with NeoFS withdrawals (we need some GAS to do the job, so we take a fee), this solution is not convincing to me:
- it only allows GAS to be used, while contracts may want some different tokens, sending some amount with
onNEP17Payment
callback doesn't have this problem - it's not easy to follow transfers this way, also not a problem for
onNEP17Payment
Effectively, if contract wants your money onNEP17Payment
works fine already, it's just a part of the contract interface and for users it's the same "do smth good" button in whatever UI they use.
|
||
==Specification== | ||
|
||
Contract will have a <code>JSON</code> string in their storage at prefix <code>0xfe</code>. At this storage location the <code>JSON</code> string will |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Contracts use storage the way they like, some may already be using this prefix. Storage scheme is deeply internal for contracts, so we can't dictate anything there. Also, parsing JSON is never fun in runtime, this can be abused to raise contract call cost (in time).
** Methods <code>verify</code>, <code>onNEP11Payment</code> and <code>onNEP17Payment</code> will be ignored. | ||
* Amount | ||
** If the amount doesn't exist. Then the smallest unit of GAS is used (Datoshi). For example: GAS's small unit in Datoshi <code>0.00000001</code> | ||
** If the amount does exist. Than that unit amount will than be deducted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of where? VM GAS? So it'd be like minting some amount of new GAS out of (previously burned) system fee?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be added in as a vm system fee within transaction, Thats why I chose to use only gas. All this really is an vm fee for using a method. Much like an opcode fee. It just makes Call
more expensive when your calling a method that has a fee within a contract. We could always add this to manifest for a method and add property fee and receiver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be arranged in a simpler way then. Just like we have System.Runtime.BurnGas
we can also have System.Runtime.MintGas
(or GrabGas
, or whatever we may call it) that would add a system fee (like BurnGas
) and mint the amount to calling contract. Nothing else needed, test invocations will work fine.
But there is some potential for abuse there probably. Although it's all limited by system fee that user is already agreed to pay by signing a transaction.
* Receiver Address | ||
** If receiver doesn't exist. Then the contract itself SHOULD have the <code>onNEP17Payment</code> method and SHOULD support NEP17 and accept GAS. | ||
** If reciever does exist. Then the reciever address will be used. The reciever address can be a NEP17 contract. However that contract SHOULD accept GAS. | ||
** If <code>0x0000000000000000000000000000000000000000</code> is used the amount is burnned no matter what. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have System.Runtime.Burn.Gas
for this.
Now contract owners, such as a exchange may want a way to get a little gas for sending funds to external wallets. This would allow the contract to have one or several methods to have a fixed price, taking a bit of GAS from transactioner for calling the a method (Much like an opcode price works). For example, a LP token maybe want you to pay gas for withdrawing funds. Reason most LP/Fund contracts do this to pay for the LP contract pool's transaction fees for adjusting prices and other things.