Crypto ne peut plus continuer ainsi : un appel à l'auto-sauvetage d'un professionnel de la blockchain

Auteur : Robert Mao, fondateur et PDG d'ArcBlock

Cet article est autorisé à être reproduit et partagé librement, dans l'espoir de faire voir cet appel à l'auto-sauvetage de l'industrie par un plus grand nombre de personnes.

Crypto ne peut plus continuer ainsi. Les vols massifs répétés ne volent pas seulement des actifs, mais aussi la confiance des participants dans l'ensemble de l'industrie. Nous devons nous auto-sauver.

Le 29 octobre 2026, Binance a subi un grave incident de sécurité. Son annonce préliminaire estime qu'environ 6,3 milliards de dollars d'actifs ont été affectés, dont environ 3 milliards de dollars d'actifs ont été gelés ; l'enquête a d'abord pointé vers le portable d'un ingénieur DevOps, puis d'autres points d'intrusion possibles ont été découverts. Binance a également déclaré qu'aucune preuve de fuite de clés privées de portefeuille n'avait été trouvée. Le montant affecté n'est pas la perte nette finale, la chaîne d'attaque complète reste à enquêter.[[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/ " \l "fn-binance)

Cet appel est adressé aux bâtisseurs de projets blockchain comme Ethereum, Solana, ainsi qu'à Binance, Coinbase, Kraken et à tous les échanges, portefeuilles, protocoles et bâtisseurs de sécurité désireux de participer : reconstruisons ensemble les bases de la protection des actifs. Je suis prêt à participer et j'espère que d'autres agiront également.

C'est déjà assez lourd. Mais je crains encore plus que cet incident ne fasse perdre confiance à de nombreuses personnes dans Crypto, et que de nombreux attaquants considèrent cette industrie comme une cible à continuer d'exploiter. Même si quelqu'un finit par supporter les pertes, les compensations ne peuvent pas automatiquement restaurer la confiance des utilisateurs, et ne peuvent pas empêcher la répétition de la même destruction.

Binance n'est qu'une porte d'entrée qui nous oblige aujourd'hui à faire face à des problèmes. En détournant le regard, les échanges, les ponts, les protocoles en chaîne et les portefeuilles ont déjà laissé une longue liste de blessures. De nouveaux réseaux et produits continuent d'apparaître, mais les anciens modes de défaillance se répètent sans cesse. Nous ne pouvons pas publier un communiqué, attendre un moment, puis considérer le prochain incident comme une routine.

Nous devons également reconnaître que les escroqueries et les pratiques qui ne produisent que des concepts sans assumer de responsabilités de construction ont blessé cette industrie trop longtemps. Les équipes qui travaillent sérieusement sur la technologie et l'infrastructure doivent également supporter les conséquences de la perte de confiance. Lorsque les gens considèrent l'ensemble de Crypto comme une escroquerie, les technologies et explorations réellement dignes d'être préservées pourraient également être abandonnées.

En tant que fondateur d'ArcBlock et professionnel de Crypto et Blockchain, je ne veux pas accepter une telle fin. Je crois que cette industrie a une valeur qui mérite d'être protégée, et je pense que nous devons assumer la responsabilité de notre base de sécurité. Si nous continuons à attendre passivement le prochain incident, la perte répétée pourrait finalement détruire tout ce que nous avons construit ensemble.

Ainsi, je souhaite émettre cet appel : les bâtisseurs d'échanges, de portefeuilles et de blockchain doivent reconstruire ensemble les bases du contrôle des actifs et de la vérification de la sécurité, afin de limiter l'ampleur des destructions causées par une seule intrusion. La chronologie ci-dessous explique pourquoi un changement est nécessaire ; les solutions techniques qui suivent sont ce que je pense pouvoir commencer à faire.

Cette chronologie des incidents est déjà trop longue

En 2008, Satoshi Nakamoto a proposé un système de paiement électronique pair-à-pair, tentant de réduire la dépendance à l'égard des intermédiaires de confiance.[[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/ " \l "fn-bitcoin) Les incidents majeurs qui ont suivi ont continuellement exposé les problèmes de concentration des fonds, des autorisations et des dépendances logicielles.

Voici une liste chronologique d'événements représentatifs dans les domaines des échanges centralisés (CEX), des échanges décentralisés (DEX), des ponts et des portefeuilles. Ce n'est pas une base de données complète d'incidents, ni une statistique des pertes par an. Les montants indiqués, le cas échéant, se réfèrent à l'impact brut approximatif au moment de l'incident ; les vols, gel et récupérations ultérieures sont indiqués séparément et ne peuvent pas être additionnés comme pertes permanentes.

2008 · Livre blanc de Bitcoin

• Point de départ
• Le livre blanc de Bitcoin propose un paiement pair-à-pair sans intermédiaire financier.
• Source

2011--2014 · Vol à long terme de Mt. Gox

• CEX
• Mt. Gox a subi un vol à long terme et a finalement cessé ses activités. Les poursuites ultérieures du département de la Justice des États-Unis ont accusé que 647 000 BTC avaient été volés entre 2011 et 2014. Ce n'est pas une attaque unique survenue en 2014.
• Source

2012 · Bitcoinica et Bitfloor

• CEX / Infrastructure d'hébergement
• L'environnement d'hébergement Linode de Bitcoinica a été compromis ; la même année, la sauvegarde de portefeuille non cryptée de Bitfloor est devenue un point d'entrée pour l'attaque. Les serveurs et sauvegardes derrière la plateforme sont également des frontières de sécurité des actifs.
• Source

2015 · Portefeuille chaud de Bitstamp

• CEX
• Le portefeuille chaud de Bitstamp a été compromis, puis l'environnement d'exploitation a été reconstruit. L'officiel a distingué l'ampleur de l'incident de la réserve hors ligne, indiquant que l'isolement peut limiter l'exposition.
• Source

2016 · Bitfinex

• CEX
• Environ 120 000 BTC ont été volés chez Bitfinex. Les arrangements multi-signatures nécessitent toujours une autorisation et une vérification indépendantes de bout en bout.
• Source 1 · Source 2

2016 · The DAO

• Protocole en chaîne
• Le contrat The DAO a subi une attaque de réentrance, environ 3,6 millions d'ETH ont été transférés vers un sous-DAO, entraînant ensuite un fork d'Ethereum. Les chemins d'exécution légaux peuvent produire des résultats commerciaux catastrophiques.
• Source 1 · Source 2

2017 · Bibliothèque de portefeuilles partagés Parity

• Portefeuille de contrat
• La bibliothèque de portefeuilles partagés Parity a été détruite, environ 513 000 ETH ont été gelés. Ils n'ont pas été transférés, mais pourraient également avoir perdu leur capacité d'utilisation en raison de la dépendance au code commun.
• Source

2018 · Coincheck

• CEX
• Le portefeuille chaud NEM de Coincheck a été volé. La frontière entre les réserves hors ligne, les autorisations de portefeuille chaud et les besoins commerciaux est à nouveau devenue un problème.
• Source

2019 · Binance

• CEX
• Binance a annoncé que 7 000 BTC avaient été retirés en une seule transaction. Les sorties massives d'actifs doivent être contraintes avant la signature.
• Source

2020 · KuCoin

• CEX
• Incident du portefeuille chaud de KuCoin, qui a ensuite récupéré une grande partie des actifs grâce à une collaboration multi-parties. Le montant volé brut et la perte finale ne sont pas le même chiffre.
• Source

2021 · Poly Network

• Protocole inter-chaînes
• Environ 612 millions de dollars d'actifs ont été transférés hors de Poly Network, puis restitués progressivement. L'autorisation inter-chaînes et le contrôle des actifs ne peuvent pas dépendre uniquement des chemins d'affaires normaux.
• Source

2022 · Pont Ronin

• Pont
• Les droits des validateurs de Ronin ont été compromis, 173 600 ETH et 25,5 millions de USDC ont été transférés. Les clés de plusieurs validateurs pourraient également tomber entre les mains de la même chaîne d'attaque.
• Source

2022 · Portefeuille Slope

• Portefeuille
• Événement du portefeuille Slope dans l'écosystème Solana. Solana a indiqué que des informations sur les clés privées avaient été accidentellement transmises à un service de surveillance d'application ; ce n'est pas une rupture du consensus de Solana.
• Source

2023 · Euler

• Protocole de prêt
• Environ 197 millions de dollars d'actifs d'Euler ont été transférés en raison d'une vulnérabilité du protocole, puis récupérés. La combinaison complexe d'une seule transaction peut amplifier les défauts de logique commerciale.
• Source

2023 · Kit de connexion Ledger

• Outil de connexion de portefeuille
• Le Kit de connexion Ledger a subi une attaque de chaîne d'approvisionnement, un code malveillant a pénétré dans le front-end de l'application. La sécurité des dispositifs matériels ne peut pas remplacer la vérification du contenu des transactions.
• Source

2024 · DMM Bitcoin

• CEX
• Environ 308 millions de dollars ont été volés chez DMM Bitcoin. Le FBI et d'autres agences ont ensuite révélé des attaques d'ingénierie sociale ciblant des personnes et des chaînes de signatures connexes.
• Source

2024 · Radiant Capital

• Protocole de prêt / Signature
• Environ 50 millions de dollars ont été volés chez Radiant Capital, plusieurs dispositifs de développeurs ont été compromis. Les signatures multiples peuvent encore dépendre d'informations de transaction contaminées.
• Source

2025 · Bybit / Safe

• CEX / Front-end de portefeuille
• Environ 1,5 milliard de dollars d'incidents chez Bybit, l'attaque impliquait l'environnement de développement de Safe et le front-end, les signataires ont approuvé des transactions modifiant la logique de contrôle du portefeuille.
• Source 1 · Source 2

2025 · Cetus DEX

• DEX
• Environ 223 millions de dollars d'incidents chez Cetus sur Sui, les chercheurs ont signalé des défauts dans la bibliothèque mathématique. Les environnements non EVM doivent également vérifier le code et l'exposition des actifs.
• Source

2026-07 · Défaut de nombre aléatoire COLDCARD

• Portefeuille matériel / Génération de semences
• Un défaut de firmware a affaibli la génération de semences, permettant aux attaquants de reconstruire les clés privées pertinentes lorsque le dispositif est hors ligne. Les mises à jour ne peuvent pas réparer les semences faibles déjà générées, une migration selon l'annonce est toujours nécessaire.
• Source

2026-10 · Implantation matérielle Ledger

• Portefeuille matériel / Attaque de distribution
• Ledger a confirmé que des dispositifs authentiques avaient été modifiés et circulaient via des canaux de distribution en Asie du Sud-Est, des composants implantés volaient les mots de récupération lors de l'initialisation. Le fabricant a déclaré que ses puces, systèmes d'exploitation et serveurs n'avaient pas été compromis.
• Source

2026 · Incident multi-chaînes de Binance

• CEX / Multi-chaînes
• Binance a d'abord estimé qu'environ 6,3 milliards de dollars d'actifs étaient affectés, d'autres enquêtes sur les points d'intrusion possibles sont toujours en cours. Un système d'exploitation unique peut exposer simultanément des actifs sur plusieurs réseaux.
• Source 1 · Source 2 · Source 3

Il y a ici des CEX, des échanges décentralisés, des protocoles de prêt et des ponts ; des actifs volés et des actifs gelés. Les attaques se produisent à différents niveaux, et les méthodes de réparation sont également différentes. Je m'oppose à réduire tout cela à "les utilisateurs n'ont pas bien gardé leurs clés privées". Comment les utilisateurs peuvent-ils savoir qu'un environnement de développement d'un outil particulier, une bibliothèque partagée, ou une autorisation qu'ils ne comprennent pas, deviendra l'entrée de tous leurs actifs ?

Les réseaux distribués ont déjà accompli beaucoup de choses, mais l'isolement des défaillances du contrôle des actifs est encore loin d'être suffisant. L'exécution en chaîne a fidèlement complété une transaction, mais ne peut pas répondre à la question de savoir pourquoi cette transaction avait le droit de déplacer autant de choses.

Construire une base de sécurité commune avec différentes voies technologiques

La contribution d'Ethereum est considérable. Il a permis à un plus grand nombre de personnes de créer des applications sur la chaîne, formant ainsi une riche boîte à outils et une expérience de développement. Cependant, aujourd'hui, de nombreuses nouvelles chaînes et L2 (réseaux d'extension de deuxième couche) considèrent la compatibilité EVM comme un objectif primordial. L'EVM, qui est la machine virtuelle exécutant les contrats intelligents d'Ethereum, devient une technologie largement reproduite. La compatibilité facilite effectivement la migration des applications ; la documentation de projets comme Unichain souligne clairement la réutilisation des outils d'Ethereum comme valeur d'un environnement d'exécution équivalent.

Je pense que considérer la compatibilité EVM comme la réponse par défaut de l'industrie crée une concentration de risques structurels. Il peut y avoir de nombreux noms de réseaux, et les validateurs peuvent être différents, mais les développeurs peuvent déployer à plusieurs reprises les mêmes contrats, utiliser les mêmes habitudes d'autorisation et dépendre des mêmes bibliothèques logicielles. Les erreurs dans cette dépendance commune ne disparaîtront pas simplement parce qu'elles sont déployées sur une autre chaîne. C'est un jugement sur la voie technique, et cela ne signifie pas que chaque implémentation de l'EVM a nécessairement la même vulnérabilité.

Mes critiques envers Ethereum se situent ici. La capacité d'exécution des contrats génériques est directement liée aux actifs transférables, confiant une grande responsabilité au code des applications et aux interactions avec les portefeuilles. Les contrats peuvent appeler d'autres contrats, les autorisations peuvent exister à long terme, et une confirmation apparemment ordinaire peut changer la manière dont le contrôle des comptes est exercé par la suite. La sécurité dépend de plus en plus de la compréhension correcte de ces combinaisons par chaque équipe de développement, ainsi que de la compréhension correcte par chaque utilisateur de ce qu'il a signé.

L'EIP-7702 illustre clairement ce problème. Un transfert ordinaire est "combien donner à qui cette fois" ; une autorisation déléguée peut être "permettre à ce code d'exécuter des opérations pour mon compte à l'avenir". Cela vise à améliorer l'expérience utilisateur et à segmenter les autorisations, mais la mise en place de la délégation elle-même accorde une large capacité d'exécution, et les autorisations détaillées doivent être correctement mises en œuvre par le code délégué. Le préprint de Minfeng Qi et al. intitulé "EIP-7702 Phishing Attack" a étudié les chemins permettant de contrôler un compte après avoir induit la signature de ce type d'autorisation. La commodité augmente, mais la responsabilité en matière de sécurité augmente également, et il ne suffit pas de laisser cela aux utilisateurs.

L'incident de Binance s'étend sur plusieurs chaînes, et l'enquête n'est pas encore terminée ; il ne faut pas attribuer directement tous les impacts à l'EIP-7702 ou à l'EVM. Les réentrées, les services de signature compromis et les manipulations de front-end ne sont pas la même vulnérabilité. Mais cette distinction ne devrait pas devenir une excuse pour cesser de questionner l'architecture : pourquoi les couches inférieures n'ont-elles pas conservé davantage de contraintes difficiles à contourner pour protéger les erreurs des couches supérieures ?

Le MEV me déplaît également. Il fait référence à l'espace de valeur supplémentaire que les participants peuvent obtenir en incluant, excluant et en ordonnant des transactions. Pour moi, utiliser le pouvoir d'ordonnancement pour frapper les transactions des utilisateurs et aggraver leurs résultats de transaction devrait être considéré comme un bug à corriger, et ne devrait pas être présenté comme une fonctionnalité à conserver simplement parce que certaines personnes peuvent en tirer profit. La documentation d'Ethereum elle-même reconnaît clairement les dommages causés aux utilisateurs par les transactions de frappe, ainsi que les risques que le MEV pose à la stabilité du réseau. Le MEV n'est pas exclusif à Ethereum, il inclut également des activités telles que l'arbitrage et le règlement ; l'industrie a déjà mené des recherches sur l'atténuation. Ma critique est que les incitations à maintenir le réseau ne devraient pas devenir une raison pour sacrifier les conditions de transaction des utilisateurs. Un meilleur système de transaction devrait intégrer les résultats de livraison minimaux et les frais autorisés dans les autorisations, et limiter l'espace dont disposent les ordonneurs pour nuire aux utilisateurs en utilisant des informations non exécutées.

J'ai toujours pensé que l'impact d'Ethereum sur la crypto-monnaie ressemble un peu à celui de PHP sur Internet : il a permis à de nombreuses personnes de créer des choses, mais a également laissé des dettes techniques à long terme à rembourser. PHP devra encore corriger de graves vulnérabilités d'exécution de code à distance en octobre 2026. La maturité et la vulgarisation ne peuvent pas remplacer le renforcement continu. La valeur de l'Internet réside dans le fait que les langages, les frameworks et les services cloud peuvent évoluer séparément. Nous devrions également permettre à différents modèles d'actifs et méthodes d'exécution de continuer à se développer, plutôt que de considérer "la compatibilité avec une seule machine virtuelle" comme un ticket d'entrée dans l'écosystème.

Ainsi, j'appelle les écosystèmes Bitcoin, Solana, Ripple/XRP Ledger, ainsi que les bâtisseurs comme ArcBlock, à participer sérieusement à la construction d'une base de sécurité commune. Participer aux normes et à l'interopérabilité ne nécessite pas de se transformer d'abord en Ethereum. La diversité doit se traduire par des méthodes de contrôle et de vérification des actifs, acceptant l'examen public. Les incidents de Slope et Cetus nous rappellent déjà que le non-EVM n'a également aucune exemption de sécurité.

Ce que j'espère voir se former, ce sont des normes de sécurité adoptables par différents environnements d'exécution : les mêmes exigences de restriction d'actifs et de vérification peuvent être mises en œuvre par l'EVM et d'autres voies, puis publiquement vérifiées pour leurs garanties et coûts respectifs.

Sept mesures de renforcement à entreprendre

1. Imposer des contraintes de contrôle des risques aux droits de disposition des actifs

Les grands portefeuilles devraient pouvoir définir des listes blanches de destinataires, des limites de dépenses cumulées, ainsi qu'un délai d'attente pour les nouveaux destinataires. L'essentiel est que ces règles ne puissent pas être annulées immédiatement par la même clé de transaction quotidienne. La modification des règles nécessite une autorisation indépendante, et il doit y avoir du temps pour la surveillance et l'annulation.

Les comptes intelligents existants ont déjà une base de mise en œuvre, par exemple, Safe Guards peut ajouter des restrictions de transaction en plus de la signature multiple. Nous devons le rendre plus facile à adopter et capable de couvrir tous les chemins de contrôle des actifs. Limiter uniquement les transferts directs, tout en permettant de contourner via des autorisations illimitées, des modules ou des mises à jour, compromettra la protection. La possibilité de mettre à jour les contrats de liste blanche et de modifier les autorisations du destinataire doit également entrer dans le champ de vérification.

Le verrouillage d'activation d'Apple fournit une inspiration dans la vie quotidienne : limiter la réactivation des appareils volés et restreindre l'étalonnage de certaines pièces volées, dans le but de réduire la valeur potentielle d'utilisation après le vol. Les portefeuilles devraient également être conçus dans cette direction. Si un attaquant obtient une clé, la portée des actifs pouvant être liquidés reste limitée, ce qui pourrait réduire le rendement attendu de l'attaque ; les risques de destruction de services doivent encore être traités séparément.

C'est ce que j'appelle la "constitution" de la sécurité des actifs : les droits d'opération peuvent être compromis, mais les droits de modification des limites doivent rester indépendants. Le processus de récupération doit également être contraint pour éviter qu'une mauvaise configuration ne verrouille définitivement les actifs.

2. Faire en sorte que les portefeuilles assument la responsabilité de la sécurité, et pas seulement de remettre des mots de passe

Je suis très mécontent du système de portefeuilles d'aujourd'hui : si un produit demande à une personne ordinaire de noter une série de mots, en lui demandant de ne jamais les divulguer, de ne jamais les perdre et de ne jamais se faire arnaquer, puis de blâmer l'utilisateur pour tous les échecs ultérieurs, je considère que c'est un design irresponsable. L'auto-gérance devrait donner aux gens le contrôle, mais aussi des capacités de protection et de récupération utilisables. Cela ne devrait pas exiger que chaque utilisateur devienne d'abord un expert en sécurité. C'est aussi un obstacle que la crypto-monnaie doit surmonter pour atteindre un plus grand nombre d'utilisateurs ordinaires.

Les incidents récents ont mis ce problème en lumière. Ledger a confirmé en octobre 2026 qu'un attaquant avait modifié un véritable appareil, puis l'avait renvoyé sur le marché via des canaux de distribution en Asie du Sud-Est, implantant des composants qui volaient les mots de récupération lors de l'initialisation. Ledger a défini cela comme une attaque de distribution locale après la sortie de l'appareil, et non comme une compromission de son chip, de son système d'exploitation ou de ses serveurs. L'incident de COLDCARD en juillet impliquait une réduction du firmware pour générer des graines : l'appareil n'a pas besoin d'être contrôlé à distance, l'attaquant peut également reconstruire les clés privées concernées. La mise à jour du firmware corrige le processus de génération futur, mais les graines faibles déjà générées doivent encore être migrées.

Ces deux incidents ne représentent pas la même vulnérabilité, mais montrent tous deux que même si les utilisateurs notent soigneusement les mots et conservent l'appareil hors ligne, cela ne remplace pas la vérification par le fabricant du nombre aléatoire et de la chaîne d'approvisionnement complète. Faire afficher les mots de sauvegarde par l'appareil a une utilité pour la récupération hors ligne, mais cela expose également le secret complet de récupération à un chemin d'affichage et de sauvegarde qui doit être protégé. La sécurité des puces ne peut pas remplacer la vérification de l'ensemble de l'appareil et du processus de livraison.

L'objectif d'amélioration devrait être l'ensemble du cycle de vie du portefeuille : comment les clés sont générées, comment les transactions sont interprétées, comment les autorisations sont séparées, comment récupérer après la perte de l'appareil. L'abstraction des comptes, c'est-à-dire permettre aux comptes de vérifier les autorisations via des règles programmables, ainsi que des sauvegardes de seuil comme SLIP-39, ont déjà des normes et des bases de mise en œuvre, il ne faut pas dire que l'industrie ne fait rien. Mais nous devons faire en sorte que ces capacités deviennent des protections vérifiées et faciles à utiliser, plutôt que de laisser les utilisateurs assembler des solutions complexes par eux-mêmes.

La simple confusion des mots de passe n'est pas suffisante. Des directions plus fiables incluent des sauvegardes cryptées examinées, des récupérations par seuil et des autorisations d'appareils indépendants, et permettre aux utilisateurs de compléter des exercices de récupération avant de déposer des actifs importants. Les fragments de sauvegarde et les signatures multiples sont des couches différentes : les premiers peuvent recomposer le même secret lors de la récupération, tandis que les seconds exigent l'approbation de plusieurs signataires indépendants pour approuver une transaction. Les services de récupération ne doivent pas devenir discrètement une nouvelle clé principale, et ne doivent pas permettre à des mots de passe supplémentaires de devenir un autre piège où la perte entraîne une impossibilité de récupération.

Les portefeuilles personnels et les systèmes de portefeuilles des échanges peuvent partager des normes de sécurité pour la description des transactions, les demandes de signature, les restrictions d'actifs et les processus de récupération, en adoptant différentes limites et stratégies d'approbation. Le PSBT de Bitcoin a déjà fourni un format pour transmettre des transactions à signer entre outils, cette interface commune mérite d'être poursuivie. Ce qui est commun, ce sont les exigences de sécurité vérifiables, chaque chaîne doit encore clarifier ses propres règles d'adaptation. Les portefeuilles doivent clairement présenter ce que cette signature transférera, à qui elle accordera combien de permissions futures, et être refusés par des stratégies indépendantes pour éviter les opérations hors limites ; une page de confirmation plus attrayante n'est pas suffisante.

3. Réaliser une divulgation minimale nécessaire pour être vérifiable

Prouver qu'une condition est remplie ne devrait pas toujours exiger que l'utilisateur divulgue toutes les données sous-jacentes. La divulgation sélective, les preuves à connaissance nulle et l'accès à l'audit accordé à la demande devraient devenir des options normales pour l'infrastructure. Cela est également lié à la sécurité des actifs : l'identité et la relation des actifs divulguées peuvent fournir des indices pour des escroqueries ciblées ; les données non nécessaires pour les affaires devraient être exposées le moins possible.

Le système de certificats vérifiables du W3C a déjà un chemin technique pour la divulgation sélective ; cependant, il reste nécessaire de clarifier comment prouver que les entrées sont réelles, que les certificats sont toujours valides et comment l'état peut être révoqué. L'utilisation de preuves à connaissance nulle (ZK) ne cache pas automatiquement le montant des transactions et les relations, et l'extension des preuves et la protection de la vie privée sont des objectifs différents.

Par exemple, lorsqu'une entreprise a seulement besoin de vérifier l'éligibilité des participants, l'utilisateur peut présenter une conclusion d'éligibilité valide émise par une institution de confiance, sans divulguer l'intégralité des documents financiers. Lorsque la preuve que des valeurs cachées satisfont les conditions est nécessaire, un mécanisme de preuve approprié doit être utilisé. La source fiable des certificats et l'état de révocation doivent encore être vérifiés.

Mon initiative est de clarifier "qui a besoin de vérifier quoi" avant de concevoir les données qui doivent être rendues publiques. Les personnes qui vérifient l'éligibilité peuvent n'avoir besoin que d'une conclusion d'éligibilité ; celles qui ont des responsabilités d'audit spécifiques peuvent obtenir des preuves limitées. Les contraintes vérifiables publiques devraient minimiser l'exposition permanente des informations personnelles pour tous.

IV. Éloigner les services de transaction de la garde centralisée

Le rapprochement des transactions, la recherche de chemins et l'achèvement des livraisons d'actifs devraient être conçus séparément. Un service fournissant un point d'entrée pour les transactions devrait obtenir uniquement les autorisations nécessaires pour compléter la livraison actuelle, permettant aux actifs des utilisateurs de rester sous leur contrôle le reste du temps. Les protocoles basés sur l'intention de transaction ont déjà exploré certaines voies, et l'industrie peut continuer à les compléter.

Les conditions de livraison acceptées par les utilisateurs doivent être claires, y compris ce qui est donné, ce qui est au moins reçu, quand cela expire et les frais autorisés. Si le service de transaction est compromis, l'attaquant peut refuser le service, mais ne peut pas modifier ces conditions à sa guise. Les affaires nécessitant encore une garde centralisée devraient également séparer les réserves et les autorisations opérationnelles, limitant l'exposition des portefeuilles chauds et le réapprovisionnement automatique.

IBIT est un produit négocié en bourse de Bitcoin d'iShares, dont les parts sont échangées sur le marché. Son arrangement fournit un exemple de séparation partielle : les parts et le Bitcoin sous-jacent sont enregistrés séparément, les clés privées liées au solde de la chambre forte sont stockées à froid. Les enregistrements de transactions de parts changent sans exiger que le Bitcoin sous-jacent bouge à chaque fois.

Ce qui peut être inspirant est la séparation des droits de transaction et des droits de disposition des réserves. Son solde de trading a des arrangements différents, et la garde elle-même comporte des risques ; le stockage à froid doit être associé à des instructions et des vérifications de signature indépendantes.

Je compare le point d'entrée des transactions à un routeur, espérant qu'il puisse être remplacé sans transporter l'interrupteur total des actifs de tous les utilisateurs. Le règlement est plus complexe que le transfert de paquets de données, et la livraison et l'autorisation des actifs doivent encore être vérifiées indépendamment. Une fois que le service est devenu non gardé, accorder un droit de retrait illimité ne fera que ramener le risque centralisé.

V. Isoler les pannes avec une architecture en couches, tout en conservant la capacité de remplacement

Nous avons besoin d'interfaces d'identité et d'autorisation, de stratégies d'actifs et de méthodes de vérification des règlements qui peuvent évoluer indépendamment. Différentes chaînes peuvent conserver leurs propres modèles d'exécution, connectés par des interfaces claires. Les interfaces doivent préciser les garanties de sécurité et leurs conditions, et ne peuvent pas simplement dire "appel réussi".

L'expérience d'Internet soutient cette idée. Mark Nottingham discute dans le RFC 9518 "Centralisation, Décentralisation et Normes Internet" des situations où la centralisation peut être utile, tout en analysant le pouvoir et les risques qu'elle engendre. C'est une attitude qui mérite d'être adoptée : faire en sorte que l'architecture réponde à quelles responsabilités peuvent être centralisées, jusqu'à quel point, et comment empêcher cette concentration de pouvoir de s'étendre. Un service peut identifier les anomalies de manière centralisée tout en limitant son accès aux actifs ; les utilisateurs devraient pouvoir changer de service sans perdre leurs stratégies d'actifs et leurs enregistrements de vérification.

La question d'acceptation la plus importante est : après qu'un service commercial a été compromis, quelle couche indépendante peut encore le refuser ? Si toutes les couches partagent une clé de gestion, la soi-disant séparation en couches n'est qu'une séparation sur le diagramme de déploiement.

On peut considérer cet objectif comme cinq responsabilités : le service de transaction soumet une demande, le portefeuille exprime l'intention de l'utilisateur, une stratégie indépendante limite les droits de disposition des actifs, un composant de vérification examine les opérations et les preuves, et la couche de règlement exécute les contraintes et fournit des enregistrements vérifiables. Ils peuvent être réalisés par différentes équipes, et doivent également préciser les dépendances et les conditions de défaillance.

L'architecture cible proposée dans cet article. La couche de règlement doit faire respecter les stratégies d'actifs ; les indications dans le portefeuille ne peuvent pas remplacer cette contrainte. Les signatures quotidiennes, les modifications de règles et la récupération des autorisations doivent être isolées et soumises à des tests de contournement.

VI. Permettre aux utilisateurs de vérifier facilement leurs actifs

Les gens ordinaires ne devraient pas avoir à conserver et exécuter l'intégralité de l'historique de la chaîne pour vérifier leur solde et leurs paiements ; ils ne devraient pas non plus avoir à faire confiance à un seul serveur derrière leur portefeuille. Satoshi a déjà proposé dans la section 8 de son livre blanc le SPV, ou vérification de paiement simplifiée. Le BIP-157 de Bitcoin continue d'explorer comment permettre aux clients de télécharger des filtres, de rechercher des blocs pertinents pour eux ; Ethereum a également un design de client léger. Donc, le problème n'est pas que personne n'y a jamais pensé, mais que nous devons encore intégrer la capacité de vérification avec des conditions de sécurité claires dans les portefeuilles que les utilisateurs utilisent quotidiennement.

Prenons l'exemple d'une chaîne qui prend en charge la preuve de l'état du compte : lors de la vérification du solde, le serveur doit renvoyer à la fois le solde et la preuve. Le portefeuille doit d'abord vérifier un résumé de bloc court selon les règles de cette chaîne, c'est-à-dire l'en-tête de bloc, puis vérifier si ce solde correspond aux données promises par le résumé. Le serveur fournit une réponse, et le portefeuille peut vérifier cette réponse. La vérification SPV de Bitcoin est une preuve que les transactions pertinentes ont été incluses, et ne peut pas être directement copiée pour cette preuve de solde. Le portefeuille doit également afficher clairement où il a synchronisé, quelles informations ont été vérifiées ; en cas de preuve manquante, de données périmées ou de sources contradictoires, il doit alerter ou arrêter les opérations à haut risque qui dépendent de ces informations, sans revenir discrètement à une confiance aveugle.

La vérification légère a encore des conditions. Prouver qu'une transaction a été incluse dans un bloc ne signifie pas que l'on a vérifié que toutes les transactions dans le bloc sont légales. Différentes solutions peuvent dépendre de la bonne foi de la majorité de la puissance de calcul, ou d'un enregistrement initial de confiance, c'est-à-dire un point de contrôle ; il faut également se prémunir contre le fait que le serveur cache des données ou isole l'utilisateur sur un enregistrement de chaîne périmé. Il faut également traiter si la requête elle-même pourrait exposer l'adresse d'intérêt de l'utilisateur. Les nœuds complets et les producteurs de blocs ne sont pas le même rôle ; aujourd'hui, les producteurs de blocs d'Ethereum utilisent des validateurs, et non des mineurs.

Plus important encore, prouver "qu'un transfert a effectivement eu lieu sur la chaîne" ne prouve pas "que c'est bien le transfert que l'utilisateur voulait". Les clients légers ne peuvent pas remplacer les restrictions d'actifs et les vérifications de signature précédentes. Ils permettent aux utilisateurs de moins dépendre d'une réponse non vérifiable, tandis que les stratégies d'actifs empêchent même une signature valide de disposer des actifs de manière illimitée. Construire ces deux couches ensemble, c'est décentraliser la capacité de vérification entre les participants.

VII. Établir une base publique pour l'identification des anomalies et la vérification de la sécurité

Avant une transaction, quelqu'un devrait vérifier si cette opération respecte la stratégie d'actifs et si elle modifie soudainement le comportement historique. Des anomalies évidentes peuvent déclencher une pause ou une révision accrue ; l'élargissement des autorisations nécessite un chemin indépendant. L'IA peut participer au jugement, mais ne devrait pas obtenir un laissez-passer pour contourner les règles strictes.

En même temps, nous devons maintenir collectivement des cas d'attaque, des tests d'autorisation et des outils de vérification réutilisables. Partager des normes, tout en conservant des mises en œuvre indépendantes et des vérifications indépendantes, est la seule façon de réduire les pannes communes. Les fondations et les échanges ont déjà investi dans la sécurité, comme l'Initiative de Sécurité de Trillion Dollar de la Fondation Ethereum. La prochaine question à se poser est de savoir si ces investissements peuvent se transformer en bases publiques que d'autres équipes peuvent également adopter et vérifier.

Ces sept tâches ne peuvent garantir une sécurité absolue. Ce qu'elles doivent livrer, ce sont des limites vérifiables : dans quelles conditions d'autorisation compromise, combien d'actifs sont exposés au maximum, combien de temps les anomalies peuvent être détectées, et qui dépend encore de la récupération.

L'ingénierie logicielle habilitée par l'IA : notre nouvel espoir

À ce stade, certains pourraient dire : la direction semble juste, mais l'industrie a déjà parcouru tant de chemin, combien de personnes et de temps cela nécessitera-t-il pour reconstruire ? N'est-ce pas encore du idéalisme ?

Si nous continuons à estimer selon les anciennes méthodes de production de logiciels, cette question est très réaliste. Mais d'ici 2026, je pense que les agents de codage et l'ingénierie logicielle habilitée par l'IA auront changé notre capacité de construction. Les agents de codage dont je parle sont des assistants de programmation AI capables de lire et d'écrire du code, d'appeler des outils, d'exécuter des tests et de continuer à travailler en fonction des retours dans un environnement de développement. Les constructeurs définissent des objectifs, tracent des limites de sécurité, et utilisent ces outils pour réaliser et vérifier les systèmes, tout en étant responsables des résultats.

Ce qui nécessitait auparavant de grandes équipes pour réaliser, adapter et maintenir de manière répétée, peut maintenant être tenté par de petites équipes grâce à cette nouvelle méthode d'ingénierie. Une équipe garde une couche, livre des composants autour d'interfaces claires, et d'autres équipes vérifient et combinent. Organiser le jugement architectural humain, la capacité de mise en œuvre des agents de codage et la vérification de sécurité indépendante est, selon moi, une voie de construction qui mérite d'être réévaluée sérieusement.

La recherche d'Anthropic et de PNNL donne un exemple concret : dans un environnement simulé d'infrastructure critique limité, les chercheurs rapportent que la reconstruction d'attaques a été réduite de plusieurs semaines à environ trois heures. Cela ne prouve pas qu'une petite équipe puisse réécrire en toute sécurité l'ensemble de l'industrie, mais cela indique que les travaux de vérification et de défense coûteux du passé peuvent apparaître avec de nouvelles conditions de coût.

Une façon d'organiser qui peut être lancée maintenant est de construire ensemble une usine d'IA en public. Des experts de l'industrie, des universitaires et des praticiens écrivent publiquement des exigences et des spécifications d'acceptation, expliquant ce qu'il faut protéger, quelles opérations sont autorisées, quelles permissions doivent rester en place même après une perte, puis ces exigences sont transformées en tests d'acceptation. Des agents de codage regroupés assument principalement le travail de codage, de test et de débogage ; différentes équipes vérifient la conception et les résultats, les humains portent la responsabilité du jugement et de l'acceptation.

Les participants peuvent contribuer des idées, des machines, de la puissance de calcul, ainsi que des quotas d'appel de modèles, c'est-à-dire des jetons d'IA. Les entreprises d'IA et de cloud computing peuvent également soutenir cette construction publique par le biais de quotas de modèles, de ressources de calcul et d'outils. Les spécifications, le code prototype, le flux de travail des agents, l'environnement de test et les résultats de validation peuvent tous devenir des bases maintenues en commun, permettant à la prochaine équipe de continuer directement. L'objectif est de construire des capacités de développement en tant qu'infrastructure publique réutilisable, réduisant la dépendance à une personne ou à une équipe spécifique.

Les attaquants utilisent également l'IA, nous n'avons plus de raison de laisser la défense dans les méthodes de production du passé. Mais la génération de code est rapide, ce n'est qu'un point de départ. Écrire clairement les contraintes, permettre aux tests de s'exécuter de manière répétée, et permettre à un composant d'être vérifié et remplacé, c'est ce qui transformera la capacité de l'IA en amélioration des infrastructures.

Des bâtisseurs indépendants travaillent ensemble avec des agents de codage et des outils d'IA. L'atelier spatial est une métaphore de la construction publique.

Je souhaite particulièrement adresser cet appel à ceux qui aiment encore construire. Ici, le hacker est celui qui veut comprendre comment fonctionne le système, qui est prêt à partager ses découvertes et qui souhaite que les autres vérifient son travail. Cet esprit a autrefois propulsé Internet, et aujourd'hui, il peut également propulser la Crypto.

Je ne crois pas que cette industrie manque de personnes intelligentes, ni que les secteurs de la Crypto et de l'IA ne puissent trouver les ressources pour soutenir ce travail. Ce qui est plus difficile, c'est d'organiser les talents, les fonds et la responsabilité continue. Les fondations et les entreprises capables devraient être prêtes à supporter les coûts à long terme de ce travail de base qui ne génère pas directement de revenus, mais qui profite à tous.

J'espère que nous pourrons tous ensemble créer une infrastructure cryptographique partagée au niveau mondial. Différentes réseaux et équipes pourront collaborer sous des contraintes de sécurité communes, chacun réalisant et vérifiant mutuellement, permettant aux utilisateurs de choisir et de migrer. Cela peut commencer par un composant, mais la direction doit être suffisamment grande pour accueillir la construction collective de toute l'industrie. Tous les participants, y compris ArcBlock, devraient apporter des contributions vérifiables.

Nous devrions construire ensemble une infrastructure : même si un endroit est déjà compromis, les actifs ont toujours des frontières, d'autres systèmes peuvent encore refuser les erreurs, et les utilisateurs ont toujours des voies de récupération et de sortie. Pour emprunter le nom de "Star Wars", c'est notre A New Hope. L'espoir vient des bâtisseurs ordinaires prêts à agir, ainsi que des agents de codage et de nouvelles méthodes d'ingénierie qui leur permettent d'assumer davantage de travaux de construction.

Agissons maintenant

J'invite les bâtisseurs de projets tels qu'Ethereum, Solana, Bitcoin, XRP Ledger, ainsi que les échanges comme Binance, Coinbase, Kraken, et aussi les équipes de portefeuilles, de protocoles, de recherche en sécurité, d'IA et de cloud computing : commençons par un pilote clairement défini, pour créer ensemble des améliorations que d'autres équipes peuvent également adopter et vérifier.

Les noms mentionnés ne sont que des exemples, sans ordre particulier. Quelle que soit la taille ou la technologie adoptée, toutes les participations sont les bienvenues. Cette invitation inclut également les bâtisseurs des voies technologiques critiquées dans cet article ; améliorer la sécurité des actifs mérite que nous franchissions les frontières de nos propres écosystèmes.

Je suis moi-même prêt à participer, en contribuant notre infrastructure existante, notre ingénierie logicielle et nos pratiques de collaboration en IA. Nous ne sommes qu'une petite équipe dans l'industrie, et nos capacités sont limitées, mais nous espérons commencer par un prototype et un ensemble de tests réutilisables.

Les personnes ayant une expérience opérationnelle peuvent fournir des scénarios d'attaque anonymisés, les équipes de portefeuilles et de protocoles peuvent mettre en œuvre des protections, et des chercheurs indépendants peuvent essayer de les contourner. Chaque équipe prend en charge une partie de ce qu'elle peut, vérifiant ensemble les solutions et décidant des prochaines étapes.

Je suis prêt à participer à la rédaction des exigences de limitation et de récupération des actifs de cet article en une première spécification publique, et je suis également prêt à contribuer aux pratiques techniques et d'ingénierie pertinentes, et à établir une usine d'IA publique pour ce pilote avec d'autres participants. Commençons par une question très spécifique : les clés de transaction quotidiennes ont déjà été compromises, comment faire en sorte que les attaquants ne puissent toujours pas vider le portefeuille d'un seul coup ? Écrivons les limites de perte autorisées, les permissions de modification des règles et les conditions de récupération sous forme de tests d'acceptation, puis faisons réaliser un prototype par des agents de développement, permettant à un autre groupe d'agents et à des chercheurs indépendants de chercher des chemins de contournement. Les serveurs de données renvoyant des soldes erronés, la récupération après perte d'appareil peuvent également être progressivement ajoutées aux tests. Ce que le prototype a réalisé, où il a échoué, et quelles dépendances subsistent, doivent être publiquement expliqués, puis les prochaines étapes doivent être décidées sur la base des preuves.

Les personnes prêtes à participer sont invitées à partager ou à citer publiquement cette initiative sur X, en mentionnant @mave99a, en parlant des problèmes qu'elles souhaitent résoudre, des cas d'attaque anonymisés, ou des ressources qu'elles peuvent contribuer. J'espère que la discussion se déroulera publiquement, permettant à plus de bâtisseurs de le voir et de continuer à participer.

La Crypto ne peut plus continuer ainsi. Pour ceux qui sont prêts à agir ensemble, agissons maintenant, en commençant par une amélioration réalisable et vérifiable.

1. Binance, annonce préliminaire du post officiel et mise à jour de l'enquête officielle, 2026-10-30 ; analyse multi-chaînes de TRM. Cet article est vérifié jusqu'au 2026-10-30 ; l'état de l'enquête et de la récupération peut changer. \↩\
2. Satoshi Nakamoto, Bitcoin : un système de paiement électronique pair-à-pair, 2008. \↩\
3. Uniswap, équivalence EVM d'Unichain. Le risque de dépendance commune est un jugement de l'auteur de cet article, et non la conclusion de ce document. \↩\
4. Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702 : définir le code pour les EOAs, créé le 2024-05-07. \↩\
5. Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, attaque de phishing EIP-7702, 2025-12-13, préimpression arXiv v1 ; ce n'est pas une évaluation de l'incident Binance. \↩\
6. Ethereum, valeur maximale extractible (MEV), mécanismes de tri, différents types et impacts négatifs ; "devrait être considéré comme un correctif de bug" est l'argument de l'auteur concernant les comportements nuisibles aux utilisateurs. \↩\
7. Archives des nouvelles officielles de PHP 2026 ; mise à jour des vulnérabilités connues exploitées par CISA 2026-10-26, CVE-2026-109618, CVE-2026-109619. \↩\
8. Safe, explication des risques de fonctionnalités et de permissions des Gardes et Modules. \↩\
9. Apple, Apple va élargir les options de réparation avec le soutien de pièces d'origine utilisées, 2024-04-11 ; explication du soutien actuel pour le verrouillage des pièces. \↩\
10. Ledger, réponse de Ledger à l'attaque par implantation matérielle, 2026-10, explication du fabricant sur l'attaque dans la chaîne de distribution ; Joe Grand, recherche inverse sur l'implantation matérielle. Ne pas écrire d'estimations de pertes en ligne non vérifiées par le fabricant comme des conclusions. \↩\
11. Coinkite, statut actuel de sécurité de COLDCARD, consultation du 2026-10-30, enregistrement des incidents et des réparations de juillet 2026 en cours de mise à jour ; la mise à niveau et la migration des graines sont deux opérations différentes. \↩\
12. ERC-4337 : abstraction de compte utilisant Alt Mempool ; Trezor, FAQ SLIP39, récupération par seuil, compatibilité et risques de mots de passe supplémentaires. Les mécanismes existants sont une base de construction, mais ne signifient pas que chaque déploiement est fiable. \↩\
13. BIP-174 : format de transaction Bitcoin partiellement signé, format d'échange de transactions en attente de signature, pas une norme de stratégie d'actifs inter-chaînes. \↩\
14. W3C, aperçu des identifiants vérifiables v1.0, note de groupe du 2026-07-30 ; explication de la confidentialité d'Ethereum. L'état standard des technologies décrites dans l'aperçu est indépendant. \↩\
15. Documentation du protocole CoW, intention de transaction et mécanisme de solveur ; cet article ne fournit pas une garantie de sécurité complète pour des déploiements spécifiques. \↩\
16. iShares, rapport annuel IBIT 2025, pages 8-10 du PDF sur les arrangements de garde et page 45 sur les risques. \↩\
17. Mark Nottingham, RFC 9518 : centralisation, décentralisation et normes Internet, 2023-12, soumission indépendante, RFC explicatif, pas une norme de trajectoire. \↩\
18. Chapitre 8 du livre blanc Bitcoin Vérification simplifiée des paiements ; BIP-157 : filtrage de blocs côté client ; Ethereum, clients légers. La portée de validation et les conditions de confiance des différents clients légers varient. \↩\
19. Fondation Ethereum, annonce de l'initiative de sécurité d'un trillion de dollars, 2025-05-14. \↩\
20. Anthropic, l'IA pour défendre les infrastructures critiques, 2026-01-08, recherche en environnement contrôlé en collaboration avec PNNL. \↩\
21. Anthropic, cartographie des menaces cybernétiques activées par l'IA, étude des échantillons d'abus réels. \↩\
22. Lucasfilm, Star Wars : Un nouvel espoir (Épisode IV), 1977 ; cet article emprunte le titre de l'œuvre et l'image de l'auto-sauvetage collectif. \↩\