Eclair 0.2-alpha1 is out

TL;DR The Lightning Network is doing great, today we proved it by releasing a working implementation of its on-going specification.


Today we are releasing an early version of Eclair, the first implementation to achieve compliance with the Lightning Network Specifications. If you are a developer, we encourage you to test it out! We will publish a short video tutorial later this week.

OK, great, but what does it mean for me, the average non-technical Bitcoin user?

It means a lot, actually! But first, let’s give a brief status on us and the Lightning Network.

At ACINQ, we got interested in LN in the summer of 2015, and started hacking on our own implementation right away. Other implementations appeared around that time, such as: c-lightning, Thunder, and lnd. For about a year, there have been a lot of experimentations and discussions on various aspects of lightning, mainly occuring on the lighting-dev mailing list. For example, we got some press coverage last september for publishing test results of a routing prototype. This was all fine, but there was no clear way forward and implementations were not compatible.

A few months ago, at the last Scaling Bitcoin conference in Milan, implementers from different teams around the world sat together and agreed that interoperability was the key to obtain a single, valuable, global Lightning Network. That’s when we all started working on a specification for the Lightning Network (a.k.a the BOLTs). Since then we’ve had biweekly conference calls, and we are making rapid progress towards BOLT v1.0. Being a part of this joined effort has been incredibly exciting and challenging at the same time! Despite what is at stake, this collaboration happens in a constructive and friendly atmosphere, as Rusty Russell pointed out in a recent blog post.


What our release shows today is that this initiative works! The BOLTs already cover everything that is needed to create a simple yet functional network, and we proved that they could be successfully implemented. At least 3 other projects (c-lightning, lit, lnd) are actively working towards the same goal. We have even started interoperability tests with c-lighting! Others, like Thunder, have stated that they will consider implementing the spec once it is stable.

What’s the point of having so many implementations of LN? Wouldn’t you go faster if everybody worked on the same code base?

The first thing to have in mind is that LN is fundamentally different from Bitcoin, in that it is not driven by consensus. While trying to reproduce the exact behaviour (bugs included) of a consensus-based software can prove hazardous, in general, more diversity means more security.

Having multiple implementations of the spec greatly improves the quality of the spec itself, because you have multiple independent teams that will stumble upon each imprecision, ambiguous statements, and will generally review it extremely thoroughly. This will ensure that the specification is easy to implement and will facilitate the work of all future implementors (e.g. working on higher level software such as wallets), thus helping the network grow faster.

It also greatly improves the quality of the implementations via interoperability testing, which is a great way to find bugs. For example, re-implementing secp256k1 is how a bug was found in the openssl crypto library by Bitcoin Core developers.

So, what’s special about Eclair?

Our goal is to build a cross-platform, full implementation of a lightning node. Eclair actually shares some similarities with Bitcoin Core: it has an optional GUI, a not-so-different look-and-feel, a JSON-RPC api…

It is built in Akka/Scala, a modern, concurrent language running on the JVM, thus benefiting from a rich ecosystem of tools and libraries.

Eclair already has a decent test coverage with hundreds of unit and integration tests, though it is still far from the production-ready quality we want to achieve. But we are getting there!


Next steps

The immediate goal is to finalize the spec and achieve compatibility with other implementations. We are committed to do our best in that regard, in collaboration with the other teams.

We are also currently working on an explorer for the Lightning Network, that we will release on testnet shortly after that.

Screenshot of LN explorer

We also plan to develop a LN “watcher”, a thirdparty service that LN wallets can use to monitor the blockchain on their behalf without giving up on privacy, an idea originally proposed by Tadge Dryja.