Gas cost for adding new function access keys is too low

[jakmeier]

Adding a function access key has two gas cost parameters associated with it. As of v53, this are the values:

• action_creation_config.add_key_cost.function_call_cost
  • "send_sir": 2_319_861_500_000
    • "send_not_sir": 2_319_861_500_000
    • "execution": 2_319_861_500_000
• action_creation_config.add_key_cost.function_call_cost_per_byte
  • "send_sir": 2_235_934
    • "send_not_sir": 2_235_934
    • "execution": 2_235_934

However, estimations show that the true costs per-byte are significantly higher. (The base costs are ok.) This needs to be fixed, as undercharging like this can lead to performance degradation of the network.

Luckily, each access key is limited to 2kB, thus adding a new key can never be heavily undercharged on a transaction level.

Work items to fix this:

• [x] Improve estimation to cover worst-case
• [ ] Run estimations and propose new values
• [ ] Nightly protocol feature to increase cost
• [ ] Stabilize feature

[jakmeier]

With updated estimations and properly accounting for receipt creation costs, things don't even look that bad.

1. ICount estimation has the base cost only at half the value it is today. But the per-byte cost is estimated much higher than it is today. Fortunately, it just happens to work out such that adding a key with 2kB methods (the maximum) has the right cost today. Everything with smaller arguments is even overcharged today, according to icount estimations.
2. Time-based estimations on gcloud look quite different. The base is close to today's parameter but the per-byte cost is not as big as with icount estimations. Adding 2kB method names gives only 14% undercharging.

Or in a graph:

---

Conclusion

I think we should wait until we have a better IO cost estimation setup before we do anything here.