Présentation d'Eclipse Mainnet : Le SVM L2 d'Ethereum

Eclipse Mainnet est une L2 à usage général qui combine les meilleurs éléments de la pile modulaire :

1. Règlement : Ethereum - Eclipse effectuera le règlement en Ethereum (c'est-à-dire que le pont de validation enchâssé sera sur Ethereum) et utilisera l'ETH comme jeton de gaz.
2. Exécution : Solana Virtual Machine (SVM) - Eclipse utilisera la très performante SVM comme environnement d'exécution.
3. Disponibilité des données : Celestia - Eclipse postera ses données dans Celestia pour une disponibilité évolutive des données (DA).
4. Preuve : RISC Zero - Eclipse utilisera RISC Zero pour les 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 à des applications 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 d'une échelle vraiment massive. La plupart des applications ne bénéficient pas de personnalisations de chaînes spécifiques à l'application, et l'isolement et la complexité qui en résultent peuvent en fait entraîner une dégradation de l'interface utilisateur et de l'expérience du développeur.

Une fausse dichotomie est souvent présentée entre la vision du rollup modulaire et la capacité d'avoir une chaîne unique avec une échelle massive, une exécution parallélisée et un état partagé. Le terme "modulaire" est souvent confondu avec "spécifique à une application", ce qui pourrait vous amener à penser que les rollups sont synonymes d'un monde de nombreuses chaînes fragmentées et à faible débit. Nous contestons cette idée.

Exécution : L'échelle de vitesse de Solana &

Eclipse Mainnet adoptera l'environnement d'exécution de Solana, le meilleur de sa catégorie. Cela présente des avantages considérables :

Exécution parallèle optimisée

Le SVM et son moteur d'exécution Sealevel sont réputés pour permettre l'exécution de transactions en parallèle. 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 matériel, car les processeurs continuent d'ajouter des cœurs à moindre coût. Les temps d'exécution à fil unique (tels que l'EVM d'aujourd'hui) 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 à un seul fil ne cesse de diminuer. Presque toutes les améliorations continuent de 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 très précoces et non prouvées de parallélisation de l'EVM, mais l'ajout de cette fonctionnalité tout en maintenant la compatibilité entraîne des compromis fondamentaux, notamment des performances sous-optimales sans tenir compte 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 cas du SVM) permettent une parallélisation optimale.

Marchés locaux de redevances

La plupart des marchés de redevances sont aujourd'hui globaux, ce qui signifie qu'une application chaude augmente les redevances pour tous les utilisateurs de la chaîne. Un seul NFT ne devrait pas rendre la chaîne inutilisable pour tout le reste. Le travail remarquable de Solana sur les marchés locaux de redevances résout ce conflit entre les États. Dans sa version actuelle, l'ordonnanceur 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, des marchés locaux de redevances seront mis en place au niveau des protocoles. Cela permet de s'assurer que les hausses de tarifs d'une seule application n'ont pas d'impact sur le reste de la chaîne.

Les marchés locaux de redevances sont possibles grâce au temps d'exécution parallélisé unique de Solana. Essayer de mettre en place des marchés locaux de redevances pour les points chauds de l'État dans l'EVM en utilisant des heuristiques (c'est-à-dire sans déclarer au préalable l'accès de l'État) 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 dans l'État

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 époque (~2,5 jours), l'état entier est fusionné. Cette méthode est beaucoup moins coûteuse que la merklization 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 consultation dynamique de l'état signifie que l'état ne peut pas être chargé en mémoire avant l'exécution. Dans le SVM, chaque transaction spécifie tout l'état nécessaire à 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 instantanés 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.

En outre, des équipes comme Helius améliorent activement l'accessibilité des données historiques et réduisent la taille des données grâce à la compression.

Compatibilité EVM

Neon EVM est un EVM fonctionnant comme un contrat intelligent qui peut être déployé sur n'importe quelle chaîne 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 à un seul thread. Chaque instance Neon EVM disposant de son propre marché local, les applications peuvent simplement déployer leur propre contrat pour bénéficier des avantages d'une chaîne d'applications sans fragmenter l'expérience utilisateur, la sécurité ou la liquidité.

Par ailleurs, le compilateur Solang permet de compiler le code des contrats intelligents Solidity en bytecode SVM.

MetaMask Snaps

L'intégration des utilisateurs d'EVM dans les chaînes non EVM a toujours été un obstacle majeur, mais les Metamask Snaps, récemment dévoilés, sont prêts à faire tomber cette barrière. Les utilisateurs d'EVM peuvent continuer à utiliser MetaMask sans avoir à changer de portefeuille. L'interface utilisateur est comparable à celle de n'importe quelle chaîne EVM, grâce aux contributions open-source de Driftqui ont permis de mettre au point une excellente implémentation de MetaMask Snap. Les utilisateurs de l'Eclipse Mainnet pourront interagir avec des applications nativement dans MetaMask ou utiliser un portefeuille natif de Solana comme Salmon.

Voici un aperçu de l'interface utilisateur de Drift:

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. Lors du 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 opérationnel et stable.

Sécurité

La surface d'attaque du runtime de Solana est considérablement réduite, ce qui permet d'éviter les fameux exploits de réentrance que nous avons vus bien trop souvent. Plus précisément, le système d'exécution Solana ne permet aux programmes que de s'auto-récidiver, plutôt que d'autoriser des invocations réentrantes arbitraires 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.

Une preuve plus facile à apporter

Le SVM est basé sur des 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 dans ZK. Pour les rollups optimistes, la conception basée sur les registres permet un contrôle plus facile.

Règlement : La sécurité d'Ethereum & Liquidité

Comme pour les principaux rollups d'aujourd'hui, Eclipse Mainnet s'installera sur Ethereum. Concrètement, cela signifie que notre pont de validation sur Ethereum sera directement intégré dans Eclipse. Les nœuds Eclipse se référeront à ce pont pour déterminer la "chaîne canonique". Le pont applique l'ordre correct pour Eclipse.

Cela permet à nos utilisateurs d'obtenir certaines propriétés de sécurité d'Ethereum. La passerelle validera toutes les transactions Eclipse, empêchant ainsi la soumission d'états non valides. En outre, il renforcera le caractère vivant et la résistance à la censure dans certains cas d'échec. Même si le séquenceur devait s'arrêter ou commencer à censurer au niveau L2, les utilisateurs seraient en mesure de forcer l'inclusion de leurs transactions via le pont.

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 chaîne 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 L2 pour la sécurité de leurs fonds".

Le règlement Ethereum reconnaît l'importance que les actifs natifs d'Ethereum joueront probablement dans les économies DeFi et 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 jeton de gaz. À plus long terme, l'abstraction des frais permettra aux utilisateurs de payer avec le jeton de leur choix (par exemple, l'USDC). Pour l'instant, il n'est pas prévu que l'Eclipse Mainnet dispose de son propre jeton.

Disponibilité des données : Bande passante de Celestia & Vérifiabilité

Eclipse Mainnet utilisera Celestia pour la disponibilité des données (a.k.a. data publishing ou publication de données). 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 compatibles avec la bande passante actuelle d'Ethereum. Il en sera ainsi même après l'adoption de l'EIP-4844 (a.k.a. "Proto-danksharding"), qui fournit une moyenne d'environ 0,375 Mo d'espace blobs par bloc (avec une limite d'environ 0,75 Mo par bloc).

1. Pour les transferts ERC-20 avec une compression de base(~154 octets par transaction), cela se traduit par ~213 TPS pour tous les rollups combinés.
2. Pour les swaps avec compression (~400 octets par transaction), cela se traduit par ~82 TPS pour tous les rollups combinés.

En comparaison, Celestia sera lancé avec des blocs 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 nœuds légers d'échantillonnage de la disponibilité des données (DAS ) auront été mis en ligne et que le réseau se sera stabilisé. Les nœuds lumineux DAS remplissent deux fonctions essentielles :

1. Permettre aux utilisateurs de vérifier par eux-mêmes que les données du bloc Eclipse ont été mises à disposition
2. Contribuer à la mise à l'échelle sécurisée de l'ensemble du réseau, les couches DA pouvant augmenter leur débit en toute sécurité à mesure que davantage de nœuds légers DAS sont mis en ligne.

Celestia devrait être la première couche DA à être lancée avec le DAS en production. Cela contraste avec les comités traditionnels de disponibilité des données (DAC), qui réintroduisent des hypothèses d'honnêteté du comité sans vérification par l'utilisateur (un peu comme 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 toute chaîne qui utilise l'AD hors chaîne. En particulier, il est techniquement possible pour les validateurs Celestia de ne pas divulguer les données de transaction mais d'affirmer au pont Ethereum que les données sont disponibles. Dans la pratique, le consensus de Celestia sur la preuve de l'enjeu 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 nœuds légers DAS par Celestia dès le premier jour, les propriétés de sécurité crypto-économiques et le débit DA hautement évolutif en font aujourd'hui le choix évident pour Eclipse Mainnet.

Notez que certains considèrent l'Ethereum DA onchain comme une exigence pour être une véritable "L2" ici, pour les raisons décrites ci-dessus. Nous utilisons la terminologie L2 la 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 d'échelonnement des DA après l'EIP-4844. De nouvelles recherches passionnantes continuent d'être menées, qui pourraient permettre d'obtenir des données à haut débit plus rapidement 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.

Prouver : Preuves de fraude RISC Zero ZK (sans sérialisation des états intermédiaires !)

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 clairsemé dans le SVM dès le début, mais la mise à jour de l'arbre de Merkle après chaque transaction entraîne des pertes de performances substantielles. La preuve sans arbre de Merkle exclut les cadres de rollup généralistes existants tels que la pile OP comme base pour les rollups de SVM, et nécessite également une architecture de preuve de fautes plus créative.

À un niveau élevé, une preuve d'erreur nécessite :

1. Un engagement à fournir des intrants pour une transaction,
2. La transaction elle-même, et
3. Preuve que la réexécution de la transaction aboutit à un résultat différent de celui qui a été spécifié sur la chaîne.

L'engagement d'entrée se fait généralement en fournissant la racine 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 compte 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 fautes majeures possibles :

1. Résultats incorrects - Dans ce cas, le vérificateur fournit une preuve ZK sur la chaîne des résultats corrects. Nous utilisons RISC Zero pour créer des preuves ZK de l'exécution des SVM, en poursuivant 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 chaîne.
2. Entrées incorrectes - Dans ce cas, le vérificateur affiche sur la chaîne 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 l'existence d'une fraude.

Pourquoi Eclipse, pourquoi Ethereum, pourquoi maintenant ?

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 permis aux utilisateurs d'Ethereum de bénéficier de tarifs plus avantageux 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 donné la priorité à la compatibilité avec les EVM et/ou à des optimisations visant à améliorer l'efficacité de l'épreuve ZK. Plus récemment, cependant, nous avons assisté à des progrès incroyables qui nous dispensent de faire ces compromis que les premiers rollups ont choisi, et qui les désavantagent même :

1. VM parallélisées très performantes (par exemple, SVM)
2. Mise à l'échelle DA avec support de nœuds légers DAS (par exemple, Celestia)
3. Progrès dans l'infrastructure de preuve pour la rendre pratique partout (par exemple, RISC Zero)
4. Portabilité accrue du code (par exemple, Neon et Solang) et des utilisateurs (par exemple, MetaMask Snaps) à travers les écosystèmes

Eclipse bénéficie d'un énorme recul. Nous tirons les leçons des limites auxquelles d'autres chaînes ont été confrontées, puis nous sélectionnons les meilleurs éléments pour les adapter à long terme.

https://twitter.com/0xMert?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680271128537726976%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

https://twitter.com/colludingnode?refsrc=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680285353662468097%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

Nous entendons souvent parler d'un avenir avec un million de rollups spécifiques aux applications.

Les personnalisations au niveau du consensus peuvent être extrêmement utiles pour certaines applications (par exemple, dYdX v4), et nous sommes ravis d'aider les équipes à lancer des rollups spécifiques à l'application.

Toutefois, ces cas sont peu nombreux. C'est pourquoi la plupart des nouveaux rollups ne sont encore que des fourches à EVM. Les problèmes des développeurs ne sont pas résolus par la fragmentation de l'UX sur un plus grand nombre de chaînes. Aujourd'hui, le principal cas d'utilisation d'un million de chaînes semble souvent être le lancement d'un million de jetons 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 était là, l'infrastructure nécessaire pour soutenir de nombreuses chaînes d'applications 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 chaînes Orbit d'Arbitrum, etc. ont toutes des visions de chaînes multiples avec une infrastructure partagée. L'objectif est de faciliter le fonctionnement de l'interface utilisateur entre les chaînes d'un même écosystème (par exemple, entre deux chaînes de la Superchain) et les chaînes complètement isolées (par exemple, entre Ethereum et Solana).

Cependant, les plans actuels (lorsqu'ils existent) sont encore loin d'être compétitifs par rapport à un État unique partagé. En outre, ils ne traitent pas de l'interopérabilité entre les écosystèmes (par exemple, de la superchaîne à l'hyperchaîne). Construire modulaire ne doit pas signifier construire des îles.

Il est plus compliqué pour les utilisateurs de maintenir des comptes sur plusieurs chaînes. C'est une pire expérience utilisateur que de continuer à faire des ponts et de s'inquiéter du jeton de gaz dont vous avez besoin. Il est plus compliqué et plus coûteux de dépendre des fournisseurs d'infrastructure pour l'exploitation et l'entretien d'un si grand nombre de chaînes.

Nous avons toujours apprécié la simplicité de la vision de Solana. Une machine à états partagés hautement optimisée, capable de prendre en charge la majorité des cas d'utilisation importants. Cela est souvent considéré 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 utilisent en grande partie l'EVM vanille à un seul thread, sans modification, afin de profiter des premiers effets de réseau. Par conséquent, nous voyons souvent l'espace de blocs dédié cité comme la raison pour laquelle il faut déployer un rollup spécifique à l'application. Ces monnaies NFT farfelues ne devraient pas faire grimper les prix de toutes les autres applications de votre chaîne, mais la solution n'est pas de créer votre propre chaîne. 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 interface utilisateur, liquidité fragmentée, etc.) La solution optimale est incroyablement claire : il suffit d'utiliser une VM parallélisée avec des marchés locaux de redevances pour les points névralgiques de l'État. C'est exactement ce qu'apporte le SVM.

Ethereum est le centre intellectuel, social et économique de la cryptographie. Son talon d'Achille a été la mise à l'échelle. La mise à l'échelle de la DA est encore en cours, et les environnements d'exécution L2 existants ne peuvent pas rivaliser avec des innovations plus récentes telles que le SVM. Nous craignons que l'écosystème Ethereum ne soit pris au dépourvu par une forte augmentation de l'activité telle qu'elle se présente aujourd'hui. Les MVE à fil unique et les DA limités conduiraient rapidement à une résurgence des frais élevés, mais cette fois-ci sur les rollups.

Nous pensons qu'Eclipse Mainnet est la solution évidente : il unit 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 le rollup.

Réflexions finales

La beauté d'Ethereum est qu'il se nourrit d'innovation. La feuille de route centrée sur le rollup 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 la concrétisation naturelle 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 concurrentielle d'Ethereum. D'ici là, le SVM reste la norme.

Pour participer, contactez-nous à l'adresse <a href="http://mailto:team@eclipse.builders/"" > team@eclipse.builders pour obtenir des instructions sur le réseau d'essai.

Clause de non-responsabilité：

1. Cet article est repris de[Mirror]. Tous les droits d'auteur appartiennent à l'auteur original[Eclipse]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.