Bitcoin Soft Fork : la monnaie a-t-elle vraiment besoin de ces nouveaux OP_Codes ?

Certains développeurs poussent à nouveau pour un soft fork qui fait beaucoup moins de consensus que les précédents. Il n'est pas facile de modifier le code Bitcoin.

Certains développeurs poussent à nouveau en faveur d'un soft fork qui fait beaucoup moins de consensus que les précédents.

Bitcoin Soft ForkIl n'est pas facile de modifier le code Bitcoin. Nous sommes incités à ne jamais modifier la partie du code correspondant à la limite de 21 millions.

Certaines évolutions sont néanmoins nécessaires, d'autres beaucoup moins. Malheureusement, il y aura toujours des développeurs qui voudront apporter leur mauvais grain de sel.

Les évolutions de code sont proposées via des « Pull Requests ». La plupart sont mineurs, mais certains sont majeurs. Ils deviennent alors des BIP (Bitcoin Improvement Proposals) qui sont parfois des « soft forks ».

Pour rappel, un hard fork est une évolution du code incompatible avec l'ancien. L’exemple typique est le BCH (Bitcoin Cash). Les nœuds du réseau BTC ne valident pas les blocs BCH car ils peuvent dépasser la limite de 1 Mo par bloc. Un tel changement déclenche un hard fork.

Dans le cas d'un soft fork, les deux codes coexistent sur la même blockchain. C’est ce qu’on appelle la rétrocompatibilité. Par exemple, nous pourrions modifier la taille du bloc à 0,3 Mo. C'est inférieur à la limite de 1 Mo et donc rétrocompatible avec le protocole d'origine.

Les derniers soft forks étaient SegWit (2016) et Taproot (2021). Certains développeurs font actuellement pression pour un nouveau fork permettant la création de « covenants » en ajoutant de nouveaux OP_codes.

Blockstream Research a récemment publié un résumé assez détaillé sur le sujet :

Il est essentiel de comprendre les mécanismes des transactions Bitcoin pour comprendre ce que sont les alliances. La magie opère grâce à un langage d’exécution informatique appelé « script ». C'est un langage très simple avec un nombre limité d'instructions.

Ces instructions sont appelées OP_codes. Considérez-les comme de petits engrenages numériques qui se mettent en marche lorsqu'une transaction est validée.

Plus précisément, effectuer une transaction Bitcoin signifie créer un « utxo » à partir d'un (ou plusieurs) autre « utxo » qui est détruit au cours du processus. Un utxo est un morceau de code (un script) qui relie mathématiquement une quantité de bitcoins à une adresse bitcoin (une clé publique).

Essentiellement, effectuer une transaction signifie changer la clé publique (l'adresse bitcoin) à laquelle le montant de bitcoins est lié.

Lors d'une transaction, l'OP_code étoile est OP_CHECKSIG. Cela vérifie que la signature correspond à la clé publique de l'utxo dépensé. Si tout est en ordre, un nouvel utxo contenant la clé publique du destinataire est créé.

Dans l'ensemble, Bitcoin Script est un langage de programmation « empilé » assez simple qui limite le champ des possibilités.

Blockstream écrit à ce sujet :

“ Dans l’état actuel des choses, il n’est pas possible de préconfigurer la manière dont les bitcoins d’un utxo peuvent être dépensés ni la vitesse à laquelle ils peuvent être dépensés. La seule solution est de bricoler en utilisant des PSBT (transactions Bitcoin partiellement signées) qui ne peuvent pas correctement inclure les frais de transaction, entre autres limitations. »

« La simplicité du langage de programmation Script, bien qu'il soit au cœur du modèle de sécurité de Bitcoin, introduit des limites dans sa capacité à prendre en charge les contrats intelligents les plus élémentaires.

Plus d'arithmétique dans la pile « Basé sur la pile » signifie que les données nécessaires à la mécanique des transactions sont placées dans une « pile » où les opérations logiques sont effectuées.

Exemple de mécanisme de vérification de transaction :

Le code OP OP_DUP dupliquera le public clé d'un utxo et placez-la dans la pile.

L'OP_code OP_HASH va hacher cette clé (ce qui la transforme en une adresse à laquelle les bitcoins étaient mathématiquement liés dans l'utxo)

OP_EQUALVERIFY vérifie que le hachage résultant appartient bien au utxo en question.

OP_CHECKSIG vérifie que la signature fournie correspond à la clé publique de l'utxo.

Bitcoin Script a un peu moins de 100 OP_codes non triviaux. Cependant, il n'est pas possible de multiplier, diviser ou concaténer (combiner) des données dans la pile.

Satoshi a désactivé plusieurs OP_codes en 2010 (OP_OR, OP_MUL [multiplier], OP_DIV [diviser] et OP_CAT [concaténer]). Ces OP_codes ont été supprimés car leurs implémentations d'origine présentaient des vulnérabilités exploitables susceptibles de compromettre la sécurité du réseau.

Leur absence rend cependant difficile la création de certaines conditions de dépenses exotiques (contrats intelligents). Notamment, l'incapacité de définir les conditions de dépenses dans l'utxo sur la base des données de transaction.

Blockstream explique :

« Si le script avait la capacité d'interpréter plus de détails dans les données de transaction, nous pourrions construire des contrats beaucoup plus robustes qui permettent des dépenses spécifiques. conditions."

ConventionsActuellement, le seul « contrat intelligent » possible avec le bitcoin est simplement l'acte classique de verrouillage et de déverrouillage de bitcoins lié à une clé publique. Réaliser une transaction, en substance.

Les covenants visent à créer un nouveau type d'utxo permettant à l'expéditeur d'une transaction d'imposer certaines conditions sur la manière dont le destinataire peut dépenser les bitcoins par la suite.

Voici deux OP_codes regroupés sous le terme « covenants ». » avec des capacités limitées qui

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!