search

NethermindEth / nethermind

A robust execution client for Ethereum node operators.
https://nethermind.io/nethermind-client
GNU General Public License v3.0
1.24k stars 430 forks source link

Add throttling to networking of blob transactions #6284

Open marcindsobczak opened 10 months ago

marcindsobczak commented 10 months ago

Is your feature request related to a problem? Please describe. We need some kind of throttling when sending/receiving blob txs

How networking of blob txs works? Blob txs are never gossiped as full txs to other peers. Blob txs are announced in form of NewPooledTransactionHashesMessage - in message with hashes, types and sizes.

1st scenario: We are sending NewPooledTransactionHashesMessage when we receive new blob tx Peer can response with GetPooledTransactionsMessage - hashes of requested transactions We are then responding with PooledTransactionsMessage - message with full transactions It is handled here: https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Network/P2P/Subprotocols/Eth/V66/Eth66ProtocolHandler.cs#L161-L167

At this point we need some limitation for amount of data which we are sending, to not affect health of the node. Maybe reduce/throttle announces when there is too much data flowing? Maybe not, and just create a queue with GetPooledTransactionsMessages waiting for response?

2nd scenario: We are receiving NewPooledTransactionHashesMessage. It is handled here https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Network/P2P/Subprotocols/Eth/V68/Eth68ProtocolHandler.cs#L76-L102 With actual requests send here: https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Network/P2P/Subprotocols/Eth/PooledTxsRequestor.cs#L75-L109

Then we are receiving PooledTransactionsMessage with full txs.

We need some limitation here as well. Maybe it would be enough to change flag CanReceiveTransactions when we need to throttle a bit? Flag is used in both places, when receiving hashes: https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Network/P2P/Subprotocols/Eth/V68/Eth68ProtocolHandler.cs#L56 and when receiving full txs: https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Network/P2P/Subprotocols/Eth/V66/Eth66ProtocolHandler.cs#L102

If flag will be changed to not accept hashes/txs, maybe it's worth to save hashes to request it later? But it's optional, most important part is to not let the node die when spammed hard

emlautarom1 commented 10 months ago

Maybe it would be enough to change flag CanReceiveTransactions when we need to throttle a bit?

That seems to be the case. What heuristic should we use to decide when to "throttle" (actually drop) messages? Should we limit the number of msgs/second?

marcindsobczak commented 10 months ago

I think any heuristic would be better than nothing - number of messages/second would be fine, but I think the best would be to limit by amount of data - so sumOfMsgSizes/second We are already counting size in both eth68 and eth66 handlers (https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Network/P2P/Subprotocols/Eth/V68/Eth68ProtocolHandler.cs#L52), we can use this value