-
Notifications
You must be signed in to change notification settings - Fork 20.7k
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
core, eth/downloader: implement pruning mode sync #31414
Open
rjl493456442
wants to merge
5
commits into
ethereum:master
Choose a base branch
from
rjl493456442:prunemode-sync-2
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+580
−539
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
916eaf0
to
d3b8b71
Compare
386d78f
to
5dd27fd
Compare
Snap sync with
|
Snap sync with
|
f954c7f
to
6327d1e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces new sync logic for pruning mode.
Pruning Mode:
Geth now supports two chain history modes (
-history.chain
):all
andpostmerge
.all
(default): Retains the entire historical chain as usual.postmerge
: Discards chain segments before the configured cutoff point and skips them during synchronization.The cutoff point is defined as the first block after the Paris fork and will be dynamically
adjusted in the future.
Sync mechanism with chain cutoff
A consensus has been reached across different EL implementations that chain
segments before the merge point will be pruned by default in the near future.
This means these segments—specifically block bodies and receipts—will no longer
be available in the P2P network. As a result, these components must be skipped
during retrieval in pruning mode.
Internally, Geth uses a freezer to maintain historical chain segments, which must
be inserted sequentially. This raises the question of how to handle the gap between
the genesis block and the first block after the cutoff in the freezer.
Two options were considered:
(a) Introducing a new freezer API to set the freezer tail to an arbitrary block number.
(b) Replacing chain data before the cutoff with null data.
The latter option is simpler and functionally equivalent to the former. When retrieving
data for chain segments before the cutoff, null values will be returned, indicating that
these items do not exist locally. Additionally it's a more robust approach that all chain
segment inserted into the freezer always in an atomic manner. Lots of complexities are
needed in approach (a) if this property is required. For example, we must guarantee
the header x write and body table tail shifting to x happen atomically.
Therefore, the approach (b) is chosen for the sake of simplicity.
Additionally, this pull request introduces some important changes worth highlighting.
Originally, in snap sync, the header chain and other components (bodies and receipts)
were inserted separately. However, in Proof-of-Stake, this separation is unnecessary
since the sync target is already verified by the CL.
To simplify the process, this pull request modifies
InsertReceiptChain
to insert headersalong with block bodies and receipts together. Besides,
InsertReceiptChain
doesn'thave the notion of reorg, as the common ancestor is always be found before the sync
and extra side chain is truncated at the beginning if they fall in the ancient store.
The stale canonical chain flags will always be rewritten by the new chain. No explicit
reorg logic required in the
InsertReceiptChain
.