Vitesse et confidentialité dans les transactions Bitcoin : l’alternative à Lightning

CommerceBlock, une société spécialisée dans les solutions avec actifs numériques et Bitcoin, a présenté Mercury Layer, un protocole de deuxième couche pour les transactions Bitcoin. Semblable, mais pas identique, au réseau Lightning, Mercury représente une amélioration par rapport à la mise en œuvre initiale des chaînes d’état par cette société.

Les chaînes d’état Bitcoin sont des deuxièmes couches qui fonctionnent en collaboration, avec un seul opérateur, et peut être librement transféré entre n’importe quelle paire de participants. Sur le réseau Lightning, les canaux de paiement sont établis de manière statique entre deux participants, créant ainsi une connexion directe entre eux. Ces canaux nécessitent une ouverture et une fermeture en chaînece qui signifie que la transaction initiale et la fin du canal doivent être enregistrées sur la chaîne principale Bitcoin.

L’innovation clé de Mercury, dont le serveur de test a été ouvert au publicest l’introduction d’une technique appelée « cécité » (aveuglant), avec lequel l’opérateur ne peut plus connaître les détails spécifiques des transactions, tels que les TXID (identifiants de transaction), les clés publiques et les signatures. Ceci est réalisé grâce à une variante aveugle de Schnorr MuSig2 (Schnorr multi-signatures), qui permet de signer des transactions sans que l’opérateur connaisse les détails.

Gestion des transactions dans Mercury Layer

Au lieu de s’appuyer sur la chaîne Bitcoin principale, les chaînes d’état sont partagées de manière collaborative hors chaîne. Le processus de transfert implique une collaboration entre le propriétaire actuel, le destinataire et l’opérateur, en utilisant des clés et des signatures partagées pour démontrer le transfert de propriété.

Concernant ce point, Mercury facilite le transfert de propriété d’UTXO individuels contrôlé par une clé publique unique d’une partie à l’autre sans nécessiter de transaction sur la blockchain Bitcoin ni de modification des conditions de dépenses, explique le site Internet du projet. Le SE (Statechain Operator) permet ce changement de propriété sans avoir la possibilité de saisir, confisquer ou geler la production. Pour y parvenir, la clé privée est partagée entre le SE et le propriétaire, de sorte qu’aucune des parties ne connaisse la clé privée complète.

Le serveur de l’opérateur assure le suivi des chaînes d’état uniques en leur attribuant des identifiants aléatoires, ce qui l’aide à maintenir la coordination. De plus, l’aveuglement des transactions offre une couche supplémentaire de confidentialité en garantissant que le commerçant ne connaît pas les détails sensibles.

Une fonctionnalité également pertinente est la possibilité de placer les canaux du réseau Lightning « au-dessus » de la chaîne d’états. Cela permet une grande polyvalence, donnant aux utilisateurs la possibilité d’effectuer des transactions Lightning via Mercury.

Mercury Layer améliore son itération initiale

Une différence clé entre la version initiale de Mercury Wallet et la mise à jour annoncée est que La première version a été conçue comme un portefeuille entièrement prêt à l’emploi.. Au lieu de cela, la version actuelle, Mercury Layer, adopte une approche différente.

Au lieu d’être présenté comme un portefeuille prêt pour l’utilisateur final, Mercury Layer est publié sous la forme d’une bibliothèque et d’un outil de ligne de commande (CLI). Ceci signifie que Il est fourni sous la forme d’un ensemble de ressources et de fonctionnalités que d’autres portefeuilles existants peuvent intégrer. sur leurs propres interfaces et plateformes.

Une explication plus profonde

Grâce à un publication Sur son compte officiel sur le réseau social X (anciennement Twitter), Nicholas Gregory, PDG de CommerceBlock, a fourni d’autres détails techniques sur le fonctionnement de Mercury Layer. Plus précisément, il explique le contrat de verrouillage utilisé dans Mercury Layer.

Ce contrat réduit la durée de vie utile d’une pièce de 8 heures à chaque transaction. Ce processus est basé sur le paramètre nLockTime dans les transactions, conçues pour améliorer la sécurité et réduire le risque qu’un ancien propriétaire puisse détourner les fonds du propriétaire actuel.

De plus, détaille Gregory, lorsque le serveur Mercury Layer n’est pas disponible, la question se pose de savoir comment déterminer qui est le propriétaire légitime actuel d’une pièce et qui a le droit de récupérer ses fonds. Pour résoudre ce problème, chaque transaction comprend une transaction de sauvegarde, qui est essentiellement une transaction pré-signée qui permet au propriétaire actuel de récupérer les fonds de manière indépendante, sans dépendre du serveur.

Dans les situations où deux propriétaires tentent de récupérer la même pièce, le propriétaire dont l’horodatage de la transaction se situe dans la fenêtre de temps valide prévaut. Cette validité est déterminée par le nLockTime, qui diminue constamment à chaque changement de devise d’état. Un tel système garantit que seul le propriétaire légitime actuel, sur la base de la période la plus récente et la plus valide, peut réclamer avec succès la monnaie de l’État.