This crate exposes client functionality to rapidly sync gossip data, aimed primarily at mobile devices.
The rapid gossip sync server will provide a compressed response containing differential gossip data. The gossip data is formatted compactly, omitting signatures and opportunistically incremental where previous channel updates are known. This mechanism is enabled when the timestamp of the last known channel update is communicated. A reference server implementation can be found on Github.
The primary benefit of this syncing mechanism is that it allows a low-powered client to offload the validation of gossip signatures to a semi-trusted server. This enables the client to privately calculate routes for payments, and to do so much faster than requiring a full peer-to-peer gossip sync to complete.
The server calculates its response on the basis of a client-provided
i.e., the server will return all rapid gossip sync data it has seen after the given timestamp.
Firstly, the data needs to be retrieved from the server. For example, you could use the server at https://rapidsync.lightningdevkit.org with the following request format:
curl -o rapid_sync.lngossip https://rapidsync.lightningdevkit.org/snapshot/<last_sync_timestamp>
Note that the first ever rapid sync should use
After the gossip data snapshot has been downloaded, one of the client’s graph processing
functions needs to be called. In this example, we process the update by reading its contents
from disk, which we do by calling
use bitcoin::blockdata::constants::genesis_block; use bitcoin::Network; use lightning::routing::gossip::NetworkGraph; use lightning_rapid_gossip_sync::RapidGossipSync; let network_graph = NetworkGraph::new(Network::Bitcoin, &logger); let rapid_sync = RapidGossipSync::new(&network_graph, &logger); let snapshot_contents: &[u8] = &[0; 0]; let new_last_sync_timestamp_result = rapid_sync.update_network_graph(snapshot_contents);
- The main Rapid Gossip Sync object.
- All-encompassing standard error type that processing can return