[ad_1]
Ark is the third major Layer 2 protocol with some form of unilateral exit or enforcement mechanism on the base layer to approach the point of launching on Bitcoin. Lightning came first when C-Lightning went live in the Reckless campaign in 2018, Statechains in 2021 when Mercury Wallet went live, and now Ark Lab’s coming Arkade wallet implementation of clArk (covenantless Ark) is approaching the same goal line.
clArk has some shortcomings compared to a full Ark implementation, namely the requirement in a trustless version for every user inside of an individual Ark to collaboratively sign the exit transactions in a massive n-of-n multisig when it is created. If we had CTV or another equivalent covenant, users would not need to participate in an interactive signing process, and the Ark Service Provider (ASP) could simply create the Ark using a covenant and users could be sure they have total control of their funds after it is confirmed.
Ark presents an interesting trade off in comparison with the Lightning Network, both require participants to have excess liquidity in order to receive payments. In the case of Lightning however, it is a complicated game of individual users having to figure out where to allocate their own liquidity and how to source liquidity from others in order to functionally send and receive. It is an individual problem that each user is left alone to solve. With Ark, any ASP can freely assign some of its liquidity to any of its users. They still need to solve the problem of sourcing it, but there is no longer the per-user problem of deciding whether it is worth it to allocate liquidity in that direction, it can simply be done in the moment as any individual user needs it out of a common liquidity pot.
There is still a problem with Ark’s liquidity issue though. For every payment floating on an Ark that hasn’t been closed yet, the ASP must front liquidity for those payments to allow users to receive them into a new Ark. When the ASP gets to a point where it is running out of liquidity, its fees must necessarily start skyrocketing in order to manage that issue until they are able to reclaim locked up liquidity by closing Arks.
I think a way to address this tail curve of higher fees could be to explore some lessons from Lightning, namely a routable topology. This would be incredibly simple compared to Lightning. Lightning requires mapping and routing through liquidity paths established between pairs of individual users, whereas with Ark it is simply ASP to ASP.
An ASP experiencing a liquidity crunch could “punt” payments from their own Arks to another ASP with more liquidity available, establishing the ATLC linkage between their own Ark the payment is originating from to another ASP’s Ark to be received, saving users fees. In turn as they are able to claw back liquidity as they close existing Arks and their own fees come down, other ASPs then experiencing a liquidity crunch could “return the favor” by punting payments back in their direction.
This could establish a sort of round robin and easily analyzable “I scratch your back, you scratch mine” dynamic between ASPs, that while leaving some revenue on the table during high fee liquidity crunches, would overall create a more predictable and affordable experience for their users.
This does come with the risk that payments across ASPs like this essentially interlink Arks across different ASPs, meaning non-cooperative closes would necessitate the closure of Arks operated by multiple entities, but given that cooperative closes depend on user behavior I don’t think this fundamentally changes the risk profile absent ASPs intentionally griefing each other. This could be viewed as analogous to the channel jamming problem of Lightning though.
There are some upsides, and potential downsides, but I think this is a concept that is worth exploring in terms of ameliorating Ark’s liquidity crunch issue.
[ad_2]
Source link
