Les récents vols de Bitcoins sur différentes plates-formes ont ouvert le débat de la fiabilité de la consistance éventuelle pour le milieu bancaire.
Le 2 mars 2014, Flexcoin a perdu l'intégralité de ses bitcoins à cause d'une faille dans leur code. L'attaquant a envoyé des milliers de requêtes concurrentes pour des demandes de transferts d'un de ses comptes vers un autre. Ensuite, il a répété l'opération avec d'autres comptes jusqu'à avoir épuisé tous les bitcoins. Cela a été possible car le code gérant cette partie n'était pas designé pour gérer correctement la concurrence de multiples requêtes, et tous les transferts ont eu lieu avant que l'équilibre des comptes soit actualisé. Si l'équilibre n'est pas mis à jour dans les temps, une nouvelle requête peut être validée, même si le compte est effectivement vide. Ainsi, Flexcoin a dû fermer après avoir perdu 896 BTC pour une valeur d'un demi-million de dollars.
La même chose s'est passée pour Poloniex 2 jours plus tard, mais ils n'ont perdu que 12.3% de leurs bitcoins et la société a couvert les pertes et réussi à garder la tête hors de l'eau.
Emin Gün Sirer, un professeur associé à l'Université de Cornell, a écrit un article de blog accusant le stockage de données dans des bases à consistance éventuelle d'être responsable des pertes des bitcoins. Il mentionne MongoDB, Cassandra et Riak parmi les solutions NoSQL comme étant vulnérables aux vols bancaires pour les raisons suivantes :
Le problème ici vient de l'interface et de la sémantique erronées par définition de MongoDB. Et la situation aurait été la même si ça avait été Cassandra ou Ria...
Bitcoin coincide avec une période particulièrement sombre pour les systèmes distribués, lorsque les gens armés de leur mauvaise interprétation du théorème CAP, pensaient qu'ils avaient juste à abandonner la cohérence dans leur base de données...
Ce n'est pas clair si Flexcoin ou Poloniex utilisaient MongoDB à ce moment-là, et il est important de mentionner que Sirer est impliqué dans le développement d'HyperDex, un système de stockage clé-valeur qui supporte les transactions ACID. Ce n'est également pas la première fois que Sirer critique le design de MongoDB. Il y a un an, il disait que la tolérance aux failles de MongoDB était cassée.
Si l'on met de côté l'aspect polémique, la question sur le système de stockage à cohérence éventuelle pour les opérations de banque mérite réflexion. Comme on pouvait s'y attendre, l'article de Sirer a déclenché de nombreux commentaires, dont voici quelques-uns des plus parlants.
jrp souligne le fait que la mise à jour aurait pu être réalisée avec MongoDB au niveau de la base de données, de manière atomique, mais admet que “cela ne gérera pas les autres propriétés ACID”.
jakcharlton considère que même si la cohérence éventuelle est problématique dans ce genre de cas, un “système ACID ne résout pas le problème, ça le repousse simplement aux frontières de l'application où il faudra également le gérer. La banque fut un mauvais exemple de domaine à utiliser, et cela montre clairement le problème qui se pose quand les développeurs pensent qu'ils sont à l'abri de la concurrence avec une base de données ACID”.
Alex utilise MongoDB “partout sauf lorsque les transactions sont nécessaires", dans ce cas il utilise "l'outil approprié (qui n'est pas MongoDB)”. Il considère que les développeurs ont fait l'erreur d'utiliser MongoDB pour un travail qui ne lui est pas approprié.
RobertEscriva, un développeur d'HyperDex, considère que le problème ne vient pas des développeurs mais de la croyance générale que l'on peut utiliser des systèmes à consistance éventuelle pour le milieu bancaire :
Le problème ne vient pas de la compréhension des développeurs. Il y a actuellement un mouvement largement répandu et incorrect, qui encourage les gens à utiliser des systèmes à cohérence éventuelle. Ils le justifieront ainsi : "Si cela fonctionne pour les banques, cela fonctionnera pour vous". Un tel courant de pensée est dangereux.
Au bout du compte, votre application est la somme de ses inconnues. Si vos données sous-jacentes sont incapables de vous fournir la moindre garantie - ou pire, si elles nécessitent une attention permanente et un contrat de support à $100 000 pour vous apporter des garanties - alors votre application est incorrecte dès le départ et critiquer les développeurs pour cela n'est qu'une échappatoire. Nous devrions en attendre davantage de nos fournisseurs de base de données (tout particulièrement ceux avec des centaines de millions de capital-risque).
Eric Brewer, auteur du théorème CAP, a écrit plus tôt que les banques ont abandonné la cohérence pour les opérations des ATM au profit d'une disponibilité durant les phases de partition. Mais elles font cela en prenant certaines précautions, entre autre en limitant le seuil de retrait autorisé. Nous pouvons également noter que Stripe, un moyen de paiement sur mobile, utilise MongoDB, selon un article sur leur blog.
La consistance éventuelle est-elle appropriée pour les opérations bancaires ou les développeurs devraient-ils être plus conscients de ses limitations et chercher autre chose ?