Announcing NLoop: Generic Lightning Loop
NLoop is a daemon for managing the LN channel liquidity by Submarine Swap.
What does it do?
In a nutshell, Submarine Swap is a protocol to exchange an off-chain asset deposited in a Lightning Network channel for an on-chain asset (UTXO) on the blockchain.
If you want to know more, see for example the following document.
Why did we create it?
1. because the existing software (Lightning Loop) had some shortcomings
There is already a software called Lightning Loop to manage the state of LN channels by Submarine Swap.
However, there were some things that we did not like about using this software for our usecases.
a. No support for non-BTC swaps
One of the goals of Submarine Swap is to minimize the number of channel openings and closings due to channel liquidity depletion.
This is partly for ease of management by keeping the state of the channel constant, but also to keep the expense of minor fees for on-chain transactions low.
However, the Lightning-BTC to on-chain-BTC swap does not reduce the on-chain fees, pretty much, because afterall you must pay an on-chain tx fee for a swap tx.
Unlike Loop, NLoop also supports BTC to LTC swaps, so you can reduce your expenses by using Litecoin, which usually has lower fees than the BTC.
And possibly other tokens such as Liquid-BTC or Dogecoin or whatever in the future.
b. Limited number of swap partners
With Lightning Loop, you can only swap with servers operated by Lightning Labs. And their software is closed source.
I think this is a non-negotiable point in their business model, but users may suffer from the following disadvantages due to lack of choice
- Lightninglabs may close the channel for their own sake (e.g. in order to get inbound capacity.)
- There is no alternative when their swap fee is expensive. And switching cost is high.
- The server side is closed source, so the possibility of being liquidity provider (i.e. an entity which provides the swap service to someone else) is not opened.
2. Because the alternative (Boltz) did have shortcomings too
With the above problems with Loop, we looked for other options and found boltz-backend software/service.
The development was reasonably well done, and the license was AGPL, which is a FOSS license, so I looked into the possibility of using it, and found a client called boltz-lnd, which was developed by the same people.
But I was not satisfied with the following points.
a. Insufficient validation of the server side behavior.
In general, applications that deal with cryptographic assets need to be built with a lot of care in order to be trustless.
In addition to cases where the other party returns a response that violates the protocol, there are also cases where the other party "returns information that does not violate the protocol but is advantageous to them", which need to be comprehensively validated. For example, there might be a discrepancy between what the other party tells you when you first query the fee for execution and what they actually send you as an invoice.
In such cases, you need to consider more things than you would normally expect. For example, if the amount of money they are asking for is within your expectations, but the channel you have with them is such that they charge a very large routing fee, you may lose a lot of money without realizing it.
We were concerned about the validation-comprehensiveness of boltz-lnd. Partly because it was created by the same party as the server side.
Ideally these kind of software should created by different entity, so that there is less implicit premise about how counterparty behaves.
We also needed to be able to specify a maximum fee that we wanted to pay in advance, and not perform a swap if the other party requested a higher fee. This is necessary to realize Autoloop feature as described later.
b. Dealing with edge cases
For boltz developers, boltz-server is more important than boltz-lnd, so more development resources are devoted to it (IMO).
Therefore, there were concerns about the behavior in edgecases such as when the blockchain reorged or when the server was restarted during swap.
c. Lack of necessary functions
Lightning Loop has a feature called Autoloop that will automatically continue to swap, but boltz-lnd does not have this feature.
We thought about modifying boltz-lnd or creating another daemon to monitor boltz-lnd, but since we wanted to have a function to validate the fee mentioned above and to calculate the cost of swapping, we rejected this idea because it would be easier to create it from scratch.
d. Tight coupling with server side
Related to "a. insufficient validation of server-side behavior" mentioned above, boltz-lnd is designed to work only with boltz-server. So for example, it relies on boltz-server's REST interface to tell what stage the swap is in.
In the future, we would like to be able to work with other servers besides boltz-backend (e.g., lightning loop servers), so we had to remove this dependency.
3. to experiment with secure/high-availability architecture
Applications that deal with cryptocurrency often have the following specific requirements.
To deal with these requirements, NLoop is created with Event Sourcing Pattern. It is based on asp.net core, F#, Giraffe
a. We want to prepare and ensure the audit.
One of the most common requirements in financial applications is the need to check everything that has happened in the past.
For this reason, it is important to keep a log of the operations to the DB.
It is even better if such audit logs cannot be easily changed even by the person running the application.
In the case of financial applications, it is necessary to take into account the possibility of an insider committing a crime. (See for example the following document)
An Event Sourcing System can easily handle this kind of requirement, since we can treat changes to the application itself as a immutable log.
This method is also more suitable in terms of optimizing the costs associated with channel management by monitoring the increase/decrease of assets involved.
b. Avoiding discrepancies between event publishing and the actual application state
There are cases where an application wants to change its state and notify another service at the same time, but only one of the two occurs due to a temporary communication glitch.
This is an edge case, but in the case of financial services, the discrepancy is often fatal, so it is necessary to deal with it using a transactional outbox pattern.
In the case of Submarine Swap, for example, if a downstream service fails to detect the occurrence of a swap, something unpredicatble may happen.
The Event Sourcing System makes it easier to deal with this problem.
c. Don't want to rely on block explorer
In general, most applications that monitor blockchains use Block explorer, which is a microservice for monitoring purposes only. (e.g. electrs).
However, in the case of NLoop, since the monitoring is not that complex and we want to reduce the number of dependent applications as much as possible, we skip the block explorer and directly check the block (or block filter).
By adopting the event sourcing architecture, even without the block explorer, the process of reorg is relatively straight forward. (Specifically, we attach a block hash to the event if the event is an on-chain event, and when a block is removed from the active chain, events with the same block hash is removed when re-contructing the state.)
It is also designed to support environments where block explorer cannot be easily used in the future (e.g., smartphone devices).
How can I use it?
If you are interested in using NLoop, you can download it from the official repository and follow the steps to run it with regtest.
The Open API specification (Or its Source) will give you an idea of what you can do.
Notes on use: License
NLoop is currently in open beta. Please use it at your own risk.
NLoop is licensed under the PolyForm Small Business License, which allows individuals and small business owners, There is no restriction to the usage.
For companies above a certain size, there are currently no restrictions for them either, but we may add restrictions in the future.
The current plan is to require them to perform a swap against servers that we run, (like Lightninglabs does for lightning loop).
We believe that this is a fair share for developing/maintening the software. As the trustless-ness is ensured (i.e. users can compile the code by themselves) and it allows users to switch to another option (e.g. Lightning Loop) at any time.
However, it is highly likely that we will change to a more permissive license in the future, since we don't have a server operation in sight. Since it is easier to change a license to a more permissive one than the other way around, we are releasing it under a bit strict license at first.
NLoop is now released under MIT license
Future plans
NLoop's development plan
As future plans, we are planning to add a function to compare multiple servers and swap with the one with the best conditions (including the lightning loop server), and a function to automate rebalance by self-payment.
bitbank.Inc's overall policy
bitbank.IInc. is considering to offer our users the Lightning Deposit and Withdrawal feature from their custodial account.
We also have a plan to offer Lightning-Hub-as a service in the future.
We are currently hiring, so if you are interested in working on Lightning related development, please apply.
