CostModel: cost for precompiles

[tao-stones]

Cost model accounts CUs of precompiles at get_signature_cost(), therefore their corresponding instructions are counted 0 CUs during get_transaction_cost() (as their native_cost defined in BUILTIN_INSTRUCTION_COSTS is zero). This is true for 2 existing precompiles before #3799.

Behavior changes for precompiles after #3799, get_transaction_cost() will add 3K CUs per precompile instruction to Default CU Limits, if Compute Unit Limit was not requested. This does not have direct UX impact, but block producer will reserve additional CUs from block, then release after execution.

Introducing new Precompile (for example #3826) presents additional challenges, if BUILTIN_INSTRUCTION_COSTS is frozen (eg cannot add new entry into the map): new precompile instruction will add 200K default CU to get_transaction_cost(), could lead block producer to over-reserve block space. (in both Before and After #3799).

Note: Issue only impact block producer packing process, they do not impact consensus because their actual execution cost remain same.

Potential solution:

• Cost Model to identify precompile instructions, then exclude them from get_transaction_cost()

[jstarry]

This does not have direct UX impact, but block producer will reserve additional CUs from block, then release after execution.

There actually is an impact if a transaction uses precompiles, calls an sbpf program, and doesn't specify a CU limit. The extra 3k CU's per precompile instruction will be added to the transaction's compute meter and so the called sbpf program is allowed to consume more CU's by default.

Introducing new Precompile (for example #3826) presents additional challenges, if BUILTIN_INSTRUCTION_COSTS is frozen (eg cannot add new entry into the map): new precompile instruction will add 200K default CU to get_transaction_cost(), could lead block producer to over-reserve block space. (in both Before and After #3799).

Note: Issue only impact block producer packing process, they do not impact consensus because their actual execution cost remain same.

Yes, the execution cost is the same but the calculated default compute limit will be different if such a precompile is added to BUILTIN_INSTRUCTION_COSTS. So it's not true that the "[i]ssue only impact[s] [the] block producer packing process"