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.

[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.

[tynes]

This is useful for the GasOracle predeploy that attempts to do L2 fee estimation

[tynes]

You can see here how we have handled this in the past. I believe we will need to include a calculation of the operator fee in the GasPriceOracle now

[tynes]

Can we create a role in the SuperchainConfig called "operator fee manager" and source the value from there? https://github.com/ethereum-optimism/specs/blob/d6b979ab67bd98bc3a15bf4988df08a066788047/specs/protocol/isthmus/superchain-config.md

This will make standard definition more simple, use the same superchain config that op gov recognizes, chain can also use their own superchain config if they are their own L2

[tynes]

Follow up: trying to align ongoing work that is changing with this so that things are coherent, this is the design that we are landing on.

The SystemConfig.initialize function would accept a Roles struct, it would be good to add the operatorFeeManager to that Roles struct and have no setter function meaning the operator can only change with another call to initialize. This helps keep the ABI slim and allows for each chain operator to have its own individual account that is used.

It is still possible to have each chain have its own individual accounts in the world where its sourced from the SuperchainConfig, it just means that chains that aren't governed by Optimism would deploy their own SuperchainConfig. Apologies for the back and forth, was trying to be consistent with designs in the Standard L2 Genesis project and we were flip flopping internally on how we were going to do it

[yuwen01]

This makes more sense to me than the superchain solution, happy to proceed in this direction. Once the spec lands for the Roles struct then I'll update this spec accordingly -- I've been yet unable to find reference to the design choices you linked.

[tynes]

We don't need to have the manager be a ConfigUpdate, you can remove this

[tynes]

I would like to delete this setter and instead source the fee manager from the superchain config as mentioned in a previous comment

[tynes]

This spec is looking great so far! Implementation will want to build on top of ethereum-optimism/optimism#12057 which is targeting audit Nov 4th, so it should be merged in over the next 2 weeks

[refcell]

Any updates here?

[yuwen01]

Hi! Sorry for the delay, but I've updated the spec setting the operator fee manager in the Roles struct. See system-config.md in the isthmus folder.

[maurelian]

what is this?

[yuwen01]

That's the call signature for the function. Those 4 bytes are the first four bytes of keccak("setL1BlockValuesIsthmus()"). I'll clarify this in the spec.

[refcell]

Bump on adding this to the spec to make it clear what this is

[tynes]

small nit: I think its fine to omit the trailing () when there is no return arg

[tynes]

This isn't noted anywhere, apologies about that, but its probably best to put these configurability requirements in this file so they are all in a single place

Also we would like to say that the requirement for these values is 0 for now for the superchain, with op-succinct you can use them however you would like, then when we do add zk as part of the superchain's proof system we can define the ranges of values. We don't have bandwidth to really think deeply about what the standard values should be from a product perspective and while what you have now could make sense, I don't want to ratify something thru gov that ultimately isnt right

[tynes]

This generally looks good to me. Some work started in ethereum-optimism/optimism#12847 to define the config for isthmus that you can build on. cc @vdamle for visibility

[tynes]

cc @trianglesphere come leave a review please

[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.