Ark est un nouveau mécanisme de lots de transactions hors chaîne proposé à l’origine par Burak, un jeune développeur turc. Il y a actuellement deux implémentations en cours de construction, l’une par Ark Labs, et l’autre par deuxième, à laquelle Burak n’est impliqué.
La proposition originale pour ARK a été beaucoup plus compliquée et impliquait certains objectifs de conception plus axés sur la confidentialité que les implémentations en cours de construction. Il a également été envisagé à l’origine pour exiger CheckTempPeolify (CTV) pour être construit.
Le protocole dépend d’un serveur de coordination central afin de fonctionner correctement, mais malgré cela est en mesure de fournir les mêmes fonctionnalités et garanties de sécurité que le réseau Lightning. Tant qu’un utilisateur reste en ligne pendant la période requise, à tout moment (sauf s’il choisit de faire confiance à l’opérateur pendant de courtes périodes), chaque utilisateur est capable à tout moment de quitter unilatéralement le système ARK à tout moment et de reprendre le contrôle unilatéral complet de ses fonds.
Contrairement à Lightning, ARK n’exige pas que les utilisateurs disposent de la liquidité pré-allocée qui leur est attribuée afin de recevoir des fonds. Un utilisateur d’ARK peut simplement embarquer vers un portefeuille et recevoir des fonds immédiatement sans aucune pré-allocation de liquidité.
Profitons des différentes pièces constituantes de l’arche.
L’arbre Ark
Les pièces maintenues sur ARK sont appelées utxos virtuels (Vutxos). Ce ne sont que des transactions pré-signées qui garantissent la création d’un vrai UTXO sous le contrôle unilatéral d’un utilisateur une fois soumis Onchain, mais sont autrement détenus hors chain.
Les Vutxos de chaque utilisateur sont imbriqués à l’intérieur d’un arbre de transactions pré-signées, ou un «lot». ARK fonctionne en ayant le serveur de coordinateur ou le fournisseur de services ARK (ASP), faciliter la coordination entre les utilisateurs nécessaires pour créer un lot. Chaque fois que les utilisateurs reçoivent des fonds, intégrés à l’arche ou au large, il est nécessaire de construire une transaction et l’arborescence de transaction associée pour créer un nouveau lot.
L’arbre est construit pour prendre l’onchain confirmé UTXO à racine unique, verrouillé avec un N-OF-N multi-n, y compris tous les utilisateurs, tenant des Vutxos dans l’arbre ainsi que l’ASP, et se divise lentement en de plus en plus UTXOS jusqu’à ce que ce soit finalement atteint les feuilles, qui sont chacun des utilisateurs Vutxo. Chaque VUTXO est garanti en utilisant un script qui doit être signé par un multi-2 sur 2, une clé détenue par l’utilisateur, et l’autre par l’ASP, ou tout simplement l’utilisateur après un timelock.
Chaque fois que l’arbre se divise, les Vutxos sont créés en onchain, mais il en va de même des UTXO internes qui n’ont pas encore réellement divisé en Vutxos. Chacun de ces UTXOS internes est verrouillé avec un N-OF-N multi-n composé de l’ASP, et tous les utilisateurs qui ont un Vutxo plus bas sur l’arbre. Pendant le processus de création par lots, les utilisateurs commencent à leurs Vutxos respectifs et passent par un processus de signature tout le long de la racine de l’arbre. Cela garantit que la racine ne sera jamais signée avant que la revendication de chaque utilisateur à un Vutxo soit, garantissant qu’ils ont toujours un accès unilatéral dans le pire des cas à leurs fonds.
Chaque lot a également un temps d’expiration (ce qui aura du sens dans la section suivante). Ce chemin de dépenses à expiration, qui existe en tant que condition de dépenses alternatifs pour le Root Utxo Onchain ainsi que chaque UTXO interne, permet à l’ASP de dépenser unilatéralement tous les fonds.
Transactions, préconfirmation et entrées de connecteur
En ce qui concerne les transactions sur ARK, il y a deux mécanismes possibles possibles, à la fois avec leurs propres coûts et implications en termes de modèle de sécurité. Il existe des transferts hors ronde ou des transactions préconçues, et il y a des transferts en ronde ou des transactions réellement confirmées.
Pour effectuer un transfert hors solide, un processus très simple. Si un utilisateur (Alice) veut payer un autre (Bob), il contacte simplement l’ASP et leur fait co-signer une transaction en dépensant le Vutxo à Bob. Bob reçoit ensuite cette transaction pré-signée, ainsi que toutes les autres la précédant à la racine du lot Onchain. Bob est désormais capable de quitter unilatéralement l’Arche avec cette transaction, il doit faire confiance à l’ASP pour ne pas colluder avec Alice pour le doubler. Ces transactions hors ronde peuvent même être enchaînées plusieurs fois avant de les confirmer enfin.
Pour finaliser une transaction ARK, les utilisateurs doivent s’engager dans un «échange de lots». Les utilisateurs ne peuvent pas réellement confirmer un transfert dans un seul lot, ils doivent échanger atomiquement un Vutxo dans un lot existant avec un nouveau Vutxo créé dans un nouveau lot. Cela se fait en utilisant l’ASP comme facilitateur de l’échange, et à l’aide de ce qu’on appelle une «entrée de connecteur».
Lorsqu’un utilisateur va finaliser une transaction ARK avec un échange de lots, il abandonne le contrôle du Vutxo vers l’ASP. Cela pourrait être problématique, qu’est-ce qui empêche l’ASP de le garder simplement et de ne pas leur donner un Vutxo confirmé dans un nouveau lot? L’entrée du connecteur.
Lorsqu’un nouveau lot est créé, une deuxième sortie est créée dans la transaction qui est confirmée sur la chaîne instanciant un nouvel arbre composé de connecteur UTXOS. Lorsque Bob va signer une transaction de forfaits à l’ASP pour effectuer l’échange de lots, la transaction comprend comme entrée l’un des connecteurs UTXOS.
Cela crée une garantie atomique. Le VUTXO confirmé par Bob est inclus dans un lot dans la même transaction dans laquelle l’entrée du connecteur est créée dans ce qui est nécessaire pour que sa transaction de confiscation soit valide. Si ce lot n’est jamais créé Onchain, c’est-à-dire que Bob ne reçoit jamais réellement le nouveau Vutxo confirmé, alors la transaction forfait qu’il a signée pour l’ASP ne sera jamais valide et confirmable.
Dynamique de liquidité et espace de blocage
Toute la liquidité nécessaire pour créer de nouveaux lots afin de faciliter les transferts entre les utilisateurs est fourni par l’ASP. Ils doivent avoir suffisamment de liquidité pour créer de nouveaux lots pour les utilisateurs jusqu’à ce que les anciens aient expiré et que l’ASP puisse les balayer unilatéralement pour récupérer l’ancienne liquidité précédemment verrouillée pour créer des Vutxos pour les utilisateurs.
C’est le cœur de la dynamique de liquidité au centre du protocole ARK. Bien que dans un sens, il s’agit d’une victoire massive d’efficacité, ne nécessitant pas les fournisseurs de liquidités pour évaluer les utilisateurs et deviner essentiellement lesquels recevront réellement de grands volumes de paiements avant de pouvoir recevoir des fonds, dans un autre, il s’agit d’une perte d’efficacité car l’ASP doit avoir suffisamment de liquidité pour continuer à créer de nouveaux lots pour les utilisateurs pendant que ils configurent le temps d’expiration et qu’ils peuvent commencer à récupérer une liquidité allocate pendant longtemps.
Cela peut être atténué à un degré décent par la fréquence à laquelle un ASP propose de créer de nouveaux lots pour finaliser les transactions en attente. Dans le cas d’un ASP tentant de créer de nouveaux lots en temps réel à mesure que les transactions arrivent, les exigences de liquidité seraient exorbitante. Cependant, un ASP peut réduire la fréquence à laquelle il créent de nouveaux lots et réduire considérablement leurs besoins en liquidité.
Cette dynamique a également des implications pour l’utilisation de BlockSpace. Contrairement à Lightning, qui peut fournir des garanties de confirmation solides entièrement hors chain, afin qu’une transaction ARK ait un degré de finalité sans confiance équivalent, un nouveau lot à créer en ondes. Cela signifie que contrairement à la foudre, lorsque le volume des transactions ne se reflète pas sur la vitesse, la vitesse des transactions ARK nécessite intrinsèquement une quantité proportionnelle d’utilisation de l’espace de blocs, bien que de manière très compressée et efficace. Cela crée une limite supérieure théorique du nombre de lots d’arche peut être créé au cours d’un intervalle de temps donné (bien que les arbres puissent être plus petits ou plus grands selon cette dynamique).
Emballage
Ark présente à bien des égards un ensemble de compromis presque opposés au réseau Lightning. Il s’agit d’une amélioration massive de l’efficacité de l’espace de blocs pour les transactions hors chain, et élimine le problème de l’allocation de liquidité sur le réseau de Lightning, mais il a une limite de débit liée beaucoup plus étroite qui est corrélée avec la limite de débit de blockchains.
Cette dynamique de compromis presque opposés en fait un système très complémentaire au réseau Lightning. Il peut également interagir avec lui, c’est-à-dire que Vutxos peut être échangé atomiquement dans les transactions entrant ou sortant du réseau Lightning.
En fin de compte, la façon dont il s’intègre dans l’écosystème Bitcoin plus large n’est pas encore visible, mais c’est une pile de protocole sans aucun doute précieuse qui trouvera un créneau fonctionnel, même s’il est différent de ce qui est prévu à l’origine.
Ce post Bitcoin Layer 2: Ark est apparu pour la première fois sur Bitcoin Magazine et est écrit par Shinobi.