1010#![ deny( unused_mut) ]
1111#![ deny( unused_variables) ]
1212#![ deny( unused_imports) ]
13- //! This crate exposes functionality to rapidly sync gossip data, aimed primarily at mobile
13+ //! This crate exposes client functionality to rapidly sync gossip data, aimed primarily at mobile
1414//! devices.
1515//!
16- //! The server sends a compressed response containing differential gossip data. The gossip data is
17- //! formatted compactly, omitting signatures and opportunistically incremental where previous
18- //! channel updates are known (a mechanism that is enabled when the timestamp of the last known
19- //! channel update is communicated) . A reference server implementation can be found
20- //! [here ](https://github.com/lightningdevkit/rapid-gossip-sync-server).
16+ //! The rapid gossip sync server will provide a compressed response containing differential gossip
17+ //! data. The gossip data is formatted compactly, omitting signatures and opportunistically
18+ //! incremental where previous channel updates are known. This mechanism is enabled when the
19+ //! timestamp of the last known channel update is communicated. A reference server implementation
20+ //! can be found [on Github ](https://github.com/lightningdevkit/rapid-gossip-sync-server).
2121//!
22- //! An example server request could look as simple as the following. Note that the first ever rapid
23- //! sync should use `0` for `last_sync_timestamp`:
22+ //! The primary benefit of this syncing mechanism is that it allows a low-powered client to offload
23+ //! the validation of gossip signatures to a semi-trusted server. This enables the client to
24+ //! privately calculate routes for payments, and to do so much faster than requiring a full
25+ //! peer-to-peer gossip sync to complete.
26+ //!
27+ //! The server calculates its response on the basis of a client-provided `latest_seen` timestamp,
28+ //! i.e., the server will return all rapid gossip sync data it has seen after the given timestamp.
29+ //!
30+ //! # Getting Started
31+ //! Firstly, the data needs to be retrieved from the server. For example, you could use the server
32+ //! at <https://rapidsync.lightningdevkit.org> with the following request format:
2433//!
2534//! ```shell
2635//! curl -o rapid_sync.lngossip https://rapidsync.lightningdevkit.org/snapshot/<last_sync_timestamp>
2736//! ```
37+ //! Note that the first ever rapid sync should use `0` for `last_sync_timestamp`.
2838//!
29- //! Then, call the network processing function. In this example, we process the update by reading
30- //! its contents from disk, which we do by calling the `sync_network_graph_with_file_path` method:
39+ //! After the gossip data snapshot has been downloaded, one of the client's graph processing
40+ //! functions needs to be called. In this example, we process the update by reading its contents
41+ //! from disk, which we do by calling [sync_network_graph_with_file_path]:
3142//!
3243//! ```
3344//! use bitcoin::blockdata::constants::genesis_block;
4758//! let rapid_sync = RapidGossipSync::new(&network_graph);
4859//! let new_last_sync_timestamp_result = rapid_sync.sync_network_graph_with_file_path("./rapid_sync.lngossip");
4960//! ```
50- //!
51- //! The primary benefit this syncing mechanism provides is that given a trusted server, a
52- //! low-powered client can offload the validation of gossip signatures. This enables a client to
53- //! privately calculate routes for payments, and do so much faster and earlier than requiring a full
54- //! peer-to-peer gossip sync to complete.
55- //!
56- //! The reason the rapid sync server requires trust is that it could provide bogus data, though at
57- //! worst, all that would result in is a fake network topology, which wouldn't enable the server to
58- //! steal or siphon off funds. It could, however, reduce the client's privacy by forcing all
59- //! payments to be routed via channels the server controls.
60- //!
61- //! The way a server is meant to calculate this rapid gossip sync data is by using a `latest_seen`
62- //! timestamp provided by the client. It's not included in either channel announcement or update,
63- //! (not least due to announcements not including any timestamps at all, but only a block height)
64- //! but rather, it's a timestamp of when the server saw a particular message.
61+ //! [sync_network_graph_with_file_path]: RapidGossipSync::sync_network_graph_with_file_path
6562
6663// Allow and import test features for benching
6764#![ cfg_attr( all( test, feature = "_bench_unstable" ) , feature( test) ) ]
6865#[ cfg( all( test, feature = "_bench_unstable" ) ) ]
6966extern crate test;
7067
68+ #[ cfg( feature = "std" ) ]
7169use std:: fs:: File ;
72- use std :: ops:: Deref ;
73- use std :: sync:: atomic:: { AtomicBool , Ordering } ;
70+ use core :: ops:: Deref ;
71+ use core :: sync:: atomic:: { AtomicBool , Ordering } ;
7472
73+ use lightning:: io;
7574use lightning:: routing:: gossip:: NetworkGraph ;
7675use lightning:: util:: logger:: Logger ;
7776
@@ -83,7 +82,8 @@ pub mod error;
8382/// Core functionality of this crate
8483pub mod processing;
8584
86- /// Rapid Gossip Sync struct
85+ /// The main Rapid Gossip Sync object.
86+ ///
8787/// See [crate-level documentation] for usage.
8888///
8989/// [crate-level documentation]: crate
@@ -94,21 +94,22 @@ where L::Target: Logger {
9494}
9595
9696impl < NG : Deref < Target =NetworkGraph < L > > , L : Deref > RapidGossipSync < NG , L > where L :: Target : Logger {
97- /// Instantiate a new [`RapidGossipSync`] instance
97+ /// Instantiate a new [`RapidGossipSync`] instance.
9898 pub fn new ( network_graph : NG ) -> Self {
9999 Self {
100100 network_graph,
101101 is_initial_sync_complete : AtomicBool :: new ( false )
102102 }
103103 }
104104
105- /// Sync gossip data from a file
105+ /// Sync gossip data from a file.
106106 /// Returns the last sync timestamp to be used the next time rapid sync data is queried.
107107 ///
108108 /// `network_graph`: The network graph to apply the updates to
109109 ///
110110 /// `sync_path`: Path to the file where the gossip update data is located
111111 ///
112+ #[ cfg( feature = "std" ) ]
112113 pub fn sync_network_graph_with_file_path (
113114 & self ,
114115 sync_path : & str ,
@@ -117,6 +118,17 @@ impl<NG: Deref<Target=NetworkGraph<L>>, L: Deref> RapidGossipSync<NG, L> where L
117118 self . update_network_graph_from_byte_stream ( & mut file)
118119 }
119120
121+ /// Update network graph from binary data.
122+ /// Returns the last sync timestamp to be used the next time rapid sync data is queried.
123+ ///
124+ /// `network_graph`: network graph to be updated
125+ ///
126+ /// `update_data`: `&[u8]` binary stream that comprises the update data
127+ pub fn update_network_graph ( & self , update_data : & [ u8 ] ) -> Result < u32 , GraphSyncError > {
128+ let mut read_cursor = io:: Cursor :: new ( update_data) ;
129+ self . update_network_graph_from_byte_stream ( & mut read_cursor)
130+ }
131+
120132 /// Gets a reference to the underlying [`NetworkGraph`] which was provided in
121133 /// [`RapidGossipSync::new`].
122134 ///
@@ -125,7 +137,7 @@ impl<NG: Deref<Target=NetworkGraph<L>>, L: Deref> RapidGossipSync<NG, L> where L
125137 & self . network_graph
126138 }
127139
128- /// Returns whether a rapid gossip sync has completed at least once
140+ /// Returns whether a rapid gossip sync has completed at least once.
129141 pub fn is_initial_sync_complete ( & self ) -> bool {
130142 self . is_initial_sync_complete . load ( Ordering :: Acquire )
131143 }
0 commit comments