Valid peers dropped due to blob tx validation failure from another peer

[leonbiton1]

System information

Geth version: 1.13.14-stable-c18a9e54
CL client: prysm
OS & Version: Amazon Linux 2

Expected behaviour

When multiple peers send transaction announcements (for a blob transaction with a sidecar), and then another peer later sends the full transaction but without the sidecar, leading to validation failure, only the peer that sent the invalid full transaction should be dropped.

Actual behaviour

Instead of only dropping the peer who sent the invalid full transaction, all peers who previously announced the transaction (with the correct size) are also dropped due to Announced transaction size mismatch.

Code Analysis

• In tx_fetcher.go, when an announcement arrives, it is stored in:

  • f.waitslots
  • f.announced
  • f.waitlist

• When the full transaction arrives via Enqueue(), it iterates over f.addTxs(), where it fails validation (missing sidecar in blob transaction).

• However, despite the validation failure, the full transaction still proceeds to f.cleanup.

• In cleanup, the size check is applied to all peers who previously announced the transaction, leading to their disconnection, even though they never sent the invalid full transaction.

Backtrace

TRACE[02-10|15:41:45.617] Transaction validation failed            hash=b0e4bf..d948a1 err="missing sidecar in blob transaction"
WARN [02-10|15:41:45.617] Announced transaction size mismatch      peer=fe907eef61226eb98ffc181c2bb95b39881301efee838e8d4b4caf85ab7b1088 tx=b0e4bf..d948a1 size=221  ann=393,755
WARN [02-10|15:41:45.617] Announced transaction size mismatch      peer=3864397c93fd2efded8163377cc6d83090613df9443c70c93c1b6c70b302023f tx=b0e4bf..d948a1 size=221  ann=393,755
WARN [02-10|15:41:45.617] Announced transaction size mismatch      peer=2db63adf0aee55da89afd2004acf1e0324a90abed53084b87cc3da29bc84927b tx=b0e4bf..d948a1 size=221  ann=393,755
WARN [02-10|15:41:45.617] Announced transaction size mismatch      peer=9c111c7cd78469794e36786c3a5edaf3f1e0e4c008b55166ffdf086c5a18352b tx=b0e4bf..d948a1 size=221  ann=393,755
WARN [02-10|15:41:45.617] Announced transaction size mismatch      peer=b2825db6dbdb29807bfb405dad3fe887f1a60a0889ebfec0c575df3b9de08d31 tx=b0e4bf..d948a1 size=221  ann=393,755

[jwasinger]

On one hand, an error like this makes sense to be caught at the decoding of PooledTransactions, which would result in the peer being disconnected from the eth protocol layer. But I'm not sure what implementing a separate transaction type for "live" blob transactions entails.

An alternative solution would be to surface the error from the blob pool and use this as a signal in the fetcher to disconnect the offending peer. This has the downside of leaking some abstraction from the blob subpool.

The case of failure due to a missing/malformed sidecar seems like a weird case for the fetcher: the represented transaction could be valid, but has missing/incorrect auxiliary data. And yet we forward this through cleanup and remove the tx hash from the trackers.