Published on: 2018-10-12T08:58:41+00:00
In a discussion between ZmnSCPxj and Fabrice, they explore the idea of reducing synchronization issues in Lightning Network by utilizing set reconciliation algorithms. They suggest incorporating the timestamp and enable/disable state of channel updates as part of an item, enabling the use of standard set reconciliation algorithms. For channel updates with the same short channel ID, all items except the one with the latest timestamp can be dropped. While this approach may be less efficient than Zmn's proposed extension, Fabrice believes it offers a natural solution to handle sync problems.Fabrice expresses concern about potentially overlooking something in the current channel queries. He proposes a solution that builds upon the existing "channel queries" to address outdated channel updates in Lightning Network. By extending query parameters to include channel update timestamps, nodes can request a list of [channel id | channel update timestamp #1 | channel update timestamp #2] within a specific block range when connecting to another node. This allows offline nodes to determine their synchronization progress and display a "sync progress" indicator as they receive requested items. Fabrice has opened an issue on the RFC's Github repository and initiated a forum discussion to gather feedback on his proposal.ZmnSCPxj responds to Fabrice via email, offering a potential solution to the set reconciliation problem. While Fabrice had initially focused on missing updates for existing items, ZmnSCPxj suggests considering the timestamp and enable/disable state of channel updates to reduce the problem to a set reconciliation scenario. This would enable both sides to employ standard set reconciliation algorithms, discarding all items except the one with the latest timestamp for channel updates sharing the same short channel ID. ZmnSCPxj acknowledges that this solution might be less efficient than Fabrice's proposed extension.Lightning Network functions as a peer-to-peer network of nodes, with nodes acting as vertices and channels as edges. Payments can be made to any node through a route determined by the local routing table. To send a payment, nodes utilize their routing table to compute a route and send an onion-like message to the initial node on that route, which forwards it to subsequent nodes until reaching the destination. The routing table contains static information such as channel announcements and dynamic information like channel updates, which can frequently change. Maintaining an up-to-date routing table, known as "routing table sync" or "routing sync," is crucial for the proper functioning of Lightning Network wallets primarily used for payments. Offline nodes face challenges in syncing their channel updates accurately, leading to outdated information. Current schemes involve requesting peers to provide a complete dump of their routing table or querying for specific channel IDs within a block range. However, these schemes still encounter issues with offline nodes.Fabrice's proposed timestamp-based channel update sync scheme aims to extend query parameters by including channel update timestamps. When a node establishes a connection with another node, it requests a list of [channel id | channel update timestamp #1 | channel update timestamp #2] within a given block range. This enables offline nodes to determine their synchronization progress and display a "sync progress" indicator as they receive the requested items. Positive results have been obtained through testing this scheme on a mobile wallet.
Updated on: 2023-07-31T20:29:21.677964+00:00