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.

[trianglesphere]

I saw comment somewhere, maybe gone by now, that there would be restrictions on how large the operator fee scalar and fee constant should be set. If this feature becomes a standard chain features I think that this restriction is very important to protect user funds.

[yuwen01]

I think that the operator fee will probably not become part of the superchain config since it adds complexity. Its purpose is more intended for non-standard chains, like op-succinct chains, for example.

My previous proposal wa the at the constant was between 0 and 600 Gwei and that the scalar was between 0 and 0.5x (basefee + priorityfee).

[refcell]

This looks good, just add a clarifier for the l1 block attributes function signature so it's clear what that value is at the top of the table in l1-attributes.md.

[yuwen01]

This looks good, just add a clarifier for the l1 block attributes function signature so it's clear what that value is at the top of the table in l1-attributes.md.

Thanks! Just fixed.

[yuwen01]

@sebastianst If you have a moment could you please review this spec?

[tynes]

cc @emhane @vdamle - Would be good to have your eyes on this as its isthmus related work

[leruaa]

@tynes About the possible conflicts in SystemConfig, my concern is mainly about that part with the Roles struct that don't exist yet, but added in ethereum-optimism/optimism#12932

[hashcashier]

While the simplicity here is appealing, this method of using gas to meter proving costs won't really work. The underlying assumption here is that gas correlates with proving cost, which doesn't really hold at all, and would lead often to a higher fee than what should be paid if the constant & scalar billing parameters are set to assume the worst-case ratio.

For example, SSTORE costs differ based on the delta from zero to non-zero values, and have gas refunds for clearing values. Cycle counts for a trie update in the stateless zk clients don't really follow these dynamics.

Do you think we can generalize this further into a more customizeable or precise metering approach?

[tynes]

@leruaa Do you mind sharing an update of the status of this?

[leruaa]

@tynes I think it's ready to be merged, all the feedbacks have been handled.

[tynes]

This section is underspecified. What are the definitions of the network upgrade transactions? The ecotone specs contain examples of this. This is important because the derivation pipeline has to deterministically create these transactions, ie who is the from, what is the to, what is the data? For the contract deployments, we need finalized bytecode, which will need to come from a release

[hashcashier]

Suggesting we use the transaction gas limit instead of metered usage to minimize the potential abuse of gas refunds on proving costs.

[hashcashier]

Suggested change

	`operatorFee = (gasUsed * operatorFeeScalar / 1e6) + operatorFeeConstant`
	`operatorFee = (gasLimit * operatorFeeScalar / 1e6) + operatorFeeConstant`

[hashcashier]

Suggested change

	- `gasUsed` is amount of gas used by the transaction.
	- `gasLimit` is the maximum amount of gas that can be used by the transaction.