Architecture EVM : Evolution complète : Stratégie de mise à l'échelle progressive d'Ethereum

Alors que l’écosystème Ethereum se développe rapidement, la question de la manière de faire évoluer le réseau tout en préservant la sécurité et la décentralisation est devenue l’un des défis les plus importants. La feuille de route technologique présentée par Vitalik Buterin propose une approche globale visant à optimiser et à étendre l’EVM. Il s’agit d’une stratégie qui augmente progressivement la capacité de traitement d’Ethereum sur deux couches distinctes, à court terme et à long terme.

Optimisation à court terme de l’EVM Ethereum : optimisation du Gas et parallélisation de la validation des blocs

La stratégie de mise à l’échelle à court terme se concentre sur la maximisation de l’efficacité opérationnelle tout en tirant parti de la conception de machine EVM existante. Grâce aux améliorations techniques centrées sur la mise à niveau Glamsterdam, le réseau devrait progressivement améliorer sa capacité de traitement.

L’introduction d’un mécanisme de liste d’accès au niveau des blocs permettra de paralléliser le processus de validation des blocs de l’EVM. Les tâches de validation, qui étaient auparavant exécutées de manière séquentielle, pourront désormais être traitées simultanément par plusieurs processus, ce qui réduira le temps global de génération des blocs. Cela constitue une amélioration qui se traduit directement par une augmentation de la vitesse de traitement des transactions sur l’ensemble du réseau.

Le ePBS (Encrypted Proposer-Builder Separation), qui sera également introduit à Glamsterdam, dispose de plusieurs fonctionnalités clés. Ce qui mérite une attention particulière, c’est la possibilité d’étendre le temps alloué à la validation des blocs pour chaque slot, passant de plusieurs centaines de millisecondes à une proportion de temps plus importante. Cela crée une marge dans le processus de validation, permettant de traiter davantage de données en toute sécurité.

Le fonctionnement du gaz multidimensionnel : Innovation dans la conception de l’EVM

Le mécanisme de revalorisation du gaz ne représente pas simplement un ajustement tarifaire, mais signifie un changement fondamental dans la philosophie de conception de l’EVM. Si le coût en gaz des différentes opérations correspond exactement à leur temps d’exécution et à la consommation de ressources correspondante, cela permettra une allocation plus efficace des ressources réseau.

L’introduction des gaz multidimensionnels fera évoluer le mécanisme de gaz, qui était jusqu’à présent géré dans une seule dimension, vers une structure permettant une gestion indépendante des limites pour plusieurs types de ressources. Dans la première étape, la mise à niveau Glamsterdam prévoit de séparer le “coût de création d’état” du “coût d’exécution et de calldata”.

Par exemple, dans l’opération SSTORE actuelle, le changement d’un emplacement de stockage de zéro à non zéro consomme 20000 gaz. Après le re-prix à Glamsterdam, ce coût devrait être considérablement augmenté, atteignant environ 60000 gaz. Ce changement apparemment négatif a en réalité une visée stratégique. En élargissant simultanément la limite de gaz, il est possible de faire en sorte que la vitesse d’expansion de la capacité d’exécution de la validation des blocs dépasse considérablement la vitesse d’expansion de la taille de l’état de la blockchain.

Dans la conception existante de l’EVM, le gaz est implémenté comme une seule dimension. Par conséquent, toutes les opcodes, comme GAS et CALL, sont basées sur cette hypothèse. Cependant, la transition vers un gaz multidimensionnel nécessite de modifier cette hypothèse de base sans compromettre la compatibilité descendante.

La solution adoptée doit respecter les conditions immuables suivantes. Premièrement, si un appel est initié avec du gaz X, cet appel doit consommer du gaz X et doit pouvoir être utilisé pour des opérations normales, la création d’états ou d’autres dimensions qui pourraient être ajoutées à l’avenir. Deuxièmement, si l’opcode GAS indique actuellement qu’il y a du gaz Y, cela signifie que, même si un appel consommant du gaz X est émis, il doit rester au moins Y - X gaz après le retour de l’appel, pouvant être utilisé pour des opérations ultérieures.

Dans une mise en œuvre concrète, on introduit N+1 dimensions de gaz. Par défaut, N=1 (création d’état), et la dimension supplémentaire est appelée “réservoir”. La logique d’exécution EVM consomme prioritairement le gaz des dimensions dédiées autant que possible, et en cas de pénurie, effectue une consommation supplémentaire à partir du réservoir.

Par exemple, dans une situation où vous possédez du gaz (100000 pour créer un état, 100000 pour le réservoir ), si vous utilisez SSTORE pour créer un nouvel état trois fois, la transition du gaz sera (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000). Dans cette conception, l’opcode GAS renvoie le réservoir, et CALL passe une quantité de gaz spécifiée à partir du réservoir tout en transférant simultanément tout le gaz autre que celui du réservoir.

L’introduction de la tarification multidimensionnelle appliquant des frais de gaz variables différents sur plusieurs dimensions de ressources devrait améliorer la durabilité économique à long terme et réaliser une meilleure efficacité d’allocation des ressources.

Chemin de mise à l’échelle à long terme : Fusion de ZK-EVM et des Blobs

Alors que les améliorations à court terme augmentent l’efficacité des machines EVM existantes, les stratégies de mise à l’échelle à long terme envisagent des modifications de conception plus fondamentales. Deux principales orientations technologiques, ZK-EVM (validation d’exécution EVM basée sur des preuves à connaissance nulle) et Blobs, façonneront l’avenir d’Ethereum.

Actuellement, en 2026, l’émergence de clients compatibles avec ZK-EVM est sur le point de devenir une réalité. Nous atteignons une étape où les nœuds peuvent participer à l’attestation (vérification de signature sur le réseau) en utilisant ZK-EVM. Cependant, à ce stade initial, ces clients n’ont pas encore atteint un niveau de sécurité suffisant pour que le réseau puisse s’y fier complètement. Il est acceptable qu’environ 5 % des nœuds du réseau utilisent ZK-EVM, mais toute adoption au-delà de ce pourcentage sera mise en attente. À ce stade, si des problèmes surviennent avec les preuves ZK-EVM, les récompenses de mise des nœuds individuels ne seront pas confisquées, mais il existe un risque de construction de blocs invalides, ce qui pourrait entraîner une perte de revenus pour ces nœuds.

En 2027, il est recommandé que davantage de nœuds exécutent ZK-EVM. C’est une période où l’accent est mis sur la vérification formelle et l’amélioration continue de la sécurité. Ce qui est important, c’est que seulement 20 % des nœuds du réseau utilisent ZK-EVM, ce qui permet de fournir un chemin de validation à faible coût pour les solo stakers et d’améliorer considérablement la limite de gaz. Étant donné que le nombre total de solo stakers est lui-même inférieur à 20 % du réseau, cette amélioration à ce stade bénéficiera à de nombreux utilisateurs.

À un stade où la technologie est suffisamment mature, un mécanisme de preuve de 3 sur 5 sera introduit. Cela signifie qu’un bloc doit contenir au moins 3 preuves parmi 5 systèmes de preuve différents pour être considéré comme valide. Ce mécanisme de preuve diversifié permet de réduire le risque de dépendre d’une seule technologie et d’améliorer encore la résilience du réseau. À un stade ultérieur, il est prévu que la plupart des nœuds passent à un état où ils dépendent de preuves ZK-EVM, à l’exception des nœuds nécessitant des fonctions d’index.

À long terme, l’objectif est d’améliorer davantage la robustesse du ZK-EVM et de réaliser des vérifications formelles plus rigoureuses. À ce stade, des modifications structurelles au niveau de la machine virtuelle, y compris des orientations telles que RISC-V, seront également envisagées. Cela suggère la possibilité d’une évolution fondamentale de la conception de la machine EVM.

Évolution vers les Blobs et les couches de données avancées

Concernant les Blobs, grâce à l’amélioration continue de la couche de transport PeerDA, l’objectif est d’atteindre finalement un débit de données d’environ 8 Mo/s. Ce niveau de capacité de traitement des données est d’une ampleur suffisante pour répondre adéquatement à la demande d’Ethereum lui-même. Cependant, Ethereum n’a pas l’intention de devenir une couche de données à l’échelle mondiale, mais plutôt de répondre à la demande d’un réseau indépendant.

Actuellement, les Blobs sont principalement utilisés pour le stockage de données dans les solutions de couche 2 (L2). En tant qu’évolution future, il est envisagé d’écrire directement les données des blocs d’Ethereum dans les Blobs. L’objectif de ce changement est d’une importance cruciale. Il sera possible de valider un réseau Ethereum hautement évolutif sans télécharger et réexécuter la chaîne complète.

La réalisation de cet objectif nécessite la combinaison de deux technologies clés. Tout d’abord, les ZK-SNARKs (preuves non interactives succinctes à connaissance nulle) rendent le processus de réexécution lui-même inutile. Ensuite, grâce à PeerDAS et aux Blobs, il devient possible de vérifier la disponibilité des données sans avoir à télécharger toutes les données. Cette combinaison permet à des nœuds légers de participer pleinement à la vérification du réseau.

La stratégie de mise à l’échelle d’Ethereum montre une approche visant à élargir progressivement la capacité du réseau tout en équilibrant l’efficacité à court terme et l’évolution structurelle à long terme. L’optimisation continue de l’EVM et l’introduction progressive de nouvelles techniques de validation détermineront le développement du réseau Ethereum dans les années à venir.