ethereum / ethereum/execution-apis

How to handle reorg'ed blob txs

Open
#333 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Io
Stars
1.1k
Forks
530
Avg merge
5d 8h
Merged PRs (30d)
9

Description

When reorg happens, CL or EL clients take the reorg'ed objects (i.e. txs, attestations, exits... etc) and put them on the new canonical chain, so they are not lost. EL client handles txs reorging, but by itself, it's not sufficient to handle blob txs, because the blobs are not included within the blocks. EL clients may need more visibility to see all the blobs, such as flash bots inclusion. To satisfy this, CL needs to support EL. Here are a few options with tradeoffs:

1. CL pushes blobs to EL on every `newPayload` call.

2. CL pushes reorg'ed blobs hashes to EL on every `forkchoiceUpdated` call. EL can request them via p2p

1 and 2 are less ideal from our perspective. It couples EL and CL in ways we aren't comfortable with and in deeper ways than we had envisioned. CL clients will be required to make decisions about execution and deal with extra complexity. 1 also increases the latency, which delays state transition. It's probably best not to couple this resolution closing with engine API. Instead, the CL client could optionally call `sendRawTransaction` for reorg'ed blob txs, and the blob users could do the same too. It's also probably safe to assume blob users are more sophisticated, and they can also monitor blob txs status and resubmit in the event of reorg. Here is option 3

3. CL optionally can call `sendRawTransaction` on reorg'ed blob tx

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.