Note de la rédaction : Alors que l'écosystème Ethereum ne cesse de s'étendre, la question de savoir comment mettre à l'échelle le réseau sans sacrifier la sécurité et la décentralisation est devenue un enjeu central. Dans cet article, Vitalik Buterin détaille davantage la voie de mise à l'échelle d'Ethereum : à court terme, des améliorations techniques comme l'optimisation du mécanisme de Gas et la parallélisation de la validation des blocs permettront d'accroître l'efficacité d'exécution ; à long terme, le réseau s'appuiera sur l'architecture ZK-EVM et des données blobs pour augmenter sa capacité.

Dans l'ensemble, cette feuille de route propose un plan de mise en œuvre par étapes, visant à jeter les bases d'une augmentation continue de la capacité du réseau Ethereum au cours des prochaines années.

Voici le texte original :

Parlons maintenant de la mise à l'échelle (scaling). Cela se divise principalement en deux parties : la mise à l'échelle à court terme et la mise à l'échelle à long terme.

Mise à l'échelle à court terme

J'ai déjà écrit ailleurs sur la mise à l'échelle à court terme. L'idée centrale est globalement la suivante :

· Les listes d'accès au niveau du bloc (block-level access lists) (qui seront lancées avec la mise à niveau Glamsterdam) permettront une validation parallélisée des blocs.

· L'ePBS (également prévu pour Glamsterdam) possède plusieurs caractéristiques, dont l'une est : il nous permet d'utiliser en toute sécurité une plus grande proportion du temps de chaque slot pour valider les blocs, au lieu de n'utiliser que quelques centaines de millisecondes comme c'est le cas actuellement.

· Le repricing du Gas (gas repricing) veillera à ce que le coût en gas des différentes opérations corresponde à leur temps d'exécution réel (ainsi qu'aux autres coûts qu'elles engendrent). Nous explorons également dès à présent un mécanisme de gas multidimensionnel (multidimensional gas), permettant de fixer des plafonds distincts pour différentes ressources. Combinées, ces deux mesures nous permettront d'utiliser une plus grande proportion du temps de slot pour valider les blocs, sans craindre les cas extrêmes.

Concernant le gas multidimensionnel, nous avons établi une feuille de route par étapes. La première phase, lors de la mise à niveau Glamsterdam, consistera à séparer le « coût de création d'état » du « coût d'exécution et de calldata ».

Par exemple, actuellement : une opération SSTORE, si elle modifie un emplacement de stockage de non-zéro → non-zéro, coûte 5000 gas ; si elle modifie de zéro → non-zéro, elle coûte 20000 gas.

Lors d'un repricing du gas dans Glamsterdam, ce coût supplémentaire sera significativement augmenté (par exemple, porté à 60000). L'objectif est, tout en augmentant la limite de gas, de permettre à la capacité d'exécution de s'étendre beaucoup plus rapidement que la taille de l'état.

J'ai déjà écrit sur les raisons ici : https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Ainsi, dans Glamsterdam : cette opération SSTORE consommera 5000 de « gas ordinaire » et, par exemple, 55000 de « gas de création d'état ».

Il est important de noter : le gas de création d'état ne comptera pas dans la limite de gas des transactions d'environ 16 millions.

Cela signifie qu'il deviendra possible de créer des contrats plus volumineux qu'actuellement.

Comment le Gas multidimensionnel est-il implémenté dans l'EVM ?

Une question se pose ici : la conception de l'EVM suppose par défaut que le gas n'a qu'une dimension, par exemple, les opcodes GAS, CALL, etc., reposent sur cette hypothèse.

Notre méthode de résolution consiste à maintenir deux invariants :

Si vous initiez un call avec X gas, alors ce call disposera de X gas, utilisable pour des « opérations ordinaires », ou la « création d'état », ou d'autres dimensions qui pourraient être ajoutées à l'avenir.

Si l'opcode GAS vous indique que vous avez Y gas, puis que vous initiez un call consommant X gas, alors après le retour du call, vous aurez toujours au moins Y − X gas disponible pour les opérations suivantes.

La mise en œuvre concrète est la suivante : nous introduisons N+1 dimensions de gas. Par défaut, N = 1 (création d'état), la dimension supplémentaire est appelée reservoir (réserve).

La logique d'exécution de l'EVM est :

Si possible, consommer en priorité le gas des dimensions dédiées.

Si ce n'est pas suffisant, consommer ensuite depuis le reservoir.

Par exemple, si vous possédez : (100000 gas de création d'état, 100000 reservoir)

Si vous effectuez trois opérations SSTORE créant un nouvel état, l'évolution du gas sera : (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)

Dans cette conception :

L'opcode GAS retourne la valeur du reservoir.

L'opcode CALL transmettra la quantité spécifiée de gas depuis le reservoir, ainsi que tout le gas non-reservoir.

Tarification multidimensionnelle du Gas

Par la suite, nous introduirons davantage la tarification multidimensionnelle (multi-dimensional pricing), permettant à différentes dimensions de ressources d'avoir des prix de gas flottants distincts.

Cela apportera :

Une meilleure viabilité économique à long terme.

Une efficacité optimisée dans l'allocation des ressources.

Voir : https://vitalik.eth.limo/general/2024/05/09/multidim.html

Et le mécanisme de reservoir résout justement le problème des appels imbriqués (sub-call) mentionné à la fin de cet article.

Mise à l'échelle à long terme

La mise à l'échelle à long terme comprend principalement deux directions : ZK-EVM et Blobs.

Blobs

Pour les blobs, nous prévoyons d'itérer continuellement sur PeerDAS, avec pour objectif final d'atteindre une capacité de débit de données d'environ 8 Mo/seconde.

Cette échelle :

Est suffisante pour répondre aux besoins propres d'Ethereum.

N'a pas pour ambition de devenir une « couche de données globale ».

Actuellement, les blobs sont principalement utilisés pour les L2. Le plan futur est que les données des blocs Ethereum elles-mêmes soient écrites directement dans les blobs.

L'objectif est de permettre aux utilisateurs de vérifier un réseau Ethereum hautement scalable sans avoir à télécharger et réexécuter toute la chaîne :

Les ZK-SNARKs éliminent le besoin de réexécution.

PeerDAS + blobs permet de vérifier la disponibilité des données sans avoir à télécharger l'intégralité des données.

ZK-EVM

Pour le ZK-EVM, notre objectif est d'augmenter progressivement la dépendance du réseau à son égard.

2026 : Des clients prenant en charge ZK-EVM apparaîtront, permettant aux nœuds d'utiliser ZK-EVM pour participer à l'attestation. Mais ils ne seront pas encore suffisamment sûrs pour que l'ensemble du réseau dépende d'eux. Cependant, si environ 5 % du réseau les utilise, cela sera acceptable. (Si le ZK-EVM rencontre un problème, vous ne serez pas slashing, mais vous pourriez construire sur un bloc invalide et ainsi perdre des récompenses.)

2027 : Nous commencerons à recommander qu'une plus grande proportion de nœuds exécute ZK-EVM, tout en mettant l'accent sur la vérification formelle et l'amélioration de la sécurité. Même si seulement 20 % du réseau utilise ZK-EVM, cela nous permettra d'augmenter significativement la limite de gas, car cela offre une voie de validation à faible coût pour les stakers solo, dont la proportion est elle-même inférieure à 20 %.

Une fois la technologie mature : Nous introduirons un mécanisme de preuve obligatoire 3-sur-5. C'est-à-dire qu'un bloc devra contenir au moins 3 preuves provenant de 5 systèmes de preuve différents pour être considéré comme valide. À ce stade, nous prévoyons que la majorité des nœuds, à l'exception de ceux qui doivent effectuer de l'indexation, dépendront des preuves ZK-EVM.

Long terme : Continuer à améliorer ZK-EVM pour le rendre plus robuste et effectuer des vérifications formelles plus strictes. Cette phase pourrait également impliquer des changements au niveau de la machine virtuelle, par exemple vers des directions comme RISC-V.

Voir : https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052