Author: Billy Tetrud 2017-09-04 09:52:55
Published on: 2017-09-04T09:52:55+00:00
The lightning network is a decentralized network for fast and cheap transactions. Billy Tetrud proposed a protocol for route discovery and generation that can replace the basic flood-the-network style route discovery, but isn't so complicated that it needs a ton of study and work. In his protocol, each node knows about its own local network topology, and to find a final route, a transaction originator queries a number of its connections for routes to the intended destination. This means that nodes are not receiving or storing the entire network topology, which makes route discovery a lot less taxing on the network (in terms of bandwidth and storage space). When a node joins the network, it broadcasts its information to all its channels, announcing its relevant channel information. It requests local network topology information from all its channels for information about channels 1 hop beyond its direct connection (ie it will receive information about which addresses those channels are connected to, and their related fee info / etc). It then requests topology information for channels 2 hops beyond, etc until it has filled its cache to its satisfaction (the user can choose some amount of megabytes as its limit of network topology data to store). It also subscribes to topology changes for nodes at those distances (eg if a node has requested information from 3 hops away, it will receive info about any new channels or removed channels that fall within that distance).When a node receives an announcement message from a node joining the network, it will store that node's info in its cache and it will also 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. If it does, it finds the cost of the cheapest path it has. It asks all the channels on the edge of its cached local view for their cheapest path (however you want to define cheapest), specifying that it only cares about paths with a maximum cost of the cheapest path it has already found in its cache. When a node receives a path request from a node, it checks its cache for its cheapest cache-only path and asks nodes on the edge of its cached local view for their cheapest path, specifying that it only cares about paths with a maximum cost of either its cheapest cache-only path or the max-cost specified by the requesting node minus the channel cost between it and the requesting node (whichever is cheaper). A node on the edge of its cached local view is not asked for route information if the cost to that node exceeds the max-cost this relay node would specify. All the route information can be encrypted and signed so relaying nodes can't read the information inside, and so the requesting source node can verify which nodes sent that information.The protocol should keep both node-announcement messages and route request messages highly localized. Johan Torås Halseth commented on the proposal, saying that if every node within 3 hops is kept in the local topology, most of the network will end up being stored anyway. Therefore, he suggested that the routing algorithms will be easier to optimize and analyze after some real-world data.
Updated on: 2023-05-24T02:35:11.456954+00:00