AUTEUR ORIGINAL : SHINOBI

Compilation originale : Bloc licorne

Malgré la portée de la proposition, quelle est la raison pour laquelle la « grande récupération de script » de Rusty Russell pourrait être la voie à suivre pour le développement de Bitcoin ?

Bloc licorne Note : Rusty Russell est un développeur actif dans la communauté Bitcoin et est très respecté dans la communauté. Il a beaucoup travaillé sur le développement du noyau Linux et a été impliqué dans de nombreux projets de développement long Bitcoin de base.

Bitcoin a été conçu à l’origine pour avoir un langage de script complet conçu pour couvrir et support tous les cas d’utilisation de sécurité potentiels que les utilisateurs pourraient rencontrer à l’avenir. Comme Satoshi Nakamoto l’a dit avant sa disparition :

"L’essence de Bitcoin est qu’une fois la version 0.1 publiée, la conception de base est déterminée pour le reste du cycle de vie. Par conséquent, je voulais le concevoir pour le support de tous les types de trading possibles auxquels je pouvais penser. Le problème est que tout nécessite des codes de support spéciaux et des champs de données, qu’ils soient utilisés ou non, ce qui conduit à des cas particuliers plus longs. La solution est un script qui généralise le problème afin que les deux parties puissent décrire leurs transactions avec des conditions spécifiques que le réseau Nœud évalue ou valide en fonction de ces conditions. - Satoshi Nakamoto, 17 juin 2010

Son but est de donner aux utilisateurs un langage suffisamment commun pour qu’ils puissent organiser leurs types de transactions comme ils le souhaitent. C’est-à-dire des courts métrages permettant aux utilisateurs de concevoir et d’expérimenter la façon d’écrire leurs propres pièces.

Avant de disparaître, Satoshi Nakamoto a supprimé 15 de ces codes d’opération, les a entièrement désactivés et a ajouté une limite stricte sur la pile du moteur de script qui limitait la taille des blocs de données pouvant être manipulés (520 octets). C’est parce qu’il s’est planté, laissant derrière lui de nombreuses façons dont des scripts complexes pourraient être utilisés pour mener des attaques DOS sur l’ensemble du réseau (envoyant un grand nombre de demandes de spam, provoquant la panne du réseau), créant des transactions énormes et coûteuses qui feraient planter les nœuds.

Ces codes d’opération n’ont pas été supprimés parce que Satoshi Nakamoto pensait que les fonctionnalités étaient dangereuses ou que les gens ne devraient pas les utiliser pour construire quelque chose qui pourrait être réalisé, mais simplement (du moins en surface) en raison du risque qu’ils représentent pour l’ensemble du réseau sans contraintes de ressources, tels que les pires coûts de validation qu’ils pourraient imposer au réseau sans limitations.

Depuis lors, chaque mise à niveau de Bitcoin a fini par être une optimisation fonctionnelle des fonctionnalités restantes, corrigeant d’autres défauts moins graves que Satoshi Nakamoto nous a laissés, et élargissant la fonctionnalité de notre sous-ensemble de script restant.

Excellente récupération de script

Lors de la conférence Austin Bitcoin ++ début mai, le développeur principal de Lightning Network, Rusty Russell, a fait une proposition très radicale dans son premier discours à la conférence, où il a essentiellement eu l’idée de réactiver le grand code d’opération que Satoshi Nakamoto avait désactivé avant sa disparition en 2010.

Dans les années qui ont suivi l’activation de Taproot en 2021 (Taproot est une mise à niveau majeure de Bitcoin qui vise à améliorer la confidentialité, la sécurité et l’évolutivité), l’espace de développement a en fait été un peu sans but. Nous savons tous que Bitcoin n’est pas assez évolutif pour vraiment fournir des services auto-souverains à une taille importante de la population mondiale, et peut même ne pas être en mesure de fournir une évolutivité aux fournisseurs de services qui peuvent surpasser les très grands dépositaires et fournisseurs de services, et ne peuvent pas vraiment se libérer des contraintes longues des gouvernements, d’une manière qui minimise la confiance ou la garde.

Cet article souligne le niveau technique de Bitcoin, qui n’est pas une question à débattre. La question qui mérite d’être débattue est de savoir comment corriger cette faille, qui est un sujet très controversé. Depuis l’introduction de Taproot, tout le monde a proposé des propositions très étroites visant à résoudre des problèmes qui ne peuvent être résolus que pour des cas d’utilisation spécifiques.

Par exemple, ANYPREVOUT (APO) est une proposition qui permet de réutiliser les signatures dans différentes transactions, aussi longues que le script et le montant saisis sont les mêmes, et cette proposition est spécifiquement conçue pour optimiser le Lightning Network et ses versions plus longues. CHECKTEMPLATEVERIFY (CTV) est une proposition qui exige que les pièces sonnantes et trébuchantes ne soient dépensées que par des transactions qui correspondent exactement à des transactions prédéfinies, et cette proposition est conçue pour étendre la fonctionnalité des chaînes de transactions pré-signées en les rendant totalement fiables. OP_VAULT est spécialement conçu pour définir un « délai d’expiration » pour une solution de stockage à froid, afin que les utilisateurs puissent « annuler la récupération » du stockage à froid en l’envoyant vers des paramètres de long plus froids afin d’éviter que leurs Clé secrète ne soient compromis.

Il y a d’autres propositions plus longues, mais je pense que vous avez déjà compris l’essentiel. Au cours des dernières années, chaque proposition a été conçue pour augmenter légèrement l’évolutivité ou améliorer une seule petite fonctionnalité, car cela est considéré comme souhaitable. C’est la raison profonde pour laquelle ces discussions n’ont pas progressé. Personne n’était satisfait des autres propositions parce qu’elles ne répondaient pas aux cas d’utilisation qu’ils souhaitaient.

Personne d’autre que le parrain de la proposition ne croit qu’une proposition est suffisamment complète pour être considérée comme une prochaine étape raisonnable.

C’est la logique qui sous-tend « Great Script Recovery ». En poussant et en analysant une récupération complète des scripts, comme Satoshi Nakamoto l’a conçu à l’origine, nous pouvons réellement essayer d’explorer l’ensemble des courts métrages dont nous avons besoin, plutôt que de nous disputer et de nous battre pour savoir quelles petites extensions de fonctionnalités sont assez bonnes pour le moment.

OPCODES (Code d’opération)

• OP_CAT : prend deux éléments de données de la pile et les additionne pour former une seule donnée.
• OP_SUBSTR : Accepte un paramètre de longueur (en octets), récupère une donnée de la pile, supprime les octets de cette longueur et remet sur la pile.
• OP_LEFT et OP_RIGHT : accepte un paramètre de longueur qui prend un élément de données de la pile et supprime les octets de la longueur spécifiée d’un côté ou de l’autre.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT et OP_DOWNSHIFT : accepte un élément de données et effectue les opérations binaires correspondantes sur celui-ci.
• OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV et OP_MOD : opérateurs mathématiques pour les opérations de multiplication, de division et de modulo (renvoyant le reste de la division).

En plus de la liste ci-dessus des codes d’opération à récupérer, Rusty Russell propose trois autres codes d’opération conçus pour simplifier la combinaison de différents codes d’opération :

OP_CTV (ou TXHASH/équivalent Code d'opération) : permet l’application précise de certaines parties d’une transaction qui doivent être exactement prédéfinies.

CSFS : permet de vérifier les signatures, pas seulement pour l’ensemble de la transaction, ce qui nécessite que certaines parties du script ou des données utilisées soient signées dans l’ordre pour être exécutées.

OP_TWEAKVERIFY : valide les opérations basées sur Schnorr qui impliquent des Clé publique, telles que l’ajout ou la soustraction d’Clé publique individuels du Clé publique agrégé. Cela peut être utilisé pour s’assurer que lorsqu’une partie laisse unilatéralement une sortie de transaction partagée inutilisée (UTXO), tous les fonds des autres participants sont envoyés à une clé publique agrégée qui ne nécessite pas la signature de la partie sortante pour effectuer des dépenses coopératives.

Pourquoi faisons-nous cela ?

Layer 2 réseaux sont essentiellement des extensions de la couche de base de Bitcoin, et ils sont fonctionnellement limités par les fonctions de la couche de base. Lightning Network nécessite trois Soft Fork distincts avant de pouvoir être réellement implémenté : CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) et SegWit (Segregated Witness).

Sans une couche de base plus flexible, vous ne pouvez pas construire un réseau de couche 2 plus flexible. Le seul raccourci est de faire confiance aux tiers, ce qui est très simple et direct, et j’espère que nous aspirons tous à supprimer autant que possible les tiers de confiance de tous les aspects de l’interaction avec Bitcoin à grande échelle.

Nous devons être en mesure de faire quelque chose qui n’est actuellement pas possible dans l’ordre pour fusionner en toute sécurité plus de deux personnes dans une seule sortie de transaction inutilisée (UTXO) et être en mesure de fonctionner sans confiance sur la couche de base. La flexibilité actuelle de Bitcoin Script n’est pas suffisante. Au niveau le plus élémentaire, nous avons besoin de contrats, et nous avons besoin de scripts qui peuvent réellement appliquer des détails plus fins sur l’exécution des transactions pour s’assurer qu’un utilisateur quittant en toute sécurité son propre UTXO ne met pas les fonds des autres utilisateurs en danger.

D’un point de vue plus élevé, voici ce dont nous avons besoin :

Introspection : Nous devons être en mesure de vérifier des détails spécifiques sur la pile concernant la transaction de dépense elle-même, tels que « cette somme d’argent ira à cette clé publique d’une sortie ». Cela me permet de retirer mes fonds par moi-même en utilisant ma propre branche Taproot spécifique, tout en m’assurant que je ne peux pas retirer les fonds de quelqu’un d’autre. Le script exécuté garantira que les fonds des autres propriétaires sont renvoyés à l’adresse constituée de la clé publique des autres utilisateurs, au cas où d’autres participants entraîneraient une perte de fonds.

Transfert de données : Disons que nous prenons le concept d’un seul UTXO, par exemple, avec un grand nombre de personnes, que n’importe qui peut aller et venir à sa guise. Dans ce cas, nous avons besoin d’un moyen de suivre qui a le plus ou le moins d’argent, généralement en utilisant l’arbre de Merkle et ses racines. Cela signifie que lorsque quelqu’un part, nous devons nous assurer d'«enregistrer » qui a droit à quoi dans le cadre du changement UTXO pour les fonds de tous les autres. Il s’agit essentiellement d’une utilisation spécifique de l’introspection.

Modification de la clé publique : nous devons nous assurer que les modifications apportées à la clé publique agrégée peuvent être vérifiées sur la pile. Dans le système de partage UTXO (Unused Transaction Output), notre objectif est de faciliter la coopération et le flux efficace de fonds grâce à une clé publique agrégée qui inclut tous les participants. Lorsque quelqu’un quitte unilatéralement un UTXO partagé, nous devons supprimer sa clé publique personnelle de la clé publique agrégée. Si toutes les combinaisons possibles ne sont pas calculées au préalable, la seule option consiste à vérifier que la soustraction d’une clé publique de la clé publique agrégée produira une clé publique valide composée des clés publiques individuelles restantes.

Comme je l’ai dit plus haut, la raison de la désactivation de tous ces codes d’opération est de faire face aux attaques DOS (qui provoquent le plantage du réseau en envoyant un grand nombre de demandes de spam), ce qui peut provoquer le plantage des nœuds qui composent le réseau. Une façon de résoudre ce problème est de limiter la quantité de ressources pouvant être utilisées par l’un de ces codes d’opération.

En ce qui concerne la vérification de signature, la partie la plus coûteuse du script Bitcoin, nous disposons déjà d’une telle solution, appelée budget d’opération de signature (sigops). Chaque utilisation du code d’opération de vérification de signature consomme un certain « budget », c’est-à-dire le nombre d’opérations de signature autorisées par bloc, ce qui fixe une limite stricte au coût qu’une transaction peut générer pour valider un bloc.

Taproot change cette façon de travailler, en n’utilisant pas plus long une seule limite de bloc globale, mais à la place chaque transaction a sa propre limite sigops (opération de signature), proportionnelle à la taille de la transaction. Cela équivaut essentiellement à la même limite globale, mais il est plus facile de comprendre que chaque transaction a longs moins de sigops disponibles.

La modification de la limite sigops (opération de signature) de Taproot pour le traitement de chaque transaction ouvre la possibilité d’une approche de généralisation, ce que Rusty Russell a suggéré en termes de limites varops. L’idée est d’attribuer un coût à chaque code d’opération réactivé pour tenir compte du pire scénario que chaque code d’opération peut créer, c’est-à-dire le coût de calcul le plus élevé encouru au moment de la validation. De cette façon, chaque code d’opération aura sa propre limite « sigops », limitant la quantité de ressources qu’il peut consommer pendant le processus de validation. Cela sera également basé sur la taille de toutes les transactions qui utilisent ces codes d’opération, de sorte que l’inférence peut être facilitée tout en s’accumulant jusqu’à la limite globale implicite par bloc.

Cela résoudrait l’attaque DOS (en envoyant beaucoup de demandes de spam, provoquant le plantage du réseau) à cause de ces transactions de spam, et ce qui a amené Satoshi Nakamoto à désactiver initialement tous ces codes d’opération.

Un élan pour aller de l’avant

Je suis sûr que les plus anciens d’entre vous penseront : « C’est trop de changement. » Je peux comprendre cela, mais je pense qu’un aspect important à comprendre en tant que proposition, c’est que nous n’avons pas à tout faire. La valeur de cette proposition n’est pas nécessairement que toutes ces fonctionnalités soient entièrement restaurées, mais que nous allons examiner de manière holistique une vaste suite de composants fondamentaux et nous demander ce que nous voulons vraiment en termes de fonctionnalités.

Il s’agirait d’un changement complet par rapport aux trois dernières années de chamailleries et de débats, car nous n’avons discuté que de petits changements étroits qui n’ont que certaines fonctions. C’est comme une place où tout le monde peut se réunir et regarder dans la direction de l’avenir. Peut-être que nous finirons par restaurer toutes ces fonctionnalités, ou peut-être que nous finirons par en activer quelques-unes, car le consensus est que ce sont celles que nous convenons tous qu’elles doivent être activées.

Quel que soit le résultat final, il peut s’agir d’un changement qui a un impact positif sur l’ensemble de la conversation sur notre orientation future. Nous pouvons en fait cartographier et obtenir une image complète de la situation, plutôt que de nous frayer un chemin à tâtons en débattant de la route trouble à suivre.

Ce n’est en aucun cas le chemin que nous devons emprunter, mais je pense que c’est la meilleure chance pour nous de décider de la voie que nous voulons emprunter. Il est temps de recommencer à travailler ensemble de manière pratique et productive.