Hi Alex, This is quite similar to eclair's cluster mode [1] so I can definitely say it's a great idea :-)
Our rationale was as much reducing the attack surface (we didn't like our node being directly accessible from the internet) as improving scalability (handling the constant flow of connections/disconnections from mobile wallets, and a ton of gossip). Some specific points on our implementation: - there can be N instances of proxy and their number can be adjusted without downtime - our proxy also does preprocessing for gossip (they keep an up-to-date copy of routing table and directly answer queries, and also dedup incoming announcements before forwarding to the backend, where the announcements are verified) - outgoing connections (initiated by an operator from the backend) are also initiated by the proxy. Even incoming connections from Tor are directed to the proxy. The backend node handles zero LN connections - since the front needs the node key for the secure handshake, this led us to introduce a separate key hierarchy for channel management [2] - we have considered, but not implemented, a "lockdown mode" where the front would only allow incoming connections from known peers that already have a channel - if your setup has a separate db server (e.g. postgres), and logs are properly rotated/streamed out, then the resources that typically run out when scaling up (file descriptors, disk space, etc.) should be really under control on your main node Hope that helps, Pierre [1] https://github.com/ACINQ/eclair/blob/master/docs/Cluster.md [2] https://github.com/ACINQ/eclair/pull/1584 Le jeu. 1 sept. 2022 à 19:56, Alex Akselrod via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > At NYDIG, we're considering ways to harden large LND deployments. Joost > and I discussed that currently, when external untrusted peers make inbound > connections, LND must verify the identity of the peer during the noise > handshake, and it must do this before enforcing any potential key-based > allow lists. This is done in the same process as the node's other critical > tasks, such as monitoring the chain. > > To reduce the attack area of the main node process, we'd like to propose a > means to optionally separate the peer communication into a separate > process: something like CLN's connectd, running separately, and the > connections would be multiplexed over a single network connection initiated > from the node to the proxy. The core of our current idea is demonstrated in > a draft PR: https://github.com/lightningnetwork/lnd/pull/6843 > > I'd love some early feedback on the general direction of this. If this > would be interesting, I'll build it out into a fully working feature. > > Thanks, > > Alex Akselrod > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
