Enable Proto-Danksharding on testnet

[palango]

Enable proto-danksharding on the testnet

• [x] Enable blob batch submission policy. See also https://github.com/ethereum-optimism/optimism/pull/8769
  • Set --data-availability-type=blobs in batcher config
• [x] Check if L1 data reading needs to be adapted.

[jcortejoso]

I've tested this on different testnets, with Holesky as Layer1. It seems to work as expected (well). Some lessons:

• L2 testnet needs to have Ecotone hardfork enabled/active.
• We need a Beacon Node provider for op-node syncing using blob data. So far the more reliable (and with a free-usage option) is https://www.rockx.com/. Using other providers (publicnode free holesky beacon endpoint) caused some issues.
• On L1 testnets (also on Mainet but I think in a lower degree) Blob data price is most of the time low but it has very noticiable peaks that may last for several minutes. During this periods, txfee can multiply x1000 that "normal-condition" fees (1wei blob gas price). To avoid using too much ether from the batcher and minimize the impact of these periods, setting high values of OP_BATCHER_MAX_CHANNEL_DURATION (500-5000) will avoid making "empty" batcher txs and optimize the costs on L1. Also setting a high number of OP_BATCHER_TARGET_NUM_FRAMES (combined with OP_BATCHER_MAX_CHANNEL_DURATION) would optimize the L1 fees, at cost of increasing time interval for L2 block transition from unsafe -> safe (particularly if activity on L2 is low).

Example of batcher transactions with different blob gas price conditions: High gas Fee: Low/Normal gas fee:

[palango]

We need a Beacon Node provider for op-node syncing using blob data. So far the more reliable (and with a free-usage option) is https://www.rockx.com/. Using other providers (publicnode free holesky beacon endpoint) caused some issues.

For full syncing nodes we also might need a blob archive node: https://docs.optimism.io/builders/node-operators/management/blobs#configure-a-blob-archiver-archive-nodes See #232 and #233 for the respective issues.

Regarding costs, I assume it's still cheaper than posting it as call data?

[jcortejoso]

For full syncing nodes we also might need a blob archive node: https://docs.optimism.io/builders/node-operators/management/blobs#configure-a-blob-archiver-archive-nodes

Yes, exactly (op-node fullsync)

Regarding costs, I assume it's still cheaper than posting it as call data?

In most and what we probably could say "expected" conditions, blob data should be cheaper than calldata (particularly on Mainnet). But I guess there can be conditions where it can be more expensive to use blob data depending on network conditions, activity on L2 and missconfigurations on your batcher. As summary things I've learned:

• Gas Fee market and blob fee market are different markets and independent, and if gas demand is low but blob demand is high, it can be cheaper to use calldata
• In my short experience testing this, I think is particularly the case for ETH testnets (Sepolia and Holesky) where blob data price seems to have very noticiable peaks (unfortunately I could not find any data aggregation service tracking blob fee price for testnets, apart from checking the blocks manually on etherscan or https://blobscan.com/).
• Minimum blob space you can submit (and pay) is 128kb (1 frame), so if you have low L2 activity and low batcher submitting window OP_BATCHER_MAX_CHANNEL_DURATION, you may be submitting almost empty blobs to L1.
• In addition it seems current op-batcher implementation cannot dynamically choose the number of blob frames per transaction, so if you've configured 6 frames (better configuration for increasing your batcher L1 throughput), but the L2 does not generate enough data to fill those 6 frames, the batcher would be paying 6 128kb blobFee * tx (tx depends on channel duration), wasting a lot of blob space that needs to be paid anyway.

But I think in "normal" conditions we can expect blob DA to be cheaper than calldata DA. Also my initial guess to me is that blob DA throughput can be higher that calldata throughput, in case of very high activity on L2.

Also as a summary recommendation:

• Use calldata if your L2 has very low activity (and low OP_BATCHER_MAX_CHANNEL_DURATION).
• Use blob with 1 frame when your L2 has low-moderate load, and you want to speed up L1 submission speed (lower OP_BATCHER_MAX_CHANNEL_DURATION windows).
• Use blob with 6 frames for as the more efficient L1 gas option, and also the configuration with more throughput. This is the desired configuration for savings fees while having a medium-high L2 activity. Downside is that it may take longer to commit your L2 data on L1, particularly for applications/providers that are waiting for L1 state (bridges, exchanges, etc...)..