Thanks for this write-up! I was interested in ark when the protocol was proposed and started to be implemented to understand the interaction between lightning and how it is possible to use it to solve lightning problems.
I like to define ark as a technique, and not as a layer, just because it fits very well in many use cases, and we may not need to classify ark in a category, but just use the underlying technique to fix some problems that we are having and in this case with lightning scalability.
So I will add my considerations that I had when I presented a PoC of an ark channel factory in Prague last year with an LDK full node implementation (See the draft PR in Macros/custom txs by vincenzopalazzo · Pull Request #452 · vincenzopalazzo/lampo.rs · GitHub)
I will try to add the design decisions that I was thinking about while implementing it regarding some of your points.
>Interoperability and routing abstractions
My idea on how to use the ark channel factory on today’s model is more like implementing a phoenix model LSP, where the mobile is having a channel with one of the LSPs. Here there is an assumption that the LSP for the lightning node is also an Ark operator, but in the big picture, I think this assumption can be removed.
At the implementation level, if today you want to implement this, it is already possible because mobile + LSP are already 0 conf channels, so you can just assume this is a confirmed channel for the ark channel.
Then, due to the ark has a liveness “issue” that requires the mobile wallet to be online at some point to refresh the vtxo, you can use this time to “refresh” the channel by basically closing and opening a new channel or splicing (depending on how complicated you want to make the mobile wallet + LSP relationship).
Consideration at the lightning script level.
At the script level as of today, we can already implement it somehow by just having some extra path for every script (I need to double check this with the unilateral exit) and here is an unreviewed funding transaction lampo.rs/lampo-ark-wallet/src/lib.rs at 63027fea90e7292d32a4e5c9465848b06339aa38 · vincenzopalazzo/lampo.rs · GitHub example
The general idea is that for every lightning script you will have two cases:
<lightning script> + ASP signature<lightning script> + timeout for the ark unilateral exit
I also considered the case where a public channel that impacts the public network will be based on an Ark channel factory, and with my current understanding of the Ark protocol, I think it will create overcomplicated stuff at the gossip level & interconnection between lightning nodes that have channels with different ASPs, but I can be wrong. It has been a while since I thought about this problem, so I probably need too refresh my mind on this last consideration.