Tracking issue: Compute costs for storage related host functions

[jakmeier]

This tracks the increased compute costs, as defined in NEP-455, for a list of storage related host functions, introduced with protocol version 61.

wasm_touching_trie_node:    { gas: 16_101_955_926, compute: 110_000_000_000 }
wasm_storage_write_base:    { gas: 64_196_736_000, compute: 200_000_000_000 }
wasm_storage_remove_base:   { gas: 53_473_030_500, compute: 200_000_000_000 }
wasm_storage_read_base:     { gas: 56_356_845_750, compute: 200_000_000_000 }
wasm_storage_has_key_base:  { gas: 54_039_896_625, compute: 200_000_000_000 }

Compute Costs NEP: https://github.com/near/NEPs/blob/master/neps/nep-0455.md
PR that sets the values: #8924
Analysis to justify the values: #8006

Summary

The protocol team has long been investigating issues where storage accesses take longer than the time budget given by the gas costs. On average, the gas cost seems okay but in some cases RocksDB is too slow.

Flat storage is a feature that helps bringing down the worst-case timing of storage operations. But for contracts that heavily optimized for the pre-flat-storage current caching setup, the storage latency is expected to be worse when flat storage lands.

To counteract, we decided to increase compute costs of storage operations and therefore increase the time budget per storage operation. The values were chosen such that we are confident a validator with recommended hardware can meet the timing requirement.

Keeping compute costs as they are means we reduce the throughput of storage-heavy function calls per chunk.
It also makes brute-force DoS attacks (buying up all chunk space) slightly cheaper.

Removing compute costs too early would open us up for undercharging attacks, where chunk production can be delayed by malicious actors.

What needs to happen to reset compute costs

This change is not intended to be in place forever. There are two ways out.

1. Optimize storage further, such that we can meet the timing limits given by gas costs.
2. Increase the gas costs to the values of the compute cost. This would potentially break many existing smart contracts and definitely increase operation costs for Sweatcoin, Aurora, SocialDB, and all other contracts that use a lot of storage accesses.

The two alternatives require different next steps to explore. Right now, we focus on option 1 and work on figuring out how we can improve our storage performance in a meaningful way.

• Initiative: Align on solution to improve storage write performance #8895
• Further steps TBD