You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we are rate limited or by the node we are requesting data from, the node will disconnect us by sending a GoodbyeMessage.
In that scenario we close all connections and we and up calling RpcHandler::onRemoteWriteClosed which will call Eth2OutgoingRequestHandler::readComplete.
So we will end up considering all inflight requests to the peer as completed and run onRequestComplete as nothing happened.
In that method we do an early validation of blocks and blobs. The first validation is a simple one and unlikely to fail even if we are dealing with incomplete block response. The blobSidecar validation (validateNewBlobSidecars) easely fails if we receive less blobs than expected. This could happen if the rate limit happens on the blobsByRange portion of the batch, while blocksByRange is not rate limited.
When this validation fails, we consider the peer as behaving badly and we apply a big penalty.
Possible solution
sendEth2Request could start giving more feedback instead of returning SafeFuture<Void> to be able to discriminate between an actual completed request and a request that has been interrupted along the way.
The text was updated successfully, but these errors were encountered:
Context
When we requests new blocks\blobs we run:
Down the line,
blocksRequest
andblobSidecarsRequest
call:Problem
When we are rate limited or by the node we are requesting data from, the node will disconnect us by sending a
GoodbyeMessage
.In that scenario we close all connections and we and up calling
RpcHandler::onRemoteWriteClosed
which will callEth2OutgoingRequestHandler::readComplete
.So we will end up considering all inflight requests to the peer as completed and run
onRequestComplete
as nothing happened.In that method we do an early validation of blocks and blobs. The first validation is a simple one and unlikely to fail even if we are dealing with incomplete block response. The blobSidecar validation (
validateNewBlobSidecars
) easely fails if we receive less blobs than expected. This could happen if the rate limit happens on the blobsByRange portion of the batch, while blocksByRange is not rate limited.When this validation fails, we consider the peer as behaving badly and we apply a big penalty.
Possible solution
sendEth2Request
could start giving more feedback instead of returningSafeFuture<Void>
to be able to discriminate between an actual completed request and a request that has been interrupted along the way.The text was updated successfully, but these errors were encountered: