fix(txpool): reject EIP-4844 blob txs at every mempool ingress - #394
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e0416806d2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Gravity does not support EIP-4844: the pipe-exec layer drops every type-3 transaction before grevm, so a blob tx admitted to the mempool can never be executed and only wastes pool capacity (and the KZG-verification cost on ingress). Disable blob support in the pool validator via `.no_eip4844()`. The type-3 reject in `validate_one` is origin-independent, so this single flag covers every mempool ingress: RPC `eth_sendRawTransaction` (Local) and PFN broadcast (External, which lands in the reth pool via `add_external_transaction`) alike. The consensus `OrderedBlock` path is already guarded separately by the pipe-exec `tx_filter`. Add a validator test asserting a blob tx is rejected with `Eip4844Disabled` on Local and External origins and through `add_external_transaction`. Remove the `can_handle_blobs` e2e test: it drives a full EthereumNode and injects a blob tx, which is now correctly rejected — the scenario is no longer applicable now that Gravity does not accept blob transactions.
e041680 to
9b53b76
Compare
Lchangliang
left a comment
Lchangliang
left a comment
There was a problem hiding this comment.
Reviewed locally. The txpool EIP-4844 rejection path looks correct, and the targeted tests plus e2e compile check pass.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e75f9ef495
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // This is origin-independent, so it covers every mempool ingress — RPC | ||
| // `eth_sendRawTransaction` (Local) and PFN broadcast (External via | ||
| // `add_external_transaction`) alike. | ||
| .no_eip4844() |
There was a problem hiding this comment.
When the node is started with --rpc.forwarder, eth_sendRawTransaction does not follow the Local -> add_transaction -> validator path described here: crates/rpc/rpc/src/eth/helpers/transaction.rs:40-55 forwards the raw bytes to the configured endpoint, ignores the subsequent local add_pool_transaction error, and returns the forwarded hash. In that configuration, a type-3 transaction can still get a successful RPC response and be sent downstream before this .no_eip4844() validator ever rejects it, so the pool-only gate does not cover every RPC ingress unless the RPC helper validates/rejects blobs before forwarding.
Useful? React with 👍 / 👎.
Bring in main's blob-rejection hardening (#394) and the SYSTEM_CALLER serial-vs-grevm convergence test (#395), rebasing #394 onto the v2.3.0 transaction-validator API. Conflict resolutions: - ethereum/node node.rs: keep v2.3.0 `eth_builder(provider, evm_config)` and drop the config-gated `set_eip4844(!blobs_disabled)`; apply #394's unconditional `.no_eip4844()` so Gravity rejects every EIP-4844 tx at every mempool ingress regardless of config. - transaction-pool eth.rs: adapt #394's `no_eip4844_rejects_blob_tx_*` test to the v2.3.0 two-arg `EthTransactionValidatorBuilder::new`. - e2e main.rs/blobs.rs: take #394's removal of the obsolete `can_handle_blobs` e2e test while keeping v2.3.0's `mod custom_genesis`.
Gravity rejects EIP-4844 blob txs at the pool validator (`.no_eip4844()`, #394), so injecting a blob into a full node now fails with "transaction type not supported". Remove the blob-injection + `getBlobsV1` section from `test_engine_ssz_proxy_can_mine_block`; the SSZ proxy's capabilities, identity, newPayload, forkchoice, and mine-block coverage is unchanged. Mirrors #394's removal of the now-inapplicable `can_handle_blobs` e2e test.
2 participants
What
Gravity does not support EIP-4844. The pipe-exec layer already drops every type-3
transaction before grevm (
tx_filter.rs), so a blob tx admitted into the mempoolcan never be executed — it only wastes bounded blob-subpool capacity and costs
KZG-sidecar verification on ingress.
This disables blob support at the pool validator via
.no_eip4844()inEthereumPoolBuilder.Why one flag covers every ingress
The type-3 reject in
EthTransactionValidator::validate_oneis origin-independent,so a single flag rejects blob txs at every mempool ingress:
eth_sendRawTransactionadd_transaction→ validatoradd_external_txn→add_external_transaction→ validatoradd_external_transactions→ validatorThe consensus
OrderedBlockexecution path is a separate surface already guardedby the pipe-exec
tx_filter(type-3 drop before grevm) — not touched here.Test
no_eip4844_rejects_blob_tx_on_every_originasserts a blob tx is rejected withEip4844Disabledon bothLocalandExternalorigins, and thatadd_external_transaction(the PFN receive path) rejects it and leaves nothing inthe pool.
Related
Addresses the transaction-pool blob ingress surface reported in
Galxe/gravity-audit#817 — this removes the reachable blob mempool vector on the
gravity side. The underlying upstream
add_transactionsender-info rollback (thegeneric root fix) is a separate, complementary change proposed against
paradigmxyz/reth.