Crate lightning_rapid_gossip_sync
source · [−]Expand description
This crate exposes functionality to rapidly sync gossip data, aimed primarily at mobile devices.
The server sends a compressed response containing differential gossip data. The gossip data is formatted compactly, omitting signatures and opportunistically incremental where previous channel updates are known (a mechanism that is enabled when the timestamp of the last known channel update is communicated). A reference server implementation can be found here.
An example server request could look as simple as the following. Note that the first ever rapid
sync should use 0 for last_sync_timestamp:
curl -o rapid_sync.lngossip https://rapidsync.lightningdevkit.org/snapshot/<last_sync_timestamp>Then, call the network processing function. In this example, we process the update by reading
its contents from disk, which we do by calling the sync_network_graph_with_file_path method:
use bitcoin::blockdata::constants::genesis_block;
use bitcoin::Network;
use lightning::routing::gossip::NetworkGraph;
use lightning_rapid_gossip_sync::RapidGossipSync;
let block_hash = genesis_block(Network::Bitcoin).header.block_hash();
let network_graph = NetworkGraph::new(block_hash, &logger);
let rapid_sync = RapidGossipSync::new(&network_graph);
let new_last_sync_timestamp_result = rapid_sync.sync_network_graph_with_file_path("./rapid_sync.lngossip");The primary benefit this syncing mechanism provides is that given a trusted server, a low-powered client can offload the validation of gossip signatures. This enables a client to privately calculate routes for payments, and do so much faster and earlier than requiring a full peer-to-peer gossip sync to complete.
The reason the rapid sync server requires trust is that it could provide bogus data, though at worst, all that would result in is a fake network topology, which wouldn’t enable the server to steal or siphon off funds. It could, however, reduce the client’s privacy by forcing all payments to be routed via channels the server controls.
The way a server is meant to calculate this rapid gossip sync data is by using a latest_seen
timestamp provided by the client. It’s not included in either channel announcement or update,
(not least due to announcements not including any timestamps at all, but only a block height)
but rather, it’s a timestamp of when the server saw a particular message.
Modules
Error types that these functions can return
Core functionality of this crate
Structs
Rapid Gossip Sync struct See crate-level documentation for usage.