Alors que la portée des propositions est assez large, quelle pourrait être la raison pour laquelle la « Grande récupération de script » de Rusty Russell est considérée comme la voie à suivre pour le développement de Bitcoin ?

Note du bloc de licorne : Rusty Russell est un développeur actif dans la communauté Bitcoin et est très respecté en son sein. Il a apporté des contributions remarquables au développement du noyau Linux et a participé à divers projets de développement du noyau Bitcoin.

Lorsque Bitcoin a été initialement conçu, il incluait un langage de script complet destiné à couvrir et à soutenir tout cas d'utilisation de sécurité potentiel que les utilisateurs pourraient proposer à l'avenir. Comme l'a déclaré Satoshi Nakamoto avant de disparaître :

“La nature de Bitcoin est telle que une fois la version 0.1 a été publiée, la conception de base a été figée pour le reste de sa durée de vie. Pour cette raison, je voulais la concevoir pour prendre en charge tous les types de transactions auxquels je pouvais penser, mais dans les versions ultérieures, nous avons supprimé la possibilité d'exécuter des scripts arbitraires. Le problème était que chaque fonctionnalité nécessitait des codes de support spéciaux et des champs de données, qu'ils soient utilisés ou non, ce qui a conduit à trop de cas spéciaux. La solution a été le script, qui a généralisé le problème de telle sorte que les transactions puissent décrire leurs conditions d'une manière qui leur est spécifique, et les nœuds du réseau peuvent évaluer et valider ces conditions.” - Satoshi Nakamoto, 17 juin 2010

Le but principal était de donner aux utilisateurs un langage suffisamment générique pour leur permettre d'organiser leurs types de transactions selon leurs souhaits. En d'autres termes, cela donne aux utilisateurs l'espace pour concevoir et expérimenter la manière dont ils écrivent leur propre argent.

Avant sa disparition, Satoshi Nakamoto a supprimé 15 opcodes, les désactivant complètement, et a ajouté une limite stricte sur la taille des blocs de données pouvant fonctionner sur la pile du moteur de script (520 octets). Cela était dû au fait qu'il avait effectivement commis une erreur, laissant derrière lui de nombreuses façons dont des scripts complexes pourraient potentiellement être utilisés pour mener des attaques DOS sur l'ensemble du réseau (envoi de grandes quantités de requêtes indésirables, provoquant la paralysie du réseau), créant ainsi des transactions énormes et coûteuses susceptibles de faire planter des nœuds.

Ces opcodes n'ont pas été supprimés parce que Satoshi Nakamoto les considérait comme dangereux, ou parce que les gens ne devraient pas les exploiter pour construire ce qu'ils pourraient, mais simplement (du moins en apparence) parce qu'ils représentaient un risque pour l'ensemble du réseau sans limites de ressources, et pourraient donc imposer les pires coûts de vérification sur le réseau sans restrictions.

Depuis lors, chaque mise à niveau de Bitcoin a finalement été une optimisation des fonctionnalités restantes, corrigeant d'autres défauts moins graves laissés par Satoshi Nakamoto et étendant la fonctionnalité du sous-ensemble de scripts qui nous sont restés.

Super récupération de script

Lors de la conférence Bitcoin++ à Austin début mai, Rusty Russell, développeur principal du Lightning Network, a fait une proposition très radicale lors de sa première intervention à la conférence. Il a essentiellement proposé de réactiver la plupart des opcodes désactivés par Satoshi Nakamoto avant sa disparition en 2010.

Depuis l'activation de Taproot en 2021 (Taproot est une mise à niveau significative de Bitcoin visant à améliorer la confidentialité, la sécurité et la scalabilité), le domaine du développement a été quelque peu sans but. Il est bien compris que Bitcoin manque de scalabilité suffisante pour fournir véritablement des services souverains à une population significative dans le monde, ou même pour offrir une scalabilité de manière minimale ou de confiance qui puisse surpasser de très grandes institutions et prestataires de services de garde, et ne peut vraiment échapper aux contraintes de la surveillance gouvernementale.

Cet article met en lumière une compréhension au niveau technique de Bitcoin, qui n'est pas un sujet de débat. La question controversée est de savoir comment aborder cette lacune, ce qui est un sujet très controversé. Depuis la proposition de Taproot, tout le monde propose des propositions très étroites visant à résoudre des problèmes qui ne peuvent être résolus que par des cas d'utilisation spécifiques.

Par exemple, ANYPREVOUT (APO) est une proposition qui permet de réutiliser des signatures dans différentes transactions tant que les scripts d'entrée et les montants sont les mêmes. Cette proposition est spécifiquement conçue pour optimiser le Lightning Network et ses versions multi-parties. CHECKTEMPLATEVERIFY (CTV) est une proposition qui exige que les jetons ne soient dépensés que par des transactions correspondant exactement aux transactions prédéfinies. Cette proposition est conçue pour étendre la fonctionnalité des chaînes de transactions pré-signées en les rendant complètement sans confiance. OP_VAULT est spécifiquement conçu pour définir une "durée d'attente" pour les solutions de stockage à froid afin que les utilisateurs puissent "annuler" les retraits du stockage à froid en les envoyant à des configurations plus froides à signatures multiples pour empêcher que leurs clés ne soient divulguées.

Il y a de nombreuses autres propositions, mais je pense que vous avez compris les points clés. Au cours des dernières années, chaque proposition visait soit à augmenter légèrement la scalabilité, soit à améliorer une petite fonctionnalité, car cela était jugé souhaitable. C'est pourquoi ces discussions n'ont pas progressé. Personne n'est satisfait des autres propositions car elles n'ont pas répondu aux cas d'utilisation qu'ils veulent voir.

Mis à part les proposants, personne ne croit qu'aucune proposition est suffisamment complète pour être considérée comme une prochaine étape raisonnable.

C'est la logique derrière la "Grande récupération de script." En plaidant en faveur et en analysant la restauration complète des scripts, tout comme l'avait initialement conçu Satoshi Nakamoto, nous pouvons effectivement tenter d'explorer l'ensemble de l'espace fonctionnel dont nous avons besoin, plutôt que de débattre et de se quereller sur la question de savoir quelle petite extension de fonctionnalité est suffisante pour le moment.

CODES D'OPÉRATION (Operation Codes)

• OP_CAT: Obtenir deux données de la pile et les ajouter pour former une seule donnée.
• OP_SUBSTR : Accepte un paramètre de longueur (en octets), obtient une partie des données de la pile, supprime les octets de cette longueur et les remet sur la pile.
• OP_LEFT et OP_RIGHT : Accepte un paramètre de longueur, prend un morceau de données de la pile et supprime des octets de la longueur spécifiée d'un côté ou de l'autre de celle-ci.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT et OP_DOWNSHIFT : Accepter un élément de données et effectuer l'opération bit correspondante sur celui-ci.
• OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, et OP_MOD : Opérateurs mathématiques pour les opérations de multiplication, de division et de modulo (retournant le reste de la division).

En plus des opcodes mentionnés ci-dessus pour récupérer, Rusty Russell a proposé trois opcodes supplémentaires conçus pour simplifier la combinaison de différents opcodes:

OP_CTV (ou TXHASH/code équivalent) : permet de faire respecter de manière fine certaines parties d'une transaction, exigeant que ces parties soient exactement cohérentes avec le contenu prédéfini.

CSFS : Permet la vérification des signatures, pas seulement de l'ensemble de la transaction, de sorte que certaines parties du script ou des données utilisées doivent être signées avant de pouvoir être exécutées.

OP_TWEAKVERIFY: Une validation d'opération basée sur Schnorr, impliquant des clés publiques, telles que l'ajout ou la soustraction de clés publiques individuelles à partir d'une clé publique agrégée. Cela peut être utilisé pour s'assurer que lorsqu'une partie dépense unilatéralement à partir d'une sortie de transaction non utilisée partagée (UTXO), les fonds de toutes les autres parties sont envoyés à une clé publique agrégée qui permet une dépense coopérative sans exiger la signature de la partie quittant l'UTXO partagé.

Pourquoi faisons-nous cela?

Les réseaux de couche 2 sont essentiellement des extensions de la couche de base Bitcoin, et ils sont limités par les fonctionnalités de la couche de base. Avant que le Lightning Network puisse être mis en œuvre, trois forks doux séparés étaient nécessaires : CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) et Segregated Witness (SegWit).

Sans une couche de base plus flexible, il est impossible de construire des réseaux Layer2 plus flexibles. Le seul raccourci est de faire confiance à des tiers, ce qui est très simple, mais j'espère que nous aspirons tous à éliminer autant que possible la confiance envers les tiers dans chaque aspect de l'interaction avec la scalabilité de Bitcoin.

Nous devons être en mesure de faire des choses qui sont actuellement impossibles, telles que la consolidation en toute sécurité de deux individus ou plus dans une seule sortie de transaction inutilisée (UTXO) et être capable d'exécuter sans confiance sur la couche de base. La flexibilité actuelle des scripts Bitcoin n'est pas suffisante. Au niveau le plus élémentaire, nous avons besoin de contrats, et nous avons besoin de scripts pour appliquer effectivement des détails plus fins sur l'exécution des transactions afin de garantir qu'un utilisateur sortant en toute sécurité son propre UTXO ne met pas les fonds d'autres utilisateurs en danger.

D'un point de vue plus élevé, voici la fonctionnalité dont nous avons besoin :

Introspection : Nous devons être en mesure d'inspecter réellement des détails spécifiques concernant la transaction de dépense elle-même sur la pile, tels que "cette partie de l'argent ira à une clé publique particulière d'une sortie." Cela me permet d'utiliser ma propre branche spécifique de Taproot pour extraire mes fonds de manière indépendante tout en m'assurant que je ne peux pas prendre les fonds de quelqu'un d'autre. Le script exécuté garantira que les fonds des autres propriétaires sont renvoyés à des adresses composées des clés publiques d'autres utilisateurs pour éviter la perte de fonds causée par d'autres participants.

Transfert de données en cours : En supposant que nous développions davantage le concept d'un seul UTXO avec un grand nombre de personnes, où n'importe qui peut entrer et sortir librement. Dans ce cas, nous avons besoin d'un moyen de suivre qui possède combien d'argent, en utilisant généralement des arbres de Merkle et leurs racines. Cela signifie que lorsque quelqu'un sort, nous devons nous assurer que les "enregistrements" indiquent qui a droit à recevoir quoi dans le cadre de l'UTXO de change des fonds d'autres personnes. 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 aux clés publiques agrégées peuvent être vérifiées sur la pile. Dans un schéma de transaction de sortie non dépensée (UTXO) partagée, notre objectif est de faciliter la coopération et le flux efficace des fonds grâce à une clé publique agrégée contenant tous les participants. Lorsqu'une personne quitte unilatéralement l'UTXO partagé, nous devons supprimer sa clé publique individuelle de la clé publique agrégée. Si toutes les combinaisons possibles n'ont pas été précalculées, alors la seule option est de vérifier si soustraire une clé publique de la clé publique agrégée permettrait de générer une clé publique valide composée des clés publiques individuelles restantes.

Assurer la sécurité : Comme je l'ai mentionné ci-dessus, la raison de la désactivation de tous ces opcodes était de contrer les attaques DOS (provocant des crashes réseau en envoyant de grandes quantités de requêtes inutiles), ce qui pourrait conduire au crash des nœuds formant le réseau. Une façon de résoudre ce problème est de limiter la quantité de ressources que l'un de ces opcodes peut utiliser.

En ce qui concerne la vérification de la signature, la partie la plus coûteuse du script Bitcoin, nous avons déjà une solution pour cela appelée le budget des opérations de signature (sigops). Chaque utilisation d'un code de vérification de signature consomme un certain “budget”, c'est-à-dire le nombre d'opérations de signature autorisées par bloc, établissant une limite stricte sur le coût nécessaire pour valider un bloc pour une transaction à un utilisateur. Taproot modifie le fonctionnement en n'utilisant plus de limite de bloc globale unique, mais en attribuant à chaque transaction sa propre limite de sigops (opérations de signature), proportionnelle à la taille de la transaction. Cela équivaut essentiellement à la même limite globale, mais rend plus facile de comprendre combien de sigops chaque transaction a à disposition.

Le changement de Taproot concernant la limite de sigops (opérations de signature) pour chaque transaction offre la possibilité d'une approche généralisée, qui est également la suggestion de Rusty Russell concernant les limitations varops. L'idée est d'allouer un coût pour chaque opcode réactivé afin de tenir compte du pire scénario que chaque opcode pourrait créer en termes de coût computationnel le plus cher lors de la vérification. Ainsi, chaque opcode aura sa propre limite de "sigops", limitant la quantité de ressources qu'il peut consommer lors de la vérification. Cela sera également basé sur la taille de toutes les transactions utilisant ces opcodes, ce qui rendra pratique l'inférence tout en s'accumulant à la limite globale implicite de chaque bloc. Cela permettra de contrer les attaques DOS (causant des crashs réseau en envoyant de grandes quantités de requêtes indésirables), ce qui était également la raison pour laquelle Satoshi Nakamoto avait initialement désactivé tous ces opcodes.

La Force Motrice Avant

Je crois que beaucoup d'entre vous pourraient penser, "C'est un grand changement." Je comprends cette perspective, mais je pense qu'un aspect important à comprendre à propos d'une proposition est que nous n'avons pas à tout faire d'un coup. La valeur de cette proposition ne réside peut-être pas nécessairement dans la restauration complète de toutes ces fonctionnalités, mais plutôt dans notre examen approfondi d'une vaste gamme de composants fondamentaux et dans le fait de nous demander quelles fonctionnalités nous désirons vraiment.

Cela marquerait un changement complet par rapport aux trois dernières années de disputes et de débats, où nous nous contentions de débattre de changements mineurs et limités, des changements qui n'affectaient que certaines fonctionnalités. C'est comme un carré où tout le monde peut se réunir et envisager collectivement la direction de l'avenir. Peut-être, à la fin, nous restaurerons toutes ces fonctionnalités, ou peut-être n'en activerons-nous que certaines, car le consensus consiste à convenir des fonctionnalités que nous croyons tous devoir être activées.

Peu importe le résultat final, cela peut être un changement qui a un impact positif sur l'ensemble du dialogue concernant notre direction future. Nous pouvons réellement cartographier et comprendre pleinement la situation, plutôt que d'avancer à tâtons lors de la discussion de la prochaine étape sur un chemin obscur.

Ce n'est en aucun cas la seule voie à suivre que nous devons emprunter, mais je crois que cela offre la meilleure opportunité pour nous de décider quelle voie emprunter. Il est temps de recommencer à travailler ensemble de manière pratique et efficace.

Déclaration:

1. Cet article initialement intitulé “伟大的脚本恢复：比特币的前进之路” est reproduit à partir de [ Bloc licorne]. Tous les droits d'auteur appartiennent à l'auteur original [SHINOBI]. Si vous avez des objections à la reproduction, veuillez contacter le Porte Apprendrel'équipe, l'équipe s'en occupera dès que possible.

2. Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.