727 FinanceUn incident ne fait pas que emporter des actifs, il emporte aussi la confiance. La crypto ne peut pas continuer ainsi ; nous devons nous sauver nous-mêmes.
Auteur : Robert Mao, fondateur et CEO d'ArcBlock
Cet article est autorisé à être librement reproduit et transmis par quiconque, dans l'espoir que davantage de personnes verront cet appel à l'industrie pour qu'elle se sauve elle-même.
La crypto ne peut pas continuer ainsi. Encore et encore, des vols massifs emportent non seulement des actifs, mais aussi la confiance des participants dans l'ensemble de l'industrie. Nous devons nous sauver nous-mêmes.
Le 29 octobre 2026, un incident de sécurité majeur s'est produit chez Binance. Son annonce préliminaire estimait qu'environ 6,3 milliards de dollars d'actifs étaient affectés, et qu'environ 3 milliards de dollars des actifs affectés avaient été gelés ; l'enquête pointait initialement vers l'ordinateur portable d'un ingénieur DevOps, et d'autres points d'intrusion possibles ont ensuite été découverts. Binance a également déclaré qu'aucune preuve de fuite de clé privée de portefeuille n'avait été trouvée. Le montant affecté n'est pas la perte nette finale, et la chaîne d'attaque complète reste sous enquête. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Cette initiative s'adresse aux bâtisseurs de projets blockchain tels qu'Ethereum et Solana, ainsi qu'à Binance, Coinbase, Kraken, et à toutes les plateformes d'échange, portefeuilles, protocoles et bâtisseurs de sécurité disposés à participer : reconstruisons ensemble les fondations de la protection des actifs. Je suis prêt à participer, et j'espère que davantage de personnes agiront ensemble.
C'est déjà suffisamment lourd. Mais ce qui m'inquiète davantage, c'est la confiance dans la crypto que cet incident va détruire, et le nombre d'attaquants qu'il va conduire à considérer cette industrie comme une cible qui vaut encore la peine de continuer à attaquer. Même si quelqu'un finit par supporter les pertes, une indemnisation ne peut pas réparer automatiquement la confiance des utilisateurs, ni empêcher le même type de destruction de se reproduire.
Binance n'est que le point d'entrée qui nous force aujourd'hui à affronter le problème. En détournant le regard, les plateformes d'échange, les ponts, les protocoles on-chain et les portefeuilles ont depuis longtemps laissé une longue traînée de blessures. De nouveaux réseaux et produits ne cessent d'apparaître, mais les anciens modes de défaillance se répètent encore et encore. Nous ne pouvons pas publier une annonce, attendre un moment, puis traiter le prochain incident comme une routine.
Nous devons aussi reconnaître que les arnaques et la pratique consistant à simplement créer des concepts sans assumer la responsabilité de construire ont nui à cette industrie pendant trop longtemps. Les équipes qui construisent sérieusement la technologie et l'infrastructure doivent aussi supporter ensemble les conséquences de la perte de confiance. Au moment où les gens verront toute la crypto comme une arnaque, la technologie et l'exploration qui méritent vraiment d'être préservées risquent aussi d'être abandonnées avec elle.
En tant que fondateur d'ArcBlock et praticien de la crypto et de la blockchain, je ne suis pas disposé à accepter un tel résultat. Je crois que cette industrie a une valeur qui mérite d'être protégée, et je crois aussi que nous devons assumer la responsabilité de nos propres fondations de sécurité. Si nous continuons à attendre passivement le prochain incident, des saignements répétés pourraient finir par détruire tout ce que nous avons construit ensemble.Je souhaite donc lancer cette initiative : les constructeurs d'exchanges, de portefeuilles et de blockchains devraient reconstruire ensemble les fondations du contrôle des actifs et de la vérification de sécurité, afin que l'ampleur des dommages causés par une seule intrusion soit limitée. La chronologie ci-dessous explique pourquoi le changement est nécessaire ; la proposition technique qui suit est le travail que je crois que nous pouvons commencer à accomplir.
En 2008, Satoshi Nakamoto a proposé un système de paiement électronique pair à pair, tentant de rendre les paiements moins dépendants d'intermédiaires de confiance. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Pourtant, les incidents majeurs survenus depuis lors ont exposé à maintes reprises le problème de la reconcentration des fonds, des autorisations et des dépendances logicielles.
Voici une liste chronologique d'incidents représentatifs dans des domaines tels que les exchanges centralisés (CEX), les exchanges décentralisés (DEX), les bridges et les portefeuilles. Il ne s'agit ni d'une base de données exhaustive des incidents, ni d'une statistique des pertes année par année. Lorsque des montants sont indiqués, ils se réfèrent à l'impact brut approximatif au moment de l'incident ; le vol, le gel et la récupération ultérieure sont décrits séparément et ne peuvent être additionnés comme des pertes permanentes.
2008 · Livre blanc du Bitcoin
Point de départ
Le livre blanc du Bitcoin proposait des paiements pair à pair sans institutions financières comme intermédiaires.
Source
2011–2014 · Vol de longue durée de Mt. Gox
CEX
Mt. Gox a subi un vol de longue durée et a finalement cessé ses activités. Un acte d'accusation ultérieur du département de la Justice des États-Unis a allégué qu'environ 647 000 BTC avaient été volés entre 2011 et 2014. Il ne s'agissait pas d'une attaque d'une seule journée en 2014.
Source
2012 · Bitcoinica et Bitfloor
CEX / infrastructure de garde
L'environnement d'hébergement Linode de Bitcoinica a été compromis ; la même année, la sauvegarde non chiffrée du portefeuille de Bitfloor est devenue un point d'entrée pour l'attaque. Les serveurs et les sauvegardes derrière la plateforme font également partie de la frontière de sécurité des actifs.
Source
2015 · Portefeuille chaud de Bitstamp
CEX
Le portefeuille chaud de Bitstamp a été compromis, et l'environnement d'exploitation a ensuite été reconstruit. La distinction officielle entre l'ampleur de l'incident et les réserves hors ligne a montré que l'isolation peut limiter l'ampleur de l'exposition.
Source
2016 · Bitfinex
CEX
Environ 120 000 BTC ont été volés à Bitfinex. Les dispositifs multisignatures nécessitent toujours une autorisation et une vérification indépendantes de bout en bout.
Source 1 · Source 2
2016 · The DAO
Protocole on-chain
Le contrat de The DAO a subi une attaque par réentrance, et environ 3,6 millions d'ETH ont été transférés dans un sous-DAO, déclenchant ensuite un fork d'Ethereum. Un chemin d'exécution légitime peut 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, et environ 513 000 ETH ont été gelés. Même s'ils ne sont pas transférés, les fonds peuvent devenir inutilisables en raison de dépendances de code partagées.
Source
2018 · Coincheck
CEXLe hot wallet NEM de Coincheck a été victime d'un vol. La frontière entre les réserves hors ligne, les autorisations des hot wallets et les besoins opérationnels est une fois de plus 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 d'actifs à grande échelle doivent être contraintes avant la signature.
Source
2020 · KuCoin
CEX
Incident du hot wallet de KuCoin, avec une grande quantité d'actifs ensuite récupérés grâce à une collaboration multipartite. Le montant brut volé 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 et ensuite restitués par étapes. L'autorisation inter-chaînes et le contrôle des actifs ne peuvent pas tenir uniquement via les chemins opérationnels normaux.
Source
2022 · Pont Ronin
Pont
Les autorisations des validateurs de Ronin ont été compromises, et 173 600 ETH et 25,5 millions d'USDC ont été transférés hors du système. Les clés de plusieurs validateurs peuvent également tomber dans la même chaîne d'attaque.
Source
2022 · Portefeuille Slope
Portefeuille
Incident du portefeuille Slope dans l'écosystème Solana. Solana a officiellement déclaré que des informations de clé privée avaient été transmises par accident à un service de surveillance d'applications ; il ne s'agissait pas d'une compromission du consensus de Solana.
Source
2023 · Euler
Protocole de prêt
Environ 197 millions de dollars d'actifs ont été transférés hors d'Euler en raison d'une vulnérabilité du protocole et ensuite récupérés. Des combinaisons complexes dans une seule transaction peuvent amplifier les failles de logique métier.
Source
2023 · Ledger Connect Kit
Outil de connexion de portefeuille
Ledger Connect Kit a subi une attaque de la chaîne d'approvisionnement, et du code malveillant a pénétré le frontend de l'application. La sécurité du dispositif matériel 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 à DMM Bitcoin. Le FBI et d'autres agences ont ensuite divulgué des attaques d'ingénierie sociale ciblant le personnel concerné et la chaîne de signature.
Source
2024 · Radiant Capital
Protocole de prêt / signature
Environ 50 millions de dollars ont été volés à Radiant Capital, et plusieurs appareils de développeurs ont été compromis. La signature multipartite peut encore dépendre collectivement d'informations de transaction contaminées.
Source
2025 · Bybit / Safe
CEX / frontend de portefeuille
L'incident Bybit d'environ 1,5 milliard de dollars impliquait l'environnement développeur et le frontend de Safe, et les signataires ont approuvé une transaction qui modifiait la logique de contrôle du portefeuille.
Source 1 · Source 2
2025 · Cetus DEX
DEXL'incident d'environ 223 millions de dollars chez Cetus sur Sui, avec des chercheurs pointant une faille dans une bibliothèque mathématique. Les environnements non-EVM doivent également examiner leur code et l'étendue de l'exposition des actifs.
Source
2026-07 · Faille du générateur de nombres aléatoires de COLDCARD
Portefeuille matériel / génération de seedUne faille de firmware a affaibli la génération de seeds, permettant aux attaquants de reconstruire les clés privées concernées pendant que l'appareil était hors ligne. La mise à niveau ne peut pas corriger les seeds faibles déjà générées ; une migration conformément à l'avis reste nécessaire.
Source
2026-10 · Implant matériel Ledger
Portefeuille matériel / attaque par distribution
Ledger a confirmé que des appareils authentiques ont été modifiés et diffusés via les canaux de distribution en Asie du Sud-Est, avec des composants implantés volant les phrases de récupération lors de l'initialisation. Le fournisseur affirme que ses puces, son système d'exploitation et ses serveurs n'ont pas été compromis.
Source
2026 · Incident multi-chaînes Binance
CEX / multi-chaînes
Binance a initialement estimé qu'environ 6,3 milliards de dollars d'actifs étaient concernés, et les enquêtes sur d'autres points d'intrusion possibles sont toujours en cours. Un seul système d'exploitation peut exposer des actifs sur plusieurs réseaux simultanément.
Source 1 · Source 2 · Source 3
Ici, il y a des CEX, mais aussi des échanges décentralisés, des protocoles de prêt et des bridges ; il y a des actifs volés et des actifs gelés. Les attaques se produisent à différents niveaux, et les méthodes de remédiation diffèrent. Je m'oppose à réduire tout cela à la seule phrase « les utilisateurs n'ont pas su protéger leurs clés privées ». Comment les utilisateurs peuvent-ils savoir que l'environnement de développement d'un certain outil, une certaine bibliothèque partagée ou une autorisation incompréhensible deviendra le point d'entrée vers tous leurs actifs ?
Les réseaux distribués ont déjà fait beaucoup, mais l'isolation des fautes pour le contrôle des actifs est loin d'être suffisante. L'exécution on-chain accomplit fidèlement une transaction, mais elle ne peut pas répondre à notre place à la question de savoir pourquoi cette transaction a le droit de déplacer autant.
La contribution d'Ethereum est significative. Il a permis à davantage de personnes d'écrire des applications on-chain et a favorisé un ensemble riche d'outils et d'expérience de développement. Mais aujourd'hui, de nombreuses nouvelles chaînes et L2 (réseaux de mise à l'échelle de couche 2) considèrent la compatibilité EVM comme leur objectif principal. L'EVM, la machine virtuelle qui exécute les contrats intelligents d'Ethereum, devient une prémisse technique largement répliquée. La compatibilité facilite certes la migration des applications ; la documentation de projets tels qu'Unichain cite explicitement la réutilisation de l'outillage Ethereum comme la valeur d'un environnement d'exécution équivalent. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Je crois que traiter la compatibilité EVM comme la réponse par défaut de l'industrie crée une concentration structurelle des risques. Il peut y avoir de nombreux noms de réseaux, et les validateurs peuvent différer, 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 les dépendances partagées ne disparaissent pas simplement parce que le déploiement a lieu sur une autre chaîne. Il s'agit d'un jugement sur la trajectoire technique, et non de l'affirmation que chaque implémentation EVM présente nécessairement la même vulnérabilité.C'est aussi là que réside ma critique d'Ethereum. La capacité d'exécution de contrats à usage général se connecte directement à des actifs transférables, ce qui impose une responsabilité énorme au code applicatif et aux interactions de portefeuille. Les contrats peuvent appeler des contrats, les autorisations peuvent persister longtemps, et une confirmation apparemment ordinaire peut modifier le mode de contrôle ultérieur d'un compte. La sécurité dépend de plus en plus de la compréhension correcte de ces combinaisons par chaque équipe de développement, et de la compréhension correcte par chaque utilisateur de ce qu'il a signé.
L'EIP-7702 rend ce problème très clair. Un transfert ordinaire, c'est « combien à qui cette fois-ci » ; une autorisation de délégation peut signifier « à partir de maintenant, laisse ce morceau de code exécuter des opérations au nom de mon compte ». Elle vise à améliorer l'expérience utilisateur et à affiner les permissions, mais la mise en place d'une délégation accorde en soi une large capacité d'exécution, et les permissions granulaires doivent encore être correctement implémentées par le code délégué. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) La prépublication « EIP-7702 Phishing Attack » de Minfeng Qi et al. étudie la voie du contrôle persistant d'un compte après avoir incité à la signature de telles autorisations. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) À mesure que la commodité augmente, la responsabilité en matière de sécurité augmente aussi ; la première ne peut pas être simplement transférée aux utilisateurs.
Cet incident Binance s'étend sur plusieurs chaînes, et l'enquête n'est pas encore terminée, de sorte que l'impact global ne peut pas être directement attribué à l'EIP-7702 ou à l'EVM. La réentrance, la compromission des services de signature et la falsification du front-end ne sont pas non plus la même vulnérabilité. Mais de telles distinctions ne doivent pas devenir une excuse pour cesser de questionner l'architecture : pourquoi la couche sous-jacente ne conserve-t-elle pas davantage de contraintes difficiles à contourner, au nom des erreurs des couches supérieures ?
Le MEV me mécontente aussi. Il désigne l'espace dans lequel les participants obtiennent une valeur supplémentaire par l'inclusion, l'exclusion et l'ordonnancement des transactions. Pour moi, utiliser le pouvoir d'ordonnancement pour prendre en sandwich les transactions des utilisateurs et aggraver leurs résultats d'exécution devrait être traité comme un bug à corriger, et non empaqueté comme une fonctionnalité digne d'être préservée simplement parce que certains peuvent en profiter. La documentation d'Ethereum elle-même reconnaît explicitement le préjudice du sandwich de transactions pour les utilisateurs et le risque du MEV pour la stabilité du réseau. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) Le MEV n'est pas propre à Ethereum et englobe aussi différentes activités telles que l'arbitrage et la liquidation ; l'industrie dispose déjà de recherches sur l'atténuation. Ma critique est que l'incitation à maintenir le réseau ne peut pas devenir une raison de sacrifier les conditions de transaction des utilisateurs. Un meilleur système de transaction devrait inscrire le résultat de livraison minimal et les frais autorisés dans l'autorisation, et limiter l'espace permettant aux ordonnanceurs d'utiliser les informations non remplies pour nuire aux utilisateurs.J'ai toujours pensé que l'impact d'Ethereum sur le Crypto ressemble un peu à celui de PHP sur l'Internet : il a permis à beaucoup de gens de construire des choses, et il a aussi laissé une dette d'ingénierie qui prendra longtemps à rembourser. PHP a encore dû corriger une grave vulnérabilité d'exécution de code à distance en octobre 2026. La maturité et la popularité ne peuvent pas remplacer le durcissement continu. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) Ce qui a de la valeur dans l'Internet, c'est 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 la même machine virtuelle » comme le ticket d'entrée dans l'écosystème.
Par conséquent, j'appelle les écosystèmes Bitcoin, Solana et Ripple/XRP Ledger, ainsi que les bâtisseurs, y compris ArcBlock, à participer sérieusement à la construction d'une base de sécurité commune. Participer aux normes et à l'interopérabilité n'exige pas de se refaire d'abord en Ethereum. La diversité doit être mise en œuvre dans le contrôle des actifs et les méthodes de vérification, et être ouverte à l'examen public. Les incidents Slope et Cetus nous ont déjà rappelé que le non-EVM ne bénéficie pas non plus d'une exemption de sécurité.
Ce que j'espère voir prendre forme, c'est une spécification de sécurité que différents environnements d'exécution peuvent tous adopter : les mêmes limites d'actifs et exigences de vérification peuvent être mises en œuvre séparément par l'EVM et d'autres voies, et les garanties et coûts de chacune peuvent ensuite être examinés publiquement.
1. Que les contrôles de risque sous-jacents contraignent le pouvoir de disposition des actifs
Les grands portefeuilles devraient pouvoir définir des listes blanches de destinataires, des plafonds de dépenses cumulés et des périodes d'attente pour les nouveaux destinataires. L'essentiel est que ces règles ne puissent pas être immédiatement annulées par la même clé de transaction quotidienne. La modification des règles exige une autorisation indépendante et doit laisser le temps à la surveillance et à la révocation.Les comptes intelligents existants disposent déjà d’une base de mise en œuvre ; par exemple, les Safe Guards peuvent ajouter des restrictions de transaction au-delà du multisig. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Nous devons en faire une capacité fondamentale plus facile à adopter, couvrant tous les chemins de contrôle des actifs. Si seuls les transferts directs sont restreints tandis que les contournements via des approbations illimitées, des modules ou des mises à niveau sont autorisés, la protection échouera. La possibilité de mettre à niveau le contrat de liste blanche et l’évolution des autorisations du destinataire doivent également entrer dans le périmètre de vérification. L’Activation Lock d’Apple offre une source d’inspiration du quotidien : il restreint la réactivation des appareils volés et limite le calibrage de certaines pièces volées, dans le but de réduire la valeur exploitable après un vol. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Les portefeuilles méritent aussi d’être conçus dans cette direction. Si un attaquant obtient une clé, l’éventail des actifs qu’il peut convertir en liquidités reste limité, et le rendement attendu d’une attaque peut diminuer ; les risques tels que la perturbation des services doivent encore être traités séparément.
C’est ce que j’appelle la « constitution » de la sécurité des actifs : l’autorité opérationnelle peut être compromise, mais l’autorité de modification des limites doit rester indépendante. Les processus de récupération doivent également être encadrés, afin d’éviter qu’une seule erreur de configuration ne verrouille définitivement les actifs.
II. Faire porter la responsabilité de la sécurité aux portefeuilles, plutôt que de simplement remettre des phrases mnémoniques
Je ressens une forte insatisfaction à l’égard des systèmes de portefeuille actuels : si un produit demande à une personne ordinaire de recopier une série de mots, exige qu’elle ne les divulgue jamais, ne les perde jamais et ne se les fasse jamais soutirer par ruse, puis attribue toutes les défaillances ultérieures à la responsabilité de l’utilisateur, je considère cela comme une conception irresponsable. L’auto-conservation devrait donner aux gens le contrôle, et elle devrait aussi leur donner des capacités de protection et de récupération utilisables. Elle ne devrait pas exiger que chaque utilisateur devienne d’abord un expert en sécurité. C’est aussi un seuil que le Crypto doit franchir pour atteindre davantage d’utilisateurs ordinaires.Des incidents récents ont mis ce problème directement sur la table. En octobre 2026, Ledger a confirmé que des attaquants avaient modifié des appareils authentiques avant de les remettre sur le marché via les canaux de distribution en Asie du Sud-Est, des composants implantés dérobant les phrases de récupération lors de l'initialisation. Ledger a qualifié cela d'attaque de distribution localisée après la sortie de l'usine de l'appareil, et non de compromission de sa puce, de son système d'exploitation ou de ses serveurs. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) L'incident de juillet de COLDCARD impliquait un affaiblissement du micrologiciel lors de la génération de la graine : l'appareil n'avait pas besoin d'être contrôlé à distance pour qu'un attaquant reconstruise les clés privées concernées. La mise à jour du micrologiciel corrige le processus de génération pour l'avenir, mais les graines faibles déjà générées doivent encore être migrées. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Ces deux incidents ne relèvent pas du même type de vulnérabilité, mais ensemble ils montrent que : même si les utilisateurs copient soigneusement les mots et gardent l'appareil hors ligne, ils ne peuvent pas vérifier l'aléa et l'intégrité de la chaîne d'approvisionnement à la place du fabricant. Le fait que l'appareil affiche les mots de sauvegarde a pour but la récupération hors ligne, mais cela fait aussi passer le secret de récupération complet par un chemin d'affichage et de sauvegarde qui doit être protégé. La sécurité de la puce ne peut pas remplacer la vérification de l'ensemble de l'appareil et du processus de livraison.
L'objectif de l'amélioration devrait être le cycle de vie complet du portefeuille : comment les clés sont générées, comment les transactions sont expliquées, comment les permissions sont séparées et comment la récupération fonctionne après la perte d'un appareil. L'abstraction de compte, c'est-à-dire permettre aux comptes de vérifier l'autorisation via des règles programmables, et les sauvegardes à seuil telles que SLIP-39, disposent déjà de normes et de bases de mise en œuvre, on ne peut donc pas dire que personne dans l'industrie n'y travaille. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Mais nous devons faire de ces capacités des protections testées et faciles à utiliser, plutôt que de laisser les utilisateurs assembler eux-mêmes des schémas complexes.
Une simple obfuscation des mots mnémoniques ne suffit pas. Les directions plus fiables incluent des sauvegardes chiffrées auditées, la récupération à seuil et l'autorisation par appareil indépendant, ainsi que le fait de faire effectuer aux utilisateurs des exercices de récupération avant de déposer des montants importants d'actifs. Les fragments de sauvegarde et le multisig sont des couches différentes : les premiers peuvent se recombiner en un même secret lors de la récupération, tandis que le second exige que plusieurs signataires indépendants approuvent une transaction. Les services de récupération ne doivent pas devenir discrètement une nouvelle clé maîtresse, et un mot de passe supplémentaire ne doit pas non plus devenir un autre piège où sa perte signifie une perte irrécupérable.Les portefeuilles personnels et les systèmes de portefeuilles d'échange peuvent partager des spécifications de sécurité pour les descriptions de transactions, les demandes de signature, les restrictions d'actifs et les processus de récupération, tout en adoptant des limites et des politiques d'approbation différentes. Le PSBT de Bitcoin fournit déjà un format pour transmettre des transactions non signées entre outils, et cette interface commune mérite d'être développée davantage. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) 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 présenter clairement ce que cette signature transférera et quelle autorité subséquente elle accorde à qui, et des politiques indépendantes doivent rejeter les opérations hors limites ; une page de confirmation plus jolie ne suffit pas.
III. Atteindre la vérifiabilité avec une divulgation minimale nécessaire
Prouver qu'une condition est remplie ne devrait pas toujours exiger des utilisateurs qu'ils divulguent toutes les données sous-jacentes. La divulgation sélective, les preuves à divulgation nulle de connaissance et l'accès d'audit accordé à la demande devraient devenir des options normales dans l'infrastructure. Cela est également lié à la sécurité des actifs : l'identité publique et les relations entre actifs peuvent fournir des indices pour une tromperie ciblée ; les données dont l'entreprise n'a pas besoin doivent être exposées le moins possible.
Le système de credentials vérifiables du W3C dispose déjà d'une voie technique pour la divulgation sélective ; toutefois, prouver que les entrées sont authentiques, que les credentials restent valides et comment le statut est révoqué doit encore être clarifié. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) L'adoption de preuves à divulgation nulle de connaissance (ZK) ne masque pas automatiquement les montants et les relations des transactions ; la mise à l'échelle 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é à participer, un utilisateur peut présenter une conclusion d'éligibilité valide émise par une institution de confiance sans divulguer de documents financiers complets. Lorsqu'il est nécessaire de prouver qu'une valeur cachée satisfait une condition, un mécanisme de preuve approprié peut alors être utilisé. La source de confiance du credential et son statut de révocation doivent encore être vérifiés.
Mon initiative est de clarifier d'abord « qui doit vérifier quoi », puis de concevoir les données qui doivent être rendues publiques. Ceux qui vérifient l'éligibilité peuvent n'avoir besoin que de la conclusion d'éligibilité ; ceux qui assument des responsabilités d'audit spécifiques peuvent obtenir des preuves restreintes. Les contraintes vérifiables publiquement devraient minimiser les informations personnelles exposées de manière permanente à tous.
IV. Rendre les services de transaction aussi exempts que possible de garde centraliséeLa correspondance des ordres, la recherche de chemin et le règlement des actifs doivent être conçus séparément. Un service fournissant un point d'entrée de négociation ne devrait obtenir que les autorisations nécessaires pour mener à bien le règlement en cours dans la mesure du possible, afin que les actifs des utilisateurs restent sous leur contrôle respectif le reste du temps. Les protocoles de transaction basés sur l'intention existants ont déjà exploré une partie du chemin, et l'industrie peut continuer à le compléter. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
Ce à quoi les utilisateurs consentent doit être des conditions de règlement claires, incluant ce qui est payé, ce qui est reçu au minimum, quand cela expire, et les frais autorisés. Après qu'un service de négociation a été compromis, l'attaquant peut refuser le service, mais ne peut pas modifier arbitrairement ces conditions. Les entreprises qui nécessitent encore une garde centralisée devraient également séparer les autorisations de réserve et opérationnelles, et limiter l'exposition des portefeuilles chauds et les limites de réapprovisionnement automatique.
IBIT est le produit négocié en bourse de bitcoin d'iShares, et ce qui se négocie sur le marché sont ses actions. Son arrangement fournit un exemple d'isolation partielle : les actions et le Bitcoin sous-jacent sont enregistrés séparément, et les clés privées pertinentes pour le Vault Balance (solde de garde) sont placées en stockage à froid. Les changements dans l'enregistrement des transactions d'actions n'exigent pas que le Bitcoin sous-jacent se déplace à chaque transaction. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Ce que l'on peut en apprendre est la séparation des droits de négociation et des droits de disposition des réserves. Son Trading Balance (solde du service de négociation) a un arrangement différent, et la garde elle-même comporte également des risques ; le stockage à froid doit être associé à une vérification indépendante des instructions et des signatures.
Je compare le point d'entrée de négociation à un routeur dans l'espoir qu'il puisse être remplacé sans porter un interrupteur principal sur les actifs de tous les utilisateurs. Le règlement est plus complexe que le transfert de paquets, et la livraison des actifs et l'autorisation doivent encore être vérifiées indépendamment. Rendre un service non dépositaire puis lui accorder des droits de retrait illimités ne fera que ramener le risque centralisé.
V. Utiliser une architecture en couches pour isoler les défaillances et préserver la remplaçabilitéNous avons besoin d’interfaces d’identité et d’autorisation, de politiques d’actifs et de méthodes de vérification du règlement qui puissent évoluer indépendamment. Différentes chaînes peuvent conserver leurs propres modèles d’exécution et se connecter via des interfaces claires. Les interfaces doivent énoncer les garanties de sécurité et leurs conditions, et pas seulement dire « l’appel a réussi ». L’expérience d’Internet soutient cette approche. Dans la RFC 9518, « Centralization, Decentralization, and Internet Standards », Mark Nottingham examine spécifiquement les situations dans lesquelles la centralisation peut être utile, et analyse aussi le pouvoir et les risques qu’elle apporte. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) C’est exactement l’attitude qui mérite d’être adoptée : laisser l’architecture répondre à quelles responsabilités peuvent être centralisées, dans quelle mesure, et comment empêcher ce pouvoir de s’étendre. Un service peut être autorisé à identifier centralement des anomalies tandis que son droit de toucher aux actifs est limité ; les utilisateurs doivent pouvoir changer de service sans perdre leurs propres politiques d’actifs et leurs enregistrements de vérification.
La question d’acceptation la plus importante est : après la compromission d’un service métier, quelle couche indépendante peut encore le rejeter ? Si toutes les couches partagent une seule clé administrative, la prétendue superposition n’est qu’une superposition sur un schéma de déploiement.
Cet objectif peut être considéré comme cinq couches de responsabilité : le service de transaction soumet les requêtes, le portefeuille exprime l’intention de l’utilisateur, une politique indépendante limite l’autorité sur la disposition des actifs, le composant de vérification contrôle les opérations et les preuves, et la couche de règlement applique les contraintes et fournit des enregistrements vérifiables. Elles peuvent être mises en œuvre par différentes équipes, et leurs dépendances ainsi que leurs conditions de défaillance doivent aussi être décrites séparément.
L’architecture cible préconisée dans cet article. La couche de règlement doit appliquer la politique d’actifs ; les invites dans le portefeuille ne peuvent pas remplacer cette contrainte. La signature quotidienne, les modifications de règles et l’autorité de récupération doivent être isolées et soumises à des tests de contournement.
6. Permettre aux utilisateurs de vérifier légèrement leurs propres actifs
Les personnes ordinaires ne devraient pas avoir à stocker et exécuter tout l’historique de la chaîne entière pour vérifier leurs propres soldes et reçus ; elles ne devraient pas non plus devoir faire confiance uniquement à un seul serveur derrière le portefeuille. Satoshi Nakamoto a déjà proposé la SPV, vérification simplifiée des paiements, à la section 8 du livre blanc. Le BIP-157 de Bitcoin continue d’explorer la possibilité de laisser les clients télécharger des filtres et trouver les blocs qui les concernent ; Ethereum dispose aussi de conceptions de client léger. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Le problème n’est donc pas que personne n’y ait jamais pensé, mais que nous devons encore intégrer une capacité de vérification avec des conditions de sécurité claires dans les portefeuilles que les utilisateurs emploient chaque jour.Prenons l’exemple d’une chaîne qui prend en charge les preuves d’état de compte : lors d’une requête de solde, le serveur doit renvoyer à la fois le solde et une preuve. Le portefeuille vérifie d’abord un court digest de bloc, c’est-à-dire l’en-tête de bloc, selon les règles de cette chaîne, puis vérifie si ce solde est cohérent avec les données engagées par le digest. Le serveur fournit la réponse, et le portefeuille peut vérifier la réponse. Le SPV de Bitcoin vérifie la preuve que des transactions pertinentes ont été incluses ; il ne peut pas être directement copié comme preuve de solde. Le portefeuille doit aussi afficher clairement jusqu’où il s’est synchronisé et quelles informations ont été vérifiées ; lorsque des preuves manquent, que les données sont obsolètes ou que des sources entrent en conflit, il doit avertir ou arrêter les opérations à haut risque qui dépendent de ces informations, et ne doit jamais revenir silencieusement à une confiance aveugle.
La vérification légère a encore des conditions. Prouver qu’une transaction a été incluse dans un bloc n’est pas la même chose que vérifier soi-même que toutes les transactions du bloc sont valides. Différents schémas peuvent dépendre de l’honnêteté d’une majorité de puissance de hachage, ou d’un enregistrement initial de confiance, c’est-à-dire un checkpoint ; ils doivent aussi se prémunir contre des serveurs qui retiennent des données ou isolent des utilisateurs sur un enregistrement de chaîne obsolète. La question de savoir si la requête elle-même expose les adresses qui intéressent un utilisateur doit également être traitée. Les nœuds complets et les producteurs de blocs ne sont pas le même rôle ; Ethereum utilise aujourd’hui des validateurs plutôt que des mineurs pour la production de blocs.
Plus important encore, prouver que « ce transfert a réellement eu lieu on-chain » ne peut pas prouver que « c’est exactement le transfert que l’utilisateur voulait ». Les clients légers ne peuvent pas remplacer les limites d’actifs et les vérifications de signature antérieures. Ils permettent aux utilisateurs de dépendre moins d’une réponse non vérifiable, tandis que la politique d’actifs garantit que même une signature valide ne peut pas disposer d’actifs sans limite. Ce n’est qu’en construisant ensemble ces deux couches que la capacité de vérification peut être répartie entre les participants.
7. Faire de l’identification des anomalies et de la vérification de sécurité une infrastructure publique
Avant une transaction, quelqu’un devrait vérifier si l’opération respecte la politique d’actifs et si elle modifie soudainement le comportement historique. Les anomalies évidentes peuvent déclencher une pause ou un examen renforcé ; l’extension des permissions exige une autre voie indépendante. L’IA peut participer au jugement, mais ne doit pas recevoir un laissez-passer qui prime sur des règles strictes.
En même temps, nous devons maintenir conjointement des cas d’attaque, des tests de permissions et des outils de vérification pouvant être exécutés de manière répétée. Ce n’est qu’en partageant les spécifications et en préservant des implémentations indépendantes et une vérification indépendante que l’on peut réduire les défaillances de mode commun. Les fondations et les exchanges ont déjà des investissements en sécurité, comme l’initiative Trillion Dollar Security de la Ethereum Foundation. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) La prochaine question à poser est de savoir si l’investissement peut être transformé en infrastructure publique que d’autres équipes peuvent également adopter et inspecter.Aucun de ces sept éléments de travail ne peut garantir une sécurité absolue. Ce qu'ils doivent fournir, ce sont des frontières inspectables : dans quelles conditions de compromission des permissions, combien d'actifs sont exposés au maximum, à quelle vitesse les anomalies peuvent être détectées, et de qui dépend encore la reprise.
À ce stade, certains diront peut-être : la direction semble bonne, mais l'industrie a déjà progressé pendant tant d'années ; combien de personnes et combien de temps faudrait-il pour reconstruire ? N'est-ce pas encore de l'idéalisme ?
Si l'on raisonne selon le mode de production logicielle du passé, ce doute est très réaliste. Mais d'ici 2026, je crois que les agents de codage et l'ingénierie logicielle assistée par IA ont déjà changé la capacité de construction que nous pouvons mobiliser. Les agents de codage mentionnés ici sont des assistants de programmation IA capables de lire et d'écrire du code, d'appeler des outils, d'exécuter des tests et de continuer à travailler à partir des retours dans un environnement de développement. Les constructeurs fixent les objectifs, définissent les frontières de sécurité, utilisent ces outils pour implémenter et vérifier les systèmes, et assument la responsabilité des résultats.
Un travail qui nécessitait auparavant de grandes équipes pour implémenter, adapter et maintenir de manière répétée peut désormais être tenté par de petites équipes avec cette nouvelle approche d'ingénierie. Une équipe détient une couche, livre des composants autour d'interfaces claires, puis d'autres équipes les inspectent et les combinent. Organiser le jugement architectural humain, la capacité d'implémentation des agents de codage et la vérification de sécurité indépendante constitue, à mon avis, la voie de construction qu'il vaut la peine de réévaluer sérieusement.
Les recherches d'Anthropic et du PNNL en donnent un exemple concret : dans un environnement de simulation limité d'infrastructure critique, les chercheurs ont rapporté que la reconstruction d'une attaque était passée de plusieurs semaines possibles à environ trois heures. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Cela ne prouve pas qu'une petite équipe peut déjà réécrire en toute sécurité l'ensemble du secteur, mais cela montre que des travaux de vérification et d'offense-défense auparavant coûteux peuvent avoir de nouvelles conditions de coût.
Une approche organisationnelle que l'on peut démarrer dès maintenant consiste à construire conjointement une Build in Public AI Factory. Des experts du secteur, des universitaires et des praticiens rédigent ouvertement les exigences et les spécifications d'acceptation (spec), en expliquant ce qui doit être protégé, quelles opérations sont autorisées et quelles frontières doivent encore tenir après la compromission de quelles permissions, puis transforment ces exigences en tests d'acceptation. Des groupes d'agents de codage prennent en charge l'essentiel du codage, des tests et du débogage ; différentes équipes inspectent les conceptions et les résultats, et les humains assument le jugement et la responsabilité de l'acceptation.Les participants peuvent apporter des idées, des machines, de la puissance de calcul et des quotas d'invocation de modèles, c'est-à-dire des tokens 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, les workflows d'agents, les environnements de test et les résultats de vérification peuvent tous devenir des infrastructures maintenues en commun, permettant à l'équipe suivante de continuer directement à partir de là. L'objectif est de transformer la capacité de développement en installations publiques réutilisables et de réduire la dépendance au temps d'une seule personne ou à une seule équipe.
Les attaquants utilisent aussi l'IA, et nous n'avons plus de raison de laisser la défense dans les méthodes de production du passé. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Mais la rapidité de la génération de code n'est qu'un point de départ. Ce n'est qu'en écrivant clairement les contraintes, en rendant les tests exécutables de manière répétée et en rendant un composant inspectable et remplaçable que la capacité de l'IA peut être transformée en amélioration de l'infrastructure.
Les bâtisseurs indépendants travaillent ensemble à l'aide d'agents de codage et d'outils d'IA. L'atelier spatial est une métaphore de la construction publique. Je tiens particulièrement à adresser cet appel à ceux qui aiment encore construire. Le « hacker » ici désigne quelqu'un qui est prêt à comprendre comment un système fonctionne, prêt à partager ce qu'il découvre et prêt à laisser les autres tester son travail. Cet esprit a autrefois fait avancer l'Internet, et aujourd'hui il peut aussi faire avancer le Crypto.
Je ne crois pas que cette industrie manque de personnes intelligentes, et je ne crois pas que les industries du Crypto et de l'IA ne puissent pas trouver les ressources pour soutenir ce travail. Ce qui est plus difficile, c'est d'organiser ensemble les talents, le financement et la responsabilité soutenue. Les fondations et les entreprises capables devraient être prêtes à assumer le coût à long terme d'un travail fondamental qui ne génère pas directement de revenus mais bénéficie à tous.
J'espère que chacun pourra travailler ensemble pour construire une infrastructure cryptographique partagée à l'échelle mondiale. Différents réseaux et équipes peuvent collaborer sous des contraintes de sécurité communes, chacun mettant en œuvre ses propres solutions et testant celles des autres, et les utilisateurs peuvent choisir et migrer. Cela peut commencer par un seul composant, mais la direction doit être suffisamment vaste pour accueillir toute l'industrie construisant ensemble. Tous les participants, y compris ArcBlock, devraient contribuer un travail vérifiable.
Nous devrions construire conjointement un type d'infrastructure où, même si une partie a été compromise, les actifs ont encore des limites, les autres systèmes peuvent encore rejeter les erreurs, et les utilisateurs ont encore des chemins de récupération et de sortie. Empruntant le nom à Star Wars, c'est notre A New Hope. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) L'espoir vient des bâtisseurs ordinaires prêts à agir, et aussi de ce moment où les agents de codage et les nouvelles méthodes d'ingénierie leur permettent d'assumer davantage de travail de construction.Je souhaite adresser une invitation aux constructeurs de projets tels qu'Ethereum, Solana, Bitcoin et XRP Ledger, aux plateformes d'échange telles que Binance, Coinbase et Kraken, ainsi qu'aux équipes de portefeuilles, de protocoles, de recherche en sécurité, d'IA et d'informatique en nuage : commencez par un pilote au périmètre clairement défini et produisez conjointement des améliorations que d'autres équipes pourront adopter et tester.
Les noms cités ne sont que des exemples, sans ordre particulier. Quelle que soit votre taille ou la voie technique que vous suivez, vous êtes les bienvenus pour participer. Cette invitation inclut également les constructeurs des voies techniques critiquées dans cet article ; améliorer ensemble la sécurité des actifs vaut la peine de franchir les frontières de nos écosystèmes respectifs.
Je suis moi-même disposé à participer et à contribuer avec 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 ce que nous pouvons faire est limité. J'espère commencer par un prototype et un ensemble de tests reproductibles.
Les personnes ayant une expérience opérationnelle concrète 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 tenter de les contourner. Chaque équipe assume la partie qu'elle peut traiter, teste conjointement la solution et décide de la prochaine étape.
Je suis disposé à participer à l'organisation des exigences de limitation et de récupération des actifs décrites dans cet article en une première spécification publique, et je suis également disposé à contribuer les pratiques techniques et d'ingénierie pertinentes pour construire, avec d'autres participants, une AI Factory publique pour ce pilote. Choisissons d'abord un problème très précis : une fois la clé de transaction quotidienne compromise, comment empêcher encore l'attaquant de vider le portefeuille d'un seul coup ? Inscrivez dans les tests d'acceptation la plage de perte autorisée, l'autorité de modification des règles et les conditions de récupération, puis chargez des agents de développement d'implémenter un prototype, et chargez un autre groupe d'agents et de chercheurs indépendants de chercher des voies de contournement. Les serveurs de données renvoyant des soldes incorrects, ainsi que la récupération après perte d'appareil, peuvent également être ajoutés progressivement aux tests. Ce que le prototype accomplit, où il échoue et quelles dépendances subsistent doivent tous être expliqués publiquement, et la prochaine étape doit être décidée sur la base des preuves.
Ceux qui souhaitent participer sont invités à republier ou citer publiquement cette initiative sur X et à @mave99a, et à parler du problème que vous voulez résoudre, de cas d'attaque anonymisés ou des ressources que vous pouvez contribuer. J'espère que la discussion se déroulera publiquement, afin que davantage de constructeurs puissent la voir et s'y joindre.
La crypto ne peut pas continuer ainsi. Ceux qui sont disposés à travailler ensemble, agissons maintenant, en commençant par une amélioration qui peut être construite et qui résiste aux tests.Binance, publication officielle de l'annonce initiale et mise à jour officielle de l'enquête de suivi, 2026-10-30 ; analyse multi-chaînes TRM. Ce brouillon a été vérifié au 2026-10-30 ; l'état de l'enquête et du recouvrement peut évoluer. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. La concentration des risques liée aux dépendances partagées est un jugement de l'auteur dans cet article, et non une conclusion de ce document. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, créé le 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, préimpression arXiv v1 ; ne constitue pas une identification de cet incident Binance. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), mécanismes d'ordonnancement, différents types et effets négatifs ; « devrait être corrigé comme un bug » est la position d'ingénierie de l'auteur sur les comportements nuisant aux utilisateurs. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
Archive officielle des actualités PHP 2026 ; mise à jour du catalogue des vulnérabilités exploitées connues de la CISA du 2026-10-26, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, description des fonctionnalités et des risques de permissions. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11 ; description actuelle du support de l'appairage des pièces. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, déclaration du fournisseur sur une attaque dans la chaîne de distribution ; Joe Grand, recherche en rétro-ingénierie sur les implants matériels. Ne pas présenter d'estimations non vérifiées de pertes réseau comme des conclusions définitives. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, consulté le 2026-10-30, registre mis à jour en continu de l'incident de juillet 2026 et des mesures correctives ; la mise à niveau et la migration de la seed sont deux opérations distinctes. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool ; Trezor, SLIP39 FAQs, récupération par seuil, compatibilité et risques supplémentaires liés à la passphrase. Les mécanismes existants constituent une base pour construire, et ne signifient pas que chaque déploiement est fiable. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174 : Format de transaction Bitcoin partiellement signée, un format d'échange pour les transactions non signées, et non une spécification générale de stratégie d'actifs inter-chaînes. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, Note de groupe du 2026-07-30 ; notes sur la confidentialité d'Ethereum. Le statut normatif des technologies décrites dans l'aperçu est indépendant dans chaque cas. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
Documentation de CoW Protocol, intentions de transaction et mécanismes de solveurs ; cet article ne fournit aucune approbation de sécurité globale pour un déploiement spécifique. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 Annual Report, pages PDF 8–10 sur les modalités de conservation et page 45 sur les informations relatives aux risques. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, soumis indépendamment, RFC informatif, non une spécification de la voie normative. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Livre blanc Bitcoin, Section 8 Simplified Payment Verification ; BIP-157: Client Side Block Filtering ; Ethereum, Light clients. Les différents clients légers ont des périmètres de vérification et des conditions de confiance différents. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI to defend critical infrastructure, 2026-01-08, recherche en environnement limité en collaboration avec PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapping AI-enabled cyber threats, recherche sur des échantillons réels d'abus. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977 ; cet article emprunte le titre et l'imagerie de l'auto-sauvetage conjoint. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)