Décodage du mythe des gardiens : les développeurs et l'« écosystème » du Bitcoin (2)
TechFlow SélectionTechFlow Sélection
Décodage du mythe des gardiens : les développeurs et l'« écosystème » du Bitcoin (2)
Dans cet épisode du podcast, Jeffrey et Ajian approfondissent la question de l'« erreur de perception » concernant les frais de « gas » du Bitcoin.
Dédié à des analyses Web3 approfondiesInvité : Jeffrey Hu, Directeur technique chez HashKey Capital
A Jian, chercheur senior sur Bitcoin et contributeur de BTC Study
Rédaction : HashKey Capital
Dans cet épisode du podcast « Hash Out 42 » produit par HashKey Capital, deux chercheurs sur Bitcoin discutent de la complexité des frais réseau du réseau Bitcoin, ainsi que des défis liés à la gestion des transactions et de la taille des blocs. Dans ce chapitre, Jeffrey, directeur technique chez HashKey Capital, et le chercheur sur Bitcoin A Jian analysent en profondeur l'idée fausse concernant les « frais de gaz » (gas fees) sur Bitcoin — un terme davantage adapté au modèle transactionnel d'Ethereum. Ils insistent sur le fait que les frais sur Bitcoin sont basés sur la taille des transactions, et non pas sur la quantité de calcul effectuée comme c'est le cas sur Ethereum.
Un point préoccupant est l'encombrement du réseau Bitcoin et la hausse des frais de transaction causés par les jetons BRC20. Récemment, cette tendance a non seulement eu un impact négatif sur l'expérience utilisateur, mais a également entraîné une croissance significative de l'ensemble UTXO, soulevant des incertitudes pour l'avenir du réseau Bitcoin, notamment en termes de besoins accrus en calcul et en stockage.
L'épisode aborde également l'importance cruciale de faire fonctionner un nœud complet (full node) sur le réseau Bitcoin. Bien qu'exécuter un nœud complet ne procure pas nécessairement d'avantages économiques directs, cela joue un rôle fondamental dans la préservation de l'intégrité du réseau, sa résistance à la censure, et permet une vérification sans confiance de la blockchain. Cela est essentiel pour protéger la confidentialité financière individuelle et la liberté des transactions.
En outre, l'épisode poursuit son analyse sur la distinction entre fourches molles (soft forks) et fourches dures (hard forks) dans le réseau Bitcoin, ainsi que sur le rôle du vote des mineurs lors des mises à niveau du réseau. À travers l'exemple du BIP 148 et de la mise à niveau SegWit, il illustre comment les opérateurs de nœuds complets peuvent exercer une influence active lors de mises à jour controversées. La discussion souligne que posséder un nœud complet donne plus de pouvoir et de choix aux utilisateurs, contribuant ainsi fortement à la santé du réseau et à la souveraineté financière individuelle.
Enfin, l’épisode réaffirme l’essence philosophique de Bitcoin. Contrairement à d'autres cryptomonnaies qui peuvent s'aligner sur des notions de pouvoir ou d'autorité, Bitcoin vise à limiter le pouvoir afin de protéger la liberté individuelle, ce qui lui confère une place unique dans l'écosystème des cryptomonnaies.
Cet épisode de « Hash Out 42 » offre aux auditeurs intéressés par les complexités techniques et philosophiques de Bitcoin une opportunité approfondie et complète d'apprentissage.
Jeffrey Hu : On a parlé tout à l’heure des frais réseau, notamment de la manière dont on détermine si une transaction doit être incluse dans un bloc. On a mentionné que ces frais pouvaient être élevés. Il y a donc récemment une idée répandue selon laquelle BRC20 congestionne terriblement le réseau Bitcoin, faisant grimper les « frais de gaz », ce qui irrite beaucoup les développeurs et les puristes, qui envisagent alors certaines mesures correctives. Je vais commencer par là, car ce sujet me met particulièrement mal à l’aise. L’expression « frais de gaz sur Bitcoin » est clairement erronée – ce n’est pas simplement une question de manie linguistique. Bitcoin n’a pas de concept de « gas fee ». On peut parler de frais de transaction, ou simplement de « fees ». Utiliser le terme « gas » reflète une incompréhension profonde, bien au-delà d’une simple erreur de vocabulaire. Sur Ethereum, les calculs, voire le stockage, sont tarifés en unités de « gas ». Mais sur Bitcoin, les frais sont entièrement basés sur la taille de la transaction : plus une transaction laisse de traces sur la chaîne, plus elle occupe d’espace dans un bloc, et plus ses frais sont élevés. Ces deux modèles sont donc très différents. J’espère donc que ceux qui comprennent cela éviteront désormais d’utiliser le terme « gas » pour parler des frais Bitcoin, car c’est une confusion importante.
Concernant cette confusion, il existe aussi une autre idée reçue assez répandue : celle que BRC20 cause la congestion du réseau ou des frais élevés. C’est effectivement une réalité observée récemment. De mon point de vue, il est vrai que la taille des blocs récents est souvent très grande, et que les frais peuvent être élevés, affectant négativement certains utilisateurs. D’un point de vue expérience utilisateur, c’est effectivement problématique. Mais ce qui me préoccupe davantage, et qui va à l’encontre de l’approche traditionnellement prudente des développeurs Bitcoin, c’est surtout la croissance rapide de l’ensemble UTXO. Par exemple, même si on a vu apparaître début 2023 un bloc de 4 Mo à cause d’une inscription, ce qui a suscité la surprise, je pense que cela reste dans des limites acceptables. En effet, dès l’activation de la fourche SegWit, les ingénieurs savaient techniquement que, dans des cas extrêmes, chaque bloc pourrait atteindre 4 Mo – ce scénario était anticipé. De même, une mémoire tampon (mempool) remplie de transactions à traiter, entraînant des frais élevés, était une situation prévisible.
Ce qui n’avait pas été anticipé, en revanche, c’est la croissance massive de l’ensemble UTXO. Prenons l’analogie du dépôt d’argent à la banque : si tout le monde dépose des billets de 100 euros, la banque gère cela facilement. Mais si soudain, tout le monde commence à déposer des pièces de 10 centimes, la charge de traitement, de comptabilité et de suivi devient énorme. C’est exactement ce qui se passe aujourd’hui avec l’explosion de l’UTXO set. Cette croissance-là n’avait pas été anticipée par les développeurs ni imaginée dans les discussions passées. J’ai vu un chiffre selon lequel l’ensemble UTXO aurait presque doublé depuis le début de l’année. A Jian, avez-vous vu ces données ? Pouvez-vous les confirmer ou corriger ?
A Jian : Un ami m’avait partagé des données à ce sujet, que j’ai réactualisées aujourd’hui. Le 21 avril dernier, l’ensemble UTXO du réseau Bitcoin contenait environ 86 millions d’UTXO, représentant environ 5 Go. Mais le 25 novembre – il y a donc peu de temps – ce nombre est passé à 140 millions, pour un volume total de 8,74 Go. Donc oui, vous avez raison : si on compare à la fin de l’année dernière, l’ensemble UTXO a bel et bien doublé. Certains auditeurs peuvent ne pas saisir pleinement l’importance de l’UTXO set. Expliquons cela : la blockchain est un registre historique de toutes les transactions passées. Elle a donc une taille – les données de blocs – qui augmente constamment. Actuellement, la blockchain Bitcoin pèse plus de 500 Go.
Mais il existe une autre composante : après avoir traité toutes les transactions, on obtient un état actuel du système. Sur Bitcoin, cet état est représenté par l’ensemble UTXO. Il indique combien d’outputs non dépensés existent, combien chacun contient, et sous quelles conditions ils peuvent être dépensés. C’est donc le résultat final de toutes les transactions Bitcoin exécutées jusqu’à présent.
Chaque fois qu’un nouveau bloc apparaît, un nœud doit accomplir deux tâches : télécharger les données du bloc et les stocker localement, puis valider chaque transaction du bloc une par une. Pour cela, il doit consulter l’UTXO set : quel output est dépensé ? Quels nouveaux outputs sont créés ? La validation consiste à récupérer les UTXO concernés, vérifier les signatures et autres preuves d’autorisation, et s’assurer qu’aucune inflation n’a lieu – bref, que la transaction soit valide. Ce processus implique donc de rechercher activement des éléments dans l’UTXO set, ce qui augmente considérablement les opérations de lecture/écriture sur le disque dur.
Le fait de devoir extraire des UTXO spécifiques d’un ensemble gigantesque, puis de les traiter, implique une charge disque bien plus importante que le simple stockage des blocs. C’est pourquoi la taille de l’état (l’UTXO set) inquiète tant la communauté. Certains d’entre vous ont peut-être entendu parler du « problème d’explosion d’état » sur Ethereum – c’est exactement le même phénomène. Sur Ethereum, après traitement des transactions, on obtient un nouvel état : les comptes externes, les contrats, leurs soldes et données internes. Sans connaître cet état, impossible de valider le prochain bloc.
Sur Bitcoin, c’est identique : sans l’UTXO set à jour, on ne peut pas valider le prochain bloc. Cette charge disque devient donc un coût opérationnel majeur pour continuer à faire tourner un nœud complet et à participer à la sécurité du réseau. C’est à ce niveau précis que je suis particulièrement inquiet des récents développements.
Franchement, un NFT de 3 Mo, je m’en inquiète moins. Mais des choses comme BRC20, ou d’autres projets récents visant à émettre des jetons – j’hésite même à les appeler des protocoles, tant c’est tiré par les cheveux –, posent problème. Comme je l’ai déjà dit ailleurs, leur sécurité est hautement douteuse. Ces systèmes, comme BRC20, provoquent objectivement une inflation de l’UTXO set. D’autres projets vont jusqu’à dissimuler des données dans des champs de signature, les intégrant aux outputs des transactions – ce qui alourdit encore plus l’UTXO set. Et c’est pire que simplement injecter des données sur la chaîne.
Bref, ces dernières semaines – peut-être un mois et demi – m’ont fait me demander si nous avions encore des principes fondamentaux en commun, ou s’il restait une once de respect. Imaginez un square public avec des massifs fleuris. Même s’il n’y a pas de panneau « Interdit de marcher sur les pelouses », un citoyen responsable s’abstiendra par civisme. Même absence de règles explicites, mais comportement autonome guidé par la conscience collective.
Même chose ici : même s’il n’y a pas de restriction formelle, chacun devrait réfléchir à l’impact de ses actions. Pourquoi tant d’indifférence ? Je pense que la réponse est simple : beaucoup n’exécutent pas de nœud complet. Ils ne perçoivent donc pas les efforts cachés derrière les services qu’ils utilisent. S’ils réalisaient que leur usage repose sur des contributions invisibles, ils seraient probablement plus prudents. Malheureusement, dans un contexte spéculatif où règnent bulles et intérêts personnels, ces appels à la responsabilité tombent dans le vide. C’est décourageant.
Jeffrey Hu : J’ai aussi entendu une autre idée répandue : certains disent que les inscriptions actuelles sont une avancée technique par rapport à OP_RETURN. En effet, OP_RETURN n’irritait pas tant les développeurs, car il permettait d’écrire peu de données – contrairement aux inscriptions actuelles qui en exploitent davantage grâce à un bug découvert par Luke. Mais d’après ce que vient d’expliquer A Jian, ce n’est pas vraiment là que se situe le problème. D’après moi, la différence clé entre OP_RETURN et les inscriptions modernes réside dans leur mécanisme. Bien qu’OP_RETURN puisse transporter des données – voire servir à émettre ou transférer des jetons – il diffère fondamentalement des inscriptions ou des méthodes qui dissimulent des données dans des signatures. Pourquoi ? Parce qu’un output OP_RETURN n’entre jamais dans l’UTXO set. Son nom même l’indique : dans le script, quand on arrive à OP_RETURN, l’exécution s’arrête immédiatement – comme un « return » dans un langage de programmation. Cet output devient donc intrinsèquement impensable. Il ne peut plus jamais être dépensé. Techniquement, ce n’est même plus un UTXO – puisqu’il n’est pas « unspent » (non dépensé), mais carrément impensable.
C’est pourquoi les implémentations récentes de nœuds ont optimisé ce cas : elles ne conservent pas les outputs OP_RETURN dans l’UTXO set. C’est une amélioration – ou modification – qui évite de surcharger inutilement le réseau. C’est donc une solution bien moins problématique, tant en termes de controverse que de charge opérationnelle pour les nœuds.
A Jian : Oui. En réalité, OP_RETURN et les méthodes actuelles sont largement interchangeables. Bien sûr, les amateurs d’NFT Ordinals veulent pouvoir inscrire intégralement les données médias d’un NFT en une seule fois – besoin légitime, certes. Mais ce n’est pas le cœur du problème. Ce qui compte, c’est l’impact sur l’UTXO set. Par exemple, même si BRC20 utilisait OP_RETURN pour stocker ses données, cela ne changerait rien à l’inflation de l’UTXO set. Le vrai problème, c’est l’utilisation d’un système catastrophique de contrat intelligent hors chaîne. Honnêtement, les utilisateurs de BRC20 devraient adopter OP_RETURN : leur méthode actuelle est économiquement inefficace, nécessitant deux transactions pour transférer des fonds. Avec OP_RETURN, ils pourraient tout faire en une seule transaction, à moindre coût.
Quoi qu’il en soit, la racine du problème est bien l’utilisation de mauvais systèmes de contrats intelligents hors chaîne. Même le développeur à l’origine des Ordinals, qui propose de suivre les satoshis comme base de contrats hors chaîne, travaille maintenant sur un nouveau protocole de jetons fongibles basé uniquement sur le suivi des UTXO. Si les gens utilisaient cela, on éviterait les problèmes causés par BRC20. Ce serait bien plus conforme aux attentes. Mais au moment d’enregistrer ce podcast, je ne vois pas quand cela arrivera. C’est lamentable.
Jeffrey Hu : Passons à un autre malentendu, ou mythe courant. A Jian vient de souligner l’importance d’exécuter un nœud complet. Mais beaucoup pensent que cela ne sert à rien, sauf peut-être pour accélérer un mint d’inscription ou de BRC20. Sinon, ils croient que ce sont toujours les mineurs qui décident des nouvelles fonctionnalités. Alors, quelle est la véritable importance d’exécuter un nœud complet ? Beaucoup ne le réalisent pas. Hier encore, j’ai lu un article affirmant que, contrairement à Ethereum, sur Bitcoin ni les développeurs ni personne n’ont le pouvoir absolu. Les mises à jour doivent passer par un vote des mineurs. Même si les développeurs poussent une mise à jour, les mineurs peuvent refuser de l’adopter, ou bloquer l’activation. Qu’en pensez-vous, A Jian ?
A Jian : Jeffrey a mentionné la distinction entre fourches molles et dures – mises à jour compatibles ou non. Mais je voudrais reculer d’un pas. Rappelons à tous les auditeurs que, quelle que soit la terminologie, mettre à jour un projet cryptographique aussi important que Bitcoin, Ethereum ou tout autre projet prometteur comporte des risques énormes et est extrêmement difficile. Cela implique une coordination préalable, la définition du contenu de la mise à jour, la concertation entre toutes les parties prenantes, l’expression des avis, et enfin l’activation coordonnée du réseau – autrement dit, une synchronisation collective autour de nouvelles règles de consensus. Ce processus est extrêmement complexe, coûteux en énergie, et toujours potentiellement dangereux. Le fait que nous ayons réussi plusieurs fourches molles ou dures par le passé ne change rien à ce risque inhérent – c’est valable pour tout projet de cryptomonnaie.
Revenons au cas spécifique de Bitcoin. Oui, il existe un processus de vote des mineurs pour les mises à jour. Deux exemples marquants : SegWit et Taproot. Dans les deux cas, les mineurs ont dû voter. Mais faut-il croire que les utilisateurs, ou les opérateurs de nœuds complets, sont simplement des spectateurs passifs ? Doivent-ils juste accepter ce que proposent les développeurs ou ce que les mineurs décident en bloc ? Pas du tout. Prenons l’exemple de SegWit. Cette technologie était discutée depuis longtemps – selon la troisième édition de « Mastering Bitcoin », elle remonterait à 2011. Mais son activation effective n’a eu lieu qu’en 2017. Entre 2015 et 2017, des débats violents ont opposé développeurs, mineurs et utilisateurs.
Un moment clé fut la proposition du BIP 148 – je ne me souviens plus du numéro exact. Son auteur proposait une implémentation cliente qui forcerait l’activation de SegWit. Comment ? Normalement, SegWit étant une fourche molle, chaque mineur signale sa préparation via un bit spécial dans les blocs qu’il extrait. Pendant une période de réajustement de difficulté (2016 blocs), si un seuil suffisant de mineurs (50 % ou 80 %) exprime son soutien, la mise à jour est activée.
Mais initialement, beaucoup de mineurs – surtout les pools – adoptaient une attitude passive : « Attendons de voir si les autres soutiennent. Si personne ne bouge, moi non plus. » C’est là qu’intervient BIP 148 : tout utilisateur d’un client implémentant BIP 148 refuserait automatiquement, à partir d’une date donnée, tout bloc ne signalant pas le support de SegWit. Autrement dit, si un mineur extrait un bloc sans signal, ce bloc est jugé invalide par ces nœuds. Si la majorité des nœuds suit BIP 148, alors un fork se produirait : la chaîne validée ne conserverait que les blocs des mineurs ayant exprimé leur soutien.
C’est un exemple frappant de l’influence qu’un opérateur de nœud complet peut exercer lors d’une mise à jour controversée. Cette proposition a suscité de vives polémiques : certains la jugeaient légitime, d’autres y voyaient un risque excessif de fork, donc une méthode à proscrire.
Finalement, BIP 148 n’a pas été massivement adopté. Mais ce cas montre clairement qu’un nœud complet n’est pas condamné à l’attente passive. Il peut agir de façon proactive – certes, parfois de manière agressive, ce qui peut menacer le consensus. Mais cela démontre que votre pouvoir en tant qu’opérateur de nœud est bien plus grand que ce que beaucoup imaginent.
Je voudrais ajouter quelques points. Exécuter un nœud complet n’a jamais, pendant presque toute l’histoire de Bitcoin, procuré de bénéfice économique direct. Ces derniers mois – peut-être un an – ont été une exception : certains utilisateurs pensent que cela accélère la diffusion de leurs transactions, leur offrant un avantage économique. Mais historiquement, ce n’était pas le cas. Pourtant, c’est ce réseau de nœuds complets qui garantit des propriétés fondamentales de Bitcoin : résistance à la censure, vérification sans confiance de la blockchain, assurance que les bitcoins reçus sont authentiques, protection de la vie privée financière (personne ne peut localiser vos adresses IP ou traquer vos activités), et maintien d’un seuil d’entrée bas pour l’exploitation minière.
Imaginez un réseau réduit à trois nœuds, tous contrôlés par des mineurs. En tant que petit mineur, vous ne pouvez pas concurrencer : ils peuvent garder les transactions pour eux, vous empêchant de percevoir des frais. Ainsi, l’accessibilité des nœuds complets est cruciale même pour la décentralisation minière.
Oui, exécuter un nœud complet ne rapporte pas d’argent, mais c’est vital. C’est pourquoi les développeurs Bitcoin travaillent sans relâche à rendre le logiciel plus efficace, à renforcer les règles de protection des nœuds, et surveillent attentivement toute action susceptible d’alourdir la blockchain ou l’UTXO set. Tout cela vise à préserver l’accessibilité des nœuds complets, condition sine qua non de la survie à long terme de Bitcoin et de sa valeur.
Exécuter son propre nœud complet ne vous enrichira pas, mais cela protège votre vie privée financière, vous permet de vérifier sans confiance tous les blocs, vous assure de ne pas recevoir de faux bitcoins, et vous permet de contribuer au réseau : aider d’autres nœuds à recevoir rapidement les nouvelles transactions et blocs, accélérer la validation, et faciliter l’entrée de nouveaux mineurs. Ces contributions sont essentielles, même si elles ne sont pas rémunérées. Voilà pourquoi nous sommes si sensibles aux questions d’aujourd’hui : les inscriptions gonflent-elles la blockchain ? BRC20 est-il bénéfique ou nuisible ? Clairement, s’il ne fait qu’enfler l’UTXO set, c’est uniquement nuisible.
Jeffrey Hu : Oui, tout cela forme un système interconnecté. Modifier un élément affecte tout le reste – c’est ma conviction. J’ajoute ceci : récemment, j’ai participé avec Yu语里弄 à un club de lecture de la troisième édition de « Mastering Bitcoin ». En la lisant, j’ai été surpris dès les premiers chapitres – pourtant basiques – par une idée qui a bouleversé ma compréhension du nœud complet. Comme beaucoup, je pensais qu’un Full Node était simplement un nœud stockant l’intégralité du registre. Mais ce livre donne une définition très claire : FULL NODE signifie Full Verification Node – nœud de vérification complète.
Autrement dit, ce n’est pas juste un stockage passif, mais une capacité à vérifier activement et intégralement les transactions qui vous concernent. Cela renforce considérablement la sécurité de vos fonds. À l’inverse, les nœuds légers (light nodes) ou clients légers doivent récupérer l’en-tête du bloc auprès d’un full node, puis demander les transactions pertinentes, avant de les vérifier localement. Or, comme l’a dit A Jian, ce processus expose à des risques : atteinte à la vie privée, censure possible par le full node, filtrage de transactions. Par exemple, si je veux envoyer une transaction BRC20 et qu’un full node refuse de la transmettre ? La solution est simple : exécutez votre propre full node. Personne ne pourra vous bloquer. À moins, bien sûr, que le réseau devienne si lourd que l’exécution d’un full node devienne impossible.
Un dernier point sur les mineurs : beaucoup pensent que leur puissance de calcul leur donne un contrôle absolu. Une idée fausse courante est que, avec 51 % de la puissance de hachage, un mineur peut tout faire. Ce n’est pas vrai. Un double spend, par exemple, ne concerne que ses propres fonds : il peut annuler un paiement qu’il a fait, mais il ne peut pas modifier arbitrairement l’historique complet de la blockchain. S’il tentait cela, ce serait une autre forme de fork dur. Donc non, avoir 51 % ou pratiquer le minage égoïste avec 30 % ne donne pas carte blanche. Ce sont des idées reçues à corriger.
Voilà donc quelques compléments sur le sens d’exécuter un full node.
A Jian : J’ajoute un point, qui risque de froisser certains. Je connais des personnes qui, au fond d’elles-mêmes, vouent un culte au pouvoir : elles croient que la force permet tout, que la force est bonne en soi, et que les autres doivent s’y soumettre ou la craindre. Cela fonctionne dans beaucoup de domaines de la vie. Mais Bitcoin n’est pas né de ce culte de la force. Au contraire, Bitcoin est conçu pour limiter tout pouvoir, afin de préserver la liberté individuelle. Ce logiciel n’existe pas pour donner du pouvoir à certains, mais pour empêcher que quiconque en accumule trop. Sa philosophie fondamentale va à l’encontre de l’idée que « le plus fort a toujours raison ».
C’est là, selon moi, la grande vertu de Bitcoin. Toutes les cryptomonnaies ne partagent pas ce principe. Certaines projets manifestent clairement un culte du pouvoir, ou de la personnalité charismatique – qu’on appelle « charisme » ou « leadership visionnaire ». Elles ne cherchent pas à limiter ce pouvoir extraordinaire.
Bitcoin, lui, vise un système sans point de défaillance unique, résistant à la censure, où chaque nœud complet peut vérifier la blockchain à moindre coût, garantissant ainsi la confidentialité financière et la liberté des transactions. Il veut utiliser Bitcoin pour protéger la propriété individuelle, le droit de chacun sur ses propres biens.
Si vous croyez que la force justifie tout, vous ne pourrez jamais apprécier ce qu’est Bitcoin. Pour vous, Bitcoin ne sera qu’un moyen d’enrichissement rapide, source de pouvoir. Cela peut être un effet secondaire temporaire, mais ce n’est pas ce que veulent ceux qui construisent Bitcoin, ni ceux qui croient en sa mission. Le monde qu’ils espèrent n’est pas celui-là.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
