Split LND in node and core processes

[joostjager]

LND remote signing is currently only available as a blind signer without the possibility of validation and policy enforcement. This is detailed further in #6243.

Making the remote signer more intelligent seems to lead to a great deal of duplication of logic between lnd and the remote signer, to the point where the remote signer needs to keep its own channel state database and chain backend connection.

One idea (previously described #6243 (comment)) is to split lnd in a node process and a core process to achieve a similar result without duplication.

In this diagram, pathfinding and invoicing are still part of node. Those components however could easily be isolated in dedicated processes too.

The main change is that peer messages are forwarded from node to core after they've been decrypted by node using the node key. The node key is derived from the main seed, so node won't have access to the keys that core uses (which would defeat the purpose of the split).

To remain flexible, it may be an option to use abstract interfaces for the link between node and core, where an in-process and a grpc implementation of the interface exist. This allows users that don't care about remote signing to keep running a single process.

As a starting point, we've created two branches that give a rough impression of the touch points:

LND Core: https://github.com/bottlepay/lnd/tree/lnd-core
LND Node: https://github.com/bottlepay/lnd/tree/lnd-node

The purpose of this issue is to discuss what it would take to complete the described split, how much effort would be required and whether this is a solution that can count on support from the community.

[Crypt-iQ]

I think we could go further and split out contractcourt (optionally) so you essentially have a watchtower

[Roasbeef]

Related to this issue, and the comment posted there: #6294

[Roasbeef]

Tbh, I don't think much really needs to be done w.r.t removing code from the main project. Instead in the spirit of issues like #6294 and #6288 as we start to further refactor and decouple the main sub-systems, then it would be possible for anyone to spin up a subset of the sub-systems in a new process and have that implement some new custom functionality.

Like consider if #6288 was done, something like lnmux would be much smaller, as it could re-use all the invoice registry logic and then just add the new service discovery and coordination aspects.

I'd also consider this to be mostly under the umbrella of this master tracking issue: #3944. I don't see many major obstacles towards this either, given that we have a new peersrpc, where the next call will likely be gossip message injection and potentially generalized messages as well. For example, today someone could already do something like spin up lnd in a new process, and slot in Redis (or w/e) as a custom DB driver, or hook up their external wallet as the main on-chian key handler.

I'm not sure we (lnd in the repo) need to make that hard split though, as long as it's possible for someone to do something like: instantiate the gossiper on a new machine, have lnd connect out to that to push out notifications, and then read the new gossip updates/states from its abstracted ChannelGraph reference.

[joostjager]

I didn't want to suggest to actually remove code. In those branches, I removed code only to highlight the breaking points that currently exist.

I think it is fine to leave everything in a single repository, as long as the interfaces are defined in such a way that it becomes possible to create that inter-process connection between node and core as described above.

It's definitely something under the umbrella of #3944, but I also think it helps to define sub-issues like these to discuss concrete separations in specific areas. Also there may be more refactoring required than just instantiating a different version of a component.

The most important question for this specific issue though is whether the proposed split would actually make a node deployment more secure. How much does decrypting and forwarding node messages in a "frontend" process help with security? It does seem to shrink the attack surface slightly, but is it meaningful enough?

[Roasbeef]

but I also think it helps to define sub-issues like these to discuss concrete separations in specific areas.

Agreed, I think #6294 is likely an initial first step, as it allows the strict seperation of gossip from the rest of the daemon. We have another in-flight project that starts to extend the peersrpc server to be able to push out gossip updates as well, which sets the stage for further decomposition.

How much does decrypting and forwarding node messages in a "frontend" process help with security? It does seem to shrink the attack surface slightly, but is it meaningful enough?

IIUC, the goal here isn't actually better security, but more flexibility. Depending on the desired set up, I don't think the decrypt and forward would even really be necessary. One benefit of splitting out gossip is that you can reduce the load on a given node, and also map N nodes to the gossip store/updates of a single node. So in that scenario the main nodes would either just have a read-only view into the on-disk graph state, or use a new RPC bridge to be notified of any changes and also push our their own updates. This then allows the main node to have even fewer connections: only those that it actually has direct channels with.

[joostjager]

Separating the gossip from the rest of the daemon indeed looks like a good step to increase flexibility and it reduces the amount of code that runs in the channel-managing core process.

I think you're saying that beyond that, adding decrypt-and-forward may not make the setup more secure. Isn't that another reduction of the attack surface that helps with security? Or is there a different separation that you think would be more beneficial to address first from a security point of view?