Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[epic]: ChannelDB, Graph, Gossiper and Router separation #8833

Open
ellemouton opened this issue Jun 12, 2024 · 0 comments
Open

[epic]: ChannelDB, Graph, Gossiper and Router separation #8833

ellemouton opened this issue Jun 12, 2024 · 0 comments
Labels
advanced Issues suitable for very experienced developers architecture Related to system design enhancement Improvements to existing features / behaviour epic Issues created to track large feature development graph routing

Comments

@ellemouton
Copy link
Collaborator

ellemouton commented Jun 12, 2024

This issue aims to track a set of improvements that we want to make to LND in the long haul. In general this involves adding more abstractions and making things more modular so that:

  1. there is more clear ownership of what a sub-system owns
  2. more abstractions means that LND can be "pieced" together: for example we could spin up a new LND node, turn off it's gossiper and point it's ChannelRouter to an existing, fully populated channel graph source.

LND Today

  • DB: the node's channel state data is stored in the same DB as the network graph data
  • Gossiper: the gossiper handles both network announcements from peers but then also special cases certain announcements relevant to the node it belongs to. It does some announcement validation & then sends the announcements to the Router to handle further.
  • The Router then further validates the announcements, handles topology change notifications and writes the announcements to the graph.

lnd-today drawio

The Vision

  • A complete separation between the Gossiper and the Router.
  • Router only has read access through a very small interface to a Graph source. And it essentially can become completely node agnostic.
  • Gossiper does all announcement validation and is the only thing writing to the graph DB.
  • Local Chans Announcement manager has it's own DB for it's channel state and channel announcements.

With the following vision, LND really only needs the following pieces on startup (from the sub-systems we are referring to here that is):

  • a Local Announcement Manager which we will provide with a BroadcastAnnouncements call which may be backed by it's own gossiper or another node's gossiper.
  • a Router which we will provide with a RoutingGraph interface which could be backed by a different node's channel graph.

lnd-vision drawio

Related Issue: #6294

What's next?

The following 2 steps seem to be good starting points:

  1. Just ensuring that the pathfinding logic in the Router only has access to an abstracted, read only routing graph. Along with this, we can abstract out the additionalEdges and bandwidthManager inputs so that those are provided via an interface or via call-backs in the pathfinding request.
  2. removing announcement validation, pruning and topology subscription from the router
@ellemouton ellemouton added the enhancement Improvements to existing features / behaviour label Jun 12, 2024
@yyforyongyu yyforyongyu added routing graph architecture Related to system design advanced Issues suitable for very experienced developers labels Jun 13, 2024
@saubyk saubyk added the epic Issues created to track large feature development label Jun 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
advanced Issues suitable for very experienced developers architecture Related to system design enhancement Improvements to existing features / behaviour epic Issues created to track large feature development graph routing
Projects
None yet
Development

No branches or pull requests

3 participants