Eclipse Mainnet est une couche 2 universelle qui combine les meilleurs éléments de l'architecture modulaire :
Couche de règlement : Ethereum - Eclipse réglera avec Ethereum (c'est-à-dire que le pont de validation sera sur Ethereum) et utilisera ETH comme jeton de gaz.
Couche d'exécution : Machine virtuelle Solana (SVM) - Eclipse exécutera une SVM hautes performances comme environnement d'exécution.
Disponibilité des données : Celestia - Eclipse publiera ses données sur Celestia pour une disponibilité des données (DA) évolutive.
Preuve : RISC Zero - Eclipse utilisera RISC Zero pour les preuves de fraude sans connaissance (sans avoir besoin de sérialisation d'état intermédiaire !)
La plupart des points forts d'Eclipse concernent le déploiement de cumuls spécifiques à des applications pour divers projets, mais il est plus que jamais clair qu'Ethereum a besoin d'une couche 2 universelle capable d'atteindre une véritable échelle. La plupart des applications ne bénéficieront pas de la personnalisation des chaînes spécifiques aux applications, et l'isolement et la complexité qui en résultent peuvent en réalité conduire à une pire expérience utilisateur et développeur.
Il existe souvent une fausse dichotomie entre la vision des cumuls modulaires et la possibilité d'avoir une chaîne unique avec une mise à l'échelle massive, une exécution parallèle et un état partagé. « Modulaire » est souvent confondu avec « spécifique à une application », ce qui laisse penser que le cumul signifie un monde composé de nombreuses chaînes fragmentées et à faible débit.
Couche d'exécution : la vitesse et l'échelle de Solana
Eclipse Mainnet utilisera un environnement d'exécution de premier ordre de type Solana. Cela apporte d’énormes avantages :
Exécution parallèle optimisée
SVM et son runtime Sealevel sont réputés pour leur prise en charge de l'exécution de transactions parallèles. Les transactions qui ne touchent pas les états qui se chevauchent peuvent être exécutées en parallèle plutôt qu'en série.
Cela permet à SVM d'évoluer directement avec le matériel à mesure que le processeur continue d'ajouter davantage de cœurs à moindre coût. Les environnements d'exécution monothread (comme l'EVM actuel) ne bénéficient pas par nature d'un coût par cœur inférieur. Au cours de la dernière décennie, les améliorations des performances monothread ont régulièrement diminué. Presque toutes les améliorations proviennent toujours de l'augmentation du nombre de cœurs. Il est donc essentiel de tirer parti de cette tendance en matière de parallélisation des charges de travail :
Bien qu'il y ait eu quelques premières tentatives pour paralléliser l'EVM, l'ajouter tout en maintenant la compatibilité s'accompagne de compromis fondamentaux, notamment des performances sous-optimales sans résoudre d'autres goulots d'étranglement (tels que la croissance de l'État). Les contrats qui déclarent les dépendances d'état à l'avance (comme dans SVM) permettent d'obtenir une parallélisation optimale.
Marché des frais natifs
Aujourd’hui, la plupart des marchés de frais sont mondiaux, ce qui signifie qu’une application populaire augmentera les frais pour tous les utilisateurs de la chaîne. Une seule frappe NFT ne devrait pas rendre la chaîne entière inutile pour tout le reste. Le travail incroyable de Solana sur un marché de frais natif résout ce problème de conflit d’état entre applications. Dans sa mise en œuvre actuelle, le planificateur donne la priorité aux transactions sans conflits, permettant ainsi aux transactions sans conflit de se dérouler à un coût inférieur. À long terme, des marchés de frais natifs seront mis en œuvre au niveau des protocoles. Cela garantit que les hausses de frais pour une seule demande n’ont pas d’impact sur les autres parties de la chaîne.
Le marché des frais natifs bénéficie du moteur d'exécution de parallélisation unique de Solana. Tenter de mettre en œuvre un marché payant natif pour les hotspots d’État dans l’EVM en utilisant des heuristiques (c’est-à-dire ne pas déclarer l’accès de l’État à l’avance) introduirait des inefficacités et d’éventuels vecteurs d’attaque.
Des recherches préliminaires sont également en cours afin que les applications puissent facilement internaliser la valeur native de l'application elle-même, ce qui nécessite aujourd'hui souvent plus de créativité dans la conception au niveau de l'application.
Gestion de la croissance de l'État
Avant même que l’exécution séquentielle de l’EVM ne constitue un goulot d’étranglement, la croissance de l’État constitue son goulot d’étranglement le plus pressant.
Étant donné que les États n'ont pas d'arborescence Merkle, Solana n'introduit pas la surcharge liée à la mise à jour de l'arborescence Merkle pour chaque mise à jour d'état. Au lieu de cela, après chaque époque (2,5 jours), l’intégralité de l’état est archivée. C'est moins cher que l'archivage en direct (comme dans EVM).
Plus important encore, EVM dispose d'un accès dynamique au compte (c'est-à-dire que les transactions peuvent toucher n'importe quel état à la demande). Cette recherche d'état dynamique signifie que l'état ne peut pas être chargé en mémoire avant l'exécution. Dans SVM, chaque transaction spécifie tous les états requis pour l'exécution.
Par conséquent, la taille de l’état n’affecte pas l’exécution de la SVM. En supposant que les validateurs mettent à niveau leurs disques de stockage tous les deux ans, le réseau peut doubler en toute sécurité la taille des instantanés tous les deux ans sans rencontrer de problèmes majeurs.
De plus, 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é EVM
Neon EVM est un contrat intelligent de machine virtuelle Ethereum qui peut être déployé sur n'importe quelle chaîne SVM. Cela apporte une compatibilité EVM complète (y compris la prise en charge du bytecode EVM et Ethereum JSON-RPC) au réseau principal Eclipse, avec un débit supérieur à celui de l'EVM à thread unique. Étant donné que chaque instance Neon EVM dispose de son propre marché de frais natif, les applications peuvent simplement déployer leurs propres contrats pour profiter des avantages de la chaîne d'applications sans perturber l'UX, la sécurité ou la liquidité.
De plus, le compilateur Solang peut compiler le code du contrat intelligent Solidity en bytecode SVM.
Snaps MetaMask
Guider les utilisateurs EVM à utiliser des chaînes non EVM a toujours été un obstacle important, mais les MetaMask Snaps récemment annoncés briseront cet obstacle. Les utilisateurs d'EVM peuvent continuer à utiliser MetaMask sans changer de portefeuille. Grâce aux contributions open source de Drift à la création d'une excellente implémentation de MetaMask Snaps, l'expérience est similaire à l'interaction avec n'importe quelle chaîne EVM. Les utilisateurs d'Eclipse Mainnet pourront interagir avec les applications de manière native dans MetaMask ou utiliser des portefeuilles natifs de Solana tels que Salmon.
Firedanseur
Firedancer est le client Solana très attendu développé par Jump et est conçu pour 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 Solana, mais nous prévoyons d'adopter Firedancer une fois que le code sera opérationnel et stable.
sécurité
Solana fonctionne avec une surface d'attaque considérablement réduite, empêchant les attaques de réentrée que nous avons vues trop souvent. Plus précisément, le runtime Solana autorise uniquement l'auto-récursion du programme et n'autorise pas les appels inter-programmes réentrants arbitraires. De plus, la séparation de l’état et du code donne lieu à un code sans état, qui est généralement plus facile à tester efficacement.
Preuve plus simple
SVM est basé sur des registres et le jeu d'instructions est beaucoup plus petit que EVM, ce qui rend l'exécution de SVM plus facile à prouver dans ZK. Pour des cumuls optimistes, une conception basée sur des registres permet un point de contrôle plus simple.
Couche de règlement : sécurité et liquidité sur Ethereum
Comme le rollup majeur d'aujourd'hui, Eclipse Mainnet sera réglé avec Ethereum. Concrètement, cela signifie que notre pont de vérification sur Ethereum sera intégré directement dans Eclipse. Le nœud Eclipse examinera ce pont pour déterminer la « chaîne canonique ». Ce pont applique un ordre correct pour Eclipse.
Cela permet à nos utilisateurs d’obtenir certaines propriétés de sécurité d’Ethereum. Le pont validera toutes les transactions Eclipse et empêchera la validation d'états non valides. De plus, cela renforcera la vivacité finale et la résistance à la censure dans certains cas d'échec. Même si le donneur d'ordre de L2 cesse de fonctionner ou commence la censure, les utilisateurs pourront forcer l'inclusion de leurs transactions via le pont.
En raison de ces propriétés de sécurité, les bibliothèques valides et optimales sont souvent appelées « Ethereum L2 ». L2BEAT définit L2 comme « une chaîne qui tire entièrement ou partiellement sa sécurité de la couche 1 d’Ethereum afin que les utilisateurs n’aient pas besoin de compter sur l’honnêteté des validateurs L2 pour protéger leurs fonds ».
Le règlement d’Ethereum reflète l’importance des actifs natifs d’Ethereum dans les économies DeFi et NFT d’Eclipse Mainnet. L’ETH est clairement la monnaie décentralisée préférée de la plupart des utilisateurs, nous utiliserons donc également l’ETH comme jeton de gaz. À long terme, l'abstraction des frais permettra aux utilisateurs de payer avec n'importe quel jeton de leur choix (par exemple USDC). Actuellement, Eclipse Mainnet n'a pas l'intention d'émettre ses propres jetons.
Disponibilité des données : bande passante et vérifiabilité de Celestia
Eclipse Mainnet utilisera Celestia pour la disponibilité des données (également appelée publication de données ou publication de données). Celestia est un partenaire écosystémique à long terme d'Eclipse.
Le débit et les frais cibles d'Eclipse Mainnet ne sont malheureusement pas pris en charge par les limitations actuelles de bande passante d'Ethereum. Cela est vrai même après EIP-4844 (alias « Proto-danksharding »), qui fournit environ 0,375 Mo d'espace blob par bloc (avec une limite par bloc d'environ 0,75 Mo).
Pour les transferts ERC-20 avec compression de base (~154 octets par transaction), cela équivaut à ~213 TPS pour tous les Rollups.
Pour les échanges compressés (~ 400 octets par transaction), cela équivaut à ~ 82 TPS tous agrégés.
En comparaison, Celestia lancera des blocs de 2 Mo d'ici la fin de cette année. Une fois qu'un nombre suffisant de nœuds légers DAS (Data Availability Sampling) seront mis en ligne et que le réseau se révélera stable, l'espace blob devrait augmenter à 8 Mo peu de temps après le lancement. Le nœud lumineux DAS remplit deux fonctions clés :
Permettre aux utilisateurs de vérifier par eux-mêmes si les données du bloc Eclipse sont disponibles ;
Aide à faire évoluer en toute sécurité l'ensemble du réseau, car à mesure que davantage de nœuds légers DAS sont mis en ligne, la couche DA peut augmenter son débit en toute sécurité.
Celestia devrait être la première couche DA à activer le DAS en production. Cela contraste avec les comités de disponibilité des données (DAC) traditionnels, qui réintroduisent l’hypothèse d’honnêteté du comité sans vérification de l’utilisateur (similaire aux blockchains monolithiques existantes).
Il existe des hypothèses de sécurité inhérentes pour les utilisateurs qui transfèrent les fonds du réseau principal Ethereum vers n'importe quelle chaîne utilisant DA hors chaîne. En particulier, les validateurs de Celestia peuvent techniquement rejeter les données de transaction mais affirmer que les données sont disponibles sur le pont Ethereum. En fait, le consensus sur la preuve de participation de Celestia signifie que la rétention de données par Celestia elle-même est punissable, ce qui nous fait croire que ce risque est irréaliste.
Dans l'ensemble, la prise en charge des nœuds légers DAS de Celestia, ses propriétés de sécurité cryptoéconomiques et son débit DA hautement évolutif dès le premier jour en font le choix évident pour Eclipse Mainnet aujourd'hui.
Nous avons également l'intention de surveiller les progrès d'Ethereum en matière de mise à l'échelle du DA après l'EIP-4844. De nouvelles recherches passionnantes émergent qui pourraient fournir une DA à haut débit plus tôt qu’on ne le pensait (cette dernière utilisant des tables de hachage distribuées plus avancées). Si Ethereum offre une plus grande échelle à nos utilisateurs, nous évaluerons la possibilité de migrer vers Ethereum DA.
Preuve : Preuve de fraude RISC Zero ZK (aucune sérialisation d'état intermédiaire requise !)
Notre preuve sera similaire au SIMD anti-fraude SVM d'Anatoly, qui lui-même est similaire à 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 voulons éviter de réintroduire les arbres Merkle dans SVM. Nous avons essayé d'insérer une arborescence Merkle clairsemée après chaque transaction dans SVM, mais la mise à jour de l'arborescence Merkle a entraîné une perte de performances importante. Ne pas utiliser les arbres Merkle exclut les cadres de cumul à usage général existants (tels que la pile OP) comme base du cumul SVM, et nécessite également des architectures plus créatives et résistantes aux pannes.
En bref, la preuve d'échec nécessite :
Engagement en matière d'entrée de transaction,
la transaction elle-même, et
Prouver que la réexécution de la transaction entraîne un résultat différent de celui spécifié sur la chaîne.
Les engagements d'entrée sont généralement accomplis en fournissant une racine Merkle de l'arborescence d'état de cumul. Notre exécuteur publiera une liste d'entrées et de sorties (y compris les hachages de compte et l'état global associé) 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 auto-extraire le compte dans son propre état, calculer le compte de sortie et confirmer que l'engagement sur Ethereum est correct.
Il existe deux principaux types de pannes possibles :
Sortie d'erreur - Dans ce cas, le vérificateur fournit une preuve en chaîne sans connaissance de la sortie correcte de l'exécution de la SVM. Nous utilisons RISC Zero pour créer une preuve sans connaissance de l'exécution de SVM, qui s'inscrit dans la continuité de notre précédente preuve d'exécution du bytecode BPF. Cela permet à notre contrat de règlement de garantir l'exactitude sans avoir à exécuter lui-même ces transactions en chaîne.
Mauvaise entrée - Dans ce cas, le validateur publie une référence aux données historiques en chaîne, montrant que l'état d'entrée ne correspond pas à ce qui a été revendiqué. Grâce au Quantum Gravity Bridge de Celestia, notre contrat de règlement garantit que ces données historiques prouvent réellement la fraude.
Nous nous tenons sur les épaules de géants. Le rollup d’aujourd’hui a fait progresser la recherche dans notre secteur et offre aux utilisateurs d’Ethereum des frais inférieurs à ceux de L1.
Cependant, ils ne profitent pas pleinement des dernières technologies qui nécessitent une grande échelle. Des progrès incroyables récents ont éliminé la nécessité de faire ces compromis comme le faisaient les rollups précédents, les désavantageant effectivement :
VM parallèle hautes performances (telle que SVM) ;
Extension DA avec prise en charge des nœuds légers DAS (tels que Celestia) ;
Les progrès de l'infrastructure de preuve qui la rendent pratique partout (par exemple RISC Zero) ;
Portabilité améliorée entre les écosystèmes de code (par exemple Neon et Solang) et les utilisateurs (par exemple MetaMask Snaps)
Nous pouvons tirer les leçons des limites rencontrées par d’autres chaînes et sélectionner les meilleurs éléments pour une expansion à long terme.
Nous entendons souvent parler d’un million de Rollups spécifiques aux applications à l’avenir.
La personnalisation au niveau du consensus peut être très utile pour certaines applications (telles que dYdX v4), et nous sommes heureux d'aider l'équipe à lancer des rollups spécifiques à l'application.
Ces situations sont cependant rares. C'est pourquoi la plupart des nouveaux rollups ne sont encore que de simples forks EVM. Les problèmes des développeurs ne seront pas résolus en fragmentant l’UX sur plusieurs chaînes. Le principal cas d’utilisation trouvé aujourd’hui pour des millions de chaînes semble souvent être simplement le lancement de plus de pièces. Pour la grande majorité des cas d’utilisation, la nécessité d’une personnalisation complète de la pile technologique n’existe pas aujourd’hui.
Même si une demande réelle existe, l’infrastructure nécessaire pour prendre en charge de nombreuses chaînes d’applications avec une UX compétitive ne sera pas en place avant des années (voire pas du tout). La Superchain d'Optimism (pile OP), les Hyperchains de zkSync (pile ZK), la chaîne Orbit d'Arbitrum, etc. ont toutes la vision de nombreuses chaînes avec une infrastructure partagée. Ceci vise à fournir une UX plus fluide pour les opérations inter-chaînes au sein du même écosystème (par exemple, entre deux chaînes au sein d'une Superchain), plutôt que pour des chaînes complètement isolées (par exemple, entre Ethereum et Solana).
Cependant, les projets actuels (s’ils existent) sont loin de permettre de rivaliser avec un État unique partagé. De plus, ils ne résolvent pas les problèmes d’interopérabilité entre les écosystèmes (par exemple, Superchain à Hyperchain). Construire la modularité ne doit pas signifier construire des silos.
Il est plus compliqué pour les utilisateurs de gérer des comptes sur de nombreuses chaînes. Traverser constamment les chaînes et se soucier des jetons de gaz requis est une pire expérience utilisateur. S’appuyer sur des fournisseurs d’infrastructures pour exploiter et entretenir autant de chaînes est également plus complexe et plus coûteux.
Nous avons toujours admiré la simplicité de la vision de Solana. Une machine à états partagée hautement optimisée avec l’échelle nécessaire pour prendre en charge les cas d’utilisation les plus précieux. Ceci est souvent considéré comme incompatible avec les feuilles de route centrées sur le cumul, mais ce n'est pas réellement le cas. Nous voulions combiner le meilleur des deux mondes.
Ce malentendu est dû au fait que les rollups actuels exécutent en grande partie l'EVM original à thread unique, qui est resté en grande partie inchangé pour tirer parti des premiers effets de réseau. Par conséquent, nous voyons souvent « l’espace de bloc privé » cité comme raison du déploiement de cumuls spécifiques à l’application. Les autres applications de votre chaîne ne devraient pas voir leurs prix augmenter à cause d'une frappe NFT folle, mais la réponse n'est pas de construire votre propre chaîne. Vous faites des compromis pénibles et inutiles (complexité, coût, moins bonne expérience utilisateur, liquidité fragmentée, etc.). La meilleure solution est claire : utilisez simplement une VM parallèle avec un marché payant natif pour les hotspots d’État. C'est exactement ce qu'apporte SVM.
Ethereum est le centre intellectuel, social et économique de la crypto. Son talon d'Achille a toujours été l'expansion. L'expansion de la disponibilité des données est toujours un travail en cours, et les environnements d'exécution L2 existants ne peuvent pas rivaliser avec les innovations plus récentes telles que les SVM. Nous craignons que si le statu quo actuel persiste, l’écosystème Ethereum soit pris au dépourvu en cas d’augmentation spectaculaire de l’activité. Les EVM monothread et la disponibilité limitée des données peuvent rapidement entraîner une résurgence de coûts élevés, mais cette fois-ci en matière de cumuls.
Nous pensons qu'Eclipse Mainnet est la solution évidente : combinant les performances de Solana avec la sécurité, la vérifiabilité et les effets réseau d'une feuille de route centrée sur le cumul.
Conclusion
La beauté d’Ethereum est qu’il innove constamment. Les feuilles de route centrées sur le rollup en sont un exemple, déléguant l'exécution et l'innovation au marché libre. L2 a l’étrange capacité de tirer parti des effets de réseau et des garanties de règlement d’Ethereum tout en expérimentant les meilleurs nouveaux environnements d’exécution. Eclipse Mainnet est une mise en œuvre naturelle de cette vision.
Si une couche d’exécution plus performante devait émerger un jour, nous serions très heureux de la voir déployée en tant qu’Ethereum L2 compétitif. D’ici là, SVM reste la norme.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Eclipse Mainnet : une couche 2 modulaire avec la sécurité Ethereum et la vitesse Solana qui s'appuie sur les points forts des autres
Écrit par : Éclipse
Compilé par : Deep Wave TechFlow
Eclipse Mainnet est une couche 2 universelle qui combine les meilleurs éléments de l'architecture modulaire :
La plupart des points forts d'Eclipse concernent le déploiement de cumuls spécifiques à des applications pour divers projets, mais il est plus que jamais clair qu'Ethereum a besoin d'une couche 2 universelle capable d'atteindre une véritable échelle. La plupart des applications ne bénéficieront pas de la personnalisation des chaînes spécifiques aux applications, et l'isolement et la complexité qui en résultent peuvent en réalité conduire à une pire expérience utilisateur et développeur.
Il existe souvent une fausse dichotomie entre la vision des cumuls modulaires et la possibilité d'avoir une chaîne unique avec une mise à l'échelle massive, une exécution parallèle et un état partagé. « Modulaire » est souvent confondu avec « spécifique à une application », ce qui laisse penser que le cumul signifie un monde composé de nombreuses chaînes fragmentées et à faible débit.
Couche d'exécution : la vitesse et l'échelle de Solana
Eclipse Mainnet utilisera un environnement d'exécution de premier ordre de type Solana. Cela apporte d’énormes avantages :
Exécution parallèle optimisée
SVM et son runtime Sealevel sont réputés pour leur prise en charge de l'exécution de transactions parallèles. Les transactions qui ne touchent pas les états qui se chevauchent peuvent être exécutées en parallèle plutôt qu'en série.
Cela permet à SVM d'évoluer directement avec le matériel à mesure que le processeur continue d'ajouter davantage de cœurs à moindre coût. Les environnements d'exécution monothread (comme l'EVM actuel) ne bénéficient pas par nature d'un coût par cœur inférieur. Au cours de la dernière décennie, les améliorations des performances monothread ont régulièrement diminué. Presque toutes les améliorations proviennent toujours de l'augmentation du nombre de cœurs. Il est donc essentiel de tirer parti de cette tendance en matière de parallélisation des charges de travail :
Bien qu'il y ait eu quelques premières tentatives pour paralléliser l'EVM, l'ajouter tout en maintenant la compatibilité s'accompagne de compromis fondamentaux, notamment des performances sous-optimales sans résoudre d'autres goulots d'étranglement (tels que la croissance de l'État). Les contrats qui déclarent les dépendances d'état à l'avance (comme dans SVM) permettent d'obtenir une parallélisation optimale.
Marché des frais natifs
Aujourd’hui, la plupart des marchés de frais sont mondiaux, ce qui signifie qu’une application populaire augmentera les frais pour tous les utilisateurs de la chaîne. Une seule frappe NFT ne devrait pas rendre la chaîne entière inutile pour tout le reste. Le travail incroyable de Solana sur un marché de frais natif résout ce problème de conflit d’état entre applications. Dans sa mise en œuvre actuelle, le planificateur donne la priorité aux transactions sans conflits, permettant ainsi aux transactions sans conflit de se dérouler à un coût inférieur. À long terme, des marchés de frais natifs seront mis en œuvre au niveau des protocoles. Cela garantit que les hausses de frais pour une seule demande n’ont pas d’impact sur les autres parties de la chaîne.
Le marché des frais natifs bénéficie du moteur d'exécution de parallélisation unique de Solana. Tenter de mettre en œuvre un marché payant natif pour les hotspots d’État dans l’EVM en utilisant des heuristiques (c’est-à-dire ne pas déclarer l’accès de l’État à l’avance) introduirait des inefficacités et d’éventuels vecteurs d’attaque.
Des recherches préliminaires sont également en cours afin que les applications puissent facilement internaliser la valeur native de l'application elle-même, ce qui nécessite aujourd'hui souvent plus de créativité dans la conception au niveau de l'application.
Gestion de la croissance de l'État
Avant même que l’exécution séquentielle de l’EVM ne constitue un goulot d’étranglement, la croissance de l’État constitue son goulot d’étranglement le plus pressant.
Étant donné que les États n'ont pas d'arborescence Merkle, Solana n'introduit pas la surcharge liée à la mise à jour de l'arborescence Merkle pour chaque mise à jour d'état. Au lieu de cela, après chaque époque (2,5 jours), l’intégralité de l’état est archivée. C'est moins cher que l'archivage en direct (comme dans EVM).
Plus important encore, EVM dispose d'un accès dynamique au compte (c'est-à-dire que les transactions peuvent toucher n'importe quel état à la demande). Cette recherche d'état dynamique signifie que l'état ne peut pas être chargé en mémoire avant l'exécution. Dans SVM, chaque transaction spécifie tous les états requis pour l'exécution.
Par conséquent, la taille de l’état n’affecte pas l’exécution de la SVM. En supposant que les validateurs mettent à niveau leurs disques de stockage tous les deux ans, le réseau peut doubler en toute sécurité la taille des instantanés tous les deux ans sans rencontrer de problèmes majeurs.
De plus, 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é EVM
Neon EVM est un contrat intelligent de machine virtuelle Ethereum qui peut être déployé sur n'importe quelle chaîne SVM. Cela apporte une compatibilité EVM complète (y compris la prise en charge du bytecode EVM et Ethereum JSON-RPC) au réseau principal Eclipse, avec un débit supérieur à celui de l'EVM à thread unique. Étant donné que chaque instance Neon EVM dispose de son propre marché de frais natif, les applications peuvent simplement déployer leurs propres contrats pour profiter des avantages de la chaîne d'applications sans perturber l'UX, la sécurité ou la liquidité.
De plus, le compilateur Solang peut compiler le code du contrat intelligent Solidity en bytecode SVM.
Snaps MetaMask
Guider les utilisateurs EVM à utiliser des chaînes non EVM a toujours été un obstacle important, mais les MetaMask Snaps récemment annoncés briseront cet obstacle. Les utilisateurs d'EVM peuvent continuer à utiliser MetaMask sans changer de portefeuille. Grâce aux contributions open source de Drift à la création d'une excellente implémentation de MetaMask Snaps, l'expérience est similaire à l'interaction avec n'importe quelle chaîne EVM. Les utilisateurs d'Eclipse Mainnet pourront interagir avec les applications de manière native dans MetaMask ou utiliser des portefeuilles natifs de Solana tels que Salmon.
Firedanseur
Firedancer est le client Solana très attendu développé par Jump et est conçu pour 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 Solana, mais nous prévoyons d'adopter Firedancer une fois que le code sera opérationnel et stable.
sécurité
Solana fonctionne avec une surface d'attaque considérablement réduite, empêchant les attaques de réentrée que nous avons vues trop souvent. Plus précisément, le runtime Solana autorise uniquement l'auto-récursion du programme et n'autorise pas les appels inter-programmes réentrants arbitraires. De plus, la séparation de l’état et du code donne lieu à un code sans état, qui est généralement plus facile à tester efficacement.
Preuve plus simple
SVM est basé sur des registres et le jeu d'instructions est beaucoup plus petit que EVM, ce qui rend l'exécution de SVM plus facile à prouver dans ZK. Pour des cumuls optimistes, une conception basée sur des registres permet un point de contrôle plus simple.
Couche de règlement : sécurité et liquidité sur Ethereum
Comme le rollup majeur d'aujourd'hui, Eclipse Mainnet sera réglé avec Ethereum. Concrètement, cela signifie que notre pont de vérification sur Ethereum sera intégré directement dans Eclipse. Le nœud Eclipse examinera ce pont pour déterminer la « chaîne canonique ». Ce pont applique un ordre correct pour Eclipse.
Cela permet à nos utilisateurs d’obtenir certaines propriétés de sécurité d’Ethereum. Le pont validera toutes les transactions Eclipse et empêchera la validation d'états non valides. De plus, cela renforcera la vivacité finale et la résistance à la censure dans certains cas d'échec. Même si le donneur d'ordre de L2 cesse de fonctionner ou commence la censure, les utilisateurs pourront forcer l'inclusion de leurs transactions via le pont.
En raison de ces propriétés de sécurité, les bibliothèques valides et optimales sont souvent appelées « Ethereum L2 ». L2BEAT définit L2 comme « une chaîne qui tire entièrement ou partiellement sa sécurité de la couche 1 d’Ethereum afin que les utilisateurs n’aient pas besoin de compter sur l’honnêteté des validateurs L2 pour protéger leurs fonds ».
Le règlement d’Ethereum reflète l’importance des actifs natifs d’Ethereum dans les économies DeFi et NFT d’Eclipse Mainnet. L’ETH est clairement la monnaie décentralisée préférée de la plupart des utilisateurs, nous utiliserons donc également l’ETH comme jeton de gaz. À long terme, l'abstraction des frais permettra aux utilisateurs de payer avec n'importe quel jeton de leur choix (par exemple USDC). Actuellement, Eclipse Mainnet n'a pas l'intention d'émettre ses propres jetons.
Disponibilité des données : bande passante et vérifiabilité de Celestia
Eclipse Mainnet utilisera Celestia pour la disponibilité des données (également appelée publication de données ou publication de données). Celestia est un partenaire écosystémique à long terme d'Eclipse.
Le débit et les frais cibles d'Eclipse Mainnet ne sont malheureusement pas pris en charge par les limitations actuelles de bande passante d'Ethereum. Cela est vrai même après EIP-4844 (alias « Proto-danksharding »), qui fournit environ 0,375 Mo d'espace blob par bloc (avec une limite par bloc d'environ 0,75 Mo).
En comparaison, Celestia lancera des blocs de 2 Mo d'ici la fin de cette année. Une fois qu'un nombre suffisant de nœuds légers DAS (Data Availability Sampling) seront mis en ligne et que le réseau se révélera stable, l'espace blob devrait augmenter à 8 Mo peu de temps après le lancement. Le nœud lumineux DAS remplit deux fonctions clés :
Celestia devrait être la première couche DA à activer le DAS en production. Cela contraste avec les comités de disponibilité des données (DAC) traditionnels, qui réintroduisent l’hypothèse d’honnêteté du comité sans vérification de l’utilisateur (similaire aux blockchains monolithiques existantes).
Il existe des hypothèses de sécurité inhérentes pour les utilisateurs qui transfèrent les fonds du réseau principal Ethereum vers n'importe quelle chaîne utilisant DA hors chaîne. En particulier, les validateurs de Celestia peuvent techniquement rejeter les données de transaction mais affirmer que les données sont disponibles sur le pont Ethereum. En fait, le consensus sur la preuve de participation de Celestia signifie que la rétention de données par Celestia elle-même est punissable, ce qui nous fait croire que ce risque est irréaliste.
Dans l'ensemble, la prise en charge des nœuds légers DAS de Celestia, ses propriétés de sécurité cryptoéconomiques et son débit DA hautement évolutif dès le premier jour en font le choix évident pour Eclipse Mainnet aujourd'hui.
Nous avons également l'intention de surveiller les progrès d'Ethereum en matière de mise à l'échelle du DA après l'EIP-4844. De nouvelles recherches passionnantes émergent qui pourraient fournir une DA à haut débit plus tôt qu’on ne le pensait (cette dernière utilisant des tables de hachage distribuées plus avancées). Si Ethereum offre une plus grande échelle à nos utilisateurs, nous évaluerons la possibilité de migrer vers Ethereum DA.
Preuve : Preuve de fraude RISC Zero ZK (aucune sérialisation d'état intermédiaire requise !)
Notre preuve sera similaire au SIMD anti-fraude SVM d'Anatoly, qui lui-même est similaire à 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 voulons éviter de réintroduire les arbres Merkle dans SVM. Nous avons essayé d'insérer une arborescence Merkle clairsemée après chaque transaction dans SVM, mais la mise à jour de l'arborescence Merkle a entraîné une perte de performances importante. Ne pas utiliser les arbres Merkle exclut les cadres de cumul à usage général existants (tels que la pile OP) comme base du cumul SVM, et nécessite également des architectures plus créatives et résistantes aux pannes.
En bref, la preuve d'échec nécessite :
Les engagements d'entrée sont généralement accomplis en fournissant une racine Merkle de l'arborescence d'état de cumul. Notre exécuteur publiera une liste d'entrées et de sorties (y compris les hachages de compte et l'état global associé) 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 auto-extraire le compte dans son propre état, calculer le compte de sortie et confirmer que l'engagement sur Ethereum est correct.
Il existe deux principaux types de pannes possibles :
Nous nous tenons sur les épaules de géants. Le rollup d’aujourd’hui a fait progresser la recherche dans notre secteur et offre aux utilisateurs d’Ethereum des frais inférieurs à ceux de L1.
Cependant, ils ne profitent pas pleinement des dernières technologies qui nécessitent une grande échelle. Des progrès incroyables récents ont éliminé la nécessité de faire ces compromis comme le faisaient les rollups précédents, les désavantageant effectivement :
Nous pouvons tirer les leçons des limites rencontrées par d’autres chaînes et sélectionner les meilleurs éléments pour une expansion à long terme.
Nous entendons souvent parler d’un million de Rollups spécifiques aux applications à l’avenir.
La personnalisation au niveau du consensus peut être très utile pour certaines applications (telles que dYdX v4), et nous sommes heureux d'aider l'équipe à lancer des rollups spécifiques à l'application.
Ces situations sont cependant rares. C'est pourquoi la plupart des nouveaux rollups ne sont encore que de simples forks EVM. Les problèmes des développeurs ne seront pas résolus en fragmentant l’UX sur plusieurs chaînes. Le principal cas d’utilisation trouvé aujourd’hui pour des millions de chaînes semble souvent être simplement le lancement de plus de pièces. Pour la grande majorité des cas d’utilisation, la nécessité d’une personnalisation complète de la pile technologique n’existe pas aujourd’hui.
Même si une demande réelle existe, l’infrastructure nécessaire pour prendre en charge de nombreuses chaînes d’applications avec une UX compétitive ne sera pas en place avant des années (voire pas du tout). La Superchain d'Optimism (pile OP), les Hyperchains de zkSync (pile ZK), la chaîne Orbit d'Arbitrum, etc. ont toutes la vision de nombreuses chaînes avec une infrastructure partagée. Ceci vise à fournir une UX plus fluide pour les opérations inter-chaînes au sein du même écosystème (par exemple, entre deux chaînes au sein d'une Superchain), plutôt que pour des chaînes complètement isolées (par exemple, entre Ethereum et Solana).
Cependant, les projets actuels (s’ils existent) sont loin de permettre de rivaliser avec un État unique partagé. De plus, ils ne résolvent pas les problèmes d’interopérabilité entre les écosystèmes (par exemple, Superchain à Hyperchain). Construire la modularité ne doit pas signifier construire des silos.
Il est plus compliqué pour les utilisateurs de gérer des comptes sur de nombreuses chaînes. Traverser constamment les chaînes et se soucier des jetons de gaz requis est une pire expérience utilisateur. S’appuyer sur des fournisseurs d’infrastructures pour exploiter et entretenir autant de chaînes est également plus complexe et plus coûteux.
Nous avons toujours admiré la simplicité de la vision de Solana. Une machine à états partagée hautement optimisée avec l’échelle nécessaire pour prendre en charge les cas d’utilisation les plus précieux. Ceci est souvent considéré comme incompatible avec les feuilles de route centrées sur le cumul, mais ce n'est pas réellement le cas. Nous voulions combiner le meilleur des deux mondes.
Ce malentendu est dû au fait que les rollups actuels exécutent en grande partie l'EVM original à thread unique, qui est resté en grande partie inchangé pour tirer parti des premiers effets de réseau. Par conséquent, nous voyons souvent « l’espace de bloc privé » cité comme raison du déploiement de cumuls spécifiques à l’application. Les autres applications de votre chaîne ne devraient pas voir leurs prix augmenter à cause d'une frappe NFT folle, mais la réponse n'est pas de construire votre propre chaîne. Vous faites des compromis pénibles et inutiles (complexité, coût, moins bonne expérience utilisateur, liquidité fragmentée, etc.). La meilleure solution est claire : utilisez simplement une VM parallèle avec un marché payant natif pour les hotspots d’État. C'est exactement ce qu'apporte SVM.
Ethereum est le centre intellectuel, social et économique de la crypto. Son talon d'Achille a toujours été l'expansion. L'expansion de la disponibilité des données est toujours un travail en cours, et les environnements d'exécution L2 existants ne peuvent pas rivaliser avec les innovations plus récentes telles que les SVM. Nous craignons que si le statu quo actuel persiste, l’écosystème Ethereum soit pris au dépourvu en cas d’augmentation spectaculaire de l’activité. Les EVM monothread et la disponibilité limitée des données peuvent rapidement entraîner une résurgence de coûts élevés, mais cette fois-ci en matière de cumuls.
Nous pensons qu'Eclipse Mainnet est la solution évidente : combinant les performances de Solana avec la sécurité, la vérifiabilité et les effets réseau d'une feuille de route centrée sur le cumul.
Conclusion
La beauté d’Ethereum est qu’il innove constamment. Les feuilles de route centrées sur le rollup en sont un exemple, déléguant l'exécution et l'innovation au marché libre. L2 a l’étrange capacité de tirer parti des effets de réseau et des garanties de règlement d’Ethereum tout en expérimentant les meilleurs nouveaux environnements d’exécution. Eclipse Mainnet est une mise en œuvre naturelle de cette vision.
Si une couche d’exécution plus performante devait émerger un jour, nous serions très heureux de la voir déployée en tant qu’Ethereum L2 compétitif. D’ici là, SVM reste la norme.