Ark est le troisième protocole majeur de couche 2 avec une forme de mécanisme de sortie ou d’application unilatérale sur la couche de base pour approcher le point de lancement sur Bitcoin. Lightning est arrivé en premier lorsque C-Lightning a été mis en ligne dans la campagne Reckless en 2018, Statechains en 2021 lorsque Mercury Wallet a été mis en ligne, et maintenant la prochaine implémentation du portefeuille Arkade d’Ark Lab de clArk (covenantless Ark) se rapproche de la même ligne d’objectif.
clArk présente certaines lacunes par rapport à une implémentation complète d’Ark, à savoir l’exigence dans une version sans confiance pour chaque utilisateur à l’intérieur d’un Ark individuel de signer de manière collaborative les transactions de sortie dans un multisig massif n sur n lors de sa création. Si nous avions CTV ou une autre convention équivalente, les utilisateurs n’auraient pas besoin de participer à un processus de signature interactif, et le fournisseur de services Ark (ASP) pourrait simplement créer l’Arche en utilisant une convention et les utilisateurs pourraient être sûrs d’avoir le contrôle total de leurs fonds après. c’est confirmé.
Ark présente un compromis intéressant par rapport au Lightning Network, les deux exigeant que les participants disposent d’un excès de liquidités pour recevoir des paiements. Cependant, dans le cas de Lightning, il s’agit d’un jeu complexe dans lequel les utilisateurs individuels doivent déterminer où allouer leurs propres liquidités et comment obtenir des liquidités auprès d’autrui afin d’envoyer et de recevoir de manière fonctionnelle. Il s’agit d’un problème individuel que chaque utilisateur doit résoudre seul. Avec Ark, tout ASP peut librement attribuer une partie de ses liquidités à n’importe lequel de ses utilisateurs. Ils doivent encore résoudre le problème de l’approvisionnement, mais il n’y a plus de problème pour chaque utilisateur de décider si cela vaut la peine d’allouer des liquidités dans cette direction, cela peut simplement être fait au moment où chaque utilisateur individuel en a besoin. d’une réserve de liquidité commune.
Il existe cependant toujours un problème de liquidité d’Ark. Pour chaque paiement flottant sur une Arche qui n’a pas encore été fermée, l’ASP doit fournir des liquidités pour ces paiements afin de permettre aux utilisateurs de les recevoir dans une nouvelle Arche. Lorsque l’ASP arrive à un point où il manque de liquidités, son les frais doivent nécessairement commencer à monter en flèche afin de gérer ce problème jusqu’à ce qu’ils soient en mesure de récupérer les liquidités bloquées en fermant Arks.
Je pense qu’un moyen de remédier à cette courbe extrême de frais plus élevés pourrait être d’explorer certaines leçons de Lightning, à savoir une topologie routable. Ce serait incroyablement simple par rapport à Lightning. Lightning nécessite une cartographie et un routage via des chemins de liquidité établis entre des paires d’utilisateurs individuels, alors qu’avec Ark, il s’agit simplement d’ASP vers ASP.
Un ASP confronté à une crise de liquidité pourrait « envoyer » les paiements de sa propre Arche vers un autre ASP ayant plus de liquidités disponibles, établissant ainsi le lien ATLC entre sa propre Arche d’où provient le paiement et l’Arche d’un autre ASP pour être reçu, économisant ainsi les frais des utilisateurs. À leur tour, comme ils sont en mesure de récupérer des liquidités à mesure qu’ils ferment les Arks existants et que leurs propres frais diminuent, d’autres ASP confrontés alors à une crise de liquidité pourraient « rendre la pareille » en renvoyant les paiements dans leur direction.
Cela pourrait établir une sorte de tournoi à la ronde et une dynamique facilement analysable « Je te gratte le dos, tu grattes le mien » entre les ASP, qui tout en laissant des revenus sur la table lors de crises de liquidité à frais élevés, créerait globalement une expérience plus prévisible et abordable pour leur utilisateurs.
Cela comporte le risque que les paiements entre ASP comme celui-ci relient essentiellement les Arks à différents ASP, ce qui signifie que les fermetures non coopératives nécessiteraient la fermeture des Arks exploités par plusieurs entités, mais étant donné que les fermetures de coopératives dépendent du comportement des utilisateurs, je ne pense pas que cela modifie fondamentalement le profil de risque sans que les ASP ne se dérangent intentionnellement. Cela pourrait cependant être considéré comme analogue au problème de brouillage de canal de Lightning.
Il y a des avantages et des inconvénients potentiels, mais je pense que c’est un concept qui mérite d’être exploré pour atténuer le problème de crise de liquidité d’Ark.