isthmus: operator fee

[yuwen01]

Overview

We propose adding additional fee scalars to the fee formula, which allow for more flexibility for chains that leverage alt-DA, ZK proving, or custom gas tokens.

This spec goes with this design doc.

[sebastianst]

Also curious to hear from @tynes and @roberto-bayardo, who's implemented changes to the fee function in Fjord.

I propose to use a prefix for this feature that conveys more meaning, like OperatorFee or FixedFee.

[sebastianst]

I find the use of the prefix "configurable" a bit meaningless for this feature. Other fee parameters, like the (blob)BaseFeeScalars are also "configurable". Maybe we use a prefix that better describes the reason for their introduction, like

• OperatorFee
• operatorFeeScalar
• operatorFeeConstant
  or something similar that attaches more meaning to them? fixedFee... could also work.

[sebastianst]

Don't we want to set it to 1? Otherwise there's no fees any more.

[yuwen01]

The configurableFeeScalar is only scaled by the gas used -- it doesn't scale any of the existing fees. The goal is to add a separate component to the fee calculation, like base fee and priority fee.

[sebastianst]

So we don't need any fractional scaling, like we introduced with Fjord for the model parameters? I mean something like

Suggested change

	`configurableFee = gas_used * configurableFeeScalar + configurableFeeConstant`
	`configurableFee = (gas_used * configurableFeeScalar + configurableFeeConstant) / 1e6`

to allow for a decimal precision of 6.

[yuwen01]

Good point -- it makes sense for users to be able to have fractional scalars. However, I don't know why a user would want to have a fractional constant. The only reason I can think would be to save bits -- see my other comment.

[sebastianst]

Do we really want or need 64 bits instead of 32 bits size for the new parameters? E.g. the (blob)baseFeeScalars also worked with 32 bits (and also a decimal scaling factor, see other comment).

[yuwen01]

Thanks for the feedback! I agree with your point about renaming to operatorFee and allowing for 6 decimal points of precision, but I was a little unsure about reducing the bit width of the operatorFeeConstant and operatorFeeScalar.

I think it should be fine to decrease the Scalar to 32 bits, but I'm concerned that 32 bits won't be enough to represent the constant factor. For example, in this transaction https://optimistic.etherscan.io/tx/0xa6dfc18c35bf39fa60823e9280bde18496e27e9016040f7ad9ded6797c374f05, the total transaction fee in wei requires 43 bits to represent.

If we scale the constant term by a fixed factor we could fit it in 32 bits. But I don't know how much control a user might want over this constant.

[tynes]

We will also need an isHolocene bool as well as branching logic in the fee estimation functions

[tynes]

We will also want to include the specific ABI changes to the SystemConfig

[refcell]

Nice work.

[refcell]

I believe this should be padded to the start of the operatorFeeScalar.

i.e.

Suggested change

	- `[1, 8)`: padding, must be zero.
	- `[1, 12)`: padding, must be zero.

[yuwen01]

on second thought maybe this isn't necessary -- if we read the scalars from the l1block before isthmus is set, we'll just read from uninitialized storage, which defaults to 0. So the derived operator fee will just be 0.