Aujourd’hui, sur le réseau Bitcoin, une véritable drame d’ampleur historique s’est joué. Le principal défenseur institutionnel du Bitcoin, le patron de MicroStrategy, Michael Saylor, a publié un manifeste monumental intitulé « 110 raisons pour lesquelles BIP-110 est une mauvaise idée ». Saylor s’est fermement opposé aux tentatives de modifier le consensus de la couche de base (L1) afin de lutter contre le « spam » (inscriptions et jetons), en qualifiant cela de menace pour la neutralité du protocole.
Et il ne s’est pas écoulée plus d’une heure avant que la réalité technique ne porte un coup dévastateur aux partisans du fork. Une vulnérabilité critique du consensus, dévoilée publiquement sous le nom de code BlockSlop, casse la logique de mise à jour des nœuds dans BIP-110.
Démêlons cela sans émotion : qu’est-ce qui s’est passé, pourquoi le remède s’est révélé plus dangereux que la maladie elle-même, et comment cela change l’architecture de la mise à l’échelle de Bitcoin.
🔥 Guerre de religion : Deux camps morts-ends dans X
La discussion autour de BIP-110 a mis en évidence de façon claire une fracture profonde au sein de la communauté, où le compromis est impossible :
Le camp « par amour de l’art » :
Des maximalistes radicaux qui exigent une pureté absolue de Bitcoin. Ils sont prêts à introduire un filtrage strict des données et à modifier les règles de consensus, uniquement pour que leurs nœuds domestiques restent « légers ».
Le camp « à 1,5 million de dollars par pièce » :
Des témoins de l’éternel Tuzu-moon, guidés par les promesses des institutions. Ils s’en fichent de la décentralisation et de la charge sur les nœuds — si des images JPEG ou des memecoins pumpent le prix et rapportent des commissions aux mineurs tout de suite, ils sont prêts à les bourrer dans chaque bloc.
Les deux camps font la même erreur : ils essaient de résoudre un problème économique et architectural de Bitcoin par des moyens politiques sur la couche de base (L1). Et le bug BlockSlop l’a prouvé — https://blockslop.dev/
🔍 C’est quoi BlockSlop et pourquoi c’est une catastrophe ?
L’essence technique de la vulnérabilité de BlockSlop réside dans le « upgrade validation gap » (un écart de validation lors d’une mise à jour tardive).
Toutes les nouvelles règles de filtrage des données BIP-110 sont définies dans la fonction ConnectBlock(). Cependant, lors d’un simple redémarrage après une mise à niveau du nœud Bitcoin, par défaut, il charge déjà la base de données UTXO (chainstate) existante et fait aveuglément confiance à l’état enregistré. Elle ne vérifie que quelques derniers blocs, mais ne se reconnecte jamais à l’historique ancien.
Quand SegWit (BIP-141) a été introduit, les développeurs avaient prévu ce problème : ils ont créé un mécanisme de protection spécial (NeedsRedownload() ) qui vérifiait de force l’historique et envoyait le nœud vers un refus sûr (-reindex) si les données n’étaient pas validées selon les nouvelles règles. Pour BIP-110, cette protection a été oubliée.
Résultat : si un nœud a téléchargé un bloc qui viole les règles BIP-110 avant sa mise à jour, alors après l’upgrade il continuera à considérer ce bloc invalide comme vrai et à construire sa chaîne par-dessus. En même temps, un nœud fraîchement lancé à partir de zéro rejettera ce bloc sans appel.
Saylor l’a littéralement prédit dans le point 50 de son manifeste : « L’exception du grand-père rend la validité dépendante de l’historique... Cela augmente la complexité de l’implémentation et crée des bugs ». Le réseau se scinde non pas en deux parties, mais en $1 + N chaînes incompatibles, où chaque nœud mis à jour se retrouve bloqué dans son propre historique « sale » unique.
💡 La seule issue : la modularité et la couche 2
L’échec de BIP-110 et de BlockSlop a prouvé de façon frappante que la couche de base de Bitcoin doit rester aveugle, conservatrice et neutre monétairement. On ne peut pas utiliser des lois de consensus pour censurer les intentions humaines.
Il faut gérer le coût des ressources physiques de la blockchain directement via des mécanismes de marché, mais le faire aux bords décentralisés du réseau (Layer 2).
Un exemple éclatant de la bonne approche d’ingénierie est l’architecture de mise à l’échelle de type Nervos ($CKB ) avec sa technologie d’attachement isomorphe (RGB++). Au lieu de surcharger L1 de Bitcoin avec une logique complexe de tokens ou d’essayer de l’interdire, toute la programmabilité est déplacée sur des rails modulaires flexibles.
Et pourtant, le problème du « gonflement des données » (state bloat) y est résolu dès le départ au niveau économique avec le modèle de state-rent (1 pièce CKB = 1 octet d’espace). Tu veux stocker des données pour toujours ? Bloque le capital pour ça. Le marché se régule tout seul, les nœuds restent propres, et $BTC sur L1 conserve une neutralité absolue, sans risquer de catastrophiques splits de chaîne.
🏁 Conclusion
Essayer de « guérir » Bitcoin avec des interdictions administratives du consensus s’est avéré être une iatrogénie classique — un cas où le remède blesse le patient pire que la maladie elle-même. Bitcoin n’a pas besoin de « gardiens de la pureté ». Bitcoin a besoin de « gardiens de la neutralité ». Et aux ingénieurs : il est temps d’arrêter de se battre dans les commentaires et de se concentrer sur la construction de solutions modulaires de Layer 2.
Et n’oubliez pas : ce n’est pas un conseil financier, faites votre analyse (DYOR). En crypto, nous ne prenons jamais de risques avec l’argent qui nourrit la famille.