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

- `l1FeeScalar` is actually `scalar` in the code.
- `l1FeeOverhead` is actually `overhead` in the code.

Didn't change `exec-engine.md` because there those variable names are defined correctly.

Also added update config transaction type 3 to the doc.

Based on https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/names/213.md

Closing: DEVRL-847

specs/deposits.md

@@ -288,8 +288,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].

specs/system_config.md

@@ -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,