Le marché est maintenant complètement désensibilisé à la "blockchain à haute vitesse", pourquoi dit-on que Somnia pourrait être différente des autres ?
Cet article analysera les deux questions suivantes :
Question 1 : Le marché s'est complètement désensibilisé aux "blockchains publiques à haute vitesse", pourquoi dit-on que Somnia pourrait être différent ?
Question 2 : Somnia, qui prétend être la couche 1 EVM parallèle la plus rapide et la plus économique, exagère-t-elle ?
➡️➡️➡️ Simple • Propre • Version ⬅️⬅️⬅️
Cette partie résume Somnia sous trois dimensions : technique, contexte et écosystème, permettant à chacun de comprendre les points forts et les avantages de ce projet.
💠Les points forts technologiques de Somnia
🔹Algorithme de consensus multi-flux : chaîne de données + chaîne de consensus, bénéfique pour prévenir le MEV, réduire la redondance, diminuer les coûts tout en augmentant l'efficacité.
🔹Innovant compilateur EVM : réalise un EVM parallèle au niveau des instructions, résolvant les interactions à haute fréquence dans des cas extrêmes.
🔹Moteur de base de données IceDB développé en interne : amélioration de la vitesse de lecture et d'écriture des données et de la stabilité du réseau.
🔹Technologie de compression des données : améliorer l'efficacité du transfert de données.
💠Avantages de fond de Somnia
🔹Équipe : L'équipe de développement vient d'Improbable, une entreprise technologique multinationale fondée en 2012 et basée à Londres, au Royaume-Uni. Elle a déjà développé des logiciels, des jeux et des produits de métavers Web3.
🔹Financement : 2,7 millions de dollars investis par des institutions renommées telles que MSquared, a16z, SoftBank, Mirana, etc.
💠Avancement de l'écosystème de Somnia
🔹Carte écologique : Le réseau de test Somnia a déjà intégré 4 produits AI/sociaux, 7 jeux, 4 projets NFT et 6 applications DeFi. De plus, 2 produits AI/sociaux, 11 jeux et 1 application DeFi seront bientôt lancés.
🔹Données écologiques : Environ fin février 2025 jusqu'à la rédaction de cet article (2025, le réseau de test Somnia a produit plus de 100 millions de blocs, avec un temps de production moyen de 0,1 seconde par bloc. Il y a eu 96 878 557 adresses de portefeuilles participant au réseau de test, avec un volume de transactions de 26,43 millions au cours de la dernière journée.
Sur les explorateurs de blocs, on peut souvent voir le nombre de transactions et de blocs clignoter sans cesse, Somnia le qualifie de "sous-seconde", visible à l'œil nu.
💠Pourquoi dit-on que Somnia pourrait être différent des autres ?
🔹Interactions à haute fréquence : Bien que le marché ait complètement désensibilisé le concept de "blockchain à haute vitesse", Somnia ne se contente pas de poursuivre des indicateurs techniques, mais se concentre sur la manière dont la technologie Web3 peut réellement servir des scénarios d'application, en particulier dans les domaines des jeux et des interactions sociales à forte fréquence.
🔹Fusion de Web3 et Web3 : Le contexte unique de Somnia pourrait jouer un rôle clé dans la fusion de Web3 et Web2. Somnia a le potentiel d'offrir aux utilisateurs de Web2 un accès sans couture au monde de Web3, ce qui pourrait donner naissance à un véritable écosystème d'applications centré sur l'expérience utilisateur.
➡️➡️➡️ Détails • Explication • Version ⬅️⬅️⬅️
La partie précédente a présenté les points forts, les avantages et les progrès écologiques de Somnia. Cette partie procédera à une analyse approfondie de la technologie de Somnia. Pour que tout le monde comprenne, comment Somnia réalise techniquement des interactions à haute fréquence, comment elle parvient à des coûts bas et des performances élevées, et pourquoi Somnia diffère des autres projets EVM parallèles.
💠Algorithme de consensus multi-flux : chaîne de données + chaîne de consensus
🔹Aperçu : Structure de chaîne de données + chaîne de consensus
Somnia a adopté un nouvel algorithme de consensus multi-flux )MULTISTREAM(.
Le terme multi-chaînes fait référence au fait que Somnia enregistre les informations de transaction sur plusieurs chaînes de données, chaque chaîne de données étant enregistrée par un validateur unique qui ne peut pas interférer avec les chaînes de données des autres validateurs.
Le consensus, Somnia exécute le consensus sur la chaîne de consensus, classe les transactions et enregistre les références des transactions sur la chaîne de consensus. La chaîne de consensus est exécutée et maintenue collectivement par tous les validateurs.
🔹Aperçu : Flux de travail de consensus multi-flux de Somnia
Après qu'un utilisateur a envoyé une demande au réseau Somnia, le validateur qui reçoit la demande écrira les transactions sur la chaîne de données.
b La chaîne de consensus télécharge et télécharge les fragments de données du sommet de la chaîne de données avec les autres validateurs de la chaîne de données tous les cycles de temps, par exemple toutes les 30 secondes, 1 seconde, etc. ).
Le validateur C inclura l'ensemble des ensembles de fragments de données en haut de la chaîne de données comme un fragment de données complet écrit dans la chaîne de consensus.
Les validateurs trient les transactions, mettent à jour l'état en fonction des transactions triées, et tous les validateurs écrivent simultanément dans la base de données IceDB de Somnia.
🔹Points forts : Le tri des transactions de Somnia est favorable à la prévention de l'MEV
Somnia utilise une fonction pseudo-aléatoire déterministe pour trier les transactions.
Nous savons que dans les programmes informatiques, il n'y a en réalité pas de véritable aléatoire, mais un aléatoire pseudo-généré par des algorithmes. Les fonctions pseudo-aléatoires déterministes ont deux caractéristiques : d'une part, leur caractère aléatoire, on ne peut pas prédire quel sera le prochain nombre aléatoire généré, mais chaque validateur, en exécutant le programme, générera toujours le même nombre aléatoire dans un ordre fixe.
Ainsi, tous les validateurs exécutent la même fonction de pseudo-aléatoire déterministe, générant une série de nombres aléatoires identiques, et classent la chaîne de données selon ces nombres aléatoires. Sur cette base, les transactions de ce cycle sont triées.
Par exemple, la chaîne de données triée est B, A, C...
Donc, l'ordre des transactions est que les transactions de la chaîne de données B viennent en premier, suivies de la chaîne de données A, puis de la chaîne de données C... Bien sûr, ce processus éliminera les transactions répétées en fonction des valeurs de hachage.
Bien sûr, l'ordre des chaînes de données est fixe, mais l'ordre des transactions dans différentes chaînes de données peut varier. Par exemple, dans la chaîne de données A, il se peut que la transaction 1 soit en premier et la transaction 2 en second, tandis que dans la chaîne de données B, il se peut que la transaction 2 soit en premier et la transaction 1 en second. Étant donné que l'ordre des chaînes de données est B avant A, l'ordre final des transactions est donc la transaction 2 en premier et la transaction 1 en second.
L'avantage de ce mode de classement est qu'il est difficile pour les attaquants MEV de soudoyer les validateurs, car ils ne savent pas comment les données de la chaîne de blocs des validateurs seront classées. Supposons qu'il y ait 100 nœuds validateurs dans le réseau, si un attaquant MEV réussit à soudoyer 50 validateurs, tant qu'il y a un validateur non soudoyé ( qui inclut la transaction attaquée ) et qui est placée devant ces 50 validateurs, la chaîne de consensus enregistrera les transactions dans le bon ordre, et l'attaque MEV échouera.
🔹Points forts : réduire les redondances, diminuer les coûts et augmenter l'efficacité
D'une part, chaque validateur de Somnia enregistre une chaîne de données distincte, sans processus de validation des données entre les validateurs. Lors de la transmission de l'instantané, seules les informations d'instantané de chaque chaîne de données sont transmises, ces informations d'instantané ne comprenant pas les informations de transaction spécifiques, ce qui réduit ainsi la redondance des interactions.
D'autre part, les différentes chaînes de données de Somnia n'ont pas besoin de synchroniser les informations des autres chaînes de données, et la chaîne de consensus n'enregistre pas les informations de transaction, mais enregistre plutôt un instantané des informations de la chaîne de données et les références de transaction triées toutes les périodes de temps, ainsi que la valeur de hachage (. Cela réduit la redondance de stockage.
Somnia peut être plus efficace dans son fonctionnement grâce à la réduction de la redondance des interactions.
Grâce à la réduction de la redondance de stockage, Somnia nécessite des coûts inférieurs lors de son fonctionnement.
🔹Complément : la chaîne de données anti-falsification
Bien qu'il n'y ait pas de vérification d'information de la chaîne de données, les validateurs ne peuvent pas falsifier les informations de transaction. En effet, si un validateur falsifie les informations de transaction, cela affectera la valeur de hachage de la transaction ainsi que celle des transactions ultérieures, entraînant un conflit entre ces informations et celles stockées dans la chaîne de consensus.
💠Parallélisme EVM au niveau des instructions
🔹Point de douleur : la congestion des interactions à haute fréquence est difficile à améliorer par le parallélisme des transactions
L'EVM parallèle de Somnia est différent de Monad et Reddio, car l'EVM parallèle de ces trois chaînes est basé sur le parallélisme des transactions, c'est-à-dire qu'il exécute les transactions en parallèle afin d'améliorer la vitesse des transactions.
Parmi eux, Monad permet l'exécution parallèle des transactions de manière optimiste, corrigeant les conflits lorsqu'ils sont détectés. Reddio, quant à lui, gère les transactions parallèles qui ne présentent pas de conflits et n'ont pas de dépendances.
Cependant, lorsque de nombreuses transactions connexes apparaissent, les transactions ne peuvent pas être exécutées en parallèle, ce qui entraîne facilement une congestion. Il y a deux exemples extrêmes, par exemple, lorsque de nombreux utilisateurs commencent soudainement à utiliser l'USDC pour échanger un certain token sur le réseau, ces transactions, en raison de la nécessité de passer par le pool LP, ne peuvent pas être exécutées en parallèle et doivent être exécutées séquentiellement.
Un autre exemple extrême est le fait que d'innombrables personnes se précipitent pour mint un même NFT, ce qui ne peut pas non plus être fait en parallèle, car le nombre de NFTs est limité. Il doit être exécuté séquentiellement pour déterminer qui peut réussir à mint et qui échoue.
La méthode que Reddio utilise pour résoudre ce problème est d'utiliser des GPU, tirant parti de la puissance de calcul des GPU pour résoudre la congestion des interactions à haute fréquence. Bien que cela puisse améliorer l'efficacité des transactions, cela augmente également le coût des transactions.
🔹Points forts : EVM parallèle au niveau des instructions
Pour résoudre le problème de congestion causé par le grand nombre de transactions connexes se déroulant simultanément et la difficulté de gérer les transactions en parallèle, Somnia a innové en développant un compilateur EVM.
Dans le processus d'exécution standard de l'EVM, les instructions dans les transactions ne peuvent être interprétées qu'une par une dans l'ordre. Cependant, Somnia prend en charge la division des transactions en plusieurs ensembles d'instructions, où les ensembles d'instructions sans conflit et sans relations de dépendance peuvent être exécutés en parallèle.
Prenons l'exemple d'une transaction Swap, qui peut être divisée en plusieurs ensembles d'instructions selon les fonctionnalités : vérification des paramètres, traitement des paramètres, vérification des soldes, vérification des autorisations, vérification de l'état du pool, calcul des prix, calcul des frais, transfert des jetons d'entrée, mise à jour de l'état du pool et des enregistrements de frais, transfert des jetons de sortie, déclenchement d'événements. Parmi ces ensembles d'instructions, ceux qui ne sont pas en conflit et n'ont pas de relations de dépendance peuvent être exécutés en parallèle, ce qui améliore l'efficacité d'exécution des transactions.
La clé de l'EVM parallèle à jeu d'instructions est Somnia, son compilateur EVM unique qui compile le bytecode EVM en code machine x86. Les processeurs modernes sont des cœurs multithread, chaque cœur de CPU pouvant exécuter du code machine en parallèle sur plusieurs threads, ce qui permet d'exécuter plusieurs instructions EVM en parallèle, augmentant ainsi la vitesse d'exécution d'une seule transaction. Par conséquent, Somnia peut également être qualifié d'EVM parallèle au niveau matériel.
🔹Points forts : Avantages en termes de coût et d'efficacité.
Exécution interprétée standard de l'EVM : Transaction 1 → analysée en bytecode → exécution interprétée séquentielle → Transaction 2 → analysée en bytecode → exécution interprétée séquentielle → Transaction 3 → analysée en bytecode → exécution interprétée séquentielle...
Exécution de compilation EVM de Somnia : code de contrat → analysé en bytecode → compilé dynamiquement en code machine → exécution parallèle de l'ensemble d'instructions de la transaction 1 → exécution parallèle de l'ensemble d'instructions de la transaction 2 → exécution parallèle de l'ensemble d'instructions de la transaction 3…
On peut voir qu'avec plus de transactions, l'exécution de compilation EVM de Somnia est de plus en plus avantageuse.
Ainsi, pour le trading normal non haute fréquence, Somnia utilise toujours l'exécution interprétée standard de l'EVM, en analysant chaque exécution de l'EVM en bytecode EVM, puis en exécutant l'interprétation dans l'ordre.
Pour les transactions à haute fréquence centralisées, Somnia active le compilateur EVM, qui compile le bytecode EVM en code machine x86. Ensuite, en exécutant le code machine de manière répétée selon les paramètres, il est possible d'effectuer rapidement des transactions à haute fréquence centralisées, un effet que l'EVM parallèle au niveau des transactions ne peut pas atteindre.
Ainsi, Somnia peut réaliser un double avantage entre le coût et l'efficacité.
💠Moteur de base de données IceDB
🔹Aperçu : Utilisation de l'arbre LSM à la place de la structure de données de l'arbre de Merkle
La grande majorité des blockchains utilisent la structure de données Arbre de Merkle (Merkle Tree). Les nœuds feuilles de l'arbre de Merkle stockent les valeurs de hachage des données de transaction (ou les données de transaction elles-mêmes, puis les hachent), tandis que les nœuds non-feuilles stockent la valeur de hachage des valeurs de hachage de leurs nœuds enfants, combinant les valeurs de hachage par paires à chaque niveau, jusqu'à obtenir une racine de Merkle (Merkle Root), permettant ainsi de vérifier en toute sécurité l'intégrité des données dans le bloc et d'empêcher toute altération des données.
Prenons l'exemple d'un arbre de Merkle pour le stockage de données d'un contrat de jetons ERC20, les nœuds feuilles de l'arbre de Merkle comprennent :
• La quantité totale de tokens )TotalSupply(, le symbole du token )NameSymbol( et d'autres attributs, chaque attribut correspondant à une clé ) nom d'attribut ( et une valeur ) valeur d'attribut ( ;
• La situation de détention de chaque adresse de détention de ce jeton, chaque adresse correspond à une clé ), un hachage d'adresse ( et une valeur ), le nombre de jetons détenus ( ;
• Toutes les autorisations de ce jeton, chaque adresse d'autorisation correspond à une clé ), un hachage d'adresse ( et une valeur ) représentant la quantité d'autorisation ( ;
……
Supposons qu'un jeton ERC ait 4 attributs, 32000 adresses de détention et 2764 adresses autorisées. Ce nombre n'est clairement pas élevé. Mais cela représente un total de 32768 nœuds feuilles, et pour écrire la racine de Merkle de ce jeton, il faut effectuer 65535 hachages.
Le moteur de base de données IceDB développé par Somnia n'utilise pas la structure de données courante des arbres de Merkle, donc il n'y a pas de racine de hachage dans les informations de bloc.
IceDB utilise un arbre LSM ) Log-Structured Merge-Tree, arbre de fusion structuré par journaux (. Il s'agit d'une structure de données arborescente basée sur le journal, dont la principale caractéristique est l'ajout de données plutôt que la modification sur place, ce qui élimine les problèmes de falsification.
L'écriture dans la base de données IceDB se fait d'abord dans la MemTable en mémoire. Lorsque la MemTable est pleine, elle est vidée sur le disque, formant un SSTable. LSM fusionne régulièrement les SSTable tout en supprimant les clés en double.
Ce processus ne nécessite pas de calcul de hachage, il suffit d'écrire de nouvelles données dans MemTable. Par conséquent, que ce soit pour l'écriture de données en mémoire, dans le cache ou sur le disque, la vitesse d'écriture de la base de données IceDB est clairement plus rapide.
🔹Points forts : des vitesses de lecture et d'écriture plus rapides
La structure de données LSM tree présente un avantage de performance évident en matière d'écriture des données. En outre, le document technique de Somnia mentionne que "nous avons créé un cache de données capable d'optimiser à la fois la lecture et l'écriture, ce qui fait que le temps moyen de lecture et d'écriture d'IceDB se situe entre 15 et 100 nanosecondes."
🔹Caractéristiques : rapport de performance de lecture/écriture et Gas équitable et efficace
Dans la plupart des réseaux blockchain, bien que les nœuds validateurs finaux tendent à stocker les mêmes données, il existe néanmoins des différences entre les données stockées dans la mémoire et sur le disque de différents nœuds validateurs à court terme. Cela entraîne des variations dans la consommation de Gas pour les utilisateurs lors de la lecture et de l'écriture de données, en raison de l'accès à différents emplacements. D'autre part, en raison des emplacements d'accès différents, le temps nécessaire aux utilisateurs pour lire et écrire des données peut être prolongé, et au cours de cette fenêtre temporelle, le Gas du réseau peut changer. Par conséquent, il est difficile de déterminer un Gas équitable et efficace. Si le Gas est sous-estimé, les nœuds peuvent devenir passifs à cause de faibles revenus, ce qui affecte l'efficacité du réseau. Si le Gas est surestimé, les utilisateurs paient des frais supplémentaires inutiles, et cela pourrait même offrir des opportunités pour des attaques MEV.
Sous le moteur de base de données IceDB, les utilisateurs ne trouvent pas les données requises dans le cache à chaque fois qu'ils lisent ou écrivent des données. Par conséquent, il est nécessaire de lire les données depuis la mémoire et le SSD, de comptabiliser la fréquence de lecture des données depuis la mémoire et le SSD, et de retourner un "rapport de performance". Le "rapport de performance" fournit une base déterministe pour le calcul du Gas nécessaire pour l'utilisateur, rendant ainsi le Gas du réseau plus juste et efficace, ce qui est bénéfique pour la stabilité des stablecoins du réseau.
💠Technologie de compression des données
Selon la théorie de la distribution de puissance de l'information et de la fréquence décrite dans la documentation technique de Somnia, en résumant en fonction de la probabilité de survenue de l'information, il est possible d'obtenir un taux de compression élevé des données.
Chaque chaîne de données de Somnia est gérée par un validateur, qui n'a pas besoin d'envoyer l'ensemble du bloc, mais seulement le flux d'informations. De plus, la compression en flux a un taux de compression plus élevé, ce qui favorise l'amélioration des capacités de transmission du réseau.
De plus, Somnia utilise des signatures BLS pour améliorer la vitesse de transmission et de vérification des signatures.
Sous l'algorithme de consensus multi-flux de Somnia, les nœuds validateurs de la chaîne de données s'envoient mutuellement des fragments de données de la chaîne, sans qu'il y ait un leader centralisé pour le téléchargement et le téléchargement centralisés des données, permettant aux validateurs de répartir de manière équilibrée la bande passante. Chaque validateur doit envoyer des fragments de données à d'autres validateurs tout en téléchargeant les fragments de données envoyés par d'autres validateurs, ce qui rend la bande passante nécessaire pour le téléchargement et l'envoi de chaque validateur symétrique. Par conséquent, la capacité de transmission du réseau Somnia sera relativement équilibrée et stable.
💠Écrit en dernier
Bien que Web3 semble plus avancé que Web2 en surface, en réalité, le système technologique de Web2 est souvent plus complexe et mature. Lorsque les développeurs de Web2 participent au développement de Web3, leurs antécédents techniques peuvent apporter plus d'innovation au monde de la blockchain.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Le marché est maintenant complètement désensibilisé à la "blockchain à haute vitesse", pourquoi dit-on que Somnia pourrait être différente des autres ?
Auteur : TVBee
Cet article analysera les deux questions suivantes :
Question 1 : Le marché s'est complètement désensibilisé aux "blockchains publiques à haute vitesse", pourquoi dit-on que Somnia pourrait être différent ?
Question 2 : Somnia, qui prétend être la couche 1 EVM parallèle la plus rapide et la plus économique, exagère-t-elle ?
➡️➡️➡️ Simple • Propre • Version ⬅️⬅️⬅️
Cette partie résume Somnia sous trois dimensions : technique, contexte et écosystème, permettant à chacun de comprendre les points forts et les avantages de ce projet.
💠Les points forts technologiques de Somnia
🔹Algorithme de consensus multi-flux : chaîne de données + chaîne de consensus, bénéfique pour prévenir le MEV, réduire la redondance, diminuer les coûts tout en augmentant l'efficacité.
🔹Innovant compilateur EVM : réalise un EVM parallèle au niveau des instructions, résolvant les interactions à haute fréquence dans des cas extrêmes.
🔹Moteur de base de données IceDB développé en interne : amélioration de la vitesse de lecture et d'écriture des données et de la stabilité du réseau.
🔹Technologie de compression des données : améliorer l'efficacité du transfert de données.
💠Avantages de fond de Somnia
🔹Équipe : L'équipe de développement vient d'Improbable, une entreprise technologique multinationale fondée en 2012 et basée à Londres, au Royaume-Uni. Elle a déjà développé des logiciels, des jeux et des produits de métavers Web3.
🔹Financement : 2,7 millions de dollars investis par des institutions renommées telles que MSquared, a16z, SoftBank, Mirana, etc.
💠Avancement de l'écosystème de Somnia
🔹Carte écologique : Le réseau de test Somnia a déjà intégré 4 produits AI/sociaux, 7 jeux, 4 projets NFT et 6 applications DeFi. De plus, 2 produits AI/sociaux, 11 jeux et 1 application DeFi seront bientôt lancés.
🔹Données écologiques : Environ fin février 2025 jusqu'à la rédaction de cet article (2025, le réseau de test Somnia a produit plus de 100 millions de blocs, avec un temps de production moyen de 0,1 seconde par bloc. Il y a eu 96 878 557 adresses de portefeuilles participant au réseau de test, avec un volume de transactions de 26,43 millions au cours de la dernière journée.
Sur les explorateurs de blocs, on peut souvent voir le nombre de transactions et de blocs clignoter sans cesse, Somnia le qualifie de "sous-seconde", visible à l'œil nu.
💠Pourquoi dit-on que Somnia pourrait être différent des autres ?
🔹Interactions à haute fréquence : Bien que le marché ait complètement désensibilisé le concept de "blockchain à haute vitesse", Somnia ne se contente pas de poursuivre des indicateurs techniques, mais se concentre sur la manière dont la technologie Web3 peut réellement servir des scénarios d'application, en particulier dans les domaines des jeux et des interactions sociales à forte fréquence.
🔹Fusion de Web3 et Web3 : Le contexte unique de Somnia pourrait jouer un rôle clé dans la fusion de Web3 et Web2. Somnia a le potentiel d'offrir aux utilisateurs de Web2 un accès sans couture au monde de Web3, ce qui pourrait donner naissance à un véritable écosystème d'applications centré sur l'expérience utilisateur.
➡️➡️➡️ Détails • Explication • Version ⬅️⬅️⬅️
La partie précédente a présenté les points forts, les avantages et les progrès écologiques de Somnia. Cette partie procédera à une analyse approfondie de la technologie de Somnia. Pour que tout le monde comprenne, comment Somnia réalise techniquement des interactions à haute fréquence, comment elle parvient à des coûts bas et des performances élevées, et pourquoi Somnia diffère des autres projets EVM parallèles.
💠Algorithme de consensus multi-flux : chaîne de données + chaîne de consensus
🔹Aperçu : Structure de chaîne de données + chaîne de consensus
Somnia a adopté un nouvel algorithme de consensus multi-flux )MULTISTREAM(.
Le terme multi-chaînes fait référence au fait que Somnia enregistre les informations de transaction sur plusieurs chaînes de données, chaque chaîne de données étant enregistrée par un validateur unique qui ne peut pas interférer avec les chaînes de données des autres validateurs.
Le consensus, Somnia exécute le consensus sur la chaîne de consensus, classe les transactions et enregistre les références des transactions sur la chaîne de consensus. La chaîne de consensus est exécutée et maintenue collectivement par tous les validateurs.
🔹Aperçu : Flux de travail de consensus multi-flux de Somnia
Après qu'un utilisateur a envoyé une demande au réseau Somnia, le validateur qui reçoit la demande écrira les transactions sur la chaîne de données.
b La chaîne de consensus télécharge et télécharge les fragments de données du sommet de la chaîne de données avec les autres validateurs de la chaîne de données tous les cycles de temps, par exemple toutes les 30 secondes, 1 seconde, etc. ).
Le validateur C inclura l'ensemble des ensembles de fragments de données en haut de la chaîne de données comme un fragment de données complet écrit dans la chaîne de consensus.
Les validateurs trient les transactions, mettent à jour l'état en fonction des transactions triées, et tous les validateurs écrivent simultanément dans la base de données IceDB de Somnia.
🔹Points forts : Le tri des transactions de Somnia est favorable à la prévention de l'MEV
Somnia utilise une fonction pseudo-aléatoire déterministe pour trier les transactions.
Nous savons que dans les programmes informatiques, il n'y a en réalité pas de véritable aléatoire, mais un aléatoire pseudo-généré par des algorithmes. Les fonctions pseudo-aléatoires déterministes ont deux caractéristiques : d'une part, leur caractère aléatoire, on ne peut pas prédire quel sera le prochain nombre aléatoire généré, mais chaque validateur, en exécutant le programme, générera toujours le même nombre aléatoire dans un ordre fixe.
Ainsi, tous les validateurs exécutent la même fonction de pseudo-aléatoire déterministe, générant une série de nombres aléatoires identiques, et classent la chaîne de données selon ces nombres aléatoires. Sur cette base, les transactions de ce cycle sont triées.
Par exemple, la chaîne de données triée est B, A, C...
Donc, l'ordre des transactions est que les transactions de la chaîne de données B viennent en premier, suivies de la chaîne de données A, puis de la chaîne de données C... Bien sûr, ce processus éliminera les transactions répétées en fonction des valeurs de hachage.
Bien sûr, l'ordre des chaînes de données est fixe, mais l'ordre des transactions dans différentes chaînes de données peut varier. Par exemple, dans la chaîne de données A, il se peut que la transaction 1 soit en premier et la transaction 2 en second, tandis que dans la chaîne de données B, il se peut que la transaction 2 soit en premier et la transaction 1 en second. Étant donné que l'ordre des chaînes de données est B avant A, l'ordre final des transactions est donc la transaction 2 en premier et la transaction 1 en second.
L'avantage de ce mode de classement est qu'il est difficile pour les attaquants MEV de soudoyer les validateurs, car ils ne savent pas comment les données de la chaîne de blocs des validateurs seront classées. Supposons qu'il y ait 100 nœuds validateurs dans le réseau, si un attaquant MEV réussit à soudoyer 50 validateurs, tant qu'il y a un validateur non soudoyé ( qui inclut la transaction attaquée ) et qui est placée devant ces 50 validateurs, la chaîne de consensus enregistrera les transactions dans le bon ordre, et l'attaque MEV échouera.
🔹Points forts : réduire les redondances, diminuer les coûts et augmenter l'efficacité
D'une part, chaque validateur de Somnia enregistre une chaîne de données distincte, sans processus de validation des données entre les validateurs. Lors de la transmission de l'instantané, seules les informations d'instantané de chaque chaîne de données sont transmises, ces informations d'instantané ne comprenant pas les informations de transaction spécifiques, ce qui réduit ainsi la redondance des interactions.
D'autre part, les différentes chaînes de données de Somnia n'ont pas besoin de synchroniser les informations des autres chaînes de données, et la chaîne de consensus n'enregistre pas les informations de transaction, mais enregistre plutôt un instantané des informations de la chaîne de données et les références de transaction triées toutes les périodes de temps, ainsi que la valeur de hachage (. Cela réduit la redondance de stockage.
Somnia peut être plus efficace dans son fonctionnement grâce à la réduction de la redondance des interactions.
Grâce à la réduction de la redondance de stockage, Somnia nécessite des coûts inférieurs lors de son fonctionnement.
🔹Complément : la chaîne de données anti-falsification
Bien qu'il n'y ait pas de vérification d'information de la chaîne de données, les validateurs ne peuvent pas falsifier les informations de transaction. En effet, si un validateur falsifie les informations de transaction, cela affectera la valeur de hachage de la transaction ainsi que celle des transactions ultérieures, entraînant un conflit entre ces informations et celles stockées dans la chaîne de consensus.
💠Parallélisme EVM au niveau des instructions
🔹Point de douleur : la congestion des interactions à haute fréquence est difficile à améliorer par le parallélisme des transactions
L'EVM parallèle de Somnia est différent de Monad et Reddio, car l'EVM parallèle de ces trois chaînes est basé sur le parallélisme des transactions, c'est-à-dire qu'il exécute les transactions en parallèle afin d'améliorer la vitesse des transactions.
Parmi eux, Monad permet l'exécution parallèle des transactions de manière optimiste, corrigeant les conflits lorsqu'ils sont détectés. Reddio, quant à lui, gère les transactions parallèles qui ne présentent pas de conflits et n'ont pas de dépendances.
Cependant, lorsque de nombreuses transactions connexes apparaissent, les transactions ne peuvent pas être exécutées en parallèle, ce qui entraîne facilement une congestion. Il y a deux exemples extrêmes, par exemple, lorsque de nombreux utilisateurs commencent soudainement à utiliser l'USDC pour échanger un certain token sur le réseau, ces transactions, en raison de la nécessité de passer par le pool LP, ne peuvent pas être exécutées en parallèle et doivent être exécutées séquentiellement.
Un autre exemple extrême est le fait que d'innombrables personnes se précipitent pour mint un même NFT, ce qui ne peut pas non plus être fait en parallèle, car le nombre de NFTs est limité. Il doit être exécuté séquentiellement pour déterminer qui peut réussir à mint et qui échoue.
La méthode que Reddio utilise pour résoudre ce problème est d'utiliser des GPU, tirant parti de la puissance de calcul des GPU pour résoudre la congestion des interactions à haute fréquence. Bien que cela puisse améliorer l'efficacité des transactions, cela augmente également le coût des transactions.
🔹Points forts : EVM parallèle au niveau des instructions
Pour résoudre le problème de congestion causé par le grand nombre de transactions connexes se déroulant simultanément et la difficulté de gérer les transactions en parallèle, Somnia a innové en développant un compilateur EVM.
Dans le processus d'exécution standard de l'EVM, les instructions dans les transactions ne peuvent être interprétées qu'une par une dans l'ordre. Cependant, Somnia prend en charge la division des transactions en plusieurs ensembles d'instructions, où les ensembles d'instructions sans conflit et sans relations de dépendance peuvent être exécutés en parallèle.
Prenons l'exemple d'une transaction Swap, qui peut être divisée en plusieurs ensembles d'instructions selon les fonctionnalités : vérification des paramètres, traitement des paramètres, vérification des soldes, vérification des autorisations, vérification de l'état du pool, calcul des prix, calcul des frais, transfert des jetons d'entrée, mise à jour de l'état du pool et des enregistrements de frais, transfert des jetons de sortie, déclenchement d'événements. Parmi ces ensembles d'instructions, ceux qui ne sont pas en conflit et n'ont pas de relations de dépendance peuvent être exécutés en parallèle, ce qui améliore l'efficacité d'exécution des transactions.
La clé de l'EVM parallèle à jeu d'instructions est Somnia, son compilateur EVM unique qui compile le bytecode EVM en code machine x86. Les processeurs modernes sont des cœurs multithread, chaque cœur de CPU pouvant exécuter du code machine en parallèle sur plusieurs threads, ce qui permet d'exécuter plusieurs instructions EVM en parallèle, augmentant ainsi la vitesse d'exécution d'une seule transaction. Par conséquent, Somnia peut également être qualifié d'EVM parallèle au niveau matériel.
🔹Points forts : Avantages en termes de coût et d'efficacité.
Exécution interprétée standard de l'EVM : Transaction 1 → analysée en bytecode → exécution interprétée séquentielle → Transaction 2 → analysée en bytecode → exécution interprétée séquentielle → Transaction 3 → analysée en bytecode → exécution interprétée séquentielle...
Exécution de compilation EVM de Somnia : code de contrat → analysé en bytecode → compilé dynamiquement en code machine → exécution parallèle de l'ensemble d'instructions de la transaction 1 → exécution parallèle de l'ensemble d'instructions de la transaction 2 → exécution parallèle de l'ensemble d'instructions de la transaction 3…
On peut voir qu'avec plus de transactions, l'exécution de compilation EVM de Somnia est de plus en plus avantageuse.
Ainsi, pour le trading normal non haute fréquence, Somnia utilise toujours l'exécution interprétée standard de l'EVM, en analysant chaque exécution de l'EVM en bytecode EVM, puis en exécutant l'interprétation dans l'ordre.
Pour les transactions à haute fréquence centralisées, Somnia active le compilateur EVM, qui compile le bytecode EVM en code machine x86. Ensuite, en exécutant le code machine de manière répétée selon les paramètres, il est possible d'effectuer rapidement des transactions à haute fréquence centralisées, un effet que l'EVM parallèle au niveau des transactions ne peut pas atteindre.
Ainsi, Somnia peut réaliser un double avantage entre le coût et l'efficacité.
💠Moteur de base de données IceDB
🔹Aperçu : Utilisation de l'arbre LSM à la place de la structure de données de l'arbre de Merkle
La grande majorité des blockchains utilisent la structure de données Arbre de Merkle (Merkle Tree). Les nœuds feuilles de l'arbre de Merkle stockent les valeurs de hachage des données de transaction (ou les données de transaction elles-mêmes, puis les hachent), tandis que les nœuds non-feuilles stockent la valeur de hachage des valeurs de hachage de leurs nœuds enfants, combinant les valeurs de hachage par paires à chaque niveau, jusqu'à obtenir une racine de Merkle (Merkle Root), permettant ainsi de vérifier en toute sécurité l'intégrité des données dans le bloc et d'empêcher toute altération des données.
Prenons l'exemple d'un arbre de Merkle pour le stockage de données d'un contrat de jetons ERC20, les nœuds feuilles de l'arbre de Merkle comprennent :
• La quantité totale de tokens )TotalSupply(, le symbole du token )NameSymbol( et d'autres attributs, chaque attribut correspondant à une clé ) nom d'attribut ( et une valeur ) valeur d'attribut ( ;
• La situation de détention de chaque adresse de détention de ce jeton, chaque adresse correspond à une clé ), un hachage d'adresse ( et une valeur ), le nombre de jetons détenus ( ;
• Toutes les autorisations de ce jeton, chaque adresse d'autorisation correspond à une clé ), un hachage d'adresse ( et une valeur ) représentant la quantité d'autorisation ( ;
……
Supposons qu'un jeton ERC ait 4 attributs, 32000 adresses de détention et 2764 adresses autorisées. Ce nombre n'est clairement pas élevé. Mais cela représente un total de 32768 nœuds feuilles, et pour écrire la racine de Merkle de ce jeton, il faut effectuer 65535 hachages.
Le moteur de base de données IceDB développé par Somnia n'utilise pas la structure de données courante des arbres de Merkle, donc il n'y a pas de racine de hachage dans les informations de bloc.
IceDB utilise un arbre LSM ) Log-Structured Merge-Tree, arbre de fusion structuré par journaux (. Il s'agit d'une structure de données arborescente basée sur le journal, dont la principale caractéristique est l'ajout de données plutôt que la modification sur place, ce qui élimine les problèmes de falsification.
L'écriture dans la base de données IceDB se fait d'abord dans la MemTable en mémoire. Lorsque la MemTable est pleine, elle est vidée sur le disque, formant un SSTable. LSM fusionne régulièrement les SSTable tout en supprimant les clés en double.
Ce processus ne nécessite pas de calcul de hachage, il suffit d'écrire de nouvelles données dans MemTable. Par conséquent, que ce soit pour l'écriture de données en mémoire, dans le cache ou sur le disque, la vitesse d'écriture de la base de données IceDB est clairement plus rapide.
🔹Points forts : des vitesses de lecture et d'écriture plus rapides
La structure de données LSM tree présente un avantage de performance évident en matière d'écriture des données. En outre, le document technique de Somnia mentionne que "nous avons créé un cache de données capable d'optimiser à la fois la lecture et l'écriture, ce qui fait que le temps moyen de lecture et d'écriture d'IceDB se situe entre 15 et 100 nanosecondes."
🔹Caractéristiques : rapport de performance de lecture/écriture et Gas équitable et efficace
Dans la plupart des réseaux blockchain, bien que les nœuds validateurs finaux tendent à stocker les mêmes données, il existe néanmoins des différences entre les données stockées dans la mémoire et sur le disque de différents nœuds validateurs à court terme. Cela entraîne des variations dans la consommation de Gas pour les utilisateurs lors de la lecture et de l'écriture de données, en raison de l'accès à différents emplacements. D'autre part, en raison des emplacements d'accès différents, le temps nécessaire aux utilisateurs pour lire et écrire des données peut être prolongé, et au cours de cette fenêtre temporelle, le Gas du réseau peut changer. Par conséquent, il est difficile de déterminer un Gas équitable et efficace. Si le Gas est sous-estimé, les nœuds peuvent devenir passifs à cause de faibles revenus, ce qui affecte l'efficacité du réseau. Si le Gas est surestimé, les utilisateurs paient des frais supplémentaires inutiles, et cela pourrait même offrir des opportunités pour des attaques MEV.
Sous le moteur de base de données IceDB, les utilisateurs ne trouvent pas les données requises dans le cache à chaque fois qu'ils lisent ou écrivent des données. Par conséquent, il est nécessaire de lire les données depuis la mémoire et le SSD, de comptabiliser la fréquence de lecture des données depuis la mémoire et le SSD, et de retourner un "rapport de performance". Le "rapport de performance" fournit une base déterministe pour le calcul du Gas nécessaire pour l'utilisateur, rendant ainsi le Gas du réseau plus juste et efficace, ce qui est bénéfique pour la stabilité des stablecoins du réseau.
💠Technologie de compression des données
Selon la théorie de la distribution de puissance de l'information et de la fréquence décrite dans la documentation technique de Somnia, en résumant en fonction de la probabilité de survenue de l'information, il est possible d'obtenir un taux de compression élevé des données.
Chaque chaîne de données de Somnia est gérée par un validateur, qui n'a pas besoin d'envoyer l'ensemble du bloc, mais seulement le flux d'informations. De plus, la compression en flux a un taux de compression plus élevé, ce qui favorise l'amélioration des capacités de transmission du réseau.
De plus, Somnia utilise des signatures BLS pour améliorer la vitesse de transmission et de vérification des signatures.
Sous l'algorithme de consensus multi-flux de Somnia, les nœuds validateurs de la chaîne de données s'envoient mutuellement des fragments de données de la chaîne, sans qu'il y ait un leader centralisé pour le téléchargement et le téléchargement centralisés des données, permettant aux validateurs de répartir de manière équilibrée la bande passante. Chaque validateur doit envoyer des fragments de données à d'autres validateurs tout en téléchargeant les fragments de données envoyés par d'autres validateurs, ce qui rend la bande passante nécessaire pour le téléchargement et l'envoi de chaque validateur symétrique. Par conséquent, la capacité de transmission du réseau Somnia sera relativement équilibrée et stable.
💠Écrit en dernier
Bien que Web3 semble plus avancé que Web2 en surface, en réalité, le système technologique de Web2 est souvent plus complexe et mature. Lorsque les développeurs de Web2 participent au développement de Web3, leurs antécédents techniques peuvent apporter plus d'innovation au monde de la blockchain.