Route finding and route generation



Summary:

The email introduces a proposal for a new protocol to replace the flood-the-network style routing currently in use in the lightning network. The proposed protocol involves each node knowing about its own local network topology and sending queries for routes to the intended destination instead of receiving or storing the entire network topology. This approach makes route discovery less taxing on the network in terms of bandwidth and storage space.When a node joins the network, it broadcasts its information and requests local network topology information from all its channels for information about channels 1 hop beyond, then requests topology information for channels 2 hops beyond until it has filled its cache to its satisfaction. When a node receives an announcement message from a node joining the network, it will store that node's info in its cache and forward that info to any node that's subscribed to topology changes that fall within the relevant distance.When a node wants to construct a route for a transaction, it checks to see if it has a path to that node in its cache, finds the cost of the cheapest path it has, asks all the channels on the edge of its cached local view for their cheapest path, and constructs a path when it gets all the responses. When a node receives a path request from a node, it checks its cache for its cheapest cache-only path, asks nodes on the edge of its cached local view for their cheapest path, and reports the results that satisfy the max-cost requirements of the requesting node.Laolu, a co-author of the Flare paper, has responded to the proposed protocol using a technical mailing list. Although this mailing list may have a strange structure initially, it is a great venue to discuss matters such as routing protocols and solutions for the Bitcoin development community. However, due to the mainnet release of various lightning node software, the mailing list traffic has been lower than usual recently, so replies may take some time.Laolu explains that the proposed protocol is essentially Dynamic Source Routing (DSR) with a mix of components from Fisheye State Routing (FSR), making it a hybrid protocol that combines reactive and proactive elements to achieve its goals. The current stop-gap is a pure proactive protocol, meaning that nodes gather all link state data and make forwarding and routing decisions based on that information. This incurs a clear trade-off in the increase in table state and bandwidth required to keep up with announcements. However, having complete information allows for more intelligent pathfinding decisions while ensuring collection of redundant sets of routes for each payment. This ensures that there are multiple options to fall back to if earlier routes in the set fail.Laolu stresses that asking nodes for a path to a destination defeats the purpose of using onion routing and suggests exploring more scalable routing protocols like distance vector-based algorithms instead. In conclusion, Laolu believes that the system's layout allows for multiple heterogeneous routing protocols to be used within the network, similar to the Internet's eBGP vs iBGP, allowing different sub-graphs to choose protocols that best suit their goals in light of the tradeoffs.Overall, the proposed protocol keeps both node-announcement messages and route request messages highly localized, which can help reduce the burden on the network and improve efficiency.


Updated on: 2023-05-19T16:03:02.295413+00:00