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

Implement bifurcation for syncTarget estimation / verification #217

Open
cristaloleg opened this issue Sep 9, 2024 · 1 comment · May be fixed by #219
Open

Implement bifurcation for syncTarget estimation / verification #217

cristaloleg opened this issue Sep 9, 2024 · 1 comment · May be fixed by #219
Assignees

Comments

@cristaloleg
Copy link
Contributor

TODO

@cristaloleg cristaloleg self-assigned this Sep 9, 2024
@renaynay
Copy link
Member

Reasoning

As we are removing the adequateHeight sanity check for the sync target since it is based on a parameter that may become variable in the future, we should introduce additional light-weight sync target verification. This comes in the form of skipping verification.

Description

Skipping verification will allow go-header to verify a recent network head (either inbound from headersub or served by the p2p.Exchange) against a subjective head that is non-adjacent. We already have non-adjacent header verification but skipping verification via bifurcated header sync.

Bifurcated header sync just means that if a sync target cannot be verified non-adjacently against a subjective head due to lack of sufficient validator set overlap, then the halfway point between those two headers should be downloaded and attempted.

For example:
Subjective head is 500, network head is 1000. Header at height 1000 does not have sufficient validator set overlap, so the client downloads height 750 (which does have enough sufficient overlap), verifies it against 500 and advances the subjective head to 750. Client tries to apply height 1000 against 750 and if there is sufficient overlap, it applies 1000 as the subjective head. If not, it downloads the halfway point and retries the process.

Please keep in mind, for the first iteration, it is okay not to cache the downloaded blocks if they cannot be applied -- we can redownload them via the p2p.Exchange once the sync target is set as it will be initially complicated for the syncer to use that cache to fill out gaps in sync ranges.

For later iterations, a cache for this bifurcation process would reduce the need to do redundant requests for the same information from the network.

References

https://github.com/celestiaorg/celestia-core/blob/v0.34.x-celestia/light/client.go#L777

@cristaloleg cristaloleg linked a pull request Sep 24, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants