mimblewimble/grin

Initial header sync (request headers from fast peers or avoid slow peers)

Open

#3082 opened on Oct 4, 2019

View on GitHub
 (4 comments) (0 reactions) (0 assignees)Rust (4,876 stars) (991 forks)batch import
enhancementhelp wanted

Description

The initial sync feels slow. We request headers in chunks of 512 from random connected peer. Sometimes we hit a slow peer and the latency introduced in even a few requests from a slow peer makes the header sync feel slow.

It might be nice to track peer speeds and make a better decision in terms of prioritizing faster peers as we proceed with the header sync.

We already track download rates at some level of granularity (not entirely sure what we do today) as we display this on the TUI - so we may already collect enough information to make this decision around which peers are best to request headers from.

Contributor guide

Tech stack
rust
Domain
backendperformance
Issue type
performance
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
Rust basicsUnderstanding of P2P networking
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Investigate how the peer download rates are currently tracked in the codebase, likely in the sync module or TUI display code. Look for existing rate tracking structures and how headers are requested. Then design a strategy to prioritize faster peers, potentially using a scoring or sorting mechanism. Review comments in the issue for any additional context or suggestions.