Improve initial fee implementation

[PhilippGackstatter]

As a follow-up to the initial fee implementation (i.e. #1614), we can do the following extensions. For each of these we could create a sub-issue.

• Add the remaining nullifier_base_fee and output_note_base_fee as mentioned in Add fee parameters to the BlockHeader #1612. This means integrating them into the compute_fee procedure and testing them in test_fee.rs.
• Implement EIP-1559-style demand based changes. Here we have to do some research on the concrete mathematical model to use. The mechanism in EIP-1559 may be a bit too sensitive and a better approach suggested to us was a momentum-based approach where the base fee increases in a larger step only if there are 3-4 blocks in a row that are above target utilization.
  • This also requires defining min and max bounds.
• We should enable users to set a tip on the transaction. Either an absolute value or a value relative to the fee computed in the epilogue.
  • If that value is provided via the advice provider, then we have to make sure that it is covered by the tx summary, by taking it out of the vault before invoking execute_auth_procedure. If we take it out together with the computed fee a malicious remote prover could change this value. This would only work with an absolute value then.
  • If we want to use a relative value, then we may have to commit to the value by providing it as an input on the transaction stack.
• Another line of work is to update batches and blocks to integrate fees into their logic, i.e. validate the fee of the transaction and output notes that contain the tip for the batch and block producers.

[bobbinth]

Thank you for writing this up! A few comments/thoughts:

Add the remaining nullifier_base_fee and output_note_base_fee as mentioned in Add fee parameters to the BlockHeader #1612. This means integrating them into the compute_fee procedure and testing them in test_fee.rs.

Yes, let's create a separate issue for this. I think we can try to include it in this milestone. There is a bit of a discussion I think about the exact dimensions here. For example, how do we cover the cost of account tree update?

Implement EIP-1559-style demand based changes. Here we have to do some research on the concrete mathematical model to use. The mechanism in EIP-1559 may be a bit too sensitive and a better approach suggested to us was a momentum-based approach where the base fee increases in a larger step only if there are 3-4 blocks in a row that are above target utilization.

Let's create a separate issue for this as well, but as there is some research to be done, let's leave it for the next milestone. For now, we'll just have a flat fee for all blocks.

We should enable users to set a tip on the transaction. Either an absolute value or a value relative to the fee computed in the epilogue.

• If that value is provided via the advice provider, then we have to make sure that it is covered by the tx summary, by taking it out of the vault before invoking execute_auth_procedure. If we take it out together with the computed fee a malicious remote prover could change this value. This would only work with an absolute value then.
• If we want to use a relative value, then we may have to commit to the value by providing it as an input on the transaction stack.

This warrants a bit of a discussion but overall, shouldn't be too difficult to pin down. My initial thoughts that there would be a pay_tip (or something similar) procedure that would take an absolute amount (or, probably, a TIP_ASSET). The tip would be provided non-deterministically, and pay_tip would be called in the auth procedure before we generate a transaction summary (and so, it would be covered by the signature).

This should work pretty well for local (user-generated) transaction. For network transactions, we'll need to come up with something else. Maybe here the tip could be proportional to the base fee, or maybe based on some other parameters (not sure what yet). In either case, there probably should be a mechanism for a network account to specify something like max_fee beyond which it is not willing to go.

Let's create an issue for this and depending on where we land, we could try to do it in this milestone, or in the next one.

Another line of work is to update batches and blocks to integrate fees into their logic, i.e. validate the fee of the transaction and output notes that contain the tip for the batch and block producers.

The way it works right now is that the fee is effectively burned, right? (i.e., we don't collect it in batches or anything like that). If so, let's create an issue to discuss this, but we probably don't need to address this until the next milestone.

Separately, I think there is one more thing that we need to do on the fee front: make sure we include storage size, note counts, etc. into the estimation of the cycle count after the transaction fee is computed. Let's create an issue for this too (unless we already have one).

[PhilippGackstatter]

The way it works right now is that the fee is effectively burned, right? (i.e., we don't collect it in batches or anything like that). If so, let's create an issue to discuss this, but we probably don't need to address this until the next milestone.

After reading through this thread (#1217 (comment)) again, I think that the batch and block producer tip claiming would be quite significant work, and I'm not sure we really need it right now? So I would delay this to the future.

On the other hand, validating that the transaction's FEE_ASSET covers the fees is something I think we should have, e.g. in the next milestone. I'll open an issue for that.

After that I would close this issue as more specific ones have been opened.

[bobbinth]

After reading through this thread (#1217 (comment)) again, I think that the batch and block producer tip claiming would be quite significant work, and I'm not sure we really need it right now? So I would delay this to the future.

Agreed!

[PhilippGackstatter]

Closing as the tasks here have been moved to more specific issues.