Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: small clarifications #5

Merged
merged 6 commits into from
Oct 4, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 16 additions & 6 deletions protocol/additional-fee-scalars.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

#### Metadata

Authors: @puma314.
Authors: @puma314, @yuwen01.
Created: September 15, 2024.

# Purpose
Expand All @@ -28,11 +28,19 @@ The purpose of this design doc is to propose a simple addition to the existing f
While the length will likely be proportional to the length of the full document,
the summary should be as succinct as possible. -->

We propose the addition of 2 new rollup operator configured scalars (that can be updated via the `SystemConfig`) named `operatorFeeScalar` and `operatorFeeConstant` that factor in the fee calculation as follows:
We propose the addition of 2 new rollup operator configured scalars, collectively named the Operator Fee Parameters. These scalars are named
`operatorFeeScalar` and `operatorFeeConstant`, and they factor in the fee calculation as follows:
```
totalFee = operatorFeeConstant + operatorFeeScalar * gasUsed / 1e6 + gasUsed * (baseFee + priorityFee) + l1Fee
operatorFee = operatorFeeConstant + operatorFeeScalar * gasUsed / 1e6

totalFee = operatorFee + gasUsed * (baseFee + priorityFee) + l1Fee
```

These scalars will be updated via the `SystemConfig` L1 contract. A new role, the `OperatorFeeManager`, is added
to administrate the `operatorFeeScalar` and `operatorFeeConstant`.

A new fee vault, the `OperatorFeeVault`, is added to store the operator fee.

# Problem Statement + Context

<!-- Describe the specific problem that the document is seeking to address as well
Expand Down Expand Up @@ -73,17 +81,20 @@ The `operatorFee` will be directed to a new `FeeVault`, the `OperatorFeeVault`,

These 2 new config values can be added to the [`L1 attributes`](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/ecotone/l1-attributes.md) transaction, with a very small diff to the proof.

The chain governor (aka [System Config Owner](https://specs.optimism.io/protocol/configurability.html#system-config-owner)) will be responsible for updating these values. We expose a new function in the `SystemConfig` contract for updating the `operatorFeeScalar` and `operatorFeeConstant`.
We expose a new function in the `SystemConfig` contract for updating the `operatorFeeScalar` and `operatorFeeConstant`. This function is only callable by the `OperatorFeeManager`, a new role responsible for tuning the operator fee scalars. The `OperatorFeeManager` is administrated by
the chain governor.

```solidity
function setOperatorFeeScalars(uint32 operatorFeeScalar, uint64 operatorFeeConstant) external onlyOperatorFeeManager;
```

This function will emit a `ConfigUpdate` log-event, with a new `UpdateType`: `UpdateType.OPERATOR_FEE_SCALARS`.
It is also only callable by the `OperatorFeeManager`, a new role responsible for tuning the operator fee scalars.

In order to ensure a smooth network upgrade process, these scalars are automatically set to zero at the start of the upgrade.

The operator fee manager is automatically set to the chain governor at the start of the upgrade. The chain governor administers
the operator fee manager role.

## Analysis

* **Alt-DA**: For chains using alt-DA, the `operatorFeeConstant` is useful if there is a relatively constant overhead to posting to another DA layer.
Expand All @@ -97,7 +108,6 @@ Does it consume a large amount of computational resources or time? -->

The L1Attributes deposited transactions includes one extra slot of calldata -- the two new scalars,
storage packed together.
The SystemConfig contract stores the two scalars, requiring two new storage slots.

# Alternatives Considered

Expand Down