Un pirate a volé 31 millions de dollars d'Ether - comment cela s'est produit et ce que cela signifie pour Ethereum

Hier, un pirate a réussi le deuxième plus grand casse de l'histoire des monnaies numériques.

Vers 12 h 00 HNP, un attaquant inconnu a exploité une faille critique dans le portefeuille multi-signatures Parity sur le réseau Ethereum, vidant trois portefeuilles massifs de plus de 31 000 000 $ d'Ether en quelques minutes. Compte tenu de quelques heures de plus, le pirate aurait pu s'en sortir avec plus de 180 000 000 $ de portefeuilles vulnérables.

Mais quelqu'un les a arrêtés.

Après avoir tiré la sonnette d'alarme, un groupe de hackers bienveillants à chapeau blanc de la communauté Ethereum s'est rapidement organisé. Ils ont analysé l'attaque et ont réalisé qu'il n'y avait aucun moyen d'inverser les vols, mais de nombreux autres portefeuilles étaient vulnérables. Le temps était compté, ils n'ont donc vu qu'une seule option disponible: pirater les portefeuilles restants avant l'attaquant.

En exploitant la même vulnérabilité, les chapeaux blancs ont piraté tous les portefeuilles à risque restants et vidé leurs comptes, empêchant ainsi l'attaquant d'atteindre les 150 000 000 $ restants.

Oui, tu l'as bien lu.

Pour empêcher le pirate de voler d'autres banques, les chapeaux blancs ont écrit un logiciel pour voler toutes les banques restantes dans le monde. Une fois que l'argent a été volé en toute sécurité, ils ont commencé à retourner les fonds à leurs titulaires de compte respectifs. Les personnes qui ont économisé leur argent grâce à cet exploit héroïque sont en train de récupérer leurs fonds.

C'est une histoire extraordinaire, et elle a des implications importantes pour le monde des crypto-monnaies.

Il est important de comprendre que cet exploit n'était pas une vulnérabilité dans Ethereum ou dans Parity lui-même. Il s'agissait plutôt d'une vulnérabilité dans le code de contrat intelligent par défaut que le client Parity donne à l'utilisateur pour le déploiement de portefeuilles multi-signatures.

Tout cela est assez compliqué, donc pour que les détails soient clairs pour tout le monde, ce message est divisé en trois parties:

  1. Qu'est-il exactement arrivé? Une explication d'Ethereum, des contrats intelligents et des portefeuilles multi-signatures.
  2. Comment l'ont-ils fait? Une explication technique de l'attaque (spécifiquement pour les programmeurs).
  3. Et maintenant? Les implications de l'attaque sur l'avenir et la sécurité des contrats intelligents.

Si vous connaissez Ethereum et le monde de la cryptographie, vous pouvez passer à la deuxième section.

1. Que s'est-il passé exactement?

Cette histoire comprend trois éléments constitutifs: Ethereum, les contrats intelligents et les portefeuilles numériques.

Ethereum est une monnaie numérique inventée en 2013 - 4 ans après la sortie de Bitcoin. Depuis, elle est devenue la deuxième plus grande monnaie numérique au monde en termes de capitalisation boursière - 20 milliards de dollars, contre 40 milliards de dollars pour Bitcoin.

Comme toutes les crypto-monnaies, Ethereum est un descendant du protocole Bitcoin et améliore la conception de Bitcoin. Mais ne vous y trompez pas: bien qu'il s'agisse d'une monnaie numérique comme le Bitcoin, Ethereum est beaucoup plus puissant.

Alors que Bitcoin utilise sa blockchain pour implémenter un registre des transactions monétaires, Ethereum utilise sa blockchain pour enregistrer les transitions d'état dans un gigantesque ordinateur distribué. La monnaie numérique correspondante d'Ethereum, l'éther, est essentiellement un effet secondaire de l'alimentation de cet ordinateur massif.

En d'autres termes, Ethereum est littéralement un ordinateur qui couvre le monde entier. Quiconque exécute le logiciel Ethereum sur son ordinateur participe aux opérations de cet ordinateur mondial, la machine virtuelle Ethereum (EVM). Parce que l'EVM a été conçu pour être complet de Turing (en ignorant les limites de gaz), il peut faire presque tout ce qui peut être exprimé dans un programme informatique.

Permettez-moi d'être catégorique: ce sont des trucs fous. Le monde de la crypto est bouillonnant quant au potentiel d'Ethereum, qui a vu sa valeur monter en flèche au cours des 6 derniers mois.

La communauté des développeurs s'est ralliée à cela, et il y a beaucoup d'enthousiasme à propos de ce qui peut être construit au-dessus de l'EVM - et cela nous amène à des contrats intelligents.

Les contrats intelligents sont simplement des programmes informatiques qui s'exécutent sur l'EVM. À bien des égards, ils sont comme des contrats normaux, sauf qu'ils n'ont pas besoin d'avocats ou de juges pour les interpréter. Au lieu de cela, ils sont compilés en bytecode et interprétés sans ambiguïté par l'EVM. Avec ces programmes, vous pouvez (entre autres) transférer par programme de la monnaie numérique uniquement sur la base des règles du code de contrat.

Bien sûr, il y a des choses que les contrats normaux font que les contrats intelligents ne peuvent pas - les contrats intelligents ne peuvent pas facilement interagir avec des choses qui ne sont pas sur la blockchain. Mais les contrats intelligents peuvent également faire des choses que les contrats normaux ne peuvent pas faire, comme appliquer un ensemble de règles entièrement par le biais d'une cryptographie incassable.

Cela nous amène à la notion de portefeuilles. Dans le monde des monnaies numériques, les portefeuilles sont la façon dont vous stockez vos actifs. Vous accédez à votre portefeuille en utilisant essentiellement un mot de passe secret, également connu sous le nom de votre clé privée (simplifiée un peu).

Il existe de nombreux types de portefeuilles qui confèrent différentes propriétés de sécurité, telles que les limites de retrait. L'un des types les plus populaires est le portefeuille multi-signatures.

Dans un portefeuille multi-signatures, plusieurs clés privées peuvent déverrouiller le portefeuille, mais une seule clé ne suffit pas pour le déverrouiller. Si votre portefeuille multi-signatures dispose de 3 clés, par exemple, vous pouvez spécifier qu'au moins 2 des 3 clés doivent être fournies pour réussir à le déverrouiller.

Cela signifie que si vous, votre père et votre mère êtes chacun signataires de ce portefeuille, même si un criminel a piraté votre mère et volé sa clé privée, il ne pourrait toujours pas accéder à vos fonds. Cela conduit à des garanties de sécurité beaucoup plus fortes, donc les multi-scigs sont une norme en matière de sécurité de portefeuille.

C'est le type de portefeuille que le pirate informatique a attaqué.

Alors qu'est-ce qui a mal tourné? Ont-ils cassé les clés privées? Ont-ils utilisé un ordinateur quantique ou une sorte d'algorithme d'affacturage de pointe?

Non, toute la cryptographie était saine. L'exploit était presque ridiculement simple: ils ont trouvé un bogue introduit par le programmeur dans le code qui leur permettait de réinitialiser le portefeuille, presque comme le restaurer aux paramètres d'usine. Une fois cela fait, ils étaient libres de se définir comme les nouveaux propriétaires, puis de tout quitter.

2. Comment est-ce arrivé?

Ce qui suit est une explication technique de ce qui s'est passé exactement. Si vous n'êtes pas développeur, n'hésitez pas à passer à la section suivante, car cela va être lourd en programmation.

Ethereum a un modèle de programmation assez unique. Sur Ethereum, vous écrivez du code en publiant des contrats (que vous pouvez considérer comme des objets), et les transactions sont exécutées en appelant des méthodes sur ces objets pour muter leur état.

Pour exécuter du code sur Ethereum, vous devez d'abord déployer le contrat (le déploiement est lui-même une transaction), ce qui coûte une petite quantité d'Ether. Vous devez ensuite appeler des méthodes sur le contrat pour interagir avec lui, ce qui coûte plus d'Ether. Comme vous pouvez l'imaginer, cela incite un programmeur à optimiser son code, à la fois pour minimiser les transactions et les coûts de calcul.

Une façon de réduire les coûts est d'utiliser des bibliothèques. En faisant appel à votre contrat à une bibliothèque partagée qui a été déployée à un moment précédent, vous n'avez pas à redéployer tout code partagé. Dans Ethereum, garder votre code SEC vous fera économiser directement de l'argent.

Le portefeuille multi-signature par défaut dans Parity a fait exactement cela. Il contenait une référence à une bibliothèque externe partagée qui contenait la logique d'initialisation du portefeuille. Cette bibliothèque partagée est référencée par la clé publique du contrat de bibliothèque.

// Constante d'adresse FIELDS _walletLibrary = 0xa657491c1e7f16adb39b9b60e87bbb8d93988bc3;

La bibliothèque est appelée à plusieurs endroits, via une instruction EVM appelée DELEGATECALL, qui fait ce qui suit: pour toute méthode qui appelle DELEGATECALL, elle appellera la même méthode sur le contrat auquel vous déléguez, mais en utilisant le contexte du contrat actuel . C'est essentiellement comme un super appel, sauf sans la partie héritage. (L'équivalent en JavaScript serait OtherClass.functionName.apply (this, args).)

Voici un exemple de cela dans leur portefeuille multi-signature: la méthode isOwner délègue simplement à la méthode isOwner de la bibliothèque de portefeuille partagée, en utilisant l'état du contrat actuel:

fonction isOwner (adresse _addr) constante renvoie (bool) {return _walletLibrary.delegatecall (msg.data); }

Tout cela est assez innocent. Le portefeuille multi-signature lui-même contenait tous les bons contrôles d'autorisation, et ils étaient sûrs d'appliquer rigoureusement l'autorisation sur toutes les actions sensibles liées à l'état du portefeuille.

Mais ils ont fait une erreur critique.

Solidity vous permet de définir une «méthode de secours». Il s'agit de la méthode qui est appelée lorsqu'aucune méthode ne correspond à un nom de méthode donné. Vous le définissez en ne lui donnant pas de nom:

function () {// fait des trucs ici pour toutes les méthodes inconnues}

L'équipe de parité a décidé de laisser toute méthode inconnue qui a envoyé de l'éther au contrat par défaut pour déposer l'éther envoyé.

function () payable {// payable n'est qu'un mot-clé qui signifie que cette méthode peut recevoir / payer de l'éther
if (msg.value> 0) {// vient-il de recevoir de l'argent? Dépôt (msg.sender, msg.value); } else {throw; }}

Mais ils sont allés plus loin, et c'était là leur erreur critique. Ci-dessous se trouve le code réel qui a été attaqué.

function () payable {// vient d'être envoyé de l'argent? if (msg.value> 0) Deposit (msg.sender, msg.value); sinon if (msg.data.length> 0) _walletLibrary.delegatecall (msg.data); }

Fondamentalement:

  • Si le nom de la méthode n'est pas défini sur ce contrat…
  • Et il n'y a pas d'éther envoyé dans la transaction…
  • Et il y a des données dans la charge utile du message…

Ensuite, il appellera exactement la même méthode si elle est définie dans _walletLibrary, mais dans le contexte de ce contrat.

À l'aide de cela, l'attaquant a appelé une méthode appelée initWallet (), qui n'était pas définie sur le contrat multisig mais était définie dans la bibliothèque de portefeuille partagée:

function initWallet (address [] _owners, uint _required, uint _daylimit) {initDaylimit (_daylimit); initMultined (_ propriétaires, _requis); }

Qui appelle la méthode initMultiowed ...

fonction initMultiowed (adresse [] _owners, uint _required) {m_numOwners = _owners.length + 1; m_owners [1] = uint (msg.sender); m_ownerIndex [uint (msg.sender)] = 1; for (uint i = 0; i <_owners.length; ++ i) {m_owners [2 + i] = uint (_owners [i]); m_ownerIndex [uint (_owners [i])] = 2 + i; } m_required = _required; }

Voyez-vous ce qui vient de se passer là-bas? L'attaquant a essentiellement réinitialisé le contrat en déléguant via la méthode de la bibliothèque, en écrasant les propriétaires sur le contrat d'origine. Ce sont eux et tout autre éventail de propriétaires qu'ils fourniront comme arguments.

Étant donné qu'ils contrôlent désormais l'intégralité du portefeuille, ils peuvent extraire trivialement le reste du solde. Et c'est précisément ce qu'ils ont fait.

Le initWallet: https://etherscan.io/tx/0x707aabc2f24d756480330b75fb4890ef6b8a26ce0554ec80e3d8ab105e63db07

Le transfert: https://etherscan.io/tx/0x9654a93939e98ce84f09038b9855b099da38863b3c2e0e04fd59a540de1cb1e5

Alors, quelle était finalement la vulnérabilité? On pourrait dire qu'il y en avait deux. Tout d'abord, initWallet et initMultiOWN dans la bibliothèque de portefeuille n'étaient pas marqués comme internes (c'est comme une méthode privée, ce qui empêcherait cet appel délégué), et ces méthodes n'ont pas vérifié que le portefeuille n'était pas déjà initialisé. L'un ou l'autre contrôle aurait rendu ce hack impossible.

La deuxième vulnérabilité était le delegateCall brut. Vous pouvez considérer cela comme équivalent à une instruction eval brute, exécutée sur une chaîne fournie par l'utilisateur. Pour être succinct, ce contrat a utilisé la métaprogrammation pour proxy les appels de méthode potentiels à une bibliothèque sous-jacente. L'approche la plus sûre ici serait de mettre en liste blanche les méthodes spécifiques que l'utilisateur est autorisé à appeler.

Le problème, bien sûr, est que cela coûte plus cher en gaz (car il doit évaluer plus de conditions). Mais quand il s'agit de sécurité, nous devons probablement surmonter cette préoccupation lors de la rédaction de contrats intelligents qui déplacent des sommes énormes.

C'était donc l'attaque.

C'était une capture intelligente, mais une fois que vous le signalez, cela semble presque élémentaire. L'attaquant a ensuite sauté sur cette vulnérabilité pour trois des plus gros portefeuilles qu'ils pouvaient trouver - mais à en juger par les temps de transaction, ils le faisaient entièrement manuellement.

Le groupe chapeau blanc faisait cela à grande échelle en utilisant des scripts, et c'est pourquoi ils ont pu battre l'attaquant au poinçon. Compte tenu de cela, il est peu probable que l'attaquant ait été très sophistiqué dans la façon dont il a planifié son attaque.

Vous pourriez cependant poser la question - pourquoi ne font-ils pas simplement reculer ce hack, comme ils l'ont fait avec le hack DAO?

Malheureusement, ce n'est pas vraiment possible. Le hack DAO était unique en ce que lorsque l'attaquant a vidé le DAO dans un DAO enfant, les fonds ont été gelés pendant plusieurs jours dans un contrat intelligent avant de pouvoir être remis à l'attaquant.

Cela a empêché la mise en circulation des fonds volés, de sorte que l'éther volé a été effectivement cloisonné. Cela a donné à la communauté Ethereum beaucoup de temps pour mener un quorum public sur la façon de faire face à l'attaque.

Dans cette attaque, l'attaquant a immédiatement volé les fonds et pourrait commencer à les dépenser. Un hard fork ne serait pas pratique - que faites-vous de toutes les transactions qui se produisent en aval? Qu'en est-il des personnes qui ont innocemment échangé des actifs avec l'attaquant? Une fois que l'éther qu'ils ont volé est blanchi et entre dans la circulation générale, c'est comme des billets contrefaits qui circulent dans l'économie - il est facile de s'arrêter quand tout est dans une mallette, mais une fois que tout le monde détient potentiellement un billet contrefait, vous ne pouvez pas vraiment revenir en arrière l'horloge plus.

La transaction ne sera donc pas annulée. La perte de 31 M $ est maintenue. C'est une leçon coûteuse mais nécessaire.

Alors, que devons-nous retirer de cela?

3. Que signifie cette attaque pour Ethereum?

Il y a plusieurs points importants à retenir ici.

Tout d'abord, rappelez-vous, ce n'était pas une faille dans Ethereum ou dans les contrats intelligents en général. Il s'agissait plutôt d'une erreur de développeur dans un contrat particulier.

Alors, qui étaient les développeurs de crackpot qui ont écrit cela? Ils auraient dû mieux savoir, non?

Les développeurs ici étaient une collaboration croisée entre la fondation Ethereum (littéralement les créateurs d'Ethereum), l'équipe centrale de Parity et les membres de la communauté open-source. Il a fait l'objet d'un examen approfondi par les pairs. Il s'agit essentiellement de la norme de programmation la plus élevée qui existe dans l'écosystème Ethereum.

Ces développeurs étaient humains. Ils ont fait une erreur. Et les réviseurs qui ont audité ce code ont fait de même.

J'ai lu quelques commentaires sur Reddit et HackerNews dans le sens de: «Quelle erreur évidente! Comment était-il même possible qu'ils aient raté cela? » (Ignorant que la vulnérabilité «évidente» a été introduite en janvier et découverte seulement maintenant.)

Quand je vois des réponses comme celle-ci, je sais que les personnes qui commentent ne sont pas des développeurs professionnels. Pour un développeur sérieux, la réaction est plutôt: merde, c'était une erreur stupide. Je suis content de ne pas avoir réussi.

Des erreurs de ce type sont régulièrement commises dans la programmation. Tous les programmes comportent un risque d'erreur de développeur. Nous devons rejeter la mentalité de «s'ils étaient juste plus prudents, cela ne serait pas arrivé». À une certaine échelle, la prudence ne suffit pas.

Comme les programmes évoluent vers une complexité non triviale, vous devez commencer à le considérer comme étant donné que les programmes ne sont probablement pas corrects. Aucune quantité de diligence ou de test humain n'est suffisante pour empêcher tous les bogues possibles. Même des organisations comme Google ou la NASA font des erreurs de programmation, malgré l'extrême rigueur qu'elles appliquent à leur code le plus critique.

Nous ferions bien de prendre une page des pratiques de fiabilité du site dans des entreprises comme Google et Airbnb. Chaque fois qu'il y a un bug de production ou une panne, ils font une analyse post mortem et le distribuent au sein de l'entreprise. Dans ces autopsies, il y a toujours un principe de ne jamais blâmer les individus.

Blâmer les erreurs sur les individus est inutile, car tous les programmeurs, quelle que soit leur expérience, ont une probabilité non nulle de faire une erreur. Au lieu de cela, le but d'un post-mortem est d'identifier ce qui dans le processus a permis à cette erreur de se déployer.

Le problème n'était pas que le développeur avait oublié d'ajouter des éléments internes à la bibliothèque de portefeuille, ou qu'ils avaient effectué un delegateCall brut sans vérifier quelle méthode était appelée.

Le problème est que leur chaîne d'outils de programmation leur a permis de faire ces erreurs.

À mesure que l'écosystème des contrats intelligents évolue, il doit évoluer dans le sens de rendre ces erreurs plus difficiles, ce qui signifie rendre les contrats sécurisés par défaut.

Cela m'amène à mon prochain point.

La force est une faiblesse en ce qui concerne les langages de programmation. Plus un langage de programmation est fort et expressif, plus son code devient complexe. Solidity est un langage très complexe, modélisé pour ressembler à Java.

La complexité est l'ennemi de la sécurité. Les programmes complexes sont plus difficiles à raisonner et plus difficiles à identifier. Je pense que des langues comme Viper (maintenues par Vitalik Buterin) sont une étape prometteuse dans cette direction. Viper inclut par défaut des mécanismes de sécurité de base, tels que des constructions en boucle bornées, aucun débordement d'entier, et empêche d'autres bogues de base que les développeurs ne devraient pas avoir à raisonner.

Moins le langage vous le permet, plus il est facile d'analyser et de prouver les propriétés d'un contrat. La sécurité est difficile car la seule façon de prouver une déclaration positive comme «ce contrat est sécurisé» est de réfuter tous les vecteurs d'attaque possibles: «ce contrat ne peut pas être réinitialisé», «ses fonds ne sont accessibles que par les propriétaires», etc. Moins vous devez envisager de vecteurs d'attaque, plus il est facile de développer un contrat sécurisé.

Un modèle de programmation plus simple permet également des choses comme la vérification formelle et la génération automatique de tests. Ce sont des domaines en recherche active, mais tout comme les contrats intelligents ont incorporé une cryptographie de pointe, ils devraient également commencer à intégrer la pointe de la conception de langages de programmation.

Il y a là aussi une leçon plus importante.

La plupart des programmeurs qui entrent dans cet espace, y compris moi-même, viennent d'un arrière-plan de développement Web, et la chaîne d'outils Blockchain est conçue pour être familière aux développeurs Web. Solidity a obtenu une énorme adoption dans la communauté des développeurs en raison de sa familiarité avec d'autres formes de programmation. D'une certaine manière, cela pourrait finir par être sa chute.

Le problème est que la programmation de la blockchain est fondamentalement différente du développement web.

Laisse-moi expliquer.

Avant l'ère du modèle Web client-serveur, la plupart des programmes étaient effectués pour des logiciels grand public emballés ou sur des systèmes embarqués. C'était avant le jour des mises à jour automatiques du logiciel. Dans ces programmes, un produit livré était définitif - vous avez publié une forme de votre logiciel tous les 6 mois, et s'il y avait un bogue, ce bogue devrait rester jusqu'à la prochaine version. En raison de ce cycle de développement plus long, toutes les versions du logiciel ont été rigoureusement testées dans toutes les circonstances imaginables.

Le développement Web est beaucoup plus indulgent. Lorsque vous envoyez un mauvais code à un serveur Web, ce n'est pas grave s'il y a une erreur critique - vous pouvez simplement restaurer le code ou avancer avec un correctif, et tout va bien parce que vous contrôlez le serveur. Ou si le pire se produit et qu'il y a une violation active ou une fuite de données, vous pouvez toujours arrêter le saignement en éteignant vos serveurs et en vous déconnectant du réseau.

Ces deux modèles de développement sont fondamentalement différents. C'est seulement à partir de quelque chose comme le développement Web que vous pouvez obtenir la devise «aller vite et casser les choses».

Aujourd'hui, la plupart des programmeurs sont formés sur le modèle de développement Web. Malheureusement, le modèle de sécurité de la blockchain s'apparente davantage à l'ancien modèle.

Dans la blockchain, le code est intrinsèquement irréversible. Une fois que vous avez déployé un mauvais contrat intelligent, n'importe qui est libre de l'attaquer aussi longtemps et durement qu'il le peut, et il n'y a aucun moyen de le reprendre s'il y parvient en premier. Sauf si vous intégrez des mécanismes de sécurité intelligents dans vos contrats, s'il y a un bug ou une attaque réussie, il n'y a aucun moyen d'arrêter vos serveurs et de corriger l'erreur. Être sur Ethereum par définition signifie que tout le monde possède votre serveur.

Un dicton courant en cybersécurité est «l'attaque est toujours plus facile que la défense». La blockchain multiplie fortement ce déséquilibre. Il est beaucoup plus facile d'attaquer car vous avez accès au code de chaque contrat, savez combien d'argent il contient et pouvez prendre autant de temps que vous voulez essayer de l'attaquer. Et une fois votre attaque réussie, vous pouvez potentiellement voler tout l'argent du contrat.

Imaginez que vous déployiez un logiciel pour des distributeurs automatiques. Mais au lieu d'un bogue vous permettant de voler simplement des bonbons sur une machine, le bogue vous permettait de voler simultanément des bonbons sur toutes les machines du monde qui utilisaient ce logiciel. Oui, c'est ainsi que fonctionne la blockchain.

Dans le cas d'une attaque réussie, la défense est extrêmement difficile. Les chapeaux blancs du hack Parity ont montré à quel point leurs options de défense étaient limitées - il n'y avait aucun moyen de garantir ou de démanteler les contrats, ni même de récupérer l'argent volé; tout ce qu'ils pouvaient faire était de pirater les contrats vulnérables restants avant l'attaquant.

Cela pourrait sembler épeler un avenir sombre.

Mais je ne pense pas que ce soit un glas pour la programmation de la blockchain. Il confirme plutôt ce que tout le monde sait déjà: cet écosystème est jeune et immature. Il faudra beaucoup de travail pour développer la formation et la discipline pour traiter les contrats intelligents comme les banques traitent leur logiciel ATM. Mais nous devrons y arriver pour que la blockchain réussisse à long terme.

Cela signifie non seulement que les programmeurs arrivent à maturité et reçoivent plus de formation. Cela signifie également développer des outils et des langages qui facilitent tout cela et nous donnent des garanties rigoureuses sur notre code.

C'est encore tot. Ethereum est un travail en cours et évolue rapidement. Vous ne devez pas considérer Ethereum comme une banque ou comme un remplaçant pour une infrastructure financière. Et vous ne devriez certainement pas stocker d'argent dans un portefeuille chaud que vous n'êtes pas à l'aise de perdre.

Mais malgré tout cela, je pense toujours que Ethereum va gagner à long terme. Et voici pourquoi: la communauté des développeurs d'Ethereum est ce qui le rend si puissant.

Ethereum ne vivra ni ne mourra à cause de l'argent qu'il contient. Il vivra ou mourra en fonction des développeurs qui se battent pour cela.

La ligue des chapeaux blancs qui se sont réunis et ont défendu les portefeuilles vulnérables ne l'ont pas fait pour de l'argent. Ils l'ont fait parce qu'ils croient en cet écosystème. Ils veulent qu'Ethereum prospère. Ils veulent voir leur vision de l'avenir devenir réalité. Et après toutes les spéculations et les profits, ce sont finalement ces gens qui vont faire entrer la communauté dans son avenir. Ils sont fondamentalement la raison pour laquelle Ethereum gagnera à long terme - ou s'ils abandonnent Ethereum, leur abandon sera la raison pour laquelle il perdra.

Cette attaque est importante. Cela va secouer les gens. Cela obligera la communauté à examiner longuement et attentivement les meilleures pratiques de sécurité. Cela obligera les développeurs à traiter la programmation des contrats intelligents avec beaucoup plus de rigueur qu'aujourd'hui.

Mais cette attaque n'a pas ébranlé la force des constructeurs qui travaillent sur ce genre de choses. Donc, dans ce sens, c'est un revers temporaire.

En fin de compte, des attaques comme celle-ci sont bonnes pour la communauté à grandir. Ils vous appellent à vos sens et vous forcent à garder les yeux ouverts. Ça fait mal, et la presse va probablement gâcher l'histoire. Mais chaque blessure renforce la communauté et nous rapproche d'une compréhension vraiment approfondie de la technologie de la blockchain - à la fois ses dangers et son incroyable potentiel.

PS Si vous êtes un développeur et que vous souhaitez en savoir plus sur la sécurité des contrats intelligents, c'est une très bonne ressource.

Errata: Cet article disait à l'origine que Gavin Wood était le développeur du contrat, ce qui est incorrect. Gavin est le fondateur de Parity et a poussé le correctif au contrat, mais n'était pas le développeur d'origine. Il a également affirmé à l'origine que 77 millions de dollars supplémentaires étaient vulnérables, mais cela ne prend pas en compte tous les jetons ERC20 (ICO) qui étaient vulnérables. Le montant total est en fait de 150 000 000 $ + si vous incluez tous les jetons ERC20. Au moment de la rédaction de cet article (21 juillet 16 h HNE), la valeur totale des actifs économisés par les chapeaux blancs était de 179 704 659 $.