Introduction

Ce que les blockchains stockent et font référence lors du traitement des transactions est appelé l'état. Sur Ethereum, l'état est la propriété qui facilite le consensus des nœuds. Chaque nœud complet doit stocker et mettre à jour cet état pendant chaque période de blocs valides. L'état, aussi important qu'ils soient pour les blockchains, présente un inconvénient; ils augmentent avec le temps. Ils posent un problème majeur dans les blockchains, telles que Bitcoin et Ethereum, car l'augmentation de la taille s'accompagne d'une augmentation équivalente des exigences matérielles pour les nœuds. Le seuil d'espace exclut certains nœuds au fil du temps, entraînant une centralisation.EIP-2935propose d'apporter la non-appartenance à l'Éthereum, soulageant les nœuds du fardeau de la taille. EIP-2935 est une proposition d'amélioration qui tente d'atteindre la non-appartenance en stockant et en servant les derniers 8192 hachages de blocs de l'état pour l'exécution non-appartenante dans l'Éthereum.

Aperçu rapide de la structure actuelle d'Ethereum

Blocs

Les blocs sont des lots de transactions avec une référence (hash) du bloc précédent inclus dans la chaîne. Les hashs dans chaque bloc sont dérivés des données du bloc lui-même de manière cryptographique. Cette inclusion lie les chaînes ensemble avec des hashs, et le regroupement implique que tous les participants du réseau sont d'accord et synchronisent l'état en même temps. De plus, l'accord sur les blocs regroupés indique à Ethereum de mettre à jour son état mondial chez chaque participant du réseau en tant que nœud.

Alt: Changement d'état dans Ethereum

Une fois qu'un nouveau bloc est géré et diffusé avec un validateur sur le réseau, le reste des participants l'ajoutent à leur stockage et mettent à jour leur état global. Le validateur de chaque bloc est sélectionné aléatoirement par le Organisation autonome décentralisée de randomisation (RANDAO)Le paramètre. La structure des blocs est strictement ordonnée, et la création de blocs et les processus de consensus sont spécifiés dans le cadre du protocole de preuve d'enjeu d'Ethereum.

Un bloc contient plusieurs champs dans son en-tête et son corps. Par exemple, l'en-tête du bloc comprend les champs slot, proposer_index, parent_root, state_root, et body. Le corps du bloc comprend randao_reveal, eth1_data, graffiti, proposer_slashings, attester_slashings, attestations, deposits, voluntary_exits, sync_aggregate, et execution_payload. Chaque champ a des paramètres différents, répondant à des besoins différents.

Ethereum’s 12-secondLa période de création de bloc, également appelée "créneau", provient du fait de laisser suffisamment de temps aux participants du réseau pour se synchroniser avec les nouveaux blocs et se mettre d'accord sur le consensus. Pendant cette période :

1. Le proposant de bloc sélectionne aléatoirement un validateur,
2. Le validateur regroupe les transactions et les exécute pour déterminer un nouvel état global,
3. Ils incluent ces informations dans un nouveau bloc et les diffusent au reste de l'ensemble de validateurs via un protocole de propagation de rumeurs,
4. D'autres validateurs réexécutent les transactions pour garantir la validité et être d'accord avec le changement d'état global en tant que consensus,
5. Si le validateur vérifie que le nouveau bloc est valide, il l'ajoute à son stockage.

La finalité d'un bloc et d'une transaction signifie qu'ils ne peuvent pas être modifiés sans une importante consommation d'ETH dans un réseau distribué. Ethereum adopte une approche de "blocs de point de contrôle" pour gérer la finalisation. Le premier bloc de chaque époque est considéré comme le point de contrôle de cet intervalle. Les validateurs votent pour cette hypothèse afin de la rendre valide. Si les deux tiers de l'ETH total mis en jeu avec les votes des validateurs élisent une paire de points de contrôle, les points de contrôle sont promus à un statut justifié. Les points de contrôle justifiés précédents sont promus après la mise à niveau des points de contrôle suivants, et deviennent finalisés. Si un acteur malveillant souhaite annuler un bloc finalisé, il doit s'engager à perdre au moins un tiers de l'offre totale d'ETH mis en jeu. Bien qu'un mécanisme appelé fuite d'inactivitévise à rétablir la finalité en imposant de fortes pénalités sur les fonds des validateurs et en réduisant les récompenses des attestants en cas d'échec permanent d'un grand nombre de validateurs.

Lors du traitement du bloc, Ethereum applique une fonction de hachage pour prendre les données des blocs et les réduire à des chaînes uniques. Dans la fonction de hachage, chaque entrée produit une sortie unique. Les valeurs de hachage dans les blocs sont la seule partie immuable. Elle est modifiable avec un tiers de l'ETH misé total brûlé. Cependant, ce montant provient du recalcul des hachages de l'arbre de Merkle jusqu'à un point de contrôle. La sortie du processus de hachage pour chaque bloc est renvoyée avec le paramètre blockHash. Le paramètre blockHash inclut toutes les données dans le bloc.

Les valeurs de hash des blocs et d'autres paramètres nécessaires sont stockés dans les essais de Merkle. Ethereum utilise une architecture d'essai de Merkle avec différentes versions, telles que l'essai de Merkle Patricia.

Essais Merkle et Merkle Patricia

Les structures d'arbre, en particulier les arbres de Merkle, sont fondamentales pour le stockage de la blockchain. Sans les arbres de Merkle, les blockchains deviennent des blocs uniques qui sont difficiles à traiter à chaque fois. Avec les arbres de Merkle, ou plus généralement les architectures d'arbre, les blockchains atteignent l'exhaustivité avec des fragments de base. Cela leur permet de devenir des participants du réseau avec des exigences matérielles réduites.

Les essais de Merkle sont une manière structurée de hacher de grands nombres de morceaux et de les diviser en parties. Avec la Merkleisation, les données sont organisées en paires; chacune est hachée ensemble. Le processus de Merkleisation se répète jusqu'à ce qu'une seule racine de Merkle soit obtenue.

Ethereum préfère les essais de Merkle Patricia, une structure d'arbre binaire de Merkle double. Il utilise des essais binaires pour la manipulation des données de base, comme les données de transaction, car cette approche est plus efficace dans de telles situations. Cependant, Ethereum utilise les essais de Merkle Patricia plus complexes dans les cas complexes, comme la manipulation de l'état.

Dans un scénario de stockage de données de trie d'état, Ethereum utilise une carte clé-valeur. Les clés représentent des adresses et les valeurs représentent des déclarations de compte. Les tries d'état sont plus dynamiques que les tries binaires. Ainsi, de nouveaux comptes peuvent être fréquemment insérés et les clés peuvent être fréquemment insérées et supprimées. Ce processus nécessite une structure de données rapidement mise à jour qui ne nécessite pas de recalculer l'ensemble des données.

La racine du trie dépend uniquement des données, pas de l'ordre. Faire des mises à jour des données dans des ordres différents ne changera pas la racine elle-même.

Alt: Trie Merkle binaire

Ethereum utilise un arbre de Patricia Merkle modifié, qui possède certaines caractéristiques de PATRICIA (Algorithme Pratique de Récupération d'Informations Codées en Alphanumérique)et Merkle Trie avec des modifications le long de celui-ci. Cette architecture est déterministe et cryptographiquement vérifiable. La seule façon de générer une racine d'état dans cette structure est de la calculer à partir de chaque morceau d'état individuel. Deux états identiques peuvent être facilement prouvés en comparant le hachage racine et les hachages qui y ont conduit.

En fin de compte, modifier l'état avec des valeurs différentes est impossible car cela entraînera un hachage de racine d'état différent. Toutes les structures d'arbre de hachage de Patricia de Merkle dans la couche d'exécution d'Ethereum utilisent un Trie de Patricia de Merkle. Le réseau possède trois tries : Trie d'état, Trie de stockage et Trie de transaction. De plus, chaque bloc possède son propre Trie de reçus. Bien que les Tries de Patricia de Merkle soient efficaces à bien des égards, Ethereum est motivé pour les remplacer par des Tries de Verkle afin d'atteindre l'état sans état.

Alt: Arbre de Patricia de Merkle

Gaz

Le gaz est la propriété nécessaire dans l'EVM pour l'exécution. Étant donné que l'EVM utilise et a besoin de ressources de calcul pour s'exécuter, le retour de ces efforts est payé avec du gaz pour garantir la sécurité de l'EVM. Les frais de gaz sont calculés comme le montant de gaz requis multiplié par le coût par unité. C'est une valeur dynamique et dépend du type d'opération.

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559a introduit des changements importants au mécanisme des frais de transaction. Payer pour le gaz pour inclure des transactions dans les blocs a fonctionné avec une méthode de type enchère dans le passé. Avec l'EIP-1559, il y a une limite minimale appelée frais de base et un pourboire appelé frais de priorité introduit. Les blocs sont proposés pour commencer à partir de la transaction avec le frais de priorité le plus élevé. Après le processus de bloc, les frais de base sont brûlés et les frais de priorité sont utilisés pour inciter les validateurs.

État

L'état de la blockchain peut être défini comme un ensemble de données (ou variables) qui décrivent un certain système à un moment spécifique. Internet a un état presque depuis le début, mais il était stocké sur un seul serveur. Avec Web3, un état global maintenu sur un réseau ouvert et distribué sécurisé par des méthodes décentralisées a été introduit. Tout le monde peut consulter et vérifier l'état du réseau distribué à tout moment.

Ethereum inclut des comptes, des soldes, des contrats intelligents déployés et des espaces de stockage associés dans l'état global. L'état d'Ethereum croît avec les ajouts et les modifications de ces paramètres. La croissance de l'état devient problématique lorsque le coût matériel d'hébergement d'un nœud complet devient prohibitif. Face à ces défis, Vitalik Buterin introduitle concept d'Ethereum sans état en 2017. Les méthodes proposées pour résoudre la croissance de l'état dans Ethereum incluent l'expiration des données et de l'état.

Différences entre l'expiration des données et l'expiration de l'état

Expiration des données

L'expiration des données ou de l'historique signifie l'élagage des données inutiles des clients après une certaine période. Avec les « points de contrôle de subjectivité faible », les clients pourraient trouver leur chemin pour synchroniser depuis la genèse et élaguer les données historiques inutiles.

La subjectivité fait référence aux nœuds d'un réseau qui s'appuient sur des informations sociales pour parvenir à un consensus sur l'état actuel. À cette lumière, la subjectivité faible fait référence à une chaîne qui peut progresser de manière objective avec quelques informations initiales récupérées socialement. Cependant, les points de contrôle de la subjectivité faible impliquent que tous les nœuds du réseau responsables du consensus appartiennent à la chaîne canonique. Les points de contrôle de la subjectivité faible aident Ethereum PoS à obtenir l'état récent (point de contrôle de la subjectivité faible) à partir d'une source de confiance pour se synchroniser.

EIP-4444fournit le chemin pratique vers@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems">achieve data expiry through weak-subjectivity. La proposition ne vise pas à changer la manière dont les nœuds Ethereum gèrent les données d'état ; elle modifie plutôt l'accès aux données historiques.

Date d'expiration

L'expiration d'état vise à éliminer l'état des nœuds individuels s'il n'a pas été consulté récemment. L'expiration peut être mise en œuvre en termes de résiliation en fonction du loyer ou du temps. L'expiration par le loyer signifie l'imposition d'une surtaxe sur les comptes pour stocker l'état. En revanche, l'expiration par le temps signifie la mise en inactivité des comptes s'ils restent inactifs pendant une certaine période.

La Data et l'Expiration de l'État sont des domaines de recherche ouverts. Les approches actuelles pour atteindre ces statuts proposés impliquent de les faire passer par des réseaux/fournisseurs centralisés. Jusqu'à présent, la faible non-étatique et l'expiration de l'état ont été partiellement réalisées dans Ethereum.

Ethereum sans état

Introduction à la non-appartenance à un État et à l'Ethereum sans État

Ethereum Stateless introduit de nouveaux concepts dans le protocole de base. Idéalement, la non-état ne signifie pas que l'état n'existe pas. Cela signifie plutôt que les clients peuvent choisir l'état qu'ils veulent maintenir. Lorsque les clients reçoivent des blocs validés, ils reçoivent également le témoin correspondant pour ce bloc. Les témoins pour chaque bloc comprennent toutes les données requises pour exécuter les transactions contenues dans ce bloc.

EIP-161introduit la première approche de réduction d'état. Ethereum a subi une attaque de DoS (Déni de Service), et cette vulnérabilité lui a permis de créer des comptes vides qui ont augmenté l'état global d'Ethereum. L'EIP-161 proposait de supprimer les comptes vides avec une valeur zéro (0) à leur nonce qui provenaient de cette attaque, à faible coût. La proposition a été exécutée, entraînant un retour en arrière de l'état.

Un autre effort vers la non-appartenance à un État a été proposé via EIP-4788. Cette proposition visait à exposer les racines des blocs de chaîne de balises dans l'EVM. Similaire à l'approche de la Pont Eth1-Eth2en connectant la chaîne Beacon (couche de consensus) et la couche d'exécution, cette proposition permet un accès minimisé par la confiance entre l'EVM et la couche de consensus.

Parce que chaque bloc d'exécution contient la racine du bloc parent du phare, les événements de créneau manqués n'auraient pas besoin de modifier la racine du bloc précédent. Par conséquent, les prérequis de l'exécution se limitent à réserver un petit espace pour un oracle à confiance minimale dans chaque bloc d'exécution. La proposition suggère de stocker un petit historique des racines de bloc dans un contrat de racine pour améliorer l'efficacité de l'oracle.

La non-statelessness dans Ethereum est possible soit comme une non-statelessness faible ou forte.

Faible État d'absence d'État

L'état de faiblesse n'est pas un état qui élimine le besoin de stockage d'état dans tous les nœuds. Au lieu de cela, il diffère dans la manière dont les nœuds vérifient les modifications de l'état d'Ethereum. Il place la responsabilité du stockage de l'état sur les proposants de blocs et demande à d'autres nœuds de vérifier les blocs sans stocker l'intégralité des données d'état.

Les proposants de blocs doivent stocker toutes les données d'état. Cependant, les clients vérificateurs n'ont pas besoin de stocker les données d'état sur le réseau. Au lieu de cela, ils peuvent stocker la racine d'état (un hachage de l'ensemble de l'état). La faible non-stationnarité nécessite Séparation du proposant-constructeur (PBS)etVerkle essaieimplémentation.

Les proposants créent des témoins en utilisant les données d'état pour prouver les changements d'état, et les validateurs vérifient les preuves par rapport au hachage de la racine d'état.

Fort état de non-appartenance

La forte absence d'état élimine le besoin pour tout nœud de stocker les données d'état. Il fonctionne en incorporant les transactions envoyées et les témoins agrégés par les proposeurs de blocs. Les proposeurs de blocs ne stockent que l'état sur lequel ils travaillent, générant des témoins pour les comptes pertinents. La proposition nécessite encore plus de développement et comprend des exigences comme Listes d'accès ou EIP-2930.

Cependant, certains changements et propriétés peuvent être utilisés pour atteindre l'état de non-état. EIP-2935 propose de servir les hachages des blocs historiques à partir de l'état pour permettre une exécution sans état.

Introduction à l'EIP-2935

L'EIP-2935 vise à enregistrer les hachages de blocs historiques dans l'état de la blockchain dans des emplacements de stockage spéciaux appelés HISTORY_STORAGE_ADDRESS. Ce processus permettra une exécution sans état en facilitant l'accès facile aux informations historiques nécessaires dans les clients sans état.

EIP-2935 propose de stocker les 8192 derniers hachages de blocs historiques dans un contrat système pour les utiliser dans la logique de traitement des blocs. Le problème que cette proposition tente de résoudre est l'hypothèse de l'EVM selon laquelle le client dispose du hachage de bloc récent. Cette approche basée sur des hypothèses ne s'applique pas aux futures versions d'Ethereum, en particulier aux clients sans état.

Inclure les hachages des blocs précédents dans l'état permettra de regrouper ces hachages avec des fonctions de hachage à la vue d'un témoin. Un témoin sera ensuite fourni au client sans état pour vérifier l'exécution et réaliser une exécution sans état. Cette proposition est appelée spécification pré-Verkle car elle peut être implémentée avant l'adaptation aux essais Verkle dans le protocole de base, et elle facilite la non-état partiel.

Étendre la plage de blocs que blockHash sert à 8192 blocs permettra une transition douce vers des méthodes exécutionnelles. Les Rollups peuvent bénéficier de cette fenêtre d'historique plus longue en interrogeant directement ce contrat car les données blockHash sont stockées dans ce contrat. De plus, cet EIP facilitera la validation des preuves liées à la quantité de 8192 blocs de HISTORY_SERVE_WINDOW par rapport à l'état actuel.

Comprendre EIP-2935

EIP-2935 permet aux clients Ethereum, en particulier ceux sans état, d'accéder facilement aux hachages de blocs récents. Pour que cela fonctionne, il introduit quatre nouveaux paramètres :

• BLOCKHASH_SERVE_WINDOW: Indique aux clients combien de hachages de blocs passés ils doivent conserver. La valeur par défaut est 256.
• HISTORY_SERVE_WINDOW: Ce paramètre définit combien de blocs de hachages sont stockés. La valeur par défaut est 8191.
• SYSTEM_ADDRESS: Une adresse spéciale (initialement introduite dans l'EIP-4788) qui agit comme le "caller" pour écrire les hachages de bloc dans le stockage.
• ADRESSE_DE_STOCKAGE_DE_L'HISTORIQUE: L'adresse du contrat où ces hachages de bloc sont stockés.

Les spécifications de la proposition dirigent les derniers hachages de blocs HISTORY_SERVE_WINDOW à être stockés dans un stockage d'anneau à tampon avec une longueur de HISTORY_SERVE_WINDOW.

Tampon circulaire

EIP-2935 utilise une fonctionnalité supplémentaire appelée un tampon circulaire pour le stockage temporaire. Un tampon circulaire est une propriété qui permet à un réseau de réutiliser le même stockage pour des données différentes. Le stockage est limité dans le tampon circulaire à la même emplacement de stockage à chaque fois. Le tampon circulaire sur l'EIP-2935 est utilisé uniquement pour servir la fenêtre de service HISTORY_SERVE_WINDOW requise, car EIP-4788 et les accumulateurs de l'état beacon permettent une preuve contre tout ancêtre.

Règles de choix de fork et spécifications

Après la fourche, lorsque le réseau démarre avec ces considérations EIP, le paramètre HISTORY_STORAGE_ADDRESS sera désigné comme SYSTEM_ADDRESS avec une entrée block.parent.hash (32 octets par défaut), une limite de gaz de 30 000 000 et une valeur de 0. Ce processus déclenchera la fonction set() du contrat d'historique.

Le processus de fork post-proposition diffère du processus de fork régulier. Cette opération set() est une opération système générale, mais l'appel suit ces conventions :

• Doit être exécuté jusqu’à la fin
• Ne compte pas contre la limite de gaz du bloc
• Ne suit pas le mécanisme de combustion EIP-1559
• Si aucun code n'existe à l'adresse HISTORY_STORAGE_ADDRESS, l'appel doit échouer sans erreurs fatales.

Ce processus doit remplir la période de blocage de l'historique HISTORY_SERVE_WINDOW pour répondre à la période de déclenchement du tampon circulaire. Le contrat d'historique ne contiendra que le hachage parent du bloc de bifurcation, qui sert de hachage de référence et de nouveau point de départ du hachage.

Un contrat d'historique de hachage de bloc aura deux opérations : get() et set(). L'opération set() est activée si l'appelant du contrat dans une transaction est égal à l'ADRESSE_DU_SYSTÈME qui a été introduite avec l'EIP-4788. Si l'appelant et l'ADRESSE_DU_SYSTÈME ne sont pas égaux ou ne remplissent pas les conditions, l'opération get() est activée.

L'opération get() est utilisée dans l'EVM pour localiser les hachages de blocs. Elle permet aux appelants de fournir le numéro de bloc qu'ils interrogent, si l'entrée calldata n'est pas de 32 octets (ce qui signifie qu'il s'agit d'un bloc.parent.hash valide) et si la demande est en dehors de la plage ([block.number-HISTORY_SERVE_WINDOW, block.number-1]), elle annule la transaction.

set() prend block.parent.hash en entrée comme calldata lorsque l'appelant appelle le contrat avec une transaction. Il définit également la valeur de stockage comme calldata[0:32] au block.number-1 % HISTORY_SERVE_WINDOW.

L'adresse de stockage de l'historique sera déployée via l'EIP-4788, qui est mentionnée ci-dessus comme le moyen d'accéder aux hachages de blocs directement via la couche de consensus EVM. L'adresse de stockage de l'historique aura la valeur de nonce à 1 et sera exemptée de la norme de nettoyage de nonce zéro de l'EIP-161.

Logique de transition BLOCKHASH

Une préoccupation concernant cet EIP est la meilleure façon de transitionner la logique de résolution de BLOCKHASH après la fourchette. Deux approches majeures sont envisagées :

• Attendre HISTORY_SERVE_WINDOW blocs pour que l'ensemble de l'historique pertinent persiste,
• Stocker tous les derniers hachages de bloc HISTORY_SERVE_WINDOW sur le bloc de la fourche.

Les développeurs choisissent la première option. C'est plus pratique car cela ne nécessite aucun changement temporaire.

Quelle est la différence entre EIP-2935 et des EIP similaires ?

Des EIP similaires ont été proposés auparavant pour permettre et réaliser une exécution sans état. L'EIP-2935 diffère de ces propositions antérieures car il cible les complexités mises en évidence ci-dessous.

• Approche de structure de Trie : EIP-2935 n'utilise pas une structure de type trie avec plusieurs couches et opte plutôt pour une seule liste. Au contraire, l'EIP-4444 propose d'élaguer les données historiques dans les clients d'exécution plus anciens d'un an. D'autres EIP avec des ambitions similaires ont des tries Verkle comme exigences.
• Rédiger l'EIP en code EVM : l'EIP-2935 ne nécessite pas de changement dans l'EVM.
• Stockage en série illimité de hachages : Le stockage en série illimité de hachages est inefficace. Ce EIP surmonte ce problème en regroupant les hachages.

Considérations de sécurité

Étant donné que l'EIP-2935 utilise des contrats intelligents, il risque les attaques de branchement empoisonnées. Cependant, la taille de la racine de l'état rend toute tentative de mise à jour lente et une attaque empoisonnante considérablement plus coûteuse.

Qu'est-ce que cela pourrait apporter ?

• Accélérer les systèmes d'oracles sans confiance : Dans les oracles basés sur Uniswap v2, toute personne ayant accès à un nœud Ethereum peut générer une preuve du stockage d'Uniswap et la soumettre pour validation on-chain. Le prix moyen est déterminé entre le bloc actuel et le bloc de la preuve fournie, avec une preuve validée jusqu'à 256 blocs, car le blockHash supporte jusqu'à 256 blocs. Bénéficiant de l'EIP-2935, ce processus peut être amélioré en permettant l'accès à des anciens hashs de bloc, ce qui signifie que les preuves peuvent être validées sur une période plus longue.
• Permettre aux contrats de tenir compte des assertions d'état passées, de manière décentralisée : l'amélioration EIP-2935 crée la possibilité d'examiner les données de la blockchain depuis l'intérieur de l'EVM, de manière décentralisée. Un client peut interroger l'historique, l'obtenir haché et le vérifier avec d'autres nœuds. La solution pourrait rendre les clients légers efficaces et faciles à mettre en œuvre.
• Pont entre L1 <> L2 : Pour vérifier un message de L2, L1 doit connaître les racines d'état et les hachages de bloc de L2. Cependant, L1 dans son état actuel ne peut pas accéder à des hachages de bloc arbitraires en raison des limites de gaz et des contraintes architecturales. L'EIP-2935 permet à L1 de vérifier les données historiques arbitraires avec la capacité de sonder des preuves d'inclusion pour les anciens événements. L'accès et le pouvoir de vérification s'amélioreront, tout comme les performances de pontage.

Conclusion

EIP-2935 représente une étape cruciale vers la réalisation de l'objectif à long terme d'un Ethereum sans état. Stocker les derniers 8192 hachages de blocs dans un contrat dédié au sein des adresses de l'état aborde une limitation fondamentale dans la conception actuelle. L'hypothèse d'Ethereum selon laquelle les clients ont intrinsèquement accès aux hachages de blocs récents. Dans le contexte de l'exécution sans état, où les clients ne maintiennent plus l'état complet, cette hypothèse devient obsolète. L'EIP-2935 résout cela en introduisant un mécanisme léger, efficace et non intrusif qui permet aux clients sans état d'accéder aux données historiques nécessaires sans modifier l'EVM ou de s'appuyer sur des structures de données complexes comme les essais Verkle.

Au-delà de l'exécution sans état, cette proposition débloque des avantages plus larges dans l'écosystème Ethereum. Il améliore les capacités des oracles sans confiance, étend l'utilité des clients légers et renforce l'interopérabilité entre les solutions de couche 1 et de couche 2 en permettant une vérification fiable des anciennes données d'état. Sa mise en œuvre repose sur un design propre et efficace en gaz, utilisant un stockage à tampon circulaire et des contrats au niveau du système qui évitent le besoin de codage dur dans l'EVM, offrant à la fois simplicité et évolutivité.

Alors qu'Ethereum poursuit son évolution vers une plus grande décentralisation, une plus grande évolutivité et une plus grande accessibilité, l'EIP-2935 sert d'amélioration fondamentale. Il comble l'écart entre l'architecture actuelle statique et le futur sans état envisagé et pose les bases d'une infrastructure plus robuste, efficace et sans permission à travers l'écosystème blockchain.

Avertissement :

1. Cet article est repris de [ 2077research]. Tous les droits d'auteur appartiennent à l'auteur original [Yiğit Yektin]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. L'équipe Gate Learn effectue des traductions de l'article dans d'autres langues. Copier, distribuer ou plagier les articles traduits est interdit sauf mention contraire.