Au cours des dernières semaines, je n'ai pas partagé beaucoup de mises à jour sur @ethrex_client, notre client d'exécution L1 @class_lambda @ethereum et notre pile ZK L2. Veuillez suivre @ethrex_client pour en savoir plus sur tout ce que nous faisons. Dans le L1, nous exécutons déjà avec succès des testnets Ethereum et dans le L2, nous exécutons des testnets pour les applications d'identité et DeFi que nous construisons pour et avec des partenaires. Je crois sincèrement que nous sommes proches d'avoir la base de code et la pile les plus simples à maintenir, mettre à jour et modifier dans Ethereum. Nous n'aurions pas pu atteindre ce point sans vérifier le code de @NethermindEth et @go_ethereum. Avec mes partenaires @rj_aligned, @fran_aligned de @alignedlayer et @SantiDiPaolo, @AguuMg de @PolFinance_, nous sommes sur le point de publier l'un des premiers livres blancs sur un RWA L2 qui sera alimenté par Ethrex et @alignedlayer. Nous en avons beaucoup d'autres à venir, mais je suis particulièrement enthousiaste à propos de celui-ci car il reliera un cas d'utilisation très intéressant entre TradFi et DeFi. Nous avons comme conseillers et partenaires certaines des équipes les plus solides de l'industrie. J'ai hâte de partager plus sur ce projet. Mises à jour L1 Nous avons travaillé sur de nombreux fronts. Nous avons amélioré l'observabilité avec Grafana, supprimé des fonctionnalités inutilisées pour simplifier la base de code et ajouté le support pour le point de terminaison `engine_getBlobsV1`. Changelog : feat(l1) : point de terminaison de requête `engine_getBlobsV1` (#3636) chore(l1) : suppression du support redb (#4103) refactor(l1) : suppression des usizes inutiles du crate blockchain (#4110) fix(l1) : suppression d'un clone d'état inutile (#4117) fix(l1) : utilisation de l'image docker appropriée pour démarrer les localnets. (#4131) chore(l1) : ajout du temps de bloc au tableau de bord Grafana. (#4112) fix(l1) : soustraction des temps de lecture de la DB de l'exécution des blocs. (#4051) chore(l1) : améliorations des métriques. (#4118) chore(levm) : amélioration de l'organisation du nouveau test runner levm (#3958) L2 Dans le cadre de notre approche minimaliste, nous avons supprimé une quantité significative de code des bases de données L2 inutilisées. Nous continuons à simplifier la base de code et à éliminer le code mort. De plus, le CI a été stabilisé après avoir corrigé un bug lié aux prix du gaz. Nous évaluons le L2 sur deux fronts : - Coût de maintenance du réseau L2 : Nous ajustons les paramètres L2 en simulant divers scénarios avec différentes charges de transaction et configurations réseau. L'objectif est de déterminer le coût approximatif de la commission de maintenance par transaction que les utilisateurs doivent supporter pour que le réseau atteigne l'autosuffisance. - Benchmarks de génération de preuve d'exécution de bloc isolé : En utilisant l'outil ethrex-replay, nous prouvons des blocs de Hoodi, Sepolia et Mainnet pour identifier d'éventuels bugs dans la base de code et mesurer les performances de notre prouveur. Du côté d'ethrex-replay, l'outil est suffisamment stable, et nous avons mis en place une infrastructure pour rejouer périodiquement les exécutions de blocs et les preuves des réseaux publics. Nous nous attaquons maintenant aux bugs qui ont émergé lors de ces exécutions. Certains bugs proviennent d'erreurs logiques dans ethrex, tandis que d'autres sont liés à l'utilisation de la mémoire. Les premiers sont principalement résolus, et nous faisons des progrès significatifs sur les derniers. Nous avons également commencé à examiner @ziskvm et @0xLita ZKVMs pour une intégration potentielle à court terme. Nous supportons déjà @RiscZero et @SuccinctLabs. Cette semaine, nous avons fusionné une PR qui stabilise ethrex-replay, nous permettant d'identifier et de résoudre deux bugs dans ethrex. Ces corrections ont également été fusionnées. Le premier bug concernait un cas particulier dans notre précompilation ecrecover, où une entrée spécifique provoquait un échec d'exécution en raison d'un désaccord sur le gaz. Après une enquête approfondie, nous avons retracé le problème à la bibliothèque secp256k1 officielle patchée SP1. Nous l'avons résolu en migrant vers la bibliothèque k256 patchée SP1. Le deuxième bug provenait d'une hypothèse incorrecte sur la longueur de bit d'un type usize dans une partie de la base de code. Pour éviter des problèmes similaires, nous avons effectué un examen complet de la base de code et soumis plusieurs PR pour restreindre l'utilisation de usize à deux cas spécifiques : l'indexation et les scénarios contraints par une API ou une bibliothèque. De plus, nous ajoutons le support pour exécuter les suites de tests EF, y compris les tests de blockchain et d'état, avec SP1 pour améliorer notre couverture de test et garantir la robustesse à travers différents scénarios d'exécution. Avec ces bugs résolus, les problèmes ne se produisent plus. Nous réussissons à rejouer de nouveaux blocs Hoodi et Sepolia, et les exécutions de blocs Mainnet se sont considérablement améliorées, avec le taux de succès d'exécution SP1 passant de 1/10 à 6/10. Ce progrès ouvre la voie à la résolution de nos défis restants avec les replays de blocs récents : erreurs de mémoire lors de l'exécution de blocs dans le zkVM SP1 et problèmes de performance dans l'exécution et la preuve. Pour y remédier, nous avons mis en place le crate de l'outil pour le profilage de la mémoire en utilisant le crate Jemalloc. Nous travaillons également sur le support du replay de blocs historiques. Un MVP pour cette fonctionnalité est dans une PR de brouillon et fonctionne bien avec les clients ethrex, reth et geth, mais rencontre des problèmes avec les clients nethermind. Avant de publier la première version, nous visons à optimiser les requêtes RPC pour garantir des téléchargements de données de blocs précis, même en utilisant des fournisseurs RPC gratuits, pour la majorité des blocs. Améliorations DevEx : - Nous avons corrigé nos builds binaires pour ne plus nécessiter CUDA comme dépendance par défaut sur certains systèmes d'exploitation et architectures. Cette correction est incluse dans la dernière version. - Une PR a été soumise pour mettre à jour la version d'ethrex dans rex, garantissant la compatibilité avec les dernières modifications dans ethrex L2. - Nous avons commencé à développer un nouvel onglet pour le moniteur ethrex L2 dans les environnements de développement. Cet onglet affichera des informations pertinentes pour les développeurs, telles qu'une liste de comptes riches et les adresses des contrats L1 et L2. Changelog : - refactor(l2) : remplacement des constantes de différence d'état usize. - feature(l1,l2) : configuration d'ethrex-replay pour le profilage de la mémoire. - refactor(l1) : suppression de l'utilisation inutile de usize dans le crate blockchain (lié à la correction de bug). - feature(l1,l2) : ajout de nouvelles commandes au témoin d'exécution. - fix(levm) : résolution des problèmes liés à l'architecture 32 bits (lié à la correction de bug). - refactor(levm) : mise à jour de l'implémentation d'ecrecover pour utiliser k256 au lieu de secp256k1 (lié à la correction de bug). - ci(l1,l2) : séparation des builds GPU et adoption de la cible x86-64-v2. Performance Cette semaine, nous avons poursuivi notre attention sur la consommation CPU et les benchmarks. Concernant la consommation CPU, nous avons identifié 2 cas différents, l'un où la construction de blocs est présente et l'autre où elle ne l'est pas. Nous priorisons ceux sans construction de blocs étant donné qu'ils sont toujours présents et impactent d'autres efforts (comme la synchronisation instantanée). D'après nos investigations, cela est complètement lié au p2p. Nous continuerons nos efforts sur ce front. En ce qui concerne les benchmarks, après notre amélioration de la performance modexp la semaine dernière, nous nous sommes concentrés sur certaines améliorations détectées, comme codecopy et les opérations connexes ainsi que signextend, mulmod et addmod. Nous continuerons notre attention sur la consommation CPU et la performance des tests que nous avons identifiés comme prochaines étapes pour d'éventuelles améliorations, comme les transferts eth et d'autres opcodes levm.