Skip to content

taiko-geth: post-Unzen txpool accepts type-3 txs that every sealer drops, so proposers pay L1 DA for dead bytes #22015

Description

@dantaik

Problem

Since Unzen activated Cancun/Prague/Osaka on L2 (mainnet fork time 2026-08-06 13:00 UTC), taiko-geth's blobpool is fork-active: a wrapped type-3 transaction submitted via eth_sendRawTransaction now passes txpool validation (core/txpool/validation.go only rejects blob txs pre-Cancun) and sits in the blobpool.

The proposal path then picks it up: buildTransactionsLists and getPendingTxs call w.txpool.Pending(...) without OnlyPlainTxs: true (miner/taiko_worker.go:74-79, 377), so the blob tx can be committed into a proposed txlist. But every sealer skips type-3 at block import (miner/taiko_worker.go:277-281, "Skip blob transactions"), so the transaction can never execute.

Net effect:

  • The proposer pays L1 DA (manifest bytes in the proposal blob) for transactions that are guaranteed to be dropped by every node at sealing.
  • Depending on the encoding path, a pool-resident blob tx RLP-encodes in wrapped form (~128 KiB sidecar per blob), inflating txlist bytes dramatically before pruning.
  • The blob tx lingers in the blobpool indefinitely (accepted, never mined).

Proposed fix

Reject BlobTxType in taiko-geth's txpool validation while native L2 blob support is not active (a CHANGE(taiko) gate alongside the existing Taiko checks in core/txpool/validation.go), and/or pass OnlyPlainTxs: true in both Pending calls in miner/taiko_worker.go. Either is a one-line-scale change; doing both is belt-and-suspenders.

When native L2 blob support ships (design under review in #22014, §8 "Pool" rows), the gate becomes fork-conditional (!IsV7-style) rather than unconditional.

References

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions