Potential undercharging for delayed receipts

Generally we don't account for the cost of reading a delayed receipt from the state. This causes a specific issue: when a shard is congested, refund receipts coming from other shards will be put into the delayed receipt queue. However, the gas cost of executing each of refund receipt is merely 223G gas, which is smaller than the cost of reading a delayed refund receipt (roughly 565Ggas assuming that such a receipt is roughly 300 bytes). This means that when there are a lot of delayed refund receipts in the queue (>1000) at once, there maybe a significant slowdown of execution simply because of the cost spent on reading the delayed refund receipts one by one.

There are a few ways we can address this issue:

The stateless validation release should address the latency issue because delayed receipts would be held in memory and one extra memory access imposes little overhead. However, the refund receipts still need to be merklized and included in a chunk when sent as outgoing receipts and those overhead would still be there.
A local fix is to aggregate the refund receipts from shard A to shard B into one receipt with a hashmap of account to refund amount. This means that for each shard, when it processes a chunk, it needs to process at most 4 refund receipts, each containing all the refunds from another shard to this shard. This also somewhat reduces the overhead in chunk production and distribution.
A complete fix is to remove the pessimistic gas pricing and replace it with something more sensible, which would eliminate refund receipts altogether. The pessimistic gas pricing is not a sound mechanism in the first place (see discussion here). This could potentially be done in two separate steps where we first remove the pessimistic gas pricing and then later introduce a new mechanism for gas price calculation. It may sound aggressive, but as we have seen last week, pessimistic gas pricing did not deter people from spamming the network. If we have a good mechanism to control congestion, it is worth considering removing this crutch.

near / nearcore

Potential undercharging for delayed receipts #10295