-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Limit Refuel to 1 GAS #2561
Limit Refuel to 1 GAS #2561
Conversation
@shargon @roman-khimov What do you think? |
I think that if the account it's related to any transaction in the block, and it remove the total gas can poduce a Denial of service during onPersist, I agree with @roman-khimov in |
Attackers can call refuel multi times to occupy system resource. |
Limit sum of refueled gas to 1 gas? |
Limit Refuel to only one call per invocation |
How about this #2563 |
Co-authored-by: ZhangTao <zhangtao@ngd.neo.org>
@roman-khimov What do you think? |
Can anyone fix the UT? |
I will |
@superboyiii could you test it if it could produce a DoS if during |
|
Another protection mechanism can also be introduced: we can only allow |
I agree with Roman. |
Too much better |
Pay GAS in advance and refund the remaining system fee to the user. (No refund if an exception occurs) |
I have another idea. We can limit it to |
|
I think it's better than removing it.
If we limit it to |
Pay gas in advance, make a bag, and decrement this bag during refuel, like this never can affect to OnPersist |
@@ -40,10 +40,12 @@ internal override async ContractTask OnPersist(ApplicationEngine engine) | |||
[ContractMethod(CpuFee = 1 << 15, RequiredCallFlags = CallFlags.States | CallFlags.AllowNotify)] | |||
private async ContractTask Refuel(ApplicationEngine engine, UInt160 account, long amount) | |||
{ | |||
if (amount < 0) throw new ArgumentOutOfRangeException(nameof(amount)); | |||
if (amount <= 0) throw new ArgumentOutOfRangeException(nameof(amount)); | |||
if (ContractManagement.GetContract(engine.Snapshot, engine.CallingScriptHash) is null) |
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.
Account?
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.
What do you mean?
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.
Who pay te gas it's the account
argument
I think it's perfect now. |
UT |
The intention behind #2444 can be traced via #2443 to neo-project/proposals#137 and that intention to me is to have contract-sponsored actions. Limiting Refuel to fee amount makes the user inevitably pay half of the real price, so it's a discount, but the intention was rather to have contract paying 90%+ of fees. I've questioned usefulness of this method already in #2443 (from a bit different perspective though), but with this limit it's hard for me to imagine who is going to use it. Methods should solve some problems and I'm not sure it solves anything now. |
It is difficult for a contract to determine whether the sponsorship has been abused. Now it does not need to worry too much, because users have to pay at least half of the cost. |
Maybe we can limit it to |
|
I think system_fee + = Refuel /exe_Factor*3 is more resonable. Don't make a static limit to a dynamic result. |
Increases usefulness, raises amplification factor.
|
And BTW, while this probably is the only valid solution (if not counting Which technically allows to attack contract itself (draining balance from it), so maybe it's not a valid solution either. |
As a side note, think of |
We should revert first. Seems we can't get agreement soon. |
For this Refuel to work we need to make sure that the assets are innevitably taken from user or contract account. It should have similar logic to network or system fees, so relating a factor into it is a clever solution, that only introduces a price reduction, at worst. For the moment, I agree with @erikzhang in putting a limiting factor of 2, or even zero, if necessary. Best thing if we could put it in some global constant, that can be updated on time. Then, we take the time to discuss it further. I also agree to take funds only from a deployed contract. |
Another problem. Once we set the limit in |
It can be used to attack the network (amplifying DOS), so it's broken beyond repair. See also neo-project/neo#2560 and neo-project/neo#2561.
It can be used to attack the network (amplifying DOS), so it's broken beyond repair. This reverts ac60160. See also neo-project/neo#2560 and neo-project/neo#2561.
No description provided.