Imaginez un réseau blockchain capable de traiter deux cent mille transactions chaque seconde. Pas dans un futur lointain, mais comme objectif concret d’une feuille de route déjà en cours. C’est exactement ce que Sei vient d’amorcer avec le lancement progressif d’Eidos, une refonte en profondeur de son architecture de stockage. L’annonce, sortie en douceur via une mise à jour technique, marque pourtant un tournant pour ce layer-1 qui cherche à se positionner parmi les infrastructures les plus performantes du secteur.
Une refonte du stockage au cœur du projet Giga
Le 12 août, Sei a publié une note technique qui détaillait le début du déploiement d’Eidos. Cette mise à jour n’est pas isolée. Elle s’inscrit dans un triptyque plus large baptisé Giga, qui vise à reconstruire simultanément les trois piliers d’une blockchain : le consensus, l’exécution des transactions et le stockage des données. Autobahn s’occupe du consensus, Ares de l’exécution, et Eidos du stockage. Sans cette dernière pièce, les deux autres resteraient bridées.
L’idée centrale est simple à formuler, mais complexe à mettre en œuvre. À très haut débit, le goulot d’étranglement ne se trouve plus seulement dans la validation des blocs ou dans le traitement des smart contracts. Il se niche dans la manière dont les nœuds écrivent, lisent et vérifient l’état de la chaîne. Si le stockage ne suit pas, les gains de performance ailleurs deviennent purement théoriques.
Sei a déjà franchi une première étape concrète. Les composants initiaux d’Eidos sont arrivés sur le mainnet via la version 6.6. Le reste suivra par phases successives. L’équipe insiste sur un point : la migration se déroule pendant que le réseau reste pleinement opérationnel. Les anciens et les nouveaux systèmes cohabitent le temps que les données basculent progressivement.
Pourquoi les arbres de Merkle deviennent un frein
Pour comprendre l’intérêt d’Eidos, il faut revenir à la structure de données traditionnelle utilisée par la plupart des blockchains compatibles EVM. Les arbres de Merkle permettent de vérifier l’intégrité de l’état de manière élégante. Chaque modification d’une valeur force cependant le recalcul de plusieurs hachages le long du chemin jusqu’à la racine. Plus l’état grossit, plus ces recalculs deviennent coûteux en opérations disque et en temps de processeur.
À l’échelle de quelques milliers de transactions par seconde, ce surcoût reste gérable. Mais dès que l’on vise des centaines de milliers d’écritures par seconde, la structure arborescente se transforme en frein structurel. Chaque mise à jour d’état génère une cascade de recalculs qui s’accumulent et ralentissent l’ensemble du système.
Eidos propose de remplacer cette approche pour l’état EVM par une solution appelée FlatKV. Comme son nom l’indique, il s’agit d’un stockage à clé-valeur plat. Une modification d’état se traduit par une seule écriture. Plus de chemin à recalculer, plus de propagation de hachages intermédiaires.
LtHash, la vérification en temps constant
Le stockage plat pose immédiatement une question : comment vérifier l’intégrité de l’état sans l’arbre de Merkle ? La réponse de Sei s’appelle LtHash, pour lattice hashing. Au lieu de recalculer un chemin, le système maintient une empreinte globale de l’état qui peut être mise à jour en temps constant.
Concrètement, lorsqu’une valeur change, le nœud soustrait la contribution de l’ancienne valeur et ajoute celle de la nouvelle. L’empreinte se met à jour sans que le volume de travail n’augmente avec la taille de l’état. C’est un changement de paradigme : la complexité par opération reste stable même lorsque le réseau grossit massivement.
Cette approche s’inscrit directement dans les objectifs du whitepaper Giga publié en mai 2025. Le document visait 200 000 transactions par seconde, cinq gigagas de débit et une finalité inférieure à 400 millisecondes. À ce rythme, le réseau doit écrire des centaines de milliers d’entrées en base de données chaque seconde. Si le stockage ne suit pas, l’exécution la plus rapide du monde ne sert à rien.
Séparation de l’état EVM dans une base dédiée
Un autre pilier d’Eidos consiste à isoler l’état EVM du reste des données gérées par les nœuds. Jusqu’à présent, l’état Ethereum Virtual Machine partageait la même base que d’autres informations de la chaîne. Cette cohabitation créait une concurrence directe entre les requêtes historiques et le traitement des transactions en direct.
Avec la nouvelle architecture, l’état EVM dispose de son propre magasin dédié. Les modules non-EVM n’ont plus à supporter le coût des opérations liées à l’état des smart contracts. Les requêtes d’historique n’interfèrent plus autant avec le flux de transactions courantes. La séparation a commencé à arriver sur le mainnet avec la version 6.6, toujours en août.
Sei a également revu en profondeur le mécanisme de pruning, c’est-à-dire le nettoyage des données dont les nœuds n’ont plus besoin en stockage actif. Lors des tests et en production, un processus de nettoyage qui prenait auparavant entre huit et dix-huit minutes est tombé à environ cinq minutes. Les nœuds qui pouvaient se retrouver plusieurs centaines de blocs en retard restent désormais dans une fourchette d’environ soixante blocs par rapport à la tête de chaîne.
LittDB pour les blocs et les reçus
Les blocs et les reçus de transactions ont des caractéristiques de stockage très différentes de l’état des comptes et des contrats. Ils sont écrits une seule fois, lus de manière répétée, puis éventuellement archivés. Les traiter avec le même moteur que l’état vivant n’est pas optimal.
Eidos introduit donc un moteur de stockage séparé baptisé LittDB. Selon les benchmarks internes de Sei, ce système atteint un débit d’écriture supérieur à un gigaoctet par seconde tout en gérant environ 55 000 lectures ponctuelles par seconde. Un nouveau magasin de reçus a soutenu plus de 150 000 écritures par seconde lors de tests de plusieurs heures incluant le ramasse-miettes. L’équipe précise toutefois que ces chiffres mesurent les performances du moteur de stockage et ne doivent pas être confondus avec le débit de transactions de la blockchain elle-même.
Cette spécialisation des moteurs de stockage selon la nature des données est une tendance qui se dessine de plus en plus dans les architectures hautes performances. Elle permet d’optimiser chaque type d’accès sans compromettre les autres.
L’archivage hors nœud pour alléger les validateurs
Plus le débit augmente, plus le volume de données historiques explose. Si chaque nœud actif doit conserver l’intégralité de l’historique, les exigences matérielles deviennent rapidement prohibitives. Eidos change la donne en séparant clairement ce qui doit rester en stockage local rapide et ce qui peut migrer vers des systèmes d’archivage conçus pour la capacité.
L’état fréquemment consulté et l’historique récent restent sur les disques rapides des nœuds. Les enregistrements plus anciens partent vers des solutions d’archivage. Les explorateurs, les indexeurs et les utilisateurs qui ont besoin d’auditer d’anciennes transactions conservent l’accès à ces données, mais les validateurs n’ont plus à les porter en permanence.
Cette stratégie vise à éviter que les requêtes historiques ne consomment les ressources nécessaires au traitement des transactions en cours. Elle permet aussi de freiner la course à l’armement matériel qui accompagne souvent la hausse du débit d’un réseau.
Une migration conçue pour rester en ligne
L’un des aspects les plus délicats d’une telle refonte est la migration elle-même. Sei a choisi de ne pas arrêter la chaîne. Les systèmes de stockage existants et les nouveaux coexistent pendant que les données migrent par lots, bloc après bloc. Le déploiement est piloté par la gouvernance et intègre un mécanisme de retour 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 nouveaux systèmes de stockage. Des hachages d’intégrité étaient vérifiés en continu. Les tests ont montré que les temps de bloc restaient globalement stables même pendant que les processus de migration tournaient en arrière-plan.
Pour les utilisateurs et les développeurs d’applications, aucune action n’est requise. Les soldes, les smart contracts, les historiques et les points de terminaison RPC existants restent disponibles. Les opérateurs de nœuds disposent d’un guide de migration qui détaille les drapeaux de configuration et la procédure de rollback documentée.
Le troisième chantier de stockage de Sei
Eidos n’est pas la première refonte du stockage entreprise par le réseau. Sei a déjà remplacé son architecture de stockage Cosmos d’origine par SeiDB, puis a introduit la séparation du state-store qui arrive maintenant sur le mainnet. FlatKV, LittDB et le système d’archivage hors nœud constitueront les prochaines étapes, déployées au fil des versions suivantes.
Cette progression par étapes révèle une approche pragmatique. Plutôt que de tenter une révolution unique et risquée, l’équipe décompose le problème en couches successives, chacune validée en conditions réelles avant de passer à la suivante. C’est une méthode plus lente, mais qui limite les risques de régression majeure.
Le contexte d’un écosystème en expansion
Ces travaux d’infrastructure s’inscrivent dans un contexte plus large d’ouverture de l’écosystème EVM de Sei. En août 2025, MetaMask a ajouté le support natif du réseau, permettant aux utilisateurs d’accéder aux applications, d’échanger des actifs et de bridger des tokens directement depuis le portefeuille. À l’époque, Sei traitait plus de 4,2 millions de transactions quotidiennes et comptait plus de 11 millions d’utilisateurs actifs mensuels.
Plus récemment, un accord de distribution annoncé en décembre 2025 prévoyait que Xiaomi préinstalle un portefeuille Sei sur les nouveaux smartphones commercialisés hors de Chine continentale et des États-Unis. Les deux partenaires envisageaient également le support des paiements en stablecoins, notamment avec USDC, avec des déploiements initiaux prévus à Hong Kong et dans l’Union européenne.
Ces initiatives d’adoption côté utilisateur et côté hardware rendent d’autant plus critique la capacité du réseau à absorber une hausse significative de l’activité. Un stockage sous-dimensionné pourrait rapidement devenir le point de rupture.
Ce que change concrètement Eidos pour les différents acteurs
Pour un validateur, la promesse est double : une réduction progressive de la charge liée à l’historique et une meilleure isolation entre les différents types de données. Les temps de pruning plus courts et le maintien plus proche de la tête de chaîne réduisent le risque de se faire distancer. À plus long terme, l’archivage hors nœud devrait alléger les exigences de stockage local.
Pour un développeur d’application, le changement est quasiment transparent. Les interfaces existantes continuent de fonctionner. En revanche, la capacité du réseau à soutenir des volumes bien plus élevés ouvre des perspectives pour des cas d’usage qui étaient jusqu’ici trop gourmands en écritures d’état.
Pour un utilisateur final, la migration ne change rien à l’expérience quotidienne. Les soldes restent accessibles, les applications continuent de fonctionner, et les performances perçues devraient, à terme, s’améliorer si le réseau atteint effectivement les objectifs de Giga.
Les défis techniques qui restent à surmonter
Passer d’une architecture de stockage traditionnelle à un système à clé-valeur plat avec vérification par lattice hashing n’est pas anodin. La robustesse des mécanismes de rollback, la cohérence des données pendant la coexistence des deux systèmes et la fiabilité des hachages d’intégrité seront scrutées de près par la communauté technique.
Les benchmarks internes sont encourageants, mais ils restent des mesures de laboratoire. Le comportement sous charge réelle, avec un mix de transactions variées, de requêtes d’indexeurs et d’accès historiques, constituera le vrai test. La phase actuelle, où les premiers composants sont déjà en production, permettra d’accumuler de l’expérience avant le déploiement des briques plus ambitieuses comme FlatKV et LtHash.
Il faudra aussi observer comment les opérateurs de nœuds s’approprient les nouveaux paramètres de configuration et s’ils rencontrent des difficultés imprévues lors de la bascule. La documentation fournie et le mécanisme de retour arrière sont des filets de sécurité, mais la réalité opérationnelle réserve parfois des surprises.
Une vision plus large de l’évolutivité
Le projet Giga, avec ses trois axes simultanés, illustre une conviction : l’évolutivité d’une blockchain ne se résout pas en optimisant un seul composant. Consensus, exécution et stockage forment un système interdépendant. Améliorer l’un sans les autres crée simplement un nouveau goulot d’étranglement ailleurs.
En s’attaquant au stockage en même temps qu’aux autres couches, Sei tente d’éviter ce piège classique. La feuille de route est ambitieuse, avec des chiffres qui placent le réseau dans une catégorie de performance encore rare aujourd’hui. Que ces objectifs soient atteints ou non dans les délais prévus, la démarche technique mérite attention.
Le fait que la migration se fasse à chaud, sans interruption de service, ajoute une contrainte supplémentaire. Beaucoup de projets préfèrent les hard forks ou les arrêts planifiés pour des changements de cette ampleur. Sei a choisi la voie plus complexe de la cohabitation progressive. Si elle réussit, elle démontrera une maturité opérationnelle intéressante.
Les prochaines étapes à surveiller
Dans les mois qui viennent, plusieurs jalons seront déterminants. L’arrivée effective de FlatKV et de LtHash sur le mainnet constituera la vraie bascule pour l’état EVM. Le déploiement de LittDB en production et la mise en place des systèmes d’archivage hors nœud complèteront le tableau.
Il sera également utile d’observer l’évolution des métriques de performance réelles une fois les différentes phases stabilisées. Les chiffres de débit d’écriture, les temps de réponse des nœuds et la capacité à rester proche de la tête de chaîne sous charge élevée donneront une image plus précise de l’impact d’Eidos.
Enfin, la manière dont la gouvernance gère le rythme du déploiement et les éventuels ajustements en cours de route offrira un éclairage sur la culture technique du projet. Une migration de cette envergure est rarement linéaire. La capacité à adapter le plan sans compromettre la stabilité du réseau sera un indicateur clé.
Une étape parmi d’autres dans la course à la performance
Sei n’est pas le seul réseau à chercher des solutions radicales au problème du stockage. D’autres projets explorent des approches différentes, qu’il s’agisse de structures de données alternatives, de sharding plus agressif ou de solutions de disponibilité des données externalisées. Chaque architecture porte ses propres compromis en termes de complexité, de sécurité et de décentralisation.
Ce qui distingue l’approche d’Eidos, c’est la combinaison d’un stockage plat, d’une vérification en temps constant et d’une spécialisation des moteurs selon le type de données. Si cette combinaison tient ses promesses sous charge réelle, elle pourrait influencer les choix d’architecture d’autres équipes confrontées aux mêmes limites.
Pour l’instant, le réseau est encore au début du chemin. Les premiers composants sont en place, les systèmes coexistent, et les phases suivantes sont planifiées. Le vrai verdict interviendra lorsque FlatKV et LtHash seront pleinement opérationnels et que le réseau tentera de s’approcher des objectifs de 200 000 transactions par seconde.
En attendant, Eidos illustre une réalité souvent oubliée : derrière les annonces de débit et de finalité se cachent des choix de structures de données, de moteurs de stockage et de stratégies d’archivage. C’est à ce niveau de granularité que se joue une partie importante de la compétition entre blockchains. Et c’est précisément à ce niveau que Sei vient d’engager une transformation de fond.
La suite se jouera dans la capacité à maintenir la stabilité pendant que les nouvelles briques arrivent, et dans la manière dont l’écosystème s’emparera des nouvelles marges de performance une fois qu’elles seront disponibles. Pour les observateurs, les prochains mois offriront un cas d’étude concret sur la façon dont un layer-1 gère une refonte majeure de son infrastructure sans jamais couper le service.
