Couche de mercure  : une amélioration massive des chaînes d'état

• CommerceBlock publie Mercury Layer, une amélioration des chaînes d'état
• Mercure Layer introduit une variante aveugle pour protéger la confidentialité des transactions
• Les Statechains offrent des avantages en matière de liquidité et de flexibilité pour les transactions de deuxième couche sur Bitcoin

CommerceBlock publie aujourd'hui Mercury Layer, une version améliorée de sa variante d'une chaîne d'états. Vous pouvez lire une explication plus longue du fonctionnement de leurs chaînes d'état Mercury ici. La mise à niveau vers Mercury Layer représente une amélioration considérable par rapport à la mise en œuvre initiale de la chaîne d'état, mais contrairement à la version initiale de Mercury Wallet, elle n'est pas présentée comme un portefeuille entièrement prêt pour le consommateur.

Il est publié sous forme de bibliothèque et d'outil CLI que d'autres portefeuilles peuvent intégrer. Voici un bref résumé de leur fonctionnement :
Les chaînes d'État sont essentiellement analogues aux canaux de paiement à bien des égards, c'est-à-dire qu'elles constituent un UTXO partagé en collaboration avec une transaction pré-signée comme mécanisme de dernier recours permettant aux personnes de faire valoir leur propriété. La principale différence entre un canal Lightning et une chaîne d'état réside dans les parties impliquées dans le partage collaboratif de l'UTXO et dans la manière dont la propriété d'une réclamation exécutoire contre celui-ci est transférée à d'autres parties.

Contrairement à un canal Lightning, qui est créé et partagé entre deux participants statiques, une chaîne d'état est ouverte avec un facilitateur/opérateur et peut être librement transférée dans son intégralité entre deux participants prêts à faire confiance à l'opérateur pour être honnête, complètement hors de propos. -chaîne. Quelqu'un souhaitant charger une chaîne d'état collabore avec l'opérateur pour créer une clé publique unique dans laquelle le créateur et l'opérateur détiennent tous deux une part de la clé privée correspondante, sans qu'aucun d'eux n'ait une copie complète de la clé.

À partir de là, ils pré-signent une transaction permettant au créateur de récupérer unilatéralement ses pièces après un délai de verrouillage.
Pour transférer une chaîne d'état, le propriétaire actuel collabore avec le récepteur et l'opérateur pour signer une preuve cryptographique avec son partage de clé indiquant qu'il transfère la pièce, puis le récepteur et l'opérateur génèrent une nouvelle paire de partages de clés qui totalisent la même clé privée et signent. une transaction limitée dans le temps pour le nouveau propriétaire avec un délai plus court que l'original (pour garantir qu'il puisse utiliser le sien plus tôt que les anciens propriétaires).

Ce processus est répété pour chaque transfert jusqu'à ce que le timelock ne puisse plus être raccourci, auquel cas la chaîne d'états doit être fermée en chaîne.
Les propriétaires transfèrent toute la chaîne historique des états passés à chaque transfert afin que les utilisateurs puissent vérifier que les timelocks ont été correctement décrémentés et que l'opérateur les horodatage à l'aide de Mainstay, une variante d'Opentimestamps où chaque élément de données a son propre « emplacement » unique dans l'arbre Merkle. pour garantir qu’une seule version des données est horodatée.

Cela permet à tout le monde de vérifier l'historique des transferts d'une chaîne d'état.

Au pays des aveugles

Le grand changement que Mercury Layer apporte à la version originale des chaînes d’état est aveuglant. L'opérateur du service statechain ne pourra plus rien savoir de ce qui est transféré : c'est-à-dire les TXID impliqués, les clés publiques impliquées, voire les signatures qu'il collabore avec les utilisateurs pour créer pour les transactions pré-signées nécessaires à la réclamation.

vos fonds unilatéralement.
En introduisant une variante aveugle de Schnorr MuSig2, Mercury peut faciliter le processus de signature des transactions d'annulation sans connaître les détails de ce qu'ils signent. Cela nécessite quelques modifications de conception afin de tenir compte du fait que l'opérateur ne peut plus voir et publier l'intégralité de l'historique des transferts d'une chaîne d'états.

Ils ne sont même pas capables de valider la transaction qu’ils signent.
Dans l'itération précédente, le caractère unique d'un propriétaire/ensemble de transactions de chaîne d'état actuel a été attesté par l'opérateur par la publication de l'historique complet des transferts de la chaîne d'état avec Mainstay. Cela n'est pas possible ici, car dans la version aveugle, l'opérateur n'apprend aucun détail sur ces transactions.

Cela nécessite une nouvelle façon pour l’opérateur d’attester de la propriété actuelle de la chaîne d’État. Toutes ces données sont entièrement transmises à un modèle de validation côté client. L'opérateur garde simplement une trace du nombre de fois où il a signé quelque chose pour une seule chaîne d'état et indique ce numéro à un utilisateur lorsqu'il est demandé.

L'utilisateur reçoit ensuite les transactions des états de chaîne d'état passés de l'utilisateur qui leur a envoyé, et vérifie entièrement côté client que le nombre de transactions correspond à ce que l'opérateur a revendiqué, puis vérifie entièrement que les signatures sont toutes valides et que les timelocks sont décrémentés du montant approprié. chaque fois. Au lieu de publier l'intégralité des transactions de la chaîne d'état et l'ordre de transfert vers Mainstay, parce qu'il est conçu pour ignorer toutes ces informations, il publie sa part de la clé publique (et non la clé publique globale complète) pour l'utilisateur actuel pour chaque chaîne d'état.

utilisateur. Cela permet à tout utilisateur recevant une chaîne d'état de vérifier que l'historique des transferts et l'état actuel sont légitimes par rapport aux données de transaction envoyées par l'expéditeur.
Le serveur de l'opérateur garde une trace des chaînes d'états uniques pour compter les signatures passées en attribuant à chaque chaîne d'états un identifiant aléatoire lors de la création, stocké avec sa dénomination et sa clé privée et ses partages de clé publique (et non la clé publique globale globale).

Le nouveau schéma de coordination pour le partage et le repartage de la clé est réalisé de manière à ce que le serveur transmette sa part de la clé à l'utilisateur et que les données nécessaires au repartage soient masquées, de sorte que le serveur est incapable d'apprendre l'intégralité de l'utilisateur. partage de clé publique, lui permettant de créer la clé publique globale complète et d'identifier la pièce sur la chaîne.
La conception ne permet même pas à l'opérateur de savoir quand il a signé une fermeture de coopérative avec le propriétaire actuel plutôt qu'une transaction pré-signée pour un nouveau propriétaire hors chaîne ; il ne voit aucun détail permettant de distinguer les deux cas l'un de l'autre.

Ceci est cependant sans danger pour les utilisateurs qui pourraient être attaqués par quelqu'un essayant de « doubler d'argent » une chaîne d'état hors chaîne fournissant une fausse transaction qui n'a pas pu être réglée. Premièrement, cet utilisateur verrait sur la chaîne que l'UTXO soutenant cette chaîne d'état a été dépensé. Deuxièmement, l'historique des transactions, étant donné que l'opérateur doit signer toutes les mises à jour d'état, n'aurait qu'une clôture coopérative claire dans la chaîne des transactions passées.

Ces deux éléments permettraient à l’utilisateur de refuser la transaction sachant qu’elle n’est pas légitime.
Les Statechains permettent également aux canaux Lightning d'être « placés au-dessus » de la Statechain en faisant en sorte que la Statechain paie à une adresse multisig entre deux personnes, et que les deux négocient un ensemble conventionnel de transactions d'engagement Lightning par-dessus. Il faudrait fermer la chaîne d'état en chaîne avant de fermer le canal Lightning, il faudrait donc utiliser des durées de verrouillage plus longues pour les paiements Lightning, mais sinon, il fonctionnerait parfaitement normalement.

Dans l’ensemble, avec les améliorations massives de la confidentialité de la nouvelle itération des chaînes d’état et la composabilité avec Lightning, cela ouvre de nombreuses portes pour la viabilité économique et la flexibilité des mécanismes transactionnels de deuxième couche sur Bitcoin. Surtout à la lumière des récents changements radicaux dans la dynamique du mempool et de la pression sur les frais qui en résulte.
Il offre le même type d'avantages en matière de liquidité qu'Ark, c'est-à-dire qu'il peut être librement transférable sans avoir besoin de recevoir de liquidités, mais contrairement à Ark, il est aujourd'hui opérationnel et fonctionnel.

Il s’agit indéniablement d’un modèle de confiance différent de celui de Lightning seul, mais compte tenu des gains massifs en termes de flexibilité et d’évolutivité, c’est certainement une possibilité à explorer.