Spec updates for Eclipse upgrade:

- l1 block attribute changes

- l1 cost func changes

- GasPriceOracle changes

- SystemConfig contract changes

- SystemConfig log event processing changes

specs/deposits.md

@@ -30,11 +30,12 @@ with the authorization and validation conditions on L2.
     - [Nonce Handling](#nonce-handling)
 - [Deposit Receipt](#deposit-receipt)
 - [L1 Attributes Deposited Transaction](#l1-attributes-deposited-transaction)
+  - [L1 Attributes Deposited Transaction Calldata](#l1-attributes-deposited-transaction-calldata)
 - [Special Accounts on L2](#special-accounts-on-l2)
   - [L1 Attributes Depositor Account](#l1-attributes-depositor-account)
   - [L1 Attributes Predeployed Contract](#l1-attributes-predeployed-contract)
     - [L1 Attributes Predeployed Contract: Reference Implementation](#l1-attributes-predeployed-contract-reference-implementation)
-    - [Eclipse L1Block upgrade](#eclipse-l1block-upgrade)
+    - [Ecotone L1Block upgrade](#ecotone-l1block-upgrade)
 - [User-Deposited Transactions](#user-deposited-transactions)
   - [Deposit Contract](#deposit-contract)
     - [Address Aliasing](#address-aliasing)
@@ -163,8 +164,9 @@ The deposit transaction is processed exactly like a type-3 (EIP-1559) transactio
 - No L1-cost fee is charged, as deposits are derived from L1 and do not have to be submitted as data back to it.
 - No base fee is charged. The total base fee accounting does not change.
 
-Note that this includes contract-deployment behavior like with regular transactions,
-and gas metering is the same (with the exception of fee related changes above), including metering of intrinsic gas.
+Note that this includes contract-deployment behavior like with regular transactions, and gas
+metering is the same (with the exception of fee related changes above), including metering of
+intrinsic gas.
 
 Any non-EVM state-transition error emitted by the EVM execution is processed in a special way:
 
@@ -244,19 +246,41 @@ This transaction MUST have the following values:
    contract][predeploy]).
 3. `mint` is `0`
 4. `value` is `0`
-5. `gasLimit` is set to 150,000,000.
-6. `isSystemTx` is set to `true`.
-7. `data` is an [ABI] encoded call to the [L1 attributes predeployed contract][predeploy]'s
-   `setL1BlockValues()` function with correct values associated with the corresponding L1 block (cf.
-   [reference implementation][l1-attr-ref-implem]).
-
-If the Regolith upgrade is active, some fields are overridden:
-
-1. `gasLimit` is set to 1,000,000
-2. `isSystemTx` is set to `false`
-
-This system-initiated transaction for L1 attributes is not charged any ETH for its allocated `gasLimit`,
-as it is effectively part of the state-transition processing.
+5. `gasLimit` is set to 150,000,000 prior to the Regolith upgrade, and 1,000,000 after.
+6. `isSystemTx` is set to `true` prior to the Regolith upgrade, and `false` after.
+7. `data` is an encoded call to the [L1 attributes predeployed contract][predeploy] that
+depends on the upgrades that are active (see below).
+
+This system-initiated transaction for L1 attributes is not charged any ETH for its allocated
+`gasLimit`, as it is considered part of state-transition processing.
+
+### L1 Attributes Deposited Transaction Calldata
+
+Prior to the Ecotone upgrade, the `data` field of the L1 attributes deposited transaction is an
+[ABI][ABI] encoded call to the `setL1BlockValues()` function with correct values associated with
+the corresponding L1 block (cf.  [reference implementation][l1-attr-ref-implem]).
+
+If the Ecotone upgrade is active, then `data` is instead a call to the `setL1BlockValuesEcotone()`
+function, where the input args are no longer ABI encoded function parameters, but are instead
+packed into 5 32-byte aligned segments (starting after the function selector). Each unsigned
+integer argument is encoded as big-endian using a number of bytes corresponding to the underlying
+type. The overall calldata layout is as follows:
+
+| Input arg         | Type        | Calldata bytes | Segment |
+| ----------------- | ----------- | -------------- | --------|
+| {0x440a5e20}      |             | 0-3            | n/a     |
+| basefeeScalar     | uint32      | 4-7            | 1       |
+| blobBasefeeScalar | uint32      | 8-11           |         |
+| sequenceNumber    | uint64      | 12-19          |         |
+| l1BlockTimestamp  | uint64      | 20-27          |         |
+| l1BlockNumber     | uint64      | 28-35          |         |
+| basefee           | uint256     | 36-67          | 2       |
+| blobBasefee       | uint256     | 68-99          | 3       |
+| l1BlockHash       | bytes32     | 100-131        | 4       |
+| batcherHash       | bytes32     | 132-163        | 5       |
+
+Total calldata length must be exactly 164 bytes, implying the sixth and final segment is only
+partially filled.
 
 ## Special Accounts on L2
 
@@ -295,6 +319,13 @@ The predeploy stores the following values:
   - `batcherHash` (`bytes32`): A versioned commitment to the batch-submitter(s) currently operating.
   - `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.
+- With the Ecotone upgrade, the predeploy additionally stores:
+  - `blobBasefee` (`uint256`)
+  - `baseFeeScalar` (`uint32`): system configurable to scale the `basefee` in the Ecotone l1 cost computation
+  - `blobBasefeeScalar` (`uint32`): system configurable to scale the `blobBasefee` in the Ecotone l1 cost computation
+
+Following the Ecotone upgrade, `overhead` and `scalar` are frozen at the values they had on the
+block immediately prior to the fork.
 
 The contract implements an authorization scheme, such that it only accepts state-changing calls from
 the [depositor account][depositor-account].
@@ -316,9 +347,9 @@ After running `pnpm build` in the `packages/contracts-bedrock` directory, the by
 the genesis file will be located in the `deployedBytecode` field of the build artifacts file at
 `/packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json`.
 
-#### Eclipse L1Block upgrade
+#### Ecotone L1Block upgrade
 
-The L1 Attributes Predeployed contract, `L1Block.sol`, is upgraded in the Eclipse upgrade.
+The L1 Attributes Predeployed contract, `L1Block.sol`, is upgraded in the Ecotone upgrade.
 
 - `overhead`: this getter function now reverts (TBD). Storage remains the same.
 - `scalar`: this getter function now reverts (TBD). Storage remains the same.

specs/exec-engine.md

@@ -12,7 +12,8 @@
   - [Priority fees (Sequencer Fee Vault)](#priority-fees-sequencer-fee-vault)
   - [Base fees (Base Fee Vault)](#base-fees-base-fee-vault)
   - [L1-Cost fees (L1 Fee Vault)](#l1-cost-fees-l1-fee-vault)
-    - [Eclipse L1-Cost fee changes (EIP-4844 DA)](#eclipse-l1-cost-fee-changes-eip-4844-da)
+    - [Pre-Ecotone](#pre-ecotone)
+    - [Ecotone L1-Cost fee changes (EIP-4844 DA)](#ecotone-l1-cost-fee-changes-eip-4844-da)
 - [Engine API](#engine-api)
   - [`engine_forkchoiceUpdatedV2`](#engine_forkchoiceupdatedv2)
     - [Extended PayloadAttributesV2](#extended-payloadattributesv2)
@@ -23,8 +24,8 @@
 - [Sync](#sync)
   - [Happy-path sync](#happy-path-sync)
   - [Worst-case sync](#worst-case-sync)
-- [Eclipse: disable Blob-transactions](#eclipse-disable-blob-transactions)
-- [Eclipse: Beacon Block Root](#eclipse-beacon-block-root)
+- [Ecotone: disable Blob-transactions](#ecotone-disable-blob-transactions)
+- [Ecotone: Beacon Block Root](#ecotone-beacon-block-root)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
@@ -99,9 +100,14 @@ The protocol funds batch-submission of sequenced L2 transactions by charging L2
 based on the estimated batch-submission costs.
 This fee is charged from the L2 transaction-sender ETH balance, and collected into the L1 Fee Vault.
 
-The exact L1 cost function to determine the L1-cost fee component of a L2 transaction is calculated as:
-`(rollupDataGas + l1FeeOverhead) * l1Basefee * l1FeeScalar / 1000000`
-(big-int computation, result in Wei and `uint256` range)
+The exact L1 cost function to determine the L1-cost fee component of a L2 transaction depends on
+the upgrades that are active.
+
+#### Pre-Ecotone
+
+Before Ecotone activation, L1 cost is calculated as:
+`(rollupDataGas + l1FeeOverhead) * l1Basefee * l1FeeScalar / 1e6` (big-int computation, result
+in Wei and `uint256` range)
 Where:
 
 - `rollupDataGas` is determined from the *full* encoded transaction
@@ -132,9 +138,43 @@ can be accessed in two interchangeable ways:
     - Overhead as big-endian `uint256` in slot `5`
     - Scalar as big-endian `uint256` in slot `6`
 
-#### Eclipse L1-Cost fee changes (EIP-4844 DA)
+#### Ecotone L1-Cost fee changes (EIP-4844 DA)
+
+Ecotone allows posting batches via Blobs which are subject to a new fee market. To account for this feature,
+L1 cost is computed as:
+
+`(compressedTxSize) * (l1Basefee*16*lBasefeeScalar + l1BlobBasefeeScalar*l1BlobBasefeeScalar) / 1e6`
+
+Where:
+
+- the computation is an unlimited precision integer computation, with the result in Wei and having
+  `uint256` range.
 
-TBD.
+- `compressedTxSize` is an approximation of how many bytes the transaction occupies in a compressed
+  batch. It is determined from the *full* encoded transaction as: `compressedTxSize = (zeroes*4 +
+  ones*16) / 16` (To preserve precision under integer arithmetic, the division by 16 is actually
+  performed at the very end of the fee computation together with the division by 1e6 as a single
+  division by 16e6.)
+
+- `l1Basefee` is the L1 basefee of the latest L1 origin registered in the L2 chain.
+
+- `l1BlobBasefee` is the blob gasprice, computed as described in [EIP-4844][4844-gas] from the
+  header of the latest registered L1 origin block.
+
+[4844-gas]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md#gas-accounting
+
+The two basefee values and their respective scalars can be accessed in two interchangeable
+ways:
+
+- read from the deposited L1 attributes (`l1BasefeeScalar`, `l1BlobBasefeeScalar`, `basefee`,
+  `blobBasefee`) of the current L2 block
+- read from the L1 Block Info contract (`0x4200000000000000000000000000000000000015`)
+  - using the respective solidity getter functions
+  - using direct storage-reads:
+    - basefee `uint256` in slot `1`
+    - blobBasefee `uint256` in slot `7`
+    - l1BasefeeScalar big-endian `uint32` slot `8` offset `4`
+    - l1BlobBasefeeScalar as big-endian `uint32` in slot `8` offset `0`
 
 ## Engine API
 
@@ -312,12 +352,12 @@ the operation within the engine is the exact same as with L1 (although with an E
 
 [rollup node spec]: rollup-node.md
 
-## Eclipse: disable Blob-transactions
+## Ecotone: disable Blob-transactions
 
 [EIP-4844] introduces Blob transactions: featuring all the functionality of an [EIP-1559] transaction,
 plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
 
-With the Eclipse upgrade, all Cancun L1 execution features are enabled, with [EIP-4844] as exception:
+With the Ecotone upgrade, all Cancun L1 execution features are enabled, with [EIP-4844] as exception:
 as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.
 
 EIP-4844 is disabled as following:
@@ -327,7 +367,7 @@ EIP-4844 is disabled as following:
 - Block-building code does not select EIP-4844 transactions.
 - An L2 block state-transition with EIP-4844 transactions is invalid.
 
-## Eclipse: Beacon Block Root
+## Ecotone: Beacon Block Root
 
 [EIP-4788] introduces a "beacon block root" into the execution-layer block-header and EVM.
 This block root is an [SSZ hash-tree-root] of the consensus-layer contents of the previous consensus block.
@@ -335,10 +375,10 @@ This block root is an [SSZ hash-tree-root] of the consensus-layer contents of th
 With the adoption of [EIP-4399] in the Bedrock upgrade the OP-Stack already includes the `PREVRANDAO` of L1.
 And thus with [EIP-4788] the L1 beacon block root is made available.
 
-For the Eclipse upgrade, this entails that:
+For the Ecotone upgrade, this entails that:
 
 - The `parent_beacon_block_root` of the L1 origin is now embedded in the L2 block header.
-- The "Beacon roots contract" is deployed at Eclipse upgrade-time, or embedded at genesis if activated at genesis.
+- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
 - The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.
 
 [SSZ hash-tree-root]: https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md#merkleization

specs/predeploys.md

@@ -231,17 +231,26 @@ the L1 portion of the fee. This fee pays for using L1 as a data availability
 layer and should be added to the L2 portion of the fee, which pays for
 execution, to compute the total transaction fee.
 
-The values used to compute the L2 portion of the fee are:
+The values used to compute the L1 portion of the fee prior to the Ecotone upgrade are:
 
 - scalar
 - overhead
 - decimals
 
 After the Bedrock upgrade, these values are instead managed by the
-`SystemConfig` contract on L2. The `scalar` and `overhead` values
+`SystemConfig` contract on L1. The `scalar` and `overhead` values
 are sent to the `L1Block` contract each block and the `decimals` value
 has been hardcoded to 6.
 
+Following the Ecotone upgrade, the values used for L1 fee computation are:
+
+- l1BasefeeScalar
+- l1BlobBasefeeScalar
+- decimals
+
+These values are managed by the `SystemConfig` contract on the L1. The`decimals` remains hardcoded
+to 6, and the old `scalar` and `overhead` values are ignored.
+
 ## L1Block
 
 [Implementation](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L1Block.sol)