Avertissement : Cet article a été traduit de sa langue originale pour votre commodité. Bien que nous nous efforcions d'être précis, il peut y avoir de légères erreurs ou différences d'interprétation. Pour une représentation la plus exacte et véritable, veuillez consulter la publication originale, disponible ici. Nous apprécions votre compréhension et vous encourageons à consulter la source originale pour des informations détaillées.
Il s'agit d'une republication du blog de Nick Dodson datant du 30 janvier 2024.
Introduction à la Réhydratation de l'état natif (Native State Rehydration), des techniques de minimisation de l'état (State Minimizing Techniques) et d'un modèle de transaction de minimisation de l'état (State Minimizing Transaction Model).
J'ai récemment donné plusieurs conférences sur la croissance de l'état, et en voyant davantage de discussions sur X à ce sujet, j'ai pensé élargir mes présentations et l'approche que nous adoptons avec Fuel.
Alors, plongeons directement dedans. L'un des obstacles les plus importants auxquels sont confrontées les blockchains est le problème de la "croissance de l'état" - un problème qui, s'il n'est pas maîtrisé, pourrait compromettre la scalabilité et l'efficacité des réseaux blockchain. Explorons ce qu'est la croissance de l'état, pourquoi c'est un problème, et les solutions proposées pour maintenir les blockchains légères et fonctionnelles à mesure qu'elles se développent.
Comprendre les goulets d’étranglement de l’exécution d’une Blockchain
Avant de plonger dans les complexités de la croissance de l'état, examinons de plus près les trois principaux composants d'une blockchain qui sont généralement les goulets d'étranglement à la scalabilité d’un réseau :
-
Exécution. Il s'agit du travail effectué par le CPU pour garantir une synchronisation adéquate, la validation et la création de blocs futurs. ✅ Résolu : Il existe de nombreuses options pour résoudre ce problème, telles que des machines virtuelles plus efficaces (FuelVM, Stylus, SVM, MoveVM) et l'exécution parallèle de transactions (utilisant tous les cœurs de votre processeur), ainsi que de meilleurs précompilés (fonctions prédéfinies dans une VM).
-
Data (stockage et disponibilité). Il s'agit des données de transaction réelles qui génèrent les changement d'état et permettent à d'autres nœuds de se synchroniser avec le réseau blockchain, ainsi que de prouver la fraude ou la validité des rollups. ✅ Résolu : Il existe quelques options pour résoudre ce problème, comme l'EIP-4844, les conceptions de sharding et les couches de disponibilité de données externes telles que Celestia, EigenDA et Avail.
-
L’état. Il s'agit des informations actives stockées dans une base de données locale qui garantit une validation adéquate de la chaîne et les transitions d'état. Il s'agit le plus souvent du "hot path" pour le fonctionnement de la blockchain, ce qui nécessite beaucoup d'accès aléatoires sur le disque et entraîne beaucoup d'entrées-sorties, ce qui est généralement le domaine le plus lent du traitement, à part les signatures et le hachage. ❌ Non résolu.
Chacune de ces sections jouent un rôle crucial dans le fonctionnement d'une blockchain, mais c'est “l'état" qui nous intéresse particulièrement lorsque nous discutons des problèmes de mise à l’échelles.
Le défi de la croissance de l’État
La croissance de l'état fait référence à l'accumulation croissante de données qui doivent être entièrement stockées et gérées par les nœuds dans un réseau blockchain. Parce que l'état est quelque chose qui croît avec le temps, il est souvent ignoré comme un "problème futur". Cependant, à mesure que la croissance de l'état devient exponentielle pour atteindre son seuil, le fonctionnement des nœuds est considérablement alourdi, et cela devient un facteur limitant la scalabilité — s'avérant fatal lorsqu'il entrave une adoption plus large et ralentit l'innovation.
La croissance de l'état conduit à des blockchains surchargées, où les temps de transaction plus lents et les coûts de stockage plus élevés deviennent la norme, ce qui à son tour peut limiter la scalabilité et l'accessibilité d'un réseau. Vous reconnaissez la situation ? C'est parce que s'attaquer à la croissance de l'état sera le prochain catalyseur pour stimuler l'économie des rollup, pas très différent de son problème prédécesseur, le débit, qui a déclenché la révolution du rollup.
Estimations de la taille de l'état des chaînes EVM populaires.
…mais, les rollups ne résolvent pas la croissance de l’état ?
Les rollups permettent à Ethereum d'ouvrir la porte à "quelque chose de nouveau". Les solutions existantes s'attaquent à la couche d'exécution, avec certaines solutions modulaires allant même jusqu'à aborder la disponibilité des données. Mais si ces nouvelles solutions ne s'attaquent pas au problème fondamental de l'état, alors vous êtes de nouveau confronté à un jeu à somme nulle. Toute blockchain conçue aujourd'hui, avec ou sans rollup, qui n'a pas de stratégie pour aborder la croissance de l'état sera en fin de compte limitée par l'engorgement de l'état, quel que soit son environnement d'exécution ou de données.
Comparaison des conceptions d'état
Pour illustrer le problème, comparons la gestion de l'état entre Bitcoin et Ethereum :
-
État de Bitcoin : Utilise un ensemble UTXO (Unspent Transaction Output) qui est plus simple et a traditionnellement été plus facile à gérer, mais avec une programmabilité limitée.
-
État d'Ethereum : Comprend les soldes des comptes, le code des contrats intelligents et l'état des contrats intelligents - englobant les soldes des jetons, les approbations, et plus encore.
Le modèle de gestion de l'état de Bitcoin est simplifié mais limité dans sa portée. L'état de Bitcoin est géré à travers des sorties de transaction individuelles qui peuvent être dépensées ou non dépensées. Son modèle UTXO (Unspent Transaction Output) maintient un état clair à travers des sorties de transaction qui sont soit non dépensées et prêtes pour des transactions futures, soit dépensées et donc archivées dans l'historique de la blockchain. Cela rend le modèle UTXO relativement plus facile à gérer et garantit que l'état ne croît pas de manière incontrôlable à chaque transaction. Cependant, cette simplicité se fait au détriment de la programmabilité limitée de Bitcoin par rapport au système Turing-compatible d'Ethereum.
Comparativement, le modèle d'état d'Ethereum, comporte un écosystème riche en soldes de compte, codes de contrats intelligents et de myriades d'états de contrats - chaque interaction produit une trame dans la base de données en constante évolution. Cette évolution constante de l'état, bien qu'elle témoigne de la polyvalence d'Ethereum, pose d'importants défis de scalabilité. À mesure que l'état gonfle avec chaque exécution de contrat intelligent et transaction, cela conduit à un réseau surchargé avec des exigences de stockage accrues et des temps de traitement plus lents, ce qui à son tour freine l'innovation et l'adoption par les utilisateurs.
Le contraste entre les approches de gestion de l'état de Bitcoin et d'Ethereum met en évidence un compromis fondamental dans la conception des blockchains : la simplicité et l'efficacité de la gestion de l'état par rapport à la complexité et au potentiel des opérations sur chaîne.
Solutions proposées pour résoudre la croissance de l'état
Plusieurs stratégies ont été proposées pour gérer la croissance de l'état :
Laisser croitre l'État
Accepter la croissance de l'état en échange d'une utilisation plus importante de la bande passante. Cette option n'est pas recommandée car elle impose des exigences plus élevées aux nœuds complets, ce qui restreint la décentralisation du réseau.
Location de l'État
Facturer des frais pour stocker les données d'état, avec le compromis de problèmes potentiels tels que la 'pourriture d'arbre' (si tous les éléments d'état d'Ethereum sont dans un arbre et que vous oubliez certaines des feuilles, vous corrompez certains des chemins de branchement), parmis d’autres problèmes.
État sans état
Les nœuds complets n'auraient pas besoin de stocker l'état, s'appuyant sur des preuves d'état incluses avec les transactions et les blocs. Essentiellement, déplacer l'état de la chaîne de couche 1 vers les rollups. C'est la direction vers laquelle Ethereum se dirige, mais il reste de nombreuses questions sans réponse sur l'efficacité et la maintenabilité de cette approche.
https://vitalik.eth.limo/general/2021/06/18/verkle.html
"Dé-Merkalisation de l'État"
Une approche technique pour gérer les données de l'État différemment. En effet, vous utiliseriez efficacement les nœuds complets (full Node) pour valider tout ou échantillonner des éléments avec des clients légers (light client) et oublier complètement l'arbre d'état.
Compression de l'état au niveau de l'application
Utilisation de techniques de compression des données d'appel (call-data) pour compresser les données d'état. Essentiellement, vous échangez de l'état contre de la bande passante. Des demandes de bande passante plus élevées conduisent à des réseaux contraints, avec des implications qui pèsent énormément en termes de robustesse et d'efficacité sur l’infrastructure
Exemple 1 : Stakeur Uniswap V3 (image à gauche). L'état doit être réhydraté sur la bande passante. Cela permet une conception très minimisée de l'état, et les données d'appel sont bien moins chères que le stockage sur Ethereum.
Exemple 2 : NFT compressés (image à droite). Données de propriété NFT merklisées et racine stockée dans l'état.
Et maintenant... Réhydratation native de l'état.
Philosophie de Fuel sur la gestion de l’état
En exploitant le modèle UTXO, plusieurs avantages sont obtenus :
-
Arbres d'état localisés : Pas d'arbre d'état global, seulement des arbres d'état locaux pour chaque contrat intelligent.
-
Actifs natifs : Toutes les transferts d'actifs n'affectent qu'un seul élément d'état. Les actifs natifs peuvent être utilisés pour représenter un état sans valeur (par exemple, un NFT pour représenter la propriété). Ces derniers n'ont pas besoin d'être “merkalisés”, simplifiant ainsi l'état.
-
Pas d'approbation de l’état : Élimination des changements d'état inutiles des fonctions d'approbation et de transfert.
Le modèle UTXO permet tout cela tout en conservant des clients légers et vérifiables cryptographiquement riches, créant un "mode rapide" pour une véritable interopérabilité (plus de détails à ce sujet dans un prochain billet). La principale philosophie derrière l'approche de Fuel est : utiliser plus de bande passante et d'exécution, tout en utilisant moins d'état. Mais comment ?
Réhydratation native de l'état
La réhydratation native de l'état décrit les méthodes que les développeurs de Fuel peuvent utiliser pour déshydrater ou compartimenter l'état. Les choses sont réhydratées via la bande passante, ce qui permet d'accéder de nouveau à l'état lorsque nécessaire. Cela s'opposerait à l'approche conventionnelle ("utiliser des contrats intelligents pour tout") d'Ethereum, en utilisant des recherches d'état de contrat.
La nouvelle approche :
-
Stocker uniquement les hachages de racine / les changements d'état
-
Présenter les données via la bande passante pour "réhydrater" l'état
-
Fournir des techniques de minimisation de l'état pour que le développeur puisse les exploiter.
Techniques de minimisation de l'état
Une attention portée à la bande passante et à l'exécution plutôt qu'au stockage d'état. Fuel offre au développeur de nombreuses façons de faire les choses autres que le simple stockage de contrats intelligents :
-
Scripts : La logique éphémère est incluse dans les transactions, et non stockée dans l'état. Contrairement aux transactions EVM qui peuvent appeler directement un contrat (mais ne peuvent appeler qu'un seul contrat), les transactions Fuel exécutent un script, qui peut appeler zéro ou plusieurs contrats.
-
Prédicats : Contrats légers et sans état. Un prédicat est un nouveau mécanisme pur pour autoriser les transactions. Un prédicat ne peut accéder qu'aux données d'une transaction, il ne peut pas voir l'état actuel de la chaîne. Les prédicats peuvent être utilisés, entre autres, pour permettre l'abstraction de compte native (sans état).
Découvrez-en davantage sur les Prédicats dans cet article de Ryan Sproule : Un prédicat n'est pas un contrat intelligent mais permet toujours une logique d'authentification personnalisée pour dépenser des jetons. Cela signifie que les prédicats peuvent être dépensés sans avoir besoin d'une clé privée, contrairement à toute transaction EVM. En pratique, cela signifie que les utilisateurs peuvent construire des prédicats qui peuvent être dépensés entièrement sans autorisation. Lorsqu'ils sont combinés avec le concept de scripts de Fuel, l'expérience utilisateur pour interagir avec des contrats intelligents devient extrêmement puissante.
Modèle de transaction minimisant l'état
En combinant des techniques de minimisation de l'état avec le modèle UTXO, nous pouvons créer un nouveau modèle de transaction flexible. Cela offre davantage d'options pour former des transactions complexes multi-parties qui ne nécessitent pas de contrats intelligents pour accéder à l'état.
En pratique, à quoi cela ressemblerait-il ? Exemple :
Smart-contract wallets (avec seulement un seul élément d'état de 32 octets)
-
L'état du contrat est stocké dans un seul hachage racine dans un UTXO
-
L'état est réhydraté via la bande passante lorsque nécessaire
-
Les UTXO garantissent la vérifiabilité des clients légers sans arbre de merkle global
-
Ne nécessite qu'une seule lecture d'IO
-
L'état peut être modifié lorsque l'UTXO d'état est dépensé
-
Aucune perte de fonctionnalité des smart contract wallet par rapport à Ethereum
-
La bande passante et l'exécution sont prioritaires par rapport à l'état
-
Tout est fait au niveau natif (prédicats)
L'architecture de Fuel est conçue pour incorporer toutes ces fonctionnalités ainsi qu'une exécution minimisée de l'état afin de créer un ensemble conçu spécifiquement pour les rollups Ethereum. Fuel apporte de nouvelles capacités dans l'écosystème Ethereum tout en préservant la sécurité par le règlement final sur Ethereum.
Alors que la bataille contre la croissance de l'état se poursuit, les outils et les stratégies, comme ceux de Fuel, offrent de l'espoir pour un avenir évolutif et efficace. Comme le dit le proverbe, "La nécessité est mère de l'invention", et dans le monde de la blockchain, la nécessité de vaincre la croissance de l'état a en effet conduit à des solutions innovantes.
评论 (0)