Sei Lance Eidos Pour Viser 200000 Tps

Imaginez un réseau capable de traiter l’équivalent de plusieurs milliers de transactions bancaires chaque seconde, sans jamais ralentir, sans jamais bloquer les validateurs sous le poids des données. C’est exactement ce que Sei tente de concrétiser en ce moment avec le déploiement progressif d’Eidos. Alors que la plupart des blockchains peinent encore à dépasser quelques milliers de transactions par seconde sans compromis, le projet annonce un objectif de 200 000 TPS. Et le premier levier actionné n’est pas le consensus ni l’exécution, mais le stockage lui-même.

Une refonte du stockage pour préparer le futur du réseau

Le 12 août, Sei a publié une mise à jour technique détaillant le lancement d’Eidos. Quelques jours plus tard, la première phase est déjà active sur le mainnet via la version 6.6. Il ne s’agit pas d’un simple patch. C’est une reconstruction complète de la manière dont le réseau conserve et vérifie ses données. Dans le cadre plus large du roadmap Giga, Eidos forme le troisième pilier d’une architecture repensée de fond en comble : consensus avec Autobahn, exécution avec Ares, et désormais stockage avec Eidos.

Pourquoi commencer par le stockage ? Parce qu’à très haute cadence, le goulot d’étranglement ne se trouve plus forcément dans le moteur d’exécution. Quand un réseau doit écrire des centaines de milliers d’entrées en base de données chaque seconde, même les optimisations les plus poussées côté calcul deviennent inutiles si le disque et les structures de données ne suivent pas. C’est précisément ce constat qui a guidé l’équipe.

Le problème des arbres de Merkle traditionnels

Dans la plupart des blockchains, l’état du réseau repose sur des structures arborescentes de type Merkle. Chaque modification d’une valeur oblige le nœud à recalculer une série de hachages jusqu’à la racine. Plus l’état grossit, plus ce chemin de recalcul s’allonge. À grande échelle, ces opérations deviennent coûteuses en temps et en ressources.

Eidos propose de remplacer cette logique pour l’état EVM par un système plat appelé FlatKV. Ici, une modification d’état se traduit par une seule écriture. La vérification s’effectue ensuite via LtHash, un mécanisme de hachage en treillis. L’idée est simple en apparence : maintenir une empreinte digitale globale de l’état qui s’actualise en temps constant. Lorsqu’une valeur change, on retire la contribution de l’ancienne et on ajoute celle de la nouvelle. Le volume de travail par mise à jour reste stable, même si l’état global continue de croître.

À 200 000 transactions par seconde, le stockage doit écrire des centaines de milliers d’entrées chaque seconde. Sans cette capacité, l’exécution la plus rapide du monde ne sert à rien.

Équipe technique de Sei

Ce choix n’est pas anodin. Il s’inscrit directement dans les ambitions du whitepaper Giga publié en mai 2025. Le document visait déjà 200 000 TPS, 5 gigagas de débit et une finalité inférieure à 400 millisecondes. Eidos est la réponse concrète à la question du stockage dans ce scénario extrême.

Séparation de l’état EVM dans une base dédiée

Un autre changement majeur concerne l’organisation des données. Jusqu’ici, l’état EVM partageait la même base que d’autres informations gérées par les nœuds. Cette cohabitation créait des interférences : les requêtes historiques pouvaient concurrencer le traitement des transactions en cours, et les modules non-EVM subissaient une charge inutile.

Avec Eidos, l’état EVM dispose désormais de son propre espace de stockage. Les requêtes anciennes n’impactent plus directement le chemin critique des transactions live. Cette séparation a commencé à arriver sur le mainnet avec la version 6.6. En parallèle, Sei a retravaillé le mécanisme de pruning, c’est-à-dire le nettoyage des données devenues inutiles pour le fonctionnement courant des nœuds.

Ces chiffres, issus des tests et de l’observation en production, montrent que l’impact n’est pas purement théorique. Des nœuds plus légers et plus réactifs facilitent la participation d’un plus grand nombre d’opérateurs, ce qui renforce la décentralisation à long terme.

LittDB pour les blocs et les reçus de transactions

Tous les types de données n’ont pas les mêmes besoins. Les comptes et les contrats changent fréquemment. Les blocs et les reçus de transactions, eux, sont écrits une seule fois, lus à plusieurs reprises, puis archivés. Sei a donc conçu un moteur de stockage spécifique baptisé LittDB pour gérer ces données.

Selon les benchmarks internes, LittDB dépasse le gigaoctet par seconde en écriture tout en assurant environ 55 000 lectures ponctuelles par seconde. Un magasin de reçus dédié a soutenu plus de 150 000 écritures par seconde lors de tests de plusieurs heures incluant le garbage collection. L’équipe insiste toutefois sur un point important : ces chiffres mesurent la performance du moteur de stockage, pas le débit transactionnel de la blockchain elle-même.

Cette spécialisation permet d’optimiser chaque couche selon sa nature. On évite ainsi de forcer un outil unique à gérer des profils d’accès radicalement différents.

Archivage hors nœuds et allègement des validateurs

Plus un réseau traite de transactions, plus l’historique gonfle. Si chaque validateur doit conserver l’intégralité de cet historique en local, les exigences matérielles explosent. Eidos change la donne en séparant clairement ce qui doit rester sur les nœuds actifs et ce qui peut être déplacé vers des systèmes d’archivage conçus pour la capacité plutôt que pour la vitesse.

Les données fréquemment consultées et l’historique récent restent sur un stockage local rapide. Les enregistrements plus anciens migrent vers des solutions d’archivage. Les explorateurs, les indexeurs et les utilisateurs qui ont besoin d’auditer d’anciennes transactions conservent un accès à ces données. En revanche, les validateurs ne sont plus obligés de porter tout le poids de l’histoire sur leurs disques.

Cette approche répond à un problème classique : à mesure que le débit augmente, le coût du matériel nécessaire pour rester synchronisé grimpe. En réduisant le volume de données actives, Sei limite cette pression et maintient un seuil d’entrée plus accessible pour les opérateurs de nœuds.

Une migration en douceur sans interruption de service

L’un des aspects les plus délicats d’une telle refonte est la transition. Arrêter le réseau pour migrer les données n’était pas envisageable. Sei a donc conçu un processus où les anciens et les nouveaux systèmes de stockage coexistent pendant le transfert.

Les données sont déplacées par lots, bloc après bloc. Le déploiement est piloté par la gouvernance et prévoit un mécanisme de retour en arrière en cas de problème. Avant le passage en production, des nœuds d’ombre ont rejoué le trafic réel du mainnet contre les nouvelles structures tout en vérifiant en continu les hashs d’intégrité. Les tests ont montré que les temps de bloc restaient globalement stables même lorsque les processus de migration tournaient en arrière-plan.

Pour les utilisateurs et les développeurs d’applications, rien ne change. Les soldes, les smart contracts, l’historique et les points d’accès RPC existants restent disponibles. Seuls les opérateurs de nœuds ont reçu un guide de migration détaillant les drapeaux de configuration et la procédure de rollback.

Le troisième chantier de stockage de Sei

Eidos n’est pas la première tentative de modernisation du stockage sur ce réseau. Sei avait déjà abandonné l’architecture de stockage d’origine héritée de Cosmos au profit de SeiDB. La séparation de l’état-store actuellement en cours constitue une nouvelle étape. FlatKV, LittDB et le système d’archivage hors nœuds arriveront dans les phases suivantes.

Cette progression méthodique montre une volonté de ne pas tout changer d’un coup. Chaque couche est testée, déployée, observée, puis complétée. C’est une stratégie plus lente, mais qui limite les risques sur un réseau déjà en production et utilisé par des millions d’utilisateurs.

Contexte d’adoption et écosystème en expansion

Le travail d’infrastructure s’inscrit dans une dynamique plus large d’ouverture de l’écosystème EVM de Sei. En août 2025, MetaMask a ajouté un support natif, permettant aux utilisateurs d’accéder directement aux applications, d’échanger des actifs et de bridge des tokens. À cette époque, le réseau traitait déjà plus de 4,2 millions de transactions quotidiennes et comptait plus de 11 millions d’utilisateurs actifs mensuels.

En décembre 2025, un accord de distribution avec Xiaomi prévoyait la pré-installation d’un portefeuille Sei sur de nouveaux smartphones vendus hors de Chine continentale et des États-Unis. Les deux entreprises envisagaient également le support de paiements en stablecoins comme l’USDC, avec des déploiements initiaux prévus à Hong Kong et dans l’Union européenne.

Ces initiatives d’accès grand public n’ont de sens que si l’infrastructure sous-jacente peut absorber une charge croissante. Eidos apparaît donc comme la condition technique nécessaire pour que ces efforts d’adoption ne se heurtent pas à un plafond de performance.

Ce que change concrètement Eidos pour les différents acteurs

Pour les validateurs, la migration se traduit par de nouvelles options de configuration et la possibilité de réduire progressivement le volume de données stockées localement. Pour les développeurs, l’expérience reste identique : les endpoints RPC ne changent pas, les contrats continuent de fonctionner comme avant. Pour les utilisateurs finaux, l’impact est invisible. C’est précisément le signe d’une transition réussie.

À plus long terme, la spécialisation des couches de stockage devrait permettre au réseau de monter en charge sans forcer chaque participant à investir dans du matériel toujours plus onéreux. C’est un point souvent sous-estimé dans les discussions sur le scaling : la performance brute n’a de valeur que si elle reste accessible à une base suffisamment large d’opérateurs.

Les prochaines étapes du déploiement

La version 6.6 a introduit la séparation de l’état EVM et les premiers éléments de pruning amélioré. Les phases suivantes apporteront FlatKV, LtHash, le nouveau magasin de reçus et les systèmes d’archivage hors nœuds. Chaque étape sera activée progressivement, toujours sous contrôle de gouvernance et avec des mécanismes de secours.

Cette approche en couches successives permet d’observer le comportement réel du réseau à chaque jalon. Elle évite aussi de concentrer tous les risques sur un seul hard fork massif. Dans un environnement où la confiance des utilisateurs et des développeurs est fragile, cette prudence technique a de la valeur.

Pourquoi le stockage est devenu le vrai champ de bataille du scaling

Pendant des années, le débat sur le scaling s’est concentré sur le consensus et sur la capacité d’exécution. Les arbres de Merkle, les bases de données et les stratégies d’archivage restaient souvent des sujets de second plan. Avec des objectifs de débit aussi élevés que ceux de Giga, cette hiérarchie s’inverse. Le stockage devient le facteur limitant.

Sei n’est pas le seul projet à s’en rendre compte. Mais peu d’équipes ont engagé une reconstruction aussi systématique de cette couche. En traitant le stockage comme un pilier à part entière de l’architecture, au même titre que le consensus et l’exécution, le projet affiche une vision cohérente de ce qu’exige un réseau de nouvelle génération.

Le chemin vers 200 000 TPS reste long. Autobahn et Ares devront aussi livrer leurs promesses. Mais en s’attaquant dès maintenant aux contraintes de stockage, Sei se donne une chance réelle d’atteindre ces chiffres sans que les nœuds ne s’effondrent sous le poids des données. C’est une approche pragmatique, technique, et résolument tournée vers la durabilité de la performance.

Un signal fort pour l’écosystème layer-1

Dans un marché où les annonces de throughput records se multiplient, la manière dont Sei structure son roadmap attire l’attention. Plutôt que de promettre un chiffre isolé, l’équipe détaille les trois couches qui doivent évoluer de concert. Eidos n’est pas un gadget marketing. C’est une pièce d’ingénierie nécessaire pour que les autres pièces puissent fonctionner à plein régime.

Les prochains mois permettront de juger si les phases suivantes se déroulent aussi proprement que la première. Pour l’instant, le signal est clair : Sei prend le stockage au sérieux, et le mainnet commence déjà à en profiter. Dans la course aux hauts débits, ceux qui négligent cette fondation risquent de découvrir trop tard que le plafond n’était pas où ils le croyaient.

Le déploiement d’Eidos marque donc plus qu’une simple mise à jour technique. Il incarne une prise de conscience : pour tenir 200 000 transactions par seconde de manière durable, il faut reconstruire le socle sur lequel tout le reste repose. Et cette reconstruction a commencé.