Le débat sur les blocs plus grands relancé par Bitcoin et…
La modélisation du ML-DSA-44 de NIST implique que les blocs pourraient contenir environ 500 à 700 transactions sans atténuation.
Le mouvement à long terme du Bitcoin vers des signatures post-quantiques fait resurfacer une ancienne ligne de faille de mise à l'échelle : absorber des signatures plus grandes avec des blocs plus grands, ou les compresser avec l'agrégation ZK-STARK.
Un schéma NIST modélisé place l'impact potentiel sur le débit en termes clairs, avec une capacité de bloc estimée à tomber à environ 500–700 transactions contre environ 2 500–3 000 aujourd'hui si rien d'autre ne change.
Points clés
- Les schémas de signature post-quantique approuvés par le NIST sont décrits comme étant de 10 à 100 fois plus grands queBitcoinles signatures ECDSA et Schnorr actuelles.
- La modélisation de ML-DSA-44 à 2 420 octets par signature implique que la capacité des blocs Bitcoin pourrait chuter à environ 500–700 transactions contre environ 2 500–3 000 aujourd'hui.
- Le débat sur l'atténuation est cadré autour de deux leviers : augmenter la taille des blocs de Bitcoin ou agréger les signatures dans une petite preuve ZK-STARK.
- Le script Bitcoin ne peut pas vérifier un STARK aujourd'hui, et Marin Ivezic a caractérisé la vérification STARK de couche de base comme étant « réalistiquement une conversation des années 2030 ».
Les signatures post-quantiques remettent le débit de Bitcoin sous les projecteurs.
L'impact sur le marché à court terme ne concerne pas l'apparition des ordinateurs quantiques demain. Il s'agit de ce qui arrive au débit et à la dynamique des frais de Bitcoin si le réseau migre un jour des schémas de signature ECDSA et Schnorr vers des schémas de signature post-quantiques (PQ) qui sont matériellement plus grands.
Les schémas de signature PQ approuvés par le NIST sont décrits comme étant environ 10 à 100 fois plus grands que les signatures existantes de Bitcoin. Cette augmentation de taille n'est pas cosmétique. Les signatures sont une partie essentielle du poids des transactions, donc l'enflure des signatures se traduit directement par moins de transactions par bloc, à moins que le protocole ne change ailleurs.
Marin Ivezic, auteur de PostQuantum.com et fondateur d'Applied Quantum, a modélisé le ML-DSA-44 du NIST à 2 420 octets par signature et a estimé que la capacité des blocs tomberait à environ 500 à 700 transactions par bloc, contre environ 2 500 à 3 000 aujourd'hui.
SegWit est décrit comme réduisant l'impact des grandes signatures de jusqu'à 75 %, mais l'estimation du ML-DSA-44 implique toujours une réduction suffisamment importante pour ramener les récits de mise à l'échelle et de marché des frais au centre de la feuille de route de Bitcoin.
Deux solutions concurrentes : blocs plus grands contre agrégation de signatures ZK-STARK
Le débat est présenté comme un choix entre un levier politiquement difficile et un levier techniquement difficile.
Un chemin est une ingénierie simple : augmenter la taille des blocs de Bitcoin pour absorber les plus grandes signatures PQ. Le compromis est le coût des nœuds. Des blocs plus grands signifient plus de bande passante, de stockage et de travail de vérification pour chaque nœud complet, ce que les critiques soutiennent pousse le réseau vers la centralisation. Le combat sur la taille des blocs n'est pas théorique non plus.
Bitcoin s'est scindé sur une proposition de doubler la taille des blocs en 2017, et cette histoire façonne encore les réflexes de gouvernance.
L'autre chemin est la compression : agréger les signatures dans une preuve ZK-STARK afin que les blocs n'aient pas à porter chaque signature individuelle.
Eli Ben-Sasson, co-fondateur de StarkWare, a soutenu qu'une seule preuve pourrait compresser "toutes les grandes signatures de transaction pour un bloc" en une preuve "minuscule", et a affirmé que la preuve pourrait être plus petite que l'inclusion même des signatures d'aujourd'hui, rendant potentiellement la chaîne plus rapide.
Il a averti que l'adoption des signatures PQ sans agrégation échouerait au test d'utilisabilité : "Si elles ne permettent pas l'agrégation ZK STARK, alors ce sera définitivement un mouvement très malheureux car cela ne résoudra pas vraiment le problème... où le problème est 'tout le monde peut-il réellement utiliser Bitcoin ?'"
Pourquoi les STARKs ne sont-ils pas plug-and-play sur Bitcoin aujourd'hui
La contrainte n'est pas de savoir si les STARKs fonctionnent dans l'abstrait. C'est de savoir si Bitcoin peut les vérifier sous les règles de consensus sans élargir la surface d'attaque.
Ivezic a soutenu que "la cryptographie d'Eli est solide comme un roc : des hypothèses de hachage pures, pas de configuration de confiance, des milliers de signatures compressées en une petite preuve.
Le problème est tout ce qui entoure la cryptographie", ajoutant : "Le Script Bitcoin ne peut pas vérifier un STARK aujourd'hui, et un vérificateur de production est une surface de consensus massive par rapport à un opcode de signature de hachage étroit. Étant donné qu'un petit opcode comme OP_CAT a passé des années en débat, un vérificateur STARK de couche de base est réalistiquement une conversation des années 2030."
Le moyen d'accès le plus "politiquement pragmatique" discuté est de réactiver OP_CAT, décrit comme neuf lignes de code écrites par Satoshi. Ben-Sasson a soutenu qu'OP_CAT pourrait permettre des preuves STARK et l'agrégation, mais l'intérêt qui a surgi il y a 12 à 24 mois est décrit comme ayant perdu de l'élan plus récemment.
D'autres idées plus spéculatives mentionnées incluent OP_STARK_VERIFY et BitZip, et Ethan Heilman a cadré l'espace de conception comme ajoutant des opcodes à usage général pour construire quelque chose comme un ZKRollup sur Bitcoin ou en soutenant les STARKs au niveau du consensus, avec des options d'agrégation plus faibles comme CISA également sur la table.
Signaux que les traders devraient suivre dans la feuille de route Bitcoin PQ
Le premier signal est le mouvement concret des BIP ou le renouvellement des signaux des mainteneurs et des développeurs autour de la réactivation d'OP_CAT, car cela est présenté comme le pont le plus pragmatique vers des constructions liées à STARK.
Le deuxième est de savoir si une proposition pour activer la vérification STARK sur Bitcoin progresse au-delà de la discussion. Le script ne peut pas vérifier un STARK aujourd'hui, donc la question pertinente pour le marché est de savoir si la conversation se déplace vers des approches basées sur les opcodes ou un soutien au niveau du consensus, et si l'une ou l'autre gagne un élan crédible.
Troisièmement, surveillez les modélisations et les benchmarks de suivi qui affinent l'estimation ML-DSA-44 de 2 420 octets par signature et les ~500–700 transactions par bloc impliquées. Si des schémas PQ alternatifs changent matériellement le profil de taille de signature, l'urgence du compromis d'évolutivité change avec cela.
Enfin, les jalons inter-chaînes peuvent créer une pression narrative. Starknet a annoncé un projet en trois phases pour devenir sécurisé contre les quantiques, et l'article décrit Ethereumcomme visant 2029 pour une transition post-quantique tandis que Solanaexpérimente avec des signatures PQ. Ces délais ne forcent pas la main de Bitcoin, mais ils peuvent modifier les attentes sur ce à quoi ressemble un progrès « raisonnable ».
La gouvernance, pas la cryptographie, semble être le véritable goulet d'étranglement.
Je considère le modèle ML-DSA-44 comme la fonction de contrainte clé. Si Bitcoin devait un jour adopter un style PQ de NIST sans atténuation, les mathématiques de débit seraient suffisamment laides pour ramener la mise à l'échelle et les frais dans le récit macro, même si la menace quantique elle-même reste à long terme.
Le seuil qui compte est de savoir si la gouvernance de Bitcoin peut converger vers un chemin d'atténuation crédible avant que le PQ ne devienne plus qu'un sujet de recherche. Des blocs plus grands sont le levier d'ingénierie le plus simple mais historiquement le plus difficile à socialiser, tandis que l'agrégation STARK se lit plus clairement sur le débit mais se heurte directement aux limites de Script et au risque de surface de consensus.
Si OP_CAT ou tout chemin de vérification STARK passe de "intéressant" à "actionnable", la configuration commence à sembler structurelle plutôt que guidée par le récit, car elle définirait comment Bitcoin absorbe une mise à niveau de sécurité sans rouvrir la guerre sur la taille des blocs.
