Open Rjected opened 1 year ago
this is more of a pipeline issue
an invalid block by hash, we should not re-request
the headers stage does not know that
the question here is, why is the pipeline here active in the first place?
the question here is, why is the pipeline here active in the first place?
because the CL mocker sends a FCU, and this is the first FCU, so we are running the pipeline
ah sigh
oh, what if we always fetch the full block first before triggering pipeline, this way we can also check the distance
Makes sense, so #3039 should probably be followed up with distance checks, which should address #2964
This issue is stale because it has been open for 14 days with no activity.
Ping @Rjected @mattsse on this
This issue is stale because it has been open for 14 days with no activity.
Going to ignore the Headers
stage case for now, since these hive tests now use the live sync downloaders. Now, the problem is that the full block downloaders just report a bad message here, ban the peer, and continue to request the header. Invalid headers are not propagated up to the engine.
https://github.com/paradigmxyz/reth/blob/4dbd8835e5f06ddfc5c0987046773d592dbff860/crates/interfaces/src/p2p/full_block.rs#L494-L495
To solve this, we could have the full block downloader (and range downloader) return either a regular SealedBlock
, or another variant for invalid headers or blocks. To allow the beacon engine to mark it as invalid, we would have to propagate this result up to here:
https://github.com/paradigmxyz/reth/blob/4dbd8835e5f06ddfc5c0987046773d592dbff860/crates/consensus/beacon/src/engine/mod.rs#L1576-L1578
Here, the engine can mark it as invalid
This is still an issue, we could initialize the future with a channel that the full block future pushes to if it has capacity, otherwise it should not block on insert - would be DoS risk.
But before this, we need to alter the validate_headers_range
method:
https://github.com/paradigmxyz/reth/blob/96149f05bedf52ef1a3b00c50e827e9d2992ecb3/crates/interfaces/src/consensus.rs#L39
to return the header that is invalid on error.
Describe the bug
In the test
Invalid Ancestor Chain Sync, Invalid Timestamp
(and others), the test stalls because we always returnSYNCING
and fail:This is because reth penalizes the test peer for serving invalid headers:
Because we are fetching the header by number, we have no way of verifying that the peer is serving a header which is part of the canonical chain, and need to re-request the header, in case the peer is malicious and providing bogus header data.
If we were fetching the header by hash, we would know that the peer is serving the requested header when we validate its hash. If we were to request an invalid block by hash, we should not re-request that header, because we will always get an invalid result.
We may want to differentiate between headers that we fetch by hash, and headers that we fetch by number, for this reason. Then, we can:
Similarly, for the full block downloader, we should request by hash so we can invalidate the bad block.
Steps to reproduce
Run the
Invalid Ancestor Chain Sync, Invalid Timestamp
test:Node logs
No response
Platform(s)
No response
What version/commit are you on?
No response
Code of Conduct