L’évolution des statechains de CommerceBlock et leur influence sur le marché des cartes cadeaux cryptées

Les statechains de Mercury améliorent la confidentialité dans les transactions de cryptomonnaies

CommerceBlock a révolutionné son système de statechains initiales, Mercury, une solution de deuxième couche comparable au Lightning, en renforçant significativement l’anonymat de ses utilisateurs. Désormais, l’opérateur ne peut déceler aucune information concernant les activités on-chain des usagers. CommerceBlock annonce aujourd’hui le lancement de Mercury Layer, une version améliorée de leur statechain. Une explication plus détaillée du fonctionnement des statechains Mercury est accessible ici. Ce progrès dans la Mercury Layer constitue une avancée colossale par rapport à la première implémentation de la statechain. Toutefois, contrairement à la première mise sur le marché du portefeuille Mercury, cette version ne se présente pas sous la forme d’un portefeuille prêt à l’emploi pour le consommateur. Elle est lancée sous forme de bibliothèque et d’outil CLI, que d’autres portefeuilles peuvent intégrer. Voici un résumé rapide de leur fonctionnement :

Les statechains sont essentiellement analogues aux canaux de paiement à bien des égards, c’est-à-dire qu’elles représentent un UTXO partagé de manière collaborative avec, comme mécanisme de dernier recours, une transaction pré-signée permettant aux personnes d’appliquer leur droit de propriété. La principale différence entre un canal Lightning et une statechain réside dans les parties impliquées dans le partage collaboratif de l’UTXO et dans la façon dont la propriété d’une revendication 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 statechain est ouverte avec un facilitateur/opérateur et peut être librement transférée dans son intégralité entre deux participants, qui acceptent de faire confiance à l’opérateur pour son honnêteté, entièrement hors chaîne. Une personne désireuse de charger une statechain collabore avec l’opérateur pour créer une clé publique unique dont le créateur et l’opérateur détiennent chacun une part de la clé privée correspondante, sans qu’aucun des deux n’ait une copie complète de la clé. Ils pré-signent alors une transaction permettant au créateur de réclamer ses pièces après un verrouillage temporel de manière unilatérale. Pour transférer une statechain, le propriétaire actuel collabore avec le destinataire et l’opérateur pour signer une preuve cryptographique avec leur part de clé, attestant qu’ils transfèrent la pièce, puis le destinataire et l’opérateur génèrent une nouvelle paire de parts de clés qui s’ajoutent à la même clé privée et signent une transaction verrouillée dans le temps pour le nouveau propriétaire avec un verrouillage temporel plus court que l’original (pour s’assurer qu’ils peuvent utiliser la leur plus tôt que les propriétaires précédents). Ce processus est répété à chaque transfert jusqu’à ce que le verrouillage temporel ne puisse plus être raccourci, moment auquel la statechain doit être clôturée on-chain. Les propriétaires transfèrent toute la chaîne historique des états passés avec chaque transfert afin que les utilisateurs puissent vérifier que les verrouillages temporels ont été correctement décrémentés et que l’opérateur les a horodatés en utilisant Mainstay, une variante d’Opentimestamps où chaque donnée a son propre « emplacement » unique dans l’arbre de Merkle pour garantir qu’une seule version des données est horodatée. Cela permet à tout le monde d’auditer l’historique des transferts d’une statechain.

L’impact du Mercury Layer sur l’achat de cartes cadeaux avec des cryptomonnaies

La grande nouveauté que Mercury Layer apporte à la version originale des statechains est le blinding. L’opérateur du service de statechain ne sera plus en mesure d’apprendre quoi que ce soit sur 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 les transactions pré-signées nécessaires pour revendiquer vos fonds de manière unilatérale. En introduisant une variante aveugle de Schnorr MuSig2, Mercury peut faciliter le processus de signature de transaction de sortie sans apprendre aucun détail de ce qu’ils signent. Cela nécessite quelques changements de conception pour tenir compte du fait que l’opérateur ne peut plus voir et publier l’intégralité de l’historique des transferts d’une statechain. Ils ne sont même pas capables de valider la transaction qu’ils sont en train de signer. Dans la version précédente, l’unicité d’un propriétaire de statechain/ensemble de transactions en cours était attestée par l’opérateur par la publication de l’intégralité de l’historique des transferts de la statechain 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 un nouveau mode d’attestation par l’opérateur de la propriété actuelle de la statechain. Toutes ces données sont entièrement poussées vers un modèle de validation côté client. L’opérateur se contente de suivre le nombre de fois où il a signé quelque chose pour une seule statechain et communique ce nombre à un utilisateur lorsqu’il le demande. L’utilisateur reçoit ensuite les transactions des états passés de statechain de la part de l’utilisateur qui lui envoie, et vérifie entièrement côté client que le nombre de transactions correspond à ce que l’opérateur a affirmé, puis vérifie complètement que les signatures sont toutes valides et que les verrouillages temporels ont été correctement décrémentés à chaque fois. Au lieu de publier les transactions complètes de l’état de la statechain et l’ordre de transfert à Mainstay, car il est conçu pour être ignorant de toutes ces informations, il publie sa part de la clé publique (pas la clé publique agrégée complète) pour l’utilisateur actuel de chaque statechain. Cela permet à tout utilisateur recevant une statechain de vérifier l’historique des transferts et l’état actuel est légitime contre les données de transaction envoyées par l’expéditeur. Le serveur de l’opérateur suit les statechains uniques pour compter les signatures passées en attribuant à chaque statechain un identifiant aléatoire lors de la création, stocké avec sa dénomination et ses parts de clé privée et publique (pas la clé publique agrégée complète). Le nouveau schéma de coordination pour le partage et le nouveau partage de la clé est réalisé de manière à ce que le serveur passe sa part de la clé à l’utilisateur, et les données nécessaires pour un nouveau partage sont aveuglées de sorte que le serveur est incapable d’apprendre la part de clé publique complète de l’utilisateur, lui permettant de créer la clé publique agrégée complète et d’identifier la pièce on-chain. La conception ne permet même pas à l’opérateur de savoir quand il a signé une clôture 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 pour distinguer les deux cas l’un de l’autre. Cela est cependant sûr pour les utilisateurs qui pourraient être attaqués par quelqu’un essayant de « dépenser en double » une statechain hors chaîne en fournissant une fausse transaction qui ne pourrait être réglée. Premièrement, cet utilisateur verrait on-chain que l’UTXO soutenant cette statechain a été dépensé. Deuxièmement, l’historique des transactions, parce que l’opérateur doit signer toutes les mises à jour des états, 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 en sachant qu’elle n’est pas légitime. Les statechains permettent également de « mettre en place » des canaux Lightning sur la statechain en faisant en sorte que la statechain verse à une adresse multisig entre deux personnes, et que les deux négocient un ensemble conventionnel de transactions d’engagement Lightning par-dessus. Il faudrait clore la statechain on-chain avant de clore le canal Lightning, donc il faudrait utiliser des durées de verrouillage temporel plus longues pour les paiements Lightning, mais sinon, cela fonctionnerait parfaitement normalement.

L’impact des statechains de Mercury sur l’écosystème des cryptomonnaies

Avec les améliorations importantes de la confidentialité de la nouvelle itération des statechains, et la possibilité de les combiner 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 changements radicaux récents dans la dynamique du mempool et la pression résultante sur les frais. Cela offre les mêmes avantages de liquidité que l’Arche, c’est-à-dire pouvoir être librement transférable sans nécessiter de liquidité réceptive, mais contrairement à l’Arche, est en direct et fonctionnel aujourd’hui. Il s’agit sans aucun doute d’un modèle de confiance différent de quelque chose comme Lightning seul, mais pour les gains massifs en flexibilité et évolutivité, c’est certainement une possibilité à explorer.