eth: check blob transaction validity on the peer goroutine when received

[jwasinger]

This ensures that if we receive a blob transaction where we cannot link the tx header to the sidecar commitments, we will drop the sending peer. This check is added in the protocol handler for the PooledTransactions message.

closes #31162

[jwasinger]

I'm working on test coverage for this in the form of tests in the devp2p eth test suite.

[jwasinger]

Tests passing when run individually. However, running them both (or the entire eth suite) causes them both to fail...

[jwasinger]

Tests pass when I omit LargeTxRequest from the suite. Otherwise, it causes the newly-introduced tests to fail. It's unclear what the interaction is that could cause this.

[jwasinger]

So I think I've cracked the core of the failure, and it reveals a rather interesting error:

If we connect to a peer, the peer announces/transmits a bad blob tx, causing the client eth handler to return an error and disconnect the peer, the disconnect will not happen while the client is waiting waiting for the peer to read the client's already-pooled txs that it is trying to announce.

At least, it seems this is the case. I'm trying to figure out why.

[jwasinger]

tbh, I'm actually not sure this is a comprehensive solution: the blobs/proofs could still be modified by a malicious tx-interceptor s.t. the checks introduced here pass, but the tx is ultimately failed to be added to the pool and the tx hash will not be considered for future re-request and inclusion...

I kind of wonder if there is any way at all to differentiate between sidecar-tampering-via-mitm and definitively invalid blob tx hash, given that the sender never signs over the full data... Perhaps the correct solution is: if validation of the sidecar commitment integrity wrt tx_header.blob_versioned_hashes or sidecar proof validation fails, don't remove the hash from trackers

I would be inclined to proceed with merging this, or at least merge the component of this that checks blob_tx.sidecar != nil in the handler, as that solves the related issue. But I want to ask someone with more knowledge on the cryptography side if my assumptions in the previous paragraph are correct.

[jwasinger]

Although... this PR involves changes to the public blob tx interface. So, perhaps makes sense to get verification of my assumption from someone else before proceeding:

If a blob tx header is validly-formed (number of commitment hashes in blob_versioned_hashes is in the range of the blob count that the chain is willing to accept at the time), we cannot definitively say that the given tx header cannot correspond to a correct blob transaction regardless of what we receive in the sidecar, as the sidecar contents are not signed over (only the hashes of the commitments).