Pectra: Span Batch Support

[tynes]

We will not be able to pull the Paris EVM spec as part of the Pectra hardfork into the OP stack until span batches are updated to support EIP-7702 transactions. You can see and example of the lack of support here

EIP-7702 is a huge UX win for Ethereum and we certainly want to be able to support it as early as possible. It will be a huge differentiator between EVM chains as applications that are built on it will not be able to support the same UX on chains that do not support it.

The span batch spec mentions a v2, we should consider adding EIP-7702 support to span batches v2.

Pectra is targeted to ship in early 2025 and we also want to make sure the spec for 7702 has been finalized before we invest too much time in implementing this

[tynes]

Span batch support for the set code tx type was implemented here

[tynes]

op-geth with 7702 support was implemented here

[threewebcode]

A new transaction type is added.

[emhane]

this involves a maili change after it's spec'd right @refcell ?

[emhane]

The span batch spec mentions a v2, we should consider adding EIP-7702 support to span batches v2.

~~wouldn't that be v3 @tynes ?~~ ah no it would be like a release of v2, which was prev only beta released, from linked spec

This is an experimental extension of the span-batch format, and not activated with the Delta upgrade yet.

[emhane]

as far as specs are concerned, the action items are:

• move the previously experimental v2 span batch format up under main heading https://github.com/ethereum-optimism/specs/blob/afadeea642d05eda6e111d9098c9a842c2ecf322/specs/protocol/delta/span-batches.md#span-batch-format
• move v1 span batch format down below, and give new heading "Legacy span batch format"

right @tynes ?

are there any blockers/open security concerns with stable releasing v2 format? considering it has been experimental until now, what has stabilised it? @protolambda @mslipper

[protolambda]

@emhane the fee_recipients experimental extension of span-batches isn't supported fully, and was added based on speculation of needs by external L2 chains which have since been unresponsive.

I think it's best if we keep the fee_recipients extension in a "legacy" sub-section. And then use type-3 span-batch for the EIP-7702 support, to avoid any possible conflict with other chains. And not include the fee_recipients feature there.

We should ask someone from product to investigate if fee_recipients is even used anywhere in the wild today.