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:
-
CL pushes blobs to EL on every newPayload call.
-
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
- CL optionally can call
sendRawTransaction on reorg'ed blob tx
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:
CL pushes blobs to EL on every
newPayloadcall.CL pushes reorg'ed blobs hashes to EL on every
forkchoiceUpdatedcall. EL can request them via p2p1 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
sendRawTransactionfor 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 3sendRawTransactionon reorg'ed blob tx