Store channels per-peer (ChannelManager)
Host: ariard -
The PR branch HEAD was ae665ce at the time of this review club meeting.
- The core component of LDK is the
ChannelManager. This structure gathers the channels states and the pending messages (forward HTLCs, outbound payments, inbound payments) to be applied triggering a state transition.
ChannelManagerholds on-chain data (e.g best block seen) and user setting (node config) as those fields alter the processing of the state transitions (e.g reject
funding_satoshisis under user’s
- Zooming, 2 notable members of
ChannelHodlerstores currently few different elements such as the channels, the HTLC to be forwarded and the LDK internal processing events.
PeerStateonly stores the per-peer features flag for now.
- As of today,
ChannelHolderis protected by a single
Mutexrequiring in-order processing of the events, and thus only one channel can execute state transition at the same time. #1507 and the split-off #1542 are WIP enabling better parallelization of LDK channel processing.
1) What’s the current processing flow from receiving an inbound message in
handle_message() to sending to the appropriate
Channel’s method ? How many locks are taken and when ?
2) This PR is moving the
HashMap<[u8; 32], Channel<Signer>> from
PeerState. What’s the purpose of this move ? Does it change anything for a LDK user ?
3) Why introducing a new
4) What is backward compatibility and what is LDK’s project policy on structure serialization backward compatibility ?
5) The PR is using
FairRwLock to protect
PeerState. What are the advantages of
FairRwLock compare to Rust’s traditional
6) What could be the future internal refactoring after this PR to achieve #422 ?
7) Apart of HTLC/message processing, what are the other perfomance bottlenecks of a LN node ?