From 2093c1a3582befa10ba2fd24c5f3b46d30fb242a Mon Sep 17 00:00:00 2001 From: qiang Date: Sun, 29 Sep 2024 16:21:05 +0800 Subject: [PATCH 1/8] L2 BLOB --- protocol/l2-blob.md | 199 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 199 insertions(+) create mode 100644 protocol/l2-blob.md diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md new file mode 100644 index 00000000..aeaa090a --- /dev/null +++ b/protocol/l2-blob.md @@ -0,0 +1,199 @@ +# Purpose + + + + +Currently, EIP-4844 BLOB transactions are disabled on the OP Stack because Layer 2 (L2) BLOBs offer no advantage over L2 calldata when both use the same L1 DA. This forces L3s settled on L2 to rely on the same DA as their L2, unless they want to integrate third-party DA providers or manage the security risks associated with DA bridges. However, different DA solutions have their own advantages—L1 DA provides better security, while [Alt-DA](https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md) offers lower costs. + +The purpose of this design document is to propose supporting L2 BLOBs based on Alt-DA, allowing us to leverage the advantages of both L1 DA and Alt-DA, creating a hybrid DA solution in the OP Stack. + +# Summary + + + +This document proposes support for BLOB transactions, enabling a **hybrid DA model** in the OP Stack: + - L2 calldata uses L1 DA. + - L2 BLOBs use Alt-DA. + +This enables users and applications on 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: +- High-value data (e.g., financial data) goes to L2 calldata & L1 DA; +- Low-value data (e.g., GameFi) goes to L2 BLOB & Alt-DA. + +# Problem Statement + Context + + + +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) +``` + +# Proposed Solution + + + +## 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. + +# Alternatives Considered + + + +As mentioned above, L3s could integrate third-party DA services on their own, but they would have to manage the complexities of integration. Different DA services have varying interfaces and security assumptions, particularly for DA bridges. It would be beneficial to have an enshrined 4844-compatible L2 DA layer, allowing L3s (most of which are app-specific) to focus on their application logic rather than spending time on infrastructure + +# Risks & Uncertainties + + + +Should be similar to those described in the Alt-DA [spec](https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md). + +# Reference Implementation + +1. [optimism repo changes](https://github.com/ethstorage/optimism/pull/23) +2. [op-geth repo changes](https://github.com/ethstorage/op-geth/pull/2) From 8e72b01011c108ada3e937dfd2922f5db3bc9c3f Mon Sep 17 00:00:00 2001 From: Qiang Zhu Date: Sun, 29 Sep 2024 16:38:04 +0800 Subject: [PATCH 2/8] Update l2-blob.md --- protocol/l2-blob.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md index aeaa090a..0a601923 100644 --- a/protocol/l2-blob.md +++ b/protocol/l2-blob.md @@ -37,7 +37,7 @@ costs on L1 remain high compared to L2, leading to high costs for L2 state propo 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 +which settle on L2, to have an enshrined 4844-compatible 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. @@ -123,7 +123,7 @@ function resolveL2BLOB( ) ``` -This new resolve function should use a L1 BLOB transaction to upload the BLOB, then employ the EIP-4844 `blobhash()` +This new resolve function should use an 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 From db9f62c643a2bfb97fc224513f46331e33ce1726 Mon Sep 17 00:00:00 2001 From: Qiang Zhu Date: Sun, 29 Sep 2024 16:40:12 +0800 Subject: [PATCH 3/8] Update l2-blob.md --- protocol/l2-blob.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md index 0a601923..e561e9db 100644 --- a/protocol/l2-blob.md +++ b/protocol/l2-blob.md @@ -4,7 +4,7 @@ -Currently, EIP-4844 BLOB transactions are disabled on the OP Stack because Layer 2 (L2) BLOBs offer no advantage over L2 calldata when both use the same L1 DA. This forces L3s settled on L2 to rely on the same DA as their L2, unless they want to integrate third-party DA providers or manage the security risks associated with DA bridges. However, different DA solutions have their own advantages—L1 DA provides better security, while [Alt-DA](https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md) offers lower costs. +Currently, EIP-4844 BLOB transactions are disabled on the OP Stack because Layer 2 (L2) BLOBs offer no advantage over L2 calldata when both use the same L1 DA. This forces L3s to rely on the same DA as their L2, unless they want to integrate third-party DA providers or manage the security risks associated with DA bridges. However, different DA solutions have their own advantages—L1 DA provides better security, while [Alt-DA](https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md) offers lower costs. The purpose of this design document is to propose supporting L2 BLOBs based on Alt-DA, allowing us to leverage the advantages of both L1 DA and Alt-DA, creating a hybrid DA solution in the OP Stack. From a5196de0e2fcfdcc8e79d78c84fdff5f06e47193 Mon Sep 17 00:00:00 2001 From: Qiang Zhu Date: Sun, 29 Sep 2024 16:52:07 +0800 Subject: [PATCH 4/8] Update l2-blob.md --- protocol/l2-blob.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md index e561e9db..c967101b 100644 --- a/protocol/l2-blob.md +++ b/protocol/l2-blob.md @@ -184,7 +184,7 @@ DataAvailabilityChallenge contract. -As mentioned above, L3s could integrate third-party DA services on their own, but they would have to manage the complexities of integration. Different DA services have varying interfaces and security assumptions, particularly for DA bridges. It would be beneficial to have an enshrined 4844-compatible L2 DA layer, allowing L3s (most of which are app-specific) to focus on their application logic rather than spending time on infrastructure +As mentioned above, L3s could integrate third-party DA services on their own, but they would need to manage the complexities of integration. Different DA services come with varying interfaces and security assumptions, especially concerning DA bridges. Having an enshrined 4844-compatible L2 DA layer would allow L3s (most of which are app-specific) to focus on their application logic, rather than spending time dealing with infrastructure. # Risks & Uncertainties From d88a33d72ef8cbed8d9333b4e8c9262ecad68703 Mon Sep 17 00:00:00 2001 From: Qiang Zhu Date: Tue, 8 Oct 2024 09:55:27 +0800 Subject: [PATCH 5/8] Update protocol/l2-blob.md Co-authored-by: Qi Zhou --- protocol/l2-blob.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md index c967101b..a16c8c07 100644 --- a/protocol/l2-blob.md +++ b/protocol/l2-blob.md @@ -84,7 +84,7 @@ 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` +CL (op-node) of the sequencer receives the payload from its 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. From 35d54ec08992b8045119f23a3fcb0132f791d7f0 Mon Sep 17 00:00:00 2001 From: qiang Date: Wed, 9 Oct 2024 12:11:00 +0800 Subject: [PATCH 6/8] fix comments --- protocol/l2-blob.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md index a16c8c07..e2698f6a 100644 --- a/protocol/l2-blob.md +++ b/protocol/l2-blob.md @@ -4,9 +4,12 @@ -Currently, EIP-4844 BLOB transactions are disabled on the OP Stack because Layer 2 (L2) BLOBs offer no advantage over L2 calldata when both use the same L1 DA. This forces L3s to rely on the same DA as their L2, unless they want to integrate third-party DA providers or manage the security risks associated with DA bridges. However, different DA solutions have their own advantages—L1 DA provides better security, while [Alt-DA](https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md) offers lower costs. +Currently, EIP-4844 BLOB transactions are disabled on the OP Stack, leading to two issues: -The purpose of this design document is to propose supporting L2 BLOBs based on Alt-DA, allowing us to leverage the advantages of both L1 DA and Alt-DA, creating a hybrid DA solution in the OP Stack. + - There is no enshrined L2 BLOB DA solution for L3s, forcing them to integrate third-party DA providers and manage the security risks associated with DA bridges if they don’t want to rely on the same DA as their L2. This is especially problematic if the L2 uses L1 DA, which has higher costs than Alt-DA, adding significant development complexity for L3 teams. + - It prevents many applications based on L1 BLOBs from migrating to L2 to take advantage of lower execution costs. + +The purpose of this design document is to propose supporting L2 BLOBs based on Alt-DA, allowing L3s to have an enshrined L2 BLOB DA to rely on, while also enabling applications based on L1 BLOBs to migrate to L2 seamlessly. # Summary @@ -78,8 +81,7 @@ is likely too low level. --> ## 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. +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 or relayed through a node that forwards them to the L2 sequencer. ## Uploading BLOB to Alt-DA @@ -167,12 +169,7 @@ 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 ``. +The derivation pipeline integrates with fault proofs by adding additional hint types to the preimage oracle to query the on-chain challenge status. ### `l1-l2blob-challenge-status ` From 9380461e18f12f7cc75e12cafba87009c1c52146 Mon Sep 17 00:00:00 2001 From: Qiang Zhu Date: Wed, 9 Oct 2024 13:48:14 +0800 Subject: [PATCH 7/8] Update protocol/l2-blob.md Co-authored-by: Qi Zhou --- protocol/l2-blob.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md index e2698f6a..20b6c0cc 100644 --- a/protocol/l2-blob.md +++ b/protocol/l2-blob.md @@ -42,7 +42,7 @@ 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-compatible 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. +L1 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 From 190d02f8b0fe26944f31211504a1174351b45965 Mon Sep 17 00:00:00 2001 From: Qiang Zhu Date: Wed, 9 Oct 2024 13:48:59 +0800 Subject: [PATCH 8/8] Update protocol/l2-blob.md Co-authored-by: Qi Zhou --- protocol/l2-blob.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/l2-blob.md b/protocol/l2-blob.md index 20b6c0cc..892f2d2b 100644 --- a/protocol/l2-blob.md +++ b/protocol/l2-blob.md @@ -93,7 +93,7 @@ to the L1 DA. Similarly, the sequencer may need to respond to any data availabil ## 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 +the hash included in the L2 BLOB transaction. In this case, they can initiate a data availability challenge on L1. 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).