meta tx changes the changes the max receipt chain length

[jakmeier]

When we calculate the gas price for a transaction, we use a pessimistic gas price that covers for a potential change in gas price. This allows to (almost) always charge the current gas price when burning gas, instead of executing the entire transaction at the original price.

Noteworthy: It is possible that receipts are delayed more than expected due to congestion. If the price goes up at the same time, as it would with congestion, then there are cases where a user doesn't pay the full current gas price but just the pessimistic gas price computed initially.

How pessimistic we are depends on how deep the chain of receipts can become. This is limited by maximum_depth = total_gas / min_gas_for_fn_call() because the only way to extend a receipt chain by more than a single receipt is using a function call. This maximum_depth is added to initial_receipt_hop.

nearcore/runtime/runtime/src/config.rs

Lines 276 to 288 in 2b6f9f1

	let receipt_gas_price = if gas_price == 0 {
	0
	} else {
	let maximum_depth =
	if minimum_new_receipt_gas > 0 { prepaid_gas / minimum_new_receipt_gas } else { 0 };
	let inflation_exponent = u8::try_from(initial_receipt_hop + maximum_depth)
	.map_err(|_| IntegerOverflowError {})?;
	safe_gas_price_inflated(
	gas_price,
	config.pessimistic_gas_price_inflation_ratio,
	inflation_exponent,
	)?
	};

The change with meta transactions is that now we can have an initial hop that starts with a delegate action, thereby increasing the length of the chain by 1. This means we hit the case where we can't charge the full gas price one hop earlier.

[jakmeier]

I see two options here:

1. increase the initial hop for delegate actions by 1
2. do nothing

I don't like 1. We would have to insert weird special cases in the code and make it protocol dependent. This makes an already too complicated system even more complicated, without a good reason.

Today, the assumptions for how much gas price can change per hop is not founded on any specific limits anyway, a hop can take an unlimited number of blocks. I would say this logic needs to be overhauled. And a design to deal with congestion is currently in discussion. If we insist on being consistent in our pessimistic gas calculation and do this change, this makes it only harder to implement a new design, as it would also have to still cope with the old behavior for backwards compatibility.

Hence I think 2, doing nothing, is not only fine but actually preferred from a design perspective.