jakiro
Auteurs : Wei Han Ng, Carlos Pérez, équipe de recherche consensuelle sur les apatrides ; Traduction : @bitchainvisionxiaozou
Ethereum est passé d’un petit réseau expérimental à un composant essentiel de l’infrastructure mondiale. Il règle des milliards de dollars en valeur de règlement quotidienne, coordonne des milliers d’applications et prend en charge l’ensemble de l’écosystème du réseau de couche 2 (L2).
Tout repose en fin de compte sur un composant sous-jacent essentiel : l’état (état).
1, qu’est-ce que c’est« Statut« et son importance
Le solde d’un utilisateur n’est pas stocké dans son portefeuille, mais dans l’état d’Ethereum.L’état peut être grossièrement compris comme « tout ce qu’Ethereum sait actuellement » : les comptes, le stockage du contrat (toutes les données écrites par le contrat), le bytecode (la logique qui s’exécute lors de l’utilisation de contrats intelligents).
L’état est la base de presque toutes les fonctionnalités :
Les portefeuilles en dépendent pour afficher les soldes et les enregistrements d’opérations passées ;
Les applications décentralisées (Dapps) l’interrogent pour connaître les positions, commandes ou messages existants ;
L’infrastructure (explorateurs de blocs, ponts inter-chaînes, indexeurs, etc.) lit en permanence l’état pour fournir des services par-dessus.
Si l’État devient trop grand, trop centralisé ou difficile à servir, toutes les couches ci-dessus deviennent plus fragiles, plus coûteuses et plus difficiles à décentraliser.
2,L1L’expansion a des conséquences
Ethereum continue de travailler à l’expansion du réseau depuis de nombreuses années : via le réseau de deuxième couche, EIP-4844, l’augmentation de la limite de gaz, la retarification des frais de gaz et le mécanisme intégré de séparation proposant-constructeur.Chaque étape a amélioré les capacités de traitement du réseau, mais a également apporté de nouveaux défis.
Défi 1 : le statut continue de s’étendre
La taille de l’État d’Ethereum ne fait qu’augmenter. Chaque nouveau compte, opération de stockage et écriture de bytecode augmente de manière permanente la quantité de données que le réseau doit contenir.
Cela entraîne des coûts spécifiques :
Les validateurs et les nœuds complets doivent stocker plus de données.À mesure que l’échelle de l’État augmente, la base de données doit gérer une charge de travail supplémentaire et l’efficacité diminue.
Le fournisseur de services RPC doit rester entièrement accessible et garantir que tout compte ou donnée stockée peut être interrogé à tout moment.
La croissance du statut entraîne une synchronisation des nœuds plus lente et une stabilité réduite.
L’augmentation de la limite de gaz augmente le gonflement de l’état, car chaque bloc peut accueillir davantage d’opérations d’écriture. Ce problème s’est déjà produit dans d’autres chaînes publiques.À mesure que l’échelle de l’État s’étend, il est difficile pour les utilisateurs ordinaires d’exécuter des nœuds complets, ce qui entraîne la concentration des données d’État entre les mains de quelques grands fournisseurs de services.
Dans Ethereum, la plupart des blocs ont été produits par des constructeurs professionnels.La principale préoccupation est de savoir combien d’entités indépendantes peuvent encore achever la construction de blocs de bout en bout au moment critique.Si seul un très petit nombre de participants peut stocker et fournir un état complet, la résistance à la censure et la neutralité de confiance seront compromises, car il y aura moins de donneurs d’ordre capables de construire des blocs contenant des transactions censurées.
Une partie du facteur positif réside dans le fait que des mécanismes tels que FOCIL et VOPS sont conçus pour garantir la résistance à la censure dans l’écosystème des constructeurs professionnels.Mais son efficacité repose toujours sur un écosystème sain de nœuds capables d’accéder, de stocker et de fournir des données d’état à un coût abordable.Par conséquent, contrôler la croissance de l’État est une condition préalable nécessaire et non une optimisation facultative.
Pour déterminer le point critique du problème, nous effectuons activement des tests de résistance :
Quand la croissance de l’État devient-elle un goulot d’étranglement ?
Quand la taille de l’État rend-elle difficile pour les nœuds de suivre la tête de chaîne ?
Lorsque les implémentations client échouent à des échelles d’état extrêmes.
Défi 2 : Dans une architecture sans état, qui est responsable du stockage et de la fourniture de l’état ?
Même si Ethereum maintient le plafond d’essence actuel en permanence, nous finirons par rencontrer le problème de l’inflation de l’État.Dans le même temps, la communauté s’attend clairement à un débit plus élevé.
Les systèmes sans état suppriment une limitation importante : les validateurs n’ont pas besoin de détenir l’état complet pour valider les blocs, seulement des preuves.Il s’agit d’une avancée importante en matière d’évolutivité qui répond à la fois au besoin de débit plus élevé de la communauté et révèle un fait autrefois caché selon lequel le stockage d’état peut évoluer vers une fonction indépendante et plus spécialisée, plutôt que d’être lié à chaque validateur.
À ce stade, la majeure partie de l’état ne peut être stockée que par :
constructeur de blocs ;
Fournisseur de services RPC ;
Autres opérateurs professionnels (tels que les chercheurs MEV et les explorateurs de blocs).
En d’autres termes, l’État deviendra plus centralisé.
Cela a de multiples conséquences :
Difficulté accrue de synchronisation : les prestataires de services centralisés peuvent commencer à restreindre l’accès au statut, ce qui rend difficile le démarrage de nouveaux prestataires de services ;
Résistance à la censure affaiblie : si les données de statut censurées ne peuvent pas être obtenues, les mécanismes anti-censure tels que FOCIL peuvent échouer ;
Risque de résilience du système : si seules quelques entités stockent et fournissent un état complet, leur interruption de service ou leur pression externe couperont rapidement l’accès à la plupart des composants de l’écosystème.
Même si de nombreuses entités conservent leur état, il n’existe aucun moyen efficace de vérifier qu’elles fournissent réellement des services, et les incitations existantes sont insuffisantes.La synchronisation des instantanés est largement prise en charge par défaut, mais les services RPC ne le sont pas.Sans réduire le coût des services publics ni accroître leur attrait universel, la capacité du réseau à accéder à son propre État sera limitée à un petit nombre de prestataires de services.
Ce problème affecte également les réseaux de couche 2. La capacité des utilisateurs à forcer des transactions packagées repose sur un accès fiable à l’état du contrat Rollup sur L1.Si l’accès à l’état L1 devient fragile ou hautement centralisé, ces mécanismes de soupape de sécurité seront difficiles à exploiter dans des applications pratiques.
3, les trois grandes directions que nous voyons
(1) Durée de validité du statut
Toutes les données étatiques n’ont pas la même importance permanente.Notre analyse récente montre qu’environ 80 % des données de l’État n’ont pas été consultées depuis plus d’un an.Cependant, les nœuds supportent toujours le coût du stockage de cet état à perpétuité.
L’idée centrale du mécanisme de validité d’état est de supprimer temporairement l’état inactif de « l’ensemble actif », puis de le restaurer au moyen d’une forme de preuve si nécessaire.D’une manière générale, on peut les diviser en deux grandes catégories :
Catégorie 1 : Marque, Invalidation, Résurrection
Au lieu de traiter tous les états comme actifs en permanence, le protocole marque les états rarement utilisés comme inactifs afin qu’ils ne persistent plus dans l’ensemble actif maintenu par chaque nœud, tout en permettant leur restauration dans le futur grâce à une preuve historique de leur existence.L’effet pratique est que les contrats et les soldes couramment utilisés restent actifs et ont de faibles coûts d’accès, tandis que les états oubliés depuis longtemps n’ont pas besoin d’être transportés en permanence par chaque nœud et peuvent toujours être rappelés lorsque quelqu’un en a à nouveau besoin.
Catégorie 2 : Mécanisme de défaillance multicycle
Dans une conception multipériode, nous n’invalidons pas les entrées individuelles, mais divisons périodiquement l’État en périodes (par exemple, une période = un an). Le cycle actuel est plus petit et pleinement actif, l’ancien cycle est gelé du point de vue de l’exécution en temps réel et le nouvel état est écrit dans le cycle actuel.L’ancien état ne peut être restauré qu’en prouvant son existence lors du cycle précédent.
Le mécanisme de marquage-invalidation-résurrection est généralement plus sophistiqué et le processus de résurrection plus simple, mais le processus de marquage nécessite le stockage de métadonnées supplémentaires.Les échecs multicycles sont conceptuellement plus simples et plus naturellement intégrés aux mécanismes d’archivage, mais les preuves de résurrection ont tendance à être plus complexes et plus volumineuses.
En fin de compte, ces deux approches partagent le même objectif : maintenir l’état actif léger en supprimant temporairement les parties inactives tout en ouvrant la voie à la résurrection – mais elles font des compromis différents en termes de complexité, d’expérience utilisateur et d’allocation du travail aux clients et à l’infrastructure.
(2) Archives de statut
L’archive d’état divise l’état en état froid et chaud.
Les états chauds sont des parties du réseau qui nécessitent un accès fréquent ;
L’état froid est la partie qui est encore importante pour l’histoire et la vérifiabilité, mais qui est rarement touchée.
Dans la conception des archives d’état, les nœuds stockeront explicitement séparément les états chauds et les données historiques récemment fréquemment utilisés.Même si l’état global continue de croître, les parties qui doivent être accessibles rapidement (ensembles de données chaudes) peuvent rester de taille limitée.En pratique, cela signifie que les performances d’exécution du nœud – en particulier le coût d’E/S pour accéder à l’état – peuvent rester fondamentalement stables dans le temps, sans décliner à mesure que la chaîne vieillit.
(3) Abaisser le seuil pour le stockage et les services publics
Une question évidente est la suivante : pouvons-nous atteindre nos objectifs tout en détenant moins de données ?En d’autres termes, peut-on concevoir des nœuds et des portefeuilles qui ne nécessitent pas de stockage permanent de l’état complet tout en fonctionnant comme des participants valides ?
Une direction prometteuse concerne les solutions partiellement apatrides :
Les nœuds stockent et fournissent uniquement un état partiel (tel que des données liées à un utilisateur ou une application spécifique) ;
Les portefeuilles et les clients légers jouent un rôle plus actif dans le stockage et la mise en cache des fragments d’état requis, plutôt que de s’appuyer entièrement sur quelques grands fournisseurs de services RPC.Si le stockage peut être distribué en toute sécurité aux portefeuilles et aux nœuds de « niche », la charge pesant sur les opérateurs individuels sera réduite et le groupe de détenteurs d’État deviendra plus diversifié.
Une autre direction consiste à réduire les obstacles à la gestion d’infrastructures utiles :
Simplifier le processus de déploiement des nœuds RPC qui ne desservent qu’une partie de l’État ;
Concevez des protocoles et des outils qui permettent aux portefeuilles et aux applications de découvrir et d’intégrer plusieurs sources de données locales plutôt que de s’appuyer sur un seul point de terminaison RPC complet.
4, orientation future
L’état d’Ethereum devient tranquillement la clé de plusieurs questions centrales pour l’avenir du protocole :
Dans quelle mesure l’augmentation de la taille de l’État devient-elle un obstacle à la participation ?
Lorsque les validateurs peuvent valider des blocs en toute sécurité sans nécessiter d’état, qui stockera l’état ?
Qui fournira les services de statut aux utilisateurs ?Quelle est l’incitation ?
Certains problèmes restent à déterminer, mais la direction est claire : réduire les contraintes de l’État sur les performances, réduire les coûts de stockage et améliorer l’accessibilité des services.
Notre objectif actuel est de faire progresser le travail à faible risque et à rendement élevé :
Schéma d’archivage
Nous essayons des solutions hors protocole pour contrôler la taille de l’état actif tout en nous appuyant sur des solutions d’archivage pour stocker les données historiques. Cela fournira des données réelles sur les performances, l’expérience utilisateur et la complexité opérationnelle.Si la vérification est valide, elle peut être promue vers une mise à niveau dans le protocole si nécessaire.
Certains nœuds sans état et améliorations RPC
La plupart des utilisateurs et des applications interagissent avec Ethereum via des fournisseurs de services RPC centralisés.Nous travaillons sur les améliorations suivantes :
Réduisez la difficulté et le coût d’exécution des nœuds, même si les nœuds ne stockent pas tous les états ;
Permettre à plusieurs nœuds de collaborer pour fournir des services d’État complets ;
Augmentez la diversité des fournisseurs de services RPC et évitez les goulots d’étranglement ponctuels.
Ces projets ont été soigneusement sélectionnés pour leur utilité immédiate et leur compatibilité prospective : ils amélioreront à la fois la santé actuelle d’Ethereum et jetteront les bases de mises à niveau plus approfondies du protocole à l’avenir.
