Link Search Menu Expand Document Video

Mapping the Lightning Layers Model to LDK Architecture

(Incomplete)

A mapping of how the distinct libraries in the LDK correspond to the different components in the Lighting protocol layers model.

LDK Non-Core Components (all batteries)

These include mostly components for interacting with the Bitcoin network level of the architecture. It mostly has to do with managing and storing UTXOs/keys. The two Lightning Network related components in this category are defining:

  • Disk I/O: how channels get stored (local storage, cloud etc)
  • TCP networking: how messages get sent along to LN peers

Bitcoin Network based

Blockchain data (feeds into ChainMonitor)

e.g. from Neutrino

Wallet

On-chain UTXO management logic (display balances, create transactions etc.)

Tx Broadcast (Bitcoin Networking)

Broadcasting of signed transactions to the Bitcoin network

Private key management

Signing transactions

Fee estimation

for monitoring the mempool and suggesting sensible fees

Lightning Infrastructure based

Disk storage

Channel state persistence

LN Networking

[1. Network Connection Layer]
Making peer connections, facilitating peer data to and from LDK

Core Components

These include components from the Lightning Protocol stack that are responsible for interacting with the Lightning-level network and facilitating LN logic.

Implemented components

ChainMonitor

[3. Peer-to-Peer Layer]
Tracking one or more ChannelMonitors and using them to monitor the chain for lighting transactions that are relevant to our node, and broadcasting transactions if need be

ChannelManager

[3. Peer-to-Peer Layer]
Managing channel state; gets chain updates from ChainMonitor post-initial-sync

ChannelMonitor (created by ChannelManager)

If LDK is restarting, its channel state will need to be read from disk and fed to the ChannelManager on the next step, as well as the ChainMonitor in the following step

PeerManager

[3. Peer-to-Peer Layer]
Managing peer data

Routing (NetGraphMsgHandler), potential battery

[5. Payment (Reliable) Layer]
Generating routes to send payments over.

Note: NetworkGraph in the diagram is redundant.

Missing Components

InvoiceGenerator

[2. Messaging Layer], [5. Payment Layer]
Generating invoices to send along routes.

InvoiceAcceptor

[2. Messaging Layer], [5. Payment Layer]
Accepting a received invoice, ssending HTLC back along the route, and updating channel states.