After my second attempt at running Lightning Network node went wrong, mainly due to my own mistake and bad cli interface of LND, I have decided to look deeply into the alternative implementation of the lightning node software. Eclair was more final choice driven by multiple reasons that I am planning to further talk about in this write-up. The main reason I even considered Eclair despite my dislike of Java and JVM, was that one of the largest lightning nodes on the network is ACINQ, and they are the company behind the implementation and maintenance of this open source software.
I’ve noticed them first after reading their blog about how they run $100M Lightning node and what level of care and thought they put into the whole implementation. Lightning is used to transfer large quantities of value across the internet, and I would only trust something well designed and actively maintained by the people who have to lose the most if they make a wrong choice.
Eclair in itself is not a complex implementation of the lightning network standards, and highly modular, which allows for an easy segregation of duties among different components of the node. One of the biggest sales-points for me was their approach of crash-only software which guarantees consistency of the state regardless of what happens with the running software. By that extension, to shutdown the node, you simply kill the process and start it again. It doesn’t matter what transactions were in-flight, or what stage they were in. This is huge, since anything can happen to a running node (e.g., failed disk, failed RAM, CPU, kernel panic, etc.)
Getting back to the architecture, the Eclair is simple and elegant in design and implementation. The node is separated into three main components that comprise the node: eclair-core, eclair-node, eclair-front. All of the entities are sandboxed actors (e.g., peer, channel, payment), which allows for scalabilities across CPUs and faults. This ensures high availability and security.
Clustering is also an option and can be achieved by migrating from the single node to a multi-server node. There is no need to dive into complexities of that, and by the time you need to scale, I am sure you’ll be able to figure it out.
Simple and robust API, is yet another major reason that keeps the node simple and fast. One downside of the API, is that it is protected by a single password and is not designed for RBAC (Role Based Access Control). One solution could be an implementation of another API wrapper that would implement things similar to Runes or Macaroons, which should not be a challenge considering the REST API simplicity.
On-the-fly HTLC max size adjustment, which will prevent your node accepting forwarded payments that would fail due to lack of liquidity on your side. This also makes routing better for the rest of the lightning network, but may “leak” your channel balances if not done right.
Experimentation and adjustment of path-finding algorithm. I am not there yet myself, but I see this as a great option in the future if I need it. This will allow me to make my own choices how I want to route payments and what parameters I would use to determine the best path.
Full production support of PostgreSQL server. Not only Eclair itself is not a beta release unlike LND, but also has full production support of the very reliable and battle tested database as its backend data storage. You are able to(and should) to run Active/Passive PostgreSQL cluster in synchronous mode, and ensure that all of the written data by the node are backed-up in real-time. This removes the worry of corrupted database that I have seen happen all too often.
Excellent monitoring and metrics, that can be collected by Prometheus and viewed in Grafana. Eclair provides template dashboards that you can import into Grafana to make your life easier. You can also use Kamon (external service) where you could send the metrics and monitor your node.
Support for all common networking protocols and support Socks5.
Last, but not least, support for plug-ins. Even if you are not well versed in writing plug-ins, you could take some of the available ones and modify them to your liking.
There are many more features and limitations that I didn’t mention, but you can explore them yourself here.
One down-side that you should consider, is not such a great availability of the readily available tools. So far I found that Ride-The-Lightning works well; LNBits works but I am yet to see if it is reliable; BTCPayServer has support but I have failed to use it with API directly, and only was able to use it via LNBits.
Lightning is still reckless, but nothing stops you from doing it carefully and reliably. Good luck and happy node-running! 🐶🐾🫡⚡️
My Node - RAϟKO