X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=lightning-rapid-gossip-sync%2Fsrc%2Flib.rs;h=b347f69c1feea67f430359c4d0db89da716991a1;hb=3194d833b609e72b0b3cf0bcf988d37eadc75c74;hp=70758e1fe07e6a5ae0f5a430ac374ee3ae5708be;hpb=c242003dd3c430a8395af1e48bd1e5c1f5ed94ae;p=rust-lightning diff --git a/lightning-rapid-gossip-sync/src/lib.rs b/lightning-rapid-gossip-sync/src/lib.rs index 70758e1f..b347f69c 100644 --- a/lightning-rapid-gossip-sync/src/lib.rs +++ b/lightning-rapid-gossip-sync/src/lib.rs @@ -10,24 +10,35 @@ #![deny(unused_mut)] #![deny(unused_variables)] #![deny(unused_imports)] -//! This crate exposes functionality to rapidly sync gossip data, aimed primarily at mobile +//! This crate exposes client 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](https://github.com/lightningdevkit/rapid-gossip-sync-server). +//! 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](https://github.com/lightningdevkit/rapid-gossip-sync-server). //! -//! 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`: +//! 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 `latest_seen` timestamp, +//! i.e., the server will return all rapid gossip sync data it has seen after the given timestamp. +//! +//! # Getting Started +//! Firstly, the data needs to be retrieved from the server. For example, you could use the server +//! at with the following request format: //! //! ```shell //! curl -o rapid_sync.lngossip https://rapidsync.lightningdevkit.org/snapshot/ //! ``` +//! Note that the first ever rapid sync should use `0` for `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: +//! 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 [`RapidGossipSync::update_network_graph`]: //! //! ``` //! use bitcoin::blockdata::constants::genesis_block; @@ -45,33 +56,26 @@ //! 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"); +//! let snapshot_contents: &[u8] = &[0; 0]; +//! let new_last_sync_timestamp_result = rapid_sync.update_network_graph(snapshot_contents); //! ``` -//! -//! 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. + +#![cfg_attr(all(not(feature = "std"), not(test)), no_std)] // Allow and import test features for benching #![cfg_attr(all(test, feature = "_bench_unstable"), feature(test))] #[cfg(all(test, feature = "_bench_unstable"))] extern crate test; +#[cfg(not(feature = "std"))] +extern crate alloc; + +#[cfg(feature = "std")] use std::fs::File; -use std::ops::Deref; -use std::sync::atomic::{AtomicBool, Ordering}; +use core::ops::Deref; +use core::sync::atomic::{AtomicBool, Ordering}; +use lightning::io; use lightning::routing::gossip::NetworkGraph; use lightning::util::logger::Logger; @@ -81,9 +85,10 @@ use crate::error::GraphSyncError; pub mod error; /// Core functionality of this crate -pub mod processing; +mod processing; -/// Rapid Gossip Sync struct +/// The main Rapid Gossip Sync object. +/// /// See [crate-level documentation] for usage. /// /// [crate-level documentation]: crate @@ -94,7 +99,7 @@ where L::Target: Logger { } impl>, L: Deref> RapidGossipSync where L::Target: Logger { - /// Instantiate a new [`RapidGossipSync`] instance + /// Instantiate a new [`RapidGossipSync`] instance. pub fn new(network_graph: NG) -> Self { Self { network_graph, @@ -102,13 +107,14 @@ impl>, L: Deref> RapidGossipSync where L } } - /// Sync gossip data from a file + /// Sync gossip data from a file. /// Returns the last sync timestamp to be used the next time rapid sync data is queried. /// /// `network_graph`: The network graph to apply the updates to /// /// `sync_path`: Path to the file where the gossip update data is located /// + #[cfg(feature = "std")] pub fn sync_network_graph_with_file_path( &self, sync_path: &str, @@ -117,6 +123,17 @@ impl>, L: Deref> RapidGossipSync where L self.update_network_graph_from_byte_stream(&mut file) } + /// Update network graph from binary data. + /// Returns the last sync timestamp to be used the next time rapid sync data is queried. + /// + /// `network_graph`: network graph to be updated + /// + /// `update_data`: `&[u8]` binary stream that comprises the update data + pub fn update_network_graph(&self, update_data: &[u8]) -> Result { + let mut read_cursor = io::Cursor::new(update_data); + self.update_network_graph_from_byte_stream(&mut read_cursor) + } + /// Gets a reference to the underlying [`NetworkGraph`] which was provided in /// [`RapidGossipSync::new`]. /// @@ -125,12 +142,13 @@ impl>, L: Deref> RapidGossipSync where L &self.network_graph } - /// Returns whether a rapid gossip sync has completed at least once + /// Returns whether a rapid gossip sync has completed at least once. pub fn is_initial_sync_complete(&self) -> bool { self.is_initial_sync_complete.load(Ordering::Acquire) } } +#[cfg(feature = "std")] #[cfg(test)] mod tests { use std::fs;