Protocole d'échange Lightning Latch de Mercury Layer

Commerceblock a publié un nouveau protocole d'échange atomique à utiliser avec les chaînes d'état sur son protocole Mercury Layer. Le serveur HSM a introduit une fonctionnalité permettant de prendre en charge l'échange atomique de deux chaînes d'état, ainsi que d'appliquer un échange atomique d'une chaîne d'état contre un paiement Lightning. Il s'agit du premier exemple d'interactions concrètement définies et construites entre les chaînes d'état et le Lightning Network. La synergie entre les deux protocoles a été postulée depuis que le concept de chaîne d'états a été initialement proposé par Ruben Somsen, spécifiquement comme moyen de résoudre la limitation liée au transfert simultané d'une chaîne d'états UTXO entière.

Échanges de Statechain de base

Afin de prendre en charge les nouveaux protocoles d'échange, le serveur HSM doit ajouter de nouveaux champs à ses entrées de base de données pour suivre chaque chaîne d'états qu'il facilite. Pour faciliter l'échange de statechain à statechain, le serveur doit suivre :

• Batch_id : une valeur pour associer les chaînes d'états échangées dans un groupe
• Batch-time : un temps qui démarre un compteur après lequel les chaînes d'état peuvent être « récupérées » si le swap échoue
• Verrouillé : une valeur indiquant si la chaîne d'états est verrouillée et restreinte aux transferts réguliers.

Cela permet au serveur HSM de suivre et d'appliquer toutes les variables nécessaires pour garantir un échange atomique sûr. Lors du lancement d'un échange, les utilisateurs doivent communiquer directement entre eux afin d'établir un batch_id partagé entre eux. À partir de ce point, ils échangent toutes les informations nécessaires pour faciliter un transfert normal de chaîne d'état et envoient ces informations ainsi que le batch_id et le batch-time au serveur. Ils démarrent essentiellement le processus de transfert régulier, mais attachent également les variables pour connecter les chaînes d'état individuelles en tant que participantes à un échange ensemble et la durée du délai d'attente pour cela.
À ce stade, le serveur appliquera un verrou à chaque chaîne d'états en utilisant le même batch_id dans le processus de transfert. Jusqu'à ce que le délai d'attente expire ou que toutes les chaînes d'état de sa base de données utilisant le même batch_id aient été déverrouillées par les propriétaires actuels, le serveur n'approuvera aucun transfert. Ce qui est intéressant dans la façon dont le HSM applique la logique d'échange, c'est que peu importe qui contacte le serveur en premier. Lorsque le serveur reçoit un message utilisant un batch_id, il vérifie chaque chaîne d'état dans sa base de données et s'il existe un temps de lot préexistant pour ce batch_id, il le définit comme étant le même. Cela garantit que peu importe qui enregistre le swap en premier, ils utilisent tous la même valeur de temps pour la fonction de délai d'attente.
À ce stade, chaque client impliqué dans l'échange vérifie et télécharge les messages qui ont initié le protocole de transfert et, après avoir vérifié leur exactitude, envoie un message au serveur pour déverrouiller sa chaîne d'état, supprimant ainsi les restrictions de transfert. Chaque fois que quelqu'un tente de finaliser un transfert du côté récepteur de l'une des chaînes d'état impliquées dans l'échange, le serveur vérifie que toutes les chaînes d'état avec le même batch_id sont déverrouillées. Si même un seul avec le batch_id associé est toujours verrouillé, le serveur finalisera un transfert pour aucun d'entre eux. Si un échange échoue avant l'expiration du délai, le serveur continuera à restreindre la finalisation du transfert d'échange, mais laissera les propriétaires actuels s'initialiser un nouveau transfert pour annuler efficacement l'échange.

Loquet éclair

La fonctionnalité Lightning Latch, qui permet d'échanger une chaîne d'état contre un paiement Lightning, fonctionne de manière très similaire à l'échange de chaîne d'état à chaîne d'état. Voici les nouveaux champs que le serveur doit suivre pour l'échange Lightning :

• Batch_id : une valeur pour associer les chaînes d'états échangées dans un groupe
• Batch-time : un temps qui démarre un compteur après lequel les chaînes d'état peuvent être « récupérées » si le swap échoue
• Pré-image : la pré-image du paiement Lightning, qui est générée par le serveur HSM
• Locked_1 et lock_2 : il existe deux champs de verrouillage pour l'échange Lightning, un autorisé par chaque utilisateur impliqué

Tout comme avec l'échange de statechain à statechain, les utilisateurs établissent et partagent un batch_id aléatoire. Le propriétaire actuel de la chaîne d'état envoie ensuite un message au serveur avec le batch_id et la chaîne d'état impliqués et lui demande de générer une pré-image de hashlock pour un paiement Lightning. Cet utilisateur génère ensuite une facture Lightning à l'aide de cette pré-image, et le deuxième utilisateur contacte le serveur pour confirmer qu'il a généré la pré-image. Le propriétaire actuel de la chaîne d'état commence alors le processus de transfert de la chaîne d'état et télécharge le message de transfert sur le serveur.
Après confirmation de cela, le deuxième utilisateur essayant d'échanger contre la statechain lance le paiement Lightning. À l'heure actuelle, le serveur est le seul à disposer de la pré-image, le propriétaire de la chaîne d'état ne peut donc pas encore finaliser le paiement. Le propriétaire actuel, après avoir vérifié le paiement Lighting en attente, envoie au serveur un message de déverrouillage pour supprimer le premier verrou sur la chaîne d'état. Le destinataire vérifie enfin le message de transfert et, s'il est valide, le serveur doit également supprimer son verrou.
Désormais, une fois les deux verrous supprimés, le serveur HSM communiquera la pré-image au propriétaire actuel de la chaîne d'état pour finaliser le paiement Lightning, et finalisera le transfert de la chaîne d'état vers le destinataire.
Ce schéma nécessite de faire confiance à l’opérateur de la chaîne d’état pour fonctionner honnêtement, mais cela ne constitue fondamentalement pas un changement par rapport au modèle de confiance préexistant consistant à utiliser une chaîne d’état en général. À aucun moment, l'opérateur n'a de contrôle sur les fonds des utilisateurs et n'apprend rien des détails du paiement Lightning.

A quoi ça sert ?

Ce schéma est loin de l'interaction initialement proposée entre les chaînes d'états et les canaux Lightning, empilés les uns sur les autres, mais même en tant que simple point de départ, il présente une utilité fonctionnelle pour les utilisateurs Lightning existants. Le rééquilibrage des canaux est une chose nécessaire pour de nombreux nœuds, si la capacité est entièrement poussée d'un côté ou de l'autre, l'utilité de ce canal est limitée pour acheminer les paiements. De nombreuses entreprises et utilisateurs ont commencé à expérimenter l'utilisation de Liquid comme mécanisme pour cela en raison de l'augmentation des frais en chaîne et des échanges vers et depuis le réseau Lightning plus coûteux.
Les Statechains offrent un mécanisme alternatif à une sidechain fédérée pour alléger certaines des dépenses associées à la gestion de l'équilibre des canaux. Au lieu de devoir passer directement à la chaîne principale ou d'utiliser une chaîne latérale, les fonds peuvent être échangés vers une chaîne d'état et y être conservés jusqu'à ce qu'ils soient nécessaires pour rééchanger les fonds dans un canal. Des économies similaires sur les frais peuvent être réalisées tout en conservant la possibilité de réclamer unilatéralement vos fonds sur la chaîne principale.
Un autre cas d'utilisation potentiel (AVERTISSEMENT DE DÉCLENCHEMENT) serait la possibilité de marchés plus efficaces pour le trading des ordinaux. Étant donné que les ordinaux sont simplement un schéma d'index qui suit les chemins en arrière dans l'historique des transactions vers des satoshis spécifiques, ils peuvent facilement être transférés hors chaîne sur une chaîne d'états. Cette dynamique, combinée à Lightning Latch, pourrait permettre des achats d'ordinaux hors chaîne moins chers et plus rapides. Quelqu'un pourrait créer un marché où ils pourraient être vendus instantanément hors chaîne sur le réseau Lightning.
Il est même possible qu'un jour les clients Lightning puissent savoir d'une manière ou d'une autre quels nœuds Lightning spécifiques des opérateurs de chaînes d'états croient que Latch pourrait être utilisé pour aider à acheminer les paiements en faisant passer les chaînes d'états entre différents nœuds au lieu d'utiliser les canaux Lightning conventionnels.
Sur le plan des transferts de chaîne d'état pure à chaîne d'état, cela offre la possibilité d'une couche de transmission de messages pour recréer un système de jointure de pièces comme un système de mélange de pièces hors chaîne, similaire à la fonctionnalité de mélange originale dans la première implémentation de chaîne d'état de Commerceblock.
Bien qu'il s'agisse d'un point de départ très simple, Lightning Latch et la fonctionnalité d'échange de chaînes d'états ouvrent la première porte aux chaînes d'états s'intégrant au réseau Lightning existant - et à d'autres couches similaires à venir dans le futur - d'une manière qui leur permet de toutes s'intégrer de manière transparente et fonctionnent comme un réseau unique en termes d’acheminement des paiements et de gestion des liquidités. Même si nous débattons de la nécessité et de l’utilité des pactes, il reste encore beaucoup de marge pour continuer à construire avec ce que nous avons déjà.
Vous pouvez écouter l'équipe Commerceblock expliquer la logique au-delà du protocole ici :

Discuter avec le Dr @TTrevethan pour savoir pourquoi construire un verrou éclair sur @mercurylayer #bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6
– Nicolas Gregory (@gregory_nico) 15 mars 2024

Et pour une explication plus technique, ici :

Passer en revue les aspects techniques du fonctionnement du verrou Lightning avec @TTrevethan sur @mercurylayer #bitcoin #layer2 pic.twitter.com/aQIcjh2ukq
– Nicolas Gregory (@gregory_nico) 16 mars 2024