diff --git a/specs/experimental/l2-blob.md b/specs/experimental/l2-blob.md new file mode 100644 index 000000000..7caedc5d5 --- /dev/null +++ b/specs/experimental/l2-blob.md @@ -0,0 +1,161 @@ +# L2 BLOB Transaction + + + +**Table of Contents** + +- [Overview](#overview) +- [Enabling BLOB Transactions in L2 EL](#enabling-blob-transactions-in-l2-el) +- [Uploading BLOB to Alt-DA](#uploading-blob-to-alt-da) +- [Data Availability Challenge](#data-availability-challenge) +- [Storage Requirement and BLOB Gas Cost](#storage-requirement-and-blob-gas-cost) +- [Derivation](#derivation) +- [Fault Proof](#fault-proof) + - [`l2-blob `](#l2-blob-commitment) + - [`l1-l2blob-challenge-status `](#l1-l2blob-challenge-status-commitment-blocknumber) + + + +## Overview + +The Ethereum Cancun upgrade has significantly reduced Layer 2 (L2) data uploading costs by introducing BLOB +transactions to Layer 1 (L1). This innovation has also enabled a variety of additional applications based on +the BLOBs due to their low cost, such as [blob.fm](https://blob.fm/), [EthStorage](https://ethstorage.io), and +[Ethscriptions](https://ethscriptions.com/). However, while the data upload costs have decreased, the execution +costs on L1 remain high compared to L2, leading to high costs for L2 state proposals and non-financial applications +that rely on BLOBs. + +The goal of this specification is to **support L2 BLOB transactions in the OP Stack**. This would allow L3 solutions, +which settle on L2, to have an enshrined 4844-compatiable DA layer that they can use directly, without needing to +integrate third-party DA providers or deal with the security risks associated with DA bridges. Additionally, the +applications mentioned above could migrate to L2 with minimal costs. + +Furthermore, this spec proposes using +[Alt-DA](https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md) to upload L2 BLOBs while +still using L1 DA for L2 calldata. This approach, referred to as a “hybrid DA L2”, combines the best features of +different DA solutions. This allows +users and applications of an L2 to choose between L1 DA and alt-DA for different types of transaction data within the +same network, without the need to maintain multiple L2s. Specifically, users can upload and store non-financial data +at a very low cost using L2 BLOBs and Alt-DA, while still conducting critical financial data using L2 calldata and +L1 DA. In some cases, these two types of data may even occur within the same transaction. Here are a few potential +scenarios: + +- While the Optimism mainnet continues to use L1 DA for uploading calldata, multiple app-specific or game-focused +L3s settled on it can directly use the enshrined 4844-compatible L2 DA layer, benefiting from easy integration, robust +security, and lower costs. +- Users might use a platform like Decentralized Twitter primarily for social networking (non-financial), while +also sending payments (financial) to other users within the same application. + +The following diagram illustrates the transaction data flow for a hybrid DA L2: + +```mermaid +flowchart + A[Users] -->|Non-financial Tx Using BLOB| B(L2) + A[Users] -->|Financial Tx Using Calldata| B(L2) + B -->|L2 BLOB| C(Alt-DA) + B -->|L2 Calldata| D(L1 DA) +``` + +## Enabling BLOB Transactions in L2 EL + +The interface and implementation of L2 EL should remain consistent with L1 EL to ensure seamless migration of +applications. Note that while BLOBs are gossiped within the L1 P2P network, for enshrined BLOB DA support in L2, the +BLOBs should be sent directly to the L2 sequencer. + +## Uploading BLOB to Alt-DA + +The sequencer is responsible for uploading BLOBs to the Alt-DA layer. When the +CL (op-node) receives the payload from EL via the engine API, it should inspect the envelope for any `BlobsBundle` +and upload them to the Alt-DA. Only after ensuring successful BLOB uploads can the sequencer upload the block data +to the L1 DA. Similarly, the sequencer may need to respond to any data availability challenges afterward. + +## Data Availability Challenge + +Any third party, including full nodes deriving L2 data, might find they cannot access the BLOB corresponding to +the hash included in the BLOB transaction. In this case, they can initiate a data availability challenge. The +workflow will largely follow the Alt-DA process outlined +[here](https://github.com/ethstorage/specs/blob/l2-blob/specs/experimental/alt-da.md#data-availability-challenge-contract). + +We will reuse the [DataAvailabilityChallenge][1] contract with minimal modification. First, since the BLOB hash in the BLOB +transaction is a +[VersionedHash](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md#helpers) +instead of a Keccak256 hash, we need to use the version hash as the commitment for BLOB uploading/downloading and +during challenge resolution. Therefore, we will add a CommitmentType to the DataAvailabilityChallenge contract: + +```solidity +enum CommitmentType { + Keccak256, + Generic, + VersionedHash +} +``` + +Additionally, a new challenge and resolve function should be added to the contract: + +```solidity +function challengeL2BLOB( + uint256 challengedOriginBlockNumber, + bytes calldata challengedCommitment +) external payable + +function resolveL2BLOB( + uint256 challengedOriginBlockNumber, + bytes calldata challengedCommitment, +) +``` + +This new resolve function should use a L1 BLOB transaction to upload the BLOB, then employ the EIP-4844 `blobhash()` +opcode to obtain the `versionedhash` of the BLOB. + +Note that the parameter `challengedOriginBlockNumber` in both the new challenge and resolve functions refers to the +original L1 block number corresponding to the L2 block containing the BLOB being challenged. This change also requires +that the `challenge_window` must be larger than the `sequence_window` to prevent cases where the challenge window has +already passed by the time the sequencer submits the batch on L1 + +[1]: https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/DataAvailabilityChallenge.sol + +## Storage Requirement and BLOB Gas Cost + +According to the EIP-4844 specification, BLOBs must be kept for at least +[MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS][2] +epochs, which is around 18 days. The storage upper limit can be calculated using the formula: +`BLOB_SIZE * MAX_BLOB_PER_BLOCK / BLOCK_TIME * MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS * SECONDS_PER_EPOCH`. +Assuming `MAX_BLOB_PER_BLOCK = 6` and `BLOCK_TIME = 2`, the upper limit is approximately 618 GB. + +To serve data challenge purposes, we can reduce disk requirements even further. According to the Alt-DA +[specification][3], data only needs to be available for `l2blobChallengeWindow + l2blobResolveWindow`. +If `l2blobChallengeWindow` is 43200 seconds and `l2blobResolveWindow` is 3600 seconds, the disk requirement +will be around 17 GB. + +These storage requirements are manageable for a commodity computer, and the cost of storing the data is minimal +compared to L1 data upload costs. This cost can be covered by adjusting the L1 `blobBaseFeeScalar` value. + +[2]: https://github.com/ethereum/consensus-specs/blob/4de1d156c78b555421b72d6067c73b614ab55584/configs/mainnet.yaml#L148 +[3]: https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md#data-availability-challenge-contract + +## Derivation + +Most of the derivation and reorg logic remains consistent with Alt-DA. However, instead of invalidating the entire +batch of the challenged origin, only the transaction containing the BLOB that is challenged and fails to be resolved +will be deleted. The basic workflow is as follows: + +1. When the op-node derives a batch from the `BatchQueue`, it collects all the BLOB commitments included in the batch. +2. It tracks the challenge and resolution status for the collected BLOB hashes. If some BLOBs are challenged and fail +to be resolved, the op-node should trigger a `ResetError` to initiate a reorg. +3. If a reorg is triggered, the op-node will revert to an older block and rederive the chain. Upon encountering a +block containing the expired BLOB hash, it will remove the corresponding transaction and pass the remaining block +data to the EL. + +## Fault Proof + +The derivation pipeline integrates with fault proofs by adding additional hint types to the preimage oracle to query +input data from the DA provider and the on-chain challenge status. + +### `l2-blob ` + +Retrieves BLOB data stored on the DA provider for the given ``. + +### `l1-l2blob-challenge-status ` + +Retrieves the challenge status for the given `` at the specified `` on the L1 +DataAvailabilityChallenge contract.