-
Notifications
You must be signed in to change notification settings - Fork 20.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eth: check propagated block malformation on receiption #20546
Conversation
} | ||
if hash := types.DeriveSha(request.Block.Transactions()); hash != request.Block.TxHash() { | ||
log.Warn("Propagated block has invalid body", "have", hash, "exp", request.Block.TxHash()) | ||
break // TODO(karalabe): return error eventually, but wait a few releases |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, once we do add that, it might make sense to put this check into request.sanityCheck()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Speaking of which, shouldn't you do this check after the sanity check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't really matter imho. Sanity check just checks that the numbers aren't enormous. Those shouldn't impact the uncle/tx hash in any way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…eum#20546)" This reverts commit 1204fa9.
Malformed blocks are detected and rejected by the chain inserter. If however a malformed block is broadcast to us, we only do PoW checks and quickly forward it to keep latency down. This is unfortunate, because PoW does not protect against a bad body, so every new valid PoW is an opportunity to propagate a (one!) malformed block through the network.
This PR fixes it by moving a malformation detection into block receiption (propagation is the only place where an entire block is transmitted in assembled form, the rest of the protocol already uses split headers/bodies). Long term if we rework block propagation to be smarter, even this one instance can be dropped.
The PR currently just silently discards these blocks, but long term we want to drop the offending peer altogether for protocol violation. The reason we don't do this now is not to nuke the network apart if someone attempts this malformed propagation again.