Interview approfondi de Spike OS : donner des super-pouvoirs aux applications Web3, la feuille de route et la détermination du héros caché
TechFlow SélectionTechFlow Sélection
Interview approfondi de Spike OS : donner des super-pouvoirs aux applications Web3, la feuille de route et la détermination du héros caché
Spike OS, un « L3 » modulaire et multi-chaînes pour les applications Wab3.
Dédié à des analyses Web3 approfondies
Le marché de la cryptomonnaie connaît des hauts et des bas, et le « dépassement d'audience » reste un sujet à discuter. Aujourd'hui, les applications Web3 brillent souvent brièvement sur les marchés financiers, mais peinent encore à attirer un usage réel parmi les utilisateurs extérieurs à l'écosystème. Pour chaque effort infructueux, il existe autant de traitements inadaptés.
Où se trouve donc le remède miracle pour que les applications dépassent leur cercle restreint ? La plupart attendent une réponse standard, tandis que d'autres tentent de créer leurs propres solutions à travers l'exploration.
Récemment, TechFlow a interviewé Spike OS, un projet d'infrastructure qui vise à offrir interopérabilité des données et composable aux applications Web3, permettant ainsi de combiner de nouvelles applications attrayantes pour les utilisateurs externes via le partage de données. Son fondateur Jeff nous a livré une réflexion approfondie sur les difficultés actuelles des applications Web3, tout en expliquant en détail la philosophie de conception, l’architecture produit et les plans futurs de Spike OS.
Si vous êtes intéressé par les opportunités d'investissement dans les infrastructures ou si vous développez actuellement des applications Web3, cette interview pourrait vous apporter inspiration et éclairages.
Section 1 : Philosophie de conception — Le ferry vers des eaux bleues
TechFlow : Quelle était l'idée initiale derrière la création de Spike OS ? Quel événement a déclenché ce projet ?
Jeff : Notre point de départ repose sur l'idée que le Web3 devrait servir une base d'utilisateurs plus large. L'adoption massive du Web3 ne devrait pas se limiter au secteur financier, ni être seulement un outil pour les professionnels de la finance.
Comme l’a souligné Vitalik Buterin : « Les blockchains fonctionnent bien dans les applications financières, mais les applications non financières sont aussi une direction intéressante pour l’avenir ».
Actuellement, le marché Web3 manque d'applications matures hors finance, et l’industrie est encore loin d’une véritable adoption massive. Toutefois, lors du dernier cycle, l’émergence des NFT et du GameFi – que ce soit Bored Ape, StepN ou Axie Infinity – a généré un afflux important de nouveaux utilisateurs. Bien que ces produits présentent chacun leurs défauts, ils montrent clairement qu’en l’absence d’applications non financières, il n’y aura pas de croissance significative du marché, ni la croissance rapide espérée.
Prenons l’exemple du GameFi : aujourd’hui, il n’existe aucun jeu de calibre AAA vraiment remarquable, et les jeux entièrement sur chaîne n’ont pas trouvé un large public. Nous pensons donc nécessaire de créer un nouvel environnement d’exécution Web3 : un environnement où tous les actifs sont sur chaîne, offrant une expérience utilisateur interopérable ; où les applications bénéficient d’une meilleure extensibilité et composable, tout en restant agréable à jouer.
Un tel environnement serait capable d’attirer davantage d’applications non financières et d’utilisateurs. Or, à ce jour, la couche d’infrastructure offrant cet environnement fait défaut – c’est précisément ce que nous souhaitons construire.
TechFlow : Vous avez mentionné les jeux et les applications non financières. Spike OS s'adresse-t-il principalement aux développeurs de jeux Web3 ? Comment d'autres types d'applications peuvent-elles bénéficier de votre produit ?
Jeff : Tout d'abord, nous proposons une solution technique générale, orientée vers la couche fondamentale. Cette solution n'a pas besoin de distinguer entre un jeu et une autre application.
Dans l'industrie actuelle, la frontière entre jeux et applications devient de plus en plus floue. Par exemple, Sandbox possède certes une apparence de jeu, mais ses usages vont bien au-delà : y organiser des AMA, du travail collaboratif, des spectacles ou concerts. Cela dépasse largement la définition traditionnelle d’un jeu.
Par conséquent, Spike OS ne se limite pas à cibler les jeux ou autres applications spécifiques. Il vise essentiellement à créer un environnement futuriste axé sur la disponibilité des données, la composable des modules d'applications et l'interopérabilité des données utilisateur.
Bien sûr, les développeurs de jeux pourraient collaborer plus rapidement avec Spike OS, car les utilisateurs grand public acceptent probablement mieux les jeux au début.
TechFlow : Les problèmes actuels liés à la disponibilité des données, à la composable des modules et à l'interopérabilité semblent très abstraits. Pouvez-vous les illustrer par un exemple concret ?
Jeff: Bien sûr. Prenons un exemple concret pour mieux comprendre la composable et l'interopérabilité des modules. Dans un monde ouvert comme Sandbox, des jeux développés par des tiers peuvent être intégrés.
Imaginons que j’aie créé une application de poker Texas Hold’em, installée dans le casino virtuel. Vous pouvez acheter une table (NFT), inviter d’autres joueurs, jouer et partager les gains selon les règles. Mais si vous souhaitez utiliser cette même table pour jouer au blackjack ou au mahjong (d’autres modules), vous découvrirez que la réutilisation ou le développement secondaire de l’application existante est impossible – l’idée n’était peut-être même pas envisagée par le développeur initial.
Même si les développeurs veulent fournir des modules supplémentaires, cela nécessite un travail considérable pour les rendre accessibles.
Ainsi, les applications actuelles ne sont naturellement ni modulaires ni composable, ce qui nuit autant aux utilisateurs qu’aux développeurs, préjudiciant les intérêts des deux parties. Une meilleure situation serait que les applications soient conçues comme des modules ouverts et composable. Si vous créez un scénario, d'autres pourront facilement innover dessus grâce à une innovation secondaire fluide – quelque chose qui manque tant au Web3 qu’au Web2.
Ensuite, concernant l'interopérabilité des données. Actuellement, les données de toute application sont privées aux développeurs. Elles sont stockées sur vos serveurs – AWS ou Alibaba Cloud –, dans des bases de données propriétaires contenant les données d'application, les relations sociales, les publications, etc.
D'autres applications ne peuvent pas accéder à vos données, sauf si vous ouvrez volontairement une API.
Imaginons alors un nouveau modèle dans le Web3 : les actifs restent la propriété des utilisateurs, mais toutes les données des applications circulent dans un réseau ouvert, librement appelables entre applications. Par exemple, si j’ai atteint le rang « Or » dans un jeu de tir A, un nouveau jeu pourrait automatiquement m’offrir un œuf de Pâques ou un badge spécial basé sur ce rang.
Lorsque les données sont libres d’accès entre applications, l’interopérabilité augmente considérablement. Imaginez que WeChat puisse accéder au score de crédit d’Alipay, ou que Xiaohongshu puisse analyser le profil des fans de Douyin. Ce type de partage de données stimulerait fortement l’innovation industrielle.
TechFlow : Ces problèmes existent bel et bien. Des solutions existent-elles déjà sur le marché ? Sinon, quelle est votre confiance et vos avantages en tant que pionnier ?
Jeff : Excellente question. Examinons d’abord si Ethereum et l’EVM ont déjà résolu la composable et l’interopérabilité des données ?
Les fameux « Lego DeFi » : vous créez un protocole A via des contrats intelligents, j’utilise votre protocole pour construire une autre application B. C’est ainsi que nous avons eu le « Defi Summer », puis des succès comme Curve et Aave.
Les applications financières exploitent donc pleinement la composable modulaire et l’échange de données. Pour les cas simples et standards, l’EVM a fait ses preuves. Mais ce n’est pas le cas pour les applications non financières.
Les applications non financières, ou « générales », impliquent de nombreux calculs complexes : flux vocaux, textes et multimédias dans les réseaux sociaux ; modèles 3D et animations dans les jeux ; bases de données utilisateurs multidimensionnelles…
Aujourd’hui, aucune solution ne gère efficacement ces calculs généralistes. Autrement dit, nous construisons une sorte d’EVM généraliste pour répondre à ces besoins.
Les développeurs utilisent divers langages – Java, C ou Python – mais dans notre machine virtuelle Spike OS, tout est converti en un format machine uniforme. Ainsi, tous les développeurs peuvent facilement intégrer leurs modules dans cette architecture, et ces modules s’interconnectent naturellement.
Notre équipe a précédemment lancé un projet de métavers nommé « Oasis ». En 2019, nous avons publié le premier moteur Oasis, destiné aux créateurs de contenu UGC dans le métavers.
Par ailleurs, Oasis Origin a participé au hackathon organisé par BNB Chain et a remporté la première place.
À partir de cette base, nous avons rendu le moteur open source, standardisé sa structure de données, et progressivement construit le produit Spike OS.
Ces trois à quatre dernières années, nous avons recruté continuellement de nouveaux talents, notamment des experts en moteurs open source et en langages bas niveau, afin de concrétiser ce produit. Ainsi, la création de Spike OS s’inscrit naturellement dans notre parcours. Mais cela ne signifie pas que nous sommes les seuls capables de le faire, ni que personne d’autre ne pourrait réussir.
Dans l’écosystème blockchain actuel, les solutions s’inspirent mutuellement, chacune ayant ses forces. Toutes peuvent coopérer et apprendre ensemble. Dès le départ, nous avons choisi d’ouvrir Spike OS, justement pour permettre à d’autres de bâtir dessus et d’innover davantage. Comme Ethereum à ses débuts, les contrats intelligents n’étaient pas parfaits, mais leur impact positif externe provenait de l’open source et de la gouvernance, attirant des milliers de développeurs extérieurs.
Voilà notre motivation profonde – et notre confiance – pour construire Spike OS.
TechFlow : En Web2, les produits de type système d'exploitation (OS) sont toujours difficiles à construire. Quel est selon vous le plus grand défi pour créer un produit OS en Web3 ?
Jeff : Nous nous inspirons beaucoup du système Android. Il est open source, son environnement de développement Android Studio l’est également. Ainsi, vous n’êtes pas obligé d’utiliser l’outil officiel ; vous pouvez l’améliorer selon l’architecture.
Le premier défi est donc la robustesse technique de Spike OS lui-même – bugs, erreurs, etc. Ce genre de problème est relativement facile à corriger.
Le vrai défi réside dans la formation du consensus et de l’écosystème. Notre solution sera-t-elle adoptée comme norme industrielle ? Plusieurs applications rejoindront-elles l’écosystème ? Aurons-nous assez d’applications utilisant notre solution ? Voilà nos priorités futures. Et plus il y aura d’applications, plus la complexité augmentera, mettant sous pression l’ensemble du système. Face à cette complexité croissante, risquons-nous des bugs ou des failles ?
Quant à la résolution du problème de l’écosystème, nous en parlerons plus tard dans la stratégie de développement.
Section 2 : Architecture technique — Bien plus qu'une simple « L3 »
TechFlow : Avant Spike OS, vous aviez lancé Spike Engine. S'agit-il de produits différents ? Quel lien existe-t-il entre eux ?
Jeff : Spike OS inclut Spike Engine, un peu comme Android OS inclut Android Studio.
Nous pouvons définir Spike OS en trois points :
Premièrement, c’est une solution modulaire et composable. Nous en avons déjà parlé précédemment. Spike Engine correspond surtout à l’environnement de développement modulaire/composable.
Deuxièmement, c’est un système de calcul décentralisé ouvert, où toutes les données circulent dans un réseau ouvert. La puissance de calcul nécessaire est fournie par les nœuds participants.
Troisièmement, c’est un environnement d'exécution utilisateur ouvert et interopérable. Pour l'utilisateur, c’est perçu comme un environnement d’exécution où les données sont interopérables, comme lorsque nous utilisons un smartphone Android ou iOS.
TechFlow : Engine, en tant qu'environnement de développement, est tangible, avec une interface visible. Mais qu'en est-il du concept d'« OS » ? Quelle est sa forme concrète ? Une blockchain ? Ou une couche ajoutée au-dessus des L1 et L2 ?
Jeff : Nous considérons que Spike OS est une « L3 » plug-and-play, multi-chaînes. Plus précisément, c’est un environnement d’exécution pour les calculs généraux des applications. Les L1 et L2 constituent un « environnement comptable », où les tokens et transactions sont enregistrés sur chaîne. Les calculs généraux, eux, sont traités dans Spike OS.
Nous sommes compatibles avec toutes les chaînes EVM comme ETH, Polygon, BSC, etc., et nous étendrons cette compatibilité à Aptos, Cosmos, etc.
En outre, la perception de l'OS par l'utilisateur n'est pas directe. L'utilisateur ressent simplement que, par exemple, un message envoyé à l’application A peut être reçu par l’application B, ou que les données peuvent être appelées entre applications. Une analogie familière serait que Spike OS permette, pendant une réunion sur Tencent Meeting, d’afficher directement un document de Feishu, ou de visualiser une vidéo publiée sur Douyin depuis Xiaohongshu.
Mais l’adresse du portefeuille et les actifs de l’utilisateur restent sur leur chaîne d’origine – par exemple, si une DApp tourne sur ETH, les transferts et opérations d’actifs suivent les règles d’ETH.
Quand l’utilisateur constate que ses données peuvent être utilisées librement entre appareils et applications, il perçoit une innovation majeure. Mais s’il sait qui en est à l’origine ? La majorité ne s’en soucie probablement pas.
TechFlow : Si on examine maintenant la structure interne de Spike OS, le livre blanc mentionne des éléments comme moteur, nœuds, contrats et chaînes. Pour faciliter la compréhension, pouvez-vous expliquer leur collaboration via un exemple ?
Jeff : Pas de problème. Imaginons que vous soyez un développeur. Voici comment vous utiliseriez Spike OS :
Développement du jeu — Spike Engine : Vous voulez créer un jeu de plateforme. Commencez par ouvrir Spike Engine, configurez différents modules, codez leurs comportements : sauter, se déplacer, marquer des points, passer un niveau…
Connexion des modules — Spike Contract : Votre jeu contient des modules utilisateurs, actifs, scores et scènes. Ces modules ne se connaissent pas. Pour connecter l’interface du « personnage » au « point de réapparition » de la scène, ou utiliser le « score » comme condition d’accès à la prochaine « scène », utilisez Spike Contract.
Besoins en puissance de calcul — Spike Node : Traditionnellement, après avoir fini votre jeu, vous devez acheter des serveurs, des bases de données, du rendu, des services vocaux pour le chat…
Dans Spike OS, cela revient à acheter de la « puissance de calcul ». Après avoir terminé le jeu, cliquez sur « publier » dans Spike Engine. Vous obtenez une adresse de protocole, par exemple « Spike/JeuPlateforme ». Partagez ce lien : téléchargez l’appli si c’est mobile, ou jouez directement sur navigateur.
La puissance de calcul nécessaire — rendu, communication, exécution, téléchargement, accélération CDN — est fournie par nos nœuds.
TechFlow : Concernant ces nœuds et leur puissance de calcul, quelles exigences matérielles ou temporelles ? Dans Bitcoin, devenir un nœud complet coûte cher.
Jeff : Oui, nos nœuds sont bien plus légers que ceux de Bitcoin ou d’Ethereum. Ethereum est un supercalculateur : chaque nœud doit théoriquement valider tout le réseau et conserver un résultat unique.
Les nœuds de Spike OS sont distribués en pair-à-pair. Si vous lancez une application à Shanghai, les utilisateurs locaux peuvent devenir nœuds, assurant le rendu et l’accélération pour votre environnement d’exécution.
Ce travail ne nécessite pas de validation globale, donc la charge est bien moindre.
TechFlow : Ce que vous avez décrit concerne surtout l'architecture produit. Pourriez-vous montrer l'interface front-end de Spike OS ? Beaucoup souhaitent voir où vous en êtes concrètement.
Jeff : Je peux utiliser cette démo pour illustrer vivement :
-
Accédez via « Spike/Bomberman » pour jouer directement au jeu ;
-
Ajoutez « /dev » à l’URL pour entrer immédiatement en mode développeur ;
-
Vous verrez alors les modules du jeu : « personnage – scène – action – score » ;
-
Pour remplacer la scène « verger » par une scène « espace », téléversez simplement votre nouvelle scène ;
-
Utilisez ensuite un contrat pour lier la scène espace au jeu, payez les frais de gaz, et voilà : un nouveau Bomberman est prêt. C’est essentiellement une interface légère de développement web.
TechFlow : Cette interface s'adresse surtout aux développeurs. Quels moyens ont les utilisateurs ordinaires pour participer à Spike OS ? Peuvent-ils devenir nœuds ?
Jeff : Oui, nous voulons un réseau sans permission, offrant plus de façons de participer. Un peu comme le réseau P2P de Xunlei : chaque appareil est aussi un nœud. En téléchargeant, vous contribuez aussi à l’envoi de données. Plus il y a d’utilisateurs, plus il y a de « seeders », plus la vitesse entre nœuds augmente.
Fondamentalement, Spike OS est un réseau accessible sans permission. Chaque ordinateur, voire chaque téléphone, peut y adhérer. Si nous jouons ensemble, nous fournissons mutuellement de la puissance de calcul – accélération des communications, capacité de rendu, etc.
Au début, les exigences seront plus strictes : nous évaluerons chaque nœud (temps de connexion, rapidité et précision des calculs). Mais à long terme, le réseau s’ouvrira davantage. Avec plus d’utilisateurs et de développeurs, les nœuds se multiplieront, rendant le réseau de plus en plus ouvert, jusqu’à devenir totalement sans permission.
TechFlow : Quelle est la motivation pour rejoindre en tant que nœud ? Y a-t-il une incitation économique ?
Jeff : Principalement via des récompenses en jetons. Un développeur qui louait auparavant des serveurs (coût mensuel de dizaines ou centaines de milliers) paie désormais en jetons à des nœuds de Spike pour fournir la puissance de calcul nécessaire.
Les nœuds reçoivent des récompenses proportionnelles à leur contribution. À mesure que l’écosystème grandit, le jeton devient un token de gouvernance, dont la valeur anticipée augmente, incitant davantage de participants à fournir du calcul ou à devenir nœuds.
De plus, devenir nœud requiert un « staking ». Le nœud doit garantir des calculs valides, sans ralentir le réseau ou une application. Un staking est donc requis, ajusté dynamiquement selon l’évaluation : plus votre score est élevé, plus votre mise et vos récompenses fluctuent.
Section 3 : Stratégie de déploiement — Collaboration, pas disruption
TechFlow : Avez-vous pensé à la commercialisation et à la promotion ? Spike OS semble très technique et orienté B2B. Comment toucher plus de projets et faire connaître votre existence ?
Jeff : Excellente question, que nous réfléchissons activement. J’ai une réponse provisoire, que je soumets à la communauté : les solutions matures doivent souvent faire du business development (BD), convaincre activement les entreprises d’adopter leur solution.
C’est pourquoi nous voyons des centaines d’équipes chez Polygon, Avalanche, Near, Aptos ou Sui démarcher de nouveaux projets pour développer sur leurs chaînes.
Mais Ethereum, au début, n’avait pas de BD. Il n’a pas cherché activement de grands partenaires. Pourquoi cette différence ? Selon moi, si une nouvelle solution permet à certains cas d’usage de réaliser l’impossible, avec une efficacité, une performance et une expérience bien supérieures aux solutions existantes, elle sort du même courant d’innovation.
Un exemple flagrant : l’ICO. Malgré son effondrement, tout le monde a reconnu l’utilité des contrats intelligents et de l’EVM, car seule la structure d’Ethereum permettait cette innovation. De même, nous cherchons des cas où seule la solution Spike fonctionne, offrant une excellente expérience utilisateur, une grande efficacité pour les développeurs et des coûts très bas.
Si l’innovation perçue provient des changements techniques sous-jacents, davantage de développeurs rejoindront naturellement l’écosystème – plutôt que de devoir faire du BD agressif, ce qui détournerait de notre objectif initial.
TechFlow : Dans cette optique, quelles actions concrètes allez-vous mener ? Créerez-vous des cas d'usage ou lancerez-vous des programmes d'incitation pour développeurs ?
Jeff: Oui, en trois phases.
Première phase : Nous développerons nous-mêmes des applications complètes et fonctionnant sur chaîne. Oasis, par exemple, a déjà été développé selon le modèle Spike. La démo du jeu type Bomberman sera disponible sur notre site. Nous migrerons aussi ce jeu vers d’autres chaînes pour montrer à quoi ressemblent les applications composable et non financières.
Nous devons d’abord maîtriser Spike OS et démontrer clairement sa supériorité technique.
Deuxième phase : Nous collaborerons avec les grandes blockchains et L2, principalement via investissements ou bourses (grants), pour encourager leurs développeurs à utiliser Spike OS. C’est aussi pourquoi nous serons présents à ETH Denver.
Les retours montrent que les blockchains cherchent toutes l’adoption massive et de nouveaux utilisateurs. Elles sont donc ouvertes à tout nouvel environnement de développement attirant plus d’applications ludiques et d’utilisateurs extérieurs. Étant donné que nous n’avons pas notre propre chaîne complète, nous sommes partenaires, non concurrents.
Troisième phase : Une fois l’avantage de Spike OS reconnu, nous développerons notre propre écosystème de développeurs. Via des hackathons ou incubations, nous attirerons des développeurs venant spécifiquement pour Spike OS. Mais cette phase viendra plus tard ; nous concentrons actuellement sur les deux premières.
TechFlow : Petite parenthèse. Le dernier projet portant "OS" dans son nom était EOS. Son déploiement final n’a pas tenu ses promesses. Comment éviter de suivre le même chemin ?
Jeff: EOS a suscité l’engouement, puis la déception, et s’est finalement évanoui.
Je pense que l’esprit de la blockchain consiste à innover sur les réussites passées, à coopérer pour servir plus d’utilisateurs, et non à tout recommencer depuis zéro. Prétendre modifier radicalement Ethereum et affirmer détenir la meilleure solution est une approche que je ne soutiens pas.
Dès le départ, Spike OS a choisi de s’appuyer sur les chaînes existantes, d’apporter une nouvelle puissance aux écosystèmes Ethereum, L1 et L2, afin que davantage d’actifs et de données d’applications soient sur chaîne, que le développement devienne plus accessible, et que l’innovation commerciale s’accélère.
Nous ne concurrençons pas les chaînes, mais aidons à créer plus d’applications et à attirer de nouveaux utilisateurs. C’est là notre grande différence avec EOS. Plutôt que de tout refaire, nous naviguons avec le courant, espérant trouver notre valeur en aidant les autres à réussir.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
