Feedback: Gather feedback on the usage of 'lnprototest' in the implementation

[vincenzopalazzo]

Through this issue, I am seeking feedback from individuals who have attempted to implement a runner using lnprototest within the Lightning framework, despite encountering challenges in the process.

The purpose behind this feedback collection effort is to support our ongoing review of the fundamental building blocks of lnprototest. As part of this review, I am actively soliciting input.

I have designated this issue as a centralized space where implementors who have experimented with incorporating lnprototest can share their insights, dreams, and the specific challenges they encountered during the implementation.

For those interested, you can observe the current design experimentation by following this link: lnprototest Design Experimentation

P.S: rewriting the implementation in Rust is not a viable option at the moment 😄. We will defer this decision until we have refined the framework's design to our satisfaction.

[vincenzopalazzo]

Alright, I’ll start.

Over the past few months, I’ve been studying lnprototest and exploring options for a complete rewrite. Before moving forward, I wanted to analyze what might have gone wrong with the first version.

I believe the library's design is overly complex, with a significant amount of custom code that ideally shouldn’t be maintained by the lnprototest team. Instead, we should aim to leverage better existing tools rather than building tools specifically for lnprototest, as this approach has proven to be problematic.

Architecture Points

The current lnprototest is an event-based system, where we have a list of events: some are "action events," while others are "check events" that perform sanity checks on the actions. However, I started working on some ideas a while back to transition this event-based system to a more procedural approach, similar to

def test_v2_init_is_first_msg(runner: Runner, namespaceoverride: Any) -> None:
    """Tests workflow
    runner --- connect ---> ln node
    runner <-- init ------ ln node
    """
    runner.start()

    conn1 = runner.connect(None, connprivkey="03")
    init_msg = conn1.recv_msg()
    assert (
        init_msg.messagetype.number == 16
    ), f"received not an init msg but: {init_msg.to_str()}"
    conn1.send_msg("init", globalfeatures="", features="")
    runner.stop()

However, this is not enough because we need to modify the messages to be strictly typed and add fields directly to the object, like msg.signature.

To achieve this, the following blockers need to be addressed:

• Implement a code generator, similar to lncodegen, which still needs to be completed—or perhaps @rustyrussell has a better approach?
• Rework the event-based lnprototest to be procedural, as previously described, which might allow us to merge #PR95.

Lightning Proxy

While working on PR95, I had the idea to replace our current Python proxy with a better-maintained tool for managing Lightning connections.

I started experimenting with a proxy server using an API with LND code. (See my PoC here). This server accepts HTTP requests containing messages to send to the actual node and then returns the responses received from the node under test.

A conceptual overview might look like this:

LNprototest -> send raw message -> bolt8 encryption from proxy server -> send  -> CLN|LDK
LNprototest <- send raw message <- bolt8 decryption from proxy server <- response <- CLN|LDK

However this is still under PoC so no idea if this is a good idea or not