La raison pour laquelle je comprends si profondément l’importance réelle de parvenir à un calcul totalement décentralisé tient à une expérience assez particulière qui se cache derrière tout cela. Cette histoire mérite d’être racontée : écoutez-moi, je vais vous la raconter petit à petit.
Dès 2015, je me suis déjà lancé dans le secteur des cryptomonnaies naissantes, tout en continuant à gérer mon propre projet que j’avais créé auparavant, « Fight My Monster » : un jeu MMO (jeu massivement multijoueur en ligne) et une plateforme de réseau social, comptant 3 millions d’utilisateurs, capable de s’autofinancer financièrement, et bénéficiant de levées auprès de fonds d’investissement.
Même si j’ai trouvé ma voie de manière durable dans le domaine du calcul décentralisé, je ne peux pas décevoir la communauté de joueurs qui a toujours soutenu ce jeu.
“Fight My Monster” a été développé entre 2010 et 2012, avec une architecture particulièrement innovante pour l’époque. Cette architecture permettait au système de s’étendre à grande échelle avec un coût faible et une charge d’opérations minimale (c’est-à-dire en accueillant un très grand nombre d’utilisateurs).
Fondamentalement, ce système se compose de trois composants backend essentiels. Le premier est un service web d’hébergement simple, chargé de distribuer le code de jeu frontal et les ressources vers le navigateur web des utilisateurs (à l’époque, j’utilisais un CDN, c’est-à-dire un réseau de diffusion de contenu, très courant).
Comme pour le service d’hébergement web, les deux autres composants backend doivent aussi posséder une capacité de “mise à l’échelle horizontale”. Cela signifie que, pour prendre en charge davantage d’utilisateurs et leurs besoins de calcul et de données, il me suffit d’ajouter des ressources matérielles, sans avoir à réécrire le code logiciel backend, ni à effectuer de tâches fastidieuses de gestion du système. Cette propriété m’a permis, dès le début du projet, de réaliser une expansion à grande échelle avec très peu de personnes et de financement.
Le deuxième composant est un framework de serveur de jeu horizontalement extensible appelé “Starburst”. C’est un travail que j’ai conçu et construit moi-même avec beaucoup d’implication : il repose sur un serveur open source qui prend en charge le protocole RTMP — RTMP est un protocole réseau développé par Adobe permettant que des ressources multimédias Flash exécutées dans un navigateur web communiquent directement avec le serveur (vous souvenez-vous de Flash ?). Starburst porte la logique du jeu et du réseau social, et répartit en quasi temps réel l’énorme quantité d’événements générés dans le jeu vers les utilisateurs.
Le troisième composant est une base de données NoSQL horizontalement extensible appelée Cassandra (si vous suivez l’écosystème des bases de données, vous savez sûrement que l’une de ses versions dérivées modernes, ScyllaDB, se distingue actuellement par d’excellentes performances pour répondre aux besoins d’IA en temps réel).
À noter : dans mon équipe, il y avait en plus du créateur original de Cassandra, le seul autre contributeur principal au code de Cassandra (core committer). De plus, j’étais l’une des premières personnes à avoir réellement déployé la version bêta de Cassandra dans un environnement de production à forte intensité. Quand le nombre d’utilisateurs a atteint 800 000, la base de données s’est corrompue. Les 24 heures qui ont suivi ont été terriblement stressantes : je devais de toute urgence récupérer les données et remettre le système en ligne (à cet instant, j’avais l’impression de foncer vers le cloud ; et une seconde plus tard, je me disais que tout était perdu…… Heureusement, finalement, ça s’est bien terminé).
Ce qui est le plus remarquable avec Cassandra, c’est que vous pouvez ajouter directement des nœuds (c’est-à-dire des serveurs équipés de disques durs de grande capacité) pour étendre horizontalement la capacité de stockage, le débit de lecture et — le plus important — le débit d’écriture. C’est une caractéristique très rare, mais essentielle pour mon application, car “Fight My Monster” génère une quantité massive de données.
Bien sûr, l’un des autres grands avantages de Cassandra est aussi sa tolérance aux pannes. J’avais configuré 5 réplicas (facteur de réplication = 5). Cela signifie que les données de chacun sont extrêmement sûres (du moins, c’est ce que je pensais à l’époque……). Avec 5 réplicas, pour n’importe quel quorum de données donné, tant que 3 nœuds sont en ligne, le système peut écrire les données normalement.
Contrairement à la blockchain, Cassandra ne dispose pas d’une tolérance aux pannes byzantines. Cela signifie que je dois gérer de manière très rigoureuse la sécurité de l’infrastructure pour empêcher des pirates ou des logiciels malveillants de s’infiltrer. Or, à l’époque, les pirates ne s’intéressaient pas à un MMO dont le public principal sont des enfants, associé à un réseau social, et ce n’était pas non plus une plateforme généraliste sur laquelle d’autres pourraient construire des applications.
Je fais face à une pression technique majeure : comme le volume de génération de données est énorme, les nœuds qui portent la base de données subissent une charge extrêmement élevée, si bien qu’ils “s’effondrent” très souvent ! Concrètement, cela signifie que je dois me connecter de temps en temps à l’infrastructure, mettre hors service les nœuds défaillants et ajouter de nouveaux nœuds. Heureusement, l’opération n’est pas difficile : grâce aux mécanismes de tolérance aux pannes, ce travail n’a pas besoin d’être fait de toute urgence, et ces serveurs “bare metal” peuvent aussi être planifiés de manière unifiée par mon fournisseur de services cloud……
“Fight My Monster” s’appuie sur une architecture en avance sur son époque, ce qui me permet d’implémenter facilement l’évolutivité. De plus, sa tolérance aux pannes et son backend simple, composé uniquement de 3 composants systèmes essentiels, signifient que la charge et le travail de gestion nécessaires pour faire tourner le système sont réduits au minimum. Alors, quelle leçon est-ce donc, si importante qu’elle continue à façonner ma manière de penser et le développement de l’ICP ? Vous avez sûrement l’impression qu’il s’est passé quelque chose d’inhabituel à ce moment-là : désormais, je vais raconter pour la première fois publiquement cette histoire.
À l’époque, je circulais partout en Asie. En tant que membre de l’“équipe en tournée” de la communauté core Ethereum, en période très précoce, je rendais visite aux acteurs concernés (les gens sous-estiment souvent le rôle déterminant joué par l’Asie — en particulier la Chine — dans le développement du secteur des cryptomonnaies à ses débuts) et je participais à toutes sortes d’événements liés à Ethereum. Lors de ces occasions, je me concentrais surtout sur des techniques complexes d’informatique que j’avais moi-même développées, afin d’améliorer l’évolutivité et les performances de réseaux comme Bitcoin et Ethereum.
Je ne veux pas m’étendre longuement sur les “vieilles années” dans le secteur des cryptomonnaies, mais je dois dire que c’était un moment magique. Les premiers participants m’ont laissé beaucoup de souvenirs précieux, et je leur en suis profondément reconnaissant. Cette expérience était tellement captivante que je n’avais même pas le temps de regarder mes e-mails.
Au final, pendant mon voyage, j’ai manqué d’innombrables e-mails — tous m’avertissant que : la carte bancaire utilisée pour payer les frais des nœuds Cassandra du projet Fight My Monster avait expiré……
Alors, que fait le fournisseur de cloud quand je ne réponds pas pendant quelques semaines (je ne me souviens plus de la date exacte, mais ce n’était pas long) ? C’est très simple : ils ont tout simplement supprimé tous les nœuds !!!
Difficile de décrire ce que j’ai ressenti lorsque je suis revenu à Palo Alto, en Californie, et que j’ai découvert tout cela. C’était un mélange de choc et d’effroi : l’estomac vide, l’adrénaline qui monte, la peur qui se propage sans cesse. J’ai tenté de sauver les choses en toute urgence, mais j’ai fini par confirmer que tout était irréparable. Ceux qui ont déjà subi des attaques de hackers dans le secteur des cryptomonnaies doivent sûrement comprendre ce sentiment.
Et puis, tout s’est terminé ainsi : Fight My Monster a complètement disparu. Dans la communauté, certains ont même lancé une pétition sur Change.org, demandant qu’il soit remis en ligne.
Même si j’ai perdu la valeur qu’elle aurait pu créer, je ressens aussi une certaine culpabilité. Mais, d’une certaine façon, cela me procure aussi un sentiment de soulagement : je n’ai plus à porter la responsabilité de sa maintenance (sinon, j’aurais pu me mettre à la maintenir sans fin pour la communauté). En plus, elle est devenue un joli souvenir pour une génération d’enfants (et pour certains adultes) qui ont joué à ce jeu, et elle s’est éteinte avant de devenir vieille et ennuyeuse. Tout cela m’a permis de me recentrer sur le domaine qui me passionnait alors : les réseaux informatiques décentralisés.
Cependant, j’en ai tiré une leçon extrêmement profonde : vous pouvez construire une infrastructure informatique décentralisée dotée d’évolutivité et de tolérance aux pannes, mais si, à un moment donné, il existe un point de défaillance unique dans n’importe quelle partie du système, l’ensemble peut s’effondrer complètement.
C’est précisément pour cela que, lorsque j’entends parler de certaines blockchains qui s’appuient sur des clés d’administrateur détenues par des développeurs principaux, ou lorsque j’apprends que d’énormes quantités de nœuds sont mis hors ligne parce que des fournisseurs de cloud les coupent ou à cause de pannes techniques (voire qu’ils sont à deux doigts d’être totalement paralysés), je m’inquiète toujours. Ces problèmes d’une fragilité extrême sont, dans notre secteur, bien plus fréquents que vous ne l’imaginez.
Les leçons tirées de l’épisode douloureux de Fight My Monster ont profondément influencé la conception de l’Internet Computer. Ce n’est pas uniquement la quantité de nœuds qui compte, mais aussi d’autres facteurs, plus critiques encore. Si les nœuds sont anonymes, le nombre réel d’entités indépendantes qui font tourner la majorité des nœuds peut être bien inférieur à ce que vous imaginez. En outre, malgré l’ampleur du parc de nœuds, ils fonctionnent souvent sur les plateformes de quelques fournisseurs de cloud seulement : même si ces nœuds appartiennent et sont opérés par différentes entités, le fournisseur de cloud peut décider soudain de ne plus les prendre en charge et les fermer du jour au lendemain (comme Hetzner l’a fait pour un projet blockchain bien connu).
En pratique, ce qui compte vraiment, ce n’est pas seulement le nombre de nœuds, mais le nombre d’entités indépendantes qui les font tourner, ainsi que leur indépendance en termes de localisation physique et de juridiction. Cette simple observation constitue l’une des bases de l’idée de “décentralisation déterministe” (deterministic decentralization), qui se traduira sous une forme totalement nouvelle dans les fonctionnalités d’extension à venir de l’Internet Computer : les “moteurs cloud ICP” (ICP cloud engines).
Les moteurs cloud ICP permettent aux entreprises (dans la plupart des cas) de créer des sous-réseaux d’Internet Computer qui leur appartiennent effectivement, et de contrôler elles-mêmes leur configuration. Les entreprises peuvent composer leur configuration en sélectionnant des nœuds parmi un pool de nœuds jouant le rôle de “marché”. À l’heure actuelle, plus de 1500 nœuds sont en attente et le nombre continue d’augmenter.
“L’Engine” offre une plateforme cloud serverless dotée de caractéristiques exceptionnelles. C’est un environnement idéal pour construire des applications et des services d’IA, car sa pile technologique est conçue pour permettre la génération aisée d’applications avancées d’AIware. Ces applications AIware sont à la fois sûres et dotées d’une grande résilience.
Ces applications offrent de nombreuses caractéristiques : résistance à la falsification (protection contre les attaques de hackers au niveau de l’infrastructure), disponibilité 24h/24 et 7j/7 (ce qui leur confère une grande résilience), exécution autonome optionnelle (ce qui signifie qu’il n’y a pas de porte dérobée), prise en charge native des actifs numériques, etc. Le moteur peut aussi exécuter des applications AIware telles que la suite Open SaaS, et permettre aux entreprises d’assurer des opérations métier de bout en bout. Grâce aux moteurs cloud, l’installation et la maintenance d’applications complexes comme Open CRM ou Open Email deviennent aussi simples que des applications mobiles.
Les nœuds prennent en charge le hot-plug, ce qui signifie que vous pouvez ajuster le facteur de réplication des calculs (compute replication factor) ou remplacer des nœuds sans interrompre les services hébergés par le moteur cloud. Vous vous libérez ainsi de la dépendance à un fournisseur de calcul spécifique. En outre, vous pouvez choisir d’utiliser de nouveaux types de nœuds déployés chez des hyperscalers, ainsi que des nœuds traditionnels de l’Internet Computer, ce qui en fait un marché général des ressources informatiques.
Le framework des moteurs cloud (Cloud Engine) guide les utilisateurs pour composer des nœuds offrant une indépendance, tout en offrant une flexibilité que le hébergement partagé de l’Internet Computer n’apporte pas. Par exemple, une entreprise allemande peut choisir de ne placer que des nœuds situés à l’intérieur de l’Union européenne, pour satisfaire aux exigences du RGPD (Règlement général sur la protection des données).
Cependant, la console de gestion des moteurs cloud autonomes, hébergés par le réseau Internet Computer et mise à jour par le NNS (le Network Nervous System, autrement dit le DAO le plus avancé au monde), orientera les utilisateurs : si un utilisateur assemble des nœuds provenant d’un même fournisseur de nœuds, situés dans le même centre de données ou opérés par le même opérateur cloud, la console émettra des avertissements très forts.
Ainsi, même dans le contexte des moteurs cloud ICP (Cloud Engines), les leçons tirées du projet “Fight My Monster” restent pleinement pertinentes.
On pourrait se demander pourquoi ce framework pousse avec autant de force à combiner des nœuds indépendants. En réalité, il y a une raison solide derrière cela — une raison qui, pour la communauté blockchain plus large d’aujourd’hui, est aussi importante qu’elle l’était en 2015.
J’ai hâte de partager bientôt avec vous des informations sur les moteurs cloud.
Le contenu IC qui vous intéresse
Avancées techniques | Informations sur le projet | Événements mondiaux
Suivre et mettre en favori la chaîne IC de Binance
Accéder aux dernières actualités