Statechains est un protocole de deuxième couche original développé à l’origine par Ruben Somsen en 2018, selon la proposition Eltoo (ou Symétrie LN). En 2021, une variation de la proposition originale, Mercury, a été construite par CommerceBlock. En 2024, une itération supplémentaire du schéma de mercure d’origine a été construite, Mercury Layer.
Le protocole Statechain est un peu plus compliqué à discuter par rapport à d’autres systèmes tels que Ark ou Lightning en raison de la gamme de variations possibles entre la conception proposée originale, les deux qui ont été réellement mises en œuvre et d’autres conceptions possibles qui ont été lâchement proposées.
Comme ARK, Statechains dépend d’un serveur de coordination centralisé afin de fonctionner. Contrairement à ARK, ils ont un modèle de confiance légèrement différent de celui d’un Vutxo dans un lot Ark. Ils dépendent du serveur de coordination pour supprimer les partages générés précédemment d’une clé privée afin de rester sans confiance, mais tant que le serveur suit le protocole défini et le fait, ils fournissent une forte garantie de sécurité.
L’idée générale d’une Statechain est de pouvoir transférer la propriété d’un UTXO entier entre différents utilisateurs hors chaîne, facilité par le coordinateur. Il n’est pas nécessaire de recevoir des liquidités comme la foudre, ou le serveur de coordinateur pour fournir une liquidité comme ARK.
Pour commencer, nous examinerons le protocole original proposé par Ruben Somsen.
La Statechain originale
Statechains est effectivement une transaction pré-signée permettant au propriétaire actuel de la Statechain de se retirer unilatéralement à la chaîne quand ils le souhaitent, et un historique a signé des messages prouvant cryptographiquement que les propriétaires antérieurs et les récepteurs qu’ils ont envoyés par Statechain pour approuver ces transferts.
La conception d’origine a été construite sur Eltoo à l’aide de AnyPrevout, mais les plans actuels sur la façon d’activer les mêmes fonctionnalités utilisent CheckTempAthersify et ChecksigFromStack (une explication de haut niveau à la fin de l’article ChecksigFromStack). L’idée de base est un script permettant une transaction pré-signée pour dépenser n’importe quel UTXO qui a ce script et verrouille la quantité appropriée de Bitcoin, plutôt que d’être lié à la dépense d’un seul UTXO spécifique.
Dans le protocole, un utilisateur souhaitant déposer ses pièces à un serveur de coordinateur Statechain approche d’un serveur de coordinateur et passe par un protocole de dépôt. L’utilisateur de dépôt, Bob, génère une clé qui sera la propriété unique par lui, mais aussi une deuxième clé «transitoire» qui sera finalement partagée (plus à ce sujet bientôt). Ils élaborent ensuite une transaction de dépôt verrouillant leur pièce à un multisig nécessitant la clé du coordinateur et la clé transitoire pour signer.
En utilisant ce multisig, Bob et le coordinateur signent une transaction qui dépense cette pièce de monnaie et crée un UTXO qui peut être dépensé par toute autre transaction signée par la clé transitoire et la clé du coordinateur en utilisant la symétrie LN, soit la clé unique de Bob après un timelock. Bob peut désormais financer le multisig avec le montant approprié, et la Statechain a été créée.
Pour transférer une Statechain à Charlie, Bob doit passer par un processus en plusieurs étapes. Tout d’abord, Bob signe un message avec sa clé privée unique qui atteste du fait qu’il va transférer la Statechain à Charlie. Charlie doit également signer un message attestant du fait qu’il a reçu le Statechain de Bob. Enfin, le serveur de coordinateur doit signer une nouvelle transaction permettant à Charlie de réclamer unilatéralement la Statechain en chaîne avant que Bob n’envoie une copie de la clé transitoire.
Tout cela est fait atomique à l’aide de signatures d’adaptateur. Ce sont des signatures qui sont modifiées de manière à utiliser un élément de données aléatoire qui les rend invalides, mais qui peuvent être rendus valides une fois que le support de la signature reçoit cette information. Tous les messages et la nouvelle transaction pré-signée sont signés avec des signatures d’adaptateur, et ont été atomiquement valides en même temps grâce à la publication des données de l’adaptateur.
Les détenteurs d’une StateChain doivent croire que le serveur de coordinateur ne conspire jamais avec un propriétaire précédent pour signer une fermeture immédiate de la Statechain et voler des fonds au propriétaire actuel, mais la chaîne de messages pré-signés peut prouver qu’un coordinateur a participé au vol s’ils le faisaient. Si un ancien propriétaire tente d’utiliser sa transaction pré-signatée pour voler les fonds, le TimeLock sur le chemin de dépenses en utilisant uniquement sa clé permet au propriétaire actuel de soumettre leur transaction pré-signée et de réclamer correctement les fonds sur chaîne.
Couche de mercure et de mercure
L’architecture StateChain originale nécessite un Softfork pour fonctionner. CommerceBlock a conçu leur variante de Statechains pour fonctionner sans Softfork, mais pour le faire, des compromis ont été effectués en termes de fonctionnalité.
L’idée de base est la même que la conception d’origine, tous les utilisateurs détiennent une transaction pré-signée qui leur permet de réclamer leurs fonds unilatéralement, et le serveur de coordinateur joue toujours un rôle dans la facilitation des transferts hors chaîne qui nécessitent qu’ils leur fassent confiance pour se comporter honnêtement. Les deux différences principales sont la façon dont ces transactions sont signées et la structure des utilisateurs de transactions pré-signées est donnée.
En ce qui concerne la signature, il n’y a plus de clé privée transitoire qui est transmise de l’utilisateur à l’utilisateur. Au lieu de cela, un protocole de computation multipartite (MPC) est utilisé pour que le propriétaire d’origine et le serveur de coordinateur puissent générer en collaboration des pièces partielles d’une clé privée sans que l’un ou l’autre ne possède jamais la clé complète. Cette clé est utilisée pour signer les transactions pré-signées. Le protocole MPC permet au propriétaire actuel et au coordinateur de s’engager dans un deuxième protocole avec un tiers, le récepteur d’un transfert, pour régénérer différentes pièces qui s’additionnent à la même clé privée. Dans le protocole Mercury et Mercury Layer, après avoir terminé un transfert, un serveur de coordinateur honnête supprime le matériau clé correspondant au propriétaire précédent. Tant que cela est fait, il n’est plus possible pour le coordinateur de signer une transaction avec un propriétaire précédent, car le nouveau morceau de matériel clé qu’ils ont n’est pas compatible avec la pièce que tout propriétaire précédent pourrait encore avoir. Il s’agit en fait d’une garantie plus forte, tant que le coordinateur est honnête, que la proposition originale.
La structure de transaction pré-signée pour le mercure et la couche de mercure ne peut pas utiliser la symétrie LN, car ce n’est pas possible sans Softfork. Au lieu de cela, CommerceBlock a choisi d’utiliser des timelocks décrémentants. La transaction pré-signatée du propriétaire d’origine est élaborée à l’aide de Nlocktime à un moment loin à l’avenir par rapport au point de la création de Statechain. Comme chaque utilisateur ultérieur reçoit le Statechain lors d’un transfert, la valeur Nlocktime de sa transaction est une durée prédéterminée plus courte que le propriétaire précédent. Cela garantit qu’un propriétaire précédent est incapable d’essayer même de soumettre sa transaction sur la chaîne avant que le propriétaire actuel ne le puisse, mais cela signifie également qu’à un moment donné, le propriétaire actuel doit Fermez leur Statechain en chaîne avant que les transactions des propriétaires précédents ne commencent à devenir valides.
La principale différence entre le mercure et la couche de mercure est la façon dont ces transactions sont signées. Dans le cas de Mercury, le serveur de coordinateur voit simplement la transaction proposée, la vérifie, puis la signe. Mercury Layer utilise un protocole de signature aveugle, ce qui signifie qu’ils ne voient pas réellement les détails de la transaction qu’ils signaient. Cela nécessite le suivi du serveur StateChains à l’aide d’enregistrements anonymisés sur le serveur, et une clé d’autorisation spéciale du propriétaire actuel afin qu’ils puissent être sûrs qu’ils ne signent que des transferts valides.
Synergie avec d’autres couches
StateChains peut synergie avec d’autres couche 2 qui sont basées sur des transactions pré-signées. Par exemple, une partie de la proposition d’origine suggère une combinaison de statechains et de canaux de foudre. Parce que les deux ne sont que des transactions pré-signées, il est possible de nidiquer un canal Lightning au-dessus d’une StateChain. Cela nécessite simplement que la clé de sortie unilatérale du propriétaire actuel soit un multisig et la création des transactions pré-signées dépenser qui sortent dans un canal Lightning. Cela permet à l’ouverture des canaux de foudre et à la fermeture entièrement hors chaîne.
D’une manière similaire, il est possible de nicher une Statechain au-dessus d’un Vutxo dans un lot Ark. Cela nécessite simplement les transactions pré-signées nécessaires à la construction d’une Statechain, passant la sortie Vutxo.
Emballage
Statechains n’est pas entièrement sans confiance, mais ils sont un schéma de très efficace minimisé qui est très efficace et permet de transférer librement UTXOS hors de la chaîne entre tous les utilisateurs désireux d’accepter le modèle de confiance des statechains.
Bien que la proposition d’origine n’ait pas encore été construite, les deux implémentations conçues par CommerceBlock ont été complètement mises en œuvre. Les deux n’ont rien fait de plus qu’une utilisation marginale dans le monde réel. Que cela soit dû au fait que les utilisateurs ne veulent pas accepter le modèle de confiance impliqué, ou simplement un échec en marketing ou en sensibilisation est quelque chose qui ne peut pas être pleinement vérifié.
Quoi qu’il en soit, étant donné qu’il existe deux implémentations complètes et conceptions pour une variation plus flexible si la symétrie LN est devenue possible sur Bitcoin, c’est une option qui sera toujours là. La bonne chose à propos des logiciels open source est qu’il sera toujours là, que les gens l’utilisent maintenant, s’ils le choisissent à l’avenir.