TL;DR : Nous sommes ravis d'annoncer enfin l'architecture d'Eclipse Mainnet : La L2 la plus rapide d'Ethereum, alimentée par le SVM.
Eclipse Mainnet est une L2 polyvalente (general-purpose) qui combine les meilleurs éléments de la stack modulaire :
Settlement : Ethereum - Eclipse réglera (settle) sur Ethereum (c'est-à-dire que le bridge consacré à la validation sera sur Ethereum) et utilisera l'ETH comme jeton de gas.
Exécution : Solana Virtual Machine (SVM) - Eclipse utilisera la très performante SVM comme environnement d'exécution.
Data Availability (Disponibilité des données) : Celestia - Eclipse postera ses données sur Celestia pour une data availability scalable (DA).
Proving : RISC Zero - Eclipse utilisera RISC Zero pour les ZK proofs (preuves de fraude ZK) (sans sérialisation des états intermédiaires !).
La plupart des titres d'Eclipse ont porté sur notre travail de déploiement de rollups spécifiques à une application pour une gamme de projets, mais il est maintenant plus clair que jamais qu'Ethereum a besoin d'une L2 à usage général capable de scaler à une échelle vraiment massive. La plupart des applications ne bénéficient pas de personnalisations de chain en fonction de l'application, et l'isolement et la complexité qui en résultent peuvent en fait entraîner une détérioration de l'expérience utilisateur et de l'expérience développeur.
Une fausse dichotomie est souvent présentée entre la vision d'un rollup modulaire et la capacité d'avoir une chain unique avec un scale massif, une exécution parallélisée et un état partagé. Le terme "modular" est souvent confondu avec "spécifique à app-specific", ce qui laisse penser que les rollups sont synonymes d'un monde de nombreuses chain fragmentées et à faible débit. Nous remettons en cause cette idée.
Eclipse Mainnet adoptera l'environnement d'exécution de Solana, le meilleur de sa catégorie. Cela apporte des avantages considérables :
Exécution parallèle optimisée
Le SVM et son runtime Sealevel permettent une exécution parallèle des transactions. Les transactions qui ne touchent pas à des états qui se chevauchent peuvent être exécutées en parallèle plutôt que séquentiellement.
Cela permet au SVM de s'adapter directement au hardware, car les processeurs continuent d'ajouter des cœurs à moindre coût. Les temps d'exécution single-threaded (tels que l'EVM actuel) ne bénéficient pas fondamentalement de la réduction du coût par cœur. Depuis plus d'une décennie, l'accélération des performances des systèmes single-threaded n'a cessé de diminuer. Presque toutes les améliorations continuent à provenir de l'augmentation du nombre de cœurs, il est donc essentiel de tirer parti de cette tendance en parallélisant les charges de travail :
Il existe quelques tentatives non prouvées de parallélisation de l'EVM, mais l'ajouter tout en maintenant la compatibilité entraîne des compromis fondamentaux, notamment des performances sous-optimales sans traiter d'autres goulets d'étranglement (par exemple, la croissance de l'état). Les contrats déclarant d'emblée les dépendances d'état (comme dans le SVM) permettent une parallélisation optimale.
Local Fee Markets
La plupart des marchés de fees sont aujourd'hui globaux, ce qui signifie qu'une application fortement demandée augmente les redevances pour tous les utilisateurs de la chain. Un mint de NFT ne devrait pas rendre la chain inutilisable pour tous les autres utilisateurs. Le travail remarquable de Solana sur les local fee markets résout ce conflit d'état entre applications. Dans son implémentation actuelle, le planificateur donne la priorité aux transactions sans conflit, ce qui permet aux transactions sans conflit d'être traitées avec des frais moins élevés. À plus long terme, les local fee markets seront implémentés au niveau du protocole. Cela permettra de s'assurer que les pics de frais pour une seule application n'ont pas d'impact sur le reste de la chain.
Les local fee markets sont possibles grâce au temps d'exécution parallélisé unique de Solana. Essayer de mettre en œuvre des local fee markets pour les hotspots de l'état dans l'EVM en utilisant des heuristiques (c'est-à-dire sans déclarer l'accès à l'état en amont) présenterait des inefficacités et des vecteurs d'attaque probables.
Des recherches préliminaires sont également en cours pour permettre aux applications d'internaliser facilement la valeur locale qui leur est attribuable, ce qui aujourd'hui nécessite généralement une conception plus créative au niveau de l'application.
Gestion de la croissance des états
Avant même que l'EVM ne se heurte à l'exécution séquentielle en tant que goulot d'étranglement, la croissance de l'état est son goulot d'étranglement le plus pressant.
Comme il n'y a pas d'arbre de Merkle pour l'état, Solana n'a pas besoin de mettre à jour un arbre de Merkle pour chaque mise à jour de l'état. Au lieu de cela, après chaque epoch (~2,5 jours), l'état entier est “merklized”. Cette méthode est beaucoup moins coûteuse que la merklisation en temps réel (comme dans l'EVM).
Plus important encore, l'EVM dispose d'un accès dynamique aux comptes (c'est-à-dire que les transactions peuvent 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 le SVM, chaque transaction spécifie tous les états nécessaires à l'exécution.
Par conséquent, la taille de l'état n'a pas d'impact sur l'exécution du SVM. Le réseau pourrait en toute sécurité doubler la taille des snapshots tous les deux ans sans rencontrer de problèmes majeurs, en supposant que les validateurs mettent à jour leurs disques de stockage tous les deux ans.
Également, des équipes comme Helius améliorent activement l'accessibilité des données historiques et réduisent la taille des états grâce à la compression.
Compatibilité avec l’EVM
Neon EVM est un EVM fonctionnant comme un smart contract qui peut être déployé sur n'importe quelle chain SVM. Cela apporte une compatibilité EVM complète à Eclipse Mainnet (y compris la prise en charge du bytecode EVM et de l'Ethereum JSON-RPC) avec un débit supérieur à celui des EVM single-threaded. Étant donné que chaque instance Neon EVM dispose de son propre local fee markets, les applications peuvent simplement déployer leur propre contrat pour atteindre les avantages d'une chain d'applications sans fragmenter l'UX, la sécurité ou la liquidité.
Par ailleurs, le compilateur Solang permet de compiler le code des smart contracts Solidity en bytecode SVM.
MetaMask Snaps
L'intégration des utilisateurs EVM dans des chains non EVM a toujours été un obstacle majeur, mais le récemment dévoilé Metamask Snaps, est prêt à faire tomber cette barrière. Les utilisateurs EVM peuvent continuer à utiliser MetaMask sans avoir à changer de wallet. L'interface utilisateur est comparable à celle de n'importe quelle chain EVM, grâce aux contributions open-source de Drift qui ont permis de mettre au point une excellente implémentation des MetaMask Snap. Les utilisateurs d'Eclipse Mainnet pourront interagir avec des applications nativement dans MetaMask ou utiliser un wallet natif de Solana comme Salmon.
https://x.com/DriftProtocol/status/1700135022454276414?s=20
Firedancer
Firedancer est le très attendu client Solana développé par Jump pour augmenter considérablement le débit, la résilience et l'efficacité du réseau. Au lancement, nous nous en tiendrons le plus possible au client principal de Solana, mais nous prévoyons d'adopter Firedancer une fois que le code sera en place et stable.
Sécurité
Le runtime de Solana a une surface d'attaque considérablement réduite qui empêche les exploits de réentrance infâmes que nous avons vus bien trop souvent. Plus précisément, le moteur d'exécution de Solana ne permet aux programmes que de s'auto-récurser, plutôt que d'autoriser des invocations arbitraires réentrantes entre programmes. En outre, la séparation de l'état et du code permet d'obtenir un code sans état, qui est généralement plus facile à tester efficacement.
Des tests plus faciles
Le SVM est basé sur les registres et possède un jeu d'instructions beaucoup plus petit que l'EVM, ce qui rend l'exécution du SVM plus facile à prouver en ZK. Pour les rollups optimistes, la conception basée sur les registres permet un contrôle plus facile.
Comme pour les principaux rollups d'aujourd'hui, Eclipse Mainnet se règlera sur Ethereum. Concrètement, cela signifie que notre bridge de validation sur Ethereum sera directement intégré à Eclipse. Les nodes Eclipse se tourneront vers ce bridge pour déterminer la "chain canonique". Le bridge applique l'ordre correct pour Eclipse.
Cela permet à nos utilisateurs de bénéficier de certaines propriétés de sécurité d'Ethereum. Le bridge validera toutes les transactions Eclipse, empêchant la soumission d'états non valides. En plus, il renforcera la vivacité et la résistance à la censure (censorship resistance) dans certains cas d'échec. Même si le séquenceur devait tomber en panne ou commencer à censurer au niveau du L2, les utilisateurs seraient en mesure de forcer l'inclusion de leurs transactions via le bridge.
En raison de ces propriétés de sécurité, les validiums et les optimiums sont souvent appelés "Ethereum L2". L2BEAT définit une L2 comme "une chain qui dérive entièrement ou partiellement sa sécurité de la couche 1 d'Ethereum afin que les utilisateurs n'aient pas à compter sur l'honnêteté des validateurs du L2 pour la sécurité de leurs fonds".
Le serttlement Ethereum reconnaît l'importance que les actifs natifs d'Ethereum joueront probablement dans les économies de DeFi et de NFT d’Eclipse Mainnet. L'ETH est la meilleure monnaie décentralisée que la plupart des utilisateurs préfèrent clairement, c'est pourquoi nous utiliserons également l'ETH comme token de gas. À plus long terme, l'abstraction des frais permettra aux utilisateurs de payer avec le jeton de leur choix (par exemple, USDC). Pour l'instant, il n'est pas prévu qu’Eclipse Mainnet dispose de son propre token.
Eclipse Mainnet utilisera Celestia pour la disponibilité des données (a.k.a. data publishing ou data publication). Celestia est un partenaire de longue date de l'écosystème Eclipse.
Le débit et les frais visés par Eclipse Mainnet ne sont malheureusement pas pris en charge par la bande passante actuelle d'Ethereum. Il en sera ainsi même après l'EIP-4844 (alias "Proto-danksharding"), qui fournit une moyenne d'environ 0,375 Mo d'espace blobs par block (avec une limite d'environ 0,75 Mo par block).
Pour les transferts ERC-20 avec compression de base (~154 octets par transaction), cela se traduit par ~213 TPS pour l'ensemble des rollups.
Pour les échanges avec compression (~400 octets par transaction), cela se traduit par ~82 TPS sur l'ensemble des rollups.
À titre de comparaison, Celestia sera lancé avec des blocks de 2 Mo dans le courant de l'année. Blobspace devrait passer à 8 Mo peu après le lancement, une fois que suffisamment de light nodes de data availability sampling (DAS) seront en ligne et que le réseau se sera stabilisé. Les light nodes DAS remplissent deux fonctions essentielles :
Permettre aux utilisateurs de vérifier par eux-mêmes que les données des blocks Eclipse ont été mises à disposition
Contribuer à la mise à l'échelle sécurisée de l'ensemble du réseau, étant donné que les couches de DA peuvent augmenter leur débit en toute sécurité à mesure que davantage de light nodes DAS sont mis en ligne.
Celestia devrait être la première couche de DA à être lancée avec le DAS en production. Cela contraste avec les comités de disponibilité des données (DACs - Data Availability Committees) traditionnels, qui réintroduisent des hypothèses d'honnêteté du comité sans vérification par l'utilisateur (comme dans les blockchains monolithiques existantes).
Il existe une hypothèse de sécurité inhérente pour les utilisateurs qui transfèrent leurs fonds de l'Ethereum Mainnet vers n'importe quelle chaion qui utilise la DA offchain. En particulier, il est techniquement possible pour les validateurs de Celestia de ne pas divulguer les données de transaction mais d'affirmer au bridge Ethereum que les données sont disponibles. En pratique, le consensus par preuve d'enjeu (proof-of-stake) de Celestia signifie que la rétention de données sur Celestia elle-même peut être réduite, ce qui rend ce risque irréaliste à notre avis.
Dans l'ensemble, la prise en charge des light nodes DAS de Celestia dès le premier jour, les propriétés de sécurité crypto-économiques et le débit DA hautement scalable en font le choix évident pour Eclipse Mainnet aujourd'hui.
Notez que certains considèrent la DA Ethereum onchain comme une exigence pour être une véritable "L2" ici pour les raisons décrites ci-dessus. Nous utilisons la terminologie L2 plus courante citée plus haut, et nous voulons être clairs sur les considérations de sécurité.
Nous avons également l'intention de suivre les progrès d'Ethereum en matière de DA après l'EIP-4844. De nouvelles recherches passionnantes continuent d'être publiées, offrant potentiellement une DA à haut débit plus tôt que les idées précédentes (qui utilisent des tables de hachage distribuées plus avancées). Si Ethereum offre une plus grande échelle pour Eclipse au bénéfice de nos utilisateurs, nous évaluerons la possibilité de migrer vers Ethereum DA.
Nos preuves ressembleront aux preuves de fraude SVM SIMD d'Anatoly, qui sont elles-mêmes similaires à l'idée de John Adler selon laquelle la sérialisation des états est coûteuse et qu'il est possible de l'éviter.
Plus précisément, nous voulons éviter de réintroduire un arbre de Merkle dans le SVM. Nous avons expérimenté l'insertion d'un arbre de Merkle épars dans le SVM dès le début, mais la mise à jour de l'arbre de Merkle après chaque transaction entraîne des baisses de performance substantielles. Prouver sans arbre de Merkle exclut les cadres de rollup généralistes existants tels que la OP stack comme base pour les rollups de SVM, et nécessite également une architecture de fault proof plus créative.
À un niveau élevé, une fault proof nécessite :
Un engagement à fournir des intrants pour une transaction,
La transaction elle-même, et
La preuve que la réexécution de la transaction conduit à un résultat différent de celui qui a été spécifié dans la chain.
L'engagement d'entrée se fait généralement en fournissant la root de Merkle pour l'arbre d'état du rollup. Notre “exécuteur” affichera plutôt une liste d'entrées et de sorties (y compris les hachages de comptes et l'état global pertinent) pour chaque transaction, ainsi qu'un index de la transaction qui a produit chaque entrée. Les transactions sont publiées sur Celestia, de sorte que n'importe quel nœud complet peut les suivre pour extraire les comptes d'entrée de son propre état, calculer les comptes de sortie et confirmer que l'engagement sur Ethereum est correct.
Il existe deux types de major faults (fautes majeures) possibles :
Sorties incorrectes - Dans ce cas, le vérificateur fournit une preuve ZK sur la chain des sorties correctes. Nous utilisons RISC Zero pour créer des preuves ZK de l'exécution des SVM, dans la continuité de nos travaux antérieurs prouvant l'exécution du bytecode BPF. Cela permet à notre contrat de règlement de garantir l'exactitude sans avoir à exécuter les transactions elles-mêmes sur la chain.
Entrées incorrectes - Dans ce cas, le vérificateur affiche sur la chain une référence aux données historiques montrant que l'état de l'entrée n'est pas celui qui a été déclaré. En utilisant le Quantum Gravity Bridge de Celestia, notre contrat de règlement garantit que ces données historiques prouvent effectivement la fraude.
Nous nous tenons sur les épaules de géants. Les rollups d'aujourd'hui ont fait progresser l'état de la recherche pour l'ensemble de notre industrie, et ils ont fourni aux utilisateurs d'Ethereum des frais moins élevés que ceux de la L1.
Cependant, ils ne tirent pas pleinement parti des dernières technologies nécessaires pour s'adapter au plus grand nombre. Les premiers rollups ont largement priorisé la compatibilité EVM et/ou les optimisations pour un ZK-proving plus efficace. Plus récemment, nous avons constaté des progrès incroyables qui rendent superflus les compromis choisis par les premiers rollups et les désavantagent :
VM parallélisées très performantes (par exemple, SVM)
Scaling de la DA avec la prise en charge de light nodes DAS (par exemple, Celestia)
Progrès dans l'infrastructure de preuve pour la rendre pratique partout (par exemple, RISC Zero)
Portabilité accrue du code (par exemple, Neon et Solang) et des utilisateurs (par exemple, MetaMask Snaps) à travers les écosystèmes
Eclipse bénéficie de l'énorme avantage du recul. Nous pouvons tirer des leçons des limites auxquelles d'autres chains ont été confrontées, puis sélectionner les meilleurs éléments pour les adapter à long terme.
Nous entendons souvent parler d'un avenir avec un million de rollups spécifiques aux applications.
Les personnalisations au niveau du consensus peuvent être incroyablement utiles pour certaines applications (par exemple, dYdX v4), et nous sommes ravis d'aider les équipes à lancer des rollups spécifiques à l'application.
Cependant, ces cas sont rares. C'est pourquoi la plupart des nouveaux rollups ne sont encore que des forks d'EVM. Les problèmes des développeurs ne sont pas résolus par la fragmentation de l'UX sur davantage de chains. Le principal cas d'utilisation d'un million de chains aujourd'hui semble souvent être le lancement d'un million de jetotokensns supplémentaires. La demande de personnalisation complète n'existe tout simplement pas aujourd'hui pour la grande majorité des cas d'utilisation.
Même si la demande réelle existait, l'infrastructure nécessaire pour soutenir de nombreuses app-chains avec une interface utilisateur compétitive ne sera pas disponible avant des années (si elle l'est un jour). La Superchain d'Optimism (OP Stack), les Hyperchains de zkSync (ZK Stack), les chains Orbit d'Arbitrum, et ainsi de suite ont tous des visions de nombreuses chains avec une infrastructure partagée. L'objectif est de faciliter l'utilisation de l'interface utilisateur entre les chains d'un même écosystème (par exemple, entre deux chains au sein de la Superchain) et les chains complètement isolées (par exemple, entre Ethereum et Solana).
Toutefois, les plans actuels (lorsqu'ils existent) sont encore loin d'être compétitifs avec un état unique partagé. Également, ils n'abordent pas la question de l'interopérabilité entre les écosystèmes (par exemple, de la superchain à l'hyperchain). Construire modulaire ne devrait pas signifier construire des îles.
Il est plus compliqué pour les utilisateurs de maintenir des comptes sur plusieurs chains. L'interface utilisateur est moins bonne lorsqu'il s'agit d'établir des passerelles et de se demander de quel token de gas on a besoin. Il est plus compliqué et plus coûteux de dépendre des fournisseurs d'infrastructure pour l'exploitation et la maintenance d'un si grand nombre de chains.
Nous avons toujours apprécié la simplicité de la vision de Solana. Une machine d'état partagée hautement optimisée avec l'échelle nécessaire pour prendre en charge la majorité des cas d'utilisation importants. Cette vision est souvent considérée comme incompatible avec une feuille de route centrée sur les rollups, mais ce n'est tout simplement pas le cas. Nous voulons combiner le meilleur des deux mondes.
Cette idée fausse est due au fait que les rollups d'aujourd'hui exécutent en grande partie l'EVM vanilla à un seul thread, effectivement inchangé, afin de profiter des premiers effets de réseau. Par conséquent, nous voyons souvent l'"espace de blocks dédié" cité comme la raison pour laquelle il faut déployer un rollup spécifique à une application. Ces mint fou de NFT ne devraient pas faire grimper les prix de toutes les autres applications de votre chain, mais la solution n'est pas de créer votre propre chain. C'est comme utiliser un marteau de forgeron pour casser une cacahuète. Vous faites des compromis douloureux et inutiles (complexité, coût, moins bonne expérience utilisateur, liquidité fragmentée, etc.) La solution optimale est incroyablement claire : il suffit d'utiliser une VM parallélisée avec des local fee marketsde pour les hotspots de l'État. C'est exactement ce que le SVM apporte.
Ethereum est le centre intellectuel, social et économique de la crypto. Son talon d'Achille est la scalabilité. La scalabilité du DA est toujours en cours, et les environnements d'exécution des L2 existants ne peuvent pas rivaliser avec les innovations les plus récentes comme le SVM. Nous craignons que l'écosystème Ethereum ne soit pris au dépourvu par une forte augmentation de l'activité dans sa forme actuelle. Les EVM à un seul thread et les DA contraints conduiraient rapidement à une résurgence des frais élevés, sauf cette fois-ci sur les rollups.
Nous pensons qu'Eclipse Mainnet est la solution évidente : unir les performances de Solana avec la sécurité, la vérifiabilité et les effets de réseau de la feuille de route centrée sur les rollups.
La beauté d'Ethereum est qu'il se nourrit d'innovation. La feuille de route centrée sur les rollups (rollup-centric roadmap) en est l'exemple même, déléguant l'exécution et l'innovation au marché libre. Les L2 ont l'incroyable capacité de tirer parti des effets de réseau d'Ethereum et des garanties de règlement tout en expérimentant les meilleurs nouveaux environnements d'exécution. Eclipse Mainnet est l'accomplissement naturel de cette vision.
Si une couche d'exécution plus performante voit le jour un jour, nous serons incroyablement enthousiastes à l'idée de la voir déployée en tant que L2 Ethereum compétitive. En attendant, le SVM reste la norme.
Pour participer, contactez-nous à l'adresse team@eclipse.builders pour obtenir des instructions sur le testnet.