experimental: support BLOB transactions and hybrid DA L2

[qzhodl]

Description

This spec proposes support for BLOB transactions, allowing for a hybrid DA model in the OP Stack:

• L2 calldata uses L1 DA.
• L2 BLOBs use Alt-DA.

Benefits:

• This approach combines the best features of different DA solutions, allowing 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.
• It enables L3 solutions, which settle on L2, to utilize an enshrined 4844-compatible DA layer directly, without needing to integrate third-party DA providers or deal with the security risks of DA bridges. Additionally, various applications based on L1 BLOBs could migrate to L2 with minimal costs.

[ajsutton]

Is the idea here that the BLOB data submitted as part of L2 transactions is submitted to the data availability layer (either L1 or alt-da) or that it is temporarily stored as part of the L2 chain?

If it's submitted to the data availability layer, with 6 blobs per L2 block the blob capacity on L2 would be 6 times what is available on L1 making it impossible to actually submit all that data. Even restricting L2 to just 1 blob per block would consume the entire available blob space on L1 and would still be effectively impossible to submit as there are other systems utilising some of the L1 blob space. Alt-da may be able to keep up but the only case using blobs on L2 would save money is where call data is sent to L1 and blob data to an alt-da. Otherwise both L2 call data and L2 blob data would need to be priced the same since they ultimately wind up being stored in the same place.

On the other hand if the L2 blob data is just stored temporarily by L2 nodes, there's no real guarantee of availability - L2 doesn't have the same depth of nodes to ensure the data remains available.

[qzhodl]

Is the idea here that the BLOB data submitted as part of L2 transactions is submitted to the data availability layer (either L1 or alt-da) or that it is temporarily stored as part of the L2 chain?

If it's submitted to the data availability layer, with 6 blobs per L2 block the blob capacity on L2 would be 6 times what is available on L1 making it impossible to actually submit all that data. Even restricting L2 to just 1 blob per block would consume the entire available blob space on L1 and would still be effectively impossible to submit as there are other systems utilising some of the L1 blob space. Alt-da may be able to keep up but the only case using blobs on L2 would save money is where call data is sent to L1 and blob data to an alt-da. Otherwise both L2 call data and L2 blob data would need to be priced the same since they ultimately wind up being stored in the same place.

Hi, Adrian, you’re right, there are three possible DA configurations for an L2 that supports BLOB data:

1. Both the calldata and BLOBs in L2 use L1 DA.
2. Both the calldata and BLOBs in L2 use Alt-DA.
3. L2 calldata uses L1 DA, while L2 BLOBs use Alt-DA.

In this proposal, we will specifically focus on the third option, referred to as a “hybrid DA L2,” which combines the best features of different DA solutions.

More specifically, this allows 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 needing to maintain multiple L2s (e.g., Arbitrum One and Arbitrum Nova). Users can upload and store non-financial data at a very low cost using L2 BLOBs and Alt-DA, while still conducting critical financial transactions 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.

[ajsutton]

Given that option 1 is non-viable, I'd probably drop it entirely. There's just not enough blob space on L1 for it to be the DA for L2 blobs unless L2 was somehow restricted to 1 blob per X blocks (and X may need to be variable depending on how much data is still trying to be posted to L1).

I'm not sure what benefit option 2 provides given that call data and blob data is stored in the same DA and so will have the same underlying cost. I'd be tempted to drop it as well and just focus on the case you're actually interested in.

I can see the user benefit of 3 and it seems at least viable. Whether or not it the security trade off and complexity for users in attempting to understand those security trade offs for a chain is worth it is a bigger question. While for developers being able to choose the DA type is a benefit, for users it's a highly technical complication that impacts the safety of their data. The chain can at least be sync'd even without any of the blob data though which is an advantage, but withholding or delaying access to that data could open up new attack vectors that are important to think though (potentially even for non-financial data). Not saying that as a blocker, just something to be fleshed out and carefully thought through.

[qzhodl]

I can see the user benefit of 3 and it seems at least viable. Whether or not it the security trade off and complexity for users in attempting to understand those security trade offs for a chain is worth it is a bigger question. While for developers being able to choose the DA type is a benefit, for users it's a highly technical complication that impacts the safety of their data. The chain can at least be sync'd even without any of the blob data though which is an advantage, but withholding or delaying access to that data could open up new attack vectors that are important to think though (potentially even for non-financial data). Not saying that as a blocker, just something to be fleshed out and carefully thought through.

Hi, Adrian, thanks for your feedback and insights. Here are some of our considerations regarding your concerns about the UX and security trade-offs:

• Complexity for Users. There are mainly three types of users for a Layer 2. Let’s break it down:
  • Layer 3 Developers: They may actually have a better experience, as they will have an enshrined 4844-compatible DA interface without needing to integrate third-party Alt-DA solutions or worry about DA bridge security. At the same time, they will benefit from lower costs provided by Alt-DA. I believe option 3 can help to provide a significant competitive advantage for the OP Stack, fostering a rich L3 ecosystem (e.g., app-specific or game-focused L3s).
  • L2 Application Developers: They need to understand the difference between calldata DA and BLOB DA. Since Ethereum L1 has already helped educate the ecosystem on these concepts, I don’t see this as a major blocker for developers. Once they understand the distinctions, they can significantly reduce costs for their end users.
  • End Users of L2 Applications: End users will benefit from lower costs without needing to understand the underlying technologies used by the application developers.
• Security Trade-off. This spec considers the security model in the Data Availability Challenge and Derivation sections. Essentially, it shares the same security model as the Alt-DA spec:
  • 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.
  • Derivation: The full node need to track 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. This ensures that BLOB data availability is guaranteed by the L2 consensus.

[qizhou]

• Security Trade-off. This spec considers the security model in the Data Availability Challenge and Derivation sections. Essentially, it shares the same security model as the Alt-DA spec:

  • 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.
  • Derivation: The full node need to track 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. This ensures that BLOB data availability is guaranteed by the L2 consensus.

Additionally, by paying a small storage fee to the EthStorage L2 contract as part of the BLOB L2 transaction, users can opt for enhanced security:

• Mitigating the 'Verifier's Dilemma': In the EthStorage network, storage nodes act as permissionless verifiers. They download BLOBs from the DA servers and challenge any missing BLOBs. Without downloading the BLOBs, nodes cannot generate the necessary storage proof and, as a result, are unable to claim the storage fee.

• Extended Availability: The storage fee is deposited into the EthStorage L2 contract and distributed to storage nodes over time when they submit valid storage proofs (using a proof-of-replication puzzle mechanism). This process can extend over multiple years or even longer, ensuring long-term data availability.

[qzhodl]

@ajsutton Hi Adrian, we’d love to hear any additional feedback you may have on this spec.

[qzhodl]

The PR description and spec content have been updated based on @ajsutton’s feedback.

[tynes]

cc @mdehoog