It's attackable.

The adversary can send nonce-gapped blob txs from multiple addresses, causing the out-of-memory panic.

At least we should place a cap for the total amount.

I've added the memory cap below

You can remove the lock in the add, and implement a wrapper addLocked with lock management.

Internally you can use the lock-free add to insert the gapped txs here.

good point, let me check it out

I have been thinking about what form the gapped blobpool should take in the evolution of the blobpool. In my view, we have two possible options. The first is to store a transaction in the gapped set only when "nonce too high" is the sole rejection reason. The second is to store a transaction in the gapped set when "nonce too high" is one of the rejection reasons (so there can other reasons) This PR seems to be implementing the second option, and given the current state of the blobpool, I think this is reasonable.

If cells are delivered separately from transactions in the future, first option can be beneficial in some cases, in terms of bandwidth. If a transaction in the buffer cannot be included even after the gap is resolved, then by the time the client discover it needs to be discarded (when all cells are collected and revalidation occurs through the add routine below), it will already have consumed bandwidth to fetch its cells. The first design would help reduce this overhead.

However, I am not certain this first option is necessary when we have this gapped buffer, since bandwidth can easily be wasted if someone submits gapped transactions that pass other validations and never fill the gap. I am also not sure about how often this can happen and why the submitter would do such thing.

https://github.com/ethereum/go-ethereum/compare/master...healthykim:go-ethereum:bs/cell-blobpool/sparse?expand=1

In my prototype, the buffer currently stores transactions that pass all validation checks but are simply missing their cells. Still need to do some debugging, but overall structure will remain like this
It also handles two replacement case, one for the replacement of buffered tx and the other for the replacement of pooled tx

I've selected option 2 (there can be other reasons) here, since that's the option that is a pure reorder buffer, acting before any real blobpool logic. So, at least in theory, that's the least invasive version.

However, I can imagine moving to a more complex evaluation before storing the gapped transaction. The queue in the legacypool does a more complex evaluation. I think we should check that as well before deciding on future evolution.