The Lightning protocol works by atomically updating funds throughout a number of cost channels in such a method that every little thing confirms or fails all collectively — i.e., it routes funds throughout a number of hops. An integral a part of any routing-based system is a routing desk, a set of all the data vital to truly assemble a path from level A to level B. With out this data, you possibly can’t actually route something anyplace since you don’t know get the data from the place it’s to the place you need it to go. Lightning clearly requires a routing desk, which is what the gossip protocol laid out in BOLT 7 accomplishes; the propagation and upkeep of the file of channels obtainable on the community to route funds by means of.
This gossip protocol is without doubt one of the scaling considerations of your complete Lightning protocol stack. Presently, it is extremely primary and works in a method that’s fairly much like the propagation of transactions on the Bitcoin community correct; nodes on the community obtain a gossip message, they then confirm the message in response to the principles of validity, and go it on to all of their friends to additional propagate throughout the community. It’s a naive flood fill protocol that assumes that legitimate messages will ultimately propagate throughout your complete community.
Due to this, there’s a concern of denial-of-service assaults (spam) that can wind up consuming a considerable amount of processing sources and bandwidth to cope with. Within the case of the principle Bitcoin community, nodes is not going to relay invalid transactions, so to broadcast one thing that consumes nodes’ bandwidth and computational sources requires you to truly have bitcoin to create a transaction with. Within the case of the Lightning gossip protocol, you might be required to show you management a legitimate UTXO funding a channel so as to relay a gossip message in regards to the channel. This performs the identical spam safety perform as on the principle Bitcoin community; you can’t spam messages throughout the community with out truly controlling bitcoin.
This brings me to the precise construction of the gossip protocol. This can on no account be a complete breakdown of the protocol, however a deep sufficient look into it to take a look at a proposed change and assess the trade-offs between the proposal and present protocol. There are three foremost messages at present within the gossip protocol. The channel_announcement message, node_announcement message and channel_update message. There’s additionally an announcement_signatures message, however that is solely used with direct channel friends to signal messages asserting channels, and it’s not broadly broadcast throughout your complete community. I’m not going to cowl the messages for requesting knowledge, as they don’t seem to be actually related to the purpose of this text.
The channel_announcement message is the very first thing required so as to announce a channel to the community after which to announce your node to the general public as effectively. It’s collaboratively constructed and requires each channel companions to make and broadcast. This message consists of proof that the funding transaction to a channel pays into the channel multisig tackle, after which it consists of signatures from the Lightning node id key of each contributors over the message. It declares which multisig secret is owned by which node and consists of signatures from every multisig key of the on-chain UTXO funding the channel. This proves that each nodes concerned in a channel have management of the on-chain multisig, after which it proves that their Lightning node id secret is related to it.
Subsequent up is the node_announcement message. If a node makes an attempt to relay this message with out having beforehand despatched a channel_announcement message for a legitimate channel, it’s ignored and never relayed. Nodes relay this message by themselves after opening their first public channel to permit different nodes to connect with them. This message incorporates a signature from the node id key on the message; some characteristic bits for future model updates, the community tackle the node could be reached at to open channels with, an alias (nickname) and some different bits of information.
Lastly, the channel_update message. This message can be made and broadcast unilaterally by a single node. It incorporates the minimal and most worth hashed timelock contracts (HTLCs) a channel will route; the price that the operator will cost for routing by means of that channel (base price and proportion price price); and the size of timelock distinction it requires between itself and the earlier hop, in order that it has time to discover a transaction settling on-chain and implement the right end result for itself if vital. It’s also signed like all different messages.
So the protocol as it’s now gives all the data vital to search out channels you possibly can route funds by means of, promote the data essential to know what charges every channel will cost, and gives a denial-of-service safety mechanism to stop the Lightning Community from being spammed all day with nonsense ads of channels that don’t exist by requiring signatures from the keys holding the funding UTXO on-chain.
However it has one main drawback: a complete lack of privateness. With a purpose to promote your channel on the community for folks to route funds by means of, it’s important to dox the precise UTXO used to fund that channel and affiliate it together with your Lightning node’s id key. So what can we do to repair this?
Rusty Russell from Blockstream proposed an up to date model of the gossip protocol in February 2022. It could take the core protocol from three messages down to 2 and drastically enhance the privateness properties as a consequence.
Successfully what would occur is to utterly take away the channel_announcement message and depart the protocol with node_announcement_v2 and a channel_update_v2 message. As a substitute of doxxing every particular person UTXO related to a channel, and requiring a channel_announcement first, the node_announcement_v2 could possibly be finished initially and show management over a UTXO not truly used to fund a channel. The node operator would then be allowed to promote channels reflecting some a number of of that quantity (so say you’ve 1 BTC you proved management over, now you can promote 10 BTC of routing capability), with out having to dox the precise channel UTXOs.
This could be a large privateness enchancment for the community by not requiring every channel to tie itself to a particular on-chain UTXO; chain evaluation corporations would not be capable to simply observe each public node operator’s funds on-chain between channels. The channel_update_v2 message would then take the place of each channel_announcement and channel_update, fulfilling the identical basic goal within the protocol.
In the long run, the thought of a gossip protocol based mostly on flood fill propagation might be not scalable. Flood fill is without doubt one of the most inefficient community designs for propagating data there’s, and it is a drawback that, in the long run, goes to should be optimized and shifted into one other path to actually be scalable for a cost community that hopefully will probably be world in measurement. There isn’t a possible way round that. However one of many largest shortcomings of the present gossip protocol is the evisceration of the privateness of routing node operators. You possibly can’t be a routing node with out publicly tainting your channel UTXOs as tied to you and making it simple to surveil them on-chain.
On condition that one of many largest potential utilities that the Lightning Community may add in addition to the scalability of funds is the privateness of funds, shouldn’t we be addressing the large methods during which the protocol stack falls brief in fulfilling these guarantees of privateness? I believe we should always, and one large option to begin is by enhancing the privateness of node operators who truly play the function of facilitating funds throughout the community within the first place.
