Dynamic Fee Adjustment Crate

[gabriele-0201]

This PR extracts the fee adjustment logic into its own crate, requiring multiple modifications because each parameter needs to be passed to the struct instead of being used directly.

Open questions:

• Is DynamicFeeAdjustment an acceptable name?
• Is the positioning of the crate within the repository structure acceptable?
• Is it ok to define the storage item NextLengthMultiplier inside the crate?

TODOs:

• Fix tests
• Restack on top of node: use limiting proposer #157

[gabriele-0201]

Current dependencies on/for this PR:

• main
  • PR Blobs Fees Adjustments #149
    • PR Refactor Blobs Fees Adjustments #150
      • PR Unit Testing Blobs Fees Adjustments #151
        • PR AdjustmentVariable Blobs Fees Adjustments #152
          • PR Fee Adjustment Tests #153
            • PR Dynamic Fee Adjustment Crate #161 👈

This stack of pull requests is managed by Graphite.

[rphmeier]

How about sugondat-length-fee-adjustment?

[gabriele-0201]

OK, for now, I used pallet-sugondat-length-fee-adjustment. The only thing is that the pallet currently implements both length and weight to the fee. So, pallet-sugondat-dynamic-fee-adjustment is probably more general?

[rphmeier]

Is the positioning of the crate within the repository structure acceptable?

Seems fine to me! I also considered placing it within the runtime directory as it's a runtime utility crate, but we don't have many of those and a flat structure will be easier to navigate until overcrowded.

Is it ok to define the storage item NextLengthMultiplier inside the crate?

No. That should be done in each runtime individually. It would work, I think, but convention is not to define storage items within crates that are implicitly used by structures from that crate. That's for a good reason: there would be hidden magic when using the struct.

[rphmeier]

Actually, reflecting on the few questions you have brought to mind another approach.

I believe that this should be refactored into a new pallet. There are a few reasons for this:

1. We need a storage item, or perhaps several, for handling parameters. Definitely the NextLengthMultiplier would be better as a pallet storage item.
2. We will need some on_initialize logic to handle skipped blocks after node: use limiting proposer #157 . The logic will be extremely light, but requires some calculation. I suggest that in this PR, the pallet should not have any on-initialize logic.

This also answers the directory location question: it would exist in pallets, alongside blobs. I recommend for this pallet to require Config: pallet_transaction_payment::Config, and it can simply invoke <Config as pallet_transaction_payment::Config>::MultiplierUpdate internally to solve the issue of too many generic parameters.

[gabriele-0201]

The implementation has been moved to #174