Simplify gas pricing

[jakmeier]

Dynamic gas pricing as it is implemented today creates more problems than it solves.

First, what is dynamic gas pricing? Basically, when the sum of all gas across all chunks of a block is higher than 50% capacity, the NEAR token per gas unit price increases. But it is capped at 20x the base cost. In practice, it has almost always been at the bottom. It will end up at the top if the average capacity is consistently >50% . (Any price in between is going to be highly unstable because of exponential adjustment steps in every block.)

The problems with dynamic gas pricing are mostly tied to the concept of pessimistic gas pricing. When creating a receipt and buying the gas, we don't know the real gas price as it may change during execution. We do a pessimistic estimation, which is a piece of complicated protocol specification. This ensures the user has enough balance to pay for the transaction even if the gas price increases at the max step size in every block.

The pessimistic cost can be up to 6 times the actual cost. But the exact factor depends on the action type and the amount of attached gas. More attached gas => higher price per gas unit. Note that the difference is refunded at the end. But the user must have enough balance in the first place, just in case the gas price increases during execution.

Why is it bad?

• Bad user experience: Because of pessimistic gas pricing, a user can only send a transaction if they have enough balance for the pessimistic cost.
• Broken function access keys: When setting an allowed balance to a function access key, it has to be high enough to cover the pessimistic price. Once below that threshold, the key is unusable. It's essentially impossible to use up all the allowance of a key.
• Protocol complexity: Tracking pessimistic gas during transaction execution leads to complicated code in nearcore. Pricing has to be tracked across cross contract calls. And we have to send many refunds that are solely for the purpose of refunding the delta between pessimistic and real costs.

Many more details about how gas pricing is implemented today can be found here: https://github.com/near/nearcore/blob/893ef06ad718bb44f4a2d57cf21b433bde249a5c/docs/architecture/how/gas.md

Suggestion:

• Option 1: Remove pessimistic gas pricing. Instead just use the current gas price when buying a receipt. All subsequent receipts from the same transaction can use the same price, even if it changes during execution.
• Option 2: Remove dynamic gas pricing entirely. Just fix it at the bottom where it has been most of the time anyway. (We can add proper gas pricing in the future once we need it, which should probably be per-shard instead of global)

If we go with option 2, I believe we can resolve a number of long standing issues:

• We no longer need a host function exposing the gas price. (https://gov.near.org/t/expose-gas-price-and-contract-access-key-info-within-runtime/24788)
• We no longer need to worry about unrealistically high pessimistic gas prices: Pessimistic gas price goes beyond maximum gas price nearcore#7477
• General confusion around the topic should be resolved. E.g. The field naming gas_price and gas_used is confusing nearcore#6623

cc @BenKurrek @mfornet @bowenwang1996 @abacabadabacaba

Edit: Relevant link to original discussion when dynamic pricing was introduced: #67

[BenKurrek]

YES! Thank you so much for bringing this up. I would 100% be in full support of removing the dynamic gas pricing entirely. It severely overcomplicates things in my opinion and the pros don't outweigh the cons.