Ark is the third major Layer 2 protocol with some form of unilateral exit or execution mechanism at the base layer to get closer to the launch point on Bitcoin. Lightning came first when C-Lightning launched in the Reckless campaign in 2018, Statechains in 2021 when Mercury Wallet launched, and now Ark Lab’s upcoming implementation of the Arkade wallet for clArk (covenantless Ark) is approaching the same goal line.
clArk has some shortcomings compared to the full Ark implementation, namely the requirement in an untrusted version for every user within an individual Ark to collaboratively sign checkout transactions in a huge number of n-of-n multisig upon its creation. If we had a CTV or other equivalent charter, users would not need to participate in an interactive signing process, the Ark Service Provider (ASP) could simply create an Ark with a charter and users could be sure that they had full control of their funds afterwards. This has been confirmed.
Ark presents an interesting trade-off compared to the Lightning Network, as both require participants to have excess liquidity in order to receive payments. However, in the case of Lightning, it is a complex game where individual users have to know where to allocate their liquidity and how to obtain liquidity from others in order to send and receive effectively. It is an individual problem that each user leaves to solve on their own. With Ark, any service provider (ASP) can freely allocate some of its liquidity to any of its users. They still need to solve the problem of sourcing it, but it is no longer a problem for each user to decide whether it is worth allocating liquidity in this direction, this can simply be done at the moment as any individual user needs it. From the common liquidity pool.
There is still an issue with Ark’s liquidity problem. For each payment floating on a vessel that has not yet been closed, the Application Service Provider (ASP) must provide liquidity for those payments to allow users to receive them on a new vessel. When an Application Service Provider (ASP) reaches a point where they run out of liquidity, fees must necessarily start rising in order to manage this issue until they can restore the locked-in liquidity by closing Arks.
I think one way to address this high fee tail curve could be to explore some of the lessons learned from Lightning, namely the steerable architecture. This would be incredibly simple compared to Lightning. Lightning requires mapping and routing through liquidity paths created between pairs of individual users, whereas with Ark it’s simply ASP to ASP.
A service provider experiencing a liquidity crisis can “move” payments from its ASP vessel to another service provider with more liquidity available, creating an ATLC link between its own vessel from which the payment originates to another ASP vessel to be received, creating an ATLC link between its own vessel from which the payment originates and Saves user fees. In turn, since they are able to regain liquidity when they close existing Arks and their fees fall, other ASPs experiencing a liquidity crunch can “return the favor” by funneling payments back in their direction.
This could create a sort of easily parsed “I scratch your back, you scratch mine” circular dynamic between ISPs, which, despite leaving some revenue on the table during a high-fee liquidity crisis, would overall create a more rewarding experience. Predictable and affordable for their service providers. Users.
This comes with the risk that cross-ASP payments like this could essentially tie Arks across different ASPs, meaning non-cooperative shutdowns would necessitate shutting down Arks run by multiple entities, but since cooperative shutdowns are based on user behavior, I don’t think This fundamentally changes the risk profile in the absence of providers deliberately annoying each other. This can be considered similar to the channel jamming problem in Lightning.
There are some potential pros and cons, but I think this is a concept worth exploring in terms of improving Ark’s liquidity crunch problem.
Comments are closed, but trackbacks and pingbacks are open.