[Proposal] Finalize cost should not include commands skipped by `branch` command

[HarukaMa]

💥 Proposal

Currently snarkVM counts every command for the finalize fee. However, skipped commands should take a lot less resource to execute on-chain, so the fee can't represent the real effort for nodes to execute the finalizers. Considering the current implementation for branch commands literally skips those commands, they should not contribute to the finalize fee.

Possible implications: the fee for each function call might differ for a huge amount, especially if block.height or rand.chacha is involved (we can't reliably simulate executions for those cases, especially for rand.chacha). As we don't have a complicated gas fee system like Ethereum, it would be difficult for users to always use a reasonable fee when executing programs.

[raychu86]

Great observation!

We are in the process of determining the fee model for finalize, in the current form, we are checking that you pay for the entirety of the finalize logic regardless of if the branch occurs or not. Meaning, we regard your transaction as invalid due to insufficient fees, before attempting to add it to the chain.

A solution we are planning to explore is as follows:

1. Soften the initial enforcements and provide a "suggested" fee up front.
2. Tally the proper finalize costs when actually executing the finalize in atomic_speculate.
3. Accept/Reject the transaction based on the fee. (We can abort the execution early if the provided fee is already "consumed")

This would effectively bring us to the Ethereum model where you pay for execution like gas (and halts early).

Note - We are also exploring the costs of each finalize command in this PR - https://github.com/AleoHQ/snarkVM/pull/1717

[HarukaMa]

I believe even in this approach, the user would still pay for the full amount that is submitted, as we don't (can't?) have refund mechanisms with the fee transition?

[raychu86]

Yes, at the moment we do not have a concept of "refunds" with the fee transition, because the fee transition must be constructed prior to broadcasting the transaction. For privacy reasons, we also can't explore the route of refunds via public credits due to the fee payer being private.

It is up to the developer to determine the amount of fee they'd like to provide. The upper-bound of the fee is deterministic and a fee estimate to account for branches can be determined by running VM::speculate locally (assuming a synced VM).

Any additional fee amount that is not consumed by the execution costs is effectively a "priority fee".