Merge pull request #5401 from ethereum-optimism/qbzzt/230310-spec-wit…

…hdrawal

fix(specs): Rename l1Fee<x> to <x>

specs/deposits.md

@@ -118,8 +118,9 @@ Although we define only one new transaction type, we can distinguish between two
 transactions, based on their positioning in the L2 block:
 
 1. The first transaction MUST be a [L1 attributes deposited transaction][l1-attr-deposit], followed by
-2. an array of zero-or-more [user-deposited transactions][user-deposited] submitted to the deposit
-   feed contract on L1 (called `OptimismPortal`). User-deposited transactions are only present in the first block of a L2 epoch.
+2. an array of zero-or-more [user-deposited transactions][user-deposited]
+   submitted to the deposit feed contract on L1 (called `OptimismPortal`).
+   User-deposited transactions are only present in the first block of a L2 epoch.
 
 We only define a single new transaction type in order to minimize modifications to L1 client
 software, and complexity in general.
@@ -288,8 +289,8 @@ The predeploy stores the following values:
   and reset to 0 at the start of a new epoch.
 - System configurables tied to the L1 block, see [System configuration specification](./system_config.md):
   - `batcherHash` (`bytes32`): A versioned commitment to the batch-submitter(s) currently operating.
-  - `l1FeeOverhead` (`uint256`): The L1 fee overhead to apply to L1 cost computation of transactions in this L2 block.
-  - `l1FeeScalar` (`uint256`): The L1 fee scalar to apply to L1 cost computation of transactions in this L2 block.
+  - `overhead` (`uint256`): The L1 fee overhead to apply to L1 cost computation of transactions in this L2 block.
+  - `scalar` (`uint256`): The L1 fee scalar to apply to L1 cost computation of transactions in this L2 block.
 
 The contract implements an authorization scheme, such that it only accepts state-changing calls from
 the [depositor account][depositor-account].
@@ -320,7 +321,8 @@ generated by the [L2 Chain Derivation][g-derivation] process. The content of eac
 transaction are determined by the corresponding `TransactionDeposited` event emitted by the
 [deposit contract][deposit-contract] on L1.
 
-1. `from` is unchanged from the emitted value (though it may have been transformed to an alias in `OptimismPortal`, the deposit feed contract).
+1. `from` is unchanged from the emitted value (though it may
+   have been transformed to an alias in `OptimismPortal`, the deposit feed contract).
 2. `to` is any 20-byte address (including the zero address)
     - In case of a contract creation (cf. `isCreation`), this address is set to `null`.
 3. `mint` is set to the emitted value.

specs/system_config.md

@@ -6,7 +6,7 @@
 
 - [System config contents (version 0)](#system-config-contents-version-0)
   - [`batcherHash` (`bytes32`)](#batcherhash-bytes32)
-  - [`l1FeeOverhead` and `l1FeeScalar` (`uint256,uint256`)](#l1feeoverhead-and-l1feescalar-uint256uint256)
+  - [`overhead` and `scalar` (`uint256,uint256`)](#overhead-and-scalar-uint256uint256)
   - [`gasLimit` (`uint64`)](#gaslimit-uint64)
   - [`unsafeBlockSigner` (`address`)](#unsafeblocksigner-address)
 - [Writing the system config](#writing-the-system-config)
@@ -31,7 +31,7 @@ Version `0` embeds the current batch submitter ethereum address (`bytes20`) in t
 In the future this versioned hash may become a commitment to a more extensive configuration,
 to enable more extensive redundancy and/or rotation configurations.
 
-### `l1FeeOverhead` and `l1FeeScalar` (`uint256,uint256`)
+### `overhead` and `scalar` (`uint256,uint256`)
 
 The L1 fee parameters, also known as Gas Price Oracle (GPO) parameters,
 are updated in conjunction and apply new L1 costs to the L2 transactions.
@@ -70,7 +70,7 @@ A rollup node initializes its derivation process by finding a starting point bas
 - When started from L2 genesis, the initial system configuration is retrieved from the rollup chain configuration.
 - When started from an existing L2 chain, a previously included L1 block is determined as derivation starting point,
   and the system config can thus be retrieved from the last L2 block that referenced the L1 block as L1 origin:
-  - `batcherHash`, `l1FeeOverhead` and `l1FeeScalar` are retrieved from the L1 block info transaction.
+  - `batcherHash`, `overhead` and `scalar` are retrieved from the L1 block info transaction.
   - `gasLimit` is retrieved from the L2 block header.
   - other future variables may also be retrieved from other contents of the L2 block, such as the header.
 
@@ -86,8 +86,9 @@ The contained log events are filtered and processed as follows:
 - the remaining event data is opaque, encoded as ABI bytes (i.e. includes offset and length data),
   and encodes the configuration update. In version `0` the following types are supported:
   - type `0`: `batcherHash` overwrite, as `bytes32` payload.
-  - type `1`: `l1FeeOverhead` and `l1FeeScalar` overwrite, as two packed `uint256` entries.
+  - type `1`: `overhead` and `scalar` overwrite, as two packed `uint256` entries.
   - type `2`: `gasLimit` overwrite, as `uint64` payload.
+  - type `3`: `unsafeBlockSigner` overwrite, as `address` payload.
 
 Note that individual derivation stages may be processing different L1 blocks,
 and should thus maintain individual system configuration copies,