Skip to content
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

Merged
merged 1 commit into from
Jan 13, 2020

Conversation

karalabe
Copy link
Member

@karalabe karalabe commented Jan 13, 2020

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.

@karalabe karalabe added this to the 1.9.10 milestone Jan 13, 2020
}
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
Copy link
Contributor

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().

Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@karalabe karalabe merged commit e9e69d6 into ethereum:master Jan 13, 2020
@wanwiset25 wanwiset25 mentioned this pull request Jun 3, 2024
19 tasks
wanwiset25 pushed a commit to XinFinOrg/XDPoSChain that referenced this pull request Jun 19, 2024
wanwiset25 pushed a commit to XinFinOrg/XDPoSChain that referenced this pull request Jun 28, 2024
wanwiset25 added a commit to XinFinOrg/XDPoSChain that referenced this pull request Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants