Pour la première fois en quatre ans, Bitcoin pourrait connaître un « Soft Fork dirigé par les utilisateurs » ?

La communauté de base du Bitcoin commence à promouvoir des changements dans le logiciel sous-jacent du Bitcoin, ce qui est rare depuis plus de quatre ans.

Rédigé par : GaryMa 吴说区块链

Selon Blockspace, la communauté de base de Bitcoin commence à promouvoir des changements dans le logiciel sous-jacent de Bitcoin, ce qui est rare depuis plus de quatre ans (les changements sous-jacents significatifs précédents ont été principalement initiés par le groupe des développeurs principaux).

Cette fois, le soutien de base qui émerge concerne deux propositions d’amélioration de Bitcoin (BIP), à savoir BIP-119 (CTV) et BIP-348 (CSFS). Ces deux propositions introduisent de nouvelles méthodes de rédaction de scripts Bitcoin, permettant à Bitcoin de réaliser la fonctionnalité de « contrats » (Covenants). Ces deux propositions pourraient être mises en œuvre lors de la prochaine fourchette douce de Bitcoin.

Pour éviter que certains lecteurs ne comprennent temporairement la relation entre les Covenants de Bitcoin et ces propositions BIP spécifiques, clarifions ici :

En termes simples, les Covenants sont un concept fonctionnel dans le réseau Bitcoin, et les deux BIP mentionnés dans le texte sont différentes solutions pour réaliser ce concept fonctionnel.

Qu’est-ce que les Covenants de Bitcoin ?

Définition :

Covenants est un mécanisme proposé dans le protocole Bitcoin, qui permet de définir des conditions ou des restrictions dans les transactions, stipulant comment les bitcoins peuvent être dépensés ou transférés. Ces conditions peuvent s’étendre sur plusieurs transactions, limitant ainsi les modalités de dépense futures, ce qui renforce les fonctionnalités de script de Bitcoin.

Fonction :

• Améliorer les capacités des contrats intelligents de Bitcoin, supportant des applications plus complexes (comme les prêts, les échanges décentralisés, les coffres-forts).
• Améliorer la sécurité pour empêcher le vol ou l’utilisation abusive des fonds.
• Optimiser la performance du réseau, comme réduire les frais de transaction ou améliorer la confidentialité.

Ici, nous pouvons probablement comprendre que les Pactes sont un concept, et que le BIP-119 (CTV) et le BIP-348 (CSFS) mentionnés dans cet article sont la mise en œuvre concrète de ce concept fonctionnel de Pactes.

État actuel :

Le réseau principal de Bitcoin n’a actuellement pas intégré de manière formelle les fonctionnalités liées aux Covenants, bien que des discussions et des propositions connexes (comme le BIP-119) aient été avancées pendant de nombreuses années.

BIP 119 : OP_CHECKTEMPLATEVERIFY (CTV)

Un code d’opération Bitcoin proposé, permettant aux sorties de transaction de spécifier un « modèle » (Template), exigeant que les sorties des transactions de dépense ultérieures correspondent à ce modèle.

Proposé par l’ancien contributeur principal de Bitcoin, Jeremy Rubin, cela existe depuis plus de cinq ans. Il réalise la fonctionnalité de “porte d’état” en limitant les fonds à être dépensés uniquement de la manière prédéfinie.

Les cas d’application incluent :

• Créer des paiements en masse (Batch Payments) pour réduire les frais de transaction. Construire un échange décentralisé (DEX) ou un protocole de prêt.
• Réaliser des Coffres (Vaults), protéger les fonds contre le vol.
• CTV est une implémentation légère de Covenants, axée sur les restrictions de format de sortie, sans impliquer de logique complexe.

BIP 348 : OP_CHECKSIGFROMSTACK (CSFS)

Un opcode Bitcoin proposé, permettant de vérifier si une signature est valide pour n’importe quel message, et pas seulement pour le hachage de la transaction actuelle. Il récupère la signature, la clé publique et le message de la pile de données et vérifie si la signature correspond.

Proposé officiellement par Jeremy Rubin et Brandon Black en novembre 2024.

OP_CSFS est un puissant outil pour réaliser des Covenants plus flexibles, car il permet une « introspection » sur les entrées de transaction, c’est-à-dire vérifier le contenu ou l’état complet de la transaction signée.

Applications spécifiques :

• Réalisation des Covenants : OP_CSFS peut être utilisé pour créer une logique conditionnelle complexe, garantissant que les fonds ne peuvent être dépensés que selon des règles spécifiques. Par exemple, les validateurs peuvent vérifier si les entrées de transaction correspondent à un modèle ou à des restrictions prédéfinies.
• Amélioration de la sécurité : prise en charge des Vaults et des protocoles décentralisés, prévention des vols ou des dépenses non autorisées par la vérification des signatures.
• Scalabilité : combinée avec d’autres codes d’opération (comme OP_CAT), elle permet de construire des contrats intelligents plus complexes.

En parlant des Covenants de Bitcoin ainsi que des propositions BIP-119 (CTV) et BIP-348 (CSFS), il est certain qu’on ne peut pas se passer de OP_CAT.

BIP 347 : OP_CAT

Histoire :

Existence précoce : OP_CAT fait partie du langage de script original de Bitcoin, inclus par Satoshi Nakamoto lors du lancement de Bitcoin en 2009. Il a été initialement conçu pour améliorer la flexibilité des scripts, en prenant en charge une logique plus complexe.

Raison de retrait (2010) :

• OP_CAT a été supprimé (désactivé) en 2010, en raison de la prévention des vulnérabilités de sécurité potentielles et de l’abus des ressources.
• Problème spécifique : sans restrictions, OP_CAT peut être utilisé par des utilisateurs malveillants pour générer des données de longueur illimitée (par des appels récursifs), entraînant une « attaque par déni de service » (DoS Attack), car les nœuds Bitcoin doivent traiter ces données, augmentant ainsi les coûts de calcul et de stockage.
• À l’époque, le langage de script Bitcoin a été simplifié, conservant les fonctionnalités les plus élémentaires, garantissant la légèreté, la sécurité et la décentralisation du protocole.

Définition et fonction :

OP_CAT est un code opérationnel (Opcode) du langage de script Bitcoin. Ce n’est pas une implémentation directe de Covenant, mais c’est un outil potentiel pour construire une logique Covenant complexe. Par rapport aux deux opcodes mentionnés ci-dessus, OP_CAT est plus général et convient aux opérations sur les données, mais doit être combiné avec d’autres opcodes pour réaliser des fonctionnalités complexes.

État actuel :

La communauté Bitcoin a récemment rediscuté du retour d’OP_CAT, qui avait auparavant été présenté sous la forme de la proposition BIP-420, un symbole plus ludique pour la communauté. Cependant, il a maintenant été officiellement intégré au dépôt bitcoin/bips sous le numéro BIP-347.

Comment ça avance

Selon Coindesk, au cours des dernières semaines, de nombreux développeurs de Bitcoin occidentaux ont exprimé leur soutien à CTV et CSFS sur Twitter — — c’est sans aucun doute un signal fort indiquant qu’au moins dans le cercle des médias sociaux, une partie de la communauté Bitcoin avance vers l’acceptation de ces changements.

De plus, les développeurs estiment généralement que la définition de ces deux propositions est relativement « étroite ». En termes simples, cela signifie qu’une fois activées, la probabilité qu’elles soient abusées par les utilisateurs de manière inattendue est faible. La communauté des développeurs de Bitcoin a toujours été prudente à l’égard des changements apportés à Bitcoin. Par exemple, bien que le BIP 119 soit en attente depuis près de cinq ans, récemment, le CTV a été considéré comme trop radical pour être activé.

Les co-fondateurs de ces deux propositions, Jeremy Rubin, ont précédemment fait face à une forte opposition pour leurs efforts de promotion du CTV — en particulier les critiques provenant de certains leaders d’opinion Bitcoin avec de nombreux abonnés, comme Adam Back et Jimmy Song. Ces diverses critiques ont finalement évolué en un mécontentement généralisé au sein de la communauté Bitcoin, forçant Rubin à se retirer du domaine Bitcoin.

Alors, qu’est-ce qui a vraiment provoqué ce changement ? La récente promotion de l’opcode OP_CAT semble élargir la gamme des propositions Bitcoin considérées comme « acceptables », en définissant CTV et CSFS comme des options relativement « conservatrices ». Il est à noter que la plupart des partisans de l’OP_CAT soutiennent également le BIP 119 et le BIP 348 (ainsi que la plupart des autres propositions).

Qu’est-ce que nous pouvons attendre ensuite ? Tout d’abord, les discussions vont se poursuivre. On s’attend à ce que les développeurs explorent davantage ces propositions lors de plusieurs conférences techniques, comme OPNEXT prévu en avril, BTC++ en juillet et TABConf en octobre. Une fois que les développeurs auront atteint un consensus préliminaire, l’activation réelle du soft fork sera confiée aux mineurs, à la communauté et aux investisseurs pour une validation finale.

Comment suivre l’avancement des discussions sur les BIPs dans la communauté / le processus de fork doux ?

La réponse est très difficile !

La communauté technique de Bitcoin discute généralement en profondeur de ces propositions. Mais c’est un processus de discussion qui semble obscur et répétitif.

En termes simples, le processus de soft fork du Bitcoin nécessite d’estimer approximativement le niveau de soutien des différentes parties prenantes du Bitcoin, y compris les développeurs, les hébergeurs, les investisseurs et les mineurs. L’indicateur de soutien le plus évident provient généralement des mineurs, car ils peuvent signaler leur approbation des modifications du code en émettant des signaux dans les blocs qu’ils minent. En général, Bitcoin Core exige que 95 % des blocs émettent un signal de soutien pendant une certaine période, avant de verrouiller la mise à jour pour activation.

Cependant, il n’y a actuellement pas de consensus sur la façon de définir le “soutien large”, le consensus autour du Bitcoin est en constante évolution. Les mineurs sont devenus des fournisseurs de signaux importants simplement parce qu’ils sont une entité “comptable” dans le réseau Bitcoin. En d’autres termes, en raison de la structure décentralisée du Bitcoin, il est difficile de mesurer le consensus global d’un point de vue “visible à l’œil nu”.

Cependant, une entreprise de développement célèbre pour ses NFT Bitcoin, Taproot Wizards, prend OP_CAT comme exemple et révèle, à l’aide de diagrammes de flux, le long et complexe processus de la bifurcation douce de Bitcoin. Les lecteurs intéressés peuvent consulter par eux-mêmes, ici nous allons essayer de résumer :

Cycle de vie des propositions BIPs | Le long et complexe processus des forks doux de Bitcoin

1. La proposition a été initialement soumise et discutée sur la liste de diffusion des développeurs de Bitcoin.

2. Entrer dans une discussion à plus grande échelle au sein de la communauté, on est entré dans un dilemme de discussion à long terme sur les avantages et les inconvénients de la fonction de proposition. Si l’on ne peut pas avancer davantage, cela s’arrête ici.

3. Les communautés de base rédigent des brouillons de BIP pour les propositions sur Github.

4. Les développeurs commencent à mettre en œuvre le code pertinent, ils doivent corriger les bugs à long terme pour pouvoir avancer.

5. Après révision par les éditeurs du dépôt Bitcoin BIP et reconnaissance préliminaire de la communauté, un numéro BIP officiel est attribué.

6. Accédez au réseau de test Signet. Signet est un réseau de test pour Bitcoin qui permet aux développeurs de tester de nouvelles fonctionnalités ou des modifications de code sans affecter le réseau principal. (Il est possible que la plupart des nouvelles fonctionnalités soient définitivement mises de côté à cette étape.)

7. Il est possible d’entrer dans la sidechain Liquid pour effectuer des essais.

8. Soumettre un PR à Bitcoin Core.

9. Entrer dans le processus de révision du code de Bitcoin Core et de fusion des propositions, avec une incertitude élevée. Une proposition n’a de chance d’entrer dans la phase de fusion que si elle a évité la majorité des objections et satisfait aux exigences techniques (sans bogues majeurs) ; l’avis des développeurs clés (comme Pieter Wuille) est souvent crucial, son approbation ou son rejet ayant un impact considérable sur le sort de la proposition.

10. Si l’audit du code ne pose pas de problème, attendez que le mainteneur du dépôt Bitcoin fusionne le PR dans le projet principal. Actuellement, il y a cinq mainteneurs : Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).

11. La continuité des controverses et des discussions potentielles entre différents groupes tels que les développeurs et les mineurs de Bitcoin.

12. Choisissez le mécanisme d’activation :

a. Hard fork dirigé par les mineurs (MASF) : activé par les mineurs via un signal (généralement un seuil de 95 %), qui met en œuvre de nouvelles règles, comme le mode par défaut de BIP-9 ou BIP-8. Plus stable, mais nécessite une large coordination de consensus et des tests, donc prend plus de temps ;

b. Soft fork dirigé par l’utilisateur (UASF) : activation forcée de nouvelles règles par les opérateurs de nœuds (utilisateurs) (comme « Lockinontimeout: True » de BIP-8), contournant la résistance des mineurs, avec un risque potentiel de bifurcation de chaîne et de divergences au sein de la communauté.

Conclusion

Wu a précédemment rapporté que Cobra, le mainteneur du domaine Bitcoin.org, a averti que le réseau Bitcoin pourrait connaître en 2025 un bifurcation douce dirigée par les utilisateurs (UASF) lancée par des développeurs anonymes en dehors du cœur de Bitcoin, faisant référence aux changements potentiels du BIP 119 mentionnés dans cet article. Cobra estime que ces améliorations pourraient provoquer des divergences entre les “partisans de la rigidité” et les “partisans de l’amélioration”, dirigées par des communautés de base et promues par des développeurs qui ne font pas partie du cœur de Bitcoin.

Il est entendu que l’UASF (user-led soft fork) est une mise à niveau du protocole initiée par les utilisateurs de Bitcoin, en mettant à niveau le logiciel du nœud pour appliquer les mises à jour du protocole, même si les mineurs ou d’autres parties ne le prennent pas en charge, ce qui signifie également le risque de fork de la chaîne. Bien sûr, il n’y a pas lieu de s’inquiéter à ce sujet pour le moment, après tout, beaucoup ne sont toujours pas résolus. Par exemple, les futurs soft forks ne contiendront-ils que des CTV et des CSFS ? L’OP_CAT, qui est souvent discuté avec cet ensemble d’opcodes, sera-t-il pris en compte ? Comment le processus d’activation du soft fork va-t-il se dérouler ? D’autres parties prenantes, telles que les mineurs de bitcoins, y prêteront-elles suffisamment attention ?

Après tout, tant que le consensus autour des BIPs est suffisamment large, les propositions soutenues par la communauté de base peuvent également être réalisées sous la forme de forks doux dirigés par les mineurs (MASF). De plus, même les UASF ont des exemples de succès dans l’histoire. Les UASF ont joué un rôle clé dans la mise à niveau SegWit en 2017, permettant aux utilisateurs de promouvoir un fork doux, d’éviter un fork dur, et de faciliter l’extension de Bitcoin.

Lien de référence :