Vous le savez sans doute déjà, la DAO #TheDAO comme nommée par Slock.it, traverse une épreuve inattendue. Un utilisateur de la DAO initiée par Slock.it a utilisé une boucle très maligne dans le contrat, couplée à une autre boucle maligne qui permis à l’attaquant de s’envoyer des ethers de façon répétée lors d’un dao split.
Le but intentionnel de la méthode de splitting de la DAO était de permettre à quiconque désirant céder ses jetons DAO de le faire par la création d’une child DAO, de s’en faire le seul curateur, et de white-lister son adresse pour enfin créer une proposition pour retirer ses propres fonds. Une stratégie assez lourde, mais peu importe. Le problème est que l’attaquant a retiré ses fonds sur un contrat spécial qui possédait une fonction par défaut qui entrait à nouveau dans #TheDAO pour répéter le retrait une infinité de fois. Cela n’aurait pas posé de problème si la balance n’était pas rafraichie APRES la fin d’exécution de la fonction d’envoie, ce qui permet à l’attaquant de complètement siphonner #TheDAO.
Cet évènement a déclenché un grand débat sur la manière d’appréhender l’attaquant, mais ce qui nous intéresse ici n’est pas de savoir comment réagir, mais plutôt comment éviter à la base que cela ne se produise. La portée de l’attaque et les dommages auraient pus être énormément diminués en utilisant les méthodes expliquées dans le Expanse Whitepaper.
Deux mots: compartimentation et limites
La DAO Expanse, comme décrit dans le Whitepaper, est un système de divisions parent/enfants qui sont complètement isolées les unes des autres. Plus simplement, il existe une division mère qui possède 3 divisions enfants. Nous avons temporairement nommé ces divisions [Division Fondateurs], [Division Communauté], [Division du Conseil d’Administration]. Chaque division enfant a la possibilité de soumettre une demande de prestation à la division mère. Une demande de prestation peut être accordée à la division enfant qui la demande seulement si 2 des 3 divisions enfants autorisent cette demande.
Mais alors comment cela aurait-il pu éviter à #TheDAO d’être pillée? C’est simple.
Exemple: Mettons qu’un acteur néfaste créé une proposition de dépense avec la « Division du Collectif ». La « Division du Collectif » est un smart contract par démocratie directe possédant une réserve de $1 000 000. Un participant soumet ensuite une requête de dépense, mais ayant connaissance d’une boucle de dépense lui permettant de recevoir plus qu’il ne devrait, il siphonne le collectif de ses $1m.
C’est un évènement tragique, la communauté vient de perdre $1m. Le Collectif est maintenant ruiné, et aucunes des autres demandes de prestation ne peuvent alors être financées. La seule manière pour cette division d’obtenir de nouveaux financements est d’effectuer une demande de prestation auprès de la division mère que les autres divisions enfants accepteraient. Mais pourquoi dépenseraient-ils encore plus? Ce contrat est intrinsèquement faillible. Le Whitepaper met également en évidence la nécessité d’une capacité de mise-à-jour, afin qu’un contrat puisse remplacer sa version désuète par un code amélioré. C’est l’évolution des versions d’un contrat, mais nous conservons ce sujet pour un autre post plus tard.
Nous avons parlé de la compartimentation, parlons maintenant des limites.
Imaginez maintenant qu’un acteur néfaste extorque des fonds à la DAO et réussit on ne sait comment à contrôler l’une ou les deux autres divisions enfants. Il peut donc passer seul et à loisir des demandes de prestation. Cela semble être le pire scénario, et ce serait effectivement assez terrible. Mais la DAO Expanse aura des sécurités intégrées sous la forme de limites à la fois dans le temps et dans les montants. Premièrement, une division enfant ne peut émettre qu’une seule demande par mois à la division mère, comme déterminé par le nombre de blocks mensuel, et deuxièmement cela ne peut se faire qu’à un taux max limité par un certain pourcentage du total des fonds de sa division mère. Ainsi, chaque fois qu’une division enfant se voit accorder une demande, elle diminue également le montant maximum qu’elle pourrait recevoir la fois suivante. Cela ajoute des éléments tampons qui laissent à la communauté le temps de réagir sans avoir à faire de softfork, hardfork, et autres spoonforks peu commodes.
En conclusion, nous ne pouvons pas prédire le futur, mais nous pouvons essayer de mettre en place le code le plus sûr et le mieux pensé possible. Avec une planification méticuleuse et en mettant en œuvre des sécurités intégrées comme la compartimentation et les contraintes de limites, nous augmentons nos chances de parer avec succès des comportements indésirables qui pourraient compromettre nos projets et ce que nous défendons.