Eclipse : le premier layer 2 SVM combinant la sécurité d'Ethereum, les hautes performances de Solana et la couche DA de Celestia
TechFlow SélectionTechFlow Sélection
Eclipse : le premier layer 2 SVM combinant la sécurité d'Ethereum, les hautes performances de Solana et la couche DA de Celestia
Eclipse ouvre la voie à Solana pour communiquer avec Cosmos via la communication inter-chaînes (IBC).
Dédié à des analyses Web3 approfondiesAuteur : Ac-Core, chercheur chez YBB Capital
Contexte d'Eclipse
Source de l'image : site officiel d'Eclipse
Le fondateur d'Eclipse, Neel Somani, a été ingénieur logiciel chez Airbnb et chercheur quantitatif chez Citadel. Il a fondé en 2022 la start-up Eclipse basée sur Solana, soutenue par Anatoly Yakovenko, cofondateur de Solana, ainsi que par Polygon et d'autres acteurs/institutions (construisant des blockchains Rollup compatibles entre Solana et Polygon). Selon un article de CoinDesk du 28 septembre 2022, Eclipse a levé avec succès 6 millions de dollars lors d'une pré-série A menée par Polychain, suivie d'une série A de 9 millions de dollars co-dirigée par Tribe Capital et Tabiya, pour un total de 15 millions de dollars. De plus, Eclipse a reçu une subvention de développement de la Fondation Solana afin de soutenir les rollups pilotés par la Machine Virtuelle Solana (SVM).
Grâce à son réseau professionnel et sa proximité géographique avec le siège de Solana à Chicago, le fondateur Somani a réussi à créer une blockchain originale en utilisant la machine virtuelle de Solana. Son objectif est de permettre aux développeurs de déployer des rollups pilotés par la SVM, avec un réseau test public prévu pour être lancé au début de 2023 dans l'écosystème Cosmos, et l'intention future de supporter également le langage Move d'Aptos.
Anatoly Yakovenko, cofondateur de Solana et investisseur initial d'Eclipse, a déclaré : « Eclipse ouvre la voie à une communication inter-chaînes (IBC) entre Solana et Cosmos. »
Niraj Pant, associé chez Polychain Capital, a ajouté : « À mesure que les grandes entreprises et les gouvernements s'intéressent aux blockchains, Eclipse devient une infrastructure clé pour faciliter leurs cas d'usage, tels que des applications grand public et financières à l'échelle Web2. »
Architecture d'Eclipse
Selon les explications officielles, Eclipse Mainnet est le premier L2 généraliste sur Ethereum construit autour de la SVM. Il combine les meilleurs éléments de la pile modulaire, visant à devenir le Layer 2 le plus rapide et universel d'Ethereum, propulsé par la SVM. L'architecture du projet utilise Ethereum comme couche de règlement et pont de vérification intégré officiel ; Celestia comme couche de disponibilité des données (DA) ; RISC Zero pour générer des preuves de fraude zéro-connaissance (ZK) ; et finalement, la SVM de Solana comme environnement d'exécution, formant ainsi un projet modulaire de type Layer 2. Voici une explication détaillée selon les informations officielles.
Couche de règlement — Ethereum : Eclipse effectue le règlement sur Ethereum (via un pont de vérification intégré sur Ethereum), utilise ETH comme monnaie pour les frais de gaz, et soumet les preuves de fraude directement sur Ethereum ;
Couche d'exécution — Machine Virtuelle Solana (SVM) : Eclipse exécute la SVM haute performance comme environnement d'exécution, soit un fork du client Solana Labs (v1.17) ;
Couche de disponibilité des données — Celestia : Eclipse publie ses données sur Celestia pour une disponibilité des données évolutive (DA) ;
Mécanisme de preuve — RISC Zero : Eclipse utilise RISC Zero pour produire des preuves ZK de fraude (sans sérialisation d'état intermédiaire) ;
Protocole de communication — IBC : Permet la connexion avec d'autres chaînes non-Eclipse via le standard de communication inter-chaînes (IBC) de Cosmos ;
Protocole inter-chaînes — Hyperlane : Eclipse collabore avec Hyperlane pour intégrer sa solution d'interopérabilité sans permission sur les blockchains basées sur la SVM (Solana Virtual Machine).
Source de l'image : site officiel d'Eclipse
Couche de règlement : tirer parti de la sécurité et de la liquidité d'Ethereum
Comme d'autres rollups Ethereum, Eclipse utilise Ethereum comme couche de règlement. Ce processus implique d'intégrer directement sur Ethereum un pont de vérification qui doit être validé par les nœuds d'Eclipse, garantissant ainsi la bonne vérification et l'ordre correct des transactions, offrant aux utilisateurs une sécurité au niveau d'Ethereum.
L2BEAT définit un Layer 2 comme « une chaîne qui tire entièrement ou partiellement sa sécurité de la couche 1 d'Ethereum, évitant ainsi aux utilisateurs de devoir se fier à l'honnêteté des validateurs du Layer 2 pour sécuriser leurs fonds ». Le pont de vérification d'Eclipse peut exercer une validité finale et une résistance à la censure dans certains cas de défaillance : même si le séquenceur tombe en panne ou que le L2 commence à censurer, les utilisateurs peuvent forcer leurs transactions via le pont, en utilisant ETH comme gaz brûlé.
Couche d'exécution : tirer parti de la vitesse transactionnelle et des économies d'échelle de Solana
Pour améliorer l'efficacité, Eclipse Mainnet adopte l'environnement d'exécution de Solana, utilisant la SVM et Sealevel (la solution technique de Solana pour l'extension horizontale, un moteur de traitement transactionnel ultra-parallèle permettant l'évolution sur GPU et SSD). Comparé au fonctionnement monofil (single-threaded) de l'EVM, cet avantage réside dans la capacité à exécuter des transactions sans conception d'états chevauchants, contrairement à l'exécution séquentielle classique.
Concernant la compatibilité EVM, Eclipse Mainnet collabore avec Neon EVM pour permettre aux développeurs d'utiliser les outils d'Ethereum et de construire des applications Web3 sur Solana. Selon les données officielles, le débit atteint jusqu'à 140 TPS, bien supérieur à celui de l'EVM monofil. Les utilisateurs EVM peuvent interagir nativement avec les applications sur Eclipse Mainnet via l'extension « Snaps » du portefeuille MetaMask.
Disponibilité des données : exploiter la bande passante et la vérifiabilité de Celestia
Eclipse Mainnet utilise Celestia pour assurer la disponibilité des données et a conclu un partenariat à long terme, car Ethereum ne peut actuellement supporter le débit cible et les coûts visés par Eclipse. Même après la mise à jour EIP-4844, chaque bloc ne dispose que d’environ 0,375 Mo d’espace Blobs (limite par bloc d’environ 0,75 Mo).
Selon les données officielles, pour une transaction ERC-20 sur Rollup, estimée à 154 octets par transaction, cela correspond à environ 213 TPS pour tous les rollups combinés. Pour un Compression Swap (échange compressé), à environ 400 octets par transaction, le TPS global des rollups serait d’environ 82. En comparaison, les blocs de 2 Mo proposés par Celestia devraient passer à 8 Mo grâce à Blobstream, une fois la preuve du réseau stabilisée et davantage de nœuds légers DAS (voir explication ci-dessous) déployés.
Eclipse considère que, compte tenu du compromis entre sécurité cryptoéconomique et débit DA hautement évolutive, Celestia constitue actuellement le meilleur choix pour Eclipse Mainnet, grâce au soutien des nœuds légers DAS. Bien qu’il existe une vision selon laquelle seule la DA d’Ethereum ferait de vous un « vrai » Layer 2, l’équipe du projet continuera de surveiller les progrès futurs concernant l’extension de la DA sur Ethereum. Si Ethereum pouvait fournir une DA à plus grande échelle et plus élevée en débit, une migration vers la DA d’Ethereum serait réévaluée.
Mécanisme de preuve : Preuve de fraude RISC Zero (sans sérialisation d’état intermédiaire)
La méthode de preuve d’Eclipse s’apparente à celle du SIMD (preuve de fraude SVM) d’Anatoly (voir lien GitHub 2), conforme à l’analyse de John Adler, qui consiste à éviter le coût élevé de la sérialisation d’état. Pour éviter de réintroduire des arbres de Merkle (hash trees) dans la SVM, le projet a tenté initialement d’insérer un arbre de Merkle creux (Sparse Merkle Tree), mais chaque mise à jour transactionnelle affectait gravement les performances. Sans utiliser d’arbres de Merkle pour les preuves, les cadres Rollup généraux existants (comme OP Stack) ne peuvent servir de base à un SVM Rollup, ce qui nécessite une architecture plus créative de preuve de défaut.
Les exigences de preuve de défaut sont les suivantes : l’engagement d’entrée de la transaction, la transaction elle-même, et la preuve que la réexécution de cette transaction produit un résultat différent de celui indiqué sur la chaîne.
L’engagement d’entrée est généralement réalisé via la racine Merkle de l’arbre d’état du rollup. L’exécuteur d’Eclipse publie une liste incluant les entrées et sorties de chaque transaction (valeurs de hachage des comptes et état global associé), l’index de la transaction ayant produit chaque entrée, puis publie la transaction sur Celestia. Tout nœud complet peut alors suivre ces données, extraire depuis son propre état les comptes d’entrée, calculer les comptes de sortie, et confirmer que l’engagement publié sur Ethereum est correct.
Deux types majeurs d’erreurs sont possibles :
Sortie incorrecte : un vérificateur fournit une preuve ZK sur la chaîne prouvant la sortie correcte. Eclipse utilise RISC Zero pour créer des preuves ZK de l’exécution SVM, prolongeant ainsi les travaux antérieurs sur la preuve d’exécution de code BPF (voir lien GitHub 3). Cela permet au contrat de règlement de garantir la correction sans avoir à exécuter la transaction sur la chaîne.
Entrée incorrecte : un vérificateur publie sur la chaîne des données historiques montrant que l’état d’entrée ne correspond pas à ce qui est affirmé. Dans ce cas, le Quantum Gravity Bridge (Pont de Gravité Quantique) de Celestia permet au contrat de règlement d’Eclipse de vérifier l’existence d’une fraude.
Connexion d’Eclipse à Ethereum et Celestia
Source de l'image : @jon_charb
La disponibilité des données (DA) est l’un des principaux coûts des rollups. Actuellement, deux méthodes principales existent pour la DA sur les L2 d’Ethereum : Calldata et DAC (Data Availability Committees).
● Calldata : Par exemple, Arbitrum ou Optimism publient directement les données de transaction sur Ethereum sous forme de calldata, dans des blocs très résistants à la censure. Ethereum facture les données d'appel au même titre que le calcul et le stockage, en unités de gaz — ce qui représente l'un des principaux coûts des rollups. Pour améliorer l'efficacité, la mise à jour EIP-4844 a introduit l'espace blob (Blobspace) remplaçant le calldata, offrant à tous les rollups une cible de 375 Ko par bloc.
● DAC : Comparé à la publication directe de calldata sur chaîne, le débit des DAC est beaucoup plus élevé, mais les utilisateurs doivent faire confiance à un petit comité ou groupe de validateurs pour éviter toute rétention malveillante de données. Cela inclut des solutions reposant sur le restaking, qui introduisent des hypothèses de confiance importantes pour les L2, obligeant les DAC à s'appuyer sur la réputation, des mécanismes de gouvernance ou des votes de jetons pour dissuader ou punir la dissimulation de données. Ainsi, l'utilisation d'une DA externe implique souvent un recours aux DAC.
Il convient d'ajouter qu'Eclipse utilise le réseau de consensus Proof-of-Stake Blobstream de Celestia, permettant aux L2 d'accéder à l'espace blob de Celestia, atteignant environ 8 Mo d'espace blob selon le schéma de compression, ce qui équivaut à environ 9 000 à 30 000 transferts ERC-20 par seconde. Toutefois, les L2 utilisant Blobstream dépendent de la preuve des validateurs Celestia. En cas de comportement malveillant (rétention de données) détecté par les nœuds légers, et confirmé par 2/3 des validateurs Celestia, des sanctions peuvent être appliquées. Objectivement, la confiance accordée aux DAC reste inférieure à celle d'une DA native sur chaîne, mais d’un point de vue innovation et narration de marché, cette lacune est inévitable.
Source de l'image : site officiel d'Eclipse – Logique d'interaction modulaire d'Eclipse
Selon la documentation officielle, comme illustré ci-dessus, Eclipse a testé le fonctionnement de ses données prouvées via Blobstream de Celestia (solution modulaire DA pour Ethereum basée sur DAS, comme décrit précédemment), permettant au pont de vérifier la sécurité des données fournies pour les preuves de fraude à partir des racines de données signées par Celestia. Les utilisateurs déposent des fonds sur Eclipse via un pont natif Ethereum. Le processus est le suivant :
1. L’utilisateur appelle le contrat de dépôt d’Eclipse sur Ethereum (adresse disponible dans les liens complémentaires) ;
2. Eclipse exécute l’opération dans l’exécuteur SVM (calcul du résultat SVM et production d’un nouvel état), tandis que le relais (canal entre Ethereum et Eclipse) gère l’échange de données d’adresses entre l’expéditeur et le destinataire ;
3. Le relais appelle le programme de pont SVM pour envoyer le dépôt utilisateur à l’adresse cible ;
4. Le relais valide la transaction de dépôt via un client zk-light (à confirmer ultérieurement) ;
5. Enfin, le bloc contenant la transaction de transfert est finalisé et publié via le plugin Solana Geyser.
Durant ce processus, l’exécuteur SVM publie chaque slot Eclipse via le plugin Geyser dans une file de messages. Chaque slot est ensuite publié sur Celestia sous forme de bloc de données. Les validateurs Celestia s’engagent sur les blocs de données soumis, prouvant ainsi que les transactions sont incluses dans la chaîne Eclipse et correspondent à la racine des données. Enfin, chaque bloc de données Celestia est relayé via Blobstream vers le contrat de pont d’Eclipse sur Ethereum.
Source de l'image : site officiel d'Eclipse – Interaction entre Celestia et l'exécuteur SVM
Par ailleurs, comme pour les autres L2 d’Ethereum utilisant des preuves de fraude, un délai de contestation est requis pour retirer des fonds d’Eclipse vers Ethereum, permettant aux vérificateurs de soumettre une preuve de fraude si une transition d’état est jugée invalide.
● L’exécuteur SVM publie périodiquement sur Ethereum un engagement pour une période (epoch) de slots Eclipse (par lots prédéterminés) accompagné d’une mise en jeu ;
● Le contrat de pont d’Eclipse effectue des vérifications de base pour s’assurer que le format des données publiées est correct (voir section « Conception des preuves de fraude » dans l’article de référence [2]) ;
● Si le lot passe les vérifications de base, une fenêtre prédéfinie s’ouvre. Pendant cette période, si l’engagement du lot implique une transition d’état invalide, un vérificateur peut soumettre une preuve de fraude ;
● Si un vérificateur soumet avec succès une preuve de fraude, il remporte la mise de l’exécuteur, le lot est rejeté, et l’état canonique d’Eclipse L2 revient au dernier engagement de lot valide. À ce stade, les gestionnaires d’Eclipse ont le droit de désigner un nouvel exécuteur ;
● En revanche, si la période de contestation expire sans preuve de fraude, l’exécuteur récupère sa mise et sa récompense ;
● Enfin, le contrat de pont d’Eclipse finalise toutes les transactions de retrait incluses dans le lot.
Conclusion
Eclipse en est encore à un stade précoce de développement, avec un réseau test déjà opérationnel. Il s'agit du premier L2 SVM sur Ethereum, dont le mainnet est prévu pour le premier trimestre 2024. Ethereum continue de considérer les rollups comme axe central de son développement. Indépendamment des débats sur la « légitimité », cela signifie implicitement qu’Ethereum laisse le marché définir largement ce qu’est un Layer 2, ce qui, derrière l’apparente valorisation, cache une forte concurrence entre différentes formes. C’est précisément cette ouverture qu’Eclipse exploite, combinant sécurité d’Ethereum, hautes performances de Solana et disponibilité des données de Celestia dans une puissante narration de marché.
En repensant à l’évolution d’Ethereum, un point intéressant est que lors du dernier cycle haussier, l’euphorie du « DeFi Summer » a vu fleurir de nombreuses innovations qualifiées de « devis de DeFi » ou de « Lego DeFi », entraînant une croissance explosive de l’écosystème. Lors de ce cycle, la combinaison LSD et Restaking a donné naissance à de nombreux assemblages appelés « staking de staking » ou « Lego de staking », faisant grimper rapidement le TVL d’EigenLayer, Blast ou encore l’écosystème BTC de Merlin. Si les effets de superposition et de Lego reflètent l’humeur du marché, la modularité pourrait bien composer sa propre symphonie similaire à l’avenir.
La force de la modularité réside dans la découplage des composants, permettant ainsi l’innovation à chaque niveau de la pile. L’optimisation d’un module amplifie celle des autres. Peut-être que, pour les développeurs et utilisateurs à venir, l’avancée de la modularité offrira un large éventail de choix concurrentiels.
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
@YBBCapital
