RGB Lightning Node
#205
Replies: 1 comment
-
|
The work on the lightning implementation for RGB is going for four years already, and today we have fully-working node based on LDK, created by Bitfinex team, and two ongoing projects with CLN RGB plugin and new lightning node developed from scratch, called LNP, which is developed by the LNP/BP Association - you can find the GitHub repos in https://github.com/LNP-WG |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We need a special lightning program for the RGB node, I believe a lot of changes and protocol work here, and an RGB-Lightning program eventually will be desired and better provided by RGB-WG, such that we need to open a discussion here to make a consensus to be a standard protocol and go further.
Introduction
Lightning is a BTC channels network over a gossiping network of nodes, and RGB will be more than one channel network over the same gossiping networks. The main difference between RGB-Lightning from BTC-Lightning is the assets, which are bonded in the channels. Because if one of the two counterparties of a channel cheats, he will lose his assets bond in the channel should not always be BTC. Therefore, there is more than one kind of asset in the RGB network, so there will be more than one channel network. For example, a channel network for USDT, and a channel network for EURT, these channel networks are different than each other and also different from than BTC lightning network. However, the channel network is not a real robust network and is more like a channel set, even in BTC, and we need much more discussion on this.
Channel Set
Why do I call the channel network a channel set? Because it is not always a network.
If there are nodes A to F, the channels A-B, B-C, D-E, E-F.
The graph will be following.
Node A can pay the invoice from node C, and node D can pay the invoice from node F. However, node A can not pay the invoice from node F. These are separate channel sets, even if all nodes are running the same code in the same gossipy network.
In reality, people running lightning nodes want to make a channel with a supper node to make sure they can pay everybody's invoice.
A - B - C \ | / S / | \ D - E - FHowever, the supper node becomes a single point of the network, once it is not available, node A still can not pay to node F.
This is the same issue in RGB channel networks or channel sets if we use the same architecture.
Gossiping Network / L2 network
In BTC-Lightning networks, there is only one asset over one gossiping network, but there will be more than one RGB channel network over the gossiping network. It may be good to have more than one gossiping network because we do not need the assumption every node will serve all kinds of RGB asset channels. So there will be an official announcement for the nodes of the gossiping network for each kind of asset. The easy solution is for the RGB schema owner can do the official announcement. The schema includes the owner's pubkey. The schema owner can sign messages including a list of nodes and timestamps to any node of the network to change or update the initial peers, which also takes the service provider role, of the gossiping network. Every node can verify whether the peer set is based on the schema. Also, the peer network is possibly a private L2 network not welcome for anyone to join, this property also can be defined in the schema.
Initial Peers / Service Provider
The initial peers for the L2 network are more like service providers of the network, or banks in the traditional meaning. There will be more than one possible government way of these service providers. The common and easier way is a federal between different parties. Then each individual can have a free choice to under one of the service providers, just like opening a different account at a different bank. So the payment address will need a service provider pubkey prefix before the user pubkey.
The way the individual interacts with the service provider can be an RGB cli / RGB wallet or another application or mobile app in the future, but it is good that RGB cli provides a standard way to interact with the service provider, so the user can easily have a standard way to keep the channel state.
Swap / Exchange
There is more than one asset network in RGB-Lightning, so swap and exchange will be desired by people. It is reasonable that USDT assets are issued by two different schematas because the type of assets bonded by different periods of national debt in the real world. So it is good to have a standard swap or exchange protocol in the node that runs more than one asset channel.
Why do we need th 8000 ese
Once we handle these as a part of protocol, and make it standard. It will be much easier to let people join the ecosystem, for example, miners prepare some RGB assets and become a service provider to join RGB lightning network to earn profit from liquidity moves in their channels. Such that the nodes in the RGB-Lightning ecosystem will be diverse, decentralize and the network will be more robust.
Beta Was this translation helpful? Give feedback.
All reactions