The proposal targets a hybrid routing protocol as the basis of the scheme.
Nodes proactively gather and update a routing table whose horizon extends fully into a "neighborhood" radius consisting of all nodes within a low hop distance from the source node. Within the paper we analyze the radius of 3-5 nodes.
Within this radius a node has fully visibility of the network topology, and receives updates concerning channel openings/closures. This local radius serves as a well-lit home base which the source node uses to further bootstrap network visibility farther away.
The concept of a "beacon" node is introduced. Beacon nodes are essentially routing landmarks randomly chosen for a particular node via a virtual distance metric similar to Kademelia.
The virtual distance between two nodes is the XOR of their lightning ID's, which we model as being 256-bits.
Using a node's initial neighbor radius, the source node then executes a "beacon search" where it seeks to extend its illuminate portion of the network, seeking nodes with a close virtual distance to itself.
This search is performed iteratively, using HORNET circuits to maintain the privacy of the source node executing the beacon search.
At each iteration, a reachable node is consulted for nodes with a close distance to the source node. These nodes are then selected as beacon candidates, continuing till the parameterized number of beacon nodes have been discovered.
The beacon search is part of the initial setup a node goes through when it joins the network. Afterwards is proactively performs maintenance on its routing table as it receives updates from its local neighborhood.
The reactive component is executed once a node wishes to send a payment within the network. As we envision very high velocity payments, fee schedules aren't propagated through the network. This allows individual nodes to update their fees dynamically without requiring network-wide synchronization.
Entering the reactive phase, a node establishes a HORNET circuit with several possible paths to the destination. During the circuit initialization fee information is gathered from the intermediate nodes, using a slight modification to HORNET's forwarding segments (FS). The circuit set up is executed in parallel.
Once set up is complete, the source node performs local ranking of the gathered routes with the up to date fee information, selecting an "optimal route".
The established HORNET circuit with the destination can also be used to transfer additional payment meta-data (more R values, etc) between the sender and receiver.
The beacon nodes are leveraged once again in the case that the sender cannot initially find a route to the receiver. The sender can ask the receiver for a dump of their visibility within the network. If this is sufficient then the reactive phase circuit establishment is then entered. Otherwise, the sender then extends its view of the network using the receiver's address, performing an iterative DFS looking for node with a close distance to the receiver. Once/if an intersection is found, everything proceeds as normal. If the receiver doesn't wish to share their routing table, the send can still perform the beacon search extension non-interactively.
The distance metric of the bacon nodes can also be used to facilitate rendezvous routing. The receiver picks a node within its view of the network (possibly at the edge), then sends this to the sender. The sender can then use the distance metric to locate the rendezvous node, establish a hornet circuit, and use the nested header given to her by the receiver to complete the route.
Finally another major component of the scheme is "path authentication". All link-layer channel advertisements must carry a valid proof of existence. The proof scheme uses a combination of an SPV proof showing inclusion of the funding transaction, along with an aggregate EC Schnorr signature which binds+authenticates the public keys used in the multi-sig, and the public keys of the nodes within the lightning network.
::