iEx.ec est à suivre de près. À l’issue de la Devcon pendant laquelle le projet a reçu un accueil chaleureux, Gilles Fedak, chercheur à l’INRIA et fondateur d’iExec, nous présente le projet ainsi que sa vision du cloud distribué basé sur la blockchain. iEx.ec ambitionne de devenir le « Airbnb du serveur » et s’en donne visiblement les moyens.
Pourrais-tu nous expliquer comment fonctionne iEx.ec ?
Le nom vient de « I execute » en anglais qui évoque une fonction en script shell pour lancer un processus. Ce qu’on essaie de faire, c’est un cloud distribué basé sur la blockchain. Le principe de base, c’est d’utiliser la blockchain d’Ethereum pour construire une place de marché de la ressource informatique. La façon la plus simple de le représenter c’est le « Airbnb du serveur ». Sur cette place de marché, on peut mettre des ressources de calculs, de stockage, d’applications, de services. Ça c’est à long terme, au début on va plutôt se concentrer à ce qu’on sait bien faire.
Ce qu’on sait bien faire, c’est surtout du calcul applicatif. On déploie des smart contracts sur la blockchain qui décrivent ces différentes entités, et on peut choisir des applications, une ou plusieurs ressources de calcul, plusieurs données et lorsqu’on a payé, on lance l’exécution de ces tâches ou de ces sacs de tâches. iEx.ec s’occupe de tout : réserver les machines, déployer les applis, transférer les données, exécuter les tâches et rapatrier les résultats.
Comment est né le projet ?
L’idée originale vient de mon sujet de thèse, un système qui s’appelle XtremWeb, une plateforme globale pair-à-pair de calcul. Le principe qu’on appelle Desktop Grid est d’utiliser des machines réparties sur Internet pendant leur temps d’inactivité pour exécuter des applications massivement parallèles. On a une version en « prod » qui est développée et maintenue par Oleg Lodygensky de l’IN2P3. C’est le projet XtremWeb-HEP pour « High Energy Physics ».
En terme de recherche, ce qu’il faut comprendre c’est que faire du calcul sur du desktop permet de faire émerger toute une série de problématiques qui étaient un peu exotiques à l’époque où on a commencé (j’ai commencé ma thèse en 1999) et qui sont devenues normales maintenant.
L’exemple typique, c’est les pannes. Il y a 15 ans, on avait des machines qui n’étaient pas de très grandes tailles (200-300 nœuds), une panne était un événement rare qui arrivait de temps en temps. Aujourd’hui, la machine numéro un du top 500 (dans les supercalculateurs) a dix millions de cœurs, donc une panne c’est un événement tout à fait normal et fréquent. Dans la conception des systèmes, il faut prendre en compte la tolérance aux pannes. Il y a toute une série de thématiques comme ça dans les desktop grids qui en fait sont des thématiques courantes, il y a même des choses qui rejoignent les problématiques de la blockchain.
Par exemple dans la blockchain, il y a le problème de savoir si quelqu’un n’est pas en train de tricher avec un transaction, c’est ce qu’on appelle les fautes byzantines. Une faute byzantine est difficile à détecter parce qu’on a l’impression que le calcul se déroule normalement. Tu as un résultat pour ton calcul mais ton résultat est faux parce qu’il y a eu une petite erreur. Dans les machines à dix millions de cœurs, ce sont des choses qui arrivent, non pas parce que les cœurs trichent, mais parce qu’il peut y avoir un petit rayon cosmique qui vient taper un bit de la mémoire. Des erreurs comme ça qui normalement arrivent très peu, à dix millions de cœurs, peuvent se produire.
D’un point de vue recherche, on veut montrer qu’on peut faire du calcul parallèle sur Internet. D’un point de vue techno, il y a un gros intérêt parce qu’il devient facile d’assembler des infrastructures en prenant des machines réparties sur Internet, dans des réseaux locaux, dans des data-centers de façon hyper simple, sans configuration, avec de la sécurité, de la tolérance aux pannes, de la virtualisation, de la certification de résultat, etc.
On adresse également les problèmes de gaspillage, c’est-à-dire la façon de réutiliser les ressources qui sont inutilisées. Pour ça, ces technos de Desktop Grid sont vraiment idéales. Et quand on fait rencontrer cette techno avec la blockchain… c’était vraiment le chaînon manquant : c’est une techno peer-to-peer donc elle nous intéresse, elle donne du consensus et c’est très intéressant parce que jusqu’à présent c’était très difficile de faire des middlewares pour ce type d’infra qui soient serverless.
Oui parce que tu es tout de suite un tiers de confiance…
Oui, avant on se mettait en tiers de confiance entre les demandes et les offres de ressources. Maintenant, grâce à la blockchain ces interactions peuvent se faire en P2P. Donc, il y beaucoup de fonctionnalités pour lesquelles on utilisait des serveurs qu’on va pouvoir faire tourner de façon autonome et résiliente sur la blockchain via des smarts contracts. C’est pas forcément un truc qu’on va vouloir faire tout de suite. Pour l’instant on essaie d’abord de rendre disponible ce qu’on sait bien faire à la blockchain et on verra après comment faire évoluer l’architecture des logiciels, c’est pas le plus important pour nous actuellement.
L’idée c’est de faire se rencontrer ces deux technos pour faire iEx.ec. Notre originalité, c’est de donner un point de vue « infrastructure » à la blockchain. Par exemple, à la Devcon, c’était très orienté développeur. C’est bien, mais il n’y avait rien sur l’infrastructure, on a rien entendu sur les mineurs. Pourtant, les mineurs ça compte. Il y a un côté un peu étonnant là-dedans. On ne cherche pas à faire du mining, c’est très différent de ce qu’on fait. De quelles infrastructures auront besoin les applications qui vont s’exécuter sur la blockchain ? Et quelle est l’infrastructure immédiatement disponible pour elles ? Quand tu exécutes une application distribuée sur Ethereum, en fait il y a un gros problème qu’on met un petit peu sous le tapis : le stockage coûte très cher.
Dans les solutions de stockage pour les applis décentralisées, il y a des projets comme IPFS ou Swarm, comment iEx.ec se démarque de ce type de stockage ? C’est deux types de stockage différents, n’est-ce pas ?
Oui, c’est une très bonne question. Nous, il y a un truc qu’on ne fera jamais c’est le stockage, j’appelle ça « stockage » pour simplifier. En tous cas, il y a peu de chances qu’on le fasse à la StorJ, Swarm ou IPFS. Ce que j’appelle stockage, c’est « rendre disponible à tout moment une donnée ». Par contre pour nous ce qui est super important, c’est de pouvoir accéder à une donnée (par exemple stockée sur StorJ, Dropbox, Amazon S3 et d’autres), la transférer jusqu’à une place où on va avoir lieu le calcul, typiquement sur l’infrastructure iEx.ec, exécuter le calcul et renvoyer ce résultat vers du Swarm, IPFS, etc. Le consensus va jusqu’au transfert de la donnée, pas plus loin.
Notre problématique est un petit peu différente du stockage : quand tu veux faire du calcul, là où sont les données, c’est important. Une fois que tu as placé ta donnée dans l’infrastructure iEx.ec, c’est-à-dire sur les workers iEx.ec qui vont nous permettre d’exécuter des applications, il faut pouvoir la contrôler. Si tu as ponctuellement des choses un peu data intense, avec de grands volumes de données, tu n’as pas envie qu’elles soient éparpillées n’importe où. Tu veux qu’elles restent plus ou moins proches les unes des autres, par exemple quand tu as besoin de communication ou bien de réutiliser des données qui ont déjà été placées. C’est des choses qu’on sait très bien faire. On utilise un logiciel qui s’appelle BitDew. On sait donner des directives de placement des données. C’est le genre de chose que Storj ou Swarm ne font pas : pour eux pour eux c’est transparent, c’est « J’envoie mes données dans du stockage ». Le stockage est fait par un ensemble de noeuds distribués sur Internet, mais « je ne suis pas capable précisément de dire comment est-ce que je vais distribuer et comment je vais redistribuer ». Par exemple si je mets des patterns de communication un peu particulier comme on utilise dans quelques calculs parallèles, ça ils ne savent pas le faire, d’ailleurs ils n’ont pas besoin de le faire. Alors que pour nous, c’est indispensable.
Peux-tu nous parler des cas d’utilisations d’iExe.ec ?
À court terme, on veut être immédiatement utilisable. C’est notre chemin critique. Toute application qui a envie de s’exécuter sur Ethereum et qui à un moment est coincée parce qu’une partie de l’algo coûte trop cher à exécuter sur Ethereum ou parce que la donnée est trop grosse pour être stockée sur Ethereum, c’est à celles-là qu’on veut s’adresser immédiatement.
L’exemple typique c’était le post de blog qu’il y avait eu sur le jeu d’échec : le développeur porte un jeu d’échec sur Ethereum, il y a toute une partie facile : je décris mon jeu, mon échiquier, mes coups en termes de smart contract, j’ai une fonction qui permet de déterminer si la partie d’échec se termine, il peut y avoir pat ou mat. Je veux faire ça sur Ethereum, et d’un seul coup patatraque : l’exécution me coûte beaucoup trop cher. Dans cet exemple, il met sa fonction dans iEx.ec sous forme d’application, il appelle un petit smart contract d’utilisation d’une ressource, on lui donne les paramètres et il récupère le résultat à partir d’un smart contract. Finalement, c’est du RPC asynchrone.
Et ensuite il peut continuer et ça lui coûte moins cher, mais surtout il peut le faire. Pour l’instant on là est en premier lieu pour permettre à un plus grand spectre d’applications de s’exécuter sur la blockchain.
Et à plus long terme ?
À plus long terme, on parle d’une échéance d’un ou deux ans, l’objectif c’est qu’on ait vraiment une infrastructure avec des machines, une API bien claire au niveau des smart contracts qu’ils puissent faire ça. Et puis ce que je pense fondamentalement c’est que cette infrastructure va être très différente des infrastructures de cloud qu’on a maintenant. Actuellement, les infrastructures de cloud sont extrêmement centralisées, et il y a plein de problèmes associés. Grâce à la blockchain on peut faire émerger un nouveau type d’infrastructure qui sera beaucoup plus efficace pour toute une série d’applications pour lesquelles on sait dès maintenant que les clouds centralisés ne seront pas efficaces, notamment pour tout ce qui est IoT, smart cities, et ce genre de choses. Par exemple dans l’IoT, est-ce qu’on a envie que tous les flux d’informations retourne vers des data centers centralisés ? A priori, non. Donc, à plus long terme le cloud décentralisé sera plus efficace énergétiquement, les données sont plus proches des utilisateurs et des consommateurs. Donc ce qu’on peut imaginer c’est que, par conséquence, il y aura des applications qui viendront sur la blockchain pour avoir accès à ce cloud décentralisé. Le cloud décentralisé sans la blockchain, je n’y crois pas.
Plusieurs startups françaises commencent à proposer des produits qui préfigurent le Cloud décentralisé, je pense à Qarnot Computing ou Stimergy notamment. Sans la blockchain, ils ne peuvent pas arriver à faire émerger une infrastructure face à Amazon ou OVH. On peut aussi aller vers des choses beaucoup plus agressives. Dans le cloud décentralisé, tu peux mettre ta Free Box, ton laptop ou d’autres choses comme ça.
Il faut bien comprendre que ce n’est pas une problématique uniquement pour le Cloud, c’est la même problématique pour la production de l’électricité par exemple. On est sur les mêmes schémas de production décentralisée à l’échelle d’un bâtiment et d’échanges entre bâtiments via la blockchain.
Justement, quel est l’intérêt pour un serveur ou data center de vous faire une place ?
La première chose que veulent les data centers, c’est augmenter le taux d’utilisation. Or, pour l’instant, on ne peut accéder aux ressources d’OVH que si on est client d’OVH directement. Via la blockchain, tu peux avoir les ressources inutilisées de tout le monde, puisque c’est une place de marché unique. Ensuite on discute avec les mineurs Ethereum. Par exemple on a un très bon contact avec Marco Streng de Genesis Mining. Leur machine Enigma a plus de 10 000 GPUs ; c’est une facture électrique de plusieurs millions par mois sur l’ensemble de leurs fermes de mining. Ils prennent un risque financier important, il peut se passer tout et n’importe quoi sur Ethereum du jour au lendemain. Et la difficulté de minage augmente exponentiellement. Donc ils ont probablement envie de mitiger le risque d’utilisation de leur infrastructure et de s’offrir d’autres débouchés peut-être même à haute valeur ajoutée.
Même ponctuellement ?
Oui, de toute façon, ils font du cloud mining, c’est-à-dire qu’ils louent leur infrastructure à des clients qui minent pour eux-mêmes. Donc ils pourraient facilement passer à du cloud rendering ou du cloud deep learning puisque iEx.ec permet de déployer facilement de nouvelles applications. Quelque part, on rend cette puissance de calcul aux applications et pas uniquement à la maintenance de la blockchain.
Et il y a un troisième type de ressource que j’aimerais faire émerger, parce que j’y crois très fort et que je trouve l’idée un peu délirante. La conclusion que j’avais donnée à la Devcon, ce serait d’être capable de faire des mineurs iEx.ec à énergie positive, un mineur qui produirait plus d’énergie qu’il en consomme. Ca ressemblerait à petit panneau solaire, une batterie, et un noeud à base de rapsberry. On a un collègue de l’Université de Tunis, Heithem Abbes qui a commencé à travailler sur ce sujet. En plus, il fait beau en Tunisie…
Pour du Proof-of-Work classique, ça n’a aucun intérêt. Par contre dans le cas d’iEx.ec, ça a vraiment du sens : si tu veux hoster un petit service qui consomme pas énormément de temps CPU. Un service Web, ou par exemple la fonction de terminaison du jeu d’échec dont on parlait.
Ca veut aussi dire que, par rapport à un Cloud centralisé, je ne paie plus les serveurs, je ne paie plus la maintenance, les locaux, je ne paie plus la facture d’électricité. On peut vraiment avoir des prix agressifs par rapport à Amazon.
Quel est votre business modèle ?
À la base, on a envie d’être un pure player blockchain, c’est-à-dire que ce qu’on ne veut pas « rendre payant le HPC par la blockchain ». On veut s’adresser d’abord aux applications blockchain et partir sur du consensus d’exécution off-chain. Ça c’est une des « values » propositions de base. C’est ce qu’on appelle le Proof-of-Contribution qui porte sur l’exécution de la fonction et sur le transfert des données. Ça s’affinera par la suite mais c’est le début.
Qui dit Proof-of-Contribution dit consensus. Qui dit consensus dit token pour le réaliser. Ce qui est assez unique dans ces problématiques de blockchain c’est les notions d’incentive : c’est l’algo de consensus et comment le consensus est rétribué qui vont avoir un énorme impact sur la façon dont l’infrastructure va se construire.
L’incentive a vraiment un impact direct sur toute l’économie qu’il y aura derrière. Donc c’est à nous de trouver les bons incentives pour que le cloud décentralisé s’établisse selon nos perspectives. C’est pas nous qui allons investir dans des panneaux solaires, par contre il va falloir qu’on construise les bons consensus et la bonne rémunération du consensus pour arriver in fine à favoriser des mineurs à très faible coût d’opération. C’est une démarche qui est assez neuve et on n’est pas forcément habitué à raisonner sur ces critères. Sur les deux ans qui viennent, il va falloir faire du tuning pour trouver les bons paramètres et les bons leviers. Mais tout ça ne fait pas un business modèle, ce n’est pas ça qui va nous faire vivre.
Si on arrive à mettre ça en place, on sera comme une sorte de « Docker + OVH » du cloud distribué pour la blockchain. Typiquement, il y aura un mode d’utilisation qui sera gratuit pour lequel on n’intervient pas. On déploie les smart contracts pour la place de marché, on crée les logiciels qui permettent de faire fonctionner l’infrastructure, et les gens échangeront entre eux les ressources. Ça va te donner un certain niveau de confiance, un certain niveau de qualité de service.
Du point de vue business, il y a deux choses cruciales : ce sont les notions de confiance et de qualité de service. Je ne crois pas du tout à une infrastructure qui serait entièrement ouverte pour tout le monde. J’ai rencontré beaucoup d’entreprises, depuis 2012 lorsqu’on a obtenu un financement de l’ANR (Agence Nationale pour la Recherche) qui avait financé une action de transfert technologique. Pour beaucoup d’entreprises, surtout des PME innovantes, il faut des réponses très claires à la question : « où vont mes données ? ». Pour eux c’est une évidence, je n’envoie pas mes données n’importe où. À partir du moment où quelqu’un va dire « Je veux que mes données aillent uniquement chez les acteurs en qui iEx.ec a confiance », là il n’y a pas de raisons de ne pas faire payer ce service. Confiance et la qualité de service. La qualité de service, c’est par exemple « Je veux être sûr que mon calcul soit rendu en moins de 24h ». C’est la base pour faire du service payant.
Quelles sont les prochaines étapes pour vous ?
On finalise le white paper. La rédaction a commencé en juillet et on voulait attendre la fin de la Devcon où j’ai beaucoup appris. On se donne quelques semaines pour le terminer. Ensuite on a un rendez-vous important à Super Computing qui est la grand-messe des professionnels du cloud, du High Performance Computing et du Big Data. À SC, a lieu le « top 500 », c’est-à-dire le classement des plus grosses machines au monde. On espère aller là-bas avec des mineurs et voir si l’infrastructure des mineurs a du sens pour les gens qui font du super computing. C’est intéressant parce qu’on va présenter une démo qui va permettre de valider un certain nombre d’hypothèses. La démo devra orchestrer via la blockchain des fournisseurs d’applications qui se décrivent elles-mêmes via des smart contracts sur la blockchain. On pense à une application type analyse financière, où il y a souvent du machine learning, donc une grosse consommation en puissance de calcul. On aimerait avoir un fournisseur de données comme Kaiko qui fournit des données sur les historiques de cours de crypto-monnaies pour les principales plateformes d’échanges. Et puis des fournisseurs de ressources, on a un partenariat avec Stimergy, et on a aussi envie de travailler avec des mineurs comme Genesis Computing. iEx.ec est au milieu de ces acteurs pour orchestrer tout ça.
On n’arrivera pas une solution parfaite, finalisée et ouverte au public mais au moins un prototype pour comprendre où sont les difficultés, essayé de montrer ce qui a du sens d’un point de vue écosystème économique.
Après SC, si tout se passe bien, on va chercher à se financer via une « ICO » vente collaborative de token. On n’a pas encore de date à annoncer mais on vise fin 2016. On pense qu’on a un positionnement assez unique. Par rapport à Golem, il y a toute une partie qu’ils font que nous on connaît très bien depuis très longtemps donc ça nous permet, nous, de nous focaliser vraiment sur la partie blockchain et justement de se détacher un peu cette partie HPC.
Comment s’est passée la Devcon pour vous ?
La Devcon, c’était super. Je m’intéresse à Ethereum depuis l’arrivée du white paper. J’avais commencé vraiment à jouer avec en novembre dernier. Après honnêtement, j’ai un peu laissé tomber l’écriture de smart contracts (sûrement à tort) mais je me suis intéressé au côté conceptuel, j’ai fait un gros état de l’art sur la blockchain. Donc à la Devcon, je n’arrivais pas en expert du domaine. On a eu un très très bon feedback sur ce qu’on propose. L’expérience sur les infrastructures distribuées (Cloud, Grid, HPC) peut apporter beaucoup et j’ai eu l’impression que certains commencent à se poser la question de l’infrastructure.
J’ai vu beaucoup de gens qui étaient vraiment très intéressés. Ça nous a permis de valider plein de choses. Et puis après bon, en tant que conférencier, j’ai fais pas mal de conférence scientifiques et là j’ai trouvé que c’était franchement génial. On a discuté avec plein de gens, j’ai appris énormément. Le seul truc qu’on peut regretter, c’est de ne pas avoir ce don d’ubiquité pour à la fois assister aux talks mais en même temps discuter dans les traverses.
On a eu aussi un super accueil de la part de la communauté française, d’ailleurs je les remercie encore une fois, ils nous ont vraiment beaucoup soutenus, ils nous ont beaucoup aidés, ils ont été vraiment géniaux. Je le pense très sincèrement et j’espère que j’arriverais à rendre à la communauté.
On a eu aussi beaucoup de contacts côté chinois. Mon partenaire, Haiwu He est francochinois et il est actuellement professeur à l’Académie des Sciences à Pékin. Haiwu s’est bien intégré dans la communauté blockchain. Ils fonctionnent différemment que nous avec moins scrupules à tout mélanger : une association, c’est aussi un lieu où trouver des investisseurs. Il y a peut-être des choses à apprendre à ce niveau-là.
On a eu pas mal de contacts notamment avec l’association DACA à Pékin, Digital Asset Chinese Association. DACA fédère les différentes places de marché, BTC Trade, Yun Bao, des mineurs, des traders, des investisseurs, des développeurs, des médias blockchain. Ils ont un programme de formation qui s’appelle « We are Satoshi Nakamoto ». On va essayer de faire venir le président, Mr Han en France et de lui faire rencontrer ChainTech pour qu’il y ait des contacts de bon niveau qui s’établissent, et avec d’autres associations éventuellement.
On va essayer de créer des liens entre les deux communautés en tirant partie de notre position privilégiée, puisqu’on est franco-chinois. S’il y a des gens qui ont envie de nous rejoindre, ils ne doivent pas hésiter. C’est ouvert. Il ne faut surtout pas qu’on soit LE lien, il faut qu’on aide à créer des liens entre la France et la Chine. On serait très heureux de contribuer à ça.
Interview réalisée par Julien Béranger qui travaille sur les aspects adoption et vulgarisation des crypto-monnaies depuis avril 2013 et développe actuellement le projet Abie Fund, une DAO à but non-lucratif à destination des associations et ONG.
