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/protocols/snap: fix snap sync failure on empty storage range #623

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

andicrypt
Copy link
Contributor

@andicrypt andicrypt commented Oct 31, 2024

commit ethereum/go-ethereum@1cb3b6a
commit ethereum/go-ethereum@1cb3b6a

In the first PR, we ensure that if accumulated storage response exceeds hard limit cap (and being cutdown in size), the proof will not be attached, ensuring that the prover will not mislead more entries to requested. Additionally, we re-handle the normal scenario when the particular range requested does not contain any storage slots.

rjl493456442 and others added 2 commits November 1, 2024 17:02
* eth/protocols/snap: don't include empty snapshot slot slice

This PR fixes the snapshot storage serving handler. In snap protocol
the response is capped by the response size. Server can cutdown the
response if the accumulated byte size exceeds the local hard limit.

It means we can meet a special scenario that there is no storage slot
included for a requested account, but we attach the proof for this
account by mistake.

So in the prover side, when it meets a empty storage response but with
a valid proof proves there are some more slots left in the trie, then
requestor will reject this response and disconnect with server.

In this PR, if there is no storage slot served for the requested account,
then no proof should be attached as well.

* eth/protocols/snap: loosen restrictions for flaky tests

* eth/catalyst: fix flaky test in catalyst
commit ethereum/go-ethereum@1cb3b6a

In PR
ethereum/go-ethereum@39fb82b,
we ensure that if accumulated storage response exceeds hard limit cap
(and being cutdown in size), the proof will not be attached, ensuring
that the prover will not mislead more entries to requested. However, we
now mishandle the normal scenario when the particular range requested
does not contain any slots. This PR aims to fix this.
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