Comment fonctionnent les chaînes spatiales Bitcoin – Bitcoin Magazine
L’idée des chaînes latérales en tant que mécanisme de mise à l’échelle et d’extension de fonctionnalités pour Bitcoin est un concept très ancien. Une sorte d’idée « ancêtre » de base des sidechains, fusionner les chaînes minéesremonte même avant la disparition de Satoshi.
Cette proposition était simplement l’idée de deux chaînes complètement séparées et indépendantes exploitées par le même groupe de mineurs, sans possibilité de déplacer quoi que ce soit entre les chaînes. La proposition de sidechain originale a été créé en 2014 par de nombreuses personnes qui ont ensuite fondé Blockstream littéralement une semaine environ après la publication de l’article. L’idée de base était de pouvoir faire aller et venir les pièces entre la blockchain principale de Bitcoin et d’autres chaînes latérales, avec de simples preuves de vérification de paiement (SPV) utilisées pour prouver que les choses sont valides lorsque vous envoyez des pièces d’une chaîne à l’autre. Cela ne s’est jamais concrétisé en raison de la complexité de la mise en œuvre autour des réorganisations de la chaîne, du potentiel de vol et des risques de centralisation minière (tout cela peut être lu dans la section quatre du Livre blanc Bitcoin).
Les mécanismes de cheville pour les chaînes latérales peuvent être de deux variétés, unidirectionnelles et bidirectionnelles. Les significations doivent être évidentes – dans une cheville bidirectionnelle, les pièces peuvent aller et venir entre la chaîne parente et la chaîne latérale, et dans une cheville unidirectionnelle, elles ne peuvent que se déplacer de la chaîne parente à la chaîne latérale et ne jamais reculer. Actuellement, la seule forme de pegs de sidechain bidirectionnels mis en œuvre sur Bitcoin est par consensus fédéré, ce qui signifie que le peg est garanti par un ensemble de «dépositaires» de confiance qui conservent le contrôle des fonds rattachés à la sidechain dans un portefeuille multisig jusqu’à ce qu’ils soient retirés.
Les gens, cependant, ont continué à travailler sur d’autres conceptions de chevilles de sidechain qui ne sont pas fédérées. Ici, je vais passer par la proposition Spacechain de Ruben Somsen comme exemple. Il s’agit d’un mécanisme de cheville à sens unique utilisant une conception de mine à fusion aveugle, similaire à Paul Stztorc‘s. Cela signifie que les pièces ne peuvent entrer que dans la sidechain et ne jamais en sortir, et que les mineurs n’ont pas à exécuter de nouveau logiciel pour obtenir une compensation pour l’exploitation de la sidechain (cependant, comme j’y reviendrai plus tard, ils peuvent en bénéficier davantage).
La proposition de chaîne spatiale
L’extraction par fusion oblige les mineurs à exécuter les nœuds de la chaîne Bitcoin et de toute autre chaîne qu’ils exploitent, afin de compiler les blocs pour les deux chaînes et de s’y engager dans l’en-tête de bloc Bitcoin qu’ils exploitent. L’extraction par fusion aveugle profite du fait qu’en réalité, les mineurs de Bitcoin n’ont vraiment besoin que de l’en-tête de bloc de l’autre chaîne pour s’engager dans leur bloc Bitcoin, quelqu’un d’autre peut en fait prendre la peine de mettre en place le bloc pour l’autre chaîne.
Le mécanisme proposé par Somsen pour cela peut utiliser ANYPREVOUT (APO) pour permettre une concurrence ouverte pour que quiconque puisse concourir pour construire le prochain bloc de chaîne latérale tout en garantissant qu’un seul bloc peut être engagé par bloc de chaîne principale Bitcoin. Un autre avantage de la proposition de Ruben est qu’elle ne nécessite pas de soft fork spécifique pour permettre la possibilité de déployer des chaînes spatiales. Eltoo / ANYPREVOUT est proposé pour les avantages du Lightning Network, permettant des chaînes d’état flexibles, ainsi que des usines de canaux. Les chaînes spatiales sont simplement une autre possibilité des nombreuses choses pour lesquelles l’activation d’ANYPREVOUT ouvrirait la voie.
L’idée générale de sa proposition de fusion aveugle est que, en utilisant APO, vous pouvez prédéfinir un long ensemble de transactions qui prennent le même UTXO initial et s’engagent à toujours le recréer. Alors, imaginez un seul satoshi UTXO, chaque transaction pré-créée garantissant que ce même UTXO est recréé en tant que sortie une fois confirmé. Considérez-le comme une sorte de marqueur, cet UTXO spécial est l’identifiant qui permet à quiconque regarde la blockchain principale de Bitcoin de savoir : « C’est là que je trouve un engagement envers les blocs de sidechain X ». Cela laisse cependant un problème ouvert : les frais des mineurs. Si cet UTXO doit être recréé avec le même montant, il n’y a pas de fonds pour payer les frais.
Cela peut être traité en utilisant SIGHASH_SINGLE (la signature d’une entrée ne signe que cette seule entrée et la sortie correspondante) et SIGHASH_ANYONECANPAY (les gens peuvent librement ajouter des entrées et des sorties supplémentaires sans invalider la signature tant que l’entrée/sortie utilisant SIGHASH_SINGLE est laissée telle quelle, pour ne pas invalider cette signature). Ensuite, n’importe qui peut ajouter une entrée et modifier la sortie pour payer les frais de mineur pour la transaction.
C’est également le mécanisme utilisé pour valider l’en-tête de bloc du bloc sidechain. De la même manière que Taproot s’engage dans l’arbre des différentes conditions de dépenses en modifiant la clé publique normale avec la racine Merkle de l’arbre, n’importe qui peut modifier la clé publique normale avec le hachage d’en-tête de bloc du bloc sidechain. Les nœuds de la chaîne latérale peuvent ensuite révéler et relayer cet en-tête de bloc avec un pointeur vers la transaction dans la chaîne principale pour prouver qu’il a bien été miné. À partir de là, les nœuds de la chaîne latérale effectueraient toute la validation normale pour s’assurer que le bloc de la chaîne latérale suit les règles de consensus appropriées et relaient les blocs réels sur le réseau de la chaîne latérale, tout comme sur la chaîne principale.
Si l’une des transactions utilisées pour valider les blocs de la chaîne latérale sur la chaîne principale a été utilisée pour valider un bloc invalide, ou même des données complètement inutiles, alors lorsque les nœuds de la chaîne latérale voient la transaction de validation utilisée sur la chaîne, deux choses peuvent se produire : premièrement, un bloc invalide sera propagé à travers le réseau sidechain, et s’il ne réussit pas les contrôles de validation, il sera orphelin ; ou deux, les données ne sont jamais révélées, auquel cas le prochain bloc de sidechain s’appuiera sur le dernier bloc réellement révélé et s’y engagera, et l’engagement non révélé sera ignoré. Cette deuxième possibilité suit le même type de logique de chaîne la plus longue que la chaîne principale, donc même si quelque chose a été révélé plus tard, il sera toujours orphelin à cause des futurs blocs qui ne se sont pas construits dessus.
Mais il reste le problème de la double dépense. Toute personne disposant de la clé privée utilisée pour générer le marqueur UTXO pourrait potentiellement doubler l’une des transactions prédéfinies utilisées pour s’engager dans les blocs de sidechain et invalider l’ensemble complet à partir de ce moment.
Ceci est résolu en insérant réellement la signature dans le script de verrouillage de l’UTXO lui-même. Cela verrouille la signature sur l’entrée et la sortie, garantissant la recréation du marqueur UTXO dans la prochaine transaction l’utilisant. Étant donné que cette signature va être automatiquement transmise et vérifiée lorsque l’UTXO est dépensé, il n’est pas possible de simplement la remplacer par une autre et de la dépenser vers une destination différente.
Cela laisse un dernier problème en suspens. Il serait possible, en théorie, de soumettre plusieurs transactions à la suite dans un seul bloc Bitcoin, de sorte qu’un grand nombre de blocs de chaîne latérale soient confirmés par les mineurs, le tout dans un seul bloc de chaîne principale. Cela pourrait être abusé pour attaquer par déni de service le réseau sidechain.
Afin de résoudre ce problème, un verrou temporel relatif CHECKSEQUENCEVERIFY (CSV) peut être inséré dans le script du marqueur UTXO pour garantir qu’une seule transaction utilisant le marqueur UTXO peut être confirmée à l’intérieur d’un seul bloc de chaîne principal donné.
En tout ça ressemble à ça :
Il convient également de noter que deux variantes de cette conception peuvent être implémentées avec CHECKTEMPLATEVERIFY (CTV) ou sans aucun changement. Ces deux variantes de conception ont simplement des compromis sous-optimaux.
La variante CTV utiliserait cette fonctionnalité pour s’engager dans la chaîne de transactions utilisant CTV au lieu d’APO avec le hack incluant la signature à l’intérieur du script de verrouillage UTXO. CTV s’engage sur toutes les sorties d’une transaction dépensant l’UTXO CTV, mais il ne s’engage sur aucune entrée en dehors de lui-même.
Cela signifie que vous pouvez ajouter des entrées, mais pas des sorties, à une transaction CTV. Vous pouvez donc apporter vos propres frais comme dans la conception APO, mais vous ne pouvez pas ajouter d’engagement à l’en-tête du bloc sidechain.
Donc, ce que nous devons faire ici, c’est créer une transaction complètement en dehors de la chaîne des transactions CTV pour l’engagement de la chaîne latérale de créer un UTXO qui est juste suffisant pour payer les frais de la transaction CTV (car vous ne pouvez pas créer une nouvelle sortie de changement dans cette transaction, 100 % de l’entrée que vous ajoutez va aux frais), et à l’intérieur de la transaction préparant les frais, UTXO est l’endroit où nous nous engageons dans un en-tête de bloc sidechain. Donc, première étape : une transaction créant une sortie payante et un engagement envers un en-tête de bloc de sidechain. Deuxième étape : nous prenons la sortie des frais et l’ajoutons en tant qu’entrée à la transaction CTV, qui, une fois confirmée, « exploite » notre bloc de sidechain spécifique. Cette variante ressemble à ceci :
La variante suivante utilise simplement des transactions pré-signées. Il pourrait être déployé aujourd’hui, mais en raison des limites de ce que le script peut faire, il nécessite que tous les frais pour les transactions soient payés à l’avance par celui qui crée la chaîne spatiale.
La chaîne de transactions commence par un seul UTXO et, dans une chaîne, crée deux sorties. La première sortie est le marqueur UTXO, qui signale que la chaîne de transactions est liée à une chaîne spatiale spécifique, la seconde est un UTXO de petite valeur qui peut être dépensé ouvertement par quiconque permettant d’y attacher une autre entrée/sortie. Cette deuxième transaction est l’endroit où n’importe qui peut s’engager ouvertement à être le premier à dépenser cette deuxième sortie de la chaîne de transaction de la chaîne spatiale et à l’utiliser pour s’engager dans son en-tête de bloc de chaîne latérale.
Dans la variante CTV, le bloc sidechain devait être engagé dans une transaction secondaire car CTV ne permet pas d’ajouter de nouvelles sorties dans une transaction dépensant une entrée verrouillée par CTV. Cette variante nécessite l’utilisation d’une transaction secondaire car si vous ajoutez de nouvelles entrées ou sorties à la chaîne pré-signée, vous modifierez le TXID de la transaction et invaliderez toutes les transactions pré-signées qui la suivent. Cette variante ressemble à ceci :
Le seul inconvénient de cette dernière variante est que si celui qui a pré-signé toutes les transactions à utiliser pour les engagements de bloc de sidechain ne supprime pas les clés privées utilisées pour le faire, il peut effectivement arrêter la chaîne en dépensant le marqueur actuel UTXO à tout moment. temps.
Et voila. Il s’agit de la proposition la plus récente pour une conception de chaîne latérale sur Bitcoin, et elle peut être mise en œuvre de trois manières différentes, avec la mise en garde évidente que le chemin de mise en œuvre qui peut être fait maintenant a le problème d’exiger que quelqu’un supprime une clé privée.
Cet article est simplement le premier d’une série relative aux principales propositions de conception de sidechain qui ont été publiées pour Bitcoin depuis la conception originale de 2014. Gardez un œil sur le reste.
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.