mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-02-24 15:02:20 +01:00
Code Issues Projects Releases Packages Wiki Activity
rust-lightning/ARCH.md

63 lines
4 KiB
Markdown
Raw Normal View History

Add some basic arch diagrams/descriptions.
2020-02-25 15:57:58 -05:00
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
Replace ManyChannelMonitor with chain::Watch Rename ManyChannelMonitor to chain::Watch and move to chain/mod.rs, where chain-related interfaces live. Update the documentation for clarity and to conform to rustdoc formatting.
2020-07-20 17:03:52 -07:00
HTLCs which are near expiration. The `chain::Watch` interface provides a way for you to
Add some basic arch diagrams/descriptions.
2020-02-25 15:57:58 -05:00
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
Rename NetGraphMsgHandler to P2PGossipSync NetGraphMsgHandler implements RoutingMessageHandler to handle gossip messages defined in BOLT 7 and maintains a view of the network by updating NetworkGraph. Rename it to P2PGossipSync, which better describes its purpose, and to contrast with RapidGossipSync.
2022-06-01 10:28:34 -07:00
as the `ChannelManager` or on a separate one. `P2PGossipSync` handles receiving channel
Update missed references to get_route in docs
2021-11-04 09:57:53 -05:00
and node announcements, which are then used to calculate routes by `find_route` for sending
payments. `PeerManager` handles the authenticated and encrypted communication protocol,
Rename NetGraphMsgHandler to P2PGossipSync NetGraphMsgHandler implements RoutingMessageHandler to handle gossip messages defined in BOLT 7 and maintains a view of the network by updating NetworkGraph. Rename it to P2PGossipSync, which better describes its purpose, and to contrast with RapidGossipSync.
2022-06-01 10:28:34 -07:00
monitoring for liveness of peers, routing messages to `ChannelManager` and `P2PGossipSync`
Improve routing-related documentation
2020-05-06 19:04:44 -04:00
instances directly, and receiving messages from them via the `EventsProvider` interface.
Add some basic arch diagrams/descriptions.
2020-02-25 15:57:58 -05:00
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 |
Fix architecture diagram arrow directions Arrows should signify "calls" or "generates" unless noted.
2020-08-03 16:55:11 -07:00
-------------------- ^ --------------
------| MessageSendEvent | | ^ ----------------
Fix architecture diagram line length
2020-08-03 16:51:10 -07:00
/ -------------------- | | | FeeEstimator | <-----------------------
Rename SimpleManyChannelMonitor to ChainMonitor ManyChannelMonitor was renamed chain::Watch in the previous commit. Use a more concise name for an implementation that monitors the chain for channel activity. Future work will parameterize the struct to allow for different varieties of persistence. Thus, users usually will be able to use ChainMonitor directly rather than implementing a chain::Watch that wraps it.
2020-07-20 22:12:14 -07:00
| (as MessageSendEventsProvider) | | ---------------- \
Fix architecture diagram arrow directions Arrows should signify "calls" or "generates" unless noted.
2020-08-03 16:55:11 -07:00
| ^ | | ^ ------------------------ |
Rename SimpleManyChannelMonitor to ChainMonitor ManyChannelMonitor was renamed chain::Watch in the previous commit. Use a more concise name for an implementation that monitors the chain for channel activity. Future work will parameterize the struct to allow for different varieties of persistence. Thus, users usually will be able to use ChainMonitor directly rather than implementing a chain::Watch that wraps it.
2020-07-20 22:12:14 -07:00
| \ | | / ---------> | BroadcasterInterface | |
| \ | | / / ------------------------ |
Fix architecture diagram arrow directions Arrows should signify "calls" or "generates" unless noted.
2020-08-03 16:55:11 -07:00
| \ | | / / ^ |
Rename SimpleManyChannelMonitor to ChainMonitor ManyChannelMonitor was renamed chain::Watch in the previous commit. Use a more concise name for an implementation that monitors the chain for channel activity. Future work will parameterize the struct to allow for different varieties of persistence. Thus, users usually will be able to use ChainMonitor directly rather than implementing a chain::Watch that wraps it.
2020-07-20 22:12:14 -07:00
| (as ------------------ ---------------- | |
| ChannelMessageHandler)-> | ChannelManager | ----> | chain::Watch | | |
v / ------------------ ---------------- | |
--------------- / (as EventsProvider) ^ | |
| PeerManager |- \ | | |
--------------- \ | (is-a) | |
Move `chain::Access` to `routing` and rename it `UtxoLookup` The `chain::Access` trait (and the `chain::AccessError` enum) is a bit strange - it only really makes sense if users import it via the `chain` module, otherwise they're left with a trait just called `Access`. Worse, for bindings users its always just called `Access`, in part because many downstream languages don't have a mechanism to import a module and then refer to it. Further, its stuck dangling in the `chain` top-level mod.rs file, sitting in a module that doesn't use it at all (it's only used in `routing::gossip`). Instead, we give it its full name - `UtxoLookup` (and rename the error enum `UtxoLookupError`) and put it in the a new `routing::utxo` module, next to `routing::gossip`.
2023-01-21 03:28:35 +00:00
| -------------- \ _---------------- / /
| | UtxoLookup | \ / | ChainMonitor |---------------
| -------------- \ / ----------------
Fix architecture diagram arrow directions Arrows should signify "calls" or "generates" unless noted.
2020-08-03 16:55:11 -07:00
| ^ \ / |
(as RoutingMessageHandler) | v v
Rename NetGraphMsgHandler to P2PGossipSync NetGraphMsgHandler implements RoutingMessageHandler to handle gossip messages defined in BOLT 7 and maintains a view of the network by updating NetworkGraph. Rename it to P2PGossipSync, which better describes its purpose, and to contrast with RapidGossipSync.
2022-06-01 10:28:34 -07:00
\ ----------------- --------- -----------------
-----------------> | P2PGossipSync | | Event | | chain::Filter |
----------------- --------- -----------------
Add some basic arch diagrams/descriptions.
2020-02-25 15:57:58 -05:00
```
Reference in a new issue Copy permalink