Les chaînes de transmission autorisent les mineurs de nœuds Sidechain BlockBlog
Ceci est un éditorial d’opinion de Shinobi, un éducateur autodidacte dans l’espace Bitcoin et hôte de podcast Bitcoin orienté technologie.
Cette fois, je vais m’effondrer et discuter du fonctionnement des chaînes de transmission ; elles ont été initialement proposées en 2015. De toutes les propositions discutées jusqu’à présent, les chaînes de transmission sont les plus anciennes et les plus étoffées en termes de détails de mise en œuvre et de conception spécifiques, documentées dans les BIP. 300 et 301. Paul Sztorc, le créateur du concept, avait quelques principaux objectifs de conception en tête, et bien que ce ne soit pas du tout exhaustif, en voici quelques-uns :
- Isolez chaque chaîne latérale afin que toute défaillance ou problème n’affecte que ceux qui l’utilisent.
- Autoriser les sidechains à tourner sans avoir besoin d’un nouveau fork pour chacun.
- Activez le transfert de bitcoin dans et hors d’une sidechain avec une cheville bidirectionnelle.
- Autoriser l’expérimentation gratuite dans la conception, espère-t-il, rendrait obsolète le besoin d’altcoins.
L’ensemble de la conception comporte deux aspects principaux, c’est pourquoi il existe deux BIP distincts. Le premier est le mécanisme de cheville (BIP300), qui permet le fonctionnement de la cheville à double sens. Sztorc a conçu quelque chose appelé un séquestre de taux de hachage, qui, dans les termes les plus élémentaires, permet aux mineurs en tant que groupe amorphe de conserver collectivement les pièces dans toutes les chaînes latérales. Le second est un schéma minier fusionné « à l’aveugle », où l’objectif est de permettre aux mineurs de bitcoins d’être les producteurs de blocs à un niveau consensuel sans avoir à valider la chaîne latérale pour le faire. Ces deux pièces présentent ensemble un mécanisme de rattachement bidirectionnel et un moyen pour les mineurs de bitcoins de participer à l’exploitation des chaînes latérales tout en essayant d’atténuer le risque de centralisation qu’il présente.
BIP300 spécifie la logique pour la proposition d’une nouvelle sidechain, l’activation d’une nouvelle sidechain, la proposition d’un ensemble groupé de retraits, l’approbation d’un tel ensemble de retraits, la logique de validation pour les transactions de retrait réelles et la validation pour les transactions de dépôt.
L’activation d’une nouvelle chaîne latérale dans le cadre de la proposition de chaîne de transmission est très similaire au processus d’un soft fork activé par la signalisation du mineur. La principale différence est, bien sûr, qu’il ne s’agit pas réellement d’un soft fork – un seul fork pour activer les règles de consensus de la chaîne de transmission permet aux mineurs, à tout moment, de signaler l’activation d’une nouvelle chaîne latérale. dans règles de consensus de la chaîne de transmission. Pour proposer l’activation d’une nouvelle sidechain, un mineur doit placer une donnée OP_RETURN dans sa sortie coinbase qui comprend un identifiant unique pour cette sidechain, une clé publique à utiliser dans les opérations de dépôt, des données de version, des descriptions lisibles par l’homme et des hachages du logiciel client et l’historique de GitHub (il n’y a pas d’application de consensus ici, juste des données à référencer par les humains).
Lorsqu’un mineur propose d’activer une nouvelle sidechain et d’inclure toutes les données nécessaires dans sa coinbase, cela devient une sorte de période de « signalisation du mineur » concernant l’opportunité de créer ou non cette nouvelle sidechain du point de vue du consensus de la chaîne principale. Un mineur peut utiliser un format spécial pour inclure une proposition dans ses sorties coinbase, et d’autres mineurs peuvent créer une autre sortie suivant un deuxième format pour signaler l’activation. Une nouvelle proposition de sidechain nécessite que 90 % des blocs dans une période de difficulté signalent l’activation afin qu’une nouvelle création de sidechain soit confirmée. Cela crée le mécanisme de cheville pour activer la sidechain, mais l’interaction entre la sidechain et la mainchain est plus nuancée que cela.
À ce stade, n’importe qui peut ancrer des pièces dans la sidechain. Pour se connecter à la sidechain, un utilisateur crée simplement une transaction à deux entrées avec sa propre entrée et l’UTXO correspondant au solde de la sidechain avec une seule sortie attribuant tout à la sidechain. Cela garantit que la sidechain n’a jamais qu’un seul UTXO contenant tous les fonds qui y sont bloqués. Les retraits sont gérés par le vote des mineurs. La chaîne principale ne sait pas qui possède quoi sur la chaîne latérale, et la chaîne principale considérera comme valide tout retrait approuvé par les mineurs dans le cadre du mécanisme de vote. Pour cette raison, il y a un long délai dans le processus de retrait. Il y a deux phases dans le processus de retrait d’une sidechain : une proposition de retrait (bundle), puis la phase de vote de retrait. Les mineurs doivent créer une sortie OP_RETURN dans leur transaction coinbase avec un hachage de la transaction de retrait proposée pour proposer un retrait. Ce hachage, cependant, similaire à sighash, signale qu’il ne s’engage que sur une partie d’une transaction au lieu de l’ensemble. Il ne s’engage pas sur l’UTXO d’entrée qui représente les fonds bloqués dans une chaîne de transmission ou sur la sortie qui renvoie tout ce qui n’est pas retiré vers une chaîne latérale UTXO spéciale. En effet, tout dépôt dans la chaîne de transmission créerait un nouvel UTXO et invaliderait ainsi l’engagement envers la transaction de retrait lorsque les gens seraient allés la valider.
À partir de là, la période de vote des mineurs sur la proposition de retrait commence. Une fois qu’un bundle a été proposé, les mineurs peuvent voter pour l’approuver ou non. Chaque bloc extrait permet à ce mineur d’incrémenter un compteur d’approbation, vers le haut ou vers le bas d’un, ou deux pour s’abstenir de faire quoi que ce soit. Il y a quelques limitations spécifiques en plus de cela, car il est possible d’avoir plus d’un bundle pour une seule sidechain – si un mineur choisit de voter « oui » (augmenter le compteur d’un) pour un bundle de retrait pour une sidechain, il devoir votez « non » (diminuez le compteur de un) pour chaque autre bundle associé à cette sidechain spécifique.
Il s’agit de garantir qu’il n’y a pas de « doubles retraits », où quelqu’un a une sortie en plusieurs lots qui lui rapporterait plus de bitcoins sur la chaîne principale que ce qui lui est dû.
De l’autre côté, les mineurs sont également autorisés à voter non pour chaque paquet proposé. Ceci est censé fonctionner comme une sorte d’alarme pour tout le monde qu’un mineur validant ces retraits (en s’assurant qu’il s’agit de pièces légitimement détenues sur la sidechain retirée) a remarqué que quelque chose d’invalide se produisait. N’oubliez pas qu’un point clé de cette conception est que les mineurs n’ont pas à valider quoi que ce soit sur la sidechain, donc à moins qu’ils ne choisissent de le faire de toute façon, de nombreux mineurs peuvent voter pour des bundles qu’ils ne vérifient pas. Cette fonction d’alarme est conçue pour qu’ils soient avertis qu’ils doivent vérifier les forfaits pour s’assurer qu’aucun retrait frauduleux ne se produit.
Une fois qu’un bundle a atteint le seuil requis (13 150 blocs, soit environ 90 jours), la transaction traitant réellement le retrait devient valide et peut être confirmée. Mais que font les gens si les mineurs approuvent un retrait frauduleux qui vole de l’argent à la sidechain ? La proposition de Sztorc est de s’engager dans un soft fork activé par l’utilisateur (UASF) pour invalider la transaction de rattachement invalide. Cela présente un risque énorme en termes de consensus pour la chaîne principale. L’UASF en 2017 était une décision à haut risque qui a à peine réussi et Bitcoin était beaucoup plus petit qu’il ne l’est aujourd’hui. Plus Bitcoin grandit, plus ces actions seront difficiles à coordonner.
Si vous vous souvenez de l’article sur les chaînes spatiales, cette conception était basée sur l’exploitation minière fusionnée à l’aveugle (BMM). La conception BMM de Ruben Somsen est en fait la deuxième variante de cela, la première étant la conception de Sztorc telle qu’énoncée dans BIP301. La spécification BMM dans les chaînes de transmission est composée de deux messages : un message de demande et un message d’acceptation. Les deux sont coordonnés respectivement via un type de transaction spécial sur la chaîne principale et une sortie spéciale dans la transaction coinbase d’un mineur.
La transaction de demande est construite par celui qui crée les blocs sidechain. L’intérêt de BMM est que cette personne peut être quelqu’un qui n’exploite pas, donc la transaction de demande est là pour leur permettre de payer les mineurs pour confirmer leur bloc de sidechain proposé. La proposition de bloc de sidechain construit une transaction qui inclut le hachage du bloc de sidechain, l’ID attribué à la sidechain lors de sa création et les quatre derniers octets de l’en-tête de bloc de la chaîne principale précédente. Trois règles consensuelles supplémentaires s’appliquent à ces types de transactions. Tout d’abord, une transaction de demande n’est pas valide à moins qu’il n’y ait également une sortie d’acceptation correspondante dans la transaction coinbase de ce bloc. Cela garantit que les mineurs ne peuvent pas percevoir de frais sur la demande sans également accepter et exploiter le bloc sidechain. Deuxièmement, pour chaque sidechain, une seule transaction de demande est autorisée à être incluse dans un bloc de chaîne principale. Cela permet de s’assurer qu’un seul bloc de n’importe quelle chaîne latérale peut réellement être extrait par bloc de la chaîne principale. Enfin, les quatre derniers octets du bloc de la chaîne principale précédente doivent correspondre. Cela garantit qu’une demande n’est valide que pour être minée dans le bloc suivant, et que de telles transactions ne peuvent pas être minées plus tard et voler de l’argent à un proposant de bloc sidechain après que le bloc de quelqu’un d’autre a été miné.
La sortie accept est très simple : les données d’en-tête du message et le hachage du bloc sidechain. Si un mineur exécute lui-même un nœud de chaîne de transmission, il peut simplement ignorer les transactions de demande et toujours inclure sa propre sortie d’acceptation dans sa coinbase pour exploiter ses propres blocs de chaîne latérale. Ensemble, ces deux aspects permettent aux mineurs d’exploiter eux-mêmes un nœud de sidechain, ou à un autre non-mineur de le faire et de payer le mineur pour exploiter leurs blocs. L’idée est que, si les mineurs eux-mêmes ne gèrent pas les sidechains et supportent les coûts de validation supplémentaires, alors quelqu’un d’autre peut le faire pour eux. S’il y a de la concurrence chez les non-mineurs essayant de gagner des frais sur la sidechain, ils continueront probablement d’enchérir sur les frais qu’ils sont prêts à payer aux mineurs dans leur transaction de demande jusqu’à ce qu’ils représentent la majorité des frais qu’ils gagnent, avec les non- mineur ne gardant qu’un petit pourcentage des bénéfices et payant le reste aux mineurs.
C’est la mécanique derrière le fonctionnement des chaînes de transmission. Ensuite, les chaînes latérales fédérées, puis, après cela, une ventilation de tous les inconvénients et inconvénients que chaque conception peut avoir.
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.