Hi all, Given the recent discussion about the gossip protocol and potential alternatives, we (Florian Tschorsch, Elias Rohrer and I) wanted to inform you about a paper we wrote on the convergence delay of routing information in the Lightning Network. The preprint is available here: https://arxiv.org/abs/2205.12737
As a summary, here is an excerpt from the paper stating our contributions: - We analyze the Lightning Network’s gossip protocol in its current state by looking at and comparing c-lightning and LND, the two most popular node implementations. We measure the delay seen in the real network through a passive experiment and catalog the seen gossip messages (specifically all channel updates) to understand why and when gossip messages are broadcast by nodes. The catalog is also useful to understand which types of channel updates are potentially disruptive to payment routing. - We implemented a simulator capable of simulating the Lightning Network’s gossip protocol as well as payments in the Lightning Network. We can boot- strap our simulation from historical topology data and replay recorded gossip messages. We use the simulation to gain further inside into how the gossip protocol operates and where its inefficiencies lie. - We evaluate the use of alternative message propagation mechanisms in the Lightning Network. Through simulation, we compare flooding, a structured broadcast utilizing the channel graph topology, inventory based gossip, as well as efficient set reconciliation using Minisketch. According to our measurements of the convergence delay, it takes 359.9 seconds on average until a node sees a message after it was broadcast, with 95% of nodes seeing messages after 753 seconds and 100% of nodes seeing messages after 2,500 seconds. An interesting result from dissecting samples of recorded gossip was that ~50% of all channel updates were keep alive updates (i.e. updates that only differ in the timestamp). Reducing the number of keep alives could have multiple benefits for the network. Besides reducing the bandwidth usage for each node we show through simulations that, due to the parameter choices of LND's staggered broadcast, the convergence delay would be smaller if less keep alive updates were broadcast. We were not able to pinpoint exactly why this many keep alive updates are circulating in the network and we are curious if anyone has more insights into this. The following is a list of node IDs that broadcast more than 200 keep alive updates within 10 hours during one of our gossip recordings (30th October 2021). ``` 026db2cbf3d8ab4a4c01eed2df432d20cf0a13136402097574209d2595cb9e9d93 0390b5d4492dc2f5318e5233ab2cebf6d48914881a33ef6a9c6bcdbb433ad986d0 0297a77f4d1ccc55d7a10a9b137119b1103d9a9d38a5a97ffa1d0152c818fcdd0a 03c8dfbf829eaeb0b6dab099d87fdf7f8faceb0c1b935cd243e8c1fb5af71361cf 03e691f81f08c56fa876cc4ef5c9e8b727bd682cf35605be25d48607a802526053 0260fab633066ed7b1d9b9b8a0fac87e1579d1709e874d28a0d171a1f5c43bb877 0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 03f3297397c8f5f685a562847611e20d15f56d6aaabc4d808a6e04e631dea6e612 02c43a8c5dd024c4d3c5be5612347f87cf90d79e5c2417861908d25f72046354c3 023d70f2f76d283c6c4e58109ee3a2816eb9d8feb40b23d62469060a2b2867b77f 033d8656219478701227199cbd6f670335c8d408a92ae88b962c49d4dc0e83e025 03ea08d787c0153d42f0aa286a1b7000de17d959771e059aadc1cf85d5f2a67e35 02315fe3619ffdea2561bcacecada87b226723f471a59fdbfec18c4e84bcf785b2 0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3 03c2abfa93eacec04721c019644584424aab2ba4dff3ac9bdab4e9c97007491dda 03a503d8e30f2ff407096d235b5db63b4fcf3f89a653acb6f43d3fc492a7674019 ``` If you operate one of these nodes, we would be interested to here about your set up. (What implementation are you running? Are you using any automated fee adjusters?) If results like these are interesting to you, then you might want to give the whole a paper a read. We would be thrilled to hear your thoughts/feedback. Best regards, Niklas Gögge _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
