Skip to content

cuprated: event-driven block synchronization#584

Open
redsh4de wants to merge 6 commits intoCuprate:mainfrom
redsh4de:feat/better-sync
Open

cuprated: event-driven block synchronization#584
redsh4de wants to merge 6 commits intoCuprate:mainfrom
redsh4de:feat/better-sync

Conversation

@redsh4de
Copy link
Contributor

@redsh4de redsh4de commented Feb 15, 2026

What

Make blockchain synchronization event-driven instead of polling every 30s. This makes new sync initiation near-instant as it respond to relevant events. Closes #532.

Why

The syncer previously polled every 30 seconds to check if we are behind our peers. This meant up to a 30-second delay before reacting to network's cumulative difficulty changes. Also unnecessary work when nothing had changed

Where

  • p2p/p2p-core/src/client.rs - new PeerSyncCallback struct
  • p2p/p2p-core/src/client/handshaker.rs, builder.rs, request_handler.rs, timeout_monitor.rs - plumbing
  • p2p/p2p/src/lib.rs, inbound_server.rs, connection_maintainer.rs - notify syncer on 0 peer -> 1+ peer transitions
  • consensus/context/src/lib.rs - add a read function for our cumulative difficulty for use in the callback
  • binaries/cuprated/src/main.rs, p2p.rs, p2p/request_handler.rs, blockchain/manager.rs, blockchain/syncer.rs - wire everything together, add loop label for clarity for breaks

How

Replace the 30-second polling interval with a PeerSyncCallback struct that wraps a tokio::sync::Notify with three waking paths:

  • Filtered wake (call): When a peer reports new sync data, wake the syncer only if the peer's cumulative difficulty exceeds ours.
  • Unconditional wake (wake_unconditionally): When we receive an orphan block, wake the syncer immediately.
  • First-peers wake (wake_on_first_peers): When transitioning from 0 to 1+ connected peers, wake the syncer immediately. Uses a guard that the syncer re-arms (wake_on_first_peers_arm) each time it enters the NoPeers state, so the mechanism works across repeated complete disconnect -> connect cycles.

The syncer checks sync status, then either awaits a notification (Synced/NoPeers) or starts the inner block downloader loop (BehindPeers).

After the downloader loop ends, the outer syncer loop re-checks status again before parking. The synced_notify for the Tor P2P zone start is now fired only once on initial sync completion rather than repeatedly.

@github-actions github-actions bot added A-p2p Area: Related to P2P. A-consensus Area: Related to consensus. A-binaries Area: Related to binaries. labels Feb 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-binaries Area: Related to binaries. A-consensus Area: Related to consensus. A-p2p Area: Related to P2P.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improve syncer startup

1 participant