Add fee parameters to the `BlockHeader`

[PhilippGackstatter]

To be able to compute fees in the tx kernel, the kernel must be able to figure out 1) what asset fee payments are allowed in and 2) have the necessary base fees available.

Firstly, the transaction kernel needs to be able to fetch the concrete asset (specifically the faucet ID) in which fee payments are accepted. I think it's fine to assume that this is specified once per network genesis and doesn't change throughout the network deployment. Therefore, committing to it as part of the genesis block header would be one possibility. I think it's likely we'll end up with additional static fee-related parameters that might evolve with governance updates (so very slowly) and these could also be committed to as part of this. However, that is premature optimization, so for now the simplest thing we can do is just include the AccountId of the "fee asset" faucet.

Secondly, the transaction kernel must be able to compute the fee of the current transaction. To that end, it needs the current base fee parameters. For this issue, I would propose adding two base fee parameters that I'm pretty sure we'll definitely need, based on the ones from this comment:

• verification_base_fee: Cost for the verification of a transaction.
  • Each tx pays this once proportional to ilog2 of the number of cycles a transaction took to execute..
    note_base_fee: Fee per created note.
• nullifier_base_fee: Upsert operation into an SMT of depth 64, i.e. nullifier or account updates.
  • Each tx pays this once for the account it updates plus the number of consumed notes.
  • Not too happy with the name - happy to hear suggestions.
• output_note_base_fee: Fee per created note.
  • Each tx pays this for the number of created notes.

Note that I'm ignoring the data base fee because anything to do with data and storage is a bit more tricky and we haven't explored that in the discussion too much yet, so I'd leave it out of the initial implementation.

These base fees will change with every block update based on the current demand in that block and so it makes sense to include the raw values in the BlockHeader.

Overall, we may have a separate fee-related struct that is part of the BlockHeader, e.g.:

pub struct BlockFeeParameters {
  asset_faucet_id: AccountId,
  // Not clear whether `Felt` is sufficient but probably it is.
  verification_base_fee: Felt,
  nullifier_base_fee: Felt,
  output_note_base_fee: Felt,
}

For the very first implementation, when building a new block, we could just copy the previous values to the new block header and implement demand-based changes as follow-ups.

[bobbinth]

Looks great! Thank you for writing this up! A couple of small comments:

For the initial implementation, I would maybe simplify the number of different fee dimensions to just 1 and we can expand these later. If I had to pic one dimension, I'd probably go with the number of cycles.

pub struct BlockFeeParameters {
asset_faucet_id: AccountId,
// Not clear whether Felt is sufficient but probably it is.
verification_base_fee: Felt,
nullifier_base_fee: Felt,
output_note_base_fee: Felt,
}

I think Felt is definitely enough, but I wonder if that is even needed. Maybe u32 would be sufficient. The native token will have either 6 or 8 decimal places and so with u32 the base fee could be as high as ~4.3K or ~43 to tokens (depending on decimal places) - which feel like it should be enough (especially in case of 6 decimal places).

Though, maybe this is not worth optimizing as these fields will probably be serialized using variable length encoding anyway.