(routing+lnrpc): arbitrary route source + route transformation #9153
Conversation
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
calvinrzachman
force-pushed
the
route-manipulation
branch
from
b7b7c2a
to
ad747b3
Compare
Allow configurable post-processing which transforms paths or routes built by the ChannelRouter. This allows a setup in which the ChannelRouter runs remotely from the HTLCSwitch to build routes as if they we're constructed from the perspective of the lnd instance itself by trimming hops. This means that the onions the ChannelRouter builds will be ready for direct delivery to the peer of an lnd backend via the SendOnion style RPC, without requiring it be peeled.
The RouterBackend assumes that the source public key for a route is always the node’s public key when calling UnmarshallRoute. Here we update to allow overriding of this field to any arbitrary public key.
The routerrpc.Server and ChannelRouter assume that the source public key for a route is always the node’s public key when calling BuildRoute. We update to allow overriding of this field to any arbitrary public key. The list of hop public keys must be connected to the source via channels in our graph view.
calvinrzachman
force-pushed
the
route-manipulation
branch
from
ad747b3
to
0dd29b2
Compare
|
@ellemouton: review reminder |
High level thoughtsthanks for the detailed outline. I guess I had initially thought we could have a new very abstract "virtual channel" type that the remote channel router could open with each of the LND nodes. Each LND node can be given an allow-list of who to accept such a channel from. If that abstraction could be possible, then the underlying method of sending should be able work as is today right? Ie channel router just builds the routes and sends directly to switch which uses UpdateAddHTLC to communicate the send. Then the LND node will see the incoming UpdateAddHTLC from an upstream virtual channel. Anyways - that is just what I thought the plan was. But perhaps getting channels to be that abstract is a bit of a tall order. Re the PR description
I think I lost you a bit at this point. are you saying that the remove router will call SendPayment on the LND nodes? I thought a new SendOnion endpoint was the idea? Or are you saying that the SendPayment is called on the channelrouter? If the former, then im not sure why the real LND node needs to transform the route? Yeah I think I lost you after this point. It would help to have a step by step flow (ie, what is calling what when and what is doing what transformation when etc etc). |
|
|
||
| // A transformation which will be applied to every route created for | ||
| // this payment session. | ||
| routeTransform RouteTransformFunc |
There was a problem hiding this comment.
can use fn.Option instead so that we dont have to remember to do a nil check
| // option is a functional option for configuring the payment session. | ||
| type option func(*paymentSession) | ||
|
|
||
| // withRouteTransform sets a route transformation function. | ||
| func withRouteTransform(routeTransform RouteTransformFunc) option { | ||
| return func(ps *paymentSession) { | ||
| ps.routeTransform = routeTransform | ||
| } |
There was a problem hiding this comment.
best practice is to have a separate paySessOptions struct with the specific things we all a caller to "edit".
There was a problem hiding this comment.
so I'd do:
// paySessOptions holds ...
type paySessOptions struct {
// routeTransform is ...
routeTransform fn.Option[RouteTransformFunc]
}
// newDefaultPaySessOptions constructs...
func newDefaultPaySessOptions() *paySessOptions {
return &paySessOptions{}
}
// paySessOption is a functional option for configuring the payment session.
type paySessOption func(*paySessOptions)
// withRouteTransform sets a route transformation function.
func withRouteTransform(routeTransform RouteTransformFunc) paySessOption {
return func(ps *paySessOptions) {
ps.routeTransform = fn.Some(routeTransform)
}
}
...
type paymentSession struct {
opts *paySessOptions
...
...
options := newDefaultPaySessOptions()
for _, opt := range opts {
opt(options)
}
return &paymentSession{
opts: options,
...
| @@ -251,6 +251,104 @@ func TestRequestRoute(t *testing.T) { | |||
| } | |||
| } | |||
|
|
|||
| func TestRouteTransformFunc(t *testing.T) { | |||
| @@ -194,14 +194,29 @@ type paymentSession struct { | |||
|
|
|||
| // log is a payment session-specific logger. | |||
| log btclog.Logger | |||
|
|
|||
| // A transformation which will be applied to every route created for | |||
There was a problem hiding this comment.
comment should start with name of variable
| if m.RouteTransform != nil { | ||
| options = append(options, withRouteTransform(m.RouteTransform)) | ||
| } |
There was a problem hiding this comment.
var options []paySessOption
m.RouteTransform.WhenSome(func(fn RouteTransformFunc) {
options = append(options, withRouteTransform(fn))
})
| @@ -228,6 +228,9 @@ type ChannelPolicy struct { | |||
| MinHTLC *lnwire.MilliSatoshi | |||
| } | |||
|
|
|||
| // RouteTransformFunc defines a function type for transforming a route. | |||
| type RouteTransformFunc func(route *route.Route) *route.Route | |||
There was a problem hiding this comment.
do we definitely want the flexibility to transform the entire route? It's a bit of a red flag to me cause we are depending on this module to construct a route but then we also as a caller are able to just replace that entire route... so can we not restrict the options a bit? Like WithPeeledFirstNode and things like that?
| The source node from whose perspective the route was built. If empty, | ||
| self is assumed. | ||
| */ | ||
| string source_pub_key = 9; |
| return nil, fmt.Errorf("invalid source pubkey: %w", err) | ||
| } | ||
| } | ||
|
|
||
| prevNodePubKey := r.SelfNode |
There was a problem hiding this comment.
prevNodePubKey is not necessarily selfnode anymore
There was a problem hiding this comment.
I think we should add tests for this change to make sure that things like this would be caught.
There was a problem hiding this comment.
gotta make sure that everywhere where r.SelfNode is used is still correct given this commit
| @@ -390,6 +390,12 @@ func (r *ChannelRouter) Stop() error { | |||
| return nil | |||
| } | |||
|
|
|||
| // GetSelfNode queries the current node identity public key used by the | |||
| // ChannelRouter. | |||
| func (r *ChannelRouter) GetSelfNode() route.Vertex { | |||
There was a problem hiding this comment.
can just call it SelfNode. Getter is implied (unless it clashes with a member in ChannelRouter (which I dont think it does))
| @@ -44,6 +44,8 @@ | |||
|
|
|||
| ## RPC Updates | |||
|
|
|||
| * [Allow arbitrary source public key for BuildRoute RPC](https://github.com/lightningnetwork/lnd/pull/9153) so that lnd's _*ChannelRouter*_ and _*routerrpc.Server*_ can build routes from the perspective of different nodes. | |||
There was a problem hiding this comment.
wrap at 80 🙏
(while we are here, we can fix the wrapping of the entry above (for 9017) as well)
Background & Motivation
We'd like to allow a ChannelRouter running remotely from a set of lnd instances to find paths through the network to payment destinations. For this, I have been able to come up with 2 choices:
Additional channel edges emanating from source representing fake/virtual channels: the remote ChannelRouter can have its own sense of self and think itself connected to all lnd backends via virtual channel edges. In this scenario, the channel edges emanating from the source node exist only to facilitate tricking the path finding of the ChannelRouter that its self node is actually connected to the broader network. Concerning how the ChannelRouter and pathfinding are to be informed of these edges:
Delegated pathfinding: the remote ChannelRouter has "multiple personalities", taking its sense of “self” to be all of the lnd backend nodes. Then, during pathfinding, it would select as the pathfinding source a given backend.
Change Description
If we use additional edges emanating from source node to trick the remote ChannelRouter into thinking that it’s connected to a set of lnd instances, then the routes/onions we build will include the lnd backend as a first hop. This presents us with a choice we can either:
The BuildRoute RPC provides a natural point to trim routes before sending them back to the client. Supporting the SendPaymentV2 flow from the remote ChannelRouter is a bit more involved as it does NOT have the ability to transform the route prior to onion construction and payment dispatch. We may need route post-processing hooks or otherwise more first class treatment of the channel edges emanating from source so that they meet our desired criteria. This is where the RouteTransformationFunc idea comes in.
The RouterBackend currently assumes that the source public key for a route is always the node’s public key when calling UnmarshallRoute. This means that any reliance we have on SourcePubKey field is troubled as modifications (eg: trimming) by BuildRoute or QueryRoutes will be undone.
The BuildRoute method relies on being given a continuous sequence of hop public keys from source to destination. The routerrpc.Server and ChannelRouter currently assume that the source public key for a route is always the node’s public key.