Nous avons commencé à construire Reth en 2022 pour offrir une résilience à Ethereum L1 et résoudre la mise à l'échelle de la couche d'exécution sur la couche 2.

Aujourd'hui, nous sommes ravis de partager le chemin de Reth vers 1 gigagas par seconde en L2 en 2024, et notre feuille de route à plus long terme pour aller au-delà de cela.

Nous invitons l'écosystème à collaborer avec nous alors que nous repoussons les limites des performances et des tests rigoureux dans la crypto.

Sommes-nous déjà à l'échelle ?

Il existe un chemin très simple pour que les crypto-monnaies atteignent une envergure mondiale et échappent à la spéculation en tant que cas d'utilisation dominant : les transactions doivent être bon marché et rapides.

Comment mesurez-vous la performance? Que signifie le gaz par seconde?

La performance est généralement mesurée par la métrique "Transactions Par Seconde" (TPS). Particulièrement pour Ethereum et d'autres blockchains EVM, une mesure plus nuancée et peut-être plus précise est "gas par seconde." Cette métrique reflète la quantité de travail de calcul que le réseau peut gérer chaque seconde, où "gas" est une unité qui mesure l'effort de calcul nécessaire pour exécuter des opérations telles que des transactions ou des contrats intelligents.

La normalisation autour du gaz par seconde en tant que métrique de performance permet une compréhension plus claire de la capacité et de l'efficacité d'une blockchain. Cela aide également à évaluer les implications de coût sur le système, en se protégeant contre les attaques potentielles de déni de service (DOS) qui pourraient exploiter des mesures moins nuancées. Cette métrique aide à comparer les performances entre différentes chaînes compatibles avec la machine virtuelle Ethereum (EVM).

Nous proposons à la communauté EVM d'adopter le gaz par seconde comme mesure standard, tout en l'incorporantautres dimensions de la tarification du gazcréer une norme de performance complète.

Où sommes-nous aujourd'hui?

Le gaz par seconde est déterminé en divisant l'utilisation cible de gaz par bloc par le temps de bloc. Ici, nous présentons le débit actuel de gaz par seconde et la latence sur diverses chaînes EVM L1 et L2 (non exhaustives):

Nous mettons l'accent sur le gaz par seconde pour évaluer minutieusement les performances du réseau EVM, en capturant à la fois les coûts de calcul et de stockage. Des réseaux comme Solana, Sui ou Aptos ne sont pas inclus en raison de leurs modèles de coûts distincts. Nous encourageons les efforts en vue d'harmoniser les modèles de coûts sur l'ensemble des réseaux blockchain pour permettre des comparaisons complètes et équitables.

Nous travaillons sur une suite de benchmarking continue pour Reth qui reproduit une charge de travail réelle, si vous souhaitez collaborer sur ce projet, n'hésitez pas à nous contacter. Nous avons besoin d'une Banc d'essai TPCpour les nœuds.

Comment Reth atteindra-t-il 1 gigagas par seconde ? Au-delà de cela ?

Nous avons été partiellement motivés pour construire Reth en 2022 par le besoin pressant d'avoir un client spécialement conçu pour les rollups à l'échelle du web. Nous pensons avoir un chemin prometteur devant nous.

Reth atteint déjà 100-200mgas/s lors de la synchronisation en direct (y compris la récupération des expéditeurs, l'exécution des transactions et le calcul du trie à chaque bloc); 10x d'ici nous amène à notre objectif à court terme de 1 gigagas/s.

Alors que nous avançons dans le développement de Reth, notre plan de mise à l'échelle doit équilibrer la scalabilité avec l'efficacité:

• Mise à l'échelle verticale : Notre objectif ici est de maximiser l'utilisation de chaque “boîtier” à son plein potentiel. En optimisant la manière dont chaque système individuel gère les transactions et les données, nous pouvons grandement améliorer les performances globales, tout en rendant également plus efficace pour les opérateurs de nœuds individuels.
• Mise à l'échelle horizontale : Malgré les optimisations, le volume important de transactions à l'échelle web dépasse ce qu'un seul serveur peut gérer. Pour remédier à cela, nous voulons mettre en place une architecture à échelle horizontale, similaire à un modèle Kubernetes pour les nœuds blockchain. Cela signifie répartir la charge de travail sur plusieurs systèmes pour garantir qu'aucun nœud individuel ne devienne un goulot d'étranglement.

Les optimisations que nous explorons ici ne consistent pas à résoudre croissance de l'état, que nous étudions séparément.

Voici un résumé de comment nous avons l'intention d'y arriver :

À travers l'ensemble de la pile, nous optimisons également pour IO et CPU en utilisant le modèle acteur, pour permettre à chaque partie de la pile d'être déployée en tant que service avec un contrôle précis sur son utilisation. Enfin, nous évaluons activement des bases de données alternatives, mais n'avons pas encore décidé d'un candidat.

La feuille de route de mise à l'échelle verticale de Reth

Notre objectif ici est de maximiser les performances et l'efficacité d'un seul serveur ou ordinateur portable exécutant Reth.

Just-In-Time & Ahead-of-Time EVM

Dans des environnements blockchain comme la machine virtuelle Ethereum (EVM), l'exécution du bytecode se fait à travers un interpréteur, qui traite séquentiellement les instructions. Cette méthode introduit des frais généraux car elle n'exécute pas directement les instructions natives d'assemblage, mais fonctionne plutôt à travers la couche VM.

La compilation Just-In-Time (JIT) aborde ce problème en convertissant le bytecode en code machine natif juste avant l'exécution, améliorant ainsi les performances en contournant le processus interprétatif de la VM. Cette technique, qui compile les contrats en un code machine optimisé à l'avance, est bien établie dans d'autres VM comme Java et WebAssembly.

Cependant, JIT peut être vulnérable aux codes malveillants conçus pour exploiter le processus JIT, ou peut être trop lent pour s'exécuter en direct pendant l'exécution. Reth va compiler Ahead-of-Time (AOT) les contrats les plus demandés et les stocker sur disque, pour éviter que du bytecode non fiable tente d'abuser de notre étape de compilation de code natif pendant l'exécution en direct.

Nous travaillons actuellement sur un compilateur JIT/AOT pour Revm, en cours d'intégration avec Reth. Nous allons rendre cela open source dans les semaines à venir une fois nos tests de référence terminés. En moyenne, environ 50% du temps d'exécution est passé dans l'interpréteur EVM, donc cela devrait fournir une amélioration de l'exécution EVM d'environ 2x, bien que dans certains cas plus exigeants en calcul, cela pourrait avoir un impact encore plus important. Nous partagerons nos tests de référence et l'intégration de notre propre compilateur JIT EVM dans Reth dans les semaines à venir.

Parallel EVM

Le concept d'une machine virtuelle Ethereum parallèle (Parallel EVM) permet un traitement simultané des transactions, s'écartant du modèle d'exécution sériel traditionnel de l'EVM. Nous avons 2 chemins à suivre ici:

1. Synchronisation historique: En synchronisation historique, nous pouvons calculer le meilleur calendrier de parallélisation possible en analysant les transactions passées et en identifiant tous les conflits d'état historiques. Voir notre première tentative à ce sujet dans une ancienne branche sur Github.
2. Synchronisation en direct : Pour la synchronisation en direct, nous pouvons utiliser Block STMtechniques -like pour exécuter de manière spéculative sans aucune information supplémentaire comme des listes d'accès. Cet algorithme a de mauvaises performances pendant les périodes de forte contention d'état, nous voulons donc explorer le passage entre l'exécution sérielle et parallèle en fonction de la forme de la charge de travail, ainsi que prédire statiquement quels emplacements de stockage seront accédés pour améliorer la qualité de la parallélisme. Voir un PoC par une équipe tierce ici.

Selon notre analyse historique, environ 80 % des emplacements de stockage d'Ethereum sont accédés de manière indépendante, ce qui signifie que le parallélisme pourrait entraîner une amélioration pouvant aller jusqu'à 5 fois dans l'exécution de l'EVM.

Améliorer l'engagement de l'État

Nous a récemment écrit surl'impact de l'état racine sur les performances et les différences entre le modèle de base de données Reth des autres clients, ainsi que pourquoi il est important.

Dans le modèle Reth, calculer la racine de l'état est un processus distinct de l'exécution des transactions (voir notre code) permettant l'utilisation de magasins KV standard qui n'ont pas besoin de connaître quoi que ce soit sur l'arbre. Cela représente actuellement plus de 75% du temps de bout en bout pour sceller un bloc, et c'est un domaine très passionnant à optimiser.

Nous identifions les 2 "victoires faciles" suivantes qui peuvent nous donner 2-3x de performances dans la racine d'état, sans aucun changement de protocole :

1. Racine d'état entièrement parallélisée : Pour l'instant, nous ne recalculons que l'arbre de stockage pour les comptes modifiés en parallèle, mais nous pouvons aller plus loin et calculer également l'arbre des comptes en parallèle pendant que les tâches de racine de stockage se terminent en arrière-plan.
2. Racine d'état en pipeline: Préchargez les nœuds d'arbre intermédiaires depuis le disque pendant l'exécution en notifiant le service de racine d'état des emplacements de stockage et des comptes concernés.

Au-delà de cela, nous voyons quelques voies à suivre en divergeant du comportement racine de l’état Ethereum L1 :

1. Racine d'état moins fréquente : Au lieu de calculer la racine d'état à chaque bloc, calculez-la tous les T blocs. Cela réduit le pourcentage global du temps passé dans la racine d'état dans l'ensemble du système et pourrait être la solution la plus simple et la plus efficace.
2. Racine d'état en attente : Au lieu de devoir calculer la racine d'état au même bloc, laissez-la prendre du retard de quelques blocs. Cela permet à l'exécution de progresser sans bloquer sur le calcul de la racine d'état.
3. Remplacez le codeur RLP & Keccak256: Au lieu de coder avec RLP, il peut être moins cher de simplement concaténer les octets et d'utiliser une fonction de hachage plus rapide comme Blake3.
4. Arbre plus large : Augmentez l'arité de l'arbre pour réduire l'amplification de l'E/S due à la profondeur logN de l'arbre binaire.

Il y a quelques questions ici :

1. Quels sont les effets de second ordre des changements ci-dessus sur les clients légers, L2s, ponts, coprocesseurs et autres protocoles qui reposent sur des preuves de compte et de stockage fréquentes ?
2. Pouvons-nous optimiser à la fois l'engagement de l'état pour la preuve SNARK et la vitesse d'exécution native ?
3. Quel est l'engagement d'État le plus large que nous pouvons obtenir avec les outils dont nous disposons? Quels sont les effets de deuxième ordre autour de la taille du témoin?

La feuille de route de mise à l’échelle horizontale de Reth

Nous mettrons en œuvre plusieurs des points ci-dessus tout au long de l’année 2024 et atteindrons notre objectif de 1 gigagaz/s.

Cependant, l'escalabilité verticale rencontre finalement des limites physiques et pratiques. Aucune machine seule ne peut répondre aux besoins informatiques mondiaux. Nous pensons qu'il existe 2 voies à suivre ici, qui nous permettent de déployer en introduisant plus de boîtes à mesure que la charge augmente :

Multi-Rollup Reth

Les piles L2 d'aujourd'hui nécessitent l'exécution de plusieurs services pour suivre la chaîne : L1 CL, L1 EL, la fonction de dérivation L1 -> L2 (qui peut être regroupée avec la L2 EL), et la L2 EL. Bien que cela soit idéal pour la modularité, cela devient compliqué lors de l'exécution de plusieurs piles de nœuds. Imaginez devoir exécuter 100 rollups !

Nous voulons permettre le lancement des rollups dans le même processus que Reth et réduire le coût d'exploitation de l'exécution de milliers de rollups à presque zéro.

Nous sommes déjà en cours avec notre Projets d'extensions d'exécution ([1], [2]) plus encore dans les semaines à venir ici.

Reth natif dans le cloud

Les séquenceurs haute performance peuvent avoir une demande suffisante sur une seule chaîne pour nécessiter une mise à l'échelle au-delà d'une seule machine. Ceci n'est pas possible dans les implémentations de nœuds monolithiques actuelles.

Nous voulons permettre l'exécution de nœuds Reth natifs dans le cloud, déployés en tant que pile de services pouvant s'adapter automatiquement à la demande de calcul et utiliser le stockage d'objets infiniment extensible du cloud pour la persistance. Il s'agit d'une architecture courante dans les projets de base de données sans serveur tels que NeonDB, CockroachDB ou Amazon Aurora.

Voir premières penséesde notre équipe sur certaines façons dont nous pourrions aborder ce problème.

Perspective

Nous avons l’intention de déployer cette feuille de route progressivement auprès de tous les utilisateurs de Reth. Notre mission est de donner à tous l’accès à 1 gigagaz/s et au-delà. Nous testerons nos optimisations sur Reth AlphaNet, et nous espérons que les gens construiront des nœuds haute performance modifiés en utilisant Reth comme SDK.

Il y a des questions auxquelles nous n'avons pas encore trouvé de réponses.

• Comment Reth peut-il aider à améliorer les performances dans l'écosystème L2 ?
• Comment mesurons-nous correctement les scénarios du pire cas lorsque certaines de nos optimisations pourraient être pour le cas moyen?
• Comment gérons-nous la tension entre L1 et L2 qui pourraient diverger potentiellement ?

Nous n'avons pas de réponses à bon nombre de ces questions, mais nous avons suffisamment de pistes prometteuses initiales pour nous occuper un moment et espérons voir ces efforts porter leurs fruits dans les mois à venir.

Avertissement：

1. Cet article est repris de [Gateparadigme], Tous les droits d’auteur appartiennent à l’auteur original [Georgios Konstantopoulos]. If there are objections to this reprint, please contact the Gate Learn et ils s’en occuperont rapidement.
2. Responsabilité de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.