specs: Eclipse / 4844 / Dencun draft

specs/deposits.md

@@ -34,6 +34,7 @@ with the authorization and validation conditions 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)
 - [User-Deposited Transactions](#user-deposited-transactions)
   - [Deposit Contract](#deposit-contract)
     - [Address Aliasing](#address-aliasing)
@@ -103,6 +104,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.
 
@@ -313,6 +316,16 @@ 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
+
+The L1 Attributes Predeployed contract, `L1Block.sol`, is upgraded in the Eclipse upgrade.
+
+- `overhead`: this getter function now reverts (TBD). Storage remains the same.
+- `scalar`: this getter function now reverts (TBD). Storage remains the same.
+- `x` (TBD): base-fee component scalar
+- `y` (TBD): DA-base-fee component scalar (blob base fee when operating with L1 DA)
+- `daBasefee`: the DA-base-fee.
+
 ## User-Deposited Transactions
 
 [user-deposited]: #user-deposited-transactions

specs/derivation.md

@@ -64,6 +64,7 @@
   - [L2 Chain Derivation Pipeline](#l2-chain-derivation-pipeline)
     - [L1 Traversal](#l1-traversal)
     - [L1 Retrieval](#l1-retrieval)
+      - [Eclipse: Blob Retrieval](#eclipse-blob-retrieval)
     - [Frame Queue](#frame-queue)
     - [Channel Bank](#channel-bank)
       - [Pruning](#pruning)
@@ -85,6 +86,9 @@
       - [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)
+      - [Eclipse: L1Block predeploy upgrade](#eclipse-l1block-predeploy-upgrade)
+      - [Eclipse: Beacon block roots contract deployment (EIP-4788)](#eclipse-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 -->
@@ -479,6 +483,27 @@ for each transaction:
 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].
 
+#### Eclipse: Blob Retrieval
+
+With the Eclipse upgrade the retrieval stage is extended to support an additional DA source: [EIP-4844] blobs.
+Upon each traversed transaction in the batch inbox:
+
+- 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.
+- Calldata is utilized, even if contained in a blob tx, and passed on to the next stage before any blob-data is.
+- If the transaction-type is `0x03` (`BLOB_TX_TYPE`): retrieve the blobs that match the `blob_versioned_hashes`.
+  - Blobs may be retrieved from 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.
+  - The rollup node SHOULD cryptographically verify if the retrieved blobs match the versioned hashes.
+
+On L1, the blob data is represented as a polynomial of points, each in range `[0, BLS_MODULUS)`,
+just below the capacity of a `uint256`: approximately `254.857` bits of data.
+Before proceeding with processing, the data is transformed to turn it into a continuous byte string.
+
+TODO: blob encoding format. Version + length-prefix + maximize utilization of the data.
+
+[EIP-4844]: https://eips.ethereum.org/EIPS/eip-4844
+
 ### Frame Queue
 
 The Frame Queue buffers one data-transaction at a time,
@@ -929,6 +954,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 +966,114 @@ 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.
+
+#### Eclipse: L1Block predeploy upgrade
+
+The `L1Block` contract is upgraded to process the new Eclipse L1-data-fee parameters and L1 blob base-fee.
+
+The `L1Block` is called in the very first transaction of the block,
+and parsed to retrieve the L1 block attributes.
+
+To not modify or interrupt the above system transaction behavior,
+the `L1Block` contract upgrade is executed in the last block *before* the scheduled update.
+
+A deposit transaction is derived with the following attributes:
+
+- `from`: `ProxyAdmin` owner
+- `to`: TBD (depending on multi-call approach)
+- `mint`: `0`
+- `value`: `0`
+- `gasLimit`: gas limit TBD
+- `isCreation`: `false`
+- `data`: bytecode TBD, a multi-call:
+  - deploy new contract implementation
+  - upgrade of `L1Block` through `ProxyAdmin`
+- `sourceHash`: `0x7dc74874297a8937186fdbec57ad344647a522de456088557e5fdeda88f66ddd`,
+  computed with the "Upgrade-deposited" type, with `intent = "Eclipse: L1Block upgrade"`
+
+Verify `sourceHash`:
+
+```bash
+# compute intent hash:
+cast keccak "Eclipse: L1Block upgrade"
+# 0x831b745c7397f93704ae55eb0100bf3c56fe9e304d3f21c1a93ec25f736fea26
+
+# source hash type:
+# 0x0000000000000000000000000000000000000000000000000000000000000002
+
+# compute source hash:
+cast keccak 0x0000000000000000000000000000000000000000000000000000000000000002831b745c7397f93704ae55eb0100bf3c56fe9e304d3f21c1a93ec25f736fea26
+# 0x7dc74874297a8937186fdbec57ad344647a522de456088557e5fdeda88f66ddd
+```
+
+#### Eclipse: 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`: `0xfbcd78e2e9665570c3f73026d601053af3892bdd06292d7eaf3adf4a1ee1392f`,
+  computed with the "Upgrade-deposited" type, with `intent = "Eclipse: 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
+# compute intent hash:
+cast keccak "Eclipse: beacon block roots contract deployment"
+# 0x4e73a20ffe4a8330eb1f726862f4b062301e73d081c6d3824a6e0bd6428697fe
+
+# source hash type:
+# 0x0000000000000000000000000000000000000000000000000000000000000002
+
+# compute source hash:
+cast keccak 0x00000000000000000000000000000000000000000000000000000000000000024e73a20ffe4a8330eb1f726862f4b062301e73d081c6d3824a6e0bd6428697fe
+# 0xfbcd78e2e9665570c3f73026d601053af3892bdd06292d7eaf3adf4a1ee1392f
+```
+
+[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,7 @@
   - [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)
 - [Engine API](#engine-api)
   - [`engine_forkchoiceUpdatedV2`](#engine_forkchoiceupdatedv2)
     - [Extended PayloadAttributesV2](#extended-payloadattributesv2)
@@ -22,6 +23,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)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
@@ -129,6 +132,10 @@ 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)
+
+TBD.
+
 ## Engine API
 
 <!--
@@ -305,6 +312,39 @@ 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
+
+[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:
+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.
+
+## Eclipse: 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 Eclipse 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 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/superchain-upgrades.md

@@ -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`: Eclipse - Very experimental, in development.
 
 ## Post-Bedrock Network upgrades
 
@@ -310,7 +311,32 @@ The Delta upgrade uses a *L2 block-timestamp* activation-rule, and is specified
 
 ## Eclipse
 
-Name of the next upgrade after Delta. Placeholder for development coordination.
+The Eclipse 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#eclipse-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#eclipse-beacon-block-root)
+    - [The Beacon roots contract deployment is automated](./derivation.md#eclipse-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 L1*
+  - [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#eclipse-blob-retrieval).
+- Rollup fee update: support blobs DA in
+  [L1 Data Fee computation](./exec-engine.md#eclipse-l1-cost-fee-changes-eip-4844-da)
+- Auto-upgrading and extension of the [L1 Attributes Predeployed Contract](./deposits.md#eclipse-l1block-upgrade)
+  (also known as `L1Block` predeploy)
 
 ## Fjord