BB84, un rollup OP Stack actif sur le mainnet Ethereum sous l'ID de chaîne 42069000, a entièrement supprimé les signatures de transaction de son réseau, les remplaçant par des chaînes de hachage de type Lamport dans une conception destinée à atténuer la menace quantique à long terme pesant sur la cryptographie conventionnelle. Le réseau fonctionne sur le mainnet depuis le 30 septembre. Son fondateur, qui publie sous le pseudonyme Hadamard, a décrit le système dans une publication Ethereum Research du 24 octobre et a demandé des retours critiques.

Les comptes Ethereum ordinaires autorisent les transactions avec des signatures ECDSA, qu'un ordinateur quantique suffisamment puissant exécutant l'algorithme de Shor pourrait briser. Aucune machine capable de cela n'existe aujourd'hui, mais les avertissements concernant l'exposition des clés de portefeuille ont poussé les développeurs à chercher des alternatives — une clé devient publiquement visible dès qu'un compte a envoyé une transaction. Les constructions basées sur le hachage comptent également parmi les plus anciennes candidates post-quantiques : Leslie Lamport a proposé un schéma de signature basé sur le hachage en 1979, et les normes post-quantiques de 2024 du NIST incluent un schéma basé sur le hachage, SLH-DSA.

Des comptes à chaîne de hachage, une étape à la fois

Chaque compte BB84 est construit à partir d'un secret qui est haché de manière répétée avec keccak-256 — la même fonction de hachage qu'Ethereum utilise lui-même — créant une chaîne de valeurs dont seule la dernière est publique. Pour payer, le portefeuille révèle la valeur qui précède la position actuelle, ce que n'importe qui peut vérifier en le hachant une fois. Le réseau enregistre ensuite cette valeur et fait avancer le compte d'une étape dans la chaîne.

La valeur par défaut du protocole est de 1 000 paiements par chaîne de hachage, tandis que le CLI développeur de BB84 crée des chaînes de 10 étapes pour chaque adresse à usage unique. Une étape est consommée même si le paiement lui-même échoue, et la chaîne rejette toute transaction signée de manière conventionnelle.

Les paiements s'effectuent uniquement en USDC et EURC pontés. Les transactions de commit et de reveal sont gratuites pour les utilisateurs, et les payeurs créent une nouvelle adresse à usage unique pour chaque destinataire.

Le compromis de sécurité

La publication détaille les limites de la conception. À l'intérieur du réseau, tout repose sur la difficulté à inverser keccak-256, et l'algorithme de recherche quantique de Grover ne réduirait cela qu'à environ 2^128 opérations. Les adresses, however, sont raccourcies à 160 bits, ce qui laisse environ 2^80 de résistance quantique sur l'adresse elle-même. La documentation de BB84 met en avant une sécurité post-quantique de 128 bits sans cette réserve. Le mainnet Ethereum est également toujours en ECDSA : les dépôts proviennent de portefeuilles Ethereum ordinaires, et les retraits y sont versés.

Une faille de front-running découverte pendant la rédaction de la publication

Révéler un secret le rend public, de sorte que quiconque l'observe pourrait le cop dans une transaction s'payant à lui-même. Pour éviter cela, le portefeuille envoie d'abord une transaction de commit qui verrouille le secret sur un paiement exact sans le montrer. Le reveal doit suivre dans un délai de cinq blocs par défaut.

Le point faible était que les commits ne portent aucune signature, car il n'y a rien avec quoi signer. Dans la première version, un nouveau commit remplaçait simplement le commit en attente. Un attaquant repérant un secret dans un reveal en attente pouvait insérer un commit liant ce secret à son propre paiement. Hadamard indique que l'équipe a découvert la faille pendant la rédaction de la publication et l'a corrigée avec une nouvelle règle entrée en vigueur le 21 octobre. Selon la règle révisée, le premier commit gagne, l'emplacement n'est libéré qu'après le reveal correspondant ou son expiration, le portefeuille attend que son commit soit inclus dans un bloc avant de révéler, et le RPC public n'expose pas les transactions en attente.

Ce que la correction ne couvre pas

Le griefing reste possible : n'importe qui peut publier un commit indésirable et bloquer une adresse pendant cinq blocs au maximum, sans toutefois pouvoir déplacer ses fonds. Un séquenceur malveillant constitue un autre risque résiduel : si un commit honnête expire ou est réorganisé hors de la chaîne pendant que son reveal est en attente, le secret n'est plus verrouillé. Aujourd'hui, seul le séquenceur de BB84 lui-même voit les transactions en attente.

Hadamard suggère une règle « Guy Fawkes » plus stricte, dans laquelle les commits sont ajoutés plutôt que remplacés, mais indique qu'elle n'a pas été mise en œuvre. La documentation va plus loin que la publication, affirmant que le mécanisme de commit et reveal empêche un séquenceur de voler un retrait.

Un portefeuille qui ne doit pas perdre le compte

Comme chaque chaîne comporte un nombre fixe d'étapes, le portefeuille doit la renouveler à la toute dernière en incluant un nouvel engagement dans ce paiement final. S'il manque cette étape, l'adresse est morte. Tenir le compte est tout aussi important : Hadamard indique que l'application et la chaîne se sont désynchronisées en production, de sorte que les portefeuilles doivent pouvoir se resynchroniser à partir des données de la chaîne.

Les secrets doivent toujours être protégés comme des clés. Le CLI avertit que son fichier de portefeuille stocke les clés de dépense non chiffrées et liste le chiffrement comme un élément de sa feuille de route. La suppression des signatures modifie la manière dont les dépenses sont autorisées, pas la nécessité de protéger les secrets.

Les retraits reposent sur un opérateur de confiance

BB84 n'a pas de fault proofs. Un proposeur autorisé publie l'état du réseau sur Ethereum via un jeu de litige personnalisé qui se résout immédiatement, et sans système de preuve, Hadamard écrit que selon le cadre de L2BEAT, la chaîne « ne serait même pas au Stage 0 ». Ce cadre classe les rollups du Stage 0 au Stage 2 selon le degré de confiance que les utilisateurs doivent accorder à un opérateur plutôt qu'à un système de preuve. Les retraits font donc confiance au proposeur. La documentation décrit toujours les retraits comme suivant le flux de fault proofs de l'OP Stack avec un délai de maturité de sept jours, mais comme le précise l'explication d'Optimism, les fault proofs existent pour permettre de contester un état erroné — et ici rien ne peut être contesté pendant cette attente. Le séquenceur est également exploité par BB84.

Ce qui changerait la donne

La publication se termine par des questions qui dépassent le cadre d'une seule chaîne. La plus importante est de savoir si les comptes à chaîne de hachage pourraient devenir un mode de validation de type EIP-7702 ou d'abstraction de compte native sur des réseaux layer-2 à usage général, ce qui rendrait l'idée accessible sans devoir migrer vers une chaîne dédiée. L'EIP-7702, actif depuis la mise à niveau Pectra d'Ethereum en mai 2025, permet aux comptes ordinaires d'adopter du code de smart contract. Hadamard ajoute que les vérifications supplémentaires assez simples pour être prouvées avec l'outil Cannon existant d'Optimism, qu'une règle de commit en ajout seul fermerait à la fois les failles de griefing et de séquenceur malveillant, et qu'un document plus détaillé avec les règles complètes est en préparation pour arXiv. L'effort de migration plus large d'Ethereum, décrit dans sa feuille de route quantique, couvre également les signatures des validateurs, les engagements de données et les systèmes de preuve.

Cet article est fourni à titre d'information uniquement et ne constitue pas un conseil financier ou d'investissement. Les réseaux expérimentaux comportent des risques techniques et de garde.

Source : Coindoo