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  :

é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.

À partir de ce point 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.

Jusqu' le serveur n' Lorsque le serveur reçoit un message utilisant un 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.

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  :

é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

échange Lightning, un autorisé par chaque utilisateur impliqué

Le propriétaire actuel de la chaîne d'état impliqués et lui demande de générer une pré-image de hashlock pour un paiement Lightningil 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.

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  :

/blockquote>

Et pour une explication plus technique, ici :

/blockquote>