Ceci est un éditorial d’opinion de Shinobi, un éducateur autodidacte dans l’espace Bitcoin et hôte de podcast Bitcoin orienté technologie.
Dans cet article suivant qui examine différentes conceptions d’implémentation de sidechain, nous allons passer en revue les softchains. C’est un autre de Ruben Somsenles propositions d’un mécanisme de sidechain. Cela diffère fortement des chaînes spatiales, la conception abordée dans mon article précédent. Il nécessite une modification spécifique du protocole Bitcoin Core spécifiquement structuré pour implémenter une sidechain, impose un nouveau coût de validation sur les nœuds complets Bitcoin et prend en charge un mécanisme de rattachement bidirectionnel qui ne dépend pas d’une fédération pour détenir des fonds.
Le bloc de construction
Le cœur de l’idée s’appuie sur une proposition antérieure de Somsen appelée preuves de fraude PoW, un mécanisme visant à améliorer la sécurité de la vérification simplifiée des paiements (SPV) pour les portefeuilles. L’idée s’appuie sur une simple observation à propos d’une blockchain – si un bloc invalide est produit, il y aura probablement une bifurcation dans la blockchain car tout mineur honnête existant refusera de construire sur le bloc invalide et éventuellement d’en exploiter un valide. Un bloc invalide produit et aucun fork créé par des mineurs honnêtes signifie essentiellement qu’il y a eu une panne complète dans le processus de consensus du réseau, de sorte que les chances statistiques que cela se produise sont insignifiantes. Par conséquent, un fork qui se produit peut être vu comme une sorte de signal indiquant que « Hé, quelque chose aurait pu se passer ici, vous devriez donc vérifier cela. » Les clients pourraient utiliser des fourches comme celle-ci comme une sorte d’alarme indiquant qu’ils devraient réellement télécharger ces blocs et vérifier ce qui se passe.
Cela pose cependant un problème fondamental – pour vérifier un bloc, vous devez avoir un ensemble UTXO. Pour avoir un ensemble UTXO, vous devez avoir vérifié tous les blocs précédents de la chaîne pour le construire. Alors, comment cela fonctionne-t-il en tant que mécanisme SPV ? La réponse est les engagements définis par UTXO.
Chaque bloc doit être validé par rapport à l’ensemble UTXO, une base de données de chaque bitcoin existant qui n’a pas encore été dépensé et actuellement, il ne s’agit que d’une base de données locale que chaque nœud construit et enregistre au fur et à mesure qu’il parcourt la blockchain depuis le début. Un engagement d’ensemble UTXO prend l’ensemble UTXO, en construit un arbre Merkle et, idéalement, en engage le hachage à l’intérieur de chaque bloc. Cela vous permet de recevoir un bloc avec des données supplémentaires – une branche Merkle pour chaque entrée de chaque transaction prouvant qu’elle se trouvait dans le dernier engagement d’ensemble UTXO – et de le vérifier de cette façon. Si un système utilisait un tel schéma d’engagement dès le début, et qu’il était effectivement utilisé par un grand nombre d’utilisateurs vérifiant entièrement la chaîne, alors ils fourniraient une garantie de sécurité presque équivalente à un nœud complet. Chaque fois qu’une séparation de chaîne se produit, vous pouvez télécharger tous les blocs impliqués et vous assurer que la chaîne que vous suivez est valide. Si les deux côtés de la division sont valides, le plus long gagne toujours. Cependant, si l’un d’entre eux était invalide, cela vous permettrait de le détecter immédiatement.
La cheville à double sens
Dans le cadre de la conception de la chaîne logicielle, les nœuds de la chaîne principale devraient télécharger et valider les en-têtes de bloc pour chaque chaîne logicielle, et dans le cas de tout téléchargement en chaîne et valider ces blocs à l’aide des engagements définis par UTXO. Cela constituerait la base du mécanisme de rattachement pour permettre un rattachement à double sens. Pour migrer les pièces vers la sidechain, l’utilisateur doit créer une transaction de chaîne principale en les attribuant à une chaîne logicielle spécifique, puis pointer vers cette transaction lorsqu’il est confirmé qu’il réclame des pièces sur la sidechain. Inversement, vous feriez le contraire lorsque vous tenteriez de sortir de la sidechain. C’est là que les preuves de fraude PoW entrent en jeu. Lors d’un pegout, l’idée est de créer une transaction sur la chaîne principale faisant référence à une transaction de retrait sur la chaîne latérale. Ces pièces ne deviendraient utilisables qu’après une longue fenêtre de confirmation (disons un an) et resteraient « verrouillées dans la softchain » si la transaction de retrait sur la sidechain était réorganisée ou jugée invalide. Ce dernier serait découvert car en cas de scission de chaîne, le nœud de la chaîne principale téléchargera tous les blocs de chaque côté de la scission et les vérifiera à l’aide des engagements définis par UTXO.
La longue fenêtre de confirmation pour les pégouts est telle que même un infime pourcentage de mineurs honnêtes peut avoir suffisamment de temps pour produire un seul bloc valide divisant la chaîne et déclenchant une validation de tout à partir de ce point avec les engagements définis par UTXO. Cela permet aux nœuds de la chaîne principale d’attraper les attaches frauduleuses de la chaîne latérale avant que le retrait ne soit confirmé sur la chaîne principale, invalidant ainsi cette transaction sans les obliger à valider l’intégralité de la chaîne latérale – ce qui ne serait pas différent d’une augmentation de la taille des blocs.
Paramètres de sécurité et risques
Cette conception crée des questions en termes de niveau de sécurité basé sur certaines variables et comment une telle chaîne latérale interagirait avec les mineurs. Tout d’abord, toute chaîne logicielle doit être déployée avec une exigence de difficulté minimale pour les blocs, de sorte que si le taux de hachage devient trop bas au lieu de la difficulté à s’ajuster en dessous de ce minimum de blocs sur la chaîne latérale, cela prendrait simplement plus de temps à trouver – c’est-à-dire que l’intervalle de bloc serait augmenter. Cela est nécessaire en raison des nœuds de la chaîne principale de validation anti-fraude PoW qui doivent être exécutés dans le cadre de cette conception. Si la difficulté de la chaîne logicielle est trop faible, il deviendrait alors facile pour les mineurs de bifurquer régulièrement la chaîne logicielle de manière malveillante et d’effectuer efficacement une attaque par déni de service (DoS) contre les nœuds de la chaîne principale en augmentant la quantité de données supplémentaires qu’ils faut valider.
L’exploitation minière fusionnée est une solution à ce problème. Si tous les mineurs de Bitcoin ont également miné des blocs sur la chaîne latérale, le problème des attaques DoS sur la chaîne principale en créant des divisions de chaîne sur la chaîne logicielle est résolu à peu près aussi bien que possible. Il faudrait autant de travail pour diviser la chaîne logicielle que pour la chaîne principale, empêchant les attaques arbitraires et à faible coût d’augmenter la quantité de données nécessaires pour valider la chaîne principale. Cependant, en résolvant le problème d’attaque DoS, cela crée un autre problème : l’augmentation du coût de validation des mineurs.
Si les mineurs vont également exploiter les chaînes logicielles, ils doivent exécuter les nœuds pour eux afin de s’assurer que les blocs qu’ils exploitent sont valides. S’ils ne le sont pas, ils courent le risque de devenir orphelins et de perdre les revenus des frais d’un bloc invalide. Si de nombreuses chaînes logicielles coûteuses à vérifier étaient activées, telles que les chaînes de clones Ethereum ou les grandes chaînes de blocs, cela pourrait rendre l’exploitation minière plus centralisée et coûteuse à participer. Les mineurs doivent valider une chaîne pour savoir qu’ils ne construisent pas sur un bloc invalide et perdre de l’argent, donc ce n’est pas vraiment facultatif. Rendre la validation plus coûteuse compromet les efforts visant à maximiser la décentralisation de l’exploitation minière.
Le plus gros problème est le risque qu’un bogue consensuel sur une chaîne logicielle provoque en fait une scission consensuelle de la chaîne principale elle-même. Il existe un risque que des réorganisations majeures de la chaîne latérale invalident une transaction de rattachement valide du côté de la chaîne latérale, alors que le côté de la chaîne principale est sur le point de devenir valide. N’oubliez pas que les nœuds de la chaîne principale suivent également les en-têtes de la chaîne logicielle. Cela pourrait conduire à la scission de la chaîne principale si différentes parties du réseau se trouvent de différents côtés d’une division de chaîne logicielle à droite, car un ancrage de chaîne latérale est en cours de validation sur la chaîne principale. Des bogues de consensus non déterministes sur la chaîne logicielle pourraient également provoquer une scission de la chaîne principale, c’est-à-dire si certains nœuds voyaient un rattachement comme invalide mais que d’autres le voyaient comme valide.
Cette connexion plus profonde avec le consensus de la chaîne principale rend cette conception de chaîne latérale quelque peu risquée et potentiellement quelque chose qui ne devrait pas être fait. À tout le moins, les chaînes logicielles devraient être activées une par une dans des fourches individuelles, au lieu de déployer une seule fourche qui permettrait aux chaînes logicielles d’être lancées à volonté. Le fait que dans cette conception, les divisions de chaîne obligent les nœuds de la chaîne principale à vérifier davantage de données fait de la possibilité d’activer simplement de nombreuses chaînes logicielles en même temps un vecteur d’attaque sur la chaîne principale.
Les chaînes logicielles s’impliquent davantage dans la couche de consensus de la chaîne principale que les chaînes spatiales, ce qui comporte de nombreux risques, mais elles permettent un ancrage bidirectionnel natif et donc plus de place potentielle pour différents cas d’utilisation. Ensuite, je passerai en revue les chaînes de transmission, puis quelques réflexions finales sur les chaînes latérales en général.
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.
Source https://bitcoinmagazine.com/technical/softchains-use-cases-and-security-costs
