Routing on Lightning is an optimization problem with continuous development, developers do not only aim to reduce the computational costs and increase the privacy, they also mean to delegate route computations to other nodes in a trustless manner, lets take a look at layer 1 for an example.

Full nodes are nodes that verify transactions themselves, they hold the entire blockchain and the UTXO set which makes them able to verify any transaction based on a defined consensus and the history of the transaction inputs. On the other hand lite clients use methods such as SPV to verify the existence of a transaction in a block without downloading the block itself, they rely on other full nodes to make that CPU/Memory heavy operation for them.

The way Lightning currently works is that the sender calculates the route from its node to the receiver’s node, this means that the sender’s node must have an updated network of nodes, it might not be connected to the receiver directly but it is connected through a path in the network.

This might be fine for Lightning in its current state, but it won’t be if the number of channels expand into the millions due to adoption. Trampoline payments is a new suggested way of outsourcing that aims at having lite clients outsourcing the route computation to trampoline nodes, nodes of higher Memory, bandwidth and computation power.

An example to this is very simple, we have a sending node A and a receiving node F, and a channel graph that looks like this:

A → B → C → D → E → F

The sending node A only holds close neighbors and so it doesn’t know where F is, but it knows where C is, it therefore sends the payment to C and asks it to route that payment to F, C is a trampoline node that holds the entire network and so it can calculate the most efficient path to F and send the payment through it.

Developer Christian Decker suggested multiple way of doing this. First is a simple variant where the sending node finds a close trampoline node then sends the payment information, mainly the recipient public key and the value of the transaction, the trampoline node then compute a route to the recipient node, generates shared secrets, HMACs, a new onion route and everything else. However, a small drawback here is privacy, since the sending node sends the trampoline the payment information, the trampoline node now knows the recipient, this is currently not the case as in a regular Lightning transaction each node is just routing the transaction to the next node, knowing only that it is the next one in the list not if it is the end of it.

Another is multi-trampoline routing, it is a more complex idea involving two layers of onion routing, the inner layer describes the “Trampoline route” and the outer layer describes the route between two nodes, these two nodes maybe sender and trampoline, trampoline and trampoline or trampoline and receiver.

The inner layer is a set of trampoline nodes picked randomly from a set of known nodes, once a trampoline receives the payment it unwraps the inner onion yielding the next trampoline node, it then finds a route to this node and creates an outer routing onion with that payload. This allows us to bounce payments between trampolines without them learning the recipient and while the sender does not need to keep a total view of the network topology, it needs to have just enough to guarantee a reasonable chance that two consecutive trampolines can find a route to each other.

The second method also has a trade off, it increases the maximum length of the route to length of outer hops * length of inner hops, while the length usually was just length of outer hop. This may result in increased fees but it will also result in an increase in chances of payment succeeding as this proposal brings the Lightning network “closer to Tor on TCP/IP”. Indeed just like TCP/IP a payment that fails can be retried several times until it succeeds as every trampoline node creates its own onion route. There has been a juicy discussion on this in the Lightning-dev mailing list with examples and future implementation details, you can read more about it here.

Refernces:

• Discussion
• Lightning Onion Routing
• Onion Routing