Author: Cezary Dziemian 2020-02-11 18:58:51
Published on: 2020-02-11T18:58:51+00:00
The Lightning-dev mailing list has been discussing various routing methods. One of these is ant routing, which involves nodes emitting "pheromones" that are broadcasted throughout the network. When a node receives a pheromone from a peer it has a channel with, it records the pheromone and broadcasts it to other peers it has channels with, with the distance counter increased by one. A payee can then provide the pheromone identifier to a payer, which can check if it has received that pheromone and from which channel it received it from.Another routing method discussed is `getroutequick`, which caches the result of a Dijkstra run for faster subsequent Greedy Best First Search. Combining ant routing and `getroutequick`, it is suggested that a possible payee release a pheromone once (equivalent to the pre-cached Dijkstra run) and then subsequent payments just use the pre-cached Dijkstra by referring to that pheromone. To handle pheromones, every node that wants to be a forwarding node keeps a mapping from a non-self node ID to a distance counter. When a node receives a pheromone from a peer it has a channel with, it checks if the node already exists in its mapping. If it exists and the distance counter in the pheromone is larger than or equal to the distance counter in the mapping, it ignores the pheromone. If the distance counter in the pheromone is less than that in the mapping, it updates its mapping and sends the pheromone to its peers it has channels with, but with the distance counter one greater than what it has now.The Lightning Network is also proposing a trampoline routing system that adds an onion routing layer above individual channel hopping. The trampoline node receives an onion packet, which is then sent to the destination specified by the `getroutequick` channel-level routing layer. The onion packet openly indicates how much of the HTLC timelock is allocated to reach the destination and how much is allocated to the destination itself. When it reaches the final destination, it unwraps the onion by one layer, and it might find that it is the final destination or has to use the allocated timelock to forward to the next destination.Each node already has a mapping of nodes to distance counters, so to make a payment to a node, it needs only to find some number of nodes in this mapping. Ideally, it finds two other nodes that are nearer to it than the payee node. A trampoline node might not be able to find the next trampoline, or the payer information may be too stale that the budgeted number of hops for that trampoline hop is insufficient. In those cases, the trampoline node can report back a failure with a distinct failure code. Periodically, a node may want to update the Dijkstra run for itself by re-emitting a new pheromone.With payment point+scalar, onion routing can be made more secure through "path decorrelation" by changing the outgoing PTLC at each hop in the onion route. The constant scalar used for this is secretly shared between the hop and the original payer. Another advantage of trampoline onions is that the payee can provide a pre-encrypted trampoline onion which the payer can prepend its own trampoline nodes to, i.e. hidden destinations. Trampoline onions have several advantages, such as fewer channels needing to be published offchain, making it harder to map out the full network. However, there are also disadvantages to trampoline onions, such as the possibility of censorship attacks and the need for consistent feerate and CLTV-delta at each node.
Updated on: 2023-06-02T23:41:30.481647+00:00