Implement `txpool_contentFrom` for blobpool

[thedevbirb]

Rationale

Why should this feature exist? / Use-case

AFAIK (and I hope to be wrong), it's not possible to know which blob transactions you've sent from your account using only your local Geth node, without tracking the hashes somewhere else (e.g. disk) or using external services. I stumbled into this situation while working on a L2 sequencer that, upon restarts, will not know what was the first blob transaction it sent[^1], as such it cannot replace it in case it is not landing.

The txpool_contentFrom endpoint is not implemented for the blobpool yet. Having it implemented would solve this issue, since I could query this endpoint with my running account, pull the transaction data (blob sidecar isn't strictly needed for my purposes) and make a replacement transaction if needed by doubling its fees.

Disk-usage concerns

A discussion on the implementation of txpool_content and txpool_contentFrom has sparkled originally in https://github.com/ethereum/go-ethereum/pull/29087.

I completely understand the concern for the regular txpool_content, since it can pull 10GiB in the worst case (even if at the time of writing it is 2.5GiB by default, which is still too high). However, the blob pool accepts at most maxTxsPerAccount = 16 per address, where each blob transaction can have at most maxBlobsPerTx = 7 blobs.

That means for the txpool_contentFrom endpoint, that highest size that can be read from disk is around 16 * 7 * 128 * 1024 bytes which is ~14.7MiB. While this value isn't necessarily low, it is manageable for a bit more sophisticated RPCs. Moreover, a couple of flags can be introduced to either:

1. Configure maxTxsPerAccount to a desired value. Defaults to 16 like now, but resource-constrained nodes can turn it down to 8 or 4, further reducing the load on the RPC call on worst cases;
2. Enable the txpool_contentFrom to read the blob pool. Defaults to false but if someone wishes to enable it, it can do it knowing its consequences.

Implementation

Depending on the result of the discussion, I'm available to make a PR with the feature enabled for txpool_contentFrom only and introduce the desired flags, superseding https://github.com/ethereum/go-ethereum/pull/29087.

[^1]: I guess you could subscribe to new pending transactions and wait for the blob tx to be rebroadcasted, although not so reliable?

[samuelarogbonlo]

Jumping on this @thedevbirb

[MariusVanDerWijden]

Maybe an endpoint to write out the content of the blobpool in JSON to a file? This would make it possible to debug the txpool better. And then we could have a txpool_contentFrom that only returns the hashes of the transactions

[rose2221]

would like to work on this!

[thedevbirb]

Hey @MariusVanDerWijden sorry for the late reply.

Regarding txpool_contentFrom we could directly return the transaction without the blob sidecar, like Reth does! It's not a huge different in terms of data sent over the network.

Maybe an endpoint to write out the content of the blobpool in JSON to a file

This could work, but it should probably be available only via console/IPC like the admin namespace? Or is there another way to manage permissions on Geth RPC calls?

Thank you!

[mask-pp]

The returned blob txs don't include BlobTxSidecar content but still include blobVersionedHashes, and the geth client supports an API(getBlobTxSidecar(blobHash)). I think most users only care about specific blobs, and returning all blobs at once is really heavy, which is not advisable.