Skip to content

Commit a0e5f38

Browse files
dr-orlovskydr-orlovsky
committed
README and CI improvements. Closes #15 
1 parent 30652a2 commit a0e5f38

File tree

4 files changed

+113
-24
lines changed

4 files changed

+113
-24
lines changed

‎.github/workflows/binaries.yml

+3-3
Original file line numberDiff line numberDiff line change
@@ -25,14 +25,14 @@ jobs:
2525
uses: actions-rs/cargo@v1
2626
with:
2727
command: build
28-
args: --bin keyringd --features server
28+
args: --bin wired --features server
2929
- name: Build daemon with monitoring
3030
uses: actions-rs/cargo@v1
3131
with:
3232
command: build
33-
args: --bin keyringd --features server,monitoring
33+
args: --bin wired --features server,monitoring
3434
- name: Build CLI
3535
uses: actions-rs/cargo@v1
3636
with:
3737
command: build
38-
args: --bin keyring-cli --features integration,cli
38+
args: --bin lnp-cli keyring-cli --features integration,cli

‎.github/workflows/library.yml

+1-1
Original file line numberDiff line numberDiff line change
@@ -76,7 +76,7 @@ jobs:
7676
run: |
7777
cargo new dep_test
7878
cd dep_test
79-
printf 'keyring = { path = "..", default-features = false, features = ["integration"] }\n\n[workspace]' >> Cargo.toml
79+
printf 'lnp_node = { path = "..", default-features = false, features = ["integration"] }\n\n[workspace]' >> Cargo.toml
8080
- name: Build dependency
8181
uses: actions-rs/cargo@v1
8282
with:

‎README.md

+109-20
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,41 @@
11
# lnp-node: Lightning Network Protocol Node
22

33
`lnp-node` is a new Lightning Network node written from scratch in Rust.
4-
Actually, it's a suite of daemons able to run both Lightning Network Protocol
5-
and Generalized Lightning Channels.
6-
7-
One may ask: another LN node? Why we need it? And what is "Generalized Lightning
8-
Channels"?
4+
Actually, it's a suite of daemons/microservices able to run both Lightning
5+
Network Protocol (LNP) and Generalized Lightning Channels (GLC).
6+
7+
One may ask: another LN node? Why we need it? And what is "Lightning network
8+
protocol" and "Generalized Lightning Channels"?
9+
10+
**Lightning Network Protocol** is normal Lightning messaging protocol extracted
11+
from BOLTs and extended to support arbitrary messaging, RPC, P2P and publish/
12+
subscribe APIs over TCP/IP, TCP/Tor, UDP, ZeroMQ and high latency communication
13+
channels (mesh/satellite networks) with end-to-end encryption. It is 100% LN
14+
compatible (and in these terms Lightning Network runs on this protocol de-facto)
15+
but allows much more than current LN uses. The protocol is defined as a set of
16+
LNPBP15-19 standards, which are strict extensions of BOLTs. In other words, with
17+
this protocol you can do an arbitrary messaging (and build complex distrubuted
18+
systems without central authorities like DNS, SSL, IP addresses), so at LNP/BP
19+
we use it everywhere, even for internal communications between microservices.
20+
21+
**Generalized Lightning Channels** is a way of defining payment channels in a
22+
modular and extensible way such that you can easily add new transaction outputs
23+
to the commitment transaction, switch from HTLCs to PTLCs payments, use eltoo &
24+
do a lot of experimenttion without inventing new messages and standards each
25+
time: peers are using LNP to negotiate channel and transaction structure with
26+
partially-signed transactions.
27+
28+
Idea for both protocols came from Dr Maxim Orlovsky, Dr Christian Decker and
29+
Giacomo Zucco discussions in 2019-2020 and implemented by Maxim Orlovsky as a
30+
part of [LNP/BP Core Library](https://github.com/LNP-BP/rust-lnpbp).
31+
We recommend to watch to [Potzblitz about LNP Node](https://www.youtube.com/watch?v=YmmNsWS5wiM&t=5s&ab_channel=Fulmo%E2%9A%A1)
32+
and [LNP/BP networking presentation](https://www.youtube.com/watch?v=kTwZKsbIPbc&t=2123s&ab_channel=LNPBPStandardsAssociation)
33+
to get a deeper insight into these topics. Presentations slides are also
34+
avaliable:
35+
* [LNP/BP Decentralization Solutions]()
36+
* [Future of the Lightning Network]() (slides from the Postblitz talk)
37+
38+
## Rationale & features
939

1040
The problem with the existing Lightning node implementations is their very
1141
limited extensibility for such things as:
@@ -51,12 +81,84 @@ This new node will be used to implement:
5181

5282
The node must maintain simple/modular upgradability for:
5383

84+
* RGB smart contracts (client-validated smart contract system)
85+
* Discrete log contracts (DLCs)
5486
* Schnorr's/Taproot
55-
* Pay-to-elliptic curve point replacement for HTLCs
87+
* Pay-to-elliptic curve point lock contracts (PTLC) - replacement for HTLCs
5688
* eltoo
5789

90+
## Design
91+
92+
The node (as other nodes maitained by LNP/BP Standards Association and Pandora
93+
Core company subsidiaries) consists of multiple microservices, communicating
94+
with each other via LNP ZMQ RPC interface.
95+
96+
![Node architacture](doc/node_arch.jpeg)
97+
98+
The set of microservices representing node can run as either:
99+
1) single daemon process on desktop or a server;
100+
2) cloud of docker-based daemons, one per microservice, with instance
101+
scalability and in geo-distributed environment;
102+
3) inside a single mobile app as threads;
103+
4) and even different nodes can be combined in their services between themselves
104+
into a single executables/mobile apps;
105+
5) all P2P communications are end-to-end encrypted and work over Tor.
106+
107+
Other nodes, designed an maintained by LNP/BP Standards Association with the
108+
same architecture include:
109+
* [RGB Node](https://github.com/LNP-BP/bp-node) for running RGB smart contracts
110+
over bitcoin and lightning network
111+
* [BP Node](https://github.com/LNP-BP/bp-node) for indexing bitcoin blockchain
112+
(you may think of it as a more efficient Electrum server alternative)
113+
* Bifrost – node for storing/passing client-side-validated data with watchtower
114+
functionality and used for Storm/RGB/DEX infrastructure
115+
116+
Other third parties provide their own nodes:
117+
* [Keyring](https://github.com/pandoracore/keyring) for managing private key
118+
accounts, storage and signatures with support for miniscript and PSBTs
119+
* [MyCitadel](https://github.com/mycitadel/mycitadel-node) Bitcoin, LN & RGB
120+
enabled wallet service with support for other LNP/BP protocols
121+
122+
## Project organization & architecture
123+
124+
* [`src/api/`](src/api/) – LNP messages for all daemons used for message bus
125+
* [`src/bin/`](src/api/) – binaries for daemons & CLI launching main process
126+
* [`src/cli/`](src/api/) – CLAP-based command line API talking to message bus
127+
* [`src/i8n/`](src/api/) – functions exposed to FFI talking to message bus
128+
* [`src/<name>d/`](src/api/) – service/daemon-specific code:
129+
- [`src/wired/`](src/wired) – daemon managing peer connections within
130+
Lightning peer network using LNP (Lightning network protocol). Specific
131+
supported message types are defined as a part of
132+
[LNP/BP Core Library](https://github.com/LNP-BP/rust-lnpbp)
133+
- [`src/channeld`](src/channeld) – daemon managing generalized Lightning
134+
channels with their extensions
135+
- [`src/lightningd`](src/lightningd) – daemon initializing creation of new
136+
channels
137+
- [`src/routed`](src/routed) – daemon managing routing information
138+
- [`src/gossip`](src/gossip) – daemon managing gossip data
139+
- [`src/keyd`](src/keyd) - key managing daemon
140+
141+
Each daemon (more correctly "microservice", as it can run as a thread, not
142+
necessary a process) or other binary (like CLI tool) follows the same
143+
organization concept for module/file names:
144+
* `error.rs` – daemon-specific error types
145+
* `config.rs` – CLAP arguments & daemon configuration data
146+
* `runtime.rs` – singleton managing main daemon thread and keeping all ZMQ/P2P connections and sockets; receiving and processing messages through them
147+
* `processor.rs` – business logic functions & internal state management which does not depend on external communications/RPC
148+
* `index/`, `storage/`, `cache/` – storage interfaces and engines
149+
* `db/` – SQL-specific schema and code, if needed
150+
151+
## Ways of communication
152+
153+
* IRC channels on Freenode
154+
* \#lnp-bp: discussions on this and other LNP/BP projects
155+
* \#rust-bitcoin: here you can get general support on rust-lightning
156+
* \#lightning-dev: here better to ask generic lightning-network questions
157+
* dr_orlovsky: my account on IRC
158+
* Lightning Hackdays Mattermost channel:
159+
<https://mm.fulmo.org/fulmo/channels/x-rust-ln-node>
58160

59-
## Previous work & docs
161+
## Previous (mostly independent/unrelated) work
60162

61163
* `rust-lightning` architecture explanation:
62164
<https://github.com/rust-bitcoin/rust-lightning/blob/master/ARCH.md>
@@ -77,16 +179,3 @@ The node must maintain simple/modular upgradability for:
77179
<https://github.com/LNP-BP/txserv>
78180
* SquareCrypto Development Kit based on `rust-lightning` library:
79181
<http://lightningdevkit.org/>
80-
81-
82-
## Ways of communication
83-
84-
* IRC channels on Freenode
85-
* \#lnp-bp: discussions on this and other LNP/BP projects
86-
* \#rust-bitcoin: here you can get general support on rust-lightning
87-
* \#lightning-dev: here better to ask generic lightning-network questions
88-
* dr_orlovsky: my account on IRC
89-
* Lightning Hackdays Mattermost channel:
90-
<https://mm.fulmo.org/fulmo/channels/x-rust-ln-node>
91-
92-
## Architecture

‎doc/node_arch.jpeg

144 KB
Loading

0 commit comments

Comments
 (0)