Skip to content

Latest commit

 

History

History
62 lines (54 loc) · 3.66 KB

ARCH.md

File metadata and controls

62 lines (54 loc) · 3.66 KB
Raw

Rust-Lightning is broken into a number of high-level structures with APIs to hook them together, as well as APIs for you, the user, to provide external data.

The two most important structures which nearly every application of Rust-Lightning will need to use are ChannelManager and ChannelMonitor. ChannelManager holds multiple channels, routes payments between them, and exposes a simple API to make and receive payments. Individual ChannelMonitors monitor the on-chain state of a channel, punish counterparties if they misbehave, and force-close channels if they contain unresolved HTLCs which are near expiration. The ManyChannelMonitor API provides a way for you to receive ChannelMonitorUpdates from ChannelManager and persist them to disk before the channel steps forward.

There are two additional important structures that you may use either on the same device as the ChannelManager or on a separate one. NetGraphMsgHandler handles receiving channel and node announcements, which are then used to calculate routes by get_route for sending payments. PeerManager handles the authenticated and encrypted communication protocol, monitoring for liveness of peers, routing messages to ChannelManager and NetGraphMsgHandler instances directly, and receiving messages from them via the EventsProvider interface.

These structs communicate with each other using a public API, so that you can easily add a proxy in between for special handling. Further, APIs for key generation, transaction broadcasting, block fetching, and fee estimation must be implemented and the data provided by you, the user.

The library does not rely on the presence of a runtime environment outside of access to heap, atomic integers, and basic Mutex primitives. This means the library will never spawn threads or take any action whatsoever except when you call into it. Thus, ChannelManager and PeerManager have public functions which you should call on a timer, network reads and writes are external and provided by you, and the library relies only on block time for current time knowledge.

At a high level, some of the common interfaces fit together as follows:


                     -----------------
                     | KeysInterface |  --------------
                     -----------------  | UserConfig |
         --------------------       |   --------------
  /------| MessageSendEvent |       |   |     ----------------
 |       --------------------       |   |     | FeeEstimator |
 |   (as MessageSendEventsProvider) |   |     ----------------
 |                         ^        |   |    /          |      ------------------------
 |                          \       |   |   /      ---------> | BroadcasterInterface |
 |                           \      |   |  /      /     |     ------------------------
 |                            \     v   v v      /      v        ^
 |    (as                      ------------------       ----------------------
 |    ChannelMessageHandler)-> | ChannelManager | ----> | ManyChannelMonitor |
 v               /             ------------------       ----------------------
--------------- /                ^         (as EventsProvider)   ^
| PeerManager |-                 |              \     /         /
---------------                  |        -------\---/----------
 |              -----------------------  /        \ /
 |              | ChainWatchInterface | -          v
 |              -----------------------        ---------
 |                            |                | Event |
(as RoutingMessageHandler)    v                ---------
  \                   --------------------
   -----------------> | NetGraphMsgHandler |
                      --------------------