Creating a transaction with cheap function calls and huge attached gas can cause Deny-of-Service

[frol]

Description

As far as I understand, we have a hard limit of gas allowed to be used in a single chunk / block. We use it to select the transactions we can process in a 1-second timeframe. It works fine for basic actions (transfers, deploy contracts), but falls apart when we give users control over the attached gas.

To Reproduce

1. Create a transaction with many cheap function calls and attach 2*10^14 gas to each (this is the current limit per action)
2. Since we have a hard limit of 10^16 gas per chunk, having 50 actions of 2*10^14 gas each will fill the whole 10^16 limit
3. A single transaction can put a delay of 1 second to all the transactions while being cheap to the attacker

/cc @ilblackdragon @bowenwang1996 @SkidanovAlex @nearmax

[lexfrl]

If it's an issue, it should be mitigated by increasing function_call_cost

https://github.com/nearprotocol/nearcore/blob/538a8218d218944c5ae640e9e55aef4c1ca27db9/runtime/near-runtime-fees/src/lib.rs#L148-L152

CC @olonho

[frol]

I don't think increasing the fee is a good idea as we hit other people for nothing. @nearmax suggested to refund attached gas progressively, the more you overestimate, the more you lose.

[bowenwang1996]

@frol So there seems to be a couple misunderstandings here:

• Block gas limit is 10^15, not 10^16.
• There is a difference between gas burnt and gas used. While you can make gas_used for a function call to be very large by attaching something like 10^16 gas, gas_burnt for a function call transaction is bounded and quite small. I didn't do the exact calculation myself but I believe a block can easily fit 500 - 1000 function call transactions.

Please let me know if that answers your concern.

[frol]

@bowenwang1996 the answer does not answer my concern. The concern is that we seem to select transactions that we plan to include into a block based on the gas "estimations" (for simple transactions, the gas estimation is computed or constant, but for function calls we rely on attached gas provided by the user issuing the transaction). If I am sending a transaction that allocates all the gas that is allowed to be burnt in a single block (10^15?), then no other transaction will get selected to be executed in the same block. This means that I can generate 60 transactions and each will take a whole block, so I will delay other transactions execution by a whole minute (sure, I can generate more transactions like that and delay any new transactions being processed in the next hours/days?). Also, it is going to be cheap to execute since I will get gas refund for all the attached gas, and I will only be paying small fee for the FunctionCall itself and dummy execution.

[bowenwang1996]

@frol

If I am sending a transaction that allocates all the gas that is allowed to be burnt in a single block (10^15?), then no other transaction will get selected to be executed in the same block.

As I said, there is a difference between gas_burnt and gas_used. When calculating gas_burnt of a function call transaction, it doesn't matter how much gas you attach, so it is a bounded small value. When we pull transactions from the pool, we only look at how much gas they would burn, so I don't think there is any problem there.

[lexfrl]

Just want to mention, that this is not an issue for non-sharded networks like Ethereum since transaction cost refunded immediately after execution and block counts only the actually used gas.

[lexfrl]

As I said, there is a difference between gas_burnt and gas_used. When calculating gas_burnt of a function call transaction, it doesn't matter how much gas you attach, so it is a bounded small value.

As far as I know, gas_used is just a "virtual" counter which counts "send gas" - gas which will be added to gas_burnt if ExecutionStatus is SuccessValue or SuccessReceiptId but not Failure (since in case of Failure, runtime is not sending created receipts).

[lexfrl]

@nearmax suggested to refund attached gas progressively, the more you overestimate, the more you lose.

makes sense

[frol]

@bowenwang1996 Do I read it right that a receipt get executed first, and only then we decide whether to include it into the current block? So we don't preselect any transactions (receipts) for the current block, instead, we try to run as many of them as possible; is this the case?

[bowenwang1996]

So we don't preselect any transactions (receipts)

Depends on what you mean by "preselect". We select as many as can fit in the block gas limit. Also worth noting that there are separate limits for transactions and receipts so that there is no starvation.

[lexfrl]

Do I read it right that a receipt get executed first, and only then we decide whether to include it into the current block?

The problem is that runtime can't execute function calls on the sender side. But runtime must charge sender for the gas attached.

[frol]

We select as many as can fit in the block gas limit.

How do you select how many function calls can fit into a block? (do you use attached gas?)

[bowenwang1996]

How do you select how many function calls can fit into a block? (do you use attached gas?)

No. As I said the gas attached here doesn't matter. We compute gas_burnt for this transaction (it can be viewed a fixed amount even though there is slight variation based on whether sender is the same as receiver) and then take as many transactions as we can until the sum of gas burnt exceeds the block gas limit.