Eclipse Mainnet : un nouveau paradigme de couche 2 combinant les atouts de Solana et d'Ethereum
TechFlow SélectionTechFlow Sélection
Eclipse Mainnet : un nouveau paradigme de couche 2 combinant les atouts de Solana et d'Ethereum
L2 a la capacité remarquable d'utiliser les effets de réseau et les garanties de règlement d'Ethereum tout en expérimentant les meilleurs nouveaux environnements d'exécution ; Eclipse Mainnet est la réalisation naturelle de cette vision.
Dédié à des analyses Web3 approfondiesRédaction : Eclipse
Traduction : TechFlow
Eclipse Mainnet est une couche 2 universelle combinant les meilleurs éléments de l'architecture modulaire :
-
Couche de règlement : Ethereum — Eclipse sera rattaché à Ethereum (le pont de validation résidera sur Ethereum) et utilisera ETH comme jeton de gas.
-
Couche d'exécution : Machine Virtuelle Solana (SVM) — Eclipse exécutera la SVM haute performance comme environnement d'exécution.
-
Disponibilité des données : Celestia — Eclipse publiera ses données sur Celestia afin d'assurer une disponibilité évolutive des données (DA).
-
Preuves : RISC Zero — Eclipse utilisera RISC Zero pour des preuves de connaissance nulle contre les fraudes (sans sérialisation intermédiaire d'état !).
Jusqu'à présent, l'essentiel des efforts d'Eclipse a porté sur le déploiement de rollups dédiés aux applications. Pourtant, il devient aujourd'hui plus clair que jamais qu'Ethereum a besoin d'une couche 2 universelle capable d'atteindre une véritable échelle massive. La plupart des applications ne tirent pas avantage des personnalisations offertes par des chaînes spécifiques, et l'isolement ainsi que la complexité qui en résultent peuvent même nuire à l'expérience utilisateur et développeur.
Il existe souvent une fausse dichotomie entre la vision du rollup modulaire et celle d'une chaîne unique à haut débit, parallèle et partageant un état commun. Le terme « modulaire » est fréquemment confondu avec « dédié à une application », ce qui donne l'impression que les rollups impliquent un monde fragmenté, composé de nombreuses chaînes aux débits limités.
Couche d’exécution : la vitesse et l’échelle de Solana
Eclipse Mainnet adoptera un environnement d'exécution de type Solana, offrant ainsi d'importants avantages :
Exécution parallèle optimisée
La SVM et son runtime Sealevel sont réputés pour supporter l'exécution parallèle des transactions. Les transactions qui n'accèdent pas à des états chevauchants peuvent être exécutées en parallèle plutôt qu'en série.
Cela permet à la SVM de s'évoluer directement avec le matériel, car les processeurs continuent d'ajouter davantage de cœurs à moindre coût. Contrairement aux runtimes mono-threadés (comme l'EVM actuelle), qui ne bénéficient pas intrinsèquement de la baisse du coût par cœur. Pendant plus de dix ans, les gains de performance mono-thread ont diminué constamment. Toutes les améliorations proviennent désormais de l'augmentation du nombre de cœurs, rendant essentiel d'exploiter cette tendance via la parallélisation des charges de travail :
Bien qu'il existe quelques tentatives très préliminaires de paralléliser l'EVM, l'ajout de cette fonctionnalité tout en conservant la compatibilité implique des compromis fondamentaux, notamment une performance sous-optimale si d'autres goulots d'étranglement (comme la croissance de l'état) ne sont pas résolus. En déclarant explicitement les dépendances d'état (comme dans la SVM), on atteint une parallélisation optimale.
Marché natif des frais
Aujourd’hui, la plupart des marchés de frais sont globaux : une application populaire fait grimper les frais pour tous les utilisateurs de la chaîne. Un mint de NFT ne devrait pas rendre toute la chaîne inutilisable pour les autres usages. Le travail remarquable de Solana sur les marchés natifs de frais résout ce problème de contention d’état inter-applications. Dans sa mise en œuvre actuelle, le planificateur privilégie les transactions sans conflit, permettant aux transactions non conflictuelles d’être traitées à des frais inférieurs. À long terme, ces marchés seront intégrés au niveau du protocole. Cela garantit qu’une hausse des frais pour une application n’affecte pas les autres parties de la chaîne.
Les marchés natifs de frais profitent du runtime parallèle unique de Solana. Tenter d’implémenter un tel système sur l’EVM à l’aide d’heuristiques (c’est-à-dire sans déclaration préalable des accès à l’état) entraînerait inefficacité et vecteurs d’attaque potentiels.
Des recherches préliminaires sont également en cours pour permettre aux applications d’intégrer facilement leur propre valeur native, chose qui aujourd’hui nécessite souvent une conception plus créative au niveau applicatif.
Gestion de la croissance de l’état
Avant même que l’exécution séquentielle ne devienne un goulot d’étranglement pour l’EVM, la croissance de l’état en constitue déjà un plus pressant.
Comme l’état n’utilise pas d’arbre de Merkle, Solana n’a pas à supporter le coût de mise à jour d’un tel arbre à chaque modification d’état. À la place, l’ensemble de l’état est archivé à chaque époque (tous les 2,5 jours). C’est moins coûteux que l’archivage en temps réel (comme dans l’EVM).
Plus important encore, l’EVM autorise un accès dynamique aux comptes (une transaction peut toucher n’importe quel état à la demande). Cette recherche dynamique d’état signifie que l’état ne peut pas être chargé en mémoire avant l’exécution. Dans la SVM, chaque transaction précise l’ensemble de l’état requis pour son exécution.
Par conséquent, la taille de l’état n’affecte pas l’exécution SVM. En supposant que les validateurs mettent à jour leurs disques de stockage tous les deux ans, le réseau peut doubler en toute sécurité la taille des snapshots tous les deux ans sans rencontrer de problème majeur.
De plus, des équipes comme Helius travaillent activement à améliorer l’accessibilité des données historiques et à réduire la taille de l’état par compression.
Compatibilité EVM
Neon EVM est une machine virtuelle Ethereum déployable comme contrat intelligent sur toute chaîne SVM. Cela apporte à Eclipse Mainnet une compatibilité complète avec l’EVM (y compris prise en charge du bytecode EVM et des JSON-RPC Ethereum), avec un débit supérieur à celui d’une EVM mono-threadée. Chaque instance Neon EVM possédant son propre marché natif de frais, les applications peuvent simplement déployer leurs propres contrats pour bénéficier des avantages d’une chaîne dédiée, sans compromettre l’UX, la sécurité ou la liquidité.
En outre, le compilateur Solang permet de convertir du code Solidity en bytecode SVM.
MetaMask Snaps
Faire migrer les utilisateurs EVM vers des chaînes non-EVM a toujours été un obstacle majeur. Mais l’annonce récente de MetaMask Snaps va briser cette barrière. Les utilisateurs EVM pourront continuer à utiliser MetaMask sans changer de portefeuille. Grâce à une excellente implémentation open source de Drift, l’expérience utilisateur ressemble à celle d’une interaction avec n’importe quelle chaîne EVM. Les utilisateurs d’Eclipse Mainnet pourront interagir nativement avec les applications depuis MetaMask, ou utiliser des portefeuilles natifs Solana comme Salmon.
Firedancer
Firedancer est un client Solana très attendu, développé par Jump, destiné à améliorer considérablement le débit, la résilience et l’efficacité du réseau. Au lancement, nous resterons aussi proches que possible du client principal de Solana, mais nous prévoyons d’adopter Firedancer dès que son code sera stabilisé.
Sécurité
L’environnement d’exécution Solana présente une surface d’attaque nettement réduite, empêchant les attaques par réentrance que nous avons trop souvent observées. Plus précisément, le runtime Solana autorise uniquement la récursion auto-programme, mais pas les appels croisés arbitraires entre programmes. De plus, la séparation entre code et état conduit à du code sans état, généralement plus facile à tester efficacement.
Preuves simplifiées
La SVM étant basée sur des registres et disposant d’un jeu d’instructions beaucoup plus petit que l’EVM, son exécution est plus facile à prouver en ZK. Pour un rollup optimiste, une architecture basée sur des registres permet des points de contrôle plus simples.
Couche de règlement : sécurité et liquidité d’Ethereum
Comme les principaux rollups actuels, Eclipse Mainnet sera rattaché à Ethereum. Plus précisément, notre pont de validation sur Ethereum sera intégré directement à Eclipse. Les nœuds Eclipse consulteront ce pont pour déterminer la « chaîne canonique ». Ce pont impose le bon ordonnancement des transactions sur Eclipse.
Cela permet à nos utilisateurs de bénéficier de certaines propriétés de sécurité provenant d’Ethereum. Le pont validera toutes les transactions Eclipse, empêchant la soumission d’états invalides. En outre, il garantira l’activité finale et la résistance à la censure dans certains cas de défaillance. Même si le séquenceur L2 cesse de fonctionner ou commence à censurer, les utilisateurs pourront forcer l’inclusion de leurs transactions via ce pont.
Grâce à ces propriétés de sécurité, les rollups valides et optimaux sont souvent appelés « couches 2 d’Ethereum ». L2BEAT définit une L2 comme « une chaîne dont la sécurité est entièrement ou partiellement dérivée de la couche 1 d’Ethereum, de sorte que les utilisateurs n’aient pas à compter sur l’honnêteté des validateurs L2 pour assurer la sécurité de leurs fonds. »
Le règlement sur Ethereum reflète l’importance des actifs natifs d’Ethereum dans l’économie DeFi et NFT d’Eclipse Mainnet. ETH est la monnaie décentralisée de choix pour la majorité des utilisateurs, c’est pourquoi nous utilisons également ETH comme jeton de gas. À long terme, l’abstraction des frais permettra aux utilisateurs de payer avec n’importe quel jeton de leur choix (par exemple USDC). Aucun jeton propre à Eclipse Mainnet n’est prévu pour le moment.
Disponibilité des données : bande passante et vérifiabilité de Celestia
Eclipse Mainnet utilisera Celestia pour la disponibilité des données (aussi appelée publication ou diffusion des données). Celestia est un partenaire écosystème de longue date pour Eclipse.
Le débit cible et les frais d’Eclipse Mainnet ne sont malheureusement pas supportés par la bande passante actuelle d’Ethereum, même après l’EIP-4844 (alias « Proto-danksharding »), qui fournit environ 0,375 Mo d’espace blob par bloc (limité à environ 0,75 Mo par bloc).
-
Pour des transferts ERC-20 compressés de base (environ 154 octets par transaction), cela correspond à environ 213 TPS pour tous les Rollups.
-
Pour des échanges compressés (environ 400 octets par transaction), cela correspond à environ 82 TPS pour tous les rollups.
En comparaison, Celestia lancera des blocs de 2 Mo d’ici la fin de l’année. Dès qu’un nombre suffisant de nœuds légers DAS (Data Availability Sampling) seront opérationnels et que le réseau se révélera stable, l’espace blob devrait rapidement augmenter jusqu’à 8 Mo après le lancement. Les nœuds légers DAS remplissent deux fonctions clés :
-
Permettre aux utilisateurs de vérifier eux-mêmes que les données des blocs Eclipse sont disponibles ;
-
Contribuer à l’extension sécurisée du réseau entier, car plus il y a de nœuds DAS, plus la couche DA peut augmenter son débit en toute sécurité.
Celestia devrait être la première couche DA à activer DAS en production. Cela contraste avec les comités traditionnels de disponibilité des données (DAC), qui réintroduisent une hypothèse d’honnêteté du comité sans vérification utilisateur (similaire aux blockchains monolithiques existantes).
Les utilisateurs transférant des fonds depuis Ethereum vers une chaîne utilisant une DA hors chaîne doivent faire face à une hypothèse de sécurité inhérente. Techniquement, les validateurs Celestia pourraient refuser les données de transaction tout en affirmant qu’elles sont disponibles sur le pont Ethereum. En pratique, le consensus PoS de Celestia signifie que la retenue de données par Celestia est sanctionnable, ce qui rend ce risque irréaliste selon nous.
Dans l’ensemble, le support initial de nœuds légers DAS, les propriétés de sécurité cryptoeconomiques et le débit DA hautement évolutif font de Celestia le choix évident pour Eclipse Mainnet dès le départ.
Nous prévoyons également de surveiller les progrès d’Ethereum en matière d’extension DA après l’EIP-4844. De nouvelles recherches passionnantes apparaissent constamment, pouvant fournir une DA à haut débit plus tôt que prévu (contrairement aux idées antérieures reposant sur des tables de hachage distribuées plus avancées). Si Ethereum offre une meilleure échelle à nos utilisateurs, nous évaluerons la possibilité de migrer vers la DA d’Ethereum.
Preuve : Preuve de fraude ZK de RISC Zero (pas besoin de sérialisation d’état intermédiaire !)
Notre système de preuve s’inspire du SIMD de preuve de fraude SVM d’Anatoly, lui-même proche de l’idée de John Adler selon laquelle la sérialisation d’état est coûteuse et peut être évitée.
Plus précisément, nous souhaitons éviter de réintroduire des arbres de Merkle dans la SVM. Nous avons testé l’insertion d’arbres de Merkle creux après chaque transaction dans la SVM, mais leur mise à jour entraîne une perte notable de performance. Ne pas utiliser d’arbres de Merkle exclut les frameworks rollup génériques existants (comme OP Stack) comme base pour un rollup SVM, et nécessite une architecture de preuve de fraude plus inventive.
En bref, une preuve de fraude nécessite :
-
Un engagement sur les entrées de la transaction,
-
La transaction elle-même, et
-
Une preuve que la réexécution de la transaction produit une sortie différente de celle indiquée sur la chaîne.
L’engagement sur les entrées est généralement réalisé via la racine de l’arbre Merkle de l’état du rollup. Notre moteur d’exécution publiera pour chaque transaction la liste des entrées et sorties (y compris les hachages de comptes et l’état global associé), ainsi que l’index de la transaction ayant produit chaque entrée. Les transactions sont publiées sur Celestia, donc tout nœud complet peut extraire lui-même les comptes depuis son état local, calculer les comptes de sortie, et confirmer que l’engagement sur Ethereum est correct.
Deux types principaux de fraude sont possibles :
-
Mauvaise sortie — Dans ce cas, le vérificateur fournit sur chaîne une preuve de connaissance nulle de l’exécution correcte de la SVM. Nous utilisons RISC Zero pour créer une preuve ZK de l’exécution SVM, prolongeant ainsi notre travail antérieur sur la preuve d’exécution de bytecode BPF. Cela permet à notre contrat de règlement de garantir la correction sans avoir à exécuter les transactions sur chaîne.
-
Mauvaise entrée — Ici, le vérificateur publie sur chaîne une référence vers les données historiques montrant que l’état d’entrée ne correspond pas à ce qui était déclaré. Grâce au pont gravitation quantique de Celestia, notre contrat de règlement vérifie que ces données historiques prouvent bien la fraude.
Nous nous tenons sur les épaules des géants. Les rollups actuels ont déjà fait progresser la recherche de toute notre industrie et offrent aux utilisateurs d’Ethereum des frais inférieurs à ceux de la L1.
Cependant, ils n’exploitent pas pleinement les dernières technologies nécessaires à l’échelle massive. Les progrès récents incroyables ont éliminé la nécessité de faire les compromis imposés aux premiers rollups, les plaçant désormais en position de désavantage :
-
Machines virtuelles parallèles hautes performances (par exemple SVM) ;
-
Extension DA avec support de nœuds légers DAS (par exemple Celestia) ;
-
Progrès des infrastructures de preuve rendant celles-ci pratiques partout (par exemple RISC Zero) ;
-
Portabilité accrue du code (par exemple Neon et Solang) et des utilisateurs (par exemple MetaMask Snaps) entre écosystèmes
Nous pouvons tirer des leçons des limitations rencontrées par d’autres chaînes, puis sélectionner les meilleures parties pour une extension à long terme.
On entend souvent parler d’un futur avec un million de rollups spécialisés.
La personnalisation au niveau du consensus peut être très utile pour certaines applications (par exemple dYdX v4), et nous sommes heureux d’aider les équipes à lancer des rollups dédiés.
Mais ces cas sont rares. C’est pourquoi la plupart des nouveaux rollups restent de simples fourches EVM. Les problèmes des développeurs ne se résolvent pas en fragmentant davantage l’UX sur plus de chaînes. Aujourd’hui, l’usage principal trouvé pour des millions de chaînes semble souvent être… lancer davantage de jetons. Pour la grande majorité des cas d’usage, il n’existe pas de besoin réel de personnalisation complète de la pile technologique.
Même lorsque le besoin est réel, les infrastructures nécessaires pour supporter de nombreuses chaînes applicatives avec une UX compétitive ne seront pas prêtes avant plusieurs années (si elles le sont jamais). Des projets comme Superchain d’Optimism (OP Stack), Hyperchains de zkSync (ZK Stack) ou les chaînes Orbit d’Arbitrum visent tous un grand nombre de chaînes partageant une infrastructure commune. Cela vise à offrir une UX plus fluide entre chaînes d’un même écosystème (par exemple deux chaînes dans la Superchain), contrairement aux chaînes totalement isolées (par exemple Ethereum et Solana).
Pourtant, les plans actuels (s’ils existent) sont encore loin de pouvoir rivaliser avec un état partagé unique. De plus, ils ne résolvent pas l’interopérabilité entre écosystèmes (par exemple Superchain vers Hyperchain). Construire modulaire ne doit pas signifier construire des îlots.
Gérer des comptes sur de nombreuses chaînes complique l’expérience utilisateur. Les allers-retours constants entre chaînes et la préoccupation liée au jeton de gas requis nuisent à l’UX. Dépendre de fournisseurs d’infrastructure pour opérer et maintenir autant de chaînes devient aussi plus complexe et coûteux.
Nous avons toujours apprécié la simplicité de la vision de Solana : une machine d’état hautement optimisée, capable d’échelle pour soutenir la plupart des cas d’usage intéressants. Cela est souvent perçu comme incompatible avec la feuille de route centrée sur les rollups, mais ce n’est pas le cas. Nous voulons combiner le meilleur des deux mondes.
Ce malentendu provient du fait que les rollups actuels exécutent largement une EVM primitive mono-threadée, peu modifiée pour profiter des effets réseau initiaux. On voit donc souvent invoquer « l’espace de bloc dédié » comme raison de déployer un rollup dédié. Le fait que d’autres applications sur votre chaîne voient leurs frais augmenter à cause d’un mint NFT extravagant ne justifie pas de créer sa propre chaîne. Vous faites alors des compromis douloureux et inutiles (complexité, coût, mauvaise UX, liquidité fragmentée, etc.). La meilleure solution est évidente : utilisez simplement une VM parallèle dotée d’un marché natif de frais pour les points chauds d’état. C’est exactement ce que propose la SVM.
Ethereum est le centre de gravité intellectuel, social et économique de la crypto. Son talon d’Achille a toujours été l’évolutivité. L’extension de la disponibilité des données est encore en cours, tandis que les environnements d’exécution L2 existants ne peuvent pas concurrencer des innovations plus récentes comme la SVM. Nous craignons qu’en maintenant l’état actuel, l’écosystème Ethereum soit pris au dépourvu face à une augmentation brutale d’activité. Une EVM mono-threadée et une disponibilité des données limitée feraient vite renaître des frais élevés, cette fois-ci sur les rollups.
Nous pensons qu’Eclipse Mainnet est la solution évidente : combiner la performance de Solana avec la sécurité, la vérifiabilité et les effets réseau d’une feuille de route centrée sur les rollups.
Conclusion
La beauté d’Ethereum réside dans son innovation constante. La feuille de route centrée sur les rollups en est un parfait exemple, délégant l’exécution et l’innovation au marché libre. Les L2 ont la capacité incroyable de tirer parti des effets réseau et des garanties de règlement d’Ethereum tout en expérimentant les meilleurs environnements d’exécution. Eclipse Mainnet est la réalisation naturelle de cette vision.
Si un jour un environnement d’exécution plus performant apparaît, nous serions ravis de le voir déployé comme L2 compétitif sur Ethereum. Jusque-là, la SVM reste la référence.
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
@EclipseFND
