Merge pull request #8602 from ethereum-optimism/eclipse-specs

specs: Ecotone / 4844 / Dencun

specs/deposits.md

@@ -30,10 +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)
+    - [Ecotone L1Block upgrade](#ecotone-l1block-upgrade)
 - [User-Deposited Transactions](#user-deposited-transactions)
   - [Deposit Contract](#deposit-contract)
     - [Address Aliasing](#address-aliasing)
@@ -103,6 +105,8 @@ The `sourceHash` of a deposit transaction is computed based on the origin:
   And `seqNumber = l2BlockNum - l2EpochStartBlockNum`,
   where `l2BlockNum` is the L2 block number of the inclusion of the deposit tx in L2,
   and `l2EpochStartBlockNum` is the L2 block number of the first L2 block in the epoch.
+- Upgrade-deposited: `keccak256(bytes32(uint256(2)), keccak256(intent))`.
+  Where `intent` is a UTF-8 byte string, identifying the upgrade intent.
 
 Without a `sourceHash` in a deposit, two different deposited transactions could have the same exact hash.
 
@@ -160,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:
 
@@ -241,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
 
@@ -292,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].
@@ -313,6 +347,19 @@ 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`.
 
+#### Ecotone L1Block upgrade
+
+The L1 Attributes Predeployed contract, `L1Block.sol`, is upgraded as part of the Ecotone upgrade.
+The version is incremented to `1.2.0` and several new storage slots are used for:
+
+- `blobBasefee` (`uint256`): The L1 basefee for blob transactions.
+- `blobBasefeeScalar` (`uint256`): The scalar value applied to the L1 blob base fee portion of the L1 cost.
+- `basefeeScalar` (`uint256`): The scalar value applied to the L1 base fee portion of the L1 cost.
+
+Additionally, the `setL1BlockValues` function is deprecated and replaced with `setL1BlockValuesEcotone`.
+`setL1BlockValuesEcotone` uses packed encoding for its parameters, which is described in
+[L1 Attributes Deposited Transaction Calldata](#l1-attributes-deposited-transaction-calldata)
+
 ## User-Deposited Transactions
 
 [user-deposited]: #user-deposited-transactions

specs/derivation.md

@@ -64,6 +64,8 @@
   - [L2 Chain Derivation Pipeline](#l2-chain-derivation-pipeline)
     - [L1 Traversal](#l1-traversal)
     - [L1 Retrieval](#l1-retrieval)
+      - [Ecotone: Blob Retrieval](#ecotone-blob-retrieval)
+        - [Blob Encoding](#blob-encoding)
     - [Frame Queue](#frame-queue)
     - [Channel Bank](#channel-bank)
       - [Pruning](#pruning)
@@ -85,6 +87,14 @@
       - [About reorgs Post-Merge](#about-reorgs-post-merge)
 - [Deriving Payload Attributes](#deriving-payload-attributes)
   - [Deriving the Transaction List](#deriving-the-transaction-list)
+    - [Network upgrade automation transactions](#network-upgrade-automation-transactions)
+      - [Ecotone](#ecotone)
+        - [L1Block Deployment](#l1block-deployment)
+        - [GasPriceOracle Deployment](#gaspriceoracle-deployment)
+        - [L1Block Proxy Update](#l1block-proxy-update)
+        - [GasPriceOracle Proxy Update](#gaspriceoracle-proxy-update)
+        - [GasPriceOracle Enable Ecotone](#gaspriceoracle-enable-ecotone)
+        - [Beacon block roots contract deployment (EIP-4788)](#beacon-block-roots-contract-deployment-eip-4788)
   - [Building Individual Payload Attributes](#building-individual-payload-attributes)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
@@ -469,15 +479,113 @@ updated, such that the batch-sender authentication is always accurate to the exa
 
 ### L1 Retrieval
 
-In the *L1 Retrieval* stage, we read the block we get from the outer stage (L1 traversal), and extract data from it.
-By default, the rollup operates on calldata retrieved from [batcher transactions][g-batcher-transaction] in the block,
-for each transaction:
+In the *L1 Retrieval* stage, we read the block we get from the outer stage (L1 traversal), and
+extract data from its [batcher transactions][g-batcher-transaction]. A batcher
+transaction is one with the following properties:
 
-- The receiver must be the configured batcher inbox address.
-- The sender must match the batcher address loaded from the system config matching the L1 block of the data.
+- The [`to`] field is equal to the configured batcher inbox address.
 
-Each data-transaction is versioned and contains a series of [channel frames][g-channel-frame] to be read by the
-Frame Queue, see [Batch Submission Wire Format][wire-format].
+- The sender, as recovered from the transaction signature (`v`, `r`, and `s`), is the batcher
+  address loaded from the system config matching the L1 block of the data.
+
+Each batcher transaction is versioned and contains a series of [channel frames][g-channel-frame] to
+be read by the Frame Queue, see [Batch Submission Wire Format][wire-format]. Each batcher
+transaction in the block is processed in the order they appear in the block by passing its calldata
+on to the next phase.
+
+[`to`]: https://github.com/ethereum/execution-specs/blob/3fe6514f2d9d234e760d11af883a47c1263eff51/src/ethereum/frontier/fork_types.py#L52C31-L52C31
+
+#### Ecotone: Blob Retrieval
+
+With the Ecotone upgrade the retrieval stage is extended to support an additional DA source:
+[EIP-4844] blobs. After the Ecotone upgrade we modify the iteration over batcher transactions to
+treat transactions of transaction-type == `0x03` (`BLOB_TX_TYPE`) differently. If the batcher
+transaction is a blob transaction, then its calldata MUST be ignored should it be present. Instead:
+
+- For each blob hash in `blob_versioned_hashes`, retrieve the blob that matches it. A blob may be
+    retrieved from any of a number different sources. Retrieval from a local beacon-node, through
+    the `/eth/v1/beacon/blob_sidecars/` endpoint, with `indices` filter to skip unrelated blobs, is
+    recommended.  For each retrieved blob:
+  - The blob SHOULD (MUST, if the source is untrusted) be cryptographically verified against its
+    versioned hash.
+  - If the blob has a [valid encoding][#blob-encoding], decode it into its continuous byte-string
+    and pass that on to the next phase. Otherwise the blob is ignored.
+
+Note that batcher transactions of type blob must be processed in the same loop as other batcher
+transactions to preserve the invariant that batches are always processed in the order they appear
+in the block. We ignore calldata in blob transactions so that it may be used in the future for
+batch metadata or other purposes.
+
+##### Blob Encoding
+
+Each blob in a [EIP-4844] transaction really consists of `FIELD_ELEMENTS_PER_BLOB = 4096` field elements.
+
+Each field element is a number in a prime field of
+`BLS_MODULUS = 52435875175126190479447740508185965837690552500527637822603658699938581184513`.
+This number does not represent a full `uint256`: `math.log2(BLS_MODULUS) = 254.8570894...`
+
+The [L1 consensus-specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md)
+describe the encoding of this polynomial.
+The field elements are encoded as big-endian integers (`KZG_ENDIANNESS = big`).
+
+To save computational overhead, only `254` bits per field element are used for rollup data.
+
+`127` bytes of application-layer rollup data is encoded at a time, into 4 adjacent field elements of the blob:
+
+```python
+# read(N): read the next N bytes from the application-layer rollup-data. The next read starts where the last stopped.
+# write(V): append V (one or more bytes) to the raw blob.
+bytes tailA = read(31)
+byte x = read(1)
+byte A = x & 0b0011_1111
+write(A)
+write(tailA)
+
+bytes tailB = read(31)
+byte y = read(1)
+byte B = (y & 0b0000_1111) | (x & 0b1100_0000) >> 2)
+write(B)
+write(tailB)
+
+bytes tailC = read(31)
+byte z = read(1)
+byte C = z & 0b0011_1111
+write(C)
+write(tailC)
+
+bytes tailD = read(31)
+byte D = ((z & 0b1100_0000) >> 2) | ((y & 0b1111_0000) >> 4)
+write(D)
+write(tailD)
+```
+
+Each written field element looks like this:
+
+- Starts with one of the prepared 6-bit left-padded byte values, to keep the field element within valid range.
+- Followed by 31 bytes of application-layer data, to fill the low 31 bytes of the field element.
+
+The written output should look like this:
+
+```text
+<----- element 0 -----><----- element 1 -----><----- element 2 -----><----- element 3 ----->
+| byte A |  tailA...  || byte B |  tailB...  || byte C |  tailC...  || byte D |  tailD...  |
+```
+
+The above is repeated 1024 times, to fill all `4096` elements,
+with a total of `(4 * 31 + 3) * 1024 = 130048` bytes of data.
+
+When decoding a blob, the top-most two bits of each field-element must be 0,
+to make the encoding/decoding bijective.
+
+The first byte of rollup-data (second byte in first field element) is used as a version-byte.
+
+In version `0`, the next 3 bytes of data are used to encode the length of the rollup-data, as big-endian `uint24`.
+Any trailing data, past the length delimiter, must be 0, to keep the encoding/decoding bijective.
+If the length is larger than `130048 - 4`, the blob is invalid.
+
+If any of the encoding is invalid, the blob as whole must be ignored.
+
+[EIP-4844]: https://eips.ethereum.org/EIPS/eip-4844
 
 ### Frame Queue
 
@@ -929,6 +1037,7 @@ Therefore, a [`PayloadAttributesV2`][expanded-payload] object must include the f
   - a single *[L1 attributes deposited transaction][g-l1-attr-deposit]*, derived from the L1 origin.
   - for the first L2 block in the epoch, zero or more *[user-deposited transactions][g-user-deposited]*, derived from
     the [receipts][g-receipts] of the L1 origin.
+- zero or more [network upgrade automation transactions]: special transactions to perform network upgrades.
 - zero or more *[sequenced transactions][g-sequencing]*: regular transactions signed by L2 users, included in the
   sequencer batch.
 
@@ -940,6 +1049,232 @@ entries.
 
 [deposit-contract-spec]: deposits.md#deposit-contract
 
+### Network upgrade automation transactions
+
+[network upgrade automation transactions]: #network-upgrade-automation-transactions
+
+Some network upgrades require automated contract changes or deployments at specific blocks.
+To automate these, without adding persistent changes to the execution-layer,
+special transactions may be inserted as part of the derivation process.
+
+#### Ecotone
+
+The Ecotone hardfork activation block, contains the following transactions in this order:
+
+- L1 Attributes Transaction, using the pre-Ecotone `setL1BlockValues`
+- User deposits from L1
+- Network Upgrade Transactions
+  - L1Block deployment
+  - GasPriceOracle deployment
+  - Update L1Block Proxy ERC-1967 Implementation Slot
+  - Update GasPriceOracle Proxy ERC-1967 Implementation Slot
+  - GasPriceOracle Enable Ecotone
+  - Beacon block roots contract deployment (EIP-4788)
+
+To not modify or interrupt the system behavior around gas computation, this block will not include any sequenced
+transactions by setting `noTxPool: true`.
+
+##### L1Block Deployment
+
+The `L1Block` contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee.
+
+A deposit transaction is derived with the following attributes:
+
+- `from`: `0x4210000000000000000000000000000000000000`
+- `to`: `null`
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: `300,000` (TBC)
+- `data`: L1Block deploy bytecode (TBC when PR for contracts is merged)
+- `sourceHash`: `0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8`,
+  computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
+
+This results in the Ecotone L1Block contract being deployed to `0x07dbe8500fc591d1852B76feE44d5a05e13097Ff`, to verify:
+
+```bash
+cast compute-address --nonce=0 0x4210000000000000000000000000000000000000
+Computed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
+```
+
+Verify `sourceHash`:
+
+```bash
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
+# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
+```
+
+##### GasPriceOracle Deployment
+
+The `GasPriceOracle` contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract
+will use the blob base fee to compute the gas price for L1-data-fee transactions.
+
+A deposit transaction is derived with the following attributes:
+
+- `from`: `0x4210000000000000000000000000000000000001`
+- `to`: `null`,
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: `500,000` (TBC)
+- `data`: GasPriceOracle deploy bytecode (TBC when PR for contracts is merged)
+- `sourceHash`: `0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42`
+  computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
+
+This results in the Ecotone GasPriceOracle contract being deployed to `0xb528D11cC114E026F138fE568744c6D45ce6Da7A`,
+to verify:
+
+```bash
+cast compute-address --nonce=0 0x4210000000000000000000000000000000000001
+Computed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A
+```
+
+Verify `sourceHash`:
+
+```bash
+❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
+# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
+```
+
+##### L1Block Proxy Update
+
+This transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment.
+
+A deposit transaction is derived with the following attributes:
+
+- `from`: `0x0000000000000000000000000000000000000000`
+- `to`: `0x4200000000000000000000000000000000000015` (L1Block Proxy)
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: `200,000` (TBC)
+- `data`: `0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff`
+- `sourceHash`: `0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc`
+  computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
+
+Verify data:
+
+```bash
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
+0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
+```
+
+Verify `sourceHash`:
+
+```bash
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
+# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
+```
+
+##### GasPriceOracle Proxy Update
+
+This transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle
+deployment.
+
+A deposit transaction is derived with the following attributes:
+
+- `from`: `0x0000000000000000000000000000000000000000`
+- `to`: `0x420000000000000000000000000000000000000F` (Gas Price Oracle Proxy)
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: `200,000` (TBC)
+- `data`: `0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a`
+- `sourceHash`: `0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a`
+  computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Proxy Update"`
+
+Verify data:
+
+```bash
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
+0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a
+```
+
+Verify `sourceHash`:
+
+```bash
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
+# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a
+```
+
+##### GasPriceOracle Enable Ecotone
+
+This transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula.
+
+A deposit transaction is derived with the following attributes:
+
+- `from`: `0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001` (Depositer Account)
+- `to`: `0x420000000000000000000000000000000000000F` (Gas Price Oracle Proxy)
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: `1,000,000` (TBC)
+- `data`: `0x22b90ab3`
+- `sourceHash`: `0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93`,
+  computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Set Ecotone"
+
+Verify data:
+
+```bash
+cast sig "setEcotone()"
+0x22b90ab3
+```
+
+Verify `sourceHash`:
+
+```bash
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
+# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93
+```
+
+##### Beacon block roots contract deployment (EIP-4788)
+
+[EIP-4788] introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
+at address `BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02`.
+
+For deployment, [EIP-4788] defines a pre-[EIP-155] legacy transaction, sent from a key that is derived such that the
+transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.
+
+However, this type of transaction requires manual deployment and gas-payments.
+And since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain,
+the deployment is approached differently here.
+
+Some chains may already have a user-submitted instance of the [EIP-4788] transaction.
+This is cryptographically guaranteed to be correct, but may result in the upgrade transaction
+deploying a second contract, with the next nonce. The result of this deployment can be ignored.
+
+A Deposit transaction is derived with the following attributes:
+
+- `from`: `0x0B799C86a49DEeb90402691F1041aa3AF2d3C875`, as specified in the EIP.
+- `to`: null
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: `0x3d090`, as specified in the EIP.
+- `isCreation`: `true`
+- `data`:
+  `0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500`
+- `isSystemTx`: `false`, as per the Regolith upgrade, even the system-generated transactions spend gas.
+- `sourceHash`: `0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c`,
+  computed with the "Upgrade-deposited" type, with `intent = "Ecotone: beacon block roots contract deployment"`
+
+The contract address upon deployment is computed as `rlp([sender, nonce])`, which will equal:
+
+- `BEACON_ROOTS_ADDRESS` if deployed
+- a different address (`0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B`) if `nonce = 1`:
+  when a user already submitted the EIP transaction before the upgrade.
+
+Verify `BEACON_ROOTS_ADDRESS`:
+
+```bash
+cast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875
+# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
+```
+
+Verify `sourceHash`:
+
+```bash
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
+# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
+```
+
+[EIP-4788]: https://eips.ethereum.org/EIPS/eip-4788
+[EIP-155]: https://eips.ethereum.org/EIPS/eip-155
+
 ## Building Individual Payload Attributes
 
 [payload attributes]: #building-individual-payload-attributes

specs/exec-engine.md

@@ -12,6 +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)
+    - [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)
@@ -22,6 +24,8 @@
 - [Sync](#sync)
   - [Happy-path sync](#happy-path-sync)
   - [Worst-case sync](#worst-case-sync)
+- [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 -->
 
@@ -96,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
@@ -129,6 +138,44 @@ can be accessed in two interchangeable ways:
     - Overhead as big-endian `uint256` in slot `5`
     - Scalar as big-endian `uint256` in slot `6`
 
+#### 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.
+
+- `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
 
 <!--
@@ -305,6 +352,39 @@ the operation within the engine is the exact same as with L1 (although with an E
 
 [rollup node spec]: rollup-node.md
 
+## 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 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:
+
+- Transaction network-layer announcements, announcing blob-type transactions, are ignored.
+- Transactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool.
+- Block-building code does not select EIP-4844 transactions.
+- An L2 block state-transition with EIP-4844 transactions is invalid.
+
+## 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.
+
+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 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 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
+[EIP-4399]: https://eips.ethereum.org/EIPS/eip-4399
+[EIP-4788]: https://eips.ethereum.org/EIPS/eip-4788
+[EIP-4844]: https://eips.ethereum.org/EIPS/eip-4844
 [eip-1559]: https://eips.ethereum.org/EIPS/eip-1559
 [eip-2028]: https://eips.ethereum.org/EIPS/eip-2028
 [eip-2718]: https://eips.ethereum.org/EIPS/eip-2718

specs/predeploys.md

@@ -254,17 +254,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)

specs/superchain-upgrades.md

@@ -34,7 +34,7 @@ chains following the same Superchain Target upgrade synchronously.
   - [Regolith](#regolith)
 - [Canyon](#canyon)
 - [Delta](#delta)
-- [Eclipse](#eclipse)
+- [Ecotone](#ecotone)
 - [Fjord](#fjord)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
@@ -252,6 +252,7 @@ but the matching L1-origin information may not be present at the time of activat
 - `v4.0.0`: TBD - Canyon.
   [Governance proposal](https://gov.optimism.io/t/final-upgrade-proposal-2-canyon-network-upgrade/7088).
 - `v5.0.0-1`: Delta - Experimental, devnet pre-release stage.
+- `v6.0.0-1`: Ecotone - Very experimental, in development.
 
 ## Post-Bedrock Network upgrades
 
@@ -308,10 +309,35 @@ The Delta upgrade consists of a single consensus-layer feature: [Span Batches](.
 
 The Delta upgrade uses a *L2 block-timestamp* activation-rule, and is specified only in the rollup-node (`delta_time`).
 
-## Eclipse
+## Ecotone
 
-Name of the next upgrade after Delta. Placeholder for development coordination.
+The Ecotone upgrade contains the Dencun upgrade from L1, and adopts EIP-4844 blobs for data-availability.
+
+Dencun Upgrade:
+
+- Cancun (Execution Layer):
+  - [EIP-1153: Transient storage opcodes](https://eips.ethereum.org/EIPS/eip-1153)
+  - [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844)
+    - [Blob transactions are disabled](./exec-engine.md#ecotone-disable-blob-transactions)
+  - [EIP-4788: Beacon block root in the EVM](https://eips.ethereum.org/EIPS/eip-4788)
+    - [The L1 beacon block root is embedded into L2](./exec-engine.md#ecotone-beacon-block-root)
+    - [The Beacon roots contract deployment is automated](./derivation.md#ecotone-beacon-block-roots-contract-deployment-eip-4788)
+  - [EIP-5656: MCOPY - Memory copying instruction](https://eips.ethereum.org/EIPS/eip-5656)
+  - [EIP-6780: SELFDESTRUCT only in same transaction](https://eips.ethereum.org/EIPS/eip-6780)
+  - [EIP-7516: BLOBBASEFEE opcode](https://eips.ethereum.org/EIPS/eip-7516)
+- Deneb (Consensus Layer): *not applicable to L2*
+  - [EIP-7044: Perpetually Valid Signed Voluntary Exits](https://eips.ethereum.org/EIPS/eip-7044)
+  - [EIP-7045: Increase Max Attestation Inclusion Slot](https://eips.ethereum.org/EIPS/eip-7045)
+  - [EIP-7514: Add Max Epoch Churn Limit](https://eips.ethereum.org/EIPS/eip-7514)
+
+Data Availability (DA) upgrade:
+
+- Blobs Data Availability: support blobs DA the [L1 Data-retrieval stage](./derivation.md#ecotone-blob-retrieval).
+- Rollup fee update: support blobs DA in
+  [L1 Data Fee computation](./exec-engine.md#ecotone-l1-cost-fee-changes-eip-4844-da)
+- Auto-upgrading and extension of the [L1 Attributes Predeployed Contract](./deposits.md#ecotone-l1block-upgrade)
+  (also known as `L1Block` predeploy)
 
 ## Fjord
 
-Name of the next upgrade after Eclipse. Placeholder for development coordination.
+Name of the next upgrade after Ecotone. Placeholder for development coordination.

specs/system_config.md

@@ -6,7 +6,9 @@
 
 - [System config contents (version 0)](#system-config-contents-version-0)
   - [`batcherHash` (`bytes32`)](#batcherhash-bytes32)
-  - [`overhead` and `scalar` (`uint256,uint256`)](#overhead-and-scalar-uint256uint256)
+  - [Scalars](#scalars)
+    - [`overhead`,`scalar` (`uint256,uint256`)](#overheadscalar-uint256uint256)
+    - [`l1BasefeeScalar`,`l1BlobBasefeeScalar` (`uint32,uint32`)](#l1basefeescalarl1blobbasefeescalar-uint32uint32)
   - [`gasLimit` (`uint64`)](#gaslimit-uint64)
   - [`unsafeBlockSigner` (`address`)](#unsafeblocksigner-address)
 - [Writing the system config](#writing-the-system-config)
@@ -31,10 +33,20 @@ 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.
 
-### `overhead` and `scalar` (`uint256,uint256`)
+### Scalars
 
-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.
+The L1 fee parameters, also known as Gas Price Oracle (GPO) parameters, are used to compute the L1
+data fee applied to an L2 transaction.  The specific parameters used depend on the upgrades that
+are active.
+
+#### `overhead`,`scalar` (`uint256,uint256`)
+
+Prior to the Ecotone upgrade, `overhead` and `scalar` are consulted and passed to the L2 via L1
+attribute info.
+
+#### `l1BasefeeScalar`,`l1BlobBasefeeScalar` (`uint32,uint32`)
+
+After the Ecotone upgrade, `l1BasefeeScalar` and `l1BlobBasefeeScalar` are passed to the L2 instead.
 
 ### `gasLimit` (`uint64`)
 
@@ -70,7 +82,9 @@ 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`, `overhead` and `scalar` are retrieved from the L1 block info transaction.
+  - If the chain state precedes the Ecotone upgrade, `batcherHash`, `overhead` and `scalar` are
+    retrieved from the L1 block info transaction. Otherwise, `batcherHash`, `l1BasefeeScalar`, and
+    `l1BlobBasefeeScalar` are retrieved instead.
   - `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.
 
@@ -89,6 +103,10 @@ The contained log events are filtered and processed as follows:
   - 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.
+  - type `4`: `l1BasefeeScalar` and `l1BlobBasefeeScalar` overwrite, as two packed `uint32`
+    entries in [`abi.encodePacked()`][encodePacked] format.
+
+[encodePacked]: https://docs.soliditylang.org/en/latest/abi-spec.html#non-standard-packed-mode
 
 Note that individual derivation stages may be processing different L1 blocks,
 and should thus maintain individual system configuration copies,