Le marché est désormais complètement insensible aux « blockchains publiques à haut débit » ; pourquoi Somnia pourrait-elle être différente ?
TechFlow SélectionTechFlow Sélection
Le marché est désormais complètement insensible aux « blockchains publiques à haut débit » ; pourquoi Somnia pourrait-elle être différente ?
Somnia, prétendument la première couche 1 EVM parallèle la plus rapide et la plus rentable : fait-elle que du battage ?
Dédié à des analyses Web3 approfondiesAuteur : TVBee
Cet article analyse les deux questions suivantes :
Question 1 : Le marché est désormais complètement insensible au concept de « blockchain publique à haut débit ». Pourquoi Somnia pourrait-il être différent ?
Question 2 : Somnia, qui se targue d'être la Layer 1 EVM parallèle la plus rapide et la moins coûteuse, fait-il de la surenchère ?
➡️➡️➡️ Version concise ⬅️⬅️⬅️
Dans cette section, nous résumons Somnia selon trois dimensions — technique, contexte et écosystème — afin d’en présenter les points forts et avantages clés.
💠 Points techniques saillants de Somnia
🔹 Algorithme de consensus multifuve : chaîne de données + chaîne de consensus, permettant de lutter contre le MEV, réduire les redondances, diminuer les coûts tout en améliorant l’efficacité.
🔹 Compilateur EVM innovant : exécution parallèle au niveau des instructions EVM, capable de gérer des interactions fréquentes dans des cas extrêmes.
🔹 Moteur de base de données IceDB développé en interne : accroît la vitesse de lecture/écriture et la stabilité du réseau.
🔹 Technologie de compression des données : optimise l’efficacité du transfert des données.
💠 Avantages contextuels de Somnia
🔹 Équipe : L’équipe technique provient d’Improbable, une entreprise technologique internationale fondée en 2012 et basée à Londres, Royaume-Uni. Improbable a déjà conçu des logiciels, des jeux vidéo et des produits Web3 de métavers.
🔹 Financement : Investissement total de 270 millions de dollars mené par des institutions renommées telles que MSquared, a16z, SoftBank et Mirana.
💠 Progrès de l’écosystème de Somnia
🔹 Paysage écosystémique : Sur le testnet de Somnia sont déjà déployés 4 produits IA/réseaux sociaux, 7 jeux, 4 projets NFT et 6 applications DeFi. De plus, 2 autres produits IA/réseaux sociaux, 11 jeux et 1 application DeFi seront bientôt lancés.
🔹 Données écosystémiques : Depuis son lancement fin février 2025 jusqu’à la date de rédaction de cet article (26 juin 2025), le testnet de Somnia a produit plus de 100 millions de blocs, avec un temps moyen de production de bloc de 0,1 seconde. 96 878 557 adresses de portefeuille ont participé au testnet, générant 26,43 millions de transactions au cours des dernières 24 heures.
Sur l’explorateur de blocs, on observe constamment des changements rapides du nombre de transactions et de blocs : la promesse d’un délai « sub-seconde » est perceptible à l’œil nu.
💠 Pourquoi Somnia pourrait-il être différent ?
🔹 Interactions à haute fréquence : Bien que le marché soit blasé face aux prétentions de « hautes performances », Somnia ne cherche pas seulement à améliorer les indicateurs techniques, mais vise à intégrer véritablement les technologies Web3 dans des cas d’usage pratiques, notamment les jeux et les réseaux sociaux caractérisés par des interactions fréquentes.
🔹 Convergence Web2 et Web3 : Grâce à son origine particulière, Somnia pourrait jouer un rôle central dans la fusion entre Web2 et Web3. Il a le potentiel d’offrir aux utilisateurs Web2 une passerelle fluide vers le monde Web3, favorisant ainsi un écosystème centré sur l’expérience utilisateur.
➡️➡️➡️ Version détaillée ⬅️⬅️⬅️
La partie précédente présentait [QUOI] les atouts, avantages et progrès écosystémiques de Somnia. Cette section explore en profondeur ses innovations techniques, pour comprendre [COMMENT] Somnia parvient à supporter des interactions fréquentes, à offrir faible coût et haute performance, ainsi que [POURQUOI] il se distingue des autres projets EVM parallèles.
💠 Algorithme multifuve : chaîne de données + chaîne de consensus
🔹 Aperçu : structure en chaîne de données + chaîne de consensus
Somnia adopte un nouvel algorithme de consensus multifuve (MULTISTREAM).
Le terme « multifluve » signifie que Somnia enregistre les informations de transaction sur plusieurs chaînes de données distinctes. Chaque chaîne de données est gérée par un seul validateur, sans interférence possible entre les différentes chaînes.
Le terme « consensus » indique que Somnia exécute le consensus sur une chaîne commune, où les transactions sont ordonnées et leurs références (hash) enregistrées.
🔹 Aperçu : fonctionnement du consensus multifuve de Somnia
a Après qu’un utilisateur a envoyé une requête au réseau Somnia, le validateur concerné écrit la transaction sur sa chaîne de données.
b À intervalles réguliers (par exemple toutes les 30 secondes ou chaque seconde), les validateurs des chaînes de données échangent les fragments situés au sommet de leurs chaînes respectives.
c Les validateurs rassemblent tous ces fragments en une seule tranche complète de données, qu’ils écrivent ensuite sur la chaîne de consensus.
d Les validateurs ordonnent les transactions, mettent à jour l’état du système selon cet ordre, puis écrivent collectivement les modifications dans la base de données IceDB de Somnia.
🔹 Atout : Ordre des transactions favorable à la prévention du MEV
Somnia utilise une fonction pseudo-aléatoire déterministe pour ordonner les transactions.
En informatique, il n’existe pas de hasard véritable, seulement du pseudo-hasard généré par des algorithmes. Une fonction pseudo-aléatoire déterministe possède deux caractéristiques : elle est imprévisible (on ne peut pas anticiper le prochain nombre), mais donne exactement la même séquence si exécutée par différents validateurs avec la même graine.
Ainsi, tous les validateurs exécutant cette fonction génèrent la même série de nombres aléatoires, qui détermine l’ordre des chaînes de données. Cet ordre sert ensuite à classer les transactions du cycle.
Par exemple, si l’ordre obtenu est B, A, C…, alors les transactions de la chaîne B seront traitées en premier, suivies de celles de A, puis de C… Les doublons sont supprimés via les hachages.
Il est possible que dans la chaîne A, la transaction 1 précède la transaction 2, tandis que dans la chaîne B, la transaction 2 précède la transaction 1. Si B est placée avant A dans l’ordre final, alors la transaction 2 sera exécutée avant la transaction 1.
L’avantage majeur de ce mécanisme est qu’il rend difficile le corruption des validateurs par des attaquants MEV, car l’ordre des chaînes n’est pas prévisible. Même si un attaquant corrompt 50 des 100 nœuds validateurs, tant qu’un seul validateur honnête contenant les transactions visées apparaît avant eux dans l’ordre, le consensus s’effectuera correctement et l’attaque MEV échouera.
🔹 Atout : Réduction des redondances, gains de coût et d’efficacité
D’une part, chaque validateur tient sa propre chaîne de données sans avoir à vérifier les données des autres, ce qui élimine les processus de validation croisée. Lors de l’échange de fragments, seules les empreintes (snapshots) sont transmises, sans inclure les détails des transactions, ce qui réduit les communications redondantes.
D’autre part, les chaînes de données n’ont pas besoin de synchroniser les données des autres chaînes, et la chaîne de consensus n’enregistre pas les transactions elles-mêmes, mais seulement les empreintes des chaînes et les références triées (hachages) des transactions à intervalles réguliers. Cela limite fortement la redondance de stockage.
Moins de communication redondante = efficacité accrue.
Moins de stockage redondant = coûts opérationnels réduits.
🔹 Complément : Intégrité des données sur les chaînes de données
Bien qu’il n’y ait pas de vérification croisée entre chaînes, un validateur ne peut pas falsifier les transactions. Toute modification altérerait le hachage de la transaction et de toutes les transactions ultérieures, créant un conflit avec les données enregistrées sur la chaîne de consensus.
💠 EVM parallèle au niveau des instructions
🔹 Problème : Le parallélisme au niveau des transactions ne suffit pas face aux congestions causées par des interactions fréquentes
L’EVM parallèle de Somnia diffère de ceux de Monad et Reddio. Ces trois blockchains parallélisent les transactions, c’est-à-dire exécutent plusieurs transactions simultanément pour accélérer le traitement.
Monad autorise initialement l’exécution parallèle et corrige les conflits a posteriori. Reddio, quant à lui, parallélise uniquement les transactions indépendantes et non conflictuelles.
Toutefois, lorsque de nombreuses transactions dépendantes surviennent, le parallélisme devient impossible, entraînant rapidement des embouteillages. Par exemple, si soudainement beaucoup d’utilisateurs échangent USDC contre un même jeton, ces transactions doivent toutes interagir avec le même pool de liquidités et donc s’exécuter en série.
Autre cas extrême : la course massive au minting d’un même NFT. Comme le nombre d’exemplaires est limité, chaque tentative doit être traitée séquentiellement pour déterminer qui réussit et qui échoue.
Pour résoudre cela, Reddio utilise le GPU, exploitant sa puissance de calcul pour absorber les pics d’interactions. Cela améliore l’efficacité, mais augmente aussi les coûts.
🔹 Innovation : EVM parallèle au niveau des instructions
Pour surmonter les congestions dues aux transactions dépendantes, Somnia a développé un compilateur EVM inédit.
Dans un EVM standard, les instructions d’une transaction sont exécutées séquentiellement, une par une. Somnia, lui, peut diviser une transaction en plusieurs groupes d’instructions pouvant s’exécuter en parallèle s’ils sont indépendants.
Prenez une transaction de swap : elle peut être divisée en plusieurs blocs fonctionnels — vérification des paramètres, traitement des entrées, vérification des soldes, vérification des autorisations, état du pool, calcul du prix, calcul des frais, transfert du jeton d’entrée, mise à jour de l’état du pool, transfert du jeton de sortie, émission d’événements. Les groupes d’instructions indépendants peuvent être exécutés simultanément, accélérant ainsi le traitement global.
Le cœur de cette innovation réside dans le compilateur EVM propriétaire de Somnia, qui transforme le bytecode EVM en code machine x86. Les processeurs modernes étant multi-cœurs et multithread, ils peuvent exécuter plusieurs groupes d’instructions en parallèle, augmentant considérablement la vitesse d’exécution d’une transaction unique. On peut donc qualifier Somnia d’EVM parallèle au niveau matériel.
🔹 Avantage : double gain en coût et en efficacité
Exécution standard EVM (interprétation) : transaction 1 → conversion en bytecode → exécution séquentielle → transaction 2 → conversion en bytecode → exécution séquentielle → etc.
Exécution compilée Somnia : code du contrat → conversion en bytecode → compilation dynamique en code machine → exécution parallèle des groupes d’instructions de la transaction 1 → exécution parallèle de la transaction 2 → etc.
Plus il y a de transactions, plus l’avantage de Somnia devient marqué.
Pour les transactions normales (non fréquentes), Somnia utilise toujours l’interprétation standard EVM : le code du contrat est converti en bytecode puis exécuté séquentiellement.
Pour les transactions fréquentes concentrées, Somnia active son compilateur EVM, transformant le bytecode en code machine x86. Ensuite, il réutilise ce code compilé pour exécuter rapidement des transactions similaires, un résultat impossible à atteindre avec un simple parallélisme au niveau des transactions.
Ainsi, Somnia parvient à concilier efficacité élevée et faible coût.
💠 Moteur de base de données IceDB
🔹 Aperçu : remplacement de l’arbre de Merkle par l’arbre LSM
La plupart des blockchains utilisent la structure d’arbre de Merkle. Dans celle-ci, les nœuds feuilles contiennent les hachages des données de transaction (ou les données elles-mêmes), et les nœuds internes contiennent les hachages combinés de leurs enfants, formant progressivement un hachage racine (Merkle Root), garantissant l’intégrité et l’immutabilité des données.
Par exemple, dans un contrat ERC20, les feuilles de l’arbre de Merkle incluent :
• Les attributs comme le supply total (TotalSupply), le symbole (NameSymbol), chacun constitué d’une clé (nom de l’attribut) et d’une valeur (valeur de l’attribut) ;
• La situation de détention pour chaque adresse, avec une clé (hachage de l’adresse) et une valeur (montant détenu) ;
• Les autorisations accordées, chaque adresse bénéficiaire ayant une clé (hachage) et une valeur (montant autorisé) ;
…
Supposons un jeton ERC avec 4 attributs, 32 000 détenteurs et 2 764 autorisations : cela fait 32 768 feuilles, nécessitant 65 535 calculs de hachage pour construire l’arbre complet.
Le moteur IceDB, développé en interne par Somnia, n’utilise pas l’arbre de Merkle. Il n’y a donc pas de racine de hachage dans les blocs de Somnia.
Au lieu de cela, IceDB repose sur un arbre LSM (Log-Structured Merge-Tree), une structure basée sur les journaux où les données sont ajoutées en fin de fichier plutôt que modifiées sur place, empêchant ainsi toute falsification.
Lors de l’écriture, les données entrent d’abord dans une table en mémoire (MemTable). Quand celle-ci est pleine, elle est vidée sur disque sous forme de SSTable. Les SSTables sont périodiquement fusionnés, avec suppression des clés dupliquées.
Ce processus n’exige aucun calcul de hachage : il suffit d’ajouter les nouvelles données à la MemTable. En conséquence, l’écriture dans IceDB — que ce soit en mémoire, cache ou disque — est nettement plus rapide.
🔹 Atout : lectures/écritures ultra-rapides
La structure LSM offre naturellement de meilleures performances en écriture. En outre, selon la documentation technique de Somnia, « un cache de données a été créé pour optimiser simultanément lecture et écriture, ramenant le temps moyen d’accès à 15-100 nanosecondes ».
🔹 Spécificité : rapport de performance et Gas juste et efficace
Dans la plupart des blockchains, bien que les nœuds convergeant vers les mêmes données à long terme, leurs données locales (mémoire/disque) divergent temporairement. Cela fait que les utilisateurs paient des frais (Gas) variables selon le nœud contacté. De plus, les délais d’accès peuvent varier, durant lesquels le prix du Gas peut fluctuer. Il devient alors difficile d’établir un prix juste. Sous-estimer le Gas pousse les nœuds à la paresse ; le surévaluer impose des coûts inutiles aux utilisateurs, voire crée des opportunités de MEV.
Dans IceDB, chaque fois qu’un utilisateur lit ou écrit des données, si celles-ci ne sont pas dans le cache, le système note la fréquence des accès en mémoire et SSD, et génère un « rapport de performance ». Ce rapport fournit une base déterministe pour calculer le Gas nécessaire, rendant ainsi les frais plus justes, plus stables et plus efficaces, au bénéfice de la monnaie du réseau.
💠 Technologie de compression des données
Selon la documentation technique de Somnia, en appliquant la théorie de la loi de puissance reliant fréquence et quantité d’information, une compression efficace peut être obtenue en regroupant les données selon leur probabilité d’apparition.
Chaque chaîne de données de Somnia est gérée par un seul validateur. Plutôt que d’envoyer des blocs complets, les validateurs transmettent uniquement des flux d’information. Cette approche en continu permet une compression plus poussée, améliorant ainsi la capacité de transmission du réseau.
De plus, Somnia utilise des signatures BLS pour accélérer la transmission et la vérification des signatures.
Dans l’algorithme multifuve, les validateurs échangent directement entre eux les fragments de données, sans leader central coordonnant les téléchargements. Cela équilibre la charge réseau. Chaque validateur envoie des fragments aux autres tout en en recevant, ce qui équilibre parfaitement la bande passante montante et descendante. Le réseau Somnia bénéficie donc d’une transmission stable et homogène.
💠 En guise de conclusion
Le Web3 semble techniquement supérieur au Web2, mais en réalité, l’architecture du Web2 est souvent plus complexe et mature. Lorsque des développeurs Web2 rejoignent le Web3, leur expertise apporte une innovation précieuse au monde blockchain.
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
TVBee
