script : Une critique courante de Segregated Witness est qu'il est "inutilement complexe". Pourquoi est-il choisi plutôt que des alternatives ?


J’ai récemment plongé profondément dans l’étude de la technologie Bitcoin, et je vais essayer d’y répondre rétrospectivement.

SegWit a été conçu dans les limites d’une contrainte clé  : vous ne ferez pas de hard-fork ; ce qui signifie que la spécification du consensus Bitcoin ne pourrait que devenir plus stricte, pas moins. En d’autres termes, seuls les changements consensuels en douceur auraient été pris en compte.

Avec cette contrainte à l’esprit, SegWit est une solution à laquelle vous arriveriez logiquement si vous vouliez résoudre les deux problèmes clés en même temps  :

script : Une critique courante de Segregated Witness est qu'il est

  • Limite de taille de bloc
  • Malléabilité des transactions
  • ce qui était le cas à cette époque de l’histoire du Bitcoin.

    Limite de taille de bloc

    faire valider les données par des nœuds mis à niveau et avoir un hachage ancré quelque part dans l’ancien 1 Mo bloquer afin que l’intégrité de la blockchain reste stricte. Une solution aurait été d’avoir simplement une sorte d’espace de bloc étendu, qui pourrait être spécifié avec une nouvelle limite de taille ou un algorithme qui l’ajusterait. Cela nécessiterait de résoudre ces 2 problèmes :

    • Le déplacement du BTC de l’espace de 1 Mo vers l’espace de bloc étendu devrait être considéré comme une opération valide du point de vue des nœuds non mis à niveau
    • Le déplacement de BTC de l’espace de bloc étendu vers l’espace de 1 Mo devrait également être considéré comme une opération valide du point de vue des nœuds non mis à niveau

    Cela pourrait être résolu en déclarant un modèle de script de verrouillage que tout le monde peut dépenser comme une adresse magique qui contiendra l’enregistrement des soldes déplacés vers le bloc d’extension et toutes les transactions qui déplacent BTC entre les 2 espaces encodent les points d’entrée/sortie afin que ces migrations les transactions sont considérées comme valides par les nœuds non mis à niveau. Les nœuds mis à niveau empêcheraient quelqu’un de simplement prendre les fonds comme s’il s’agissait vraiment de n’importe qui peut dépenser, et les nœuds non mis à niveau essayant de voler l’adresse verraient leurs transactions rejetées pour des raisons inconnues. Ce type de solution a en fait été proposé et rejeté au moment où SegWit était en discussion.

    Cela aurait été plus complexe que SegWit pour de nombreuses raisons et cela introduirait un autre problème clé pour les nœuds non mis à niveau  : ils n’auraient pas la bonne vue de l’état UTXO. Ils verraient simplement cette adresse de boîte noire où BTC entre et revient parfois, ils n’auraient aucune idée de qui possède le BTC à l’intérieur de la boîte noire (l’espace de blocs étendu).

    SegWit ne souffre pas de ces problèmes, car il ne change pas la définition de l’état UTXO et il ne change pas la vue des transformations d’état UTXO pour les nœuds non mis à niveau. Ils continueraient à voir la vision correcte de CE QUI a changé, mais ils n’auraient plus la vision correcte de POURQUOI cela a changé parce qu’ils ne verraient plus le « témoin ». alors SegWit est le contournement maximal possible de la limite « dure » de 1 Mo. Tout autre contournement nécessiterait une approche comme celle décrite ci-dessus.

    Malléabilité des transactions

    le « témoin » aurait pu être « séparé », mais il n’aurait pas été nécessaire de le séparer en dehors de la transaction ou de l’espace de bloc « dur » de 1 Mo. Il aurait pu rester à l’intérieur pour que tout soit moins complexe car il aurait suffi de le séparer uniquement de la préimage de la signature, de sorte que toute la transaction, à l’exception de la signature elle-même, puisse être couverte par la signature. Cela aurait évité de toucher à l’arborescence de Merkle, et la modification aurait été contenue dans les règles de validation des transactions. Ainsi, résoudre à lui seul la malléabilité des transactions aurait pu être moins complexe que SegWit, mais ce n’était pas le seul objectif de la mise à niveau.

    Conclusion sur SegWit

    En adoptant l’approche consistant à déplacer uniquement les données d’entrée quelque part pour résoudre (1.), il est devenu presque « libre » de résoudre (2.) si naturellement que la voie de la résolution de la malléabilité des transactions a été empruntée. Certaines décisions de conception alternatives, telles que des choix particuliers d’encodage ou le choix de sha256 contre sha256d, pourraient être discutées, mais à un niveau élevé,: la mise à niveau être soft-fork uniquement et maintenir une vue cohérente de l’ensemble UTXO et de ses transformations d’état.

    Remarque sur le FUD que tout le monde peut dépenser

    Lorsque SegWit faisait l’objet de discussions intenses, les gens soulevaient la possibilité que quelqu’un vole les fonds si le hashrate de SegWit tombait, car du point de vue des nœuds non mis à niveau, le BTC verrouillé dans les adresses SegWit serait gratuit pour la prise. Ce n’est pas possible, car ce ne sont pas seulement les nœuds miniers qui ont été mis à niveau  : après l’activation, les nouvelles règles de consensus sont appliquées par tous les nœuds, même les nœuds non miniers, et ils rejetteraient directement les transactions violant les nouvelles règles même si elles avaient plus de 51% de puissance de hachage.

    Je pense que la seule possibilité de vol aurait été par une réorganisation rejouant les transactions SegWit post-activation et les faisant extraire dans un bloc de pré-activation afin qu’elles soient considérées comme valides par les nouveaux nœuds, mais cela a été atténué par une activation élevée au seuil.

    Ceci est très similaire à P2SH BIP-0016, où quelqu’un pourrait affirmer que tous les hachages P2SH avec des scripts de rachat connus seraient gratuits, ce qui n’est tout simplement pas vrai.

    Une fois activé, la restauration du P2SH BIP-0016 ou du SegWit BIP-0141 nécessiterait un hard-fork. Convaincre tous les nœuds non mis à niveau restants de suivre une chaîne qui n’applique pas de nouvelles règles nécessiterait 51 % de puissance de hachage, mais cette chaîne ne serait pas BTC puisque la plupart des nœuds ont été mis à niveau, de sorte que l’attaquant hypothétique à 51 % perdrait des quantités extrêmes. d’argent, rendant l’attaque sur les nœuds non mis à niveau pratiquement impossible.

    Remarque sur les fourches rigides

    Si la contrainte de soft-fork avait été levée, alors l’espace des solutions alternatives deviendrait plus grand, et il y aurait des opportunités pour des solutions plus efficaces et moins complexes au détriment de la rupture de la rétrocompatibilité avec les nœuds non mis à niveau tout en étant rétro- compatible avec les logiciels non-nœuds tels que les portefeuilles, les indexeurs, etc. Cependant, je pense que discuter de ceux-ci sort du cadre de la question et peut être considéré comme hors sujet ici.