Skip to content

Commit 9b289c0

Browse files
committed
Refactor gossip_queries sync to be stateless
This commit simplifies the sync process for routing gossip messages. When a sync is initiated, the process is handled statelessly by immediately issuing SCID queries as channel range replies are received. This greatly simplifies the state machine at the cost of fully validating and conforming to the current spec.
1 parent a9c88c6 commit 9b289c0

File tree

4 files changed

+70
-995
lines changed

4 files changed

+70
-995
lines changed

lightning-net-tokio/src/lib.rs

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -536,8 +536,7 @@ mod tests {
536536
fn get_next_channel_announcements(&self, _starting_point: u64, _batch_amount: u8) -> Vec<(ChannelAnnouncement, Option<ChannelUpdate>, Option<ChannelUpdate>)> { Vec::new() }
537537
fn get_next_node_announcements(&self, _starting_point: Option<&PublicKey>, _batch_amount: u8) -> Vec<NodeAnnouncement> { Vec::new() }
538538
fn should_request_full_sync(&self, _node_id: &PublicKey) -> bool { false }
539-
fn query_channel_range(&self, _their_node_id: &PublicKey, _chain_hash: bitcoin::BlockHash, _first_blocknum: u32, _block_range: u32) -> Result<(), LightningError> { Ok(()) }
540-
fn query_short_channel_ids(&self, _their_node_id: &PublicKey, _chain_hash: bitcoin::BlockHash, _short_channel_ids: Vec<u64>) -> Result<(), LightningError> { Ok(()) }
539+
fn sync_routing_table(&self, _their_node_id: &PublicKey) { }
541540
fn handle_reply_channel_range(&self, _their_node_id: &PublicKey, _msg: &ReplyChannelRange) -> Result<(), LightningError> { Ok(()) }
542541
fn handle_reply_short_channel_ids_end(&self, _their_node_id: &PublicKey, _msg: &ReplyShortChannelIdsEnd) -> Result<(), LightningError> { Ok(()) }
543542
fn handle_query_channel_range(&self, _their_node_id: &PublicKey, _msg: &QueryChannelRange) -> Result<(), LightningError> { Ok(()) }

lightning/src/ln/msgs.rs

Lines changed: 4 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -824,12 +824,10 @@ pub trait RoutingMessageHandler : Send + Sync + events::MessageSendEventsProvide
824824
fn get_next_node_announcements(&self, starting_point: Option<&PublicKey>, batch_amount: u8) -> Vec<NodeAnnouncement>;
825825
/// Returns whether a full sync should be requested from a peer.
826826
fn should_request_full_sync(&self, node_id: &PublicKey) -> bool;
827-
/// Queries a peer for a list of channels with a funding UTXO in the requested
828-
/// chain and range of blocks.
829-
fn query_channel_range(&self, their_node_id: &PublicKey, chain_hash: BlockHash, first_blocknum: u32, number_of_blocks: u32) -> Result<(), LightningError>;
830-
/// Queries a peer for routing gossip messages for a set of channels identified
831-
/// by their short_channel_ids.
832-
fn query_short_channel_ids(&self, their_node_id: &PublicKey, chain_hash: BlockHash, short_channel_ids: Vec<u64>) -> Result<(), LightningError>;
827+
/// Initiates routing gossip sync by querying a peer to discover channels
828+
/// and their associated routing gossip messages. This method will use a
829+
/// sync strategy defined by the implementor.
830+
fn sync_routing_table(&self, their_node_id: &PublicKey);
833831
/// Handles the reply of a query we initiated to learn about channels
834832
/// for a given range of blocks. We can expect to receive one or more
835833
/// replies to a single query.

0 commit comments

Comments
 (0)