Une voie à suivre pour Bitcoin
Bitcoin a été initialement conçu avec un langage de script entièrement étoffé, destiné à englober et à prendre en charge tout cas d'utilisation sécurisé potentiel que les utilisateurs pourraient proposer à l'avenir. Comme Satoshi lui-même l’a dit avant de disparaître : « La nature du Bitcoin est telle qu’une fois la version 0.1 publiée, la conception de base est restée gravée dans le marbre pour le reste de sa durée de vie.
Pour cette raison, je voulais le concevoir pour prendre en charge tous les types de transactions possibles auxquels je pouvais penser. Le problème était que chaque élément nécessitait un code de support et des champs de données spéciaux, qu'il soit utilisé ou non, et ne couvrait qu'un cas particulier à la fois. Cela aurait été une explosion de cas particuliers.
La solution était un script, qui généralise le problème afin que les parties à la transaction puissent décrire leur transaction comme un prédicat évalué par le réseau de nœuds. – Satoshi, 17 juin 2010. L'objectif était de donner aux utilisateurs un langage suffisamment général pour qu'ils puissent composer leurs propres types de transactions comme bon leur semble.
C'est-à-dire donner aux utilisateurs la possibilité de concevoir et d'expérimenter la façon dont ils ont programmé leur propre argent. Avant de disparaître, Satoshi a supprimé 15 de ces opcodes, les désactivant complètement et ajoutant une limite stricte à la taille d'une donnée pouvant être manipulée sur la pile du moteur de script (520 octets). Cela a été fait parce qu'il a franchement foiré et laissé ouvert un grand nombre de façons dont des scripts compliqués pourraient être utilisés pour attaquer par déni de service l'ensemble du réseau, créant ainsi des transactions énormes et coûteuses pour valider qui feraient planter des nœuds.
Ces opcodes n'ont pas été supprimés parce que Satoshi pensait que la fonctionnalité était dangereuse, ou que les gens ne devraient pas pouvoir construire ce qu'ils pouvaient avec eux, mais uniquement (du moins apparemment) à cause du risque pour le réseau dans son ensemble d'être utilisés. sans contraintes de ressources pour limiter le pire coût de validation qu’ils pourraient imposer au réseau. Depuis lors, chaque mise à niveau de Bitcoin a finalement rationalisé les fonctionnalités restantes, corrigé d'autres défauts moins graves que Satoshi nous a laissés et étendu les fonctionnalités de ce sous-ensemble de script qui nous restait.
La grande restauration des scripts Lors du Bitcoin++ à Austin début mai, le développeur de Core Lightning, Rusty Russell, a fait une proposition assez radicale lors de la première présentation de la conférence. Il a essentiellement lancé l'idée de réactiver la plupart des opcodes que Satoshi avait désactivés en 2010 avant sa disparition. Au cours des dernières années, depuis l'activation de Taproot en 2021, l'espace de développement a été franchement sans but.
Nous savons tous que Bitcoin n'est pas suffisamment évolutif pour réellement servir une partie importante de la population mondiale de manière autonome, et probablement même pas d'une manière minimisée ou dépositaire qui puisse s'étendre au-delà de très grands dépositaires et fournisseurs de services incapables de vraiment s'échapper. le bras long du gouvernement. Quiconque comprend Bitcoin au niveau technologique le comprend, ce n’est pas une question de débat.
Ce qui fait débat, et qui est très controversé, c'est la manière de remédier à cette lacune. Depuis Taproot, tout le monde a avancé des propositions très étroites destinées à répondre uniquement à des cas d'utilisation très particuliers qui pourraient être activés. ANYPREVOUT (APO), une proposition visant à permettre la réutilisation des signatures sur différentes transactions tant que le script et le montant de l'entrée étaient les mêmes, a été spécialement conçue pour optimiser Lightning et ses versions multipartites.
CHECKTEMPLATEVERIFY (CTV), une proposition visant à imposer que les pièces ne puissent être dépensées que par une transaction qui correspond exactement à une transaction prédéfinie, a été spécialement conçue pour étendre la fonctionnalité des chaînes de transactions pré-signées en les rendant totalement sans confiance. OP_VAULT a été conçu spécifiquement pour permettre un « délai d'attente » pour les systèmes de stockage à froid, afin qu'un utilisateur puisse « annuler » un retrait du stockage à froid en l'envoyant vers une configuration multisig encore plus froide si ses clés étaient compromises. Il existe de nombreuses autres propositions, mais je pense que vous comprenez.
Plutôt que de tenter d'aborder de manière globale l'expressivité et la programmabilité nécessaires pour faire évoluer Bitcoin de manière fondamentale, chacune des propositions des dernières années a été conçue pour soit apporter une légère augmentation de l'évolutivité, soit améliorer une seule fonctionnalité étroite jugée souhaitable. Je pense que c’est la raison pour laquelle aucune de ces conversations ne mène nulle part. Personne n’est satisfait d’une autre proposition car elle ne répond pas au cas d’utilisation qu’il souhaite voir construit.
Rien n’est assez complet pour que quiconque puisse penser, en dehors de l’auteur de la proposition, qu’il s’agit de la prochaine étape raisonnable. C’est la logique derrière la Grande Restauration de l’Écriture. En poussant et en analysant une restauration complète du script tel que Satoshi l'a initialement conçu, nous pouvons réellement essayer d'explorer tout l'espace des fonctionnalités dont nous avons besoin, plutôt que de nous chamailler et de nous battre pour savoir quelle petite extension de fonctionnalité est suffisante pour le moment.
Les Opcodes OP_CAT : Prend deux éléments de données sur la pile et les additionne pour n'en former qu'un. OP_SUBSTR : prend un argument de longueur en octets et récupère un élément de données de la pile en en supprimant autant d'octets et en le remettant. OP_LEFT & OP_RIGHT : prend un argument de longueur et supprime autant d'octets d'un côté ou de l'autre d'une donnée sur la pile.
OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT : prend un élément de données de la pile et effectue l'opération binaire correspondante dessus. OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD : opérateurs mathématiques pour les opérations de multiplication, de division et de modulo (renvoyant le reste de la division). Ceux ci-dessus sont les opcodes destinés à être restaurés.
En plus de ceux-ci, Rusty en propose trois autres pour simplifier la composition des différents opcodes. OP_CTV (OU TXHASH /équivalent) : quelque chose pour permettre une application granulaire exigeant que certaines parties d'une transaction soient exactement telles que définies à l'avance. CSFS : permet de vérifier les signatures par rapport à des données arbitraires, plutôt que simplement l'intégralité de la transaction.
Cela vous permet d'exiger que des parties d'un script, ou les données qu'elles utilisent, soient signées afin d'être exécutées. OP_TWEAKVERIFY : vérifie les opérations basées sur Schnorr impliquant des clés publiques, telles que l'ajout ou la soustraction de clés publiques individuelles de celles agrégées. Cela peut être utilisé pour garantir que dans le cas où une partie quitte unilatéralement un UTXO partagé, les fonds de tous les autres sont envoyés vers une clé publique globale qui ne nécessite pas que la partie qui est partie signe pour dépenser en coopération.
Pourquoi nous voulons faire cela Les couches 2 sont intrinsèquement une extension de la couche de base de Bitcoin, elles sont par nature limitées en termes de fonctionnalités par les fonctionnalités de la couche de base. Lightning nécessitait trois softforks distincts, CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) et Segregated Witness avant qu'il ne soit possible de le mettre en œuvre. Vous ne pouvez tout simplement pas créer de couches 2 plus flexibles sans une couche de base plus flexible.
Le seul raccourci est celui des tiers de confiance, purs et simples. C’est quelque chose que j’espère que nous aspirons tous à supprimer de tous les aspects de l’interaction avec Bitcoin à l’échelle possible. Il y a des choses que nous devons être capables de faire et que nous ne pouvons tout simplement pas faire pour le moment afin de regrouper en toute sécurité plus de deux personnes dans un seul UTXO d'une manière qui peut être appliquée sans confiance sur la couche de base, le script Bitcoin n'est tout simplement pas assez souple.
Au niveau le plus élémentaire, nous avons besoin de clauses, nous avons besoin de la capacité du script à appliquer des détails plus granulaires sur la transaction qui les exécute pour garantir que des choses comme un utilisateur quittant en toute sécurité un UTXO par lui-même ne mettent pas en danger les fonds des autres utilisateurs. D'un point de vue général, c'est le type de fonctionnalité dont nous avons besoin : Introspection : nous devons être capables d'inspecter des détails spécifiques sur une transaction de dépense elle-même sur la pile, tels que « cette somme d'argent va à cette clé publique dans une sortie. » » Cela me permet de retirer mon argent moi-même en utilisant ma propre succursale Taproot spécifique, tout en m'assurant que je ne peux pas prendre l'argent de quelqu'un d'autre.
L'exécution du script imposerait par consensus que le montant correct que chacun possède soit renvoyé à une adresse composée des clés publiques des autres utilisateurs si je partais. Forward Data Carrying : Supposons que nous allions encore plus loin que l'idée d'un canal Lightning avec plus de deux personnes, nous construisons un seul UTXO avec un nombre massif de personnes dans lequel chacun peut aller et venir à sa guise. D'une manière ou d'une autre, presque toujours avec un arbre merkle et sa racine, nous avons besoin d'un moyen de savoir qui a combien d'argent.
Cela signifie que lorsque quelqu'un part, nous devons être en mesure de garantir que le « dossier » indiquant qui a droit à quoi fait partie du changement UTXO de l'argent de tous les autres. Il s’agit essentiellement d’une utilisation spécifique de l’introspection. Modification de la clé publique : nous devons pouvoir garantir que les modifications apportées aux clés publiques agrégées peuvent être vérifiées sur la pile.
L’objectif à atteindre dans les programmes de partage UTXO est qu’il existe une clé globale avec toutes les personnes impliquées permettant un mouvement de fonds coopératif et plus efficace. Chaque fois que quelqu'un quitte unilatéralement un UTXO partagé, nous devons supprimer sa clé individuelle de la clé globale. Sans précalculer toutes les combinaisons possibles à l'avance, la seule option est de pouvoir vérifier que la soustraction d'une clé de l'agrégat crée une clé valide composée du reste des clés individuelles.
Comment sécuriser cela : Varops Comme je l'ai dit ci-dessus, la raison pour laquelle tous ces opcodes ont été désactivés était de supprimer les risques d'attaques par déni de service qui pourraient littéralement faire planter les nœuds composant le réseau. Il existe un moyen de résoudre ce problème, en limitant la quantité de ressources que chacun de ces opcodes peut utiliser. Nous disposons déjà d’une telle solution en matière de vérification de signature, la partie la plus coûteuse de la vérification des scripts Bitcoin.
C'est ce qu'on appelle le budget sigops. Chaque utilisation d'un opcode de vérification de signature consomme un certain « budget » d'opérations de signature autorisées par bloc. Cela impose une limite stricte au coût que les transactions peuvent imposer aux utilisateurs pour vérifier un bloc individuel.
Taproot a modifié la façon dont cela fonctionne : au lieu d'utiliser une seule limite de bloc globale, chaque transaction a sa propre limite sigops proportionnelle à la taille de la transaction. Cela revient essentiellement à la même limite globale, mais facilite le raisonnement en termes de nombre de sigops disponibles pour une transaction individuelle. Le changement dans la façon dont Taproot gère les limites sigops par rapport à chaque transaction offre un moyen de généraliser cela, ce que Rusty propose avec une limite varops.
L'idée est d'attribuer un coût pour chacun des opcodes réactivés afin de prendre en compte le pire des cas, c'est-à-dire le coût de calcul le plus coûteux à valider, que pourrait créer chaque opcode. Avec cela, chacun de ces opcodes aurait sa propre limite « sigops » pour limiter la quantité de ressources qu'il pourrait consommer en vérification. Cela serait également basé sur la taille de toute transaction les utilisant, donc maintenez la facilité de raisonnement à ce sujet, tout en totalisant une limite globale implicite par bloc.
Cela résoudrait les risques de déni de service qui ont amené Satoshi à désactiver tous ces opcodes en premier lieu. Forward Momentum Je suis sûr que beaucoup d’entre vous pensent « c’est un changement bien trop important ». Je peux comprendre cela, mais je pense qu'un aspect important de ce projet en tant que proposition à comprendre est que nous n'avons pas besoin de tout faire.
La valeur de cette proposition ne réside pas nécessairement dans le fait de renverser tout cela dans son ensemble, mais dans le fait que nous examinerions en fait de manière exhaustive une suite massive de primitives et nous demanderions ce que nous attendons vraiment de cela en termes de fonctionnalités. . Ce serait une volte-face complète par rapport aux trois dernières années de querelles et de disputes sur de minuscules changements étroits qui n'aident que certaines fonctionnalités.
C'est une tente qui pourrait rassembler tout le monde sous un même toit pour évaluer de manière vraiment globale où aller à partir de maintenant. Peut-être que nous finirons par réactiver tout cela, peut-être que nous finirons par activer simplement quelques éléments parce que le consensus est que c'est tout ce dont nous avons besoin pour activer les fonctionnalités dont tout le monde convient que nous avons besoin. Quel que soit le résultat final, cela peut constituer un changement productif dans l’ensemble de la conversation sur la direction que nous prendrons à partir de maintenant.
Nous pouvons en fait tracer et obtenir une vue d'ensemble complète du terrain, plutôt que de nous disputer sur le chemin sombre et mal éclairé à emprunter ensuite. Cela ne doit en aucun cas être la voie à suivre, mais je pense que c’est notre meilleure chance de décider laquelle choisir. Il est temps de recommencer à travailler ensemble de manière productive.
Vous pouvez trouver la première d'une série d'interviews vidéo enregistrées sur Bitcoin++ avec une poignée de développeurs discutant de la proposition de restauration de scripts. Pour commencer, voici Rusty lui-même :
BitRss.com partage toujours ce contenu avec licence.