L'exploit lui-même était brutalement simple dans son concept et dévastateur dans ses effets. Le 17 juin 2016, selon des post-mortems largement documentés et les propres discussions techniques d'Ethereum, un attaquant a utilisé une vulnérabilité de réentrance dans la fonction de séparation de The DAO pour retirer des fonds de manière récursive avant que le contrat puisse mettre à jour les soldes. C'est le genre de bug qui ressemble à une note de bas de page d'un programmeur jusqu'à ce qu'il devienne un événement financier. La logique du contrat permettait un appel externe avant que les changements d'état ne soient finalisés, et l'attaquant a exploité cet ordre d'opérations pour continuer à demander au contrat de payer à nouveau pendant que le grand livre croyait encore que le solde original restait intact.
Le drame technique s'est déroulé non pas dans une salle d'audience en marbre mais dans l'exécution du code, bloc par bloc. La blockchain a enregistré les transferts en vue publique, ce qui a rendu le vol particulièrement lisible après coup. Mais la lisibilité n'est pas la même chose que la prévention. Au moment où les observateurs ont compris ce qu'ils voyaient, l'attaque avait déjà drainé une grande part des fonds vulnérables vers un contrat enfant contrôlé par l'attaquant. Dans des descriptions ultérieures, le montant en jeu était d'environ 3,6 millions d'ether, bien que le calcul final de la perte soit devenu enchevêtré avec la décision de fork ultérieure et les mécanismes de récupération. La comptabilité précise importait, mais le point plus profond était qu'un programme destiné à automatiser la confiance avait été amené à répéter une autorisation erronée jusqu'à ce que le coffre-fort soit vidé.
Le fardeau de maintenance derrière un système comme The DAO était énorme. S'il avait s'agit d'une entreprise conventionnelle, on aurait imaginé du personnel de back-office, des auditeurs, des rapprochements bancaires et des agents de conformité. Ici, les protections équivalentes étaient la révision de code, la supervision communautaire et l'hypothèse qu'une blockchain publique exposerait rapidement les comportements inappropriés pour les corriger. Cette hypothèse s'est révélée partiellement vraie. Les données publiques peuvent révéler une attaque, mais elles ne l'arrêtent pas. Et une fois que la valeur était à l'intérieur d'un contrat intelligent, il n'y avait pas de caissiers humains pour interrompre le processus.
Une première scène de tension est survenue lorsque les développeurs et les membres de la communauté ont réalisé que l'écoulement n'était pas une activité ordinaire. Les canaux d'analyse en ligne se sont remplis de traces de transactions alors que les participants essayaient de comprendre si le contrat était légitimement séparé ou manipulé de manière malveillante. La pression émotionnelle était immédiate. Si le schéma était un bug, alors des milliards de dollars de confiance sur le marché pouvaient s'évaporer. Si ce n'était pas un bug, alors le DAO fonctionnait comme prévu, ce qui était une possibilité encore plus effrayante car cela signifierait que la conception elle-même avait intégré la vulnérabilité.
Le mensonge au centre de l'opération n'était pas une déclaration fabriquée mais une équivalence falsifiée : que la visibilité publique signifiait sécurité publique. En réalité, la transparence du contrat permettait simplement de voir la violation en temps réel. Le système n'avait pas de rituel quotidien de rapprochement manuel qui aurait pu attraper un exploit de cas limite. Il n'y avait personne à appeler lorsque les hypothèses du code échouaient sous la pression adverse. En ce sens, l'attaque a exposé la plus conséquente illusion du projet : que la confiance pouvait être retirée de la finance sans également retirer le besoin de gestion.
Le fait surprenant, et qui mérite d'être souligné, est que l'exploit n'était pas une intrusion exotique parrainée par un État ou une avancée en cryptographie. C'était une faille logique. Cela aurait dû être réconfortant, car les failles logiques sont compréhensibles. Au lieu de cela, c'était déstabilisant, car cela suggérait que le marché n'avait pas été vaincu par un hacking avancé, mais par un échec de discipline logicielle ordinaire à une échelle extraordinaire. La fascination du public pour la blockchain avait amené de nombreuses personnes à penser que le nouveau système était plus fort que l'ancien. Dans ce cas, il était simplement plus rapide.
Il y avait des quasi-accidents dans un sens plus large. Des préoccupations en matière de sécurité avaient été discutées avant l'attaque, et l'existence de ces avertissements a rendu les conséquences plus amères. Mais dans les heures et les jours suivant l'exploit, il y avait aussi une course pour contenir les dommages réputationnels. La communauté Ethereum devait décider si elle devait préserver la sainteté de la chaîne telle que l'histoire l'avait enregistrée, ou intervenir pour inverser le vol. Cette décision n'a pas été prise par un seul directeur général ou un tribunal. Elle a émergé des développeurs, des mineurs, des échanges, des investisseurs et des arguments publics, c'est-à-dire d'une crise décentralisée sans autorité centrale.
Publiquement, les défenseurs du réseau ont essayé de présenter l'incident comme un événement exceptionnel plutôt qu'un échec structurel. Cette distinction importait car l'avenir d'Ethereum dépendait de la croyance des gens que la chaîne pouvait absorber des chocs. Mais les fissures étaient visibles pour ceux qui prêtaient attention. Un système qui avait promis de la certitude débattait maintenant de la question de savoir si la certitude elle-même pouvait être révisée. Le logiciel avait fait exactement ce pour quoi il avait été codé, et pourtant tout le monde pouvait voir que le résultat était inacceptable.
Dans des post-mortems techniques, l'exploit de réentrance est devenu un cas d'école. En termes de gouvernance, cela devenait bien pire : un référendum sur la question de savoir si le code immuable devait rester immuable lorsque le résultat ressemblait à un vol. La violation avait déjà exposé le mensonge de la sécurité. Ce qui allait suivre exposerait quelque chose de plus profond : qu'une communauté décentralisée doit finalement choisir quelles règles comptent le plus, le code écrit ou le sens humain de la justice qui dit que le code s'est égaré.