Crates.io | lnp-cli |
lib.rs | lnp-cli |
version | 0.9.1 |
source | src |
created_at | 2022-05-23 07:44:14.881723 |
updated_at | 2023-02-06 19:12:58.689072 |
description | LNP node command-line interface |
homepage | |
repository | |
max_upload_size | |
id | 591635 |
size | 94,303 |
LNP Node is a new Lightning Network node written from scratch in Rust. Actually, it's a suite of daemons/microservices able to run both Lightning Network (LN) as it is defined in BOLT standards - and generalized lightning codenamed "Bifrost": a full refactoring of the lightning network protocols supporting Taproot, Schnorr signatures, RGB assets, DLCs, multi-peer channels, channel factories/channel composability and many other advanced features. LNP Node operates using Internet2 networking protocols and specially-designed microservice architecture.
One may ask: another LN node? Why we need it? And what is this lightning network protocol (LNP), and Internet2 networking and generalization of lightning channels coming with Bifrost?
Lightning Network Protocol is unification of both "normal" (or "legacy") Lightning network and Bifrost: a family of protocols operating on top of bitcoin protocols (BP) and together composing family of LNP/BP tech stack.
Internet2 is a set of best practices to use existing protocols in network communications preserving most of privacy and anonymity. It supports both P2P and RCP (client-server) operations and represents lightning-styled Noise_XK encrypted communications (instead of SSL/TLS) for P2P and encrypted ZeroMQ for client-server communications. This allows to avoid most common pitfalls with centralized certificate authorities or plain-text low-efficiency JSON/XML RPC or web service protocols. P2P layer is an extract from BOLT-8 and, partially, BOLT-1, extended to support arbitrary messaging, RPC, P2P and publish/ subscribe APIs over TCP/IP, TCP/Tor, UDP, ZeroMQ and high latency communication channels (mesh/satellite networks) with end-to-end encryption. It is 100% LN compatible (and in these terms Lightning Network runs on this protocol de-facto) but allows much more than current LN uses. The protocol is defined as a set of LNPBP15-19 standards, which are strict extensions of BOLTs. In other words, with this protocol you can do an arbitrary messaging (and build complex distributed systems without central authorities like DNS, SSL, IP addresses), so at LNP/BP Association we use it everywhere, even for internal communications between microservices.
Bifrost is a way of defining payment channels in a modular and extensible way such that you can easily add new transaction outputs to the commitment transaction, switch from HTLCs to PTLCs payments, use taproot & do a lot of experimentation without inventing new messages and standards each time: peers are using Bifrost to negotiate channel and transaction structure with partially-signed transactions.
Idea for both protocols came from Dr Maxim Orlovsky, Dr Christian Decker and Giacomo Zucco discussions in 2019-2020 and implemented by Maxim Orlovsky as a part of LNP Core Library. We recommend to watch to Potzblitz about LNP Node and LNP/BP networking presentation to get a deeper insight into these topics. Presentations slides are also avaliable:
The problem with the existing Lightning node implementations is their very limited extensibility for such things as:
We name the extensions to Lightning network required to build this rich functionality "Bifrost". With this project LNP/BP Standards Association is trying to build an LN node with extensible and highly-modular architecture, utilizing state-of-the-art Rust approaches like:
This new node will be used to implement:
The node (as other nodes maitained by LNP/BP Standards Association and Pandora Core company subsidiaries) consists of multiple microservices, communicating with each other via ZMQ RPC interfaces.
The set of microservices representing node can run as either:
Other nodes, designed an maintained by LNP/BP Standards Association with the same architecture include:
Other third parties provide their own nodes:
The overall architecture of LNP Node is the following:
More information on the service buses used in the node:
cli/
– command line API talking to LNP Node via RPC (see below);rpc/
– RPC client library for controlling LNP Node;src/
– main node source code:
peerd/
– daemon managing peer connections
within Lightning peer network using LNP (Lightning network protocol).;channeld
– daemon managing generalized Lightning
channels with their extensions;lnpd
– daemon initializing creation of new channels and
connections;routed
– daemon managing routing & gossips;watchd
– daemon watching on-chain transaction status;signd
- key managing for key derivation & signatures;
uses Descriptor Wallet lib.Each daemon (more correctly "microservice", as it can run as a thread, not necessary a process) or other binary (like CLI tool) follows the same organization concept for module/file names:
error.rs
– daemon-specific error types;opts.rs
– CLAP arguments & daemon configuration data;runtime.rs
– singleton managing main daemon thread and keeping all ZMQ/P2P
connections and sockets; receiving and processing messages through them;automata/
- state machines implementing different operation workflows;index/
, storage/
, cache/
– storage interfaces and engines;db/
– SQL-specific schema and code, if needed.To compile the node, please install cargo
sudo apt install -y build-essential
cargo install --path . --locked --all-features
Before running the node, it is necessary to set an xpriv to create a funding wallet:
lnpd -vvv init
# The prompt shows something like this:
Initializing node data
Data directory '/[DATA_DIR]/.lnp_node/signet' ... found
Signing account 'master.key' ... creating
Please enter your master xpriv:
To compile the node, please install cargo, then run the following commands:
sudo apt install -y build-essential cmake libsqlite3-dev libssl-dev libzmq3-dev pkg-config
cargo install --path . --locked --all-features
lnpd -vvv
docker build -t lnp-node .
docker run --rm --name lnp_node lnp-node