L’année dernière, j’ai écrit sur le portefeuille Mercury de Commerceblock, une implémentation à la fois des chaînes d’état et des CoinSwaps. Cela a simultanément introduit un nouvel outil de mixage ainsi que le premier portefeuille pour implémenter une nouvelle solution de mise à l’échelle de deuxième couche. L’équipe s’est appuyée sur la proposition originale de chaîne d’états de Ruben Somsen avec quelques modifications pour la faire fonctionner sans l’indicateur de sighash ANYPREVOUT/Eltoo nécessaire, et a intégré une nouvelle conception CoinSwap pour permettre aux utilisateurs de mélanger plusieurs fois sans avoir besoin d’effectuer des transactions sur la chaîne pour chaque mélange.
Table des matières
Arrière plan
Pour résumer rapidement pour ceux qui n’ont pas lu mon article précédent : une chaîne d’état est un mécanisme hors chaîne permettant de transférer librement entre n’importe qui complètement hors chaîne. Le propriétaire / utilisateur d’origine collabore avec un opérateur de chaîne d’état pour construire une adresse ECDSA-MPC où la clé privée est partagée avec une moitié détenue par l’utilisateur et l’autre moitié par l’opérateur, puis une transaction de retrait pré-signée et verrouillée dans le temps est créée et signé, avec l’opérateur avant d’envoyer les fonds à la nouvelle adresse.
Aucune des deux parties ne contrôle entièrement la clé privée et l’utilisateur dispose d’une transaction pré-signée qui lui permet de reprendre unilatéralement les pièces après le verrouillage temporel. Lorsque l’utilisateur souhaite transférer la chaîne d’état, il en informe l’opérateur qui collabore alors avec le récepteur. Le récepteur et l’opérateur génèrent un nouvel ensemble de partages de clés privées qui correspondent à la même adresse, et génèrent une nouvelle transaction pré-signée avec un timelock inférieur à la dernière, puis l’opérateur supprime leur ancien partage de clés.
La façon dont la cryptographie fonctionne, le nouveau partage de clé de l’opérateur ne fonctionnera qu’avec le partage de clé du nouvel utilisateur, donc s’il supprime l’ancien, il ne lui est même pas possible de collaborer avec l’ancien utilisateur pour dépenser les pièces. De plus, la nouvelle transaction de retrait ayant un délai inférieur, cette transaction peut toujours être confirmée avant celle du propriétaire précédent. Cela limite le nombre de fois où la chaîne d’État peut être transférée avant qu’elle ne doive être fermée, mais si l’opérateur agit honnêtement, cela empêche les propriétaires plus âgés de voler des fonds.
Un canal Lightning au-dessus d’une chaîne d’état
Commerceblock travaille actuellement sur un nouveau BLIP (Bitcoin Lightning Improvement Proposal) pour mettre en œuvre une conception pour quelque chose proposé dans la proposition initiale de chaîne d’état de Somsen : établir un canal Lightning au-dessus d’une chaîne d’état.
L’un des défauts d’une chaîne d’états en elle-même est que l’ensemble de l’UTXO doit être transféré en une seule fois. Si, toutefois, la transaction de retrait de la chaîne d’état passe dans un canal Lightning au lieu de l’adresse d’un seul utilisateur, des fractions de la chaîne d’état peuvent être transférées via la distribution du solde initial dans un canal et ce canal peut être utilisé de manière conventionnelle pour effectuer des paiements Lightning par la suite.
Le processus commence d’abord par la création d’une chaîne d’état par un utilisateur. Le créateur et l’opérateur suivent le processus normal de création de la clé fragmentée et de signature d’une transaction de retrait de sauvegarde avec un timelock, puis le créateur (Alice) trouve une contrepartie (Bob) qui acceptera les chaînes d’état. Alice et Bob s’engagent dans le même protocole utilisé pour créer une clé fragmentée qu’Alice a fait avec l’opérateur de chaîne d’état et génèrent leur propre clé partagée. Les deux partagent ensuite à la fois la clé publique cumulative et leurs parts de clé publique individuelles avec l’opérateur de la chaîne d’état. Cela permet à l’opérateur de les mettre tous les deux au défi de signer individuellement et de prouver qu’ils sont d’accord sur le solde actuel des fermetures de coopératives sans attendre l’expiration du délai de retrait de la chaîne d’état.
À partir de là, avec l’autorisation de Bob, Alice et l’opérateur de la chaîne d’état signent une transaction en dépensant directement la chaîne d’état dans le multisig du canal Lightning et gèrent la création de la transaction du canal Lightning. À ce stade, l’adresse de la chaîne d’état est toujours contrôlée uniquement par Alice et l’opérateur, mais la transaction ouvrant un canal Lightning est maintenant en possession de Bob avec un timelock inférieur au retrait de la chaîne d’état d’origine, garantissant qu’elle peut être confirmée avant qu’Alice ne puisse unilatéralement fermer la chaîne d’état. à elle-même. Ensuite, Alice et Bob finalisent le protocole en effectuant une dernière mise à jour avec l’entité statechain, en créant une transaction finale de la chaîne d’état avec un autre timelock décrémenté en utilisant leur clé combinée avec celle de l’opérateur pour effectuer une transaction de retrait qui dépense les fonds vers le canal Lightning. Ils peuvent désormais tous les deux annoncer que le canal Lightning est ouvert et que le protocole est terminé.
Améliorer l’utilité des chaînes d’état
Cette proposition améliorerait considérablement l’utilité d’une chaîne d’État en assouplissant la dynamique de liquidité stricte de leur fonctionnement. Chaque fois que quelqu’un serait prêt à accepter une chaîne d’état mais que la dénomination ne correspond pas au paiement, l’expéditeur peut simplement ouvrir un canal Lightning entre eux à la place et attendre jusqu’à ce qu’il ait besoin de dépenser le reste des fonds (ou de finir par recevoir ce qu’il a envoyé retour) pour finaliser un transfert de l’intégralité du solde de la chaîne d’état. Une telle possibilité augmente non seulement l’utilité d’une chaîne d’états, mais augmente également l’utilité du Lightning Network s’il est correctement pris en charge.
Le rééquilibrage des canaux est une nécessité pour les nœuds du réseau, à la fois les nœuds de routage et les nœuds périphériques qui envoient et reçoivent simplement des transactions. Lorsque les fonds circulent complètement d’un côté d’un canal, cela rend le canal inutile pour faire passer les paiements dans une direction (si tout l’argent est de votre côté, vous ne pouvez pas recevoir de paiements ; s’il est de l’autre côté, alors vous ne peut pas envoyer de paiements). Cela nécessite de brasser de l’argent d’un canal à l’autre, ce qui contribue également à déséquilibrer les canaux en cours de route pour rééquilibrer le vôtre. Finalement, cette dynamique arrive à un point où les choses doivent en fait être rééquilibrées en échangeant des fonds entre Lightning et la couche de base sur la chaîne.
Les chaînes d’État permettent de déplacer la liquidité avec la même liberté que celle offerte par le fait de le faire en chaîne, sans avoir besoin de créer l’empreinte en chaîne ou de payer des frais pour cela. Supposons que vous ayez un canal épuisé, avec toute la liquidité de l’autre côté vous laissant, aucune capacité de dépense et vous avez également une chaîne d’état. Cette chaîne d’état peut être librement transférée à toute personne qui l’acceptera, et elle peut même avoir un canal Lightning en plus si vous n’envoyez pas la totalité de la valeur, et elle peut être utilisée pour rééquilibrer les fonds dans votre canal habituel de votre côté .
Cela permet beaucoup plus d’efficacité en termes de nombre de canaux que vous devez acheminer afin de rééquilibrer votre canal (rappelez-vous, vous contribuez à modifier les soldes de tous les autres canaux que vous acheminez), dans le meilleur des cas en l’envoyant littéralement directement au même pair avec lequel vous avez ouvert le canal avec lequel vous rééquilibrez. Si vous souhaitez fermer un canal avec un pair et l’ouvrir avec un autre, vous pouvez même rééquilibrer les choses afin d’avoir tout l’équilibre du canal et le déplacer entièrement hors chaîne vers le nouveau pair s’il est construit au-dessus d’un chaîne d’état.
L’avenir des chaînes d’État et de la foudre
Discutant de leurs plans pour l’avenir, Nicolas Gregory de Commerceblock a déclaré : « Notre objectif est d’établir une approche standardisée pour combiner les chaînes d’état et la technologie Lightning afin de faciliter l’équilibrage hors chaîne des canaux Lightning grâce à l’utilisation de canaux d’état. Cette spécification servira de la base pour atteindre cet objectif. »
Dès le début, les chaînes d’état ont toujours été proposées pour interagir avec Lightning afin de résoudre le problème de leur utilisation par elles-mêmes : que vous devez transférer la valeur entière de l’ensemble de l’UTXO. Ils offrent également à Lightning un degré de flexibilité qu’il n’a pas par lui-même en termes de gestion et de transfert des liquidités sur le réseau.
Maintenant que Lightning est à un stade sain de sa croissance initiale et qu’une mise en œuvre concrète des chaînes d’état existe depuis plus d’un an, il est temps de commencer à réfléchir à la manière dont ces deux technologies peuvent interagir ensemble. La foudre en tant que réseau est un système de transfert à séquestre atomique entre deux parties qui ne sont pas directement connectées sur le graphe du réseau. Le fonctionnement de chaque connexion sur ce graphique, à proprement parler, ne devrait pas avoir d’importance pour les expéditeurs et les destinataires des paiements, tant que cela fonctionne.
Les chaînes d’État et les canaux Lightning ont tous deux beaucoup à offrir en termes d’avantages, tout ce qui doit être fait est de travailler à normaliser les deux interagissant les uns avec les autres.
Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.
