Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

experimental: support BLOB transactions and hybrid DA L2 #383

Closed
wants to merge 29 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
update
qzhodl committed Sep 14, 2024
commit 3b8f575b6be95630c117f990220c97697240ec72
13 changes: 10 additions & 3 deletions specs/experimental/l2-blob.md
Original file line number Diff line number Diff line change
@@ -45,20 +45,27 @@ The interface and implementation should remain consistent with L1 EL to ensure s
## Uploading BLOB to Alt-DA
The sequencer is responsible for uploading BLOBs to a 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 Alt-DA. Only after ensuring successful BLOB uploads can the sequencer upload the block data to the on-chain DA. Similarly, the sequencer may need to respond to any data availability challenges afterward.

## DataAavaliblityChallenage Contract
## Data Availability Challenge
Any third party, including full nodes deriving L1 data, might find they cannot access the data 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).

Since the data 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 this as the commitment for BLOB uploading/downloading and during challenge resolution. Therefore, we need to add a CommitmentType to the DataAvailabilityChallenge contract:
We will reuse the [DataAvailabilityChallenge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/DataAvailabilityChallenge.sol) contract with minimal modification. First, since the data 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 this as the commitment for BLOB uploading/downloading and during challenge resolution. Therefore, we need to add a CommitmentType to the DataAvailabilityChallenge contract:

```solidity
enum CommitmentType {
Keccak256,
Generic,
VersionedHash
}
```
Additionally, a new resolve function should be added to the contract:
Additionally, a new challenge and resolve function should be added to the contract:

```solidity
function challengeL2BLOB(
uint256 challengedL1BlockNumber,
uint256 challengedL2BlockNumber,
bytes calldata challengedCommitment
) external payable

function resolve(
uint256 challengedBlockNumber,
bytes calldata challengedCommitment,