Lightning Network Interoperability Initiative

Welcome to the repository for the Lightning Network Interoperability Initiative. This is the repository we use to organise our work. Please refer to our charter as well as our github pages website for more information on our goals and current scope.

Current status

The following table lists of the stages of an initiative, along with links to the artifacts that will be produced by the start of that stage.

Key:

• ✅ -- phase complete
• 🦀 -- phase in progress
• 💤 -- phase not started yet

How Can I Get Involved?

If you'd like to participate be sure to check out any of our open issues on this repository, or open a discussion on github.

Building Documentation

This repository is also an mdbook project. You can view and build it using the following command.

make

Lightning Network Interoperability Initiative Charter

Goals

This working group exists to ensure that Lightning Network implementations are compliant with the protocol and are interoperable between different implementations.

Up to this point, the Lightning Network has been tested based on real-world experiences, aside from the integration testing that each implementation includes within its own codebase.

While tests like these are essential—because there are scenarios that can only be discovered when testing on the Bitcoin network, such as a "Fee Spike"—there are numerous cases where potential issues could be identified before deploying an implementation in a real-world setting.

An example of this is the recent splicing issues https://github.com/ElementsProject/lightning/issues/6500 between CLN and Eclair.

The primary objective of this working group is to develop testing tools that are language-agnostic and can facilitate the following types of integration tests:

• Vertical Integration Testing: An implementation must be tested alongside other implementations.
• Horizontal Integration Testing: An implementation must be tested with a protocol testing framework to ensure that the specification is clear and that the implementation adheres to the specification correctly. An example of this is the following PR on CLN https://github.com/ElementsProject/lightning/pull/6384 were lnprototest was able to hit an edge case and allow core lightning to accept invalid signature during the announcement_signatures
• Self Integration Testing: An implementation must be tested for compliance with its own standards (note: most major implementations are currently doing this).

Membership

Experiment Planning and Results

At present, efforts are being made to conduct experiments to implement and run the types of integration testing described in the GOAL document.

Experiments with Vertical Integration Testing

This type of test defines a method to test a single implementation against a protocol testing framework. Currently, there is an implementation of this test known as lnprototest, which is used in both the core lightning CI and the lampo (LDK based client) implementation.

Using lnprototest, it's possible to run tests that trigger parts of the codebase that cannot be accessed with self integration testing or horizontal integration testing. (TODO: add the link to my PR on core lightning). It also simplifies the process of implementing new features in an implementation by writing an integration test with lnprototest.

Implementation

At the moment, lnprototest is implemented in Python and primarily serves as a runner capable of communicating using the Lightning Network protocol over a socket.

Therefore, any implementation wishing to support lnprototest should create a simple Python runner for the implementation itself. Subsequently, they can utilize the lnprototest utilities to craft an integration test.

For further details on how to implement a lnprototest test, please refer to the latest lnprototest documentation.

Challenge

While lnprototest requires a simple runner to be implemented for each implementation, it would be highly beneficial to develop a minimal common API across all implementations. This would facilitate easier integration within the framework.

Moreover, a standardized (minimal) API could enable the creation of integration frameworks similar to pyln-testing from core lightning. This would, in turn, allow for writing integration tests that span multiple implementations.

As an illustrative example, you can find an integration test for an unreleased lightning node (built with LDK) that's tested alongside core lightning here.

Some initial framework is available at https://github.com/laanwj/cln4rust/tree/master/testing