mirror of
https://github.com/lightningdevkit/rust-lightning.git
synced 2025-01-19 05:43:55 +01:00
63 lines
3.6 KiB
Markdown
63 lines
3.6 KiB
Markdown
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 `ChannelMonitor`s 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 `ChannelMonitorUpdate`s 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. `Router` handles receiving channel and node
|
|
node announcements and calculates routes for sending payments. `PeerManager` handles the
|
|
authenticated and encrypted communication protocol, monitoring for liveness of peers,
|
|
routing messages to `ChannelManager` and `Router` 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 ---------
|
|
\ ----------
|
|
-----------------> | Router |
|
|
----------
|
|
```
|