Isthmus: operator fee #382

yuwen01 · 2024-09-20T05:55:49Z

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.

specs/protocol/isthmus/configurability.md

sebastianst · 2024-09-23T19:12:15Z

specs/protocol/isthmus/exec-engine.md

+calculation: the `ConfigurableFee`, which is parameterized by two scalars: the `configurableFeeScalar`
+and the `configurableFeeConstant`.


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 · 2024-09-23T19:15:36Z

specs/protocol/isthmus/l1-attributes.md

+Blocks after the Isthmus activation block contain all pre-Isthmus values 1:1,
+and also set the following new attributes:
+
+- The `configurableFeeScalar` is set to `0`.


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

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 · 2024-09-23T19:18:48Z

specs/protocol/isthmus/exec-engine.md

+
+The configurable fee is set as follows:
+
+`configurableFee = gas_used * configurableFeeScalar + configurableFeeConstant`


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.

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 · 2024-09-23T19:21:29Z

specs/protocol/isthmus/l1-attributes.md

+| configurableFeeScalar  | uint64  | 180-187        |         |
+| configurableFeeConstant    | uint64  | 188-195        |         |


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

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 · 2025-01-13T18:09:13Z

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

leruaa · 2025-01-13T21:35:54Z

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

tynes · 2025-01-23T17:41:59Z

specs/protocol/isthmus/derivation.md

+# Network upgrade automation transactions
+
+The Isthmus hardfork activation block contains the following transactions, in this order:
+


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

Can you send a link to one of the ecotone specs that contains an example of the network upgrade transaction definitions?

I don't see a clear format in the derivation spec: https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/ecotone/derivation.md#ecotone-blob-retrieval

Looks like they are in the wrong place: https://github.com/ethereum-optimism/specs/blob/87e13cba8f34a68858a334fc2587041b712facfa/specs/protocol/derivation.md#network-upgrade-automation-transactions

I can move them to the correct place

hashcashier

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

specs/protocol/isthmus/exec-engine.md

…scalars

tynes · 2025-01-28T17:38:41Z

Another question - now that standard L2 genesis is being decoupled from this, what is the state of the implementation of the system config + operator fee vault? how is the RECIPIENT set?

tynes · 2025-01-28T23:44:33Z

We need to handle both the upgrade case and the from genesis case. How do we handle the new predeploy in the upgrade case? We have a requirement that the derivation pipeline upgrade transactions are deterministic, its not straight forward to set the RECIPIENT due to this constraint. I recommend the network upgrade tx deploys a FeeVault with the RECIPIENT set to address(0) and then chains that upgrade will need to set a new implementation with the RECIPIENT that they want. Without standard L2 genesis, there isn't much of a better way to do this

tynes · 2025-01-28T23:45:16Z

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

cc @yuwen01 @ratankaliani @leruaa thoughts on this?

tynes · 2025-01-29T00:28:03Z

Opened #562 so that you can see what a spec for network upgrade txs look like

leruaa · 2025-01-29T14:00:38Z

@tynes about @hashcashier suggestion, we think that gas used is more representative of proving costs. Furthermore, we are in favor of an incremental approach, rather than updating the current implementation, at the risk of delaying delivery. Especially considering it's possible that Isthmus could be advanced to cycle 35, and that an audit needs to be done.

…scalars

tynes · 2025-01-30T01:27:11Z

@leruaa I am more concerned about delivery being delayed due to underspecification of key parts that i have commented on without it being addressed in a timely manner

we think that gas used is more representative of proving costs.

Please explain why

puma314 · 2025-01-30T19:15:26Z

The gas_used represents the actual amount of gas/computation that is used for processing the transaction. The way that proving works is that every opcode that is processed incurs a certain amount of "cycles" in the zkVM, and so gas_used is a direct measure of the opcodes that are processed. The gas_limit is NOT correlated with this, so it is quite obvious to me that gas_used is significantly more correlated with proving costs vs. gas_limit?

I think @hashcashier should specify what potential "abuse" there might be on gas refunds, as that is not clear to me.

K-Ho · 2025-01-30T20:27:49Z

The gas_used represents the actual amount of gas/computation that is used for processing the transaction. The way that proving works is that every opcode that is processed incurs a certain amount of "cycles" in the zkVM, and so gas_used is a direct measure of the opcodes that are processed. The gas_limit is NOT correlated with this, so it is quite obvious to me that gas_used is significantly more correlated with proving costs vs. gas_limit?

I think @hashcashier should specify what potential "abuse" there might be on gas refunds, as that is not clear to me.

This makes sense to me.

We have agreed this is a v0 of how to accurately charge for zk proving costs, and that we will iterate on it in the future.
This feature is growing stale and as long as there is no security risk (which should be reviewed in the FMA review), we should not optimize towards getting this out into the real world and testing it over making the perfect formula on our first try.

We've iterated many times on the fee formula for accurately charging for L1 data fees, and I guarantee we will continue to make improvements to it

tynes · 2025-01-30T21:35:17Z

The gas_used represents the actual amount of gas/computation that is used for processing the transaction. The way that proving works is that every opcode that is processed incurs a certain amount of "cycles" in the zkVM, and so gas_used is a direct measure of the opcodes that are processed. The gas_limit is NOT correlated with this, so it is quite obvious to me that gas_used is significantly more correlated with proving costs vs. gas_limit?

I think @hashcashier should specify what potential "abuse" there might be on gas refunds, as that is not clear to me.

See the following EIP for an explanation: https://eips.ethereum.org/EIPS/eip-7778

It is a real thing, given you do not get your electricity and gpu time back in the same way that you get gas back onchain

tynes · 2025-01-30T21:39:34Z

specs/protocol/isthmus/configurability.md

-| `L1_ERC_721_BRIDGE_ADDRESS` | `uint8(5)` | Sets the `L1ERC721Bridge` address |
-| `L1_STANDARD_BRIDGE_ADDRESS` | `uint8(6)` | Sets the `L1StandardBridge` address |
-| `REMOTE_CHAIN_ID` | `uint8(7)` | Sets the chain id of the base chain |
+| `OPERATOR_FEE_VAULT_CONFIG` | `uint8(4)` | Sets the Fee Vault Config for the `OperatorFeeVault` |


Given we are not combining this with L2 standard genesis, we are going to need to rethink how we go about configuring the system. How does the existing solidity implementation work?

Seems like there was a bad merge in this file, I will have a look.

Currently I added a new method setOperatorFeeScalars(uint32, uint64) to SystemConfig. But reading the same file in the main branch, I see a section about Fee Vault Config, so I guess I should conform with that and add a function setOperatoreFeeVaultConfig(address,uint256,WithdrawalNetwork) method. Is it what you have in mind?

Ah ok, I saw the Fee Vault Config section is part of L2 standard genesis, so I won't need to conform with that.

tynes · 2025-01-30T21:45:01Z

specs/protocol/isthmus/derivation.md

+Verify `data`:
+
+```bash
+git checkout 905311d64d3df67649837ec57f0b0a4b6214ce31


This is a copypasta - we don't use pnpm anymore. Please prove to me that the bytecode in the txt file is legit

We are going to want to use a commit of a release. This means we will want to remove any rc suffix on the semver of the specific contracts being upgraded

tynes · 2025-01-30T23:58:50Z

specs/protocol/isthmus/predeploys.md

@@ -67,6 +73,7 @@ graph LR
  BaseFeeVault -- "getConfig(ConfigType.GAS_PAYING_TOKEN)(address,uint256,uint8)" --> L1Block
  SequencerFeeVault -- "getConfig(ConfigType.SEQUENCER_FEE_VAULT_CONFIG)(address,uint256,uint8)" --> L1Block
  L1FeeVault -- "getConfig(ConfigType.L1_FEE_VAULT_CONFIG)(address,uint256,uint8)" --> L1Block
+  OperatorFeeVault -- "getConfig(ConfigType.OPERATOR_FEE_VAULT_CONFIG)(address,uint256,uint8)" --> L1Block


i am confused about this integration into std L2 genesis, will need to look at what the implementation does

yuwen01 added 18 commits September 19, 2024 13:03

holocene exec-engine

f4ef24d

update other files in holocene directory

d2f40a0

update feevault

7ddbce3

dont change the function signature

2e12898

specify initial configurablefee

1407fa9

typos in exec engine

50c22ec

remove configurablefeevault

78cb4cb

linter

6a78e21

clean up + pack storage slots

fb53c85

optimize packing a little

b56048a

oxford comma

7c90f2b

rephrase

f4e27b3

move changes to isthmus

1526415

reset holocene

7085d98

linter

148230b

update configupdate version

fbf8dfb

removed mention of holocene, added isthmus to SUMMARY

48a25af

merged main

98fdb84

yuwen01 marked this pull request as ready for review September 20, 2024 06:01

yuwen01 requested review from protolambda, sebastianst, ajsutton, tynes and mslipper as code owners September 20, 2024 06:01

yuwen01 added 5 commits September 20, 2024 10:38

fixed link

ead7704

add predeploys and system-config

1ade65a

update summary

4673839

rerun doctoc

b945faf

fix calldata

2f73dc2

sebastianst reviewed Sep 23, 2024

View reviewed changes

emhane mentioned this pull request Jan 8, 2025

feat(protocol): Isthmus Operator Fee op-rs/maili#10

Draft

This was referenced Jan 10, 2025

feat: add FMA for operator fee ethereum-optimism/design-docs#186

Open

Bump revm version to ^v19.1.0 to include Isthmus operator fee feature op-rs/kona#898

Closed

tynes reviewed Jan 23, 2025

View reviewed changes

hashcashier suggested changes Jan 24, 2025

View reviewed changes

specs/protocol/isthmus/exec-engine.md Show resolved Hide resolved

specs/protocol/isthmus/exec-engine.md Show resolved Hide resolved

leruaa added 2 commits January 24, 2025 04:08

Merge remote-tracking branch 'origin/main' into yuwen/additional-fee-…

f205eae

…scalars

fix merge

ba1745e

benjaminion assigned leruaa and unassigned yuwen01 Jan 24, 2025

tynes mentioned this pull request Jan 29, 2025

ecotone: move upgrade txs to correct place #562

Open

Merge remote-tracking branch 'origin/main' into yuwen/additional-fee-…

74d388f

…scalars

leruaa added 3 commits January 30, 2025 10:44

add Isthmus operator fee network upgrade transactions

e70bc27

fix: lint

e64de24

fix: toc

92b2d4b

tynes reviewed Jan 30, 2025

View reviewed changes

leruaa added 2 commits January 31, 2025 00:47

fix: detangle operator fee spec from standard L2 genesis one

3d6b257

fix: remove use of pnpm

31500e1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Isthmus: operator fee #382

Isthmus: operator fee #382

yuwen01 commented Sep 20, 2024 •

edited

Loading

sebastianst left a comment •

edited

Loading

sebastianst Sep 23, 2024

sebastianst Sep 23, 2024

yuwen01 Sep 23, 2024

sebastianst Sep 23, 2024

yuwen01 Sep 23, 2024

sebastianst Sep 23, 2024

yuwen01 Sep 23, 2024

tynes commented Jan 13, 2025

leruaa commented Jan 13, 2025

tynes Jan 23, 2025

ratankaliani Jan 28, 2025

tynes Jan 28, 2025

hashcashier left a comment

tynes commented Jan 28, 2025

tynes commented Jan 28, 2025

tynes commented Jan 28, 2025

tynes commented Jan 29, 2025

leruaa commented Jan 29, 2025

tynes commented Jan 30, 2025

puma314 commented Jan 30, 2025

K-Ho commented Jan 30, 2025

tynes commented Jan 30, 2025

tynes Jan 30, 2025

leruaa Jan 30, 2025

leruaa Jan 30, 2025

tynes Jan 30, 2025

tynes Jan 30, 2025

tynes Jan 30, 2025

		calculation: the `ConfigurableFee`, which is parameterized by two scalars: the `configurableFeeScalar`
		and the `configurableFeeConstant`.


		The configurable fee is set as follows:

		`configurableFee = gas_used * configurableFeeScalar + configurableFeeConstant`

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

		\| configurableFeeScalar \| uint64 \| 180-187 \| \|
		\| configurableFeeConstant \| uint64 \| 188-195 \| \|

		# Network upgrade automation transactions

		The Isthmus hardfork activation block contains the following transactions, in this order:

Isthmus: operator fee #382

Are you sure you want to change the base?

Isthmus: operator fee #382

Conversation

yuwen01 commented Sep 20, 2024 • edited Loading

Overview

sebastianst left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tynes commented Jan 13, 2025

leruaa commented Jan 13, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hashcashier left a comment

Choose a reason for hiding this comment

tynes commented Jan 28, 2025

tynes commented Jan 28, 2025

tynes commented Jan 28, 2025

tynes commented Jan 29, 2025

leruaa commented Jan 29, 2025

tynes commented Jan 30, 2025

puma314 commented Jan 30, 2025

K-Ho commented Jan 30, 2025

tynes commented Jan 30, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yuwen01 commented Sep 20, 2024 •

edited

Loading

sebastianst left a comment •

edited

Loading